- 26 1月, 2013 1 次提交
-
-
由 Thierry Reding 提交于
Convert all uses of devm_request_and_ioremap() to the newly introduced devm_ioremap_resource() which provides more consistent error handling. Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 1月, 2013 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 1月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
Commit bb772094 ("ARM: OMAP: Move omap2+ specific parts of sram.c to mach-omap2") adds some new sparse warnings: arch/arm/plat-omap/sram.c:43:6: warning: symbol 'omap_sram_push_address' was not declared. Should it be static? arch/arm/plat-omap/sram.c:65:6: warning: symbol 'omap_sram_reset' was not declared. Should it be static? arch/arm/plat-omap/sram.c:73:13: warning: symbol 'omap_map_sram' was not declared. Should it be static? This second version fixes the warnings by including <plat/sram.h>, at Tony's request. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 28 12月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Commit 1fe97c8f ("ARM: OMAP: Make OMAP clocksource source selection using kernel param") results in a new warning from sparse: arch/arm/plat-omap/counter_32k.c:86:12: warning: symbol 'omap_init_clocksource_32k' was not declared. Should it be static? This second version fixes this warning by including <plat/counter-32k.h>, at Tony's request. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 18 12月, 2012 3 次提交
-
-
由 Srinivas Kandagatla 提交于
This patch removes some code duplication by using module_platform_driver. Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
The cpu_is_omap macros are now local to arch/arm/mach-omap2 in soc.h and plat/cpu.h can finally be dropped for omap2+. Thanks everybody for help with fixing the drivers. Note that we can now also remove the unused plat/cpu.h from smartreflex.c and isp.c as they will cause compile errors with ARCH_MULTIPLATFORM enabled. Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: NJean Pihet <jean.pihet@newoldbits.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Looks like we missed plat-omap/fb.c for cpu_is_omap usage mach-omap2. This is the last user of cpu_is_omap, so let's quickly fix it up so we can finally remove plat/cpu.h for omap2lus. We want to limit cpu_is_omap macro usage to mach-omap2 only so we can make plat/cpu.h private. After this we can finally drop plat/cpu.h for omap2+. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 12月, 2012 2 次提交
-
-
由 Tony Lindgren 提交于
We need to move this file to allow ARM multiplatform configurations to build for omap2+. This can now be done as this file now only contains platform_data. cc: Russell King <linux@arm.linux.org.uk> cc: Alan Cox <alan@linux.intel.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Govindraj.R <govindraj.raja@ti.com> cc: Kevin Hilman <khilman@ti.com> cc: linux-serial@vger.kernel.org Reviewed-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Jon Hunter 提交于
The OMAP2420 H4 board was the only board using the plat-omap/debug-devices.c code for configuring ethernet support. Now that OMAP2420 H4 has been migrated to use the generic gpmc code for configuring ethernet support, the debug-devices.c file is no longer used and so remove it and its header file. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 07 12月, 2012 1 次提交
-
-
由 Hebbar, Gururaja 提交于
HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation): The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller > 25MHz Signed-off-by: NHebbar, Gururaja <gururaja.hebbar@ti.com> Signed-off-by: NVenkatraman S <svenkatr@ti.com> Signed-off-by: NChris Ball <cjb@laptop.org>
-
- 01 12月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Based on earlier discussions[1] we attempted to find a suitable location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion to dmaengine is complete. Unfortunately that was before I was able to try to test compile of the ARM multiplatform builds for omap2+, and the end result was not very good. So I'm creating yet another all over the place patch to cut the last dependency for building omap2+ for ARM multiplatform. After this, we have finally removed the driver dependencies to the arch/arm code, except for few drivers that are being worked on. The other option was to make the <plat-omap/dma-omap.h> path to work, but we'd have to add some new header directory to for multiplatform builds. Or we would have to manually include arch/arm/plat-omap/include again from arch/arm/Makefile for omap2+. Neither of these alternatives sound appealing as they will likely lead addition of various other headers exposed to the drivers, which we want to avoid for the multiplatform kernels. Since we already have a minimal include/linux/omap-dma.h, let's just use that instead and add a note to it to not use the custom omap DMA functions any longer where possible. Note that converting omap DMA to dmaengine depends on dmaengine supporting automatically incrementing the FIFO address at the device end, and converting all the remaining legacy drivers. So it's going to be few more merge windows. [1] https://patchwork.kernel.org/patch/1519591/# cc: Russell King <linux@arm.linux.org.uk> cc: Kevin Hilman <khilman@ti.com> cc: "Benoît Cousson" <b-cousson@ti.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: "David S. Miller" <davem@davemloft.net> cc: Vinod Koul <vinod.koul@intel.com> cc: Dan Williams <djbw@fb.com> cc: Mauro Carvalho Chehab <mchehab@infradead.org> cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> cc: David Woodhouse <dwmw2@infradead.org> cc: Kyungmin Park <kyungmin.park@samsung.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Tomi Valkeinen <tomi.valkeinen@ti.com> cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> cc: Hans Verkuil <hans.verkuil@cisco.com> cc: Vaibhav Hiremath <hvaibhav@ti.com> cc: Lokesh Vutla <lokeshvutla@ti.com> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> cc: Afzal Mohammed <afzal@ti.com> cc: linux-crypto@vger.kernel.org cc: linux-media@vger.kernel.org cc: linux-mtd@lists.infradead.org cc: linux-usb@vger.kernel.org cc: linux-fbdev@vger.kernel.org Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 22 11月, 2012 1 次提交
-
-
由 Igor Grinberg 提交于
CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way. Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER setting. To remove the dependancy, several conversions/additions had to be done: 1) Timer initialization functions are named by the platform name and the clock source in use. This also makes it possible to define and use the GPTIMER as the clock source instead of the 32K timer on platforms that do not have the 32K timer ip block or the 32K timer is not wired on the board. Currently, the the timer is chosen in the machine_desc structure on per board basis. Later, DT should be used to choose the timer. 2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults and those under !CONFIG_OMAP_32K_TIMER are removed. This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code. 3) Since we have all the timers defined inside machine_desc structure and we no longer need the fallback to gp_timer clock source in case 32k_timer clock source is unavailable (namely on AM33xx), we no longer need the #ifdef around omap2_sync32k_clocksource_init() function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the omap2_sync32k_clocksource_init() function. Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NJon Hunter <jon-hunter@ti.com>
-
- 21 11月, 2012 5 次提交
-
-
由 Tony Lindgren 提交于
Move iommu/iovmm headers from plat/ to platform_data/ as part of the single zImage work. Partially based on an earlier version by Ido Yariv <ido@wizery.com>. Cc: Ido Yariv <ido@wizery.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NJoerg Roedel <joro@8bytes.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
This file should not be in arch/arm. Move it to drivers/iommu to allow making most of the header local to drivers/iommu. This is needed as we are removing plat and mach includes from drivers for ARM common zImage support. Cc: Ido Yariv <ido@wizery.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: linux-media@vger.kernel.org Acked-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NJoerg Roedel <joro@8bytes.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
Looks like the iommu framework does not have generic functions exported for all the needs yet. The hardware specific functions are defined in files like intel-iommu.h and amd-iommu.h. Follow the same standard for omap-iommu.h. This is needed because we are removing plat and mach includes for ARM common zImage support. Further work should continue in the iommu framework context as only pure platform data will be communicated from arch/arm/*omap*/* code to the iommu framework. Cc: Ido Yariv <ido@wizery.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: linux-media@vger.kernel.org Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NJoerg Roedel <joro@8bytes.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ido Yariv 提交于
The iopgtable header file is only used by the iommu & iovmm drivers, so move it to drivers/iommu/, as part of the single zImage effort. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: NIdo Yariv <ido@wizery.com> Acked-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NJoerg Roedel <joro@8bytes.org> [tony@atomide.com: updated to be earlier in the series] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Ido Yariv 提交于
Since iommu is not supported on OMAP1 and will not likely to ever be supported, merge plat/iommu2.h into iommu.h so only one file would have to move to platform_data/ as part of the single zImage effort. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: NIdo Yariv <ido@wizery.com> Acked-by: NOhad Ben-Cohen <ohad@wizery.com> Acked-by: NJoerg Roedel <joro@8bytes.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 11月, 2012 5 次提交
-
-
由 Jon Hunter 提交于
Move definition of dmtimer platform data structure in to its own header under <linux/platform_data>. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
Remove unnecessary declaration of structure omap_dm_timer from dmtimer.h and move the actual declaration of structure omap_dm_timer towards top of dmtimer.h to avoid any compilation errors. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
The OMAP2+ system timer code stores the physical address of the timer but never uses it. Remove this and clean-up the code by removing the local variable "size" and changing the names of the local variables mem_rsrc and irq_rsrc to mem and irq, respectively. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
The omap_dm_timer_prepare function is a local function only used in the dmtimer.c file. Therefore, make this a static function and remove its declaration from the dmtimer.h file. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
由 Jon Hunter 提交于
Only OMAP1 devices use the omap_dm_timer_reset() and so require the omap_dm_timer_wait_for_reset() and __omap_dm_timer_reset() functions. Therefore combine these into a single function called omap_dm_timer_reset() and simplify the code. The omap_dm_timer_reset() function is now the only place that is using the omap_dm_timer structure member "sys_stat". Therefore, remove this member and just use the register offset definition to simplify and clean-up the code. The TISTAT register is only present on revision 1 timers and so check for this in the omap_dm_timer_reset() function. Please note that for OMAP1 devices, the TIOCP_CFG register does not have the clock-activity field and so when we reset the timer for an OMAP1 device we only need to configure the idle-mode field in the TIOCP_CFG register. Signed-off-by: NJon Hunter <jon-hunter@ti.com>
-
- 14 11月, 2012 2 次提交
-
-
由 Paul Walmsley 提交于
This reverts commit 3db11fef (ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints). This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2 http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2 http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NJean Pihet <j-pihet@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
由 Paul Walmsley 提交于
This reverts commit 3db11fef (ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints). This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2 http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2 http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2Signed-off-by: NPaul Walmsley <paul@pwsan.com> Acked-by: NJean Pihet <j-pihet@ti.com> Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
-
- 13 11月, 2012 14 次提交
-
-
由 Tomi Valkeinen 提交于
OMAP specific vram allocator is no longer in use, and we can remove all the vram code. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
OMAP specific vram allocator is no longer used, and we can remove init call to the vram allocator. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Use DMA_BIT_MASK() for fb's coherent_dma_mask for clarity. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Benoit Cousson 提交于
The debug-leds driver should not rely on hard coded macro for the iomem size but use the resource size instead. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 09 11月, 2012 2 次提交
-
-
由 Paul Walmsley 提交于
arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h are now completely unused and can be removed. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-
由 Paul Walmsley 提交于
Split omap2_set_globals_prcm() into PRM, CM, and PRCM_MPU variants, since these are all separate IP blocks. This should make it easier to move the PRM, CM, PRCM_MPU code into drivers/ in future patchsets. At this point arch/arm/plat-omap/include/plat/prcm.h is empty; a subsequent patch will remove it, and remove the #include from all the files that #include it. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-