Problems with 3.4-rc5

Problems with 3.4-rc5

[Joe Woodward]

I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues...

Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have:

CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_HCD_OMAP=y

drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init':
drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430'
drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev'
drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function)
drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in

I'm assuming this has been spotted and I've missed the fix (just a missing include?).

Secondly, I get the following when booted:
...
[    4.701232] devtmpfs: mounted
[    4.704772] Freeing init memory: 168K
[    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay
...

Which means that the display doesn't work.

I am currently running 3.3, which works just fine and doesn't give an underflow.

So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime-
PM causing a similar issue, has anything changed around here again?

(as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it).

Cheers,
Joe Woodward

Re: Problems with 3.4-rc5

[Archit Taneja]

Hi,

On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote:
> I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo (AM3703), and have noticed a couple of issues...
>
> Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have:
>
> CONFIG_USB_EHCI_HCD=m
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> CONFIG_USB_EHCI_TT_NEWSCHED=y
> CONFIG_USB_EHCI_HCD_OMAP=y
>
> drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init':
> drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'cpu_is_omap3430'
> drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of function 'omap_rev'
> drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1' undeclared (first use in this function)
> drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier is reported only once for each function it appears in
>
> I'm assuming this has been spotted and I've missed the fix (just a missing include?).
>
> Secondly, I get the following when booted:
> ...
> [    4.701232] devtmpfs: mounted
> [    4.704772] Freeing init memory: 168K
> [    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay
> ...
>

Could you add some dss debug prints? You can add "omapdss.debug=1 debug" 
in the bootargs to get that.

There was a feature called fifo merge added in 3.4, this might lead to 
underflow, we had tested this using a DVI monitor on beagle but didn't 
see any underflows.

Are you trying this out on 3.4 for the first time? What was the last 
kernel revision on which you tested this and didn't see any issues?

Thanks,
Archit

> Which means that the display doesn't work.
>
> I am currently running 3.3, which works just fine and doesn't give an underflow.
>
> So was wondering what changes have been made that may affect this? There were problems in the 3.2-era due to runtime-
> PM causing a similar issue, has anything changed around here again?
>
> (as a side not: the panel I use is a custom 800x480 added to panel-generic-dpi.c, with board-overo.c updated to use it).
>
> Cheers,
> Joe Woodward
>
>
> --
> 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
>

Re: Problems with 3.4-rc5

[Joe Woodward]

-----Original Message-----
From: Archit Taneja <a0393947@ti.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: <linux-omap@vger.kernel.org>
Date: Wed, 2 May 2012 17:54:21 +0530
Subject: Re: Problems with 3.4-rc5

> Hi,
> 
> On Wednesday 02 May 2012 05:22 PM, Joe Woodward wrote:
> > I've just given 3.4-rc5 a quick run-through on my GUMSTIX Overo
> (AM3703), and have noticed a couple of issues...
> >
> > Firstly, it fails to build "drivers/mfd/omap-usb-host.c" if you have:
> >
> > CONFIG_USB_EHCI_HCD=m
> > CONFIG_USB_EHCI_ROOT_HUB_TT=y
> > CONFIG_USB_EHCI_TT_NEWSCHED=y
> > CONFIG_USB_EHCI_HCD_OMAP=y
> >
> > drivers/mfd/omap-usb-host.c: In function 'omap_usbhs_init':
> > drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of
> function 'cpu_is_omap3430'
> > drivers/mfd/omap-usb-host.c:524:3: error: implicit declaration of
> function 'omap_rev'
> > drivers/mfd/omap-usb-host.c:524:43: error: 'OMAP3430_REV_ES2_1'
> undeclared (first use in this function)
> > drivers/mfd/omap-usb-host.c:524:43: note: each undeclared identifier
> is reported only once for each function it appears in
> >
> > I'm assuming this has been spotted and I've missed the fix (just a
> missing include?).
> >
> > Secondly, I get the following when booted:
> > ...
> > [    4.701232] devtmpfs: mounted
> > [    4.704772] Freeing init memory: 168K
> > [    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
> the overlay
> > ...
> >
> 
> Could you add some dss debug prints? You can add "omapdss.debug=1
> debug" 
> in the bootargs to get that.
> 
> There was a feature called fifo merge added in 3.4, this might lead to 
> underflow, we had tested this using a DVI monitor on beagle but didn't 
> see any underflows.
> 
> Are you trying this out on 3.4 for the first time? What was the last 
> kernel revision on which you tested this and didn't see any issues?


See below for a more complete trace with debug enabled.

I have been using 3.3.0, which doesn't give me any DSS underflow problems at all.

And yes, this is the first time I've tried anything 3.4-based.

For reference, I'm running from a RAM-based file system which is the same as I use on 3.3.0.

Cheers,
Joe

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #4 SMP Wed May 2 12:43:38 BST 2012
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Gumstix Overo
[    0.000000] Reserving 8388608 bytes SDRAM for VRAM
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 128768
[    0.000000] free_area_init_node: node 0, pgdat c06f4740, node_mem_map c7000000
[    0.000000]   Normal zone: 1024 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 127744 pages, LIFO batch:31
[    0.000000] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[    0.000000] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192 d13056 u32768
[    0.000000] pcpu-alloc: s11520 r8192 d13056 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 127744
[    0.000000] Kernel command line: console=ttyO2,115200 omapfb.rotate=0 omapdss.debug=1 debug root=/dev/ram0 rw ramdisk_size=98304 
initrd=0x81000000,96M rootfstype=squashfs
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 503MB = 503MB total
[    0.000000] Memory: 399616k/399616k available, 124672k 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 : 0xe0800000 - 0xff000000   ( 488 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0614f30   (6196 kB)
[    0.000000]       .init : 0xc0615000 - 0xc0662d00   ( 312 kB)
[    0.000000]       .data : 0xc0664000 - 0xc06f63d8   ( 585 kB)
[    0.000000]        .bss : 0xc06f63fc - 0xc0c4c020   (5464 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] 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.000854] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720)
[    0.085968] pid_max: default: 32768 minimum: 301
[    0.086669] Security Framework initialized
[    0.086944] Mount-cache hash table entries: 512
[    0.091857] CPU: Testing write buffer coherency: ok
[    0.092712] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.092773] Setting up static identity map for 0x80469f88 - 0x80469ff8
[    0.094421] Brought up 1 CPUs
[    0.094451] SMP: Total of 1 processors activated (597.64 BogoMIPS).
[    0.097656] devtmpfs: initialized
[    0.107910] ttyO2 used as console in debug mode uart2 clocks will not be gated
[    0.117309] dummy:
[    0.119415] NET: Registered protocol family 16
[    0.120605] GPMC revision 5.0
[    0.129852] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.130371] OMAP GPIO hardware version 2.5
[    0.131469] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.133270] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.134704] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.136108] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
[    0.137481] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
[    0.144836] omap_mux_init: Add partition: #1: core, flags: 0
[    0.159606] Reprogramming SDRC clock to 400000000 Hz
[    0.159637] dpll3_m2_clk rate change failed: -22
[    0.159637] NAND: Unable to find configuration in GPMC
[    0.159637]
[    0.174530] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.189086]  omap-mcbsp.2: alias fck already exists
[    0.189849]  omap-mcbsp.3: alias fck already exists
[    0.194091] OMAP DMA hardware revision 5.0
[    0.261291] bio: create slab <bio-0> at 0
[    0.264801] fixed-dummy:
[    0.266174] vads7846: 3300 mV
[    0.271728] SCSI subsystem initialized
[    0.273986] omap2_mcspi omap2_mcspi.1: master is unqueued, this is deprecated
[    0.276733] omap2_mcspi omap2_mcspi.2: master is unqueued, this is deprecated
[    0.277862] omap2_mcspi omap2_mcspi.3: master is unqueued, this is deprecated
[    0.278961] omap2_mcspi omap2_mcspi.4: master is unqueued, this is deprecated
[    0.282440] usbcore: registered new interface driver usbfs
[    0.283477] usbcore: registered new interface driver hub
[    0.284118] usbcore: registered new device driver usb
[    0.297576] omap_i2c omap_i2c.1: bus 1 rev1.4.0 at 2600 kHz
[    0.307006] twl 1-0048: PIH (irq 7) chaining IRQs 320..328
[    0.307647] twl 1-0048: power (irq 325) chaining IRQs 328..335
[    0.310028] twl4030_gpio twl4030_gpio: gpio (irq 320) chaining IRQs 336..353
[    0.311431] gpiochip_add: registered GPIOs 192 to 211 on device: twl4030
[    0.317047] VMMC1: 1850 <--> 3150 mV at 3150 mV normal standby
[    0.319335] VDAC: 1800 mV normal standby
[    0.321685] VDVI: 1800 mV normal standby
[    0.336181] omap_i2c omap_i2c.3: bus 3 rev1.4.0 at 400 kHz
[    0.344543] Switching to clocksource 32k_counter
[    0.467407] NET: Registered protocol family 2
[    0.468292] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.470916] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    0.471618] TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
[    0.480651] TCP: Hash tables configured (established 16384 bind 16384)
[    0.480743] TCP: reno registered
[    0.480804] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.481109] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.482086] NET: Registered protocol family 1
[    0.483520] RPC: Registered named UNIX socket transport module.
[    0.483551] RPC: Registered udp transport module.
[    0.483581] RPC: Registered tcp transport module.
[    0.483581] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.484374] Trying to unpack rootfs image as initramfs...
[    0.485504] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[    1.099151] Freeing initrd memory: 98304K
[    1.099334] NetWinder Floating Point Emulator V0.97 (double precision)
[    1.263275] VFS: Disk quotas dquot_6.5.2
[    1.263610] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.265106] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.265289] NFS: Registering the id_resolver key type
[    1.267211] msgmni has been set to 972
[    1.270568] io scheduler noop registered
[    1.270599] io scheduler deadline registered
[    1.270812] io scheduler cfq registered (default)
[    1.275726] omapdss DSS: dss_runtime_get
[    1.275787] omapdss DSS: dss_restore_context
[    1.275817] OMAP DSS rev 2.0
[    1.275817] omapdss DSS: dss_runtime_put
[    1.275878] omapdss DSS: dss_save_context
[    1.275909] omapdss DSS: context saved
[    1.276794] omapdss DISPC: dispc_runtime_get
[    1.276855] omapdss DSS: dss_runtime_get
[    1.276885] omapdss DSS: dss_restore_context
[    1.276885] omapdss DSS: context restored
[    1.276916] omapdss DISPC: dispc_restore_context
[    1.277099] omapdss DISPC: dispc_runtime_put
[    1.277130] omapdss DISPC: dispc_save_context
[    1.277191] omapdss DISPC: context saved, ctx_loss_count 0
[    1.277221] omapdss DSS: dss_runtime_put
[    1.277252] omapdss DSS: dss_save_context
[    1.277252] omapdss DSS: context saved
[    1.278137] omapdss RFBI: rfbi_runtime_get
[    1.278198] omapdss DSS: dss_runtime_get
[    1.278228] omapdss DSS: dss_restore_context
[    1.278228] omapdss DSS: context restored
[    1.278259] omapdss DISPC: dispc_runtime_get
[    1.278289] omapdss DSS: dss_runtime_get
[    1.278289] omapdss DISPC: dispc_restore_context
[    1.298217] omapdss RFBI: rfbi_runtime_put
[    1.298278] omapdss DISPC: dispc_runtime_put
[    1.298309] omapdss DISPC: dispc_save_context
[    1.298370] omapdss DISPC: context saved, ctx_loss_count 0
[    1.298370] omapdss DSS: dss_runtime_put
[    1.298431] omapdss DSS: dss_runtime_put
[    1.298461] omapdss DSS: dss_save_context
[    1.298461] omapdss DSS: context saved
[    1.299285] omapdss VENC: venc_runtime_get
[    1.299316] omapdss DSS: dss_runtime_get
[    1.299377] omapdss DSS: dss_restore_context
[    1.299377] omapdss DSS: context restored
[    1.299407] omapdss DISPC: dispc_runtime_get
[    1.299438] omapdss DSS: dss_runtime_get
[    1.299438] omapdss DISPC: dispc_restore_context
[    1.299468] omapdss VENC: venc_runtime_put
[    1.299530] omapdss CORE: bus_match. dev display0/generic_dpi_panel, drv venc
[    1.300079] omapdss DISPC: dispc_runtime_put
[    1.300079] omapdss DISPC: dispc_save_context
[    1.300140] omapdss DISPC: context saved, ctx_loss_count 0
[    1.300170] omapdss DSS: dss_runtime_put
[    1.300201] omapdss DSS: dss_runtime_put
[    1.300231] omapdss DSS: dss_save_context
[    1.300231] omapdss DSS: context saved
[    1.301147] omapdss DSI: dsi_runtime_get
[    1.301208] omapdss DSS: dss_runtime_get
[    1.301239] omapdss DSS: dss_restore_context
[    1.301239] omapdss DSS: context restored
[    1.301269] omapdss DISPC: dispc_runtime_get
[    1.301300] omapdss DSS: dss_runtime_get
[    1.301300] omapdss DISPC: dispc_restore_context
[    1.301330] omapdss DSI: dsi_runtime_put
[    1.301391] omapdss DISPC: dispc_runtime_put
[    1.301422] omapdss DISPC: dispc_save_context
[    1.301452] omapdss DISPC: context saved, ctx_loss_count 0
[    1.301483] omapdss DSS: dss_runtime_put
[    1.301513] omapdss DSS: dss_runtime_put
[    1.301544] omapdss DSS: dss_save_context
[    1.301544] omapdss DSS: context saved
[    1.302825] omapdss CORE: bus_match. dev display0/generic_dpi_panel, drv generic_dpi_panel
[    1.302917] omapdss CORE: driver_probe: dev display0/generic_dpi_panel, drv generic_dpi_panel
[    1.302917] omapdss DPI: init_display
[    1.303833] omapdss DISPC: dispc_runtime_get
[    1.303894] omapdss DSS: dss_runtime_get
[    1.303924] omapdss DSS: dss_restore_context
[    1.303955] omapdss DSS: context restored
[    1.303955] omapdss DISPC: dispc_restore_context
[    1.304077] omapdss DISPC: dispc_runtime_put
[    1.304107] omapdss DISPC: dispc_save_context
[    1.304168] omapdss DISPC: context saved, ctx_loss_count 0
[    1.304199] omapdss DSS: dss_runtime_put
[    1.304199] omapdss DSS: dss_save_context
[    1.304229] omapdss DSS: context saved
[    1.304290] omapdss CORE: probe done for device display0
[    1.305816] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    1.313018] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
[    1.315521] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
[    1.317077] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
[    2.428833] console [ttyO2] enabled
[    2.434326] omap_uart.3: ttyO3 at MMIO 0x49042000 (irq = 80) is a OMAP UART3
[    2.478302] brd: module loaded
[    2.502929] loop: module loaded
[    2.514190] mtdoops: mtd device (mtddev=name/number) must be supplied
[    2.522094] OneNAND driver initializing
[    2.532806] smsc911x: Driver version 2008-10-21
[    2.539978] smsc911x: Driver version 2008-10-21
[    2.547790] usbcore: registered new interface driver asix
[    2.554199] usbcore: registered new interface driver cdc_ether
[    2.561004] usbcore: registered new interface driver net1080
[    2.567596] usbcore: registered new interface driver cdc_subset
[    2.574432] usbcore: registered new interface driver zaurus
[    2.580963] usbcore: registered new interface driver cdc_ncm
[    2.589324] usbcore: registered new interface driver cdc_wdm
[    2.595428] Initializing USB Mass Storage driver...
[    2.601165] usbcore: registered new interface driver usb-storage
[    2.607635] USB Mass Storage support registered.
[    2.613677] usbcore: registered new interface driver libusual
[    2.620452] usbcore: registered new interface driver usbtest
[    2.628662] mousedev: PS/2 mouse device common for all mice
[    2.639648] ads7846 spi1.0: touchscreen, irq 210
[    2.647399] input: ADS7846 Touchscreen as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input0
[    2.663818] input: twl4030_pwrbutton as /devices/platform/omap_i2c.1/i2c-1/1-0049/twl4030_pwrbutton/input/input1
[    2.676635] twl_rtc twl_rtc: Power up reset detected.
[    2.682312] twl_rtc twl_rtc: Enabling TWL-RTC
[    2.691192] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[    2.699127] i2c /dev entries driver
[    2.706207] Driver for 1-wire Dallas network protocol.
[    2.715270] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[    2.723785] twl4030_wdt twl4030_wdt: Failed to register misc device
[    2.730621] twl4030_wdt: probe of twl4030_wdt failed with error -16
[    2.963989] usbcore: registered new interface driver usbhid
[    2.969879] usbhid: USB HID core driver
[    2.974090] oprofile: hardware counters not available
[    2.979461] oprofile: using timer interrupt.
[    2.984863] TCP: cubic registered
[    2.988464] Initializing XFRM netlink socket
[    2.993103] NET: Registered protocol family 17
[    2.997955] NET: Registered protocol family 15
[    3.003479] Registering the dns_resolver key type
[    3.008728] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    3.017059] ThumbEE CPU extension supported.
[    3.065826] clock: disabling unused clocks to save power
[    3.085449] omapdss APPLY: omap_dss_mgr_apply(lcd)
[    3.089996] Console: switching to colour frame buffer device 100x30
[    3.108276] omapdss APPLY: omap_dss_mgr_apply(lcd)
[    3.113586] omapdss APPLY: omap_dss_mgr_apply(lcd)
[    3.118713] omapdss APPLY: omap_dss_mgr_apply(tv)
[    3.123962] omapdss DSS: dss_runtime_get
[    3.128295] omapdss DSS: dss_restore_context
[    3.132812] omapdss DSS: context restored
[    3.137084] omapdss DISPC: dispc_runtime_get
[    3.141601] omapdss DSS: dss_runtime_get
[    3.145812] omapdss DISPC: dispc_restore_context
[    3.150726] omapdss DISPC: onoff 0 rf 0 ieo 0 ipc 0 ihs 1 ivs 1 acbi 0 acb 0
[    3.158264] omapdss DSS: dpll4_m4 = 864000000
[    3.162872] omapdss DSS: fck = 36000000 (24)
[    3.167419] omapdss DISPC: lck = 36000000 (1)
[    3.172027] omapdss DISPC: pck = 36000000 (1)
[    3.176666] omapdss DISPC: channel 0 xres 800 yres 480
[    3.182128] omapdss DISPC: pck 36000
[    3.185913] omapdss DISPC: hsw 10 hfp 164 hbp 89 vsw 10 vfp 10 vbp 23
[    3.192749] omapdss DISPC: hsync 33866Hz, vsync 64Hz
[    3.200042] omapdss DISPC: FIFO merge enabled
[    3.204620] omapdss APPLY: dss_mgr_write_regs(0)
[    3.209503] omapdss APPLY: dss_ovl_write_regs(0)
[    3.214385] omapdss DISPC: dispc_ovl_setup 0, pa 9f800000, pa_uv 0, sw 800, 0,0, 800x480 -> 800x480, cmode 40, rot 0, mir 0, ilace 0 chan 0 repl 1
[    3.228240] omapdss DISPC: calc_rot(0): scrw 800, 800x480
[    3.233917] omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
[    3.240722] omapdss DISPC: 0,0 800x480 -> 800x480
[    3.245697] omapdss APPLY: dss_ovl_write_regs_extra(0)
[    3.251098] omapdss DISPC: dispc_enable_plane 0, 1
[    3.256164] omapdss DISPC: fifo(0) threshold (bytes), old 960/1023, new 896/3008
[    3.263977] omapdss APPLY: dss_ovl_write_regs(1)
[    3.268829] omapdss APPLY: dss_ovl_write_regs_extra(1)
[    3.274261] omapdss DISPC: dispc_enable_plane 1, 0
[    3.279296] omapdss DISPC: fifo(1) threshold (bytes), old 960/1023, new 0/0
[    3.286651] omapdss APPLY: dss_ovl_write_regs(2)
[    3.291503] omapdss APPLY: dss_ovl_write_regs_extra(2)
[    3.296936] omapdss DISPC: dispc_enable_plane 2, 0
[    3.302001] omapdss DISPC: fifo(2) threshold (bytes), old 960/1023, new 0/0
[    3.317657] VDAC: incomplete constraints, leaving on
[    3.325897] input: gpio-keys as /devices/platform/gpio-keys/input/input2
[    3.340087] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:10 UTC (946684810)
[    3.352264] RAMDISK: squashfs filesystem found at block 0
[    3.358154] RAMDISK: Loading 49972KiB [1 disk] into ram disk... \
[    3.450561] mmc0: host does not support reading read-only switch. assuming write-enable.
[    3.459838] |
[    3.470581] mmc0: new high speed SDHC card at address 0001
[    3.478485] \
[    3.487304] mmcblk0: mmc0:0001 00000 29.2 GiB
[    3.493865] -
[    3.516296]  mmcblk0: p1
[    3.521087] /
[    3.610717] mmc1: new SDIO card at address 0001
[    3.616546] done.
[    5.950683] VFS: Mounted root (squashfs filesystem) readonly on device 1:0.
[    5.960449] devtmpfs: mounted
[    5.964263] Freeing init memory: 308K
[    6.123443] DISPC IRQ: 0x100e2: GFX_FIFO_UNDERFLOW
[    6.129302] omapdss DISPC: dispc_runtime_get
[    6.133819] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the overlay
[    6.141662] omapdss DISPC: dispc_enable_plane 0, 0
[    6.146759] omapdss DISPC: GO LCD
[    6.200408] omapdss DISPC: dispc_runtime_put
Starting logging: OK
Populating  using udev: done
[    6.435211] udevd[575]: starting version 175


