> -----Original Message-----
> From: [email protected] [mailto:linux-omap-
> [email protected]] On Behalf Of Premi, Sanjeev
> Sent: Friday, February 18, 2011 5:43 PM
> To: Cousson, Benoit
> Cc: [email protected]
> 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: [email protected]
> > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
