ARM: OMAP: OMAP5 & AM43x DSS
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 11 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 11 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/11] ARM: OMAP: OMAP5 & AM43x DSS
Hi,
Quoted 11 lines · Tomi Valkeinen
Quoted 9 lines · Tony Lindgren
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
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