* Tony Lindgren [off-list ref] [131213 09:32]:

* Rajendra Nayak [off-list ref] [131212 03:40]:

quoted

v1 of this series was posted a while back [1] but there wasn't much that
was concluded if the approach used in the series was acceptable or if there
are better alternatives. So I am just doing a repost of these to see if we
can conclude this time around.

Needless to say, patches are based off Teros omap-clocks-to-dt v10 series [2]
and I also pulled in Tonys fix to handle DT nodes with multiple 'ti,hwmod'
values [3]. The approach taken in the series *does not* work for cases with
multiple 'ti,hwmod' values and hence [3] helps me skip those instances
for now. But based on some of the recent discussions on multiple 'ti-hwmod'
values [4] it looks like its generally agreed upon that having DT nodes with
multiple 'ti-hwmod' property is wrong and that those instances need to be
fixed up anyway.

Yeah we need to have 1-to-1 mapping of device entries in the .dtsi files
to the device entries in the omap_hwmod_*_data.c files. And then we can
just deprecate "ti,hwmods" property and start parsing the standard compatible
flag instead.

FYI seems like this series needs some dependencies solved first, so assuming
you'll be resposting this.

Regards,

Tony

  

quoted

[1] http://www.spinics.net/lists/linux-omap/msg95746.html
[2] http://www.spinics.net/lists/devicetree/msg13455.html
[3] http://www.spinics.net/lists/arm-kernel/msg288036.html
[4] http://www.spinics.net/lists/arm-kernel/msg288023.html

Rajendra Nayak (3):
  ARM: OMAP2+: Add support to parse 'main_clk' info from DT
  ARM: OMAP2+: Add support to parse optional clk info from DT
  ARM: OMAP4: dts: Add main and optional clock data into DT

 arch/arm/boot/dts/omap4.dtsi               |  100 +++++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod.c           |   88 ++++++++++++++++++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  122 ----------------------------
 3 files changed, 180 insertions(+), 130 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html