> 
> Thanks,
> Archit
> 
> > Which means that the display doesn't work.
> >
> > I am currently running 3.3, which works just fine and doesn't give an
> underflow.
> >
> > So was wondering what changes have been made that may affect this?
> There were problems in the 3.2-era due to runtime-
> > PM causing a similar issue, has anything changed around here again?
> >
> > (as a side not: the panel I use is a custom 800x480 added to
> panel-generic-dpi.c, with board-overo.c updated to use it).
> >
> > Cheers,
> > Joe Woodward
> >
> >
> > --
> > 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
> >
> 
> --
> 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

Re: Problems with 3.4-rc5

[Tomi Valkeinen]

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

On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:

> > > Secondly, I get the following when booted:
> > > ...
> > > [    4.701232] devtmpfs: mounted
> > > [    4.704772] Freeing init memory: 168K
> > > [    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
> > the overlay
> > > ...
> > >
> > 
> > Could you add some dss debug prints? You can add "omapdss.debug=1
> > debug" 
> > in the bootargs to get that.
> > 
> > There was a feature called fifo merge added in 3.4, this might lead to 
> > underflow, we had tested this using a DVI monitor on beagle but didn't 
> > see any underflows.
> > 
> > Are you trying this out on 3.4 for the first time? What was the last 
> > kernel revision on which you tested this and didn't see any issues?

Can you try the following changes (separately):


diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..aca4eb1 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
 	 * combined fifo size
 	 */
 
-	if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
-		*fifo_low = ovl_fifo_size - burst_size * 2;
-		*fifo_high = total_fifo_size - burst_size;
-	} else {
-		*fifo_low = ovl_fifo_size - burst_size;
-		*fifo_high = total_fifo_size - buf_unit;
-	}
+	*fifo_low = ovl_fifo_size - burst_size;
+	*fifo_high = total_fifo_size - buf_unit;
 }
 
 static void dispc_ovl_set_fir(enum omap_plane plane,

---

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee30937..d63f1a3 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
 	burst_size = dispc_ovl_get_burst_size(plane);
 	ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
 
-	if (use_fifomerge) {
-		total_fifo_size = 0;
-		for (i = 0; i < omap_dss_get_num_overlays(); ++i)
-			total_fifo_size += dispc_ovl_get_fifo_size(i);
-	} else {
-		total_fifo_size = ovl_fifo_size;
-	}
+	total_fifo_size = ovl_fifo_size;
 
 	/*
 	 * We use the same low threshold for both fifomerge and non-fifomerge

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Problems with 3.4-rc5

[Joe Woodward]

-----Original Message-----
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 11:28:41 +0300
Subject: Re: Problems with 3.4-rc5

> On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
> 
> > > > Secondly, I get the following when booted:
> > > > ...
> > > > [    4.701232] devtmpfs: mounted
> > > > [    4.704772] Freeing init memory: 168K
> > > > [    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx,
> disabling
> > > the overlay
> > > > ...
> > > >
> > > 
> > > Could you add some dss debug prints? You can add "omapdss.debug=1
> > > debug" 
> > > in the bootargs to get that.
> > > 
> > > There was a feature called fifo merge added in 3.4, this might lead
> to 
> > > underflow, we had tested this using a DVI monitor on beagle but
> didn't 
> > > see any underflows.
> > > 
> > > Are you trying this out on 3.4 for the first time? What was the
> last 
> > > kernel revision on which you tested this and didn't see any issues?
> 
> Can you try the following changes (separately):
> 
> 
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index ee30937..aca4eb1 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum
> omap_plane plane,
>  	 * combined fifo size
>  	 */
>  
> -	if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
> -		*fifo_low = ovl_fifo_size - burst_size * 2;
> -		*fifo_high = total_fifo_size - burst_size;
> -	} else {
> -		*fifo_low = ovl_fifo_size - burst_size;
> -		*fifo_high = total_fifo_size - buf_unit;
> -	}
> +	*fifo_low = ovl_fifo_size - burst_size;
> +	*fifo_high = total_fifo_size - buf_unit;
>  }
>  
>  static void dispc_ovl_set_fir(enum omap_plane plane,
> 
> ---

The above patch fixes the problem (I no longer see any underflows).


> 
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index ee30937..d63f1a3 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum
> omap_plane plane,
>  	burst_size = dispc_ovl_get_burst_size(plane);
>  	ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
>  
> -	if (use_fifomerge) {
> -		total_fifo_size = 0;
> -		for (i = 0; i < omap_dss_get_num_overlays(); ++i)
> -			total_fifo_size += dispc_ovl_get_fifo_size(i);
> -	} else {
> -		total_fifo_size = ovl_fifo_size;
> -	}
> +	total_fifo_size = ovl_fifo_size;
>  
>  	/*
>  	 * We use the same low threshold for both fifomerge and non-fifomerge
> 

The above patch has no effect (I still see underflows).

Both patches together results in slightly different behaviour, the display is still broken- 
it flickers on and off with occassional underflows before breaking completely.

Cheers,
Joe

>  Tomi
> 

Re: Problems with 3.4-rc5

[Archit Taneja]

On Thursday 03 May 2012 02:19 PM, Joe Woodward wrote:
> -----Original Message-----
> From: Tomi Valkeinen<tomi.valkeinen@ti.com>
> To: Joe Woodward<jw@terrafix.co.uk>
> Cc: Archit Taneja<a0393947@ti.com>, linux-omap@vger.kernel.org
> Date: Thu, 03 May 2012 11:28:41 +0300
> Subject: Re: Problems with 3.4-rc5
>
>> On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
>>
>>>>> Secondly, I get the following when booted:
>>>>> ...
>>>>> [    4.701232] devtmpfs: mounted
>>>>> [    4.704772] Freeing init memory: 168K
>>>>> [    4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx,
>> disabling
>>>> the overlay
>>>>> ...
>>>>>
>>>>
>>>> Could you add some dss debug prints? You can add "omapdss.debug=1
>>>> debug"
>>>> in the bootargs to get that.
>>>>
>>>> There was a feature called fifo merge added in 3.4, this might lead
>> to
>>>> underflow, we had tested this using a DVI monitor on beagle but
>> didn't
>>>> see any underflows.
>>>>
>>>> Are you trying this out on 3.4 for the first time? What was the
>> last
>>>> kernel revision on which you tested this and didn't see any issues?
>>
>> Can you try the following changes (separately):
>>
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c
>> b/drivers/video/omap2/dss/dispc.c
>> index ee30937..aca4eb1 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -1091,13 +1091,8 @@ void dispc_ovl_compute_fifo_thresholds(enum
>> omap_plane plane,
>>   	 * combined fifo size
>>   	 */
>>
>> -	if (dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
>> -		*fifo_low = ovl_fifo_size - burst_size * 2;
>> -		*fifo_high = total_fifo_size - burst_size;
>> -	} else {
>> -		*fifo_low = ovl_fifo_size - burst_size;
>> -		*fifo_high = total_fifo_size - buf_unit;
>> -	}
>> +	*fifo_low = ovl_fifo_size - burst_size;
>> +	*fifo_high = total_fifo_size - buf_unit;
>>   }
>>
>>   static void dispc_ovl_set_fir(enum omap_plane plane,
>>
>> ---
>
> The above patch fixes the problem (I no longer see any underflows).

Tomi,

Before FIFO merge was added, the special fifo_low/high calculation was 
only done for DSI on OMAP3, now it seems to be done on OMAP3 and for all 
interfaces. Maybe this is the difference between 3.3.

>
>
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c
>> b/drivers/video/omap2/dss/dispc.c
>> index ee30937..d63f1a3 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -1077,13 +1077,7 @@ void dispc_ovl_compute_fifo_thresholds(enum
>> omap_plane plane,
>>   	burst_size = dispc_ovl_get_burst_size(plane);
>>   	ovl_fifo_size = dispc_ovl_get_fifo_size(plane);
>>
>> -	if (use_fifomerge) {
>> -		total_fifo_size = 0;
>> -		for (i = 0; i<  omap_dss_get_num_overlays(); ++i)
>> -			total_fifo_size += dispc_ovl_get_fifo_size(i);
>> -	} else {
>> -		total_fifo_size = ovl_fifo_size;
>> -	}
>> +	total_fifo_size = ovl_fifo_size;
>>
>>   	/*
>>   	 * We use the same low threshold for both fifomerge and non-fifomerge
>>
>
> The above patch has no effect (I still see underflows).
>
> Both patches together results in slightly different behaviour, the display is still broken-
> it flickers on and off with occassional underflows before breaking completely.

With both the patches combined, we are configuring DSS with FIFO merge 
enabled, but configuring thresholds normally and not utilising the large 
FIFO. Getting underflows with this is strange, because it's more or less 
similar to what it was on 3.3 without FIFO merge.

Archit

>
> Cheers,
> Joe
>
>>   Tomi
>>
>
>
>

Re: Problems with 3.4-rc5

[Tomi Valkeinen]

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

On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:

> Both patches together results in slightly different behaviour, the display is still broken- 
> it flickers on and off with occassional underflows before breaking completely.

Beagle works fine for me with omap2plus based config, and I think overo
also although I can't test it now as I broke my micro mmc adapter.

Can you send your panel definition? Any other things that could affect
display? Do you have PM enabled? Can you share your kernel config?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Problems with 3.4-rc5

[Joe Woodward]

-----Original Message-----
 From: Tomi Valkeinen <tomi.valkeinen@ti.com>
 To: Joe Woodward <jw@terrafix.co.uk>
 Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
 Date: Thu, 03 May 2012 16:07:22 +0300
 Subject: Re: Problems with 3.4-rc5
 
> On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
 > 
> > Both patches together results in slightly different behaviour, the
 > display is still broken- 
> > it flickers on and off with occassional underflows before breaking
 > completely.
 > 
> Beagle works fine for me with omap2plus based config, and I think overo
 > also although I can't test it now as I broke my micro mmc adapter.
 > 
> Can you send your panel definition? Any other things that could affect
 > display? Do you have PM enabled? Can you share your kernel config?
 > 
>  Tomi
 > 

I've gone back to a test setup others can replicate.
 
I have a GUSMTIX Overo Earth (OMAP3503-based), running in a 
Chestnut43 board with a connect 4.3" Samsung LCD panel (480x320).
 
(my previous emails were using a GUMSTIX Overo AirSTORM (AM3703), 
but the results seem to be the same with the Earth)
 
I've built stock 3.4-rc5 using the omap2plus_defconfig (using the 
CodeSorcery toolchain: arm-2010.09-50-arm-none-linux-gnueabi.bin).
 
I've had to make the following changes to the defconfig for my RFS (I've 
attached the defconfig for reference):
 CONFIG_OMAP2_DSS=y
 CONFIG_OMAP2_VRAM_SIZE=4
 CONFIG_FB_OMAP2=y
 CONFIG_PANEL_GENERIC_DPI=y
 CONFIG_TUN=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_SQUASHFS=y
 
I've also set the LCD to the default display device in board-overo.c:
 static struct omap_dss_board_info overo_dss_data = {
    .num_devices   = ARRAY_SIZE
 (overo_dss_devices),
    .devices   = overo_dss_devices,
    .default_device   = &overo_lcd43_device, /* @@ 
Default to LCD*/
 };
 
I'm booting using uBoot 2012.04.01, and run everything from RAM.
 
When booting I can see the Linux boot logo for a short time.
 
The log is pasted below, but you can see:
 [    6.621215] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling 
the overlay
 
Cheers,
 Joe
 


Uncompressing Linux... done, booting the kernel.
 [    0.000000] Booting Linux on physical CPU 0
 [    0.000000] Linux version 3.4.0-rc5 (joe@joe-VirtualBox) (gcc version 
4.5.1 (Sourcery G++ Lite 2010.09-50) ) #6 SMP Thu May 3 15:38:04 BST 
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] Reserving 4194304 bytes SDRAM for VRAM
 [    0.000000] Memory policy: ECC disabled, Data cache writeback
 [    0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
 [    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
 [    0.000000] PERCPU: Embedded 8 pages/cpu @c7408000 s11520 r8192 
d13056 u32768
 [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 128768
 [    0.000000] Kernel command line: console=ttyO2,115200 
omapfb.rotate=0 root=/dev/ram0 rw ramdisk_size=98304 
initrd=0x81000000,96M rootfstype=squashfs
 [    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
 [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 
bytes)
 [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes)
 [    0.000000] Memory: 507MB = 507MB total
 [    0.000000] Memory: 403416k/403416k available, 120872k 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 : 0xe0800000 - 0xff000000   ( 488 MB)
 [    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
 [    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
 [    0.000000]       .text : 0xc0008000 - 0xc065e058   (6489 kB)
 [    0.000000]       .init : 0xc065f000 - 0xc06acd00   ( 312 kB)
 [    0.000000]       .data : 0xc06ae000 - 0xc0740d18   ( 588 kB)
 [    0.000000]        .bss : 0xc0740d3c - 0xc0c96b20   (5464 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] 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.000946] Calibrating delay loop... 594.49 BogoMIPS (lpj=2322432)
 [    0.085937] pid_max: default: 32768 minimum: 301
 [    0.086761] Security Framework initialized
 [    0.087066] Mount-cache hash table entries: 512
 [    0.092529] CPU: Testing write buffer coherency: ok
 [    0.093566] CPU0: thread -1, cpu 0, socket -1, mpidr 0
 [    0.093658] Setting up static identity map for 0x804a5888 - 0x804a58f8
 [    0.095794] Brought up 1 CPUs
 [    0.095825] SMP: Total of 1 processors activated (594.49 BogoMIPS).
 [    0.099487] devtmpfs: initialized
 [    0.121551] dummy:
 [    0.123931] NET: Registered protocol family 16
 [    0.125549] GPMC revision 5.0
 [    0.136993] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
 [    0.137573] OMAP GPIO hardware version 2.5
 [    0.138824] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
 [    0.140502] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
 [    0.142517] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
 [    0.144104] gpiochip_add: registered GPIOs 128 to 159 on device: gpio
 [    0.145660] gpiochip_add: registered GPIOs 160 to 191 on device: gpio
 [    0.154357] omap_mux_init: Add partition: #1: core, flags: 0
 [    0.170623] Reprogramming SDRC clock to 332000000 Hz
 [    0.170715] NAND: Unable to find configuration in GPMC
 [    0.170715]
 [    0.186828] hw-breakpoint: debug architecture 0x4 unsupported.
 [    0.204162]  omap-mcbsp.2: alias fck already exists
 [    0.205047]  omap-mcbsp.3: alias fck already exists
 [    0.209991] OMAP DMA hardware revision 4.0
 [    0.289672] bio: create slab <bio-0> at 0
 [    0.293884] fixed-dummy:
 [    0.295196] vads7846: 3300 mV
 [    0.302124] SCSI subsystem initialized
 [    0.304412] omap2_mcspi omap2_mcspi.1: master is unqueued, this is 
deprecated
 [    0.308013] omap2_mcspi omap2_mcspi.2: master is unqueued, this is 
deprecated
 [    0.309326] omap2_mcspi omap2_mcspi.3: master is unqueued, this is 
deprecated
 [    0.310607] omap2_mcspi omap2_mcspi.4: master is unqueued, this is 
deprecated
 [    0.314727] usbcore: registered new interface driver usbfs
 [    0.315948] usbcore: registered new interface driver hub
 [    0.316680] usbcore: registered new device driver usb
 [    0.328979] omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 2600 kHz
 [    0.339752] twl 1-0048: PIH (irq 7) chaining IRQs 320..328
 [    0.340454] twl 1-0048: power (irq 325) chaining IRQs 328..335
 [    0.343139] twl4030_gpio twl4030_gpio: gpio (irq 320) chaining IRQs 
336..353
 [    0.345214] gpiochip_add: registered GPIOs 192 to 211 on device: 
twl4030
 [    0.351074] VMMC1: 1850 <--> 3150 mV at 3150 mV normal standby
 [    0.353881] VDAC: 1800 mV normal standby
 [    0.356292] VDVI: 1800 mV normal standby
 [    0.357604] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz
 [    0.367736] Switching to clocksource 32k_counter
 [    0.511047] NET: Registered protocol family 2
 [    0.512115] IP route cache hash table entries: 4096 (order: 2, 16384 
bytes)
 [    0.514526] TCP established hash table entries: 16384 (order: 5, 
131072 
bytes)
 [    0.515228] TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
 [    0.524719] TCP: Hash tables configured (established 16384 bind 16384)
 [    0.524841] TCP: reno registered
 [    0.524871] UDP hash table entries: 256 (order: 2, 20480 bytes)
 [    0.525207] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
 [    0.526275] NET: Registered protocol family 1
 [    0.527984] RPC: Registered named UNIX socket transport module.
 [    0.528015] RPC: Registered udp transport module.
 [    0.528045] RPC: Registered tcp transport module.
 [    0.528076] RPC: Registered tcp NFSv4.1 backchannel transport module.
 [    0.528961] Trying to unpack rootfs image as initramfs...
 [    0.530273] rootfs image is not initramfs (junk in compressed archive); 
looks like an initrd
 [    1.404937] Freeing initrd memory: 98304K
 [    1.405120] NetWinder Floating Point Emulator V0.97 (double precision)
 [    1.576263] VFS: Disk quotas dquot_6.5.2
 [    1.576660] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
 [    1.578369] squashfs: version 4.0 (2009/01/31) Phillip Lougher
 [    1.578582] NFS: Registering the id_resolver key type
 [    1.580841] jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red 
Hat, Inc.
 [    1.582214] msgmni has been set to 979
 [    1.586212] io scheduler noop registered
 [    1.586212] io scheduler deadline registered
 [    1.586486] io scheduler cfq registered (default)
 [    1.593688] OMAP DSS rev 2.0
 [    1.627441] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
 [    1.636077] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a 
OMAP UART0
 [    1.638336] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a 
OMAP UART1
 [    1.640136] omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a 
OMAP UART2
 [    2.357696] console [ttyO2] enabled
 [    2.403747] brd: module loaded
 [    2.431823] loop: module loaded
 [    2.444305] mtdoops: mtd device (mtddev=name/number) must be 
supplied
 [    2.452392] OneNAND driver initializing
 [    2.462188] tun: Universal TUN/TAP device driver, 1.6
 [    2.467559] tun: (C) 1999-2004 Max Krasnyansky 
<maxk@qualcomm.com>
 [    2.477905] smsc911x: Driver version 2008-10-21
 [    2.485748] smsc911x: Driver version 2008-10-21
 [    2.493560] usbcore: registered new interface driver asix
 [    2.499877] usbcore: registered new interface driver cdc_ether
 [    2.506866] usbcore: registered new interface driver net1080
 [    2.513549] usbcore: registered new interface driver cdc_subset
 [    2.520507] usbcore: registered new interface driver zaurus
 [    2.527130] usbcore: registered new interface driver cdc_ncm
 [    2.535827] usbcore: registered new interface driver cdc_wdm
 [    2.541961] Initializing USB Mass Storage driver...
 [    2.547821] usbcore: registered new interface driver usb-storage
 [    2.554321] USB Mass Storage support registered.
 [    2.560546] usbcore: registered new interface driver libusual
 [    2.567443] usbcore: registered new interface driver usbtest
 [    2.576019] mousedev: PS/2 mouse device common for all mice
 [    2.588287] ads7846 spi1.0: touchscreen, irq 210
 [    2.596252] input: ADS7846 Touchscreen 
as /devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/input/input0
 [    2.613708] input: twl4030_pwrbutton 
as /devices/platform/omap_i2c.1/i2c-1/1-
 0049/twl4030_pwrbutton/input/input1
 [    2.627075] twl_rtc twl_rtc: Power up reset detected.
 [    2.632598] twl_rtc twl_rtc: Enabling TWL-RTC
 [    2.642150] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
 [    2.650329] i2c /dev entries driver
 [    2.657989] Driver for 1-wire Dallas network protocol.
 [    2.667633] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial 
timeout 
60 sec
 [    2.676361] twl4030_wdt twl4030_wdt: Failed to register misc device
 [    2.683197] twl4030_wdt: probe of twl4030_wdt failed with error -16
 [    2.925811] usbcore: registered new interface driver usbhid
 [    2.931884] usbhid: USB HID core driver
 [    2.935943] oprofile: hardware counters not available
 [    2.941345] oprofile: using timer interrupt.
 [    2.946990] TCP: cubic registered
 [    2.950500] Initializing XFRM netlink socket
 [    2.955261] NET: Registered protocol family 17
 [    2.960052] NET: Registered protocol family 15
 [    2.965209] Registering the dns_resolver key type
 [    2.970520] VFP support v0.3: implementor 41 architecture 3 part 30 
variant c rev 1
 [    2.978790] ThumbEE CPU extension supported.
 [    3.033538] clock: disabling unused clocks to save power
 [    3.044952] omapfb omapfb: no driver for display: dvi
 [    3.064605] Console: switching to colour frame buffer device 60x34
 [    3.077270] omapdss DPI: Could not find exact pixel clock. Requested 
9200 kHz, got 9094 kHz
 [    3.090240] VDAC: incomplete constraints, leaving on
 [    3.102539] input: gpio-keys as /devices/platform/gpio-keys/input/input2
 [    3.115509] twl_rtc twl_rtc: setting system clock to 2000-01-01 
00:00:08 UTC (946684808)
 [    3.130462] RAMDISK: squashfs filesystem found at block 0
 [    3.136413] RAMDISK: Loading 50389KiB [1 disk] into ram disk... /
 [    3.493408] mmc0: host does not support reading read-only switch. 
assuming write-enable.
 [    3.502807] |
 [    3.509490] mmc0: new high speed SDHC card at address 0002
 [    3.517395] -
 [    3.532745] mmcblk0: mmc0:0002 SD32G 29.9 GiB
 [    3.539916] -
 [    3.553771]  mmcblk0: p1
 [    3.558837] \
 [    3.652862] mmc1: new SDIO card at address 0001
 [    3.658905] done.
 [    6.427917] VFS: Mounted root (squashfs filesystem) readonly on device 
1:0.
 [    6.438079] devtmpfs: mounted
 [    6.442260] Freeing init memory: 308K
 [    6.621215] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling 
the overlay
 


--
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

Re: Problems with 3.4-rc5

[Tomi Valkeinen]

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

On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote:
> -----Original Message-----
>  From: Tomi Valkeinen <tomi.valkeinen@ti.com>
>  To: Joe Woodward <jw@terrafix.co.uk>
>  Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
>  Date: Thu, 03 May 2012 16:07:22 +0300
>  Subject: Re: Problems with 3.4-rc5
>  
> > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
>  > 
> > > Both patches together results in slightly different behaviour, the
>  > display is still broken- 
> > > it flickers on and off with occassional underflows before breaking
>  > completely.
>  > 
> > Beagle works fine for me with omap2plus based config, and I think overo
>  > also although I can't test it now as I broke my micro mmc adapter.
>  > 
> > Can you send your panel definition? Any other things that could affect
>  > display? Do you have PM enabled? Can you share your kernel config?
>  > 
> >  Tomi
>  > 
> 
> I've gone back to a test setup others can replicate.

Ok, I can replicate it now. It seems to be somehow PM related. I
normally have USB gadget stuff compiled into kernel so that I can boot
via nfsroot with usb. After disabling USB support from the kernel, I can
see synclosts.

I have no idea yet what could be causing this. I've also tried adding
the couple of DSS patches which are in queue for next merge window, that
force OPP100 when DSS is enabled. They don't seem to help.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Problems with 3.4-rc5

[Tomi Valkeinen]

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

On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote:
> > -----Original Message-----
> >  From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >  To: Joe Woodward <jw@terrafix.co.uk>
> >  Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
> >  Date: Thu, 03 May 2012 16:07:22 +0300
> >  Subject: Re: Problems with 3.4-rc5
> >  
> > > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
> >  > 
> > > > Both patches together results in slightly different behaviour, the
> >  > display is still broken- 
> > > > it flickers on and off with occassional underflows before breaking
> >  > completely.
> >  > 
> > > Beagle works fine for me with omap2plus based config, and I think overo
> >  > also although I can't test it now as I broke my micro mmc adapter.
> >  > 
> > > Can you send your panel definition? Any other things that could affect
> >  > display? Do you have PM enabled? Can you share your kernel config?
> >  > 
> > >  Tomi
> >  > 
> > 
> > I've gone back to a test setup others can replicate.
> 
> Ok, I can replicate it now. It seems to be somehow PM related. I
> normally have USB gadget stuff compiled into kernel so that I can boot
> via nfsroot with usb. After disabling USB support from the kernel, I can
> see synclosts.
> 
> I have no idea yet what could be causing this. I've also tried adding
> the couple of DSS patches which are in queue for next merge window, that
> force OPP100 when DSS is enabled. They don't seem to help.

Also, at least on my setup, the sync lost doesn't happen very quickly
after starting the video output, but (I think) only when the system
starts to idle. My init scripts generate keys for sshd and some other
stuff, and no sync lost there, only just before the shell prompt do I
get a sync lost.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Problems with 3.4-rc5

[Joe Woodward]

-----Original Message-----
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
Date: Fri, 04 May 2012 17:01:12 +0300
Subject: Re: Problems with 3.4-rc5

> On Fri, 2012-05-04 at 16:50 +0300, Tomi Valkeinen wrote:
> > On Fri, 2012-05-04 at 10:19 +0100, Joe Woodward wrote:
> > > -----Original Message-----
> > >  From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > >  To: Joe Woodward <jw@terrafix.co.uk>
> > >  Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
> > >  Date: Thu, 03 May 2012 16:07:22 +0300
> > >  Subject: Re: Problems with 3.4-rc5
> > >  
> > > > On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
> > >  > 
> > > > > Both patches together results in slightly different behaviour,
> the
> > >  > display is still broken- 
> > > > > it flickers on and off with occassional underflows before
> breaking
> > >  > completely.
> > >  > 
> > > > Beagle works fine for me with omap2plus based config, and I think
> overo
> > >  > also although I can't test it now as I broke my micro mmc
> adapter.
> > >  > 
> > > > Can you send your panel definition? Any other things that could
> affect
> > >  > display? Do you have PM enabled? Can you share your kernel
> config?
> > >  > 
> > > >  Tomi
> > >  > 
> > > 
> > > I've gone back to a test setup others can replicate.
> > 
> > Ok, I can replicate it now. It seems to be somehow PM related. I
> > normally have USB gadget stuff compiled into kernel so that I can
> boot
> > via nfsroot with usb. After disabling USB support from the kernel, I
> can
> > see synclosts.
> > 
> > I have no idea yet what could be causing this. I've also tried adding
> > the couple of DSS patches which are in queue for next merge window,
> that
> > force OPP100 when DSS is enabled. They don't seem to help.
> 
> Also, at least on my setup, the sync lost doesn't happen very quickly
> after starting the video output, but (I think) only when the system
> starts to idle. My init scripts generate keys for sshd and some other
> stuff, and no sync lost there, only just before the shell prompt do I
> get a sync lost.
> 
>  Tomi
> 

That sounds like the same as I'm seeing. It seems that the sync lost jumps 
around a bit, from almost immediately (when the graphics are enabled), to 
up to 3 or 4 seconds later (still just before the shell prompt).

I'm assuming that setting the FIFO low and high points fixes your sync losts 
as well (as in the first patch you sent)?

I've also noted that doing things in different orders can sometimes fix the 
sync lost (such as disabling or enabling DVI output), but this all seems a bit 
random.

I'm just glad someone else has been able to replicate the problem :p

Cheers,
Joe

v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

Hi Kevin, Paul,

On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:

> > > Ok, I can replicate it now. It seems to be somehow PM related. I
> > > normally have USB gadget stuff compiled into kernel so that I can
> > boot
> > > via nfsroot with usb. After disabling USB support from the kernel, I
> > can
> > > see synclosts.
> > > 
> > > I have no idea yet what could be causing this. I've also tried adding
> > > the couple of DSS patches which are in queue for next merge window,
> > that
> > > force OPP100 when DSS is enabled. They don't seem to help.
> > 
> > Also, at least on my setup, the sync lost doesn't happen very quickly
> > after starting the video output, but (I think) only when the system
> > starts to idle. My init scripts generate keys for sshd and some other
> > stuff, and no sync lost there, only just before the shell prompt do I
> > get a sync lost.
> > 
> >  Tomi
> > 
> 
> That sounds like the same as I'm seeing. It seems that the sync lost jumps 
> around a bit, from almost immediately (when the graphics are enabled), to 
> up to 3 or 4 seconds later (still just before the shell prompt).
> 
> I'm assuming that setting the FIFO low and high points fixes your sync losts 
> as well (as in the first patch you sent)?
> 
> I've also noted that doing things in different orders can sometimes fix the 
> sync lost (such as disabling or enabling DVI output), but this all seems a bit 
> random.
> 
> I'm just glad someone else has been able to replicate the problem :p

Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on
omap3, causing DSS losing sync. I didn't notice this earlier as I have
USB gadget compiled into my kernel. Removing USB support from the kernel
causes the problem to appear, which more or less hints at a PM related
issue.

I don't see the problem with v3.3, but as there has been a lot of DSS
changes also, it could as well be a DSS change that has triggered the
problem.

It also looks that the sync lost happens when the system idles a bit. I
compared count and time files in debugfs/pm_debug/ for both working
(i.e. usb compiled in) and non-working cases, but they seem similar for
the relevant parts. core_pwrdm is always ON, mpu_pwrdm has both RET and
ON states, dss_pwrdm both RET and ON states (identical counts).

Do you have anything in mind related to PM that has changed for v3.4
which could affect DSS? Any idea what effect USB gadget has? My
understanding is that it keeps usbhost_pwrdm forcibly alive, maybe also
something else, but I'm not sure why it would affect DSS.

I also tested with my DSS OPP100 patches, which try to force OPP100 when
DSS is enabled by adding a PM constraint for bus tput of 1000000000, but
it doesn't seem to have any effect. And, I guess, the constraint affects
only core_pwrdm, and as seen it's anyway always on in both cases.

Any debugging ideas are welcome.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote:
> Hi Kevin, Paul,
> 
> On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:
> 
> > > > Ok, I can replicate it now. It seems to be somehow PM related. I
> > > > normally have USB gadget stuff compiled into kernel so that I can
> > > boot
> > > > via nfsroot with usb. After disabling USB support from the kernel, I
> > > can
> > > > see synclosts.
> > > > 
> > > > I have no idea yet what could be causing this. I've also tried adding
> > > > the couple of DSS patches which are in queue for next merge window,
> > > that
> > > > force OPP100 when DSS is enabled. They don't seem to help.
> > > 
> > > Also, at least on my setup, the sync lost doesn't happen very quickly
> > > after starting the video output, but (I think) only when the system
> > > starts to idle. My init scripts generate keys for sshd and some other
> > > stuff, and no sync lost there, only just before the shell prompt do I
> > > get a sync lost.
> > > 
> > >  Tomi
> > > 
> > 
> > That sounds like the same as I'm seeing. It seems that the sync lost jumps 
> > around a bit, from almost immediately (when the graphics are enabled), to 
> > up to 3 or 4 seconds later (still just before the shell prompt).
> > 
> > I'm assuming that setting the FIFO low and high points fixes your sync losts 
> > as well (as in the first patch you sent)?
> > 
> > I've also noted that doing things in different orders can sometimes fix the 
> > sync lost (such as disabling or enabling DVI output), but this all seems a bit 
> > random.
> > 
> > I'm just glad someone else has been able to replicate the problem :p
> 
> Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on
> omap3, causing DSS losing sync. I didn't notice this earlier as I have
> USB gadget compiled into my kernel. Removing USB support from the kernel
> causes the problem to appear, which more or less hints at a PM related
> issue.

Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch
enough pixels to update the panel. And in this case the pixel clock is
very low (small panel), so it's nowhere near any limit.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote:
> > Hi Kevin, Paul,
> > 
> > On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:
> > 
> > > > > Ok, I can replicate it now. It seems to be somehow PM related. I
> > > > > normally have USB gadget stuff compiled into kernel so that I can
> > > > boot
> > > > > via nfsroot with usb. After disabling USB support from the kernel, I
> > > > can
> > > > > see synclosts.
> > > > > 
> > > > > I have no idea yet what could be causing this. I've also tried adding
> > > > > the couple of DSS patches which are in queue for next merge window,
> > > > that
> > > > > force OPP100 when DSS is enabled. They don't seem to help.
> > > > 
> > > > Also, at least on my setup, the sync lost doesn't happen very quickly
> > > > after starting the video output, but (I think) only when the system
> > > > starts to idle. My init scripts generate keys for sshd and some other
> > > > stuff, and no sync lost there, only just before the shell prompt do I
> > > > get a sync lost.
> > > > 
> > > >  Tomi
> > > > 
> > > 
> > > That sounds like the same as I'm seeing. It seems that the sync lost jumps 
> > > around a bit, from almost immediately (when the graphics are enabled), to 
> > > up to 3 or 4 seconds later (still just before the shell prompt).
> > > 
> > > I'm assuming that setting the FIFO low and high points fixes your sync losts 
> > > as well (as in the first patch you sent)?
> > > 
> > > I've also noted that doing things in different orders can sometimes fix the 
> > > sync lost (such as disabling or enabling DVI output), but this all seems a bit 
> > > random.
> > > 
> > > I'm just glad someone else has been able to replicate the problem :p
> > 
> > Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on
> > omap3, causing DSS losing sync. I didn't notice this earlier as I have
> > USB gadget compiled into my kernel. Removing USB support from the kernel
> > causes the problem to appear, which more or less hints at a PM related
> > issue.
> 
> Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch
> enough pixels to update the panel. And in this case the pixel clock is
> very low (small panel), so it's nowhere near any limit.

And two more interesting points about the problem:

Setting DISPC's SIDLEMODE to no-idle seems to remove the issue.

With some DISPC's fifo high/low threshold values things seem to work,
while with others we get underflows. And as the required bandwidth here
is quite small, and the threshold values I tested are close to each
other, I don't think it's really a proper bandwidth issue.

I'm guessing that certain threshold values cause somehow un-optimal
accesses to the memory, and with smart-idle this somehow causes
problems.

Archit, you looked into the thresholds some time ago. I recall that some
threshold values were "bad" in some way? Were those only for OMAP4?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Joe Woodward]

Any news on this?

This thread seems to have gone a little quiet...

Cheers,
Joe

-----Original Message-----
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Paul Walmsley <paul@pwsan.com>, khilman@ti.com
Cc: Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org, Joe Woodward <jw@terrafix.co.uk>
Date: Tue, 08 May 2012 16:26:38 +0300
Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

> On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote:
> > On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote:
> > > Hi Kevin, Paul,
> > > 
> > > On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:
> > > 
> > > > > > Ok, I can replicate it now. It seems to be somehow PM
> related. I
> > > > > > normally have USB gadget stuff compiled into kernel so that I
> can
> > > > > boot
> > > > > > via nfsroot with usb. After disabling USB support from the
> kernel, I
> > > > > can
> > > > > > see synclosts.
> > > > > > 
> > > > > > I have no idea yet what could be causing this. I've also
> tried adding
> > > > > > the couple of DSS patches which are in queue for next merge
> window,
> > > > > that
> > > > > > force OPP100 when DSS is enabled. They don't seem to help.
> > > > > 
> > > > > Also, at least on my setup, the sync lost doesn't happen very
> quickly
> > > > > after starting the video output, but (I think) only when the
> system
> > > > > starts to idle. My init scripts generate keys for sshd and some
> other
> > > > > stuff, and no sync lost there, only just before the shell
> prompt do I
> > > > > get a sync lost.
> > > > > 
> > > > >  Tomi
> > > > > 
> > > > 
> > > > That sounds like the same as I'm seeing. It seems that the sync
> lost jumps 
> > > > around a bit, from almost immediately (when the graphics are
> enabled), to 
> > > > up to 3 or 4 seconds later (still just before the shell prompt).
> > > > 
> > > > I'm assuming that setting the FIFO low and high points fixes your
> sync losts 
> > > > as well (as in the first patch you sent)?
> > > > 
> > > > I've also noted that doing things in different orders can
> sometimes fix the 
> > > > sync lost (such as disabling or enabling DVI output), but this
> all seems a bit 
> > > > random.
> > > > 
> > > > I'm just glad someone else has been able to replicate the problem
> :p
> > > 
> > > Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4
> running on
> > > omap3, causing DSS losing sync. I didn't notice this earlier as I
> have
> > > USB gadget compiled into my kernel. Removing USB support from the
> kernel
> > > causes the problem to appear, which more or less hints at a PM
> related
> > > issue.
> > 
> > Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch
> > enough pixels to update the panel. And in this case the pixel clock
> is
> > very low (small panel), so it's nowhere near any limit.
> 
> And two more interesting points about the problem:
> 
> Setting DISPC's SIDLEMODE to no-idle seems to remove the issue.
> 
> With some DISPC's fifo high/low threshold values things seem to work,
> while with others we get underflows. And as the required bandwidth here
> is quite small, and the threshold values I tested are close to each
> other, I don't think it's really a proper bandwidth issue.
> 
> I'm guessing that certain threshold values cause somehow un-optimal
> accesses to the memory, and with smart-idle this somehow causes
> problems.
> 
> Archit, you looked into the thresholds some time ago. I recall that
> some
> threshold values were "bad" in some way? Were those only for OMAP4?
> 
>  Tomi
> 

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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


On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
> Any news on this?
> 
> This thread seems to have gone a little quiet...

Hi,

I've been doing testing to understand the problem, but so far I don't
have any idea why things go wrong. I haven't found out any logic in
which configuration works and which doesn't. Looks to me that for some
reason the PM prevents DSS from getting data fast enough with certain
fifo thresholds.

I have two ways to avoid the problem, but I've been reluctant to make
patches for those because I feel it's just hiding the problem. One way
is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
other is to use certain fifo threshold values, which just seem to work
for unknown reasons.

Considering that we already have a SIDLEMODE hack in DSS for omap3 when
using DSI, I wonder if the omap3 PM + DSS combination is just plain
broken, and we should disallow idle. I'm not quite sure what are the
implications of that.

I'd appreciate comments from the PM people =).

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Kevin Hilman]

Tomi Valkeinen <tomi.valkeinen@ti.com> writes:

> On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
>> Any news on this?
>> 
>> This thread seems to have gone a little quiet...
>
> Hi,
>
> I've been doing testing to understand the problem, but so far I don't
> have any idea why things go wrong. I haven't found out any logic in
> which configuration works and which doesn't. Looks to me that for some
> reason the PM prevents DSS from getting data fast enough with certain
> fifo thresholds.
>
> I have two ways to avoid the problem, but I've been reluctant to make
> patches for those because I feel it's just hiding the problem. One way
> is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> other is to use certain fifo threshold values, which just seem to work
> for unknown reasons.
>
> Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> using DSI, I wonder if the omap3 PM + DSS combination is just plain
> broken, and we should disallow idle. I'm not quite sure what are the
> implications of that.
>
> I'd appreciate comments from the PM people =).

Unfortunately, without the bandwidth to dig into this deeply myself, I
don't have much to add.

As we know, it's not unheard of for various IPs to have bugs in
smart-idle mode ;)

The one thing I can say is that the reason it probably worked on earlier
kernels was because the UART driver was not actually idling, so you were
probably never hitting low power states.  

Kevin

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> 
> > On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
> >> Any news on this?
> >> 
> >> This thread seems to have gone a little quiet...
> >
> > Hi,
> >
> > I've been doing testing to understand the problem, but so far I don't
> > have any idea why things go wrong. I haven't found out any logic in
> > which configuration works and which doesn't. Looks to me that for some
> > reason the PM prevents DSS from getting data fast enough with certain
> > fifo thresholds.
> >
> > I have two ways to avoid the problem, but I've been reluctant to make
> > patches for those because I feel it's just hiding the problem. One way
> > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> > other is to use certain fifo threshold values, which just seem to work
> > for unknown reasons.
> >
> > Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> > using DSI, I wonder if the omap3 PM + DSS combination is just plain
> > broken, and we should disallow idle. I'm not quite sure what are the
> > implications of that.
> >
> > I'd appreciate comments from the PM people =).
> 
> Unfortunately, without the bandwidth to dig into this deeply myself, I
> don't have much to add.

Yes, that's understandable.

However, can you shed some light about the PM in OMAP3. What is it that
happens here regarding PM, which does not happen is USB gadget driver is
compiled in? Or when I set DSS to no-idle or no-standby? Something about
L3/core/memory going into idle state?

I tried to look at the debugfs/pm_debug/ files, but I couldn't see a
difference between working and non-working cases. At least the
OFF/RET/ON/etc states were not affected. Are there some other debug
files to look at? Are there power saving features that are not
observable via debug files?

> As we know, it's not unheard of for various IPs to have bugs in
> smart-idle mode ;)
> 
> The one thing I can say is that the reason it probably worked on earlier
> kernels was because the UART driver was not actually idling, so you were
> probably never hitting low power states.  

There is also a change in the DSS fifos, which probably triggered this.
I think I can fall back to the old behavior.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Kevin Hilman]

