Hi,
On Friday 16 May 2014 01:44 PM, Tomi Valkeinen wrote:
On 12/05/14 18:48, Tony Lindgren wrote:
Also, I'm wondering why we still have .clk and .opt_clks entries in the
hwmod data for am43xx and omap5 which are both device tree based with
all the clocks coming from .dts files?
I think they are needed for the omap_device/hwmod stuff to work. Only
omapdss driver knows about the clocks defined in the .dts files, and the
omap_device/hwmod code still needs to do the reset and maybe some other
tasks that require the clocks.
We're already populating the hwmod data from dts entries, that's done by
omap_device_build_from_dt. Why aren't we doing that for dt defined clocks?
I'd rather not start adding new data that will then just be removed, that's
what people call "pointless extra churn".
I don't know why. I have to say I'm not 100% sure if that's done or not,
but at least I can't find where it's done.
The reason why clocks are needed from hwmod data is because we still
don't populate hwmod fields like main_clk and opt_clock from DT clocks.
The reason why this isn't done yet is because we currently haven't
figured out a clean way to tell hwmod what clock is the main_clk, and
what clocks are optional clocks.
One of the proposed methods was to assume the clock named to be "fck" as
main_clk, and the remaining clocks as optional clocks for hwmod. That
method wasn't agreed upon, this looks like the thread which discusses this:
http://marc.info/?l=linux-arm-kernel&m=138928084823142&w=2
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
