> -----Original Message----- > From: Cousson, Benoit > Sent: Monday, February 21, 2011 4:01 PM > To: Premi, Sanjeev > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: hwmod: multi-omap: disabling smartreflex on AM3517 > > Hi Sanjeev, > > On 2/21/2011 10:57 AM, Premi, Sanjeev wrote: > >> 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 > >> > >>> 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? > > Yes, still the same one :-). > Since the AM3517 does not contains the exact same list of IPs, you have > to create a dedicated CHIP_IS_3517 and then change the CHIP_IS_3430 by > CHIP_IS_3430 | CHIP_IS_3517 to every hwmod entries except SR, IVA and > any others IP that will not be there. > > The hwmod list should be considered as a very details "features" list. > So you should not have to create a new feature list elsewhere. it is a > duplication of what the hwmod list is already doing. By dumping the > hwmod list, you should know exactly what is supported by the chip. > > I'm quite sure you will have different clock nodes as well, so you will > have to do the same in the clock_data file. Benoit, I am only worried about making cpu_is_omap3517() or equiv calls in the generic functions _init(), _setup() etc. Gives impression of a hack when I look at the code. BTW, I would be posting an early version of the patch for review in about an hour. Have just one more thing to test. ~sanjeev > > Regards, > 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