Tomi Valkeinen <tomi.valkeinen@ti.com> writes:

> On Mon, 2012-05-14 at 15:48 -0700, Kevin Hilman wrote:
>> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
>> 
>> > On Mon, 2012-05-14 at 08:36 +0100, Joe Woodward wrote:
>> >> Any news on this?
>> >> 
>> >> This thread seems to have gone a little quiet...
>> >
>> > Hi,
>> >
>> > I've been doing testing to understand the problem, but so far I don't
>> > have any idea why things go wrong. I haven't found out any logic in
>> > which configuration works and which doesn't. Looks to me that for some
>> > reason the PM prevents DSS from getting data fast enough with certain
>> > fifo thresholds.
>> >
>> > I have two ways to avoid the problem, but I've been reluctant to make
>> > patches for those because I feel it's just hiding the problem. One way
>> > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
>> > other is to use certain fifo threshold values, which just seem to work
>> > for unknown reasons.
>> >
>> > Considering that we already have a SIDLEMODE hack in DSS for omap3 when
>> > using DSI, I wonder if the omap3 PM + DSS combination is just plain
>> > broken, and we should disallow idle. I'm not quite sure what are the
>> > implications of that.
>> >
>> > I'd appreciate comments from the PM people =).
>> 
>> Unfortunately, without the bandwidth to dig into this deeply myself, I
>> don't have much to add.
>
> Yes, that's understandable.
>
> However, can you shed some light about the PM in OMAP3. What is it that
> happens here regarding PM, which does not happen is USB gadget driver is
> compiled in? Or when I set DSS to no-idle or no-standby? Something about
> L3/core/memory going into idle state?

