Hi Viresh, On Mon, Aug 7, 2017 at 5:37 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 04-08-17, 15:18, Simon Horman wrote: >> From: Khiem Nguyen <khiem.nguyen.xt@xxxxxxxxxxxxxxx> >> >> 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@xxxxxxxxxxxxxxx> >> Signed-off-by: Simon Horman <horms+renesas@xxxxxxxxxxxx> >> --- >> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx 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
