Hi Viresh,
On Mon, Aug 7, 2017 at 5:37 AM, Viresh Kumar <viresh.ku...@linaro.org> wrote:
> On 04-08-17, 15:18, Simon Horman wrote:
>> From: Khiem Nguyen <khiem.nguyen...@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...@rvc.renesas.com>
>> Signed-off-by: Simon Horman <horms+rene...@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.ku...@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 -- ge...@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