My first guess would have been that in those two cases, CORE was
prevented from going into retention, but based on what you said earlier,
it sounds like CORE is always staying on.

Just to clarify: by USB gadget, I assume you mean MUSB? (a.k.a USB OTG,
or HS USB in the TRM)?  I'm a bit confused because earlier you mentioned
keeping usbhost_pwrdm active, but USB host is separate IP in its own
powerdomain, whereas USB OTG is an IP in the CORE powerdomain.

> I tried to look at the debugfs/pm_debug/ files, but I couldn't see a
> difference between working and non-working cases. At least the
> OFF/RET/ON/etc states were not affected. Are there some other debug
> files to look at? Are there power saving features that are not
> observable via debug files?

There may not be a difference in the actual states being hit, but there
may be subtle differences in latencies to enter/exit the various states.

An interesting experiment would be to disable the deeper C-states in
CPUidle and see if the problem still exists.  Here's a little shell
snippet to do this via sysfs:

# CPUidle: disable everything but C1
cd /sys/devices/system/cpu/cpu0/cpuidle
for state in state[1-6]*; do
  if [ -e ${state} ]; then 
    echo 1 > ${state}/disable
  fi
done

>> As we know, it's not unheard of for various IPs to have bugs in
>> smart-idle mode ;)
>> 
>> The one thing I can say is that the reason it probably worked on earlier
>> kernels was because the UART driver was not actually idling, so you were
>> probably never hitting low power states.  
>
> There is also a change in the DSS fifos, which probably triggered this.
> I think I can fall back to the old behavior.

