Skip to content

ARM: OMAP2+: hwmod module clock type support

Tony Lindgren linux-arm-kernel linux-clk linux-devicetree linux-omap 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 30 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 30 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.

Read the v1 thread

Cover letter [PATCH 00/30] ARM: OMAP2+: hwmod module clock type support
Quoted 22 lines · Tero Kristo
Quoted 17 lines · Tony Lindgren

Hi,

Nice to see this moving along :)

Quoted 11 lines · Tero Kristo

The ordering on this set is kind of tricky to avoid any boot issues, and it still currently causes a boot breakage between the DTS data introduction and removal of hwmod data; this generates duplicate entries for clocks which is prone to cause issues (both DT and hwmod have the same entries in place under the hwmod data is removed.) I didn't quite figure out a good way to avoid this, and could use some guidance here. Shall we squash the DT + hwmod data patches together? This avoids the boot breakage but creates pretty large patches. Also, AMx3xx data needs to be grouped together as part of their data is re-used commonly by both SoCs.

Quoted 3 lines

How about use clocks from dts if clocks property is defined? Otherwise fall back to the old static data. Then drop the static data later on with follow up patches.

Quoted 6 lines

The underlying issue is the hardcoded names of hwmod clocks within hwmod data. I think I figured out a fix for this, I am adding a few patches to this series to lookup main_clk based on the hwmod name itself. This allows re-directing the main_clk to the DT module clock in case one is available for the hwmod. The bisect issues seem to be gone with this also, I need to cleanup the patches a bit and re-post.

OK yes generated names sounds like a good solution to support the old way of doing things.

Regards,

Tony