Hi Stephen,
On Thu, Jun 30, 2016 at 10:14 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote:
> On 06/01, Geert Uytterhoeven wrote:
>> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
>> state of the mode pins either by a call from the board code, or directly
>> by using a hardcoded register access. This is a bit messy, and creates a
>> dependency between driver and platform code.
>>
>> This RFC patch series converts the various Renesas R-Car clock drivers
>> and support code from reading the mode pin states using a hardcoded
>> register access to using a new R-Car RST driver.
>
> Dumb question, can we use the nvmem reading APIs instead of an
> SoC specific function to read the modes?
Thanks for your suggestion, the nvmem API indeed looks like a suitable API,
as it does support read-only nvmems.
Unfortunately I also see a few disadvantages:
1. nvmem_init() is a subsys_initcall(), while most of our users (except for
the recent renesas-cpg-mssr driver) are clock drivers using
CLK_OF_DECLARE(), and are thus initialized from of_clk_init() at much
earlier time_init() time.
Of course the mvmem subsystem and/or the clock drivers can be changed, if
deemed useful.
2. Using the nvmem DT bindings means we have to add more DT glue from the
nvmem consumer(s) to the nvmem provider. As we need to provide backwards
compatibility with old DTSes, this means we need more C code or DT fixup
code to handle that.
3. The nvmem subsystem may be overkill to provide access to a simple 32-bit
read-only register that never changes value after boot.
Thoughts?
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