Because of the current boot defaults, the only pwrdm that is actively
transitioning during idle is the MPU pwrdm.

So if preventing the MPU pwrdm from hitting idle makes the problem go
away, we'd need to better understand this wakeup latency constraint and
possibly code it in the DSS driver.

Kevin

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Paul Walmsley]

Hello Tomi,

On Mon, 14 May 2012, Tomi Valkeinen wrote:

> I've been doing testing to understand the problem, but so far I don't
> have any idea why things go wrong. I haven't found out any logic in
> which configuration works and which doesn't. Looks to me that for some
> reason the PM prevents DSS from getting data fast enough with certain
> fifo thresholds.
> 
> I have two ways to avoid the problem, but I've been reluctant to make
> patches for those because I feel it's just hiding the problem. One way
> is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> other is to use certain fifo threshold values, which just seem to work
> for unknown reasons.
> 
> Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> using DSI, I wonder if the omap3 PM + DSS combination is just plain
> broken, and we should disallow idle. I'm not quite sure what are the
> implications of that.
> 
> I'd appreciate comments from the PM people =).

This may be caused by one of the DPLLs going into autoidle.  This can 
involve a significant wakeup latency.  I'd suggest looking at DPLL3, which 
provides the DSS interface clock, and DPLL4, which can provide the DSS 
functional clock.

