Hi Geert, On Mon, Sep 14, 2015 at 9:02 PM, Geert Uytterhoeven <[email protected]> wrote: > Hi Magnus, > > On Wed, Sep 9, 2015 at 11:21 AM, Geert Uytterhoeven > <[email protected]> wrote: >> On Wed, Sep 9, 2015 at 7:05 AM, Magnus Damm <[email protected]> wrote: >>> From: Magnus Damm <[email protected]> >>> >>> This patch hacks the CCF core to take clock-indices into >>> consideration when making a default clock name in case >>> clock-output-names is not provided. >>> >>> Without this patch of_clk_get_parent_name() does not work >>> for clocks with multiple indices associated with one node. >>> >>> Proof of concept only. Leaks memory. Not for upstream merge. >>> >>> Not-Yet-Signed-off-by: Magnus Damm <[email protected]> >> >> While this (probably) solves the issue, is this something we want to do? >> What does we gain? E.g. we still need to allocate memory to store the clock >> names, so no memory is saved by not providing clock-output-names. >> But instead of useful names, the clocks now have autogenerated names, and all >> look the same (I don't know e.g. all 384 MSTP clock numbers by heart ;-) > > Actually it's even worse: the autogenerated number is not the MSTP bit > number, which I can relate to the actual clock using > include/dt-bindings/clock/*.h, but the index in the sparse array of used bits, > which depends on how many MSTP clocks are defined in DT. > > So we moved from e.g. "hscif1" through "mstp3.10" ("bit 10 in MSTP set 3", > aka "MSTP310") to "mstp3.0" ("the first clock defined in DT for MSTP set 3").
Thanks for letting me know. It needs to be fixed for sure. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
