[PATCH 0/2] cpufreq: rcar: Enable CPUFreq support

[PATCH 0/2] cpufreq: rcar: Enable CPUFreq support

[Khiem Nguyen]

This series enables CPUFreq support in available R-Car Gen3 SoC.

It depends on 2 series below:
    [PATCH 0/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W
    [RFC 0/4] Add Z clock support

All comments are appreciated.

Khiem Nguyen (2):
   cpufreq: rcar: Add support for R8A7795 SoC
   cpufreq: rcar: Add support for R8A7796 SoC

  drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
  1 file changed, 2 insertions(+)

-- 
1.9.1

[PATCH 1/2] cpufreq: rcar: Add support for R8A7795 SoC

[Khiem Nguyen]

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>
---
  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index ac4a0ba..32f6dda 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -53,6 +53,7 @@ static const struct of_device_id machines[] 
__initconst = {
  	{ .compatible = "renesas,r8a7791", },
  	{ .compatible = "renesas,r8a7793", },
  	{ .compatible = "renesas,r8a7794", },
+	{ .compatible = "renesas,r8a7795", },
  	{ .compatible = "renesas,sh73a0", },

  	{ .compatible = "rockchip,rk2928", },
-- 
1.9.1

[PATCH 2/2] cpufreq: rcar: Add support for R8A7796 SoC

[Khiem Nguyen]

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

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 32f6dda..7d038fd 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -54,6 +54,7 @@ static const struct of_device_id machines[] 
__initconst = {
  	{ .compatible = "renesas,r8a7793", },
  	{ .compatible = "renesas,r8a7794", },
  	{ .compatible = "renesas,r8a7795", },
+	{ .compatible = "renesas,r8a7796", },
  	{ .compatible = "renesas,sh73a0", },

  	{ .compatible = "rockchip,rk2928", },
-- 
1.9.1

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

[Viresh Kumar]

On 10-05-16, 11:57, Khiem Nguyen wrote:
> 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>
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>  1 file changed, 1 insertion(+)

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

-- 
viresh

Re: [PATCH 2/2] cpufreq: rcar: Add support for R8A7796 SoC

[Viresh Kumar]

On 10-05-16, 11:59, Khiem Nguyen wrote:
> Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 32f6dda..7d038fd 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -54,6 +54,7 @@ static const struct of_device_id machines[] __initconst =
> {
>  	{ .compatible = "renesas,r8a7793", },
>  	{ .compatible = "renesas,r8a7794", },
>  	{ .compatible = "renesas,r8a7795", },
> +	{ .compatible = "renesas,r8a7796", },
>  	{ .compatible = "renesas,sh73a0", },
> 
>  	{ .compatible = "rockchip,rk2928", },

Well, you could have done that in the same patch. But I don't mind two patches
now.

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

-- 
viresh

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

[Geert Uytterhoeven]

Hi Viresh,

On Tue, May 10, 2016 at 7:07 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 10-05-16, 11:57, Khiem Nguyen wrote:
>> 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>
>> ---
>>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>>  1 file changed, 1 insertion(+)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Quoting Viresh when this file was introduced:
| This is going to be done once per boot and this shouldn't hurt. And for new
| platforms we may do things differently as they are going to use
opp-v2 bindings.

As r8a7795/r8a7796 are not arm32 "shmobile", but arm64, perhaps we should
use this new "opp-v2" binding instead? Has it been finalized?

Thanks!

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 1/2] cpufreq: rcar: Add support for R8A7795 SoC

[Viresh Kumar]

On 10-05-16, 10:17, Geert Uytterhoeven wrote:
> Hi Viresh,
> 
> On Tue, May 10, 2016 at 7:07 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 10-05-16, 11:57, Khiem Nguyen wrote:
> >> 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>
> >> ---
> >>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 
> Quoting Viresh when this file was introduced:
> | This is going to be done once per boot and this shouldn't hurt. And for new
> | platforms we may do things differently as they are going to use
> opp-v2 bindings.
> 
> As r8a7795/r8a7796 are not arm32 "shmobile", but arm64, perhaps we should
> use this new "opp-v2" binding instead? Has it been finalized?

Yeah, that would be preferred.

-- 
viresh