On Mon, 7 May 2012, Mohammed, Afzal wrote:
> On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
(attribution lost)
> > > +static struct omap_hwmod omap3xxx_gpmc_hwmod = {
> > > + .name = "gpmc",
> > > + .class = &omap3xxx_gpmc_hwmod_class,
> > > + .clkdm_name = "l3_init_clkdm",
> > > + .mpu_irqs = omap3xxx_gpmc_irqs,
> > > + .main_clk = "gpmc_fck",
> > > + .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> > > +};
> >
> > Is there some reason why you are setting the HWMOD_INIT_NO_RESET flag
> > here? Seems to me that the kernel should not rely on the bootloader GPMC
> > configuration, but should use a configuration from the board file or DT.
>
> Major reason was that there are some boards that rely on bootloader
> settings, eg. kernel does not do any setting for smsc911x. I did not
> want to break those, at least it causes problem with omap3evm, see below
But this is the whole point. The Linux GPMC driver and integration code
should be setting up the GPMC registers based on board file and/or DT
data, before the kernel touches any GPMC devices.
We don't want to rely on the bootloader settings unless we absolutely have
no other choice. Otherwise, the stability of the kernel could easily be
impacted by the bootloader's GPMC timings and other register settings, and
we want to minimize those potential sources of variation.
So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here,
which doesn't sound like the case so far, we need to understand exactly
why this is so.
> Removing it causes multiple problems, one is that CS0 is valid after
> reset of module, with base address starting from zero, which causes
> requesting resource failure for CS0, with the way it is currently coded
> (GPMC resource starts from 1MB).
Can't this be handled by using a custom hwmod reset function for the GPMC?
> Even upon skipping CS0, kernel oops at seemingly unrelated location as
> follows, probably due to gpmc reset, as bootloader configured values are
> modified to reset value. Omap3 evm uses smsc911x.
Sounds like you've got a good test platform, then :-)
> Another issue on OMAP3EVM is the detection of evm revision based on phy id,
> by reading hardcoded address, 0x2c000000. It had to be skipped to reach till
> above mentioned.
Looking at omap3_evm_get_revision() it seems that the OMAP3EVM detection
happens by reading the Ethernet chip's revision register. So can't this
be fixed by programming the GPMC appropriately to access the Ethernet
chip first?
- Paul
--
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
