- 16 Dec, 2011 12 commits
-
-
Tony Lindgren authored
Merge branch 'for_3.3/uart/runtime-pm' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into uart Conflicts: arch/arm/mach-omap2/pm34xx.c
-
-
Rajendra Nayak authored
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to identify such devices/hwmods. When the device/hwmod is requested to be enabled (the first time) by its driver/user, nothing except the mux-enable is needed. The mux data is board specific and is unavailable during initial enable() of the device, done by the framework as part of setup(). A good example of a such a device is an UART used as debug console. The UART module needs to be kept enabled through the boot, until the UART driver takes control of it, for debug prints to appear on the console. Acked-by:
Kevin Hilman <khilman@ti.com> Acked-by:
Benoit Cousson <b-cousson@ti.com> Signed-off-by:
Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use a flag rather than a state; updated commit message; edited some documentation] Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tero Kristo authored
Use the new PRCM interrupt handler code on OMAP4 systems. The OMAP code will need to be converted to use sparse IRQs for this to work. Until that time, the following message will appear on boot: PRCM: failed to allocate irq descs: -12 Signed-off-by:
Tero Kristo <t-kristo@ti.com> Tested-by:
-
Tero Kristo authored
PM interrupt handling is now done through the PRCM chain handler. The interrupt handling logic is also split in two parts, to serve IO and WKUP events separately. This allows us to handle IO chain events in a clean way. Core event code is also changed in accordance to this, as PRCM interrupt handling is done by independent handlers, and the core handler should not clear the IO events anymore. Signed-off-by:
-
Tero Kristo authored
By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by:
-
Tero Kristo authored
OMAP mux now parses active wakeup events from pad registers and calls corresponding hwmod ISRs once a wakeup is detected. This is accomplished by registering an interrupt handler for PRCM IO event, which is raised every time the HW detects wakeups. [paul@pwsan.com: This patch is a merge of Govindraj R's "ARM: OMAP2+: hwmod: Add API to check IO PAD wakeup status" patch, Tero Kristo's "ARM: OMAP2+: mux: add support for PAD wakeup interrupts" patch, and part of Tero's "ARM: OMAP: mux: add support for selecting mpu_irq for each wakeup pad" patch.] Signed-off-by:
-
Tero Kristo authored
PRCM chain handler needs to disable forwarding of interrupts during suspend, because runtime PM is disabled and most of the drivers are potentially not able to handle interrupts coming at this time. This patch masks all the PRCM interrupt events if a PRCM interrupt occurs during suspend, but does not ack them. Once suspend finish is called, all the masked events will be re-enabled, which causes immediate PRCM interrupt and handles the postponed event. The suspend prepare and complete callbacks will be called from pm34xx.c / pm44xx.c files in the following patches. The functions defined in this patch should eventually be moved to suspend->prepare and suspend->finish driver hooks, once the PRCM chain handler will be made as its own driver. Signed-off-by:
-
Tero Kristo authored
Introduce a chained interrupt handler mechanism for the PRCM interrupt, so that individual PRCM event can cleanly be handled by handlers in separate drivers. We do this by introducing PRCM event names, which are then matched to the particular PRCM interrupt bit depending on the specific OMAP SoC being used. PRCM interrupts have two priority levels, high or normal. High priority is needed for IO event handling, so that we can be sure that IO events are processed before other events. This reduces latency for IO event customers and also prevents incorrect ack sequence on OMAP3. Signed-off-by:
-
Paul Walmsley authored
Add PRM functions to test for pending PRM IRQs. This will be used in a subsequent patch to implement the PRM interrupt handler on the MPU. Add PRM functions to ensure that all outstanding writes from the MPU to the PRM IP block have completed before continuing execution. This will be used in a subsequent patch to ensure that all PRM interrupt status bits are cleared in the hardware before exiting the ISR. Normally we would not expose such a low-level function to other code. But the current implementation of the PRM interrupt code, which uses the generic IRQ chip code, doesn't give us a choice. The pending PRM IRQ functions are based on code originally written by Tero Kristo <t-kristo@ti.com>. Signed-off-by: -
Govindraj R authored
Add API to enable IO pad wakeup capability based on mux pad and wake_up enable flag available from hwmod_mux initialization. Use the wakeup_enable flag and enable wakeup capability for the given pads. Wakeup capability will be enabled/disabled during hwmod idle transition based on whether wakeup_flag is set or cleared. If the hwmod is currently idled, and any mux values were changed by _set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated. Signed-off-by:
Govindraj.R <govindraj.raja@ti.com> Signed-off-by:
-
Paul Walmsley authored
omap_hwmod_mux() currently only iterates through the dynamic pad list. This list currently only consists of pads with the OMAP_DEVICE_MUX_REMUX flag set. Subsequent patches in this series will cause hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set to be changed dynamically, to control hwmod I/O ring wakeup. For this to work correctly, hwmod mux entries with the OMAP_DEVICE_MUX_WAKEUP flag set must also be added to the dynamic pad list. So this patch modifies omap_hwmod_mux_init() to do so. Signed-off-by:
-
- 15 Dec, 2011 17 commits
-
-
Govindraj.R authored
Fixes below compilation warning. drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq': drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized] Fix below sparse warning. drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in argument 2 (different signedness) drivers/tty/serial/omap-serial.c:392:52: expected int *status drivers/tty/serial/omap-serial.c:392:52: got unsigned int *<noident> Reported-by:
-
Govindraj.R authored
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:
-
Govindraj.R authored
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: -
Govindraj.R authored
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:
-
Govindraj.R authored
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:
-
Govindraj.R authored
Reuse the num_uarts variable itself to count number of uarts. Signed-off-by:
-
Jon Hunter authored
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:
Jon Hunter <jon-hunter@ti.com> Signed-off-by:
-
Deepak K authored
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:Deepak K <deepak.k@ti.com> Signed-off-by:
-
Govindraj.R authored
With runtime adaptation done remove clock_enable/disbale API's Signed-off-by:
-
Govindraj.R authored
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:
-
Govindraj.R authored
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:
Alan Cox <alan@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Govindraj.R authored
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:
-
Govindraj.R authored
Remove the uart reset function which is configuring the TX empty irq which can now be handled within omap-serial driver. Signed-off-by:
-
Govindraj.R authored
Add missing uart regs to uart_port structure which can be used in context restore. Store dll, dlh, mdr1, scr, efr, lcr, mcr reg values into uart_port structure while configuring individual port in termios function. Signed-off-by:
-
Govindraj.R authored
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:
-
Govindraj.R authored
Adapts omap-serial driver to use pm_runtime API's. Use runtime runtime API's to handle uart clocks and obtain device_usage statics. Set runtime API's usage to irq_safe so that we can use get_sync from irq context. Auto-suspend for port specific activities and put for reg access. Moving suspend/resume hooks to dev_pm_ops structure and bind with config_suspend to avoid any compilation warning if config_suspend is disabled. By default uart autosuspend delay is set to -1 to avoid character loss if uart's are autoidled and woken up on rx pin. After boot up UART's can be autoidled by setting autosuspend delay from sysfs. echo 3000 > /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc. Also if uart is not wakeup capable we can prevent runtime autosuspend by forbiding runtime. Signed-off-by:
-
Govindraj.R authored
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:
-
- 14 Dec, 2011 4 commits
-
-
Govindraj.R authored
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:
-
Govindraj.R authored
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:
-
Govindraj.R authored
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:
-
Govindraj.R authored
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:
-
- 13 Dec, 2011 6 commits
-
-
Hemant Pedanekar authored
This patch adds cpu type, macros for identification of TI814X device. Signed-off-by:
Hemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_TI814X for now] Signed-off-by:
-
Hemant Pedanekar authored
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:
-
Leonid Iziumtsev authored
Add support for detection of the next chip in the OMAP4 family: OMAP4470 ES1.0 For more details on OMAP4470, visit: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12869&contentId=123362Signed-off-by:
Leonid Iziumtsev <x0153368@ti.com> Signed-off-by:
-
David Anders authored
allow for the omap4430 es2.3 revision to be recognized in the omap4_check_revision() function. most aspects of all omap4430 es2.x versions are identical, however a number of small variations such as default pullup or pulldown resistor configurations vary between revisions. detailed information on silicon errata for omap4430 revisions can be found at http://focus.ti.com/pdfs/wtbu/swpz009D.pdfSigned-off-by:
David Anders <x0132446@ti.com> Signed-off-by:
-
Afzal Mohammed authored
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:
Afzal Mohammed <afzal@ti.com> Signed-off-by:
Vaibhav Hiremath <hvaibhav@ti.com> Reviewed-by:
-
Afzal Mohammed authored
This patch updates the common platform files with AM335X device support (AM33XX family). The approach taken in this patch is, AM33XX device will be considered as OMAP3 variant, and a separate SoC class created for AM33XX family of devices with a subclass type for AM335X device, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks will return success on AM335X device. A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3 to include support for AM33XX build. Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by:
-
- 08 Dec, 2011 1 commit
-
-
Tony Lindgren authored
Merge branch 'for_3.3/pm/omap4-mpuss' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap4
-