Could you try:

1. applying something like the patch at the bottom of this message and 
seeing if it makes any difference?

2. if #1 does not work, changing the "dpll3" in the patch to "dpll4" ?

3. if #2 does not work, disabling autoidle on both dpll3 and dpll4?


I regret that I haven't been able to focus more on DSS issues -

- Paul


Date: Wed, 14 Mar 2012 17:49:43 -0600 (MDT)
From: Paul Walmsley <paul@pwsan.com>
Subject: Patch that should disable DPLL3 autoidle


 Test patch to disable DPLL3 autoidle.

---
 arch/arm/plat-omap/clock.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 567e4b5..4b02b35 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -351,6 +351,13 @@ int omap_clk_enable_autoidle_all(void)
 		if (c->ops->allow_idle)
 			c->ops->allow_idle(c);
 
+	c = clk_get(NULL, "dpll3_ck");
+	if (c && c->ops->deny_idle)
+		c->ops->deny_idle(c);
+	else
+		WARN(1, "Cannot disable autoidle on DPLL3\n");
+	clk_put(c);
+
 	spin_unlock_irqrestore(&clockfw_lock, flags);
 
 	return 0;
-- 
1.7.9.1

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
> Hello Tomi,
> 
> On Mon, 14 May 2012, Tomi Valkeinen wrote:
> 
> > I've been doing testing to understand the problem, but so far I don't
> > have any idea why things go wrong. I haven't found out any logic in
> > which configuration works and which doesn't. Looks to me that for some
> > reason the PM prevents DSS from getting data fast enough with certain
> > fifo thresholds.
> > 
> > I have two ways to avoid the problem, but I've been reluctant to make
> > patches for those because I feel it's just hiding the problem. One way
> > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> > other is to use certain fifo threshold values, which just seem to work
> > for unknown reasons.
> > 
> > Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> > using DSI, I wonder if the omap3 PM + DSS combination is just plain
> > broken, and we should disallow idle. I'm not quite sure what are the
> > implications of that.
> > 
> > I'd appreciate comments from the PM people =).
> 
> This may be caused by one of the DPLLs going into autoidle.  This can 
> involve a significant wakeup latency.  I'd suggest looking at DPLL3, which 
> provides the DSS interface clock, and DPLL4, which can provide the DSS 
> functional clock.
> 
> Could you try:
> 
> 1. applying something like the patch at the bottom of this message and 
> seeing if it makes any difference?
> 
> 2. if #1 does not work, changing the "dpll3" in the patch to "dpll4" ?
> 
> 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4?

Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle
doesn't affect the problem.

But... Isn't the iface clock only needed to program DSS? When the DSS is
just running independently, plain func clock should be enough, right? Or
is iface clock used for the communication between DSS and
CORE/DPLL/wakeup/something?

I also suspect that this could be just a plain DSS bug. The default FIFO
low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
The fifo is 1024 bytes). The values are calculated with fifo_size -
burst_size and fifo_size - 1.

We are now using FIFO merge features, which combines multiple fifos into
one when possible, making the fifo size 1024*3 = 3072. Using the same
low threshold and increasing the high threshold to 960/3071 works fine.
Changing the high threshold to 3008 causes underflows. Increasing the
low threshold to ~1600 makes DSS work again.

So I think that the high thresholds of 3071 and 3008 are so close to
each other that there shouldn't be any real difference in practice,
presuming everything works. But, for whatever reason, fetching of the
pixels becomes much more inefficient or with much higher start latency,
causing the underflows.

I guess we'd need HW people to debug this, but their interest in OMAP3
is probably long gone. So I think I'll just have to use values that seem
to work for the use cases we test.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Wed, 2012-05-16 at 12:08 +0300, Tomi Valkeinen wrote:
> On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
> > Hello Tomi,
> > 
> > On Mon, 14 May 2012, Tomi Valkeinen wrote:
> > 
> > > I've been doing testing to understand the problem, but so far I don't
> > > have any idea why things go wrong. I haven't found out any logic in
> > > which configuration works and which doesn't. Looks to me that for some
> > > reason the PM prevents DSS from getting data fast enough with certain
> > > fifo thresholds.
> > > 
> > > I have two ways to avoid the problem, but I've been reluctant to make
> > > patches for those because I feel it's just hiding the problem. One way
> > > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> > > other is to use certain fifo threshold values, which just seem to work
> > > for unknown reasons.
> > > 
> > > Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> > > using DSI, I wonder if the omap3 PM + DSS combination is just plain
> > > broken, and we should disallow idle. I'm not quite sure what are the
> > > implications of that.
> > > 
> > > I'd appreciate comments from the PM people =).
> > 
> > This may be caused by one of the DPLLs going into autoidle.  This can 
> > involve a significant wakeup latency.  I'd suggest looking at DPLL3, which 
> > provides the DSS interface clock, and DPLL4, which can provide the DSS 
> > functional clock.
> > 
> > Could you try:
> > 
> > 1. applying something like the patch at the bottom of this message and 
> > seeing if it makes any difference?
> > 
> > 2. if #1 does not work, changing the "dpll3" in the patch to "dpll4" ?
> > 
> > 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4?
> 
> Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle
> doesn't affect the problem.

JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to
me, sounds a bit related to dpll autoidle. By default it's 0, "interface
and functional clocks can be switched off". I tested the three other
values, but none of them had any effect.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Cousson, Benoit]

Hi Tomi,

On 5/16/2012 11:08 AM, Tomi Valkeinen wrote:
> On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
>> Hello Tomi,
>>
>> On Mon, 14 May 2012, Tomi Valkeinen wrote:
>>
>>> I've been doing testing to understand the problem, but so far I don't
>>> have any idea why things go wrong. I haven't found out any logic in
>>> which configuration works and which doesn't. Looks to me that for some
>>> reason the PM prevents DSS from getting data fast enough with certain
>>> fifo thresholds.
>>>
>>> I have two ways to avoid the problem, but I've been reluctant to make
>>> patches for those because I feel it's just hiding the problem. One way
>>> is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
>>> other is to use certain fifo threshold values, which just seem to work
>>> for unknown reasons.
>>>
>>> Considering that we already have a SIDLEMODE hack in DSS for omap3 when
>>> using DSI, I wonder if the omap3 PM + DSS combination is just plain
>>> broken, and we should disallow idle. I'm not quite sure what are the
>>> implications of that.
>>>
>>> I'd appreciate comments from the PM people =).
>>
>> This may be caused by one of the DPLLs going into autoidle.  This can
>> involve a significant wakeup latency.  I'd suggest looking at DPLL3, which
>> provides the DSS interface clock, and DPLL4, which can provide the DSS
>> functional clock.
>>
>> Could you try:
>>
>> 1. applying something like the patch at the bottom of this message and
>> seeing if it makes any difference?
>>
>> 2. if #1 does not work, changing the "dpll3" in the patch to "dpll4" ?
>>
>> 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4?
>
> Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle
> doesn't affect the problem.

The issues your are facing seems to be the well known DSS low power 
refresh mode we've been trying to use since OMAP2 :-).

DPLL3 = CORE DPLL, whereas DPLL4 = PER DPLL, so that's normal that only 
the DPLL3 change is affecting the issue.

> But... Isn't the iface clock only needed to program DSS? When the DSS is
> just running independently, plain func clock should be enough, right? Or
> is iface clock used for the communication between DSS and
> CORE/DPLL/wakeup/something?

No, the DSS does have two ports, the slave one for the register access 
and a master one for the DMA inside the DSS to fetch the data from the 
memory.

So basically, what is happening is that as soon as you allow MSTANDBY to 
happen, the DSS will allow the iclk to be gated, and assuming the 
interconnect is not used by any other initiator (like USB), the CORE 
DPLL (DPLL3) can be gated.

The issue is that when the DSS will reach the low threshold, it will 
de-assert the MSTANDBY to be able to get some fresh data. But since the 
DPLL3 was in idle, it will take several tens of us before the clock is 
re-enabled and thus before the interconnect can be used by the DSS to 
get the data. Meanwhile the DSS FIFO is still getting low.

If the latency to re-enable the DPLL + interconnect is above the 
duration that the FIFO DSS can support, you do have some FIFO underflow.

> I also suspect that this could be just a plain DSS bug. The default FIFO
> low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
> FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
> The fifo is 1024 bytes). The values are calculated with fifo_size -
> burst_size and fifo_size - 1.
>
> We are now using FIFO merge features, which combines multiple fifos into
> one when possible, making the fifo size 1024*3 = 3072. Using the same
> low threshold and increasing the high threshold to 960/3071 works fine.
> Changing the high threshold to 3008 causes underflows. Increasing the
> low threshold to ~1600 makes DSS work again.

That's weird, in theory what should matter is only the diff between the 
high and low. Well the low value should be as high as possible as well 
to support the wakeup latency.

> So I think that the high thresholds of 3071 and 3008 are so close to
> each other that there shouldn't be any real difference in practice,
> presuming everything works. But, for whatever reason, fetching of the
> pixels becomes much more inefficient or with much higher start latency,
> causing the underflows.
>
> I guess we'd need HW people to debug this, but their interest in OMAP3
> is probably long gone. So I think I'll just have to use values that seem
> to work for the use cases we test.

Anyway, in this case, a PM QoS constraint should be set on the 
interconnect to ensure that potentially the DPLL3 will not be autogated 
as soon as the iclk is gated.

The point is that whereas you set the FIFO to support the wakeup latency 
or you prevent the idle mode because you conside the DSS cannot support 
that latency because FIFO cannot be merged.

Except that I'm not sure the PM QoS OMAP is in mainline yet :-(

Regards,
Benoit

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Wed, 2012-05-16 at 12:09 +0200, Cousson, Benoit wrote:
> Hi Tomi,
> 
> On 5/16/2012 11:08 AM, Tomi Valkeinen wrote:

> > Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle
> > doesn't affect the problem.
> 
> The issues your are facing seems to be the well known DSS low power 
> refresh mode we've been trying to use since OMAP2 :-).

Hmm, so are you saying no one has managed to get fifomerge and autoidle
working reliably? If so, no point for me to even try it =).

If so, I wonder which is better to have: fifomerge or autoidle... 

> > I also suspect that this could be just a plain DSS bug. The default FIFO
> > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
> > FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
> > The fifo is 1024 bytes). The values are calculated with fifo_size -
> > burst_size and fifo_size - 1.
> >
> > We are now using FIFO merge features, which combines multiple fifos into
> > one when possible, making the fifo size 1024*3 = 3072. Using the same
> > low threshold and increasing the high threshold to 960/3071 works fine.
> > Changing the high threshold to 3008 causes underflows. Increasing the
> > low threshold to ~1600 makes DSS work again.
> 
> That's weird, in theory what should matter is only the diff between the 
> high and low. Well the low value should be as high as possible as well 
> to support the wakeup latency.

Yep. That makes me think there's some kind of problem with DSS accessing
the memory with particular fifo thresholds.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Paul Walmsley]

On Wed, 16 May 2012, Tomi Valkeinen wrote:

> JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to
> me, sounds a bit related to dpll autoidle. By default it's 0, "interface
> and functional clocks can be switched off". I tested the three other
> values, but none of them had any effect.

As I understand it (which could very well be mistaken), the CLOCKACTIVITY 
bits are only useful in situations where we'd like to allow the 
interconnect to idle, but keep the functional clock of the IP block (or 
subsystem) running.  Right now, we control an IP block's interface clock 
and functional clock together, so CLOCKACTIVITY should probably always be 
0.

But for drivers that want to do more fine-grained clock control, or if we 
create some notion of an "autonomous IP block" in our integration layer 
for devices that can function without its interconnect, it might be worth 
exploring whether it is worthwhile to change those bits.


