[PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Simon Horman]

From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>

After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev
driver", will use cpufreq-dt-platdev driver to enable cpufreq-dt support.
Hence, follow the implementation to support new R8A7795 SoC.

Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
 1 file changed, 1 insertion(+)

This is identical to a patch posted by Khiem last year.
At the time it was asked if using opp-v2 was the preferred approach.

https://patchwork.kernel.org/patch/9054011/

An inspection of the current upstream kernel code seems to indicate
that adding a binding as this patch does is compatibile with using opp-v2
and I plan to post DTS patches separately which make use of the opp-v2
bindings - they depend on this driver change to work.

I have provided an integration patch with this patch, those DTS changes,
and Renesas clock updates also depended on by the DTS changes. The result
is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.

If this work is acceptable I plan to follow up with patches to
enable CPUFreq on the r8a7796 (R-Car M3-W).

https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7795-cpufreq

A description of steps taken to lightly exercise the above can be found here:

http://elinux.org/Tests:R-CAR-GEN3-CPUFreq

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 096aea7fcb67..13b72f3c420b 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -67,6 +67,7 @@ static const struct of_device_id machines[] __initconst = {
 	{ .compatible = "renesas,r8a7792", },
 	{ .compatible = "renesas,r8a7793", },
 	{ .compatible = "renesas,r8a7794", },
+	{ .compatible = "renesas,r8a7795", },
 	{ .compatible = "renesas,sh73a0", },
 
 	{ .compatible = "rockchip,rk2928", },
-- 
2.1.4

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Viresh Kumar]

On 04-08-17, 15:18, Simon Horman wrote:
> From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> 
> After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev
> driver", will use cpufreq-dt-platdev driver to enable cpufreq-dt support.
> Hence, follow the implementation to support new R8A7795 SoC.
> 
> Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> This is identical to a patch posted by Khiem last year.
> At the time it was asked if using opp-v2 was the preferred approach.
> 
> https://patchwork.kernel.org/patch/9054011/
> 
> An inspection of the current upstream kernel code seems to indicate
> that adding a binding as this patch does is compatibile with using opp-v2
> and I plan to post DTS patches separately which make use of the opp-v2
> bindings - they depend on this driver change to work.
> 
> I have provided an integration patch with this patch, those DTS changes,
> and Renesas clock updates also depended on by the DTS changes. The result
> is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
> 
> If this work is acceptable I plan to follow up with patches to
> enable CPUFreq on the r8a7796 (R-Car M3-W).
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7795-cpufreq
> 
> A description of steps taken to lightly exercise the above can be found here:
> 
> http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 096aea7fcb67..13b72f3c420b 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -67,6 +67,7 @@ static const struct of_device_id machines[] __initconst = {
>  	{ .compatible = "renesas,r8a7792", },
>  	{ .compatible = "renesas,r8a7793", },
>  	{ .compatible = "renesas,r8a7794", },
> +	{ .compatible = "renesas,r8a7795", },
>  	{ .compatible = "renesas,sh73a0", },
>  
>  	{ .compatible = "rockchip,rk2928", },

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Rafael J. Wysocki]

