gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)

Mohammed, Afzal afzal at ti.com
Tue Aug 21 07:14:07 EDT 2012


Hi Jon,

On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote:

> > And we have been able to create such a function. Below is an implementation
> > that has been made for handling asynchronous timings. It has been tested for
> > OneNAND & SMSC on OMAP3EVM (rev G & C) with [1-4]. OneNAND was tested using
> > [5] (OMAP3EVM OneNAND works in async mode) & SMSC using [6] (mainline does
> > not have a timing calculation for smsc911x)
> 
> Are you able to verify that the timing calculated by this function are
> identical? May be some more details on exactly how you tested this would
> be good.

Yes, it was verified.

A new driver preparation series has been posted,
	http://marc.info/?l=linux-omap&m=134554573104116&w=2
that includes generic timing calculation method.

The new series mentions how timing values were validated. There are a
couple of timing parameters that would vary as mentioned in the above
mentioned mail, but these I don't expect to create problems as this is 
more inline with gpmc peripheral timings. And both of the these has
been verified that it would not create problem with peripheral
functionality. One was tested directly (we_on related for OneNAND) and
other indirectly (adv_rd(wr)_off on SMSC 9220 for SMSC 91C96).

Reason for doing so was that quirks required to handle these specific
cases could be avoided, otherwise new peripheral timing data would be
required and it would be difficult to achieve DT bindings (when DT
happens) for these kind of fixup timings.

But if this causes any problems (which I don't expect), then we will
have to fallback to the quirks that I wanted to avoid.

> Do you think that there is any value in making the tusb member a "u32
> dev_type" and then set it too GPMC_DEVICE_TUSB then this could be used
> for other devices in the future too if needed?

> Would it be possible to create a sub-function called
> gpmc_calc_timings_tusb() and put all these "if (tusb)" statements in
> there? Or maybe a generic function called gpmc_calc_timings_prepare().

Usage of a "tusb" check was something that I really wanted to avoid as
that was making generic timing calculation function peripheral Gnostic.
With the newly posted series, "tusb" field has been removed.

Regards
Afzal



More information about the linux-arm-kernel mailing list