summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/gpmc.h
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP2+: Add function to read GPMC settings from device-treeJon Hunter2013-04-011-0/+2
| | | | | | | | | | | Adds a function to read the various GPMC chip-select settings from device-tree and store them in the gpmc_settings structure. Update the GPMC device-tree binding documentation to describe these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
* ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()Jon Hunter2013-04-011-4/+1
| | | | | | | | | | With the addition of the gpmc_cs_program_settings(), we no longer need or use gpmc_cs_configure() to configure some of the GPMC chip-select options. So rename the function to gpmc_configure() and remove code that modifies options in the CONFIG1 register. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
* ARM: OMAP2+: Add function for configuring GPMC settingsJon Hunter2013-04-011-0/+6
| | | | | | | | | | | | | | | | | | | The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no common function for configuring these options and various devices set these options by either programming the GPMC CONFIG1 register directly or by calling gpmc_cs_configure() to set some of the options. Add a new function for configuring all of the GPMC options. Having a common function for configuring this options will simplify code and ease the migration to device-tree. Also add a new capability flag to detect devices that support the address-address-data multiplexing mode. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
* ARM: OMAP2+: Add structure for storing GPMC settingsJon Hunter2013-04-011-7/+21
| | | | | | | | | | | | | | | The GPMC has various different configuration options such as bus-width, synchronous or asychronous mode selection, burst mode options etc. Currently, there is no central structure for storing all these options when configuring the GPMC for a given device. Some of the options are stored in the GPMC timing structure and some are directly programmed into the GPMC configuration register. Add a new structure to store these options and convert code to use this structure. Adding this structure will allow us to create a common function for configuring these options. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
* ARM: omap2: gpmc: Mark local scoped functions staticEzequiel Garcia2013-04-011-7/+0
| | | | | | | | | This patch marks a bunch of functions that are local to gpmc.c file only as static. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP: Clear GPMC bits when applying new setting.Mark Jackson2013-04-011-1/+4
| | | | | | | | | | | | | | | | | When setting the GPMC device type, make sure any previous bits are cleared down, before applying the new setting. For OMAP4+ devices MUXADDDATA is a 2-bit field (bits 9:8) where as for OMAP2/3 devices it was only a one bit field (bit 9). For OMAP2/3 devices bit 8 is reserved and the OMAP documentation says to write a 0 to this bit. So clearing bit 8 on OMAP2/3 devices should not be a problem. Hence update the code to handle both bits 8 and 9 for all devices. Signed-off-by: Mark Jackson <mpfj@newflow.co.uk> [jon-hunter@ti.com: updated changelog] Signed-off-by: Jon Hunter <jon-hunter@ti.com>
* ARM: OMAP2+: gpmc: generic timing calculationAfzal Mohammed2012-11-091-20/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Presently there are three peripherals that gets it timing by runtime calculation. Those peripherals can work with frequency scaling that affects gpmc clock. But timing calculation for them are in different ways. Here a generic runtime calculation method is proposed. Input to this function were selected so that they represent timing variables that are present in peripheral datasheets. Motive behind this was to achieve DT bindings for the inputs as is. Even though a few of the tusb6010 timings could not be made directly related to timings normally found on peripherals, expressions used were translated to those that could be justified. There are possibilities of improving the calculations, like calculating timing for read & write operations in a more similar way. Expressions derived here were tested for async onenand on omap3evm (as vanilla Kernel does not have omap3evm onenand support, local patch was used). Other peripherals, tusb6010, smc91x calculations were validated by simulating on omap3evm. Regarding "we_on" for onenand async, it was found that even for muxed address/data, it need not be greater than "adv_wr_off", but rather could be derived from write setup time for peripheral from start of access time, hence would more be in line with peripheral timings. With this method it was working fine. If it is required in some cases to have "we_on" same as "wr_data_mux_bus" (i.e. greater than "adv_wr_off"), another variable could be added to indicate it. But such a requirement is not expected though. It has been observed that "adv_rd_off" & "adv_wr_off" are currently calculated by adding an offset over "oe_on" and "we_on" respectively in the case of smc91x. But peripheral datasheet does not specify so and so "adv_rd(wr)_off" has been derived (to be specific, made ignorant of "oe_on" and "we_on") observing datasheet rather than adding an offset. Hence this generic routine is expected to work for smc91x (91C96 RX51 board). This was verified on smsc911x (9220 on OMAP3EVM) - a similar ethernet controller. Timings are calculated in ps to prevent rounding errors and converted to ns at final stage so that these values can be directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings() would be modified to take ps once all custom timing routines are replaced by the generic routine, at the same time generic timing routine would be modified to provide timings in ps. struct gpmc_timings field types are upgraded from u16 => u32 so that it can hold ps values. Whole of this exercise is being done to achieve driver and DT conversion. If timings could not be calculated in a peripheral agnostic way, either gpmc driver would have to be peripheral gnostic or a wrapper arrangement over gpmc driver would be required. Signed-off-by: Afzal Mohammed <afzal@ti.com>
* ARM: OMAP2+: gpmc: handle additional timingsAfzal Mohammed2012-11-091-0/+19
| | | | | | | | | | | | | | | 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. Also configure bool type timings like extradelay. This needed change to the existing users that were configuring clk activation time and extra delay by directly writing to registers. Thanks to Tony for making me aware of users of clk activation and being kind enough to test the modified one. Signed-off-by: Afzal Mohammed <afzal@ti.com>
* ARM: OMAP2+: gpmc: localize gpmc headerAfzal Mohammed2012-10-151-0/+135
Requirement of gpmc header outside of mach-omap2 has been cutoff, move gpmc header file in plat-omap folder to local mach-omap2 folder Objective - common zImage participation of omap Signed-off-by: Afzal Mohammed <afzal@ti.com>
OpenPOWER on IntegriCloud