Hi Dirk,
On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme <dirk.behme@xxxxxxxxxxxx> wrote:
> I think I just want to discuss if we have a clever idea to further improve
> one detail. That is, if we have a clever idea to avoid the copy & paste
> between the family members using anything like a hierarchical way of
> defining the clocks in r8a779x-cpg-mssr.h.
>
>> Given the small amount of work needed to bootstrap r8a7796, I
>> think they still hold on their promises.
>
> Well, regarding the r8a779x-cpg-mssr.h the small amount of work needed isn't
> a really good argument if you are good with cp & sed for the copy & paste
> done ;)
They're not really created by cp & sed, as they must match the table in the
datasheet (the latter may have been created by copy & paste though :-)
> What I fear we end up the way we are doing the copy & paste
> r8a779x-cpg-mssr.h is having 5 or 6 or even more of these files, all > 90%
> identical. And once you have to change anything, you either have to change
> all these files. Or you miss anything, ending up with subtle bugs when one
> SoC does behave differently than an other one.
The point is these files are stable ABI: no single value can be changed.
No value can be reused. Only new values can be appended at the bottom
(if a newer revision of the datasheet documents more clocks than the old
version, which happens from time to time).
IMHO a hierarchical way of defining the clocks has more opportunity of
accidentally referring to a clock that doesn't exist on a particular SoC.
Furthermore, r8a779x-cpg-mssr.h is not a good name to be part of a DT binding,
due to the wildcard.
A future SoC may will match r8a779x and even be called (R-Car <something>3?),
while using a completely different CPG block.
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
