Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc

[Tony Lindgren <tony@atomide.com>]

* Mohammed, Afzal <afzal@ti.com> [120525 03:20]:
> Hi Tony,
> 
> On Fri, May 25, 2012 at 12:56:59, Tony Lindgren wrote:
> > * Paul Walmsley <paul@pwsan.com> [120523 17:55]:
> > > On Tue, 22 May 2012, Tony Lindgren wrote:
> > > > 
> > > > Unfortunately for many of the older boards these values will probably
> > > > remain unknown.
> > > > 
> > > > So the better approach here is to just disable frequency scaling
> > > > for these cases. Otherwise we'll be breaking old boards with smsc911x
> > > > where the timings for the FPGA controlling smsc911x are unknown.
> > > > 
> > > > If we somehow manage to get those values without breaking support for
> > > > these boards, then yes I agree we should deprecate hardcoded and
> > > > bootloader values.
> > > 
> > > I was thinking that if we log the register values supplied by the 
> > > bootloader to the console, then someone can write a patch to the board 
> > > file or DT data to set those register values explicitly in the kernel, 
> > > once they're known.  Or at least just report them to the l-o list.
> > > 
> > > So then that should reduce the problem cases down to boards which no one 
> > > reports the data to the mailing list within a few mainline kernel releases 
> > > -- i.e., boards which are unmaintained.  For those boards, I'd suggest 
> > > that we just drop GPMC support until someone shows up who has a board and 
> > > can test-boot it.  Or just drop the board completely ;-)
> > 
> > OK seems fair to me. It still allows us to boot the older boards with
> > minimal changes (but without L3 frequency scaling).
> > 
> > Sounds like those registers should be dumped only if no configuration
> > is specified to avoid spamming the console.
> 
> Shall I take it as go ahead to create a patch on
> Documentation/feature-removal-schedule.txt in the next version of gpmc
> series stating that implicit boot loader GPMC timings will be removed
> in three Kernel releases ? (i.e. as per Paul's suggestion, along with
> other points he has mentioned)

Yes sure as long as we can see what needs to be set in the kernel.

The GPMC timings should only come from the bootloader in the device tree
case BTW, so that's also something to consider here.

Regards,

Tony