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

2017-12-12 Thread Dmitry Osipenko 
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.

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

2017-12-12 Thread Dmitry Osipenko 
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.

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

2017-12-12 Thread Peter De Schrijver 
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.

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

2017-12-12 Thread Peter De Schrijver 
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.

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

2017-12-12 Thread Dmitry Osipenko 
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?

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

2017-12-12 Thread Dmitry Osipenko 
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?

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

2017-12-12 Thread Peter De Schrijver 
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 
> ---
>  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[] = {
>   { 1300,  31200,  312, 13, 1, 12 },
>   { 1920,  31200,  260, 16, 1,  8 },
>   { 2600,  31200,  312, 26, 1, 12 },
> + /* 216 MHz */
> + { 1200, 21600,  216,  12, 1, 12 },
> + { 1300, 21600,  216,  13, 1, 12 },
> + { 1920, 21600,  180,  16, 1,  8 },
> + { 2600, 21600,  216,  26, 1, 12 },
>   {0,  0,0,  0, 0,  0 },
>  };
>  
> -- 
> 2.15.1
>

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

2017-12-12 Thread Peter De Schrijver 
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 
> ---
>  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[] = {
>   { 1300,  31200,  312, 13, 1, 12 },
>   { 1920,  31200,  260, 16, 1,  8 },
>   { 2600,  31200,  312, 26, 1, 12 },
> + /* 216 MHz */
> + { 1200, 21600,  216,  12, 1, 12 },
> + { 1300, 21600,  216,  13, 1, 12 },
> + { 1920, 21600,  180,  16, 1,  8 },
> + { 2600, 21600,  216,  26, 1, 12 },
>   {0,  0,0,  0, 0,  0 },
>  };
>  
> -- 
> 2.15.1
>