Hi Sanjeev,
On 2/25/2011 12:39 PM, Premi, Sanjeev wrote:
From: Cousson, Benoit
Sent: Wednesday, February 23, 2011 9:23 PM
[...]
In that case you can handle that using cpu_is_3517().
omap_hwmod_init(omap3xxx_common_hwmods);
if (omap3_has_smartreflex())
omap_hwmod_init(omap3xxx_sr_hwmods);
if (omap3_has_iva())
omap_hwmod_init(omap3xxx_iva_hwmods);
if (cpu_is_omap3517())
omap_hwmod_init(omap3xxx_emac_usb_vpfe_hwmods);
...
Isn't it enough for your needs?
[sp] Removal of smartreflex has more cyclic dependencies than I expected.
I didn't anticipated that either :-(
Just removing omap34xx_sr1_hwmod, omap34xx_sr2_hwmod isn't sufficient.
It leads to:
[ 0.000000] omap_hwmod: l4_core: cannot clk_get interface_clk sr_l4_ick
[ 0.000000] omap_hwmod: l4_core: cannot clk_get interface_clk sr_l4_ick
Now wemoving, omap3_l4_core__sr1 and omap3_l4_core__sr2 from the array
omap3xxx_l4_core_slaves[] leads to ripple effect in pretty much all
hwmods.
. omap3xxx_l4_core_slaves is referenced in omap3xxx_l4_core_hwmod,
. omap3xxx_l4_core_hwmod is referenced in many other hdmods.
. and so on.
In the end, we might end up making changes to almost all.
I will be submitting an updated patch in about an hour.
I'm afraid, we will probably end up with a dynamic binding solution like
what we have to do for the clock framework for the similar reason.
We can optimize the size but it will impact the performance... the usual
trade off.
Thanks,
Benoit
--
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