[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

Hi Paul,

On 06/14/2012 07:20 PM, Paul Walmsley wrote:

On Thu, 14 Jun 2012, Jon Hunter wrote:

quoted

What does make this a bit more difficult is the function
gpmc_round_ns_to_ticks(). It appears to convert nanoseconds to ticks and
back to nanoseconds. I am guessing to account for some rounding error. I
am curious what impact this function is having on the timing. Ideally
this should be handle in gpmc_cs_set_timings().

I don't have the code in front of me at the moment, nor my old GPMC timing 
spreadsheet, so this comment may be superfluous.  But since kernel 
arithmetic needs to be in integers, it might be necessary to do some of 
the timing calculations in picosecond units to avoid roundoff issues.

A lot of the GPMC timing functions are converting to pico-seconds and
then rounding up to nano-seconds. So I think that the calculations are ok.

The real problem is, that as Afzal has highlighted, is that there is no
common method between GPMC peripherals (onenand, smsc, etc) for
populating the gpmc timings structure. This is going to cause a bit of a
headache for migrating them over to DT. So what we need to do and maybe
this is another series, separate from Afzal's series, is really clean-up
the populating of the timings.

Cheers
Jon