> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Premi, Sanjeev > Sent: Friday, February 18, 2011 5:43 PM > To: Cousson, Benoit > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: hwmod: multi-omap: disabling smartreflex on AM3517 > > > -----Original Message----- > > From: Cousson, Benoit > > Sent: Tuesday, February 15, 2011 6:18 PM > > To: Premi, Sanjeev > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: Re: hwmod: multi-omap: disabling smartreflex on AM3517 > > > > Hi Sanjeev, > > > > On 2/15/2011 12:51 PM, Premi, Sanjeev wrote: > > > AM3517 doesn't support SmartReflex. > > > > > > However, these HWMODS are defined in omap3xxxx_hwmods[]: > > > &omap34xx_sr1_hwmod, > > > &omap34xx_sr2_hwmod, > > > &omap36xx_sr1_hwmod, > > > &omap36xx_sr2_hwmod, > > > > > > (similar definition in l4_slaves as well) > > > > > > This leads to crash when booting the kernel on AM3517EVM during > > > _setup(). > > > > > > I see the field .omap_chip being initialized; but not used. > > > > Yes, it is. During the hwmod initialization (omap_hwmod_init), only the > > hwmods that match the correct chip version are kept. > > I guess that your problem is that AM3517 is probably seen as a regular > > 3430 for the moment. > > > > > If I were to use this - along with cpu_is_omap3517(), I would need > > > to define a new flag e.g. CHIP_IS_AM3517 and add it to almost all > > > devices defined in omap_hwmod_3xxx_data.c. > > > > > > Before going all out on making changes, wanted to check if there is > > > a better way. Has this/similar possibility been considered earlier? > > > > Well, this is the best way to do that for my point of view. This > > .omap_chip field was done for that purpose. > > During device init, the sr code will do query for the smartreflex hwmod > > and will failed, thus avoiding to do further initialization. > > [sp] Trying to avoid big change, and thinking 'narrowly' about this > issue in isolation, I had been mulling adding SmartReflex to > the omap3_features; and (somehow) using the same. > > But after noticing the patch related to USBOTG on AM35x, I think > original proposal is unambiguous and best way forward. > > Started working on the patch. Hope to have it ready later tonight > or tomorrow. > [sp] Just came across another issue while making this patch: Checking for presence of IVA. There is not IVA on AM3517. With existing CHIP_IS_3430 flag, the hwmod for IVA will be initialized. Benoit, Any ideas here? ~sanjeev -- 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