- Paul

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5919 bytes --]

cc Jean

Hello Tomi,

On Wed, 16 May 2012, Tomi Valkeinen wrote:

> I also suspect that this could be just a plain DSS bug. The default FIFO
> low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
> FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
> The fifo is 1024 bytes). The values are calculated with fifo_size -
> burst_size and fifo_size - 1.
> 
> We are now using FIFO merge features, which combines multiple fifos into
> one when possible, making the fifo size 1024*3 = 3072. Using the same
> low threshold and increasing the high threshold to 960/3071 works fine.
> Changing the high threshold to 3008 causes underflows. Increasing the
> low threshold to ~1600 makes DSS work again.

Just a few thoughts.

In terms of the high threshold, it seems really strange to me that 
changing the high threshold would make such a difference.  Naïvely, I'd 
assume that you'd want to set it as high as possible?  I suppose in cases 
where the interconnect is congested, setting it lower might allow lower 
latency for other interconnect users, but I'd hope we don't have to worry 
much about that.  So it doesn't seem to me that there would be any 
advantage to setting it lower than the maximum.

Probably the low threshold is the more important parameter, from a PM 
perspective.  If you know the FIFO's drain rate and the low threshold, it 
should be possible to calculate the maximum latency that the FIFO can 
tolerate to avoid an underflow.  This could be used to specify a device PM 
QoS constraint to prevent the interconnect latency from exceeding that 
value.
  
I'd guess the calculations would be something like this -- (I hope you can 
correct my relative ignorance of the DSS in the following estimates):

Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO 
drain rate would be 864 x 480 x 32 bits/second.  Since the FIFO width is 
32 bits, that's

   864 x 480 = 414 780 FIFO entries/second, or

   (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry.

So if you need a low FIFO threshold at 960 entries, you could call the 
device PM QoS functions to set a wakeup latency constraint for the 
interconnect would be nothing greater than this:

   (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs

(The reality is that it would need to be something less than this, to 
account for the time needed for the GFX DMA transfer to start supplying 
data, etc.)

The ultimate goal, with Jean's device PM QoS patches, is that these 
constraints could change the DPLL autoidle settings or powerdomain states 
to ensure the constraint was met.  He's got a page here:

  http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement

(Unfortunately it's not clear what the DPLL autoidle modes and voltage 
scaling bits are set to for many of the estimates, and we also know that 
there are many software optimizations possible for our idle path.)

We're still working on getting the OMAP device PM QoS patches merged, but 
the Linux core support is there, so you should be able to patch your 
drivers to use them -- see for example dev_pm_qos_add_request().

...

Similarly, for the low-power refresh case, if you know the GFX FIFO drain 
rate and the various latencies, it should be possible to estimate the 
minimum low threshold value needed in order to avoid a FIFO underflow.

(By "various latencies," I mean the DPLL relock latency, the GFX DMA 
latency between initiating a transfer and receiving the first result data, 
etc.  Some of these latencies may be difficult to estimate accurately.  
But if the major sources of variation can be identified, such as DPLL 
relock time or GFX DMA FIFO refill time, I'd hope we can just use trial 
and error to find some worst-case constant for the rest.)

The goal in this ase would be to allow DPLL3 to stay unlocked for as long 
as possible, to save energy.  This would imply finding the lowest possible 
FIFO low threshold that doesn't generate underflows.  Using the lowest 
possible low threshold should leave as much room as possible in the FIFO 
for data, and thus maximize the amount of time that DPLL3 can stay 
unlocked after the high threshold is reached.

Since the DPLL relock latency figures are known from the TRM section 
4.7.6.7 "Latencies," we can estimate the DPLL's contribution to the low 
threshold setting.  The DPLL relock latency depends on the DPLL's input 
rate and some DPLL settings, so it can vary.  (We probably need a 
function for the interconnect device that can estimate the worst-case 
wakeup latency for the DSS to use, based on the rest of the system 
settings.)

Let's reuse the 2.411 µs/FIFO entry estimate from above.  For convenience, 
let's suppose that the DPLL relock latency from DPLL-OFF is 1.5 ms = 1500 
µs.  So we know that the number of FIFO slots needed simply to endure the 
DPLL relock process is

   CEIL(1500 µs/relock / 2.411 µs/FIFO entry) = CEIL(622.14 ...) = 
       623 FIFO entries/relock

This of course doesn't account for the time needed for the GFX DMA 
transfer to start delivering useful data, any voltage scaling needed, etc.

...

Just paging through the DSS TRM section, some other settings that might be 
worth checking are:

- is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32?

- is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1?

- is DISPC_GFX_PRELOAD.PRELOAD set to the maximum possible value?

- is DISPC_CONFIG.FIFOFILLING set to 1?

> So I think that the high thresholds of 3071 and 3008 are so close to
> each other that there shouldn't be any real difference in practice,
> presuming everything works. But, for whatever reason, fetching of the
> pixels becomes much more inefficient or with much higher start latency,
> causing the underflows.

That's really weird.


- Paul

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote:
> cc Jean
> 
> Hello Tomi,
> 
> On Wed, 16 May 2012, Tomi Valkeinen wrote:
> 
> > I also suspect that this could be just a plain DSS bug. The default FIFO
> > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
> > FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
> > The fifo is 1024 bytes). The values are calculated with fifo_size -
> > burst_size and fifo_size - 1.
> > 
> > We are now using FIFO merge features, which combines multiple fifos into
> > one when possible, making the fifo size 1024*3 = 3072. Using the same
> > low threshold and increasing the high threshold to 960/3071 works fine.
> > Changing the high threshold to 3008 causes underflows. Increasing the
> > low threshold to ~1600 makes DSS work again.
> 
> Just a few thoughts.
> 
> In terms of the high threshold, it seems really strange to me that 
> changing the high threshold would make such a difference.  Naïvely, I'd 
> assume that you'd want to set it as high as possible?  I suppose in cases 
> where the interconnect is congested, setting it lower might allow lower 
> latency for other interconnect users, but I'd hope we don't have to worry 
> much about that.  So it doesn't seem to me that there would be any 
> advantage to setting it lower than the maximum.

It's true that the high threshold should be set as high as possible, and
this is what we do. Except for DSI command mode output on OMAP3, where,
for unknown reason, the highest value (fifosize - 1) doesn't work and we
need to program it to fifosize - burstsize. And this was causing the
original problem, fifosize - burstsize was not working for other outputs
properly.

I guess this also hints that there's something wrong with omap3 and the
dss fifo thresholds.

> Probably the low threshold is the more important parameter, from a PM 
> perspective.  If you know the FIFO's drain rate and the low threshold, it 
> should be possible to calculate the maximum latency that the FIFO can 
> tolerate to avoid an underflow.  This could be used to specify a device PM 
> QoS constraint to prevent the interconnect latency from exceeding that 
> value.

Yes, this is how the low threshold should be adjusted. I have never
tried to calculate the threshold need, though, as I haven't had all the
information and understanding to properly calculate it.

> I'd guess the calculations would be something like this -- (I hope you can 
> correct my relative ignorance of the DSS in the following estimates):
> 
> Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO 
> drain rate would be 864 x 480 x 32 bits/second.  Since the FIFO width is 
> 32 bits, that's

I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At
least those are the "units" used with fifo size, threshold sizes, burst
size, etc.

>    864 x 480 = 414 780 FIFO entries/second, or
> 
>    (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry.
> 
> So if you need a low FIFO threshold at 960 entries, you could call the 
> device PM QoS functions to set a wakeup latency constraint for the 
> interconnect would be nothing greater than this:
> 
>    (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs
> 
> (The reality is that it would need to be something less than this, to 
> account for the time needed for the GFX DMA transfer to start supplying 
> data, etc.)

Makes sense.

Another reason for underflows we have is the different rotation engines.
VRFB on omap2/3, and TILER on omap4. Both increase the "work" needed to
get pixels, although I'm not sure what the actual causes for the
increased work are.

> The ultimate goal, with Jean's device PM QoS patches, is that these 
> constraints could change the DPLL autoidle settings or powerdomain states 
> to ensure the constraint was met.  He's got a page here:
> 
>   http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
> 
> (Unfortunately it's not clear what the DPLL autoidle modes and voltage 
> scaling bits are set to for many of the estimates, and we also know that 
> there are many software optimizations possible for our idle path.)
> 
> We're still working on getting the OMAP device PM QoS patches merged, but 
> the Linux core support is there, so you should be able to patch your 
> drivers to use them -- see for example dev_pm_qos_add_request().

Thanks for the pointers, I need to study that.

> Just paging through the DSS TRM section, some other settings that might be 
> worth checking are:
> 
> - is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32?

Yes. (8 x 128 on omap4)

I presume each DMA burst has a small overhead, so maximizing the burst
size minimizes the overhead. Do you see any other effect with the burst
size? I mean, do you see any need to know the burst size value when
trying to calculate optimal thresholds?

> - is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1?

No. We set it to 0 so that PRELOAD is used. If I've understood right,
the problem with using GFXFIFOPRELOAD=1, i.e. high threshold is used for
preload value, is that the high threshold can be quite high, and the
preload needs to happen during vertical blanking. With a small vblank
time and high high threshold there may not be enough time for the
preload.

Then again, I have not verified that. And I'm not sure why it would be a
problem if the FIFO is not loaded up to the preload value during
blanking, presuming we still have enough pixels to proceed normally.

For me it would make more sense to always load the fifo to full, so
there wouldn't be need for any PRELOAD value at all.

> - is DISPC_GFX_PRELOAD.PRELOAD set to the maximum possible value?

No, it's left at the default value. But I have tried adjusting this (and
also changing the GFXFIFOPRELOAD bit), and neither fixed the original
problem.

> - is DISPC_CONFIG.FIFOFILLING set to 1?

No, it's set to 0. With this problem there's only one overlay enabled so
it shouldn't have any effect.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Jean Pihet]

Hi Tomi, Paul!

On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote:
>> cc Jean
>>
>> Hello Tomi,
>>
>> On Wed, 16 May 2012, Tomi Valkeinen wrote:
>>
>> > I also suspect that this could be just a plain DSS bug. The default FIFO
>> > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
>> > FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
>> > The fifo is 1024 bytes). The values are calculated with fifo_size -
>> > burst_size and fifo_size - 1.
>> >
>> > We are now using FIFO merge features, which combines multiple fifos into
>> > one when possible, making the fifo size 1024*3 = 3072. Using the same
>> > low threshold and increasing the high threshold to 960/3071 works fine.
>> > Changing the high threshold to 3008 causes underflows. Increasing the
>> > low threshold to ~1600 makes DSS work again.
>>
>> Just a few thoughts.
>>
>> In terms of the high threshold, it seems really strange to me that
>> changing the high threshold would make such a difference.  Naïvely, I'd
>> assume that you'd want to set it as high as possible?  I suppose in cases
>> where the interconnect is congested, setting it lower might allow lower
>> latency for other interconnect users, but I'd hope we don't have to worry
>> much about that.  So it doesn't seem to me that there would be any
>> advantage to setting it lower than the maximum.
>
> It's true that the high threshold should be set as high as possible, and
> this is what we do. Except for DSI command mode output on OMAP3, where,
> for unknown reason, the highest value (fifosize - 1) doesn't work and we
> need to program it to fifosize - burstsize. And this was causing the
> original problem, fifosize - burstsize was not working for other outputs
> properly.
>
> I guess this also hints that there's something wrong with omap3 and the
> dss fifo thresholds.
>
>> Probably the low threshold is the more important parameter, from a PM
>> perspective.  If you know the FIFO's drain rate and the low threshold, it
>> should be possible to calculate the maximum latency that the FIFO can
>> tolerate to avoid an underflow.  This could be used to specify a device PM
>> QoS constraint to prevent the interconnect latency from exceeding that
>> value.
>
> Yes, this is how the low threshold should be adjusted. I have never
> tried to calculate the threshold need, though, as I haven't had all the
> information and understanding to properly calculate it.
>
>> I'd guess the calculations would be something like this -- (I hope you can
>> correct my relative ignorance of the DSS in the following estimates):
>>
>> Looking at mach-omap2/board-rx51-video.c, let's suppose that the FIFO
>> drain rate would be 864 x 480 x 32 bits/second.  Since the FIFO width is
>> 32 bits, that's
>
> I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4. At
> least those are the "units" used with fifo size, threshold sizes, burst
> size, etc.
>
>>    864 x 480 = 414 780 FIFO entries/second, or
>>
>>    (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO entry.
>>
>> So if you need a low FIFO threshold at 960 entries, you could call the
>> device PM QoS functions to set a wakeup latency constraint for the
>> interconnect would be nothing greater than this:
>>
>>    (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs
>>
>> (The reality is that it would need to be something less than this, to
>> account for the time needed for the GFX DMA transfer to start supplying
>> data, etc.)
>
> Makes sense.
>
> Another reason for underflows we have is the different rotation engines.
> VRFB on omap2/3, and TILER on omap4. Both increase the "work" needed to
> get pixels, although I'm not sure what the actual causes for the
> increased work are.
>
>> The ultimate goal, with Jean's device PM QoS patches, is that these
>> constraints could change the DPLL autoidle settings or powerdomain states
>> to ensure the constraint was met.  He's got a page here:
Indeed! The core code is ready and the OMAP power domains code is
under review for the moment. The ultimate goal is to split the overall
latency of a device into the contributors (SW, HW SoC, HW external
etc.), so the DPLL relock time would be taken into account. However
without the submitted code in place there is no way to build the
feature in incremental steps.

>>
>>   http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
In the wiki page there is a link to the ELC/Fosdem presentation [1]
about the new model for the latency.
[1] http://omappedia.org/wiki/File:ELC-2012-jpihet-DeviceLatencyModel.pdf

>>
>> (Unfortunately it's not clear what the DPLL autoidle modes and voltage
>> scaling bits are set to for many of the estimates, and we also know that
The code is from an l-o tree + the measurement code in, so the DPLL
are allowed to auto-idle. In the new model the DPLL relock latency
contribution should be split from the power domains latency.

>> there are many software optimizations possible for our idle path.)
Sure! Recently we have had the case with the C1 cpuidle state.
Hopefully some simple experimental optimizations did fix the issue.

Regards,
Jean

>>
>> We're still working on getting the OMAP device PM QoS patches merged, but
>> the Linux core support is there, so you should be able to patch your
>> drivers to use them -- see for example dev_pm_qos_add_request().
>
> Thanks for the pointers, I need to study that.
>
>> Just paging through the DSS TRM section, some other settings that might be
>> worth checking are:
>>
>> - is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32?
>
> Yes. (8 x 128 on omap4)
>
> I presume each DMA burst has a small overhead, so maximizing the burst
> size minimizes the overhead. Do you see any other effect with the burst
> size? I mean, do you see any need to know the burst size value when
> trying to calculate optimal thresholds?
>
>> - is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1?
>
> No. We set it to 0 so that PRELOAD is used. If I've understood right,
> the problem with using GFXFIFOPRELOAD=1, i.e. high threshold is used for
> preload value, is that the high threshold can be quite high, and the
> preload needs to happen during vertical blanking. With a small vblank
> time and high high threshold there may not be enough time for the
> preload.
>
> Then again, I have not verified that. And I'm not sure why it would be a
> problem if the FIFO is not loaded up to the preload value during
> blanking, presuming we still have enough pixels to proceed normally.
>
> For me it would make more sense to always load the fifo to full, so
> there wouldn't be need for any PRELOAD value at all.
>
>> - is DISPC_GFX_PRELOAD.PRELOAD set to the maximum possible value?
>
> No, it's left at the default value. But I have tried adjusting this (and
> also changing the GFXFIFOPRELOAD bit), and neither fixed the original
> problem.
>
>> - is DISPC_CONFIG.FIFOFILLING set to 1?
>
> No, it's set to 0. With this problem there's only one overlay enabled so
> it shouldn't have any effect.
>
>  Tomi
>
--
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

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Joe Woodward]

