On 06/12/2012 01:37 AM, Mohammed, Afzal wrote:

Hi Jon,

On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote:
 

quoted

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

quoted

quoted

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

Jon