On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava <keshava_mgo...@ti.com> wrote: > hi kevin > now I am using initramfs with kernel linux3.5.rc1, > but the retention is not working in 3430 sdp. I am seeing the following > error followed by a crash > > > echo mem > /sys/power/state > [ 35.609252] PM: Syncing filesystems ... done. > [ 35.614654] PM: Preparing system for mem sleep > [ 35.658630] Freezing user space processes ... (elapsed 0.01 seconds) > done. > [ 35.689727] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) > done. > [ 35.697692] PM: Entering mem sleep > [ 35.722442] usb usb1: usb auto-resume > [ 35.726409] ehci-omap ehci-omap.0: resume root hub > [ 35.775451] hub 1-0:1.0: hub_resume > [ 35.779846] hub 1-0:1.0: hub_suspend > [ 35.784240] usb usb1: bus suspend, wakeup 0 > [ 35.788665] ehci-omap ehci-omap.0: suspend root hub > [ 35.805786] PM: suspend of devices complete after 99.304 msecs > [ 35.816497] PM: late suspend of devices complete after 4.364 msecs > [ 35.831573] PM: noirq suspend of devices complete after 8.331 msecs > [ 35.838500] Disabling non-boot CPUs ... > [ 36.312164] Powerdomain (core_pwrdm) didn't enter target state 1 > [ 36.318481] Could not enter target state in pm_suspend > [ 36.324859] Unable to handle kernel NULL pointer dereference at virtual > address 00000018 > [ 36.333557] pgd = c6280000 > [ 36.336639] [00000018] *pgd=85c8f831, *pte=00000000, *ppte=00000000 > [ 36.343414] Internal error: Oops: 17 [#1] SMP ARM > [ 36.348388] Modules linked in: > [ 36.351623] CPU: 0 Tainted: G W (3.5.0-rc1 #1) > [ 36.357574] PC is at _od_resume_noirq+0x14/0x58 > [ 36.362365] LR is at dpm_run_callback+0x2c/0x74 > [ 36.367126] pc : [<c003c150>] lr : [<c02d75e4>] psr: a0000013 > [ 36.367126] sp : c5ebfe80 ip : c0a72fc0 fp : 00000006 > [ 36.379150] r10: c78af4b8 r9 : c0a3607c r8 : c003c13c > [ 36.384643] r7 : 00000000 r6 : 00000000 r5 : c78af408 r4 : c78af408 > [ 36.391479] r3 : 00000000 r2 : 00000000 r1 : c78af408 r0 : c78af400 > [ 36.398315] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment > user > [ 36.405792] Control: 10c5387d Table: 86280019 DAC: 00000015 > [ 36.411834] Process sh (pid: 1254, stack limit = 0xc5ebe2f8) > [ 36.417785] Stack: (0xc5ebfe80 to 0xc5ec0000) > [ 36.422363] fe80: c78af408 c02d75e4 c0a36020 c0a36040 00000000 00000000 > c78af408 c0f9e4a8 > [ 36.430938] fea0: 00000010 c0a36014 c0a36074 c02d8178 58566b0d 00000008 > 58566b0d 00000008 > [ 36.439514] fec0: c0a1df38 00000010 ffffffff 00000003 c0a4d11c 00000000 > 00000000 c09da45c > [ 36.448089] fee0: 000ed008 c02d8a14 c0a62c28 c0080360 00000003 c05b9ce8 > 00000000 00000004 > [ 36.456665] ff00: 00000000 c04c9704 c78012c0 c00806a4 c5c8e000 00000003 > c05b9ce8 c007f8a8 > [ 36.465240] ff20: c5c8d4c0 c5c8d4d8 c5ebff80 c7863e00 c02674a8 c02674c0 > 00000004 c016d7fc > [ 36.473815] ff40: c5d94a80 00000004 b6ff6000 c5ebff80 00000000 00000000 > 00000000 c010c244 > [ 36.482421] ff60: c0014400 c5c92280 c5d94a80 b6ff6000 00000004 00000004 > 00000000 c010c398 > [ 36.490997] ff80: 00000000 00000000 b6f235e8 00000000 00000004 b6ff6000 > b6f235e8 c00144a8 > [ 36.499572] ffa0: c5ebe000 c00142e0 00000004 b6ff6000 00000001 b6ff6000 > 00000004 00000000 > [ 36.508148] ffc0: 00000004 b6ff6000 b6f235e8 00000004 00000004 00000964 > 0000000a 000ed008 > [ 36.516723] ffe0: b6ff6000 bee815d0 b6e61c70 b6eb1abc 60000010 00000001 > 00000000 00000000 > [ 36.525360] [<c003c150>] (_od_resume_noirq+0x14/0x58) from [<c02d75e4>] > (dpm_run_callback+0x2c/0x74) > [ 36.534973] [<c02d75e4>] (dpm_run_callback+0x2c/0x74) from [<c02d8178>] > (dpm_resume_noirq+0xdc/0x2f4) > [ 36.544677] [<c02d8178>] (dpm_resume_noirq+0xdc/0x2f4) from [<c02d8a14>] > (dpm_resume_start+0xc/0x18) > [ 36.554290] [<c02d8a14>] (dpm_resume_start+0xc/0x18) from [<c0080360>] > (suspend_devices_and_enter+0x114/0x2d8) > [ 36.564819] [<c0080360>] (suspend_devices_and_enter+0x114/0x2d8) from > [<c00806a4>] (pm_suspend+0x180/0x1fc) > [ 36.575042] [<c00806a4>] (pm_suspend+0x180/0x1fc) from [<c007f8a8>] > (state_store+0x90/0x124) > [ 36.583953] [<c007f8a8>] (state_store+0x90/0x124) from [<c02674c0>] > (kobj_attr_store+0x18/0x1c) > [ 36.593109] [<c02674c0>] (kobj_attr_store+0x18/0x1c) from [<c016d7fc>] > (sysfs_write_file+0xfc/0x180) > [ 36.602722] [<c016d7fc>] (sysfs_write_file+0xfc/0x180) from [<c010c244>] > (vfs_write+0xb0/0x134) > [ 36.611877] [<c010c244>] (vfs_write+0xb0/0x134) from [<c010c398>] > (sys_write+0x40/0x70) > [ 36.620300] [<c010c398>] (sys_write+0x40/0x70) from [<c00142e0>] > (ret_fast_syscall+0x0/0x3c) > [ 36.629180] Code: e1a04000 e2500008 01a02000 15902248 (e5d23018) > [ 36.635833] ---[ end trace b3b167c1e86e5512 ]--- > > > which kernel version are you using? do you have any good commit on which > retention works because of usb host? > > > regards > keshava > > > > On Fri, Jun 8, 2012 at 7:55 PM, Munegowda, Keshava <keshava_mgo...@ti.com> > wrote: >> >> yes! I am using the ramfs. >> >> regards >> keshava >> >> >> >> On Fri, Jun 8, 2012 at 7:31 PM, Kevin Hilman <khil...@ti.com> wrote: >>> >>> "Munegowda, Keshava" <keshava_mgo...@ti.com> writes: >>> >>> > hi Ameya >>> > I was trying to reproduce the 3430 usb pm issues ; but i see >>> > that >>> > NFS is not working in 3430 sdp; >>> >>> You don't need NFS to reproduce this. If you can't get NFS to work, >>> just use a busybox initramfs. >>> >>> This bug needs to be fixed for v3.5-rc. >>> >>> Kevin >>> >>> > it is because of the following the UART patch series (21 patch). I >>> > couldn't able to figure out the actual patch which >>> > breaks NFS because individual patches in this series does not >>> > compile. >>> > these patches are already in lo master. >>> > here is the patch list: >>> > >>> > ----------------------------------------------------------------------- >>> > ------------------------------------------------------------------ >>> > commit da27468655540b083525177f5dc6f3b1f6e3b869 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Wed Dec 14 21:24:11 2011 +0530 >>> > ARM: OMAP2+: UART: Fix compilation/sparse warnings >>> > >>> > 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: Kevin Hilman <khil...@ti.com> >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 2fd149645eb46d26130d7070c6de037dddf34880 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Wed Nov 9 17:41:21 2011 +0530 >>> > ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 36fc2d15b120ef85be74c68b5ad74ac04fbefa8a >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Wed Sep 21 16:54:12 2011 +0530 >>> > ARM: OMAP2+: UART: Do not gate uart clocks if used for >>> > debug_prints >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 08f86b3eab9807e6d36de7e00025abad893ff557 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Oct 18 17:09:10 2011 +0530 >>> > ARM: OMAP2+: UART: Avoid uart idling on suspend for >>> > no_console_suspend usecase >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 8612bd22f30369745d0fda0d540aca39ab591cc5 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 19:05:44 2011 +0530 >>> > ARM: OMAP2+: UART: Avoid console uart idling during bootup >>> > >>> > 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.html >>> > >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 969996a57fd2345a1141280dddcf9e10fa5f6690 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Oct 18 16:32:14 2011 +0530 >>> > ARM: OMAP2+: UART: remove temporary variable used to count uart >>> > instance >>> > >>> > Reuse the num_uarts variable itself to count number of uarts. >>> > >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit a9e210e0b7a344c0e44aa6bf6888176bbc635c42 >>> > Author: Jon Hunter <jon-hun...@ti.com> >>> > Date: Wed Nov 9 17:34:49 2011 +0530 >>> > ARM: OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for >>> > each UART >>> > >>> > 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-hun...@ti.com> >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit c86845db77ce220f77e6645b18800744684946ac >>> > Author: Deepak K <deepa...@ti.com> >>> > Date: Wed Nov 9 17:33:38 2011 +0530 >>> > ARM: OMAP2+: UART: Allow UART parameters to be configured from >>> > board file. >>> > >>> > 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 <deepa...@ti.com> >>> > Signed-off-by: Jon Hunter <jon-hun...@ti.com> >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 634bd6e4817cd6a7109be8d2eee5c578a283d1ee >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 19:01:24 2011 +0530 >>> > ARM: OMAP2+: UART: Remove old and unused clocks handling funcs >>> > >>> > With runtime adaptation done remove clock_enable/disbale API's >>> > >>> > Signed-off-by: Govindraj.R <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 62f3ec5fbd5fddce62b7a71adc04723a5eb903da >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Thu Oct 13 14:11:09 2011 +0530 >>> > ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 94734749af794c080f6af6ac3ce8c1c13ee2dbbd >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 19:00:33 2011 +0530 >>> > ARM: OMAP2+: UART: Move errata handling from serial.c to >>> > omap-serial >>> > >>> > 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: Govindraj.R <govindraj.r...@ti.com> >>> > Acked-by: Alan Cox <a...@linux.intel.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit ec3bebc6ec64aac23500e6b8ef5c0aaaeda735cf >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Oct 11 19:11:27 2011 +0530 >>> > ARM: OMAP2+: UART: Get context loss count to context restore >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 32212897eeb8c2b2b3c74dbd44d842963084d808 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 18:58:55 2011 +0530 >>> > ARM: OMAP2+: UART: Remove uart reset function. >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit c538d20c7f437e56c5301357c492230d1d6d1b80 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 18:57:03 2011 +0530 >>> > ARM: OMAP2+: UART: Ensure all reg values configured are >>> > available >>> > from port structure >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 9f9ac1e84a24670eea1430040e0aef278b4daffa >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 18:56:12 2011 +0530 >>> > ARM: OMAP2+: UART: Remove context_save and move context restore >>> > to >>> > driver >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit fcdca75728ac376f3de74376c791e1078ee83820 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Feb 28 18:12:23 2011 +0530 >>> > ARM: OMAP2+: UART: Add runtime pm support for omap-serial driver >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Alan Cox <a...@linux.intel.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit edd70ad757e9b336116433e6e62de79ae1dfef54 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Oct 11 14:55:41 2011 +0530 >>> > ARM: OMAP2+: UART: Remove mapbase/membase fields from pdata. >>> > >>> > 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: Govindraj.R <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 7496ba309f2adbce74d917fbb8bd3da26222d49f >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Mon Nov 7 18:55:05 2011 +0530 >>> > ARM: OMAP2+: UART: Add default mux for all uarts. >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 273558b3a0399e368d99da5b3daf1c0e11b93e06 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Sep 13 14:01:01 2011 +0530 >>> > ARM: OMAP2+: UART: Cleanup part of clock gating mechanism for >>> > uart >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Acked-by: Greg Kroah-Hartman <gre...@suse.de> (for drivers/tty >>> > changes) >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 8a60585159067f110075ef8ffda13abd94826daf >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Tue Sep 13 13:32:32 2011 +0530 >>> > ARM: OMAP2+: UART: cleanup 8250 console driver support >>> > >>> > 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 <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > commit 8384c9749f8c31c6e1e64a63c8d50af7863ce657 >>> > Author: Govindraj.R <govindraj.r...@ti.com> >>> > Date: Wed Nov 9 17:22:30 2011 +0530 >>> > ARM: OMAP2+: UART: cleanup + remove uart pm specific API >>> > >>> > 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: Govindraj.R <govindraj.r...@ti.com> >>> > Signed-off-by: Kevin Hilman <khil...@ti.com> >>> > >>> > ----------------------------------------------------------------------- >>> > ------------------------------------------------------------------ >>> > >>> > regards >>> > keshava >>> > >>> > On Wed, Jun 6, 2012 at 5:21 PM, Munegowda, Keshava >>> > <keshava_mgo...@ti.com> wrote: >>> > >>> > hi Kevin >>> > I have started this; I see that mainline is not booting in 3430 >>> > sdp >>> > i will fix this first. >>> > regards >>> > keshava >>> > >>> > On Tue, Jun 5, 2012 at 11:20 PM, Kevin Hilman <khil...@ti.com> >>> > wrote: >>> > >>> > Keshava, Felipe, >>> > ping. This problem is still preventing CORE retention in >>> > mainline. >>> > >>> > On 05/24/2012 03:13 PM, Kevin Hilman wrote: >>> > >>> > Kevin Hilman<khil...@ti.com> writes: >>> > >>> > "Munegowda, Keshava"<keshava_mgo...@ti.com> writes: >>> > >>> > On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman<khil...@ti.com> >>> > wrote: >>> > >>> > On 05/23/2012 05:01 PM, Kevin Hilman wrote: >>> > >>> > Hi Keshava, >>> > Using current l-o master, I noticed that CORE was not hitting >>> > retention >>> > in idle on my 3530/Overo. CORE hits retention on suspend just >>> > fine. >>> > Debugging this, I found that usbtll_fck was still enabled during >>> > idle, >>> > thus preventing CORE from hitting retention. >>> > To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in >>> > .config) >>> > and >>> > was then started seeing CORE hit retention in idle again. >>> > I have nothing plugged into the USB host port on this board, so I >>> > would've expected that runtime PM would've kicked in and shutdown >>> > this >>> > clock. >>> > Any ideas what's going on here? Is this expected behavior? >>> > >>> > If it helps, attached is a bootlog after enabling debug for >>> > mfd/omap-usb-host.c as well. Notice there's a couple of >>> > clock-related >>> > warnings from this driver as well. Not sure if they're relevant: >>> > usbhs_omap: alias fck already exists >>> > usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 >>> > >>> > these clocks were specific to omap4 and it should not cause any >>> > problem to omap3 boards. >>> > >>> > OK, they seem unrelated to this CORE retention problem, but the >>> > warnings >>> > should still be understood and fixed. >>> > >>> > I will try to reproduce this on 3430 sdp to explore further. >>> > >>> > Thanks for looking. Note that I only saw this problem on my 3530 >>> > platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS >>> > host >>> > AFAICT, so didn't test there. >>> > >>> > After realizing that the same IP should exist on 3430/n900, I copied >>> > some board file support for USBHS host from overo into the n900 >>> > board >>> > file in order to test on 3430/n900. >>> > Problem exists on n900 too. >>> > Kevin
Hi Kevin Since 3430 sdp is very unstable , I have switched to 3630 beagle XM. Also am observing that core retention is not working even without usb support. I have started using a branch "remotes/origin/for_3.5/pm-misc" in your tree git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git but, in this branch also the core retention is not working even without usb support. Is there any working branch you have to continue working on this problem. regards keshava -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
