Message ID | 1402477001-31132-16-git-send-email-rogerq@ti.com |
---|---|
State | Superseded |
Headers | show |
* Roger Quadros <rogerq@ti.com> [140611 01:59]: > GPMC_CLK is the external clock output pin that is used for syncronous > accesses. > > Device drivers need to know the fastest possible GPMC_CLK period in order > to calculate the most optimal device timings. Add the function > omap_gpmc_get_clk_period() to allow drivers to get the nearset possible > (equal to or greater than) GPMC_CLK period given the minimum > clock period supported by the attached device. > > This is especially needed by the onenand driver as it calculates > device timings on the fly for various onenand speed grades. Here too this should probably still be done by the gpmc to driver glue layer, not by the actual driver that shoud be Linux generic. Regards, Tony
On 06/13/2014 10:26 AM, Tony Lindgren wrote: > * Roger Quadros <rogerq@ti.com> [140611 01:59]: >> GPMC_CLK is the external clock output pin that is used for syncronous >> accesses. >> >> Device drivers need to know the fastest possible GPMC_CLK period in order >> to calculate the most optimal device timings. Add the function >> omap_gpmc_get_clk_period() to allow drivers to get the nearset possible >> (equal to or greater than) GPMC_CLK period given the minimum >> clock period supported by the attached device. >> >> This is especially needed by the onenand driver as it calculates >> device timings on the fly for various onenand speed grades. > > Here too this should probably still be done by the gpmc to driver > glue layer, not by the actual driver that shoud be Linux generic. Well, this is only needed by the omap-onenand driver to perform the timing calculations at run-time. Other option is to model the GPMC_CLK (external) as a clock and request the rate using the clock framework. But since this and the retime() is only used by 2 OMAP specific drivers, I'm not sure if it is worth the effort. cheers, -roger
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 90b7686..50ef1a9 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1578,6 +1578,44 @@ int omap_gpmc_retime(int cs, struct gpmc_settings *gpmc_s, } EXPORT_SYMBOL_GPL(omap_gpmc_retime); +/** + * omap_gpmc_get_clk_period - Get the nearest possible (equal to or higer) GPMC + * synchronous clock (GPMC_CLK) period. + * + * @cs Chip select number + * @min_ps Minimum synchronous clock period supporded by the device + * + * Returns the nearest possible GPMC clock period in picoseconds, equal to or + * higher than the requested period. 0 in case of error. + */ +unsigned long omap_gpmc_get_clk_period(int cs, + unsigned long min_ps) +{ + int div; + unsigned long clk_ps; + struct device *dev = gpmc_dev; + + if (!gpmc_dev) + return 0; + + if (cs < 0 || cs >= gpmc_cs_num) { + dev_err(dev, "%s: Invalid Chip Select\n", __func__); + return cs; + } + + div = gpmc_calc_divider(min_ps); + if (div < 0) { + dev_err(dev, "%s: Can't support requested clock period %lu ps\n", + __func__, min_ps); + return 0; + } + + clk_ps = gpmc_get_fclk_period() * div; + + return clk_ps; +} +EXPORT_SYMBOL_GPL(omap_gpmc_get_clk_period); + 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 0d40c2a..05e4b6f 100644 --- a/include/linux/platform_data/gpmc-omap.h +++ b/include/linux/platform_data/gpmc-omap.h @@ -169,6 +169,8 @@ struct gpmc_omap_platform_data { #ifdef CONFIG_ARCH_OMAP2PLUS int omap_gpmc_retime(int cs, struct gpmc_settings *gpmc_s, struct gpmc_device_timings *dev_t); +unsigned long omap_gpmc_get_clk_period(int cs, + unsigned long min_ps); #else static inline int omap_gpmc_retime(int cs, struct gpmc_settings *gpmc_s, @@ -176,6 +178,12 @@ static inline int omap_gpmc_retime(int cs, { return 0; } + +static inline unsigned long omap_gpmc_get_clk_period(int cs, + unsigned long min_ps) +{ + return 0; +} #endif /* CONFIG_ARCH_OMAP2PLUS */ #endif /* _GPMC_OMAP_H */
GPMC_CLK is the external clock output pin that is used for syncronous accesses. Device drivers need to know the fastest possible GPMC_CLK period in order to calculate the most optimal device timings. Add the function omap_gpmc_get_clk_period() to allow drivers to get the nearset possible (equal to or greater than) GPMC_CLK period given the minimum clock period supported by the attached device. This is especially needed by the onenand driver as it calculates device timings on the fly for various onenand speed grades. Signed-off-by: Roger Quadros <rogerq@ti.com> --- arch/arm/mach-omap2/gpmc.c | 38 +++++++++++++++++++++++++++++++++ include/linux/platform_data/gpmc-omap.h | 8 +++++++ 2 files changed, 46 insertions(+)