[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

Jon Hunter jon-hunter at ti.com
Tue Jun 12 13:36:53 EDT 2012

On 06/12/2012 01:37 AM, Mohammed, Afzal wrote:
> Hi Jon,
> On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote:
>> What boards have been tested with this change?
> Beagle board, after applying all 5 series of patches, without all
> patch series it can't be tested for beagle board as it depended on
> bootloader, not this API
>>> +	u16 bus_turnaround;
>>> +	u16 cycle2cycle_delay;
>>> +
>>> +	u16 wait_monitoring;
>>> +	u16 clk_activation;
>>> +
>>>  	/* The following are only on OMAP3430 */
>>>  	u16 wr_access;		/* WRACCESSTIME */
>>>  	u16 wr_data_mux_bus;	/* WRDATAONADMUXBUS */
>> In general, I agree with this, but if we apply this today, it seems that
>> we *may* be clearing these fields if they have been configured by the
>> bootloader and hence this could introduce a regression (potentially).
>> So we ever need to test boards that this change impacts or at least
>> verify that this change would not impact these boards because these
>> fields have not been configured.
> Yes, it is the exactly the reason this patch has been splitted out
> of gpmc driver conversion series. To find out whether enhancing
> existing API cause any regression and if so, then it can be easily
> root caused and would not be confused with driver conversion.
> This was the only change required w.r.t old interface, need to make
> sure that this won't causes breakage on any of the boards (the boards
> which were unknowingly depending on bootloader for these settings).
> I have only beagle board & omap3evm (both would not get affected
> by this change with existing code) and others can't be validated.
> Once this is in lo tree or mainline, this change can be validated
> for different boards.

Should you at least warn, if you are going to over-write a value?


More information about the linux-arm-kernel mailing list