- 22 2月, 2012 1 次提交
-
-
由 NeilBrown 提交于
commit 2fd14964 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos) removed the last usage of 'can_sleep' but did not remove the field. commit 8612bd22 (ARM: OMAP2+: UART: Avoid console uart idling during bootup) removed the last non-trivial use of 'pdev'. So remove these fields and the one trivial use. Acked-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NNeilBrown <neilb@suse.de> [khilman@ti.com: minor changelog edits] Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 10 2月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Prevent OMAP UARTs from going idle while they are still transferring data in PIO mode. This works around an oversight in the OMAP UART hardware present in OMAP34xx and earlier: an idle UART won't send a wakeup when the TX FIFO threshold is reached. This causes long delays during data transmission when the MPU powerdomain enters a low-power mode. The MPU interrupt controller is not able to respond to interrupts when it's in a low-power state, so the TX buffer is not refilled until another wakeup event occurs. This fix changes the erratum i291 DMA idle workaround. Rather than toggling between force-idle and no-idle, it will toggle between smart-idle and no-idle. The important part of the workaround is the no-idle part, so this shouldn't result in any change in behavior. This fix should work on all OMAP UARTs. Future patches intended for the 3.4 merge window will make this workaround conditional on a "feature" flag, and will use the OMAP36xx+ TX event wakeup support. Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 2月, 2012 1 次提交
-
-
由 Paul Walmsley 提交于
Prevent OMAP UARTs from going idle while they are still transferring data in PIO mode. This works around an oversight in the OMAP UART hardware present in OMAP34xx and earlier: an idle UART won't send a wakeup when the TX FIFO threshold is reached. This causes long delays during data transmission when the MPU powerdomain enters a low-power mode. The MPU interrupt controller is not able to respond to interrupts when it's in a low-power state, so the TX buffer is not refilled until another wakeup event occurs. This fix changes the erratum i291 DMA idle workaround. Rather than toggling between force-idle and no-idle, it will toggle between smart-idle and no-idle. The important part of the workaround is the no-idle part, so this shouldn't result in any change in behavior. This fix should work on all OMAP UARTs. Future patches intended for the 3.4 merge window will make this workaround conditional on a "feature" flag, and will use the OMAP36xx+ TX event wakeup support. Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 12月, 2011 18 次提交
-
-
由 Govindraj.R 提交于
Omap_uart_can_sleep function blocks system wide low power state until uart is active remove this func and add qos requests to prevent MPU from transitioning. Keep qos request to default value which will allow MPU to transition and while uart baud rate is available calculate the latency value from the baudrate and use the same to hold constraint while uart clocks are enabled, and if uart is auto-idled the constraint is updated with default constraint value allowing MPU to transition. Qos requests are blocking notifier calls so put these requests to work queue, also the driver uses irq_safe version of runtime API's and callbacks can be called in interrupt disabled context. So to avoid warn on slow path warning while using qos update API's from runtime callbacks use the qos_work_queue. During bootup the runtime_resume call backs might not be called and runtime callback gets called only after uart is idled by setting the autosuspend timeout. So qos_request from runtime resume callback might not activated during boot if uart baudrate is calculated during bootup for console uart, so schedule the qos_work queue once we calc_latency while configuring the uart port. Flush and complete any pending qos jobs in work queue while suspending. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
If OMAP UART is used as console uart and debug is enabled, avoid gating of uart clocks to print all debug prints. If uart clocks are gated then the debug prints from omap_device framework or hwmod framework can cause uart to enter recursive pm_runtime calls, which can cause a deadlock over power lock usage. For example: Say, uart clocks are cut and we get a print from omap_device_disable stating disabling uart clocks. This print calls omap_uart driver console_write which will call runtime API get_sync which means we enter from runtime API put context to runtime API get context. --> runtime put (take power lock) --> print disabling uart clocks --> call uart console write --> call get_sync (try to take power lock) Also any clock enable API call from uart driver should not call any uart operation until clocks are enabled back. Like get_sync having debug print calling uart console write even before clocks are enabled. So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used in debug mode. If so, do not set device_may_wakeup. This will prevent pm_runtime_enable in uart driver and will avoid uart clock gating. Debug is enabled either by adding debug word in bootarg or by setting loglevel=10 Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
If no_console_suspend is used we have prevent uart idling during suspend to provide debug prints. Power domain hooks can idle uarts if left enabled during system wide suspend so re-use the omap_device_disable_idle_on_suspend API's to ensure console_uart is not idled during suspend. omap_device_disable_idle_on_suspend API was used on all uarts since the uart driver was not runtime adapted, now with runtime adaptation we can re-use this API only for no_console_suspend use cases. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Omap-uart can be used as console uart to print early boot messages using earlyprintk so for console uart prevent hwmod reset or idling during bootup. Identify omap-uart used as console and avoid idling rather than preventing all omap-uarts from idling during bootup. Update the comments for the same. Remove the uart idling and enabling back using hwmod_idle/omap_device_enable for all uarts that where left enabled from boot to set the hwmod framework state machine right. This need not be taken care any more serial.c rather can be handled within the hwmod framework. Reference: http://www.spinics.net/lists/linux-omap/msg60300.htmlSigned-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Reuse the num_uarts variable itself to count number of uarts. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Jon Hunter 提交于
When using DMA there are two timeouts defined. The first timeout, rx_timeout, is really a polling rate in which software polls the DMA status to see if the DMA has finished. This is necessary for the RX side because we do not know how much data we will receive. The secound timeout, RX_TIMEOUT, is a timeout after which the DMA will be stopped if no more data is received. To make this clearer, rename rx_timeout as rx_poll_rate and rename the function serial_omap_rx_timeout() to serial_omap_rxdma_poll(). The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is used to indicate when the DMA for UART can be stopped if no more data is received. The value is a global definition that is applied to all instances of the UART. Each UART may be used for a different purpose and so the timeout required may differ. Make this value configurable for each UART so that this value can be optimised for power savings. Signed-off-by: NJon Hunter <jon-hunter@ti.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Deepak K 提交于
The following UART parameters are defined within the UART driver: 1). Whether the UART uses DMA (dma_enabled), by default set to 0 2). The size of dma buffer (set to 4096 bytes) 3). The time after which the dma should stop if no more data is received. 4). The auto suspend delay that will be passed for pm_runtime_autosuspend where uart will be disabled after timeout Different UARTs may be used for different purpose such as the console, for interfacing bluetooth chip, for interfacing to a modem chip, etc. Therefore, it is necessary to be able to customize the above settings for a given board on a per UART basis. This change allows these parameters to be configured from the board file and allows the parameters to be configured for each UART independently. If a board does not define its own custom parameters for the UARTs, then use the default parameters in the structure "omap_serial_default_info". The default parameters are defined to be the same as the current settings in the UART driver to avoid breaking the UART for any cuurnelty supported boards. By default, make all boards use the default UART parameters. Signed-off-by: NDeepak K <deepak.k@ti.com> Signed-off-by: NJon Hunter <jon-hunter@ti.com> Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
With runtime adaptation done remove clock_enable/disbale API's Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
From the runtime callbacks enable hwmod wakeups for uart which will internally enable io-pad wakeups for uarts if they have rx-pad pins set as wakeup capabale. Use the io-ring wakeup mechanism after uart clock gating and leave the PM_WKST set for uart to default reset values cleanup the code in serial.c which was handling PM_WKST reg. Irq_chaing(PRM_DRIVER) is used to wakeup uart after uart clocks are gated using pad wakeup mechanism. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Move the errata handling mechanism from serial.c to omap-serial file and utilise the same func in driver file. Errata i202, i291 are moved to be handled with omap-serial Moving the errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Removed errata and dma_enabled fields from omap_uart_state struct as they are no more needed with errata handling done within omap-serial. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NAlan Cox <alan@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Avoid unconditional context restore every time we gate uart clocks. Check whether context loss happened based on which we can context restore uart regs from uart_port structure. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Remove the uart reset function which is configuring the TX empty irq which can now be handled within omap-serial driver. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Remove context save function from serial.c and move context restore function to omap-serial. Remove all regs stored in omap_uart_state for contex_save/restore, reg read write funcs used in context_save/restore, io_addresses populated for read/write funcs. Clock gating mechanism was done in serial.c and had no info on uart state thus we needed context save and restore in serial.c With runtime conversion and clock gating done within uart driver context restore can be done from regs value available from uart_omap_port structure. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
The mapbase (start_address), membase(io_remap cookie) part of pdata struct omap_uart_port_info are removed as this should be derived within driver. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Padconf wakeup is used to wakeup uart after uart fclks/iclks are gated. Rx-Pad wakeup was done by writing to rx-pad offset value populated in serial.c idle_init. Remove the direct reading and writing into rx pad. Remove the padconf field part of omap_uart_state struct and pad offsets populated. Now with mux framework support we can use mux_utilities along with hmwod framework to handle io-pad configuration and enable rx-pad wake-up mechanism. To avoid breaking any board support add default mux data for all uart's if mux info is not passed from board file. With the default pads populated in serial.c wakeup capability for rx pads is set, this can be used to enable uart_rx io-pad wakeup from hwmod framework. The pad values in 3430sdp/4430sdp/omap4panda board file are same as the default pad values populated in serial.c. Remove pad values from 3430sdp/4430sdp/omap4panda board file and use the default pads from serial.c file. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
Currently we use a shared irq handler to identify uart activity and then trigger a timer. By default the timeout value is zero and can be set or modified from sysfs. If there was no uart activity for the period set through sysfs, the timer will expire and call timer handler this will set a flag can_sleep using which decision to gate uart clocks can be taken. Since the clock gating mechanism is outside the uart driver, we currently use this mechanism. In preparation to runtime implementation for omap-serial driver we can cleanup this mechanism and use runtime API's to gate uart clocks. Removes the following: * timer related info from local uart_state struct * the code used to set timeout value from sysfs. * irqflags used to set shared irq handler. * un-used function omap_uart_check_wakeup. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes) Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
We had been using traditional 8250 driver as uart console driver prior to omap-serial driver. Since we have omap-serial driver in mainline kernel for some time now it has been used as default uart console driver on omap2+ platforms. Remove 8250 support for omap-uarts. Serial_in and serial_out override for 8250 serial driver is also removed. Empty fifo read fix is already taken care with omap-serial driver with data ready bit check from LSR reg before reading RX fifo. Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr in omap-serial driver. Serial_in/out overrides are not neceesary for omap-serial driver and things that are taken with omap-serial driver are removed here. Remove headers that were necessary to support 8250 support and remove all config bindings done to keep 8250 backward compatibility while adding omap-serial driver. Remove omap_uart_reset needed for 8250 autoconf. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Govindraj.R 提交于
In preparation to UART runtime conversion remove uart specific calls from pm24xx/34xx files and their definition from serial.c These func calls will no more be used with upcoming uart runtime design. 1.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks. 2.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend path from PM code, this is removed as same is handled by uart_suspend_port/uart_resume_port in omap-serial driver which will do an port_shutdown on suspend freeing irq and port_startup on resume enabling back irq. 3.) Remove prepare_idle/resume_idle calls used to gate uart clocks. UART clocks can be gated within driver using runtime funcs and be woken up using irq_chaining from omap_prm driver. 4.) Remove console_locking from idle path as clock gating is done withing driver itself with runtime API. Remove is_suspending check used to acquire console_lock. Signed-off-by: NGovindraj.R <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 14 12月, 2011 2 次提交
-
-
由 Hemant Pedanekar 提交于
This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved in mach-omap2/common.c as same will be used for TI814X and is not board specific. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Afzal Mohammed 提交于
This patch updates the common machine specific source files for support for AM33XX/AM335x with cpu type, macros for identification of AM33XX/AM335X device. Signed-off-by: NAfzal Mohammed <afzal@ti.com> Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NKevin Hilman <khilman@ti.com> [tony@atomide.com: updated for map_io and common.h changes, dropped CK_AM33XX] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 18 11月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 05 10月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
Remove all these duplicated structures since a default one is now available. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 16 9月, 2011 2 次提交
-
-
由 Kevin Hilman 提交于
Public omap_device functions need to take platform_device pointers, conversion to omap_device pointers is done internal to the omap_device layer. Signed-off-by: NKevin Hilman <khilman@ti.com>
-
由 Kevin Hilman 提交于
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 13 7月, 2011 1 次提交
-
-
由 Kevin Hilman 提交于
Until these drivers are runtime PM converted, their device power states are managed by calling custom driver hooks late in the idle/suspend path. Therefore, do not let the suspend/resume core code automatically idle these devices since they will be managed manually by the OMAP PM core very late in the idle/suspend path. Signed-off-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 01 3月, 2011 1 次提交
-
-
由 Paul Walmsley 提交于
Rename omap_hwmod_init() to omap_hwmod_register(). Rename omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of the callers to reflect the new names. While here, update some copyrights. Suggested by Tony Lindgren <tony@atomide.com>. N.B. The comment in mach-omap2/serial.c may no longer be correct, given recent changes in init order. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 17 2月, 2011 1 次提交
-
-
由 Hemant Pedanekar 提交于
This patch updates the common machine specific source files with support for TI816X. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 2月, 2011 1 次提交
-
-
由 Tony Lindgren 提交于
The new init_early hook happens at the end of setup_arch, which is too early for kzalloc. However, there's no need to call omap_serial_early_init that early, so fix this by setting it up as a core_initcall. Signed-off-by: NTony Lindgren <tony@atomide.com> Tested-by: NKevin Hilman <khilman@ti.com>
-
- 26 1月, 2011 1 次提交
-
-
由 Torben Hohn 提交于
The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by: NTorben Hohn <torbenh@gmx.de> Cc: Thomas Gleixner <tglx@tglx.de> Cc: Greg KH <gregkh@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 12月, 2010 1 次提交
-
-
由 Tony Lindgren 提交于
This is needed to pass board specific data such as pads used to the platform level driver init code. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 22 12月, 2010 3 次提交
-
-
由 Paul Walmsley 提交于
Now that OMAP4-specific PRCM functions have been added, distinguish the existing OMAP2/3-specific PRCM functions by prefixing them with "omap2_". This patch should not result in any functional change. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NRajendra Nayak <rnayak@ti.com>
-
由 Paul Walmsley 提交于
In preparation for adding OMAP4-specific PRCM accessor/mutator functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was OMAP2xxx/3xxx-specific. This process also requires the #includes in each of these files to be changed to reference the new file name. As part of doing so, add some comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use "sideways includes", to indicate that these users of the PRM/CM includes should not be doing so. Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-by: NOmar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: NFelipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: NKevin Hilman <khilman@deeprootsystems.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com> Tested-by: NRajendra Nayak <rnayak@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Paul Walmsley 提交于
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock serializes most post-initialization hwmod operations such as enable, idle, and shutdown.) Spinlocks are needed, because in some cases, hwmods must be enabled from timer interrupt disabled-context, such as an ISR. The current use-case that is driving this is the OMAP GPIO block ISR: it can trigger interrupts even with its clocks disabled, but these clocks are needed for register accesses in the ISR to succeed. This patch also effectively reverts commit 84824022 - this patch makes _omap_hwmod_enable() and _omap_hwmod_init() static, renames them back to _enable() and _idle(), and changes their callers to call the spinlocking versions. Previously, since omap_hwmod_{enable,init}() attempted to take mutexes, these functions could not be called while the timer interrupt was disabled; but now that the functions use spinlocks and save and restore the IRQ state, it is appropriate to call them directly. Kevin Hilman <khilman@deeprootsystems.com> originally proposed this patch - thanks Kevin. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
- 01 12月, 2010 2 次提交
-
-
由 Andrei Emeltchenko 提交于
Access to some registers depends on register access mode Three different modes are available for OMAP (at least) • Operational mode LCR_REG[7] = 0x0 • Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF • Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF Define access modes and remove redefinitions and magic numbers in serial drivers (and later in bluetooth driver). Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Andrei Emeltchenko 提交于
Define MDR1 register serial definitions used in serial and bluetooth drivers. Change magic number to ones defined in serial_reg for omap1/2 serial driver. Remove redefined MDR1 register definitions in omap-serial driver. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@nokia.com> Acked-by: NG, Manjunath Kondaiah <manjugk@ti.com> Acked-by: NGovindraj.R <govindraj.raja@ti.com> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 11月, 2010 2 次提交
-
-
由 Paul Walmsley 提交于
The console semaphore must be held while the OMAP UART devices are disabled, lest a console write cause an ARM abort (and a kernel crash) when the underlying console device is inaccessible. These crashes only occur when the console is on one of the OMAP internal serial ports. While this problem has been latent in the PM idle loop for some time, the crash was not triggerable with an unmodified kernel until commit 6f251e9d ("OMAP: UART: omap_device conversions, remove implicit 8520 assumptions"). After this patch, a console write often occurs after the console UART has been disabled in the idle loop, crashing the system. Several users have encountered this bug: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html The same commit also introduced new code that disabled the UARTs during init, in omap_serial_init_port(). The kernel will also crash in this code when earlyconsole and extra debugging is enabled: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html The minimal fix for the -rc series is to hold the console semaphore while the OMAP UARTs are disabled. This is a somewhat overbroad fix, since the console may not be located on an OMAP UART, as is the case with the GPMC UART on Zoom3. While it is technically possible to determine which devices the console or earlyconsole is actually running on, it is not a trivial problem to solve, and the code to do so is not really appropriate for the -rc series. The right long-term fix is to ensure that no code outside of the OMAP serial driver can disable an OMAP UART. As I understand it, code to implement this is under development by TI. This patch is a collaboration between Paul Walmsley <paul@pwsan.com> and Tony Lindgren <tony@atomide.com>. Thanks to Ming Lei <tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their feedback on earlier versions of this patch. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com> Acked-by: NKevin Hilman <khilman@deeprootsystems.com> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Pramod <pramod.gurav@ti.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jean Pihet <jean.pihet@newoldbits.com> Cc: Govindraj.R <govindraj.raja@ti.com>
-
由 Kevin Hilman 提交于
Add additional check to omap_uart_resume_idle() so that only enabled (specifically, idle-enabled) UARTs are allowed to resume. This matches the existing check in prepare idle. Without this patch, the system will hang if a board is configured to register only some uarts instead of all of them and PM is enabled. Cc: Govindraj R. <govindraj.raja@ti.com> Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com> [tony@atomide.com: updated description] Signed-off-by: NTony Lindgren <tony@atomide.com>
-