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

[Tony Lindgren <tony@atomide.com>]

* Paul Walmsley <paul@pwsan.com> [120521 23:51]:
> 
> Next, I'd suggest implementing the code to allow GPMC timing configuration 
> from raw register data (the second method above).  This is hackish but for 
> some boards, this is all we'll have.  This will also presumably require 
> some extra DT bindings for the register data.  If this method is used, 
> this code should also call a PM function to block clock rate changes on 
> the GPMC clock, and an explanatory warning should be logged to the 
> console.

Also something to note here is that generating dynamic timings from the
fixed GPMC register values won't work for other frequencies.

As far as I remember, the main problem trying to convert fixed value
GPMC timings into dynamic timings is the fact that some GPMC values
calculated depend on clock cycles, while other values depend on time.

So the cycle values remain unknown trying to upsample from fixed timings.
 
> For boards that we don't have access to, and all someone would have are 
> the register values set by the bootloader, I'd propose a phased approach:
> 
> 1. The kernel should log the bootloader-provided GPMC timing registers to 
> the console during boot, along with a warning message that indicates that 
> GPMC for these boards will cease to function in the near future unless 
> patches are provided to update the kernel board file and/or DT data with 
> the GPMC register contents.  This should allow people who have those 
> boards and who care about them to submit kernel patches to allow the 
> GPMC-attached devices to continue to function.

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.
 
> 2. A patch to Documentation/feature-removal-schedule.txt should be
> submitted which states that support for implicit bootloader GPMC timings
> will be removed within two or three kernel releases.

I'm fine with that assuming we somehow first have the values for the
most commonly used boards for smsc911x. But before that happens, we can't
really deprecate bootloader set GPMC values.

Regards,

Tony