[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
From: Jon Hunter <hidden>
Date: 2012-06-11 18:49:35
Also in:
linux-omap
Hi Afzal, On 06/11/2012 09:02 AM, Afzal Mohammed wrote:
Configure busturnaround, cycle2cycledelay, waitmonitoringtime, clkactivationtime in gpmc_cs_set_timings(). This is done so that boards can configure these parameters of gpmc in Kernel instead of relying on bootloader.
What boards have been tested with this change? Tony is going to want to know what we have tested with such changes to avoid any regressions.
quoted hunk ↗ jump to hunk
Signed-off-by: Afzal Mohammed <redacted> --- arch/arm/mach-omap2/gpmc.c | 6 ++++++ arch/arm/plat-omap/include/plat/gpmc.h | 6 ++++++ 2 files changed, 12 insertions(+)diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 578fd4c..517953f 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c@@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t) GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access); + GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround); + GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay); + + GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring); + GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation); + if (cpu_is_omap34xx()) { GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus); GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h index 2e6e259..802fb22 100644 --- a/arch/arm/plat-omap/include/plat/gpmc.h +++ b/arch/arm/plat-omap/include/plat/gpmc.h@@ -128,6 +128,12 @@ struct gpmc_timings { u16 rd_cycle; /* Total read cycle time */ u16 wr_cycle; /* Total write cycle time */ + 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. Cheers Jon