All of lore.kernel.org
 help / color / mirror / Atom feed
* MFD USB host: prevents CORE retention in idle
@ 2012-05-24  0:01 Kevin Hilman
  2012-05-24  0:25 ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-05-24  0:01 UTC (permalink / raw)
  To: Keshava Munegowda, Felipe Balbi; +Cc: linux-omap

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?

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-05-24  0:01 MFD USB host: prevents CORE retention in idle Kevin Hilman
@ 2012-05-24  0:25 ` Kevin Hilman
  2012-05-24  7:05   ` Munegowda, Keshava
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-05-24  0:25 UTC (permalink / raw)
  To: Keshava Munegowda, Felipe Balbi; +Cc: linux-omap

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

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

With debug enabled, I see the runtime resume during init followed by the 
runtime suspend.

[    0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed 
error:-22
[    0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
[    0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
[    0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
[    0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1
[    0.944671] usbhs_omap usbhs_omap: UHH setup done, 
uhh_hostconfig=8000121d
[    0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend

However, later in the boot I see a runtime_resume and never see another 
suspend.  That seems to be the root cause of CORE not hitting retention.

 From the boot log:

[    2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[    2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
[    2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
[    3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
[    3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 
pcc=3 ordered ports=3
[    3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 
uframes 256/512/1024 park
[    3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3 
ithresh=8 period=1024 Reset HALT
[    3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller

Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how 
this driver is being runtime resumed.  Presumably it's due to how the 
rest of the USB stack works, which I'm not at all familiar with.

Hopefully, the above is enough to debug the problem,

Thanks,

Kevin

[-- Attachment #2: boot.txt --]
[-- Type: text/plain, Size: 15733 bytes --]

[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.4.0-rc7-pm+debug+initramfs-01073-g0ecc382-dirty (khilman@paris) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #20 SMP Wed May 23 17:10:56 PDT 2012
[    0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Gumstix Overo
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c09c0dc0, node_mem_map c0f1e000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 64768 pages, LIFO batch:15
[    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz
[    0.000000] PERCPU: Embedded 9 pages/cpu @c1124000 s12992 r8192 d15680 u36864
[    0.000000] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: console=ttyO2,115200n8 earlyprintk ip=192.168.1.157:192.168.1.5:192.168.1.254:255.255.255.0:overo:eth0:none root=/dev/nfs nfsroot=192.168.1.236:/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=409
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 243328k/243328k available, 18816k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc066da70   (6551 kB)
[    0.000000]       .init : 0xc066e000 - 0xc092b2c0   (2805 kB)
[    0.000000]       .data : 0xc092c000 - 0xc09c3530   ( 606 kB)
[    0.000000]        .bss : 0xc09c3554 - 0xc0f1d620   (5481 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:474
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062866] Calibrating delay loop... 497.82 BogoMIPS (lpj=1941504)
[    0.106231] pid_max: default: 32768 minimum: 301
[    0.112091] Security Framework initialized
[    0.116760] Mount-cache hash table entries: 512
[    0.128845] CPU: Testing write buffer coherency: ok
[    0.135284] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.140777] Setting up static identity map for 0x8048cf58 - 0x8048cfc8
[    0.150268] Brought up 1 CPUs
[    0.153411] SMP: Total of 1 processors activated (497.82 BogoMIPS).
[    0.189422] dummy: 
[    0.194763] NET: Registered protocol family 16
[    0.201293] GPMC revision 5.0
[    0.204742] gpmc: irq-20 could not claim: err -22
[    0.224334] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.231872] OMAP GPIO hardware version 2.5
[    0.237823] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.246490] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.255310] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.264038] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[    0.272796] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[    0.289855] omap_mux_init: Add partition: #1: core, flags: 0
[    0.327178] Reprogramming SDRC clock to 331882352 Hz
[    0.332550] Found NAND on CS0
[    0.335693] Registering NAND on CS0
[    0.342926]  usbhs_omap: alias fck already exists
[    0.366394] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.394683]  omap-mcbsp.2: alias fck already exists
[    0.401367]  omap-mcbsp.3: alias fck already exists
[    0.412933] OMAP DMA hardware revision 4.0
[    0.514068] bio: create slab <bio-0> at 0
[    0.524139] fixed-dummy: 
[    0.528808] vads7846: 3300 mV 
[    0.540191] SCSI subsystem initialized
[    0.547149] omap2_mcspi omap2_mcspi.1: master is unqueued, this is deprecated
[    0.559478] omap2_mcspi omap2_mcspi.2: master is unqueued, this is deprecated
[    0.568756] omap2_mcspi omap2_mcspi.3: master is unqueued, this is deprecated
[    0.578124] omap2_mcspi omap2_mcspi.4: master is unqueued, this is deprecated
[    0.590362] usbcore: registered new interface driver usbfs
[    0.597778] usbcore: registered new interface driver hub
[    0.604705] usbcore: registered new device driver usb
[    0.627441] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2600 kHz
[    0.646484] twl 1-0048: PIH (irq 7) chaining IRQs 320..328
[    0.653320] twl 1-0048: power (irq 325) chaining IRQs 328..335
[    0.662628] twl4030_gpio twl4030_gpio: gpio (irq 320) chaining IRQs 336..353
[    0.672149] gpiochip_add: registered GPIOs 192 to 211 on device: twl4030
[    0.686859] vdd_mpu_iva: 600 <--> 1450 mV normal 
[    0.694915] vdd_core: 600 <--> 1450 mV normal 
[    0.703033] VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby
[    0.712341] VDAC: 1800 mV normal standby
[    0.719696] VDVI: 1800 mV normal standby
[    0.725646] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
[    0.743560] Switching to clocksource 32k_counter
[    0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22
[    0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
[    0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
[    0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
[    0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1
[    0.944671] usbhs_omap usbhs_omap: UHH setup done, uhh_hostconfig=8000121d
[    0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend
[    0.948974] NET: Registered protocol family 2
[    0.955230] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.965301] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[    0.973297] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    0.985870] TCP: Hash tables configured (established 8192 bind 8192)
[    0.992675] TCP: reno registered
[    0.996124] UDP hash table entries: 128 (order: 1, 10240 bytes)
[    1.002868] UDP-Lite hash table entries: 128 (order: 1, 10240 bytes)
[    1.010864] NET: Registered protocol family 1
[    1.017608] RPC: Registered named UNIX socket transport module.
[    1.024169] RPC: Registered udp transport module.
[    1.029113] RPC: Registered tcp transport module.
[    1.034118] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.367248] VFS: Disk quotas dquot_6.5.2
[    1.371856] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.383026] NFS: Registering the id_resolver key type
[    1.391265] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[    1.400390] msgmni has been set to 475
[    1.409515] io scheduler noop registered
[    1.413848] io scheduler deadline registered
[    1.418670] io scheduler cfq registered (default)
[    1.427276] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.443817] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
[    1.454162] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
[    1.463836] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
[    1.471862] console [ttyO2] enabled, bootconsole disabled
[    1.534423] brd: module loaded
[    1.566497] loop: module loaded
[    1.581359] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.589569] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit)
[    1.607330] Creating 5 MTD partitions on "omap2-nand.0":
[    1.613189] 0x000000000000-0x000000080000 : "xloader"
[    1.628692] 0x000000080000-0x000000240000 : "uboot"
[    1.642272] 0x000000240000-0x000000280000 : "uboot environment"
[    1.654724] 0x000000280000-0x000000680000 : "linux"
[    1.669494] 0x000000680000-0x000010000000 : "rootfs"
[    1.901184] OneNAND driver initializing
[    1.914794] smsc911x: Driver version 2008-10-21
[    1.935760] smsc911x-mdio: probed
[    1.939971] smsc911x smsc911x.0: eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=smsc911x-0:01, irq=-1)
[    1.951568] smsc911x smsc911x.0: eth0: MAC Address: e6:ff:c8:7a:93:cd
[    1.958557] smsc911x: Driver version 2008-10-21
[    1.968933] usbcore: registered new interface driver asix
[    1.975402] usbcore: registered new interface driver cdc_ether
[    1.982574] usbcore: registered new interface driver smsc95xx
[    1.989593] usbcore: registered new interface driver net1080
[    1.996459] usbcore: registered new interface driver cdc_subset
[    2.003570] usbcore: registered new interface driver zaurus
[    2.010375] usbcore: registered new interface driver cdc_ncm
[    2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[    2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
[    2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
[    3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
[    3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3
[    3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes 256/512/1024 park
[    3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3 ithresh=8 period=1024 Reset HALT
[    3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
[    3.039276] /work/kernel/omap/pm/drivers/usb/core/inode.c: creating file 'devices'
[    3.039764] /work/kernel/omap/pm/drivers/usb/core/inode.c: creating file '001'
[    3.043609] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
[    3.052307] ehci-omap ehci-omap.0: park 0
[    3.052429] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
[    3.058532] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 period=512 RUN
[    3.069946] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
[    3.077667] usb usb1: default language 0x0409
[    3.077819] usb usb1: udev 1, busnum 1, minor = 0
[    3.077850] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    3.085021] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    3.092712] usb usb1: Product: OMAP-EHCI Host Controller
[    3.098388] usb usb1: Manufacturer: Linux 3.4.0-rc7-pm+debug+initramfs-01073-g0ecc382-dirty ehci_hcd
[    3.108093] usb usb1: SerialNumber: ehci-omap.0
[    3.115814] usb usb1: usb_probe_device
[    3.115844] usb usb1: configuration #1 chosen from 1 choice
[    3.117004] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[    3.118804] hub 1-0:1.0: usb_probe_interface
[    3.118835] hub 1-0:1.0: usb_probe_interface - got id
[    3.118896] hub 1-0:1.0: USB hub found
[    3.123107] hub 1-0:1.0: 3 ports detected
[    3.127593] hub 1-0:1.0: standalone hub
[    3.127624] hub 1-0:1.0: individual port power switching
[    3.127624] hub 1-0:1.0: individual port over-current protection
[    3.127655] hub 1-0:1.0: power on to power good time: 20ms
[    3.128295] hub 1-0:1.0: local power source is good
[    3.128326] hub 1-0:1.0: enabling power on all ports
[    3.131164] /work/kernel/omap/pm/drivers/usb/core/inode.c: creating file '001'
[    3.132019] ehci-omap ehci-omap.0: ...powerup ports...
[    3.157348] usbcore: registered new interface driver cdc_wdm
[    3.163299] Initializing USB Mass Storage driver...
[    3.169464] usbcore: registered new interface driver usb-storage
[    3.175994] USB Mass Storage support registered.
[    3.182708] usbcore: registered new interface driver libusual
[    3.189819] usbcore: registered new interface driver usbtest
[    3.198333] mousedev: PS/2 mouse device common for all mice
[    3.211944] ads7846 spi1.0: touchscreen, irq 210
[    3.220855] input: ADS7846 Touchscreen as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input0
[    3.234436] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[    3.241302] input: twl4030_pwrbutton as /devices/platform/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input1
[    3.254791] twl_rtc twl_rtc: Power up reset detected.
[    3.260620] twl_rtc twl_rtc: Enabling TWL-RTC
[    3.270568] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    3.279052] i2c /dev entries driver
[    3.287353] Driver for 1-wire Dallas network protocol.
[    3.297821] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[    3.306732] twl4030_wdt twl4030_wdt: Failed to register misc device
[    3.313629] twl4030_wdt: probe of twl4030_wdt failed with error -16
[    3.323944] cpuidle: using governor ladder
[    3.328491] cpuidle: using governor menu
[    3.566802] usbcore: registered new interface driver usbhid
[    3.572906] usbhid: USB HID core driver
[    3.576965] oprofile: hardware counters not available
[    3.582366] oprofile: using timer interrupt.
[    3.588195] TCP: cubic registered
[    3.591705] Initializing XFRM netlink socket
[    3.596557] NET: Registered protocol family 17
[    3.601470] NET: Registered protocol family 15
[    3.606628] Registering the dns_resolver key type
[    3.611907] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
[    3.639282] ThumbEE CPU extension supported.
[    3.643981] sr_init: No PMIC hook to init smartreflex
[    3.649841] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized
[    3.658996] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized
[    3.668823] SmartReflex Class3 initialized
[    3.717376] clock: disabling unused clocks to save power
[    3.729797] VDVI: incomplete constraints, leaving on
[    3.735504] VDAC: incomplete constraints, leaving on
[    3.744567] input: gpio-keys as /devices/platform/gpio-keys/input/input2
[    3.756988] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    3.769744] smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xd0888000, IRQ: 272
[    3.797485] IP-Config: Complete:
[    3.800903]      device=eth0, addr=192.168.1.157, mask=255.255.255.0, gw=192.168.1.254
[    3.809387]      host=overo, domain=, nis-domain=(none)
[    3.814971]      bootserver=192.168.1.5, rootserver=192.168.1.236, rootpath=
[    3.835144] Freeing init memory: 2804K
[    3.991333] mmc1: new SDIO card at address 0001
[    5.234283] hub 1-0:1.0: hub_suspend
[    5.234985] usb usb1: bus auto-suspend, wakeup 1
[    5.235015] ehci-omap ehci-omap.0: suspend root hub
/ # 

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-05-24  0:25 ` Kevin Hilman
@ 2012-05-24  7:05   ` Munegowda, Keshava
  2012-05-24 17:02     ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-05-24  7:05 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Felipe Balbi, linux-omap

On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman <khilman@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.

I will try to reproduce this on 3430 sdp to explore further.


>
> With debug enabled, I see the runtime resume during init followed by the
> runtime suspend.
>
> [    0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed
> error:-22
> [    0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
> [    0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
> [    0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
> [    0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1
> [    0.944671] usbhs_omap usbhs_omap: UHH setup done,ry
> uhh_hostconfig=8000121d
> [    0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend
>
> However, later in the boot I see a runtime_resume and never see another
> suspend.  That seems to be the root cause of CORE not hitting retention.
>
> From the boot log:
>
> [    2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
> [    2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
> [    2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
> [    3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
> [    3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1
> pcc=3 ordered ports=3
> [    3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 uframes
> 256/512/1024 park
> [    3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3
> ithresh=8 period=1024 Reset HALT
> [    3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
>
> Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how
> this driver is being runtime resumed.  Presumably it's due to how the rest
> of the USB stack works, which I'm not at all familiar with.
>
> Hopefully, the above is enough to debug the problem,
>
> Thanks,
>
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-05-24  7:05   ` Munegowda, Keshava
@ 2012-05-24 17:02     ` Kevin Hilman
  2012-05-24 22:13       ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-05-24 17:02 UTC (permalink / raw)
  To: Munegowda, Keshava; +Cc: Felipe Balbi, linux-omap

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman <khilman@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.

FYI, in order to hit core retention, there's another bug in mainline
where the counter_32k IP also prevents retention.  You'll need the hack
below[1] (on top of l-o master) to workaround this problem (real patch
with description will be coming soon.)

Also, you'll likely need the UART mux patch from Govindraj[2].  Without
this, UARTs in CORE may have runtime PM disabled, and thus also prevent
CORE from hitting retention.

Kevin

[1]
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..42eb39d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -292,6 +292,7 @@ static int __init omap2_sync32k_clocksource_init(void)
 							__func__, ret);
 		return ret;
 	}
+	omap_hwmod_set_slave_idlemode(oh, SIDLE_FORCE);
 
 	ret = omap_init_clocksource_32k(vbase);
 	if (ret) {


[2] http://marc.info/?l=linux-omap&m=133672962809100&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-05-24 17:02     ` Kevin Hilman
@ 2012-05-24 22:13       ` Kevin Hilman
  2012-06-05 17:50         ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-05-24 22:13 UTC (permalink / raw)
  To: Munegowda, Keshava; +Cc: Felipe Balbi, linux-omap

Kevin Hilman <khilman@ti.com> writes:

> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>
>> On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman <khilman@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-05-24 22:13       ` Kevin Hilman
@ 2012-06-05 17:50         ` Kevin Hilman
       [not found]           ` <CAP05o4L+0E6fa1VoP_UPTJgKjXb-VqZorUfzsTB3d-KVoFrXfw@mail.gmail.com>
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-06-05 17:50 UTC (permalink / raw)
  To: Munegowda, Keshava, Felipe Balbi; +Cc: linux-omap

Keshava, Felipe,

ping.  This problem is still preventing CORE retention in mainline.

On 05/24/2012 03:13 PM, Kevin Hilman wrote:
> Kevin Hilman<khilman@ti.com>  writes:
>
>> "Munegowda, Keshava"<keshava_mgowda@ti.com>  writes:
>>
>>> On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman<khilman@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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
       [not found]                   ` <CAP05o4LYhFQpEFukyCT2fA7XHPU2L5K8=8W0fncMJk6YEUWdOQ@mail.gmail.com>
@ 2012-06-15 12:04                     ` Munegowda, Keshava
  2012-06-15 13:47                       ` Jean Pihet
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-06-15 12:04 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Ameya Palande, Felipe Balbi, linux-omap

On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
<keshava_mgowda@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_mgowda@ti.com>
> wrote:
>>
>> yes! I am using the ramfs.
>>
>> regards
>> keshava
>>
>>
>>
>> On Fri, Jun 8, 2012 at 7:31 PM, Kevin Hilman <khilman@ti.com> wrote:
>>>
>>> "Munegowda, Keshava" <keshava_mgowda@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.raja@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 <khilman@ti.com>
>>> >        Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 2fd149645eb46d26130d7070c6de037dddf34880
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 36fc2d15b120ef85be74c68b5ad74ac04fbefa8a
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 08f86b3eab9807e6d36de7e00025abad893ff557
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 8612bd22f30369745d0fda0d540aca39ab591cc5
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 969996a57fd2345a1141280dddcf9e10fa5f6690
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit a9e210e0b7a344c0e44aa6bf6888176bbc635c42
>>> >    Author: Jon Hunter <jon-hunter@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-hunter@ti.com>
>>> >        Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit c86845db77ce220f77e6645b18800744684946ac
>>> >    Author: Deepak K <deepak.k@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 <deepak.k@ti.com>
>>> >        Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>> >        Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 634bd6e4817cd6a7109be8d2eee5c578a283d1ee
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 62f3ec5fbd5fddce62b7a71adc04723a5eb903da
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 94734749af794c080f6af6ac3ce8c1c13ee2dbbd
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Alan Cox <alan@linux.intel.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit ec3bebc6ec64aac23500e6b8ef5c0aaaeda735cf
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 32212897eeb8c2b2b3c74dbd44d842963084d808
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit c538d20c7f437e56c5301357c492230d1d6d1b80
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 9f9ac1e84a24670eea1430040e0aef278b4daffa
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit fcdca75728ac376f3de74376c791e1078ee83820
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Alan Cox <alan@linux.intel.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit edd70ad757e9b336116433e6e62de79ae1dfef54
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 7496ba309f2adbce74d917fbb8bd3da26222d49f
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 273558b3a0399e368d99da5b3daf1c0e11b93e06
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty
>>> >    changes)
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 8a60585159067f110075ef8ffda13abd94826daf
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >    commit 8384c9749f8c31c6e1e64a63c8d50af7863ce657
>>> >    Author: Govindraj.R <govindraj.raja@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.raja@ti.com>
>>> >        Signed-off-by: Kevin Hilman <khilman@ti.com>
>>> >
>>> >  -----------------------------------------------------------------------
>>> >    ------------------------------------------------------------------
>>> >
>>> >    regards
>>> >    keshava
>>> >
>>> >    On Wed, Jun 6, 2012 at 5:21 PM, Munegowda, Keshava
>>> >    <keshava_mgowda@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 <khilman@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<khilman@ti.com>  writes:
>>> >
>>> >      "Munegowda, Keshava"<keshava_mgowda@ti.com>  writes:
>>> >
>>> >      On Thu, May 24, 2012 at 5:55 AM, Kevin Hilman<khilman@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-15 12:04                     ` Munegowda, Keshava
@ 2012-06-15 13:47                       ` Jean Pihet
  2012-06-18  8:09                         ` Munegowda, Keshava
  0 siblings, 1 reply; 16+ messages in thread
From: Jean Pihet @ 2012-06-15 13:47 UTC (permalink / raw)
  To: Munegowda, Keshava; +Cc: Kevin Hilman, Ameya Palande, Felipe Balbi, linux-omap

Hi Keshava,

On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
<keshava_mgowda@ti.com> wrote:
> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
> <keshava_mgowda@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

You need the fix from
https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb

Hope this helps!

Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-15 13:47                       ` Jean Pihet
@ 2012-06-18  8:09                         ` Munegowda, Keshava
  2012-06-19 18:02                           ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-06-18  8:09 UTC (permalink / raw)
  To: Jean Pihet; +Cc: Kevin Hilman, Ameya Palande, Felipe Balbi, linux-omap

On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Hi Keshava,
>
> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
> <keshava_mgowda@ti.com> wrote:
>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>> <keshava_mgowda@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
>
> You need the fix from
> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>
> Hope this helps!
>
> Regards,
> Jean

thanks Jean
    I used this patch; this solved the crash issue, but suspend/resume
is still failing.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-18  8:09                         ` Munegowda, Keshava
@ 2012-06-19 18:02                           ` Kevin Hilman
  2012-06-20  6:23                             ` Munegowda, Keshava
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-06-19 18:02 UTC (permalink / raw)
  To: Munegowda, Keshava; +Cc: Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>> Hi Keshava,
>>
>> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
>> <keshava_mgowda@ti.com> wrote:
>>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>>> <keshava_mgowda@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
>>
>> You need the fix from
>> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>>
>> Hope this helps!
>>
>> Regards,
>> Jean
>
> thanks Jean
>     I used this patch; this solved the crash issue, but suspend/resume
> is still failing.

Failing in what way?  Did you debug any further?

It may be failing because of problems with the USB host driver, which is
what I'm needing you to debug.

I'm convinced now that these USB host PM changes were not very well
tested at all as they seem to be causing a variety of different problems
on my boards: faults during boot, preventing CORE idle retention,
hanging suspend/resume.

Anyways...

To get current l-o master to succesfully suspend/resume, you need 3 things:

1) the DSS fixes that Jean mentioned above (these are merged in
   v3.5-rc3, but not yet into l-o master)
2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
3) for for 32k timer which is also preventing CORE retention
   http://marc.info/?l=linux-omap&m=134000053229888&w=2

With that setup on top of current l-o master, suspend/resume is working
for me on several OMAP3/4 platforms.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-19 18:02                           ` Kevin Hilman
@ 2012-06-20  6:23                             ` Munegowda, Keshava
  2012-06-20  9:29                               ` Munegowda, Keshava
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-06-20  6:23 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman <khilman@ti.com> wrote:
> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>
>> On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>>> Hi Keshava,
>>>
>>> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
>>> <keshava_mgowda@ti.com> wrote:
>>>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>>>> <keshava_mgowda@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
>>>
>>> You need the fix from
>>> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>>>
>>> Hope this helps!
>>>
>>> Regards,
>>> Jean
>>
>> thanks Jean
>>     I used this patch; this solved the crash issue, but suspend/resume
>> is still failing.
>
> Failing in what way?  Did you debug any further?
>
> It may be failing because of problems with the USB host driver, which is
> what I'm needing you to debug.

The suspend/resume was failing even without USB in the mainline kernel image.

>
> I'm convinced now that these USB host PM changes were not very well
> tested at all as they seem to be causing a variety of different problems
> on my boards: faults during boot, preventing CORE idle retention,
> hanging suspend/resume.
>
> Anyways...
>
> To get current l-o master to succesfully suspend/resume, you need 3 things:
>
> 1) the DSS fixes that Jean mentioned above (these are merged in
>   v3.5-rc3, but not yet into l-o master)
> 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
> 3) for for 32k timer which is also preventing CORE retention
>   http://marc.info/?l=linux-omap&m=134000053229888&w=2
>
> With that setup on top of current l-o master, suspend/resume is working
> for me on several OMAP3/4 platforms.
>
> Kevin

Ok, I will test this.

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-20  6:23                             ` Munegowda, Keshava
@ 2012-06-20  9:29                               ` Munegowda, Keshava
  2012-06-20 14:23                                 ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-06-20  9:29 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
<keshava_mgowda@ti.com> wrote:
> On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman <khilman@ti.com> wrote:
>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>
>>> On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>>>> Hi Keshava,
>>>>
>>>> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
>>>> <keshava_mgowda@ti.com> wrote:
>>>>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>>>>> <keshava_mgowda@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
>>>>
>>>> You need the fix from
>>>> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>>>>
>>>> Hope this helps!
>>>>
>>>> Regards,
>>>> Jean
>>>
>>> thanks Jean
>>>     I used this patch; this solved the crash issue, but suspend/resume
>>> is still failing.
>>
>> Failing in what way?  Did you debug any further?
>>
>> It may be failing because of problems with the USB host driver, which is
>> what I'm needing you to debug.
>
> The suspend/resume was failing even without USB in the mainline kernel image.
>
>>
>> I'm convinced now that these USB host PM changes were not very well
>> tested at all as they seem to be causing a variety of different problems
>> on my boards: faults during boot, preventing CORE idle retention,
>> hanging suspend/resume.
>>
>> Anyways...
>>
>> To get current l-o master to succesfully suspend/resume, you need 3 things:
>>
>> 1) the DSS fixes that Jean mentioned above (these are merged in
>>   v3.5-rc3, but not yet into l-o master)
>> 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
>> 3) for for 32k timer which is also preventing CORE retention
>>   http://marc.info/?l=linux-omap&m=134000053229888&w=2
>>
>> With that setup on top of current l-o master, suspend/resume is working
>> for me on several OMAP3/4 platforms.
>>
>> Kevin
>

I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB
on beagle XM. but I can see that core retention in suspend/resume is
not working .
Apply , DSS fixes patch has resolved the the crash in suspend/resume,
but retention
is not entering.

 regards
 keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-20  9:29                               ` Munegowda, Keshava
@ 2012-06-20 14:23                                 ` Kevin Hilman
  2012-06-21  7:12                                   ` Munegowda, Keshava
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Hilman @ 2012-06-20 14:23 UTC (permalink / raw)
  To: Munegowda, Keshava; +Cc: Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

"Munegowda, Keshava" <keshava_mgowda@ti.com> writes:

> On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
> <keshava_mgowda@ti.com> wrote:
>> On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman <khilman@ti.com> wrote:
>>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>>
>>>> On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>>>>> Hi Keshava,
>>>>>
>>>>> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
>>>>> <keshava_mgowda@ti.com> wrote:
>>>>>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>>>>>> <keshava_mgowda@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
>>>>>
>>>>> You need the fix from
>>>>> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>>>>>
>>>>> Hope this helps!
>>>>>
>>>>> Regards,
>>>>> Jean
>>>>
>>>> thanks Jean
>>>>     I used this patch; this solved the crash issue, but suspend/resume
>>>> is still failing.
>>>
>>> Failing in what way?  Did you debug any further?
>>>
>>> It may be failing because of problems with the USB host driver, which is
>>> what I'm needing you to debug.
>>
>> The suspend/resume was failing even without USB in the mainline kernel image.
>>
>>>
>>> I'm convinced now that these USB host PM changes were not very well
>>> tested at all as they seem to be causing a variety of different problems
>>> on my boards: faults during boot, preventing CORE idle retention,
>>> hanging suspend/resume.
>>>
>>> Anyways...
>>>
>>> To get current l-o master to succesfully suspend/resume, you need 3 things:
>>>
>>> 1) the DSS fixes that Jean mentioned above (these are merged in
>>>   v3.5-rc3, but not yet into l-o master)
>>> 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
>>> 3) for for 32k timer which is also preventing CORE retention
>>>   http://marc.info/?l=linux-omap&m=134000053229888&w=2
>>>
>>> With that setup on top of current l-o master, suspend/resume is working
>>> for me on several OMAP3/4 platforms.
>>>
>>> Kevin
>>
>
> I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB
> on beagle XM. 

I suggested using l-o master as a baseline, not -rc2.

I just pushed a branch with this baseline so we are sure to be testing
the same baseline.  Please use the 'tmp/test/usb-host' branch from my
tree[1] as the starting point.

Build using omap2plus_defconfig, boot, then suspend/resume and send the output
of 'cat /debug/pm_debug/count'

This baseline is working fine for me on 3430/n900, 3530/Overo and
3630/Beagle-xM.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-20 14:23                                 ` Kevin Hilman
@ 2012-06-21  7:12                                   ` Munegowda, Keshava
  2012-06-21 10:47                                     ` Grazvydas Ignotas
  0 siblings, 1 reply; 16+ messages in thread
From: Munegowda, Keshava @ 2012-06-21  7:12 UTC (permalink / raw)
  To: Kevin Hilman; +Cc: Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

On Wed, Jun 20, 2012 at 7:53 PM, Kevin Hilman <khilman@ti.com> wrote:
> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>
>> On Wed, Jun 20, 2012 at 11:53 AM, Munegowda, Keshava
>> <keshava_mgowda@ti.com> wrote:
>>> On Tue, Jun 19, 2012 at 11:32 PM, Kevin Hilman <khilman@ti.com> wrote:
>>>> "Munegowda, Keshava" <keshava_mgowda@ti.com> writes:
>>>>
>>>>> On Fri, Jun 15, 2012 at 7:17 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
>>>>>> Hi Keshava,
>>>>>>
>>>>>> On Fri, Jun 15, 2012 at 2:04 PM, Munegowda, Keshava
>>>>>> <keshava_mgowda@ti.com> wrote:
>>>>>>> On Tue, Jun 12, 2012 at 6:28 PM, Munegowda, Keshava
>>>>>>> <keshava_mgowda@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
>>>>>>
>>>>>> You need the fix from
>>>>>> https://gitorious.org/linux-omap-dss2/linux/commit/9e0ca55fa5d9ff012964a7c7cef8af1b814b2fdb
>>>>>>
>>>>>> Hope this helps!
>>>>>>
>>>>>> Regards,
>>>>>> Jean
>>>>>
>>>>> thanks Jean
>>>>>     I used this patch; this solved the crash issue, but suspend/resume
>>>>> is still failing.
>>>>
>>>> Failing in what way?  Did you debug any further?
>>>>
>>>> It may be failing because of problems with the USB host driver, which is
>>>> what I'm needing you to debug.
>>>
>>> The suspend/resume was failing even without USB in the mainline kernel image.
>>>
>>>>
>>>> I'm convinced now that these USB host PM changes were not very well
>>>> tested at all as they seem to be causing a variety of different problems
>>>> on my boards: faults during boot, preventing CORE idle retention,
>>>> hanging suspend/resume.
>>>>
>>>> Anyways...
>>>>
>>>> To get current l-o master to succesfully suspend/resume, you need 3 things:
>>>>
>>>> 1) the DSS fixes that Jean mentioned above (these are merged in
>>>>   v3.5-rc3, but not yet into l-o master)
>>>> 2) disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n
>>>> 3) for for 32k timer which is also preventing CORE retention
>>>>   http://marc.info/?l=linux-omap&m=134000053229888&w=2
>>>>
>>>> With that setup on top of current l-o master, suspend/resume is working
>>>> for me on several OMAP3/4 platforms.
>>>>
>>>> Kevin
>>>
>>
>> I tired the linux2.3.5.rc2 + DSS fixes + sync 32k timer fix without USB
>> on beagle XM.
>
> I suggested using l-o master as a baseline, not -rc2.
>
> I just pushed a branch with this baseline so we are sure to be testing
> the same baseline.  Please use the 'tmp/test/usb-host' branch from my
> tree[1] as the starting point.
>
> Build using omap2plus_defconfig, boot, then suspend/resume and send the output
> of 'cat /debug/pm_debug/count'
>
> This baseline is working fine for me on 3430/n900, 3530/Overo and
> 3630/Beagle-xM.
>
> Kevin
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git


I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host'
I am seeing only the branch /wip/arm-nohz-cpusets other than master.
I didn't any usb-host branch here too:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary

regards
keshava
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-21  7:12                                   ` Munegowda, Keshava
@ 2012-06-21 10:47                                     ` Grazvydas Ignotas
  2012-06-21 18:32                                       ` Kevin Hilman
  0 siblings, 1 reply; 16+ messages in thread
From: Grazvydas Ignotas @ 2012-06-21 10:47 UTC (permalink / raw)
  To: Munegowda, Keshava
  Cc: Kevin Hilman, Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava
<keshava_mgowda@ti.com> wrote:
> I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host'
> I am seeing only the branch /wip/arm-nohz-cpusets other than master.
> I didn't any usb-host branch here too:
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary

It seems Kevin linked the wrong git tree, try this one:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git


-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: MFD USB host: prevents CORE retention in idle
  2012-06-21 10:47                                     ` Grazvydas Ignotas
@ 2012-06-21 18:32                                       ` Kevin Hilman
  0 siblings, 0 replies; 16+ messages in thread
From: Kevin Hilman @ 2012-06-21 18:32 UTC (permalink / raw)
  To: Grazvydas Ignotas
  Cc: Munegowda, Keshava, Jean Pihet, Ameya Palande, Felipe Balbi, linux-omap

Grazvydas Ignotas <notasas@gmail.com> writes:

> On Thu, Jun 21, 2012 at 10:12 AM, Munegowda, Keshava
> <keshava_mgowda@ti.com> wrote:
>> I did the clone of this , But I am not seeing the branch 'tmp/test/usb-host'
>> I am seeing only the branch /wip/arm-nohz-cpusets other than master.
>> I didn't any usb-host branch here too:
>> http://git.kernel.org/?p=linux/kernel/git/khilman/linux.git;a=summary
>
> It seems Kevin linked the wrong git tree, try this one:
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git

Oops, sorry.  

Grazvydas is right.  It's my linux-omap-pm tree that has this test
branch.

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-06-21 18:32 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-24  0:01 MFD USB host: prevents CORE retention in idle Kevin Hilman
2012-05-24  0:25 ` Kevin Hilman
2012-05-24  7:05   ` Munegowda, Keshava
2012-05-24 17:02     ` Kevin Hilman
2012-05-24 22:13       ` Kevin Hilman
2012-06-05 17:50         ` Kevin Hilman
     [not found]           ` <CAP05o4L+0E6fa1VoP_UPTJgKjXb-VqZorUfzsTB3d-KVoFrXfw@mail.gmail.com>
     [not found]             ` <CAP05o4KuoQHhTRTCtdpiywgC1HjwzXZHhROKOgSLhoK76Z2aaQ@mail.gmail.com>
     [not found]               ` <87fwa56gxp.fsf@ti.com>
     [not found]                 ` <CAP05o4JEEp-yXjijeeejN3j8uVBDQ35DMGqP9UKj3f7sNnO8LA@mail.gmail.com>
     [not found]                   ` <CAP05o4LYhFQpEFukyCT2fA7XHPU2L5K8=8W0fncMJk6YEUWdOQ@mail.gmail.com>
2012-06-15 12:04                     ` Munegowda, Keshava
2012-06-15 13:47                       ` Jean Pihet
2012-06-18  8:09                         ` Munegowda, Keshava
2012-06-19 18:02                           ` Kevin Hilman
2012-06-20  6:23                             ` Munegowda, Keshava
2012-06-20  9:29                               ` Munegowda, Keshava
2012-06-20 14:23                                 ` Kevin Hilman
2012-06-21  7:12                                   ` Munegowda, Keshava
2012-06-21 10:47                                     ` Grazvydas Ignotas
2012-06-21 18:32                                       ` Kevin Hilman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.