On 07/03/2012 03:17 AM, Tony Lindgren wrote:

* Jon Hunter [off-list ref] [120702 10:30]:

quoted

On 07/02/2012 01:36 AM, Tony Lindgren wrote:

quoted

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.

quoted

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