On Tue, 22 May 2012, Tony Lindgren wrote: > * Paul Walmsley <p...@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.
Yep indeed. That's why clock rate changes have to be blocked on the GPMC clock. If we don't have GPMC clock rate-independent timing data, then I think we'll have to keep the GPMC clock rate fixed. > > 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. 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 ;-) - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
