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

[Jon Hunter <jon-hunter@ti.com>]

Hi Paul,

On 06/14/2012 07:20 PM, Paul Walmsley wrote:
> On Thu, 14 Jun 2012, Jon Hunter wrote:
> 
>> 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