* Jon Hunter <jon-hunter@xxxxxx> [120702 10:30]: > > On 07/02/2012 01:36 AM, Tony Lindgren wrote: > > > > In general, I doubt that we can come up with better calculations. The existing > > code pretty well already follows the device spec timings. And using cycle values > > for some registers is the right thing to do according to the connected device > > specs no matter what the frequency is. In those cases converting from time values > > to cycles does not make sense. > > Ok agree, but the problem here is how to provide the timings to the > driver. The onenand code is doing a lot of rounding based upon the gpmc > clock before it presents the timings (in nano-seconds) to the gpmc > function to calculate the final timings and program the gpmc > chip-select. So therefore I think that we have the following options ... > > 1. The simplest is to continue using a global variable for storing the > gpmc f-clk handle and have the OneNAND timings calculated prior to > probing the gpmc driver. Well we should not expose gpmc fck handle to the drivers.. > 2. Provide some sort of "retime" callback that the gpmc driver can call > at probe time to calculate the timings. Yes how about the gpmc using driver code registers itself with the gpmc code and also registers it's retime function with the gpmc? That way the gpmc fck stays inside the gpmc code, and the driver specific retime function should be able to do the calculation based on driver clocks. The retime function needs to have also a pointer to driver private data for it's clocks etc. It seems this retime function may need to be called by the gpmc code when L3 changes, and the driver code if the driver is switching between runtime and idle clocks like tusb6010 for example does. Regards, Tony -- 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
