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. Regards Afzal -- 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
