On 07/03/2012 03:17 AM, Tony Lindgren wrote: > * 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.. Yes, I was hoping we could avoid continuing to do this. >> 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. Seems fine to me. Cheers Jon -- 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
