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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux