| Message ID | 1402477001-31132-15-git-send-email-rogerq@ti.com |
|---|---|
| State | New |
| Headers | show |
* Roger Quadros <rogerq@ti.com> [140611 01:58]: > Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC > timings in order to operate with different peripheral clock frequencies. > Introduce omap_gpmc_retime() to allow them to do that. The driver > needs to pass the chips select number, GPMC settings and Device timings to > omap_gpmc_retime(). > > NOTE: Device tree and board code must still pass the most conservative > timings to GPMC so that the device can be probed by the respective driver. > e.g. Onenand must operate in asynchronous mode at bootup. The device driver > can then request for more optimal timings via omap_gpmc_retime(). Hmm but many of the devices are Linux generic like sms91x and 8250 so it's not nice to start stuffing omap bus specific data there. I wonder if we should just keep device specific gpmc-smc91x.c etc in drivers/memory? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 06/13/2014 10:25 AM, Tony Lindgren wrote: > * Roger Quadros <rogerq@ti.com> [140611 01:58]: >> Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC >> timings in order to operate with different peripheral clock frequencies. >> Introduce omap_gpmc_retime() to allow them to do that. The driver >> needs to pass the chips select number, GPMC settings and Device timings to >> omap_gpmc_retime(). >> >> NOTE: Device tree and board code must still pass the most conservative >> timings to GPMC so that the device can be probed by the respective driver. >> e.g. Onenand must operate in asynchronous mode at bootup. The device driver >> can then request for more optimal timings via omap_gpmc_retime(). > > Hmm but many of the devices are Linux generic like sms91x and 8250 so it's > not nice to start stuffing omap bus specific data there. Those drivers should never need to use this function. Hopefully they will work with a one time setup where we specify the timings in the DT. This function is primarily for use by omap-onenand and tusb6010, which are both OMAP specific. cheers, -roger > > I wonder if we should just keep device specific gpmc-smc91x.c etc > in drivers/memory? > > Regards, > > Tony > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
* Roger Quadros <rogerq@ti.com> [140613 00:46]: > On 06/13/2014 10:25 AM, Tony Lindgren wrote: > > * Roger Quadros <rogerq@ti.com> [140611 01:58]: > >> Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC > >> timings in order to operate with different peripheral clock frequencies. > >> Introduce omap_gpmc_retime() to allow them to do that. The driver > >> needs to pass the chips select number, GPMC settings and Device timings to > >> omap_gpmc_retime(). > >> > >> NOTE: Device tree and board code must still pass the most conservative > >> timings to GPMC so that the device can be probed by the respective driver. > >> e.g. Onenand must operate in asynchronous mode at bootup. The device driver > >> can then request for more optimal timings via omap_gpmc_retime(). > > > > Hmm but many of the devices are Linux generic like sms91x and 8250 so it's > > not nice to start stuffing omap bus specific data there. > > Those drivers should never need to use this function. Hopefully they will work with a one time setup where we specify the timings in the DT. This function is primarily for use by omap-onenand and tusb6010, which are both OMAP specific. Well those were the only ones so far that had to tolerate with L3 speed changes at some point, so others may need it potentially too. And we could get rid of the omap specific onenand driver at some point.. But yeah, I'm fine keeping those recalc functions in the device drivers if it makes things simpler. Just something to consider in any case. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 70cb6b0..90b7686 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1542,6 +1542,42 @@ static int __init omap_gpmc_init(void) } omap_postcore_initcall(omap_gpmc_init); +/** + * omap_gpmc_retime - Reconfigre GPMC timings for the device + * + * @cs Chip select number + * @gpmc_s GPMC settings + * @dev_t New device timings to set + */ +int omap_gpmc_retime(int cs, struct gpmc_settings *gpmc_s, + struct gpmc_device_timings *dev_t) +{ + struct gpmc_timings gpmc_t; + struct device *dev = gpmc_dev; + + if (!gpmc_dev) + return -ENODEV; + + if (cs < 0 || cs >= gpmc_cs_num) { + dev_err(dev, "%s: Invalid find Chip Select\n", __func__); + return cs; + } + + if (gpmc_cs_program_settings(cs, gpmc_s)) { + dev_err(dev, "%s: Failed to set GPMC settings\n", __func__); + return -EINVAL; + } + + gpmc_calc_timings(&gpmc_t, gpmc_s, dev_t); + if (gpmc_cs_set_timings(cs, &gpmc_t)) { + dev_err(dev, "%s: Failed to set GPMC timings\n", __func__); + return -EINVAL; + } + + return 0; +} +EXPORT_SYMBOL_GPL(omap_gpmc_retime); + static struct omap3_gpmc_regs gpmc_context; void omap3_gpmc_save_context(void) diff --git a/include/linux/platform_data/gpmc-omap.h b/include/linux/platform_data/gpmc-omap.h index e861112..0d40c2a 100644 --- a/include/linux/platform_data/gpmc-omap.h +++ b/include/linux/platform_data/gpmc-omap.h @@ -166,4 +166,16 @@ struct gpmc_omap_platform_data { struct gpmc_omap_cs_data cs[GPMC_CS_NUM]; }; +#ifdef CONFIG_ARCH_OMAP2PLUS +int omap_gpmc_retime(int cs, struct gpmc_settings *gpmc_s, + struct gpmc_device_timings *dev_t); +#else +static inline int omap_gpmc_retime(int cs, + struct gpmc_settings *gpmc_s, + struct gpmc_device_timings *dev_t) +{ + return 0; +} +#endif /* CONFIG_ARCH_OMAP2PLUS */ + #endif /* _GPMC_OMAP_H */
Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC timings in order to operate with different peripheral clock frequencies. Introduce omap_gpmc_retime() to allow them to do that. The driver needs to pass the chips select number, GPMC settings and Device timings to omap_gpmc_retime(). NOTE: Device tree and board code must still pass the most conservative timings to GPMC so that the device can be probed by the respective driver. e.g. Onenand must operate in asynchronous mode at bootup. The device driver can then request for more optimal timings via omap_gpmc_retime(). Signed-off-by: Roger Quadros <rogerq@ti.com> --- arch/arm/mach-omap2/gpmc.c | 36 +++++++++++++++++++++++++++++++++ include/linux/platform_data/gpmc-omap.h | 12 +++++++++++ 2 files changed, 48 insertions(+)