- 15 Nov, 2012 5 commits
-
-
Arnd Bergmann authored
Merge tag 'omap-for-v3.8/timer-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers From Tony Lindgren <tony@atomide.com>: Timer fixes for omaps via Jon Hunter <jon-hunter@ti.com>: Several fixes for the OMAP DMTIMER driver including ... 1. Adding workaround for OMAP3+ errata i103/i767 2. Fixing posted mode support 3. Spurious interrupts when using match interrupt 4. HWMOD fixes for timers 5. Unnecessary restoration of read-only registers 6. Adds function for disabling timer interrupts 7. Fixing timer1 reset for OMAP1 * tag 'omap-for-v3.8/timer-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP: Remove __omap_dm_timer_set_source function ARM: OMAP: Remove unnecessary call to clk_get() ARM: OMAP: Add dmtimer interrupt disable function ARM: OMAP: Fix spurious interrupts when using timer match feature ARM: OMAP: Don't restore DMTIMER interrupt status register ARM: OMAP: Don't restore of DMTIMER TISTAT register ARM: OMAP: Fix dmtimer reset for timer1 ARM: OMAP2+: Don't use __omap_dm_timer_reset() ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations ARM: OMAP: Fix timer posted mode support ARM: OMAP3+: Implement timer workaround for errata i103 and i767 ARM: OMAP: Add DMTIMER definitions for posted mode Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Needed for the omap timer changes. Signed-off-by: -
Arnd Bergmann authored
Merge tag 'omap-for-v3.8/gpmc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers From Tony Lindgren <tony@atomide.com>: omap GPMC (General Purpose Memory Controller) updates via Afzal Mohammed <afzal@ti.com>: These changes provide a generic gpmc timing calculation method, migrates existing peripherals that makes use of custom gpmc timing calculation method to use the new generic one. The generic timing routine has been tested with onenand, smsc911x, and tusb6010 devices connected to GPMC in addition to simulating other devices support in the mainline kernel. * tag 'omap-for-v3.8/gpmc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: tusb6010: generic timing calculation ARM: OMAP2+: smc91x: generic timing calculation ARM: OMAP2+: onenand: generic timing calculation ARM: OMAP2+: gpmc: generic timing calculation ARM: OMAP2+: gpmc: handle additional timings ARM: OMAP2+: nand: remove redundant rounding Signed-off-by:
-
Arnd Bergmann authored
This avoids merge conflicts between the omap header changes and the gpmc updates. Signed-off-by: -
Linus Walleij authored
Recent pin changes produce this warning: arch/arm/mach-ux500/board-mop500-pins.c:73:22: error: 'out_hi_wkup_pdis' defined but not used [-Werror=unused-variable] Fix this by deleting the offending definition. Reported-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 13 Nov, 2012 1 commit
-
-
Tony Lindgren authored
-
- 12 Nov, 2012 15 commits
-
-
Tony Lindgren authored
Merge tag 'gpmc-generic-timing' of git://gitorious.org/x0148406-public/linux-kernel into omap-for-v3.8/gpmc These changes provide a generic gpmc timing calculation method, migrates existing peripherals that makes use of custom gpmc timing calculation method to use the new generic one. Generic routine has been verified for onenand async timing calculation on omap3evm (with a local change to add onenand support). Generic timing calculation method were verified for other peripherals by simulation. Generic method has to be verified on peripherals supported in mainline.
-
Jon Hunter authored
The __omap_dm_timer_set_source() function is only used by the system timer (clock-events and clock-source) code for OMAP2+ devices. Therefore, we can remove this code from the dmtimer driver and move it to the system timer code for OMAP2+ devices. The current __omap_dm_timer_set_source() function calls clk_disable() before calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to clk_set_parent() in omap_dm_timer_init_one(). The function omap_hwmod_setup_one() will enable the timers functional clock and therefore increment the use-count of the functional clock to 1. clk_set_parent() will fail if the use-count is not 0 when called. Hence, if omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call clk_disable() before calling clk_set_parent() to decrement the use-count. Hence, avoid these extra calls to disable and enable the functional clock by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after clk_set_parent(). We can also remove the delay from the __omap_dm_timer_set_source() function because enabling the clock will now be handled via the HWMOD framework by calling omap_hwmod_setup_one(). Therefore, by moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with clk_set_parent(). It should be safe to move these hwmod calls to later in the omap_dm_timer_init_one() because other calls to the hwmod layer that occur before are just requesting resource information. Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze with the following configurations: 1. CONFIG_OMAP_32K_TIMER=y 2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer" 3. CONFIG_OMAP_32K_TIMER not set 4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer" Signed-off-by:
Jon Hunter <jon-hunter@ti.com> Acked-by:
Santosh Shilimkar <santosh.shilimkar@ti.com>
-
Jon Hunter authored
Whenever we call the function omap_dm_timer_set_source() to set the clock source of a dmtimer we look-up the dmtimer functional clock source by calling clk_get(). This is not necessary because on requesting a dmtimer we look-up the functional clock source and store it in the omap_dm_timer structure. So instead of looking up the clock again used the clock handle that stored in the omap_dm_timer structure. Signed-off-by:
-
Jon Hunter authored
The OMAP dmtimer driver does not currently have a function to disable the timer interrupts. For some timer instances the timer interrupt enable function can be used to disable the interrupts because the same interrupt enable register is used to disable interrupts. However, some timer instances have separate interrupt enable/disable registers and so this will not work. Therefore, add a dedicated function to disable interrupts. This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1, 2 and 10 need this function and for OMAP5 all timers need this function. Please note that the interrupt disable function has been written so that it can be used by all OMAP devices. Signed-off-by:
-
Jon Hunter authored
The OMAP DMTIMERs can generate an interrupt when the timer counter value matches the value stored in the timer's match register. When using this feature spurious interrupts were seen, because the compare logic is being enabled before the match value is loaded and according to the documentation the match value must be loaded before the compare logic is enable. The reset value for the timer counter and match registers is 0 and hence, by enabling the compare logic before the actual match value is loaded a spurious interrupt can be generated as the reset values match. Signed-off-by:
-
Jon Hunter authored
Restoring the timer interrupt status is not possible because writing a 1 to any bit in the register clears that bit if set and writing a 0 has no affect. Furthermore, if an interrupt is pending when someone attempts to disable a timer, the timer will fail to transition to the idle state and hence it's context will not be lost. Users should take care to service all interrupts before disabling the timer. Signed-off-by:
-
Jon Hunter authored
The timer TISTAT register is a read-only register and therefore restoring the context is not needed. Furthermore, the context of TISTAT is never saved anywhere in the current code. The TISTAT register is read-only for all OMAP devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register. Signed-off-by:
-
Jon Hunter authored
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1) a fix was added to prevent timer1 being reset in the function omap_dm_timer_reset() because timer1 was being used as the system timer for OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system timer, the function omap_dm_timer_reset() is now only being called for OMAP1 devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices. Signed-off-by:
-
Jon Hunter authored
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to configure the clock-activity, idle, wakeup-enable and auto-idle fields in the timer OCP_CFG register. The name of the function is mis-leading because this function does not actually perform a reset of the timer. For OMAP2+ devices, HWMOD is responsible for reseting and configuring the timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not have the fields clock-activity, wakeup-enable and auto-idle and so this function could configure the OCP_CFG register incorrectly. Currently HWMOD is not configuring the clock-activity field in the OCP_CFG register for timers that have this field. Commit 0f0d0807 (ARM: OMAP: DMTimer: Use posted mode) configures the clock-activity field to keep the f-clk enabled so that the wake-up capability is enabled. Therefore, add the appropriate flags to the timer HWMOD structures to configure this field in the same way. For OMAP2/3 devices all dmtimers have the clock-activity field, where as for OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field. Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is configuring the dmtimer OCP_CFG register as expected for clock-events timer. Signed-off-by:
-
Jon Hunter authored
For OMAP2/3 devices, the HWMOD data does not define a software reset status field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices, the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER TISTAT register (referred to as the SYSS register in HWMOD). Add the appropriate HWMOD definitions so that HWMOD will check the software reset status when performing a software reset of the DMTIMER. Signed-off-by:
-
Jon Hunter authored
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures (referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10 use one of the defintions and the other timers use the other definition. For OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for all 12 instances of the DMTIMER. Please note that this is a difference between OMAP3 and OMAP4 and could be the source of the confusion. For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields, clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all 12 timers. Therefore, remove one of the SYSC register definitions for the DMTIMERs and ensure the appropriate register fields are defined for all DMTIMERs. Signed-off-by:
-
Jon Hunter authored
Currently the dmtimer posted mode is being enabled when the function omap_dm_timer_enable_posted() is called. This function is only being called for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence, for OMAP2+ timers that are NOT being used as a system timer, posted mode is not enabled but the "timer->posted" variable is still set (incorrectly) in the omap_dm_timer_prepare() function. This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer: switch-over to platform device driver) which was before the omap_dm_timer_enable_posted() function was introduced. Although this is a regression from the original code it only impacts performance and so is not needed for stable. Signed-off-by:
-
Jon Hunter authored
Errata Titles: i103: Delay needed to read some GP timer, WD timer and sync timer registers after wakeup (OMAP3/4) i767: Delay needed to read some GP timer registers after wakeup (OMAP5) Description (i103/i767): If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1), due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2 registers right after the timer interface clock (L4) goes from stopped to active may not return the expected values. The most common event leading to this situation occurs upon wake up from idle. GPTimer non-posted synchronization mode is not impacted by this limitation. Workarounds: 1). Disable posted mode 2). Use static dependency between timer clock domain and MPUSS clock domain 3). Use no-idle mode when the timer is active Workarounds #2 and #3 are not pratical from a power standpoint and so workaround #1 has been implemented. Disabling posted mode adds some CPU overhead for configuring and reading the timers as the CPU has to wait for accesses to be re-synchronised within the timer. However, disabling posted mode guarantees correct operation. Please note that it is safe to use posted mode for timers if the counter (TCRR) and capture (TCARx) registers will never be read. An example of this is the clock-event system timer. This is used by the kernel to schedule events however, the timers counter is never read and capture registers are not used. Given that the kernel configures this timer often yet never reads the counter register it is safe to enable posted mode in this case. Hence, for the timer used for kernel clock-events, posted mode is enabled by overriding the errata for devices that are impacted by this defect. For drivers using the timers that do not read the counter or capture registers and wish to use posted mode, can override the errata and enable posted mode by making the following function calls. __omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767); __omap_dm_timer_enable_posted(timer); Both dmtimers and watchdogs are impacted by this defect this patch only implements the workaround for the dmtimer. Currently the watchdog driver does not read the counter register and so no workaround is necessary. Posted mode will be disabled for all OMAP2+ devices (including AM33xx) using a GP timer as a clock-source timer to guarantee correct operation. This is not necessary for OMAP24xx devices but the default clock-source timer for OMAP24xx devices is the 32k-sync timer and not the GP timer and so should not have any impact. This should be re-visited for future devices if this errata is fixed. Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices. Signed-off-by: -
Jon Hunter authored
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and clock-source) the posted mode configuration of the timers is used. To allow the compiler to optimise the functions for configuring and reading the system timers, the posted flag variable is hard-coded with the value 1. To make it clear that posted mode is being used add some definitions so that it is more readable. Signed-off-by:
-
Arnd Bergmann authored
Merge tag 'ux500-pins-for-arm-soc' of http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into next/drivers From Linus Walleij <linus.walleij@linaro.org>: Ux500 pinctrl table update for v3.8, basically accumulated updates to pin muxing and biasing from internal deployment and regression testing for power performance. * tag 'ux500-pins-for-arm-soc' of http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson: ARM: ux500: fixup magnetometer pins ARM: ux500: add STM pin configuration ARM: ux500: 8500: add pinctrl support for uart1 and uart2 ARM: ux500: cosmetic fixups for uart0 ARM: ux500: 8500: define SDI sleep states ARM: ux500: 8500: update SKE keypad pinctrl table ARM: ux500: delete duplicate macro ARM: ux500: 8500: add IDLE pin configuration for SPI ARM: ux500: 8500: register LCD VSI pinctrl table Signed-off-by:
-
- 09 Nov, 2012 9 commits
-
-
Tony Lindgren authored
-
Tony Lindgren authored
-
Tony Lindgren authored
Conflicts: arch/arm/plat-omap/dmtimer.c Resolved as suggested by Jon Hunter.
-
Tony Lindgren authored
Merge branch 'for_3.8/dts_part2' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.8/dt
-
Afzal Mohammed authored
Generic gpmc timing calculation helper is available now, use it instead of custom timing calculation. Signed-off-by:Afzal Mohammed <afzal@ti.com>
-
Afzal Mohammed authored
Generic gpmc timing calculation helper is available now, use it instead of custom timing calculation. Signed-off-by: -
Afzal Mohammed authored
Generic gpmc timing calculation helper is available now, use it instead of custom timing calculation. Signed-off-by: -
Afzal Mohammed authored
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 authored
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:
-
- 08 Nov, 2012 1 commit
-
-
Afzal Mohammed authored
gpmc_cs_set_timings() calculate ticks to be programmed by rounding time in ns to next tick value. Hence remove redundant rounding of nanosecond timing. Signed-off-by:
-
- 07 Nov, 2012 6 commits
-
-
Afzal Mohammed authored
OMAP2+ family of devices are now obtaining resources via DT, earlier it was obtained from hwmod. Update binding document accrodingly, while at it add example. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Benoit Cousson <b-cousson@ti.com>
-
Ricardo Neri authored
Add the pinmux configuration for HDMI and TPD12S015A. Configure the gpios for the TPD12S015A and SDA, SCL and CEC for HDMI. Signed-off-by:
Ricardo Neri <ricardo.neri@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Ricardo Neri authored
Add the pinmux configuration for HDMI and TPD12S015A. Configure the gpios for the TPD12S015A and SDA, SCL and CEC for HDMI. Signed-off-by:
-
Tony Lindgren authored
-
Tony Lindgren authored
Merge branch 'for_3.8/dts' of git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt into omap-for-v3.8/dt
-
Tomi Valkeinen authored
The only thing omap_init_consistent_dma_size() does is increase the consistent DMA size if CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is defined. Increasing the consistent DMA size should no longer be needed with CMA in place. This patch removes omap_init_consistent_dma_size() and also arch/arm/mach-omap2/io.c:omap_common_init_early() which becomes an empty function. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 06 Nov, 2012 3 commits
-
-
Benoit Cousson authored
The EVMSK was not built with the 'make dtbs' command. Add the missing entry in the dts Makefile. Signed-off-by: -
Ajay Kumar Gupta authored
Device tree node for usbss on AM33XX. There are two musb controllers on am33xx platform so have port0-mode and port1-mode data. Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
Santhapuri, Damodar <damodar.santhapuri@ti.com> Signed-off-by:
Ravi Babu <ravibabu@ti.com> [afzal@ti.com: reg & interrupt property addition] Signed-off-by:
-
AnilKumar Ch authored
Add gpio based push buttons device tree data to am335x-evmsk device by adding all the necessary parameters like key-code, gpios and etc. Signed-off-by:
AnilKumar Ch <anilkumar@ti.com> Signed-off-by:
-