Was there ever a conclussion to this discussion?

I'm assuming this is unlikely to be fixed in 3.5?

Cheers,
Joe

-----Original Message-----
From: Jean Pihet <jean.pihet@newoldbits.com>
To: Paul Walmsley <paul@pwsan.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>, khilman@ti.com, Archit Taneja <a0393947@ti.com>, linux-omap@vger.kernel.org
Date: Fri, 25 May 2012 14:55:27 +0200
Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

> Hi Tomi, Paul!
> 
> On Fri, May 25, 2012 at 10:24 AM, Tomi Valkeinen
> <tomi.valkeinen@ti.com> wrote:
> > On Thu, 2012-05-24 at 18:39 -0600, Paul Walmsley wrote:
> >> cc Jean
> >>
> >> Hello Tomi,
> >>
> >> On Wed, 16 May 2012, Tomi Valkeinen wrote:
> >>
> >> > I also suspect that this could be just a plain DSS bug. The
> default FIFO
> >> > low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling
> the
> >> > FIFO when there are 960 or less bytes in the fifo, and stops at
> 1023.
> >> > The fifo is 1024 bytes). The values are calculated with fifo_size
> -
> >> > burst_size and fifo_size - 1.
> >> >
> >> > We are now using FIFO merge features, which combines multiple
> fifos into
> >> > one when possible, making the fifo size 1024*3 = 3072. Using the
> same
> >> > low threshold and increasing the high threshold to 960/3071 works
> fine.
> >> > Changing the high threshold to 3008 causes underflows. Increasing
> the
> >> > low threshold to ~1600 makes DSS work again.
> >>
> >> Just a few thoughts.
> >>
> >> In terms of the high threshold, it seems really strange to me that
> >> changing the high threshold would make such a difference.
>  Naïvely, I'd
> >> assume that you'd want to set it as high as possible?  I suppose in
> cases
> >> where the interconnect is congested, setting it lower might allow
> lower
> >> latency for other interconnect users, but I'd hope we don't have to
> worry
> >> much about that.  So it doesn't seem to me that there would be any
> >> advantage to setting it lower than the maximum.
> >
> > It's true that the high threshold should be set as high as possible,
> and
> > this is what we do. Except for DSI command mode output on OMAP3,
> where,
> > for unknown reason, the highest value (fifosize - 1) doesn't work and
> we
> > need to program it to fifosize - burstsize. And this was causing the
> > original problem, fifosize - burstsize was not working for other
> outputs
> > properly.
> >
> > I guess this also hints that there's something wrong with omap3 and
> the
> > dss fifo thresholds.
> >
> >> Probably the low threshold is the more important parameter, from a
> PM
> >> perspective.  If you know the FIFO's drain rate and the low
> threshold, it
> >> should be possible to calculate the maximum latency that the FIFO
> can
> >> tolerate to avoid an underflow.  This could be used to specify a
> device PM
> >> QoS constraint to prevent the interconnect latency from exceeding
> that
> >> value.
> >
> > Yes, this is how the low threshold should be adjusted. I have never
> > tried to calculate the threshold need, though, as I haven't had all
> the
> > information and understanding to properly calculate it.
> >
> >> I'd guess the calculations would be something like this -- (I hope
> you can
> >> correct my relative ignorance of the DSS in the following
> estimates):
> >>
> >> Looking at mach-omap2/board-rx51-video.c, let's suppose that the
> FIFO
> >> drain rate would be 864 x 480 x 32 bits/second.  Since the FIFO
> width is
> >> 32 bits, that's
> >
> > I think the DSS fifo entries are 8 bit on omap2/3, 128bits on omap4.
> At
> > least those are the "units" used with fifo size, threshold sizes,
> burst
> > size, etc.
> >
> >>    864 x 480 = 414 780 FIFO entries/second, or
> >>
> >>    (1 000 000 µs/s / 414 780 FIFO entries/s) = ~2.411 µs/FIFO
> entry.
> >>
> >> So if you need a low FIFO threshold at 960 entries, you could call
> the
> >> device PM QoS functions to set a wakeup latency constraint for the
> >> interconnect would be nothing greater than this:
> >>
> >>    (2.411 µs/FIFO entry * 960 FIFO entries) = 2 314.96 µs
> >>
> >> (The reality is that it would need to be something less than this,
> to
> >> account for the time needed for the GFX DMA transfer to start
> supplying
> >> data, etc.)
> >
> > Makes sense.
> >
> > Another reason for underflows we have is the different rotation
> engines.
> > VRFB on omap2/3, and TILER on omap4. Both increase the "work" needed
> to
> > get pixels, although I'm not sure what the actual causes for the
> > increased work are.
> >
> >> The ultimate goal, with Jean's device PM QoS patches, is that these
> >> constraints could change the DPLL autoidle settings or powerdomain
> states
> >> to ensure the constraint was met.  He's got a page here:
> Indeed! The core code is ready and the OMAP power domains code is
> under review for the moment. The ultimate goal is to split the overall
> latency of a device into the contributors (SW, HW SoC, HW external
> etc.), so the DPLL relock time would be taken into account. However
> without the submitted code in place there is no way to build the
> feature in incremental steps.
> 
> >>
> >>  
> http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
> In the wiki page there is a link to the ELC/Fosdem presentation [1]
> about the new model for the latency.
> [1]
> http://omappedia.org/wiki/File:ELC-2012-jpihet-DeviceLatencyModel.pdf
> 
> >>
> >> (Unfortunately it's not clear what the DPLL autoidle modes and
> voltage
> >> scaling bits are set to for many of the estimates, and we also know
> that
> The code is from an l-o tree + the measurement code in, so the DPLL
> are allowed to auto-idle. In the new model the DPLL relock latency
> contribution should be split from the power domains latency.
> 
> >> there are many software optimizations possible for our idle path.)
> Sure! Recently we have had the case with the C1 cpuidle state.
> Hopefully some simple experimental optimizations did fix the issue.
> 
> Regards,
> Jean
> 
> >>
> >> We're still working on getting the OMAP device PM QoS patches
> merged, but
> >> the Linux core support is there, so you should be able to patch your
> >> drivers to use them -- see for example dev_pm_qos_add_request().
> >
> > Thanks for the pointers, I need to study that.
> >
> >> Just paging through the DSS TRM section, some other settings that
> might be
> >> worth checking are:
> >>
> >> - is DISPC_GFX_ATTRIBUTES.GFXBURSTSIZE set to 16x32?
> >
> > Yes. (8 x 128 on omap4)
> >
> > I presume each DMA burst has a small overhead, so maximizing the
> burst
> > size minimizes the overhead. Do you see any other effect with the
> burst
> > size? I mean, do you see any need to know the burst size value when
> > trying to calculate optimal thresholds?
> >
> >> - is DISPC_GFX_ATTRIBUTES.GFXFIFOPRELOAD set to 1?
> >
> > No. We set it to 0 so that PRELOAD is used. If I've understood right,
> > the problem with using GFXFIFOPRELOAD=1, i.e. high threshold is used
> for
> > preload value, is that the high threshold can be quite high, and the
> > preload needs to happen during vertical blanking. With a small vblank
> > time and high high threshold there may not be enough time for the
> > preload.
> >
> > Then again, I have not verified that. And I'm not sure why it would
> be a
> > problem if the FIFO is not loaded up to the preload value during
> > blanking, presuming we still have enough pixels to proceed normally.
> >
> > For me it would make more sense to always load the fifo to full, so
> > there wouldn't be need for any PRELOAD value at all.
> >
> >> - is DISPC_GFX_PRELOAD.PRELOAD set to the maximum possible value?
> >
> > No, it's left at the default value. But I have tried adjusting this
> (and
> > also changing the GFXFIFOPRELOAD bit), and neither fixed the original
> > problem.
> >
> >> - is DISPC_CONFIG.FIFOFILLING set to 1?
> >
> > No, it's set to 0. With this problem there's only one overlay enabled
> so
> > it shouldn't have any effect.
> >
> >  Tomi
> >
> --
> 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


--
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

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote:
> Was there ever a conclussion to this discussion?
> 
> I'm assuming this is unlikely to be fixed in 3.5?

If by conclusion you mean full understanding and a proper fix, then no.

But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use
DSI_FIFO_BUG workaround only for manual update displays) has been
merged, and that should circumvent the problem.

Are you still seeing problems?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Joe Woodward]

-----Original Message-----
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Jean Pihet <jean.pihet@newoldbits.com>, Paul Walmsley <paul@pwsan.com>, khilman@ti.com, Archit Taneja <a0393947@ti.com>, linux-
omap@vger.kernel.org
Date: Tue, 12 Jun 2012 13:37:04 +0300
Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

> On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote:
> > Was there ever a conclussion to this discussion?
> > 
> > I'm assuming this is unlikely to be fixed in 3.5?
> 
> If by conclusion you mean full understanding and a proper fix, then no.
> 
> But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use
> DSI_FIFO_BUG workaround only for manual update displays) has been
> merged, and that should circumvent the problem.
> 
> Are you still seeing problems?

I haven't tested any kernels since 3.4, I normally wait till a later rc and had missed that patch...

If I have any problems I'll report them, but assume it's fixed otherwise.

Thanks for all the work on getting round this!

Cheers,
Joe

> 
>  Tomi
> 

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen]

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

On Tue, 2012-06-12 at 11:50 +0100, Joe Woodward wrote:
> -----Original Message-----
> From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> To: Joe Woodward <jw@terrafix.co.uk>
> Cc: Jean Pihet <jean.pihet@newoldbits.com>, Paul Walmsley <paul@pwsan.com>, khilman@ti.com, Archit Taneja <a0393947@ti.com>, linux-
> omap@vger.kernel.org
> Date: Tue, 12 Jun 2012 13:37:04 +0300
> Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
> 
> > On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote:
> > > Was there ever a conclussion to this discussion?
> > > 
> > > I'm assuming this is unlikely to be fixed in 3.5?
> > 
> > If by conclusion you mean full understanding and a proper fix, then no.
> > 
> > But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS: use
> > DSI_FIFO_BUG workaround only for manual update displays) has been
> > merged, and that should circumvent the problem.
> > 
> > Are you still seeing problems?
> 
> I haven't tested any kernels since 3.4, I normally wait till a later rc and had missed that patch...
> 
> If I have any problems I'll report them, but assume it's fixed otherwise.

If the problem is visible on plain 3.4 series (i.e. without any extras,
like PM patch series or such), and the commit fixes the problem, perhaps
I should the patch for 3.4 stable series? The commit applies cleanly to
v3.4.2. 

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]