[v1] clk: tegra20: Add 216 MHz entry for PLL_X

Message ID adc15215591018b4a35a7d64e065f81bb09e214e.1513018125.git.digetx@gmail.com
State New
Headers show
Series
  • [v1] clk: tegra20: Add 216 MHz entry for PLL_X
Related show

Commit Message

Dmitry Osipenko Dec. 11, 2017, 6:50 p.m.
The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
clock driver doesn't provide that rate, so the requested clock is rounded
up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 drivers/clk/tegra/clk-tegra20.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Peter De Schrijver Dec. 12, 2017, 10:02 a.m. | #1
On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote:
> The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
> clock driver doesn't provide that rate, so the requested clock is rounded
> up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
> 

This seems odd. If there's no table entry, _calc_rate should kick in and
calculate the parameters for 216MHz. Any idea why this is not happening?

Peter.

> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>  drivers/clk/tegra/clk-tegra20.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> index cbd5a2e5c569..e33d7548a4e9 100644
> --- a/drivers/clk/tegra/clk-tegra20.c
> +++ b/drivers/clk/tegra/clk-tegra20.c
> @@ -269,6 +269,11 @@ static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
>  	{ 13000000,  312000000,  312, 13, 1, 12 },
>  	{ 19200000,  312000000,  260, 16, 1,  8 },
>  	{ 26000000,  312000000,  312, 26, 1, 12 },
> +	/* 216 MHz */
> +	{ 12000000, 216000000,  216,  12, 1, 12 },
> +	{ 13000000, 216000000,  216,  13, 1, 12 },
> +	{ 19200000, 216000000,  180,  16, 1,  8 },
> +	{ 26000000, 216000000,  216,  26, 1, 12 },
>  	{        0,          0,    0,  0, 0,  0 },
>  };
>  
> -- 
> 2.15.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dmitry Osipenko Dec. 12, 2017, 12:08 p.m. | #2
On 12.12.2017 13:02, Peter De Schrijver wrote:
> On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote:
>> The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
>> clock driver doesn't provide that rate, so the requested clock is rounded
>> up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
>>
> 
> This seems odd. If there's no table entry, _calc_rate should kick in and
> calculate the parameters for 216MHz. Any idea why this is not happening?

Actually, it is happening. Please ignore this patch.

If PLL's rate could be calculated, why do we need the predefined tables?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter De Schrijver Dec. 12, 2017, 3:17 p.m. | #3
On Tue, Dec 12, 2017 at 03:08:08PM +0300, Dmitry Osipenko wrote:
> On 12.12.2017 13:02, Peter De Schrijver wrote:
> > On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote:
> >> The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
> >> clock driver doesn't provide that rate, so the requested clock is rounded
> >> up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
> >>
> > 
> > This seems odd. If there's no table entry, _calc_rate should kick in and
> > calculate the parameters for 216MHz. Any idea why this is not happening?
> 
> Actually, it is happening. Please ignore this patch.
> 
> If PLL's rate could be calculated, why do we need the predefined tables?

The algorithm to calculate the PLL parameters is rather crude. It will
favour undershooting the rate rather than overshooting. This is fine for
DVFS usecases when you want to avoid a too high clock rate, but not good
for eg display or memory, where as close as match as possible is needed.

Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Dmitry Osipenko Dec. 12, 2017, 9:37 p.m. | #4
On 12.12.2017 18:17, Peter De Schrijver wrote:
> On Tue, Dec 12, 2017 at 03:08:08PM +0300, Dmitry Osipenko wrote:
>> On 12.12.2017 13:02, Peter De Schrijver wrote:
>>> On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote:
>>>> The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
>>>> clock driver doesn't provide that rate, so the requested clock is rounded
>>>> up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
>>>>
>>>
>>> This seems odd. If there's no table entry, _calc_rate should kick in and
>>> calculate the parameters for 216MHz. Any idea why this is not happening?
>>
>> Actually, it is happening. Please ignore this patch.
>>
>> If PLL's rate could be calculated, why do we need the predefined tables?
> 
> The algorithm to calculate the PLL parameters is rather crude. It will
> favour undershooting the rate rather than overshooting. This is fine for
> DVFS usecases when you want to avoid a too high clock rate, but not good
> for eg display or memory, where as close as match as possible is needed.
Okay, thank you for the clarification.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cbd5a2e5c569..e33d7548a4e9 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -269,6 +269,11 @@  static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
 	{ 13000000,  312000000,  312, 13, 1, 12 },
 	{ 19200000,  312000000,  260, 16, 1,  8 },
 	{ 26000000,  312000000,  312, 26, 1, 12 },
+	/* 216 MHz */
+	{ 12000000, 216000000,  216,  12, 1, 12 },
+	{ 13000000, 216000000,  216,  13, 1, 12 },
+	{ 19200000, 216000000,  180,  16, 1,  8 },
+	{ 26000000, 216000000,  216,  26, 1, 12 },
 	{        0,          0,    0,  0, 0,  0 },
 };