On Monday, August 7, 2017 5:37:05 AM CEST Viresh Kumar wrote:
> On 04-08-17, 15:18, Simon Horman wrote:
> > From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> > 
> > After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev
> > driver", will use cpufreq-dt-platdev driver to enable cpufreq-dt support.
> > Hence, follow the implementation to support new R8A7795 SoC.
> > 
> > Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > This is identical to a patch posted by Khiem last year.
> > At the time it was asked if using opp-v2 was the preferred approach.
> > 
> > https://patchwork.kernel.org/patch/9054011/
> > 
> > An inspection of the current upstream kernel code seems to indicate
> > that adding a binding as this patch does is compatibile with using opp-v2
> > and I plan to post DTS patches separately which make use of the opp-v2
> > bindings - they depend on this driver change to work.
> > 
> > I have provided an integration patch with this patch, those DTS changes,
> > and Renesas clock updates also depended on by the DTS changes. The result
> > is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
> > 
> > If this work is acceptable I plan to follow up with patches to
> > enable CPUFreq on the r8a7796 (R-Car M3-W).
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7795-cpufreq
> > 
> > A description of steps taken to lightly exercise the above can be found here:
> > 
> > http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
> > 
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index 096aea7fcb67..13b72f3c420b 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -67,6 +67,7 @@ static const struct of_device_id machines[] __initconst = {
> >  	{ .compatible = "renesas,r8a7792", },
> >  	{ .compatible = "renesas,r8a7793", },
> >  	{ .compatible = "renesas,r8a7794", },
> > +	{ .compatible = "renesas,r8a7795", },
> >  	{ .compatible = "renesas,sh73a0", },
> >  
> >  	{ .compatible = "rockchip,rk2928", },
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> 

Applied, thanks!

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Geert Uytterhoeven]

Hi Viresh,

On Mon, Aug 7, 2017 at 5:37 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 04-08-17, 15:18, Simon Horman wrote:
>> From: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
>>
>> After the commit "a399dc9fc50 cpufreq: shmobile: Use generic platdev
>> driver", will use cpufreq-dt-platdev driver to enable cpufreq-dt support.
>> Hence, follow the implementation to support new R8A7795 SoC.
>>
>> Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> This is identical to a patch posted by Khiem last year.
>> At the time it was asked if using opp-v2 was the preferred approach.
>>
>> https://patchwork.kernel.org/patch/9054011/
>>
>> An inspection of the current upstream kernel code seems to indicate
>> that adding a binding as this patch does is compatibile with using opp-v2
>> and I plan to post DTS patches separately which make use of the opp-v2
>> bindings - they depend on this driver change to work.
>>
>> I have provided an integration patch with this patch, those DTS changes,
>> and Renesas clock updates also depended on by the DTS changes. The result
>> is working CPUFreq for the r8a7795 (R-Car H3) ES1.0.
>>
>> If this work is acceptable I plan to follow up with patches to
>> enable CPUFreq on the r8a7796 (R-Car M3-W).
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/r8a7795-cpufreq
>>
>> A description of steps taken to lightly exercise the above can be found here:
>>
>> http://elinux.org/Tests:R-CAR-GEN3-CPUFreq
>>
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index 096aea7fcb67..13b72f3c420b 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -67,6 +67,7 @@ static const struct of_device_id machines[] __initconst = {
>>       { .compatible = "renesas,r8a7792", },
>>       { .compatible = "renesas,r8a7793", },
>>       { .compatible = "renesas,r8a7794", },
>> +     { .compatible = "renesas,r8a7795", },
>>       { .compatible = "renesas,sh73a0", },
>>
>>       { .compatible = "rockchip,rk2928", },
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

I'm still a bit confused about your original comment when introducing this
file with the ever-growing table of SoCs:

    "And for new platforms we may do things differently as they are going
     to use opp-v2 bindings."

Hence I was under the impression the growing would be mitigated by new SoCs
using the opp-v2 bindings instead, and not needing an entry in the table.

Perhaps I have misunderstood that comment?

Thanks for the clarification!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] cpufreq: rcar: Add support for R8A7795 SoC

[Viresh Kumar]

On 14-08-17, 15:36, Geert Uytterhoeven wrote:
> I'm still a bit confused about your original comment when introducing this
> file with the ever-growing table of SoCs:
> 
>     "And for new platforms we may do things differently as they are going
>      to use opp-v2 bindings."
> 
> Hence I was under the impression the growing would be mitigated by new SoCs
> using the opp-v2 bindings instead, and not needing an entry in the table.
> 
> Perhaps I have misunderstood that comment?

Not really.

I have sent two patches to take care of your concerns. Do let me know if you
have any concerns with them.

-- 
viresh