Hi Stephen,
On Tue, Sep 13, 2016 at 12:16 AM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote:
> On 09/01, Geert Uytterhoeven wrote:
>> 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.
>
> Sounds like this is solvable.
Sure.
>> 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.
>
> Ah I wasn't aware we were keeping backwards compatibility around.
>
>> 3. The nvmem subsystem may be overkill to provide access to a simple 32-bit
>> read-only register that never changes value after boot.
>
> The nvmem subsystem is designed to read values from things that
> mostly never change. Overkill may be true, but the nice thing
> about using nvmem APIs is that the driver doesn't have to use
> some platform specific function that duplicates similar
> functionality. It's unfortunate that backwards incompatibility
> limits our ability to move to common linux frameworks when they
> are created after the binding is used.
This is continuing work to support old, current, and new SoCs properly.
When the first support for R-Car Gen2 SoCs was added, many frameworks
didn't have DT support, or didn't even exist.
Unlike in the mobile market, development and life span is much larger than
6 months here...
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
