fsl-dcu not works on latest "drm-next"

fsl-dcu not works on latest "drm-next"

[Meng Yi]

[-- Attachment #1.1: Type: text/plain, Size: 4036 bytes --]

Hi,


I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got some log below. And fsl-dcu not works.

Since "drm-next" merged some branch , use git bisect had some problem ,

so I manually checked out that "fsl-dcu" works at d761701c55a99598477f3cb25c03d939a7711e74

And not works now. some log below:



[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] (drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] (restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] (do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] (do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] (notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] (__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] (blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] (register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] (drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] (drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] (fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] (fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] (platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] (driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] (kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0


And full log in the attachment.

does anybody have any idea about this?

Best Regards,
Meng Yi


[-- Attachment #1.2: Type: text/html, Size: 10690 bytes --]

[-- Attachment #2: ls1021a-twr.log --]
[-- Type: application/octet-stream, Size: 14148 bytes --]

Starting kernel ...

Booting Linux on physical CPU 0xf00
Linux version 4.6.0-rc3+ (yimeng@titan) (gcc version 4.8.3 20131202 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.12 - Linaro GCC 2013.11) ) #189 SMP Fri Apr 29 14:09:18 CST 2016
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=70c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: LS1021A TWR Board
Forcing write-allocate cache policy for SMP
Memory policy: Data cache writealloc
percpu: Embedded 12 pages/cpu @bf7d2000 s19392 r8192 d21568 u49152
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/ram0 rw console=ttyS0,115200
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 984272K/1048576K available (4285K kernel code, 208K rwdata, 1828K rodata, 2048K init, 222K bss, 64304K reserved, 0K cma-reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xc0800000 - 0xff800000   (1008 MB)
    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
    modules : 0x7f800000 - 0x7fe00000   (   6 MB)
      .text : 0x80008000 - 0x807f863c   (8130 kB)
      .init : 0x80800000 - 0x80a00000   (2048 kB)
      .data : 0x80a00000 - 0x80a34300   ( 209 kB)
       .bss : 0x80a36000 - 0x80a6da7c   ( 223 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 32.
        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
Architected cp15 timer(s) running at 12.50MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2e2049cda, max_idle_ns: 440795202628 ns
sched_clock: 56 bits at 12MHz, resolution 80ns, wraps every 4398046511080ns
Switching to timer-based delay loop, resolution 80ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 25.00 BogoMIPS (lpj=125000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
Setting up static identity map for 0x80200000 - 0x8020004c
CPU1: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated (25.00 BogoMIPS).
CPU: All CPU(s) started in HYP mode.
CPU: Virtualization extensions available.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 8 bytes.
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c i2c-0: IMX I2C adapter registered
i2c i2c-0: can't use DMA, using PIO instead.
i2c i2c-1: IMX I2C adapter registered
i2c i2c-1: can't use DMA, using PIO instead.
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 44940K (88000000 - 8abe3000)
hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
futex hash table entries: 512 (order: 3, 32768 bytes)
workingset: timestamp_bits=28 max_order=18 bucket_order=0
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI host bridge /soc/pcie@3400000 ranges:
   IO 0x4000010000..0x400001ffff -> 0x00000000
  MEM 0x4040000000..0x407fffffff -> 0x40000000
layerscape-pcie 3400000.pcie: failed to find msi-parent
layerscape-pcie 3400000.pcie: failed to initialize host
layerscape-pcie: probe of 3400000.pcie failed with error -22
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
console [ttyS0] disabled
21c0500.serial: ttyS0 at MMIO 0x21c0500 (irq = 30, base_baud = 9375000) is a 16550A
console [ttyS0] enabled
21c0600.serial: ttyS1 at MMIO 0x21c0600 (irq = 30, base_baud = 9375000) is a 16550A
2950000.serial: ttyLP0 at MMIO 0x2950000 (irq = 31, base_baud = 6250000) is a FSL_LPUART
fsl-lpuart 2950000.serial: DMA tx channel request failed, operating without tx DMA
fsl-lpuart 2950000.serial: DMA rx channel request failed, operating without rx DMA
[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] (drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] (restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] (do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] (do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] (notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] (__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] (blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] (register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] (drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] (drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] (fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] (fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] (platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] (driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] (kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0
brd: module loaded
loop: module loaded
60000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000089 Chip ID 0x00227e
Amd/Fujitsu Extended Query Table at 0x0040
  Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
CAN device driver interface
libphy: Freescale PowerQUICC MII Bus: probed
fsl-gianfar soc:ethernet@2d10000: enabled errata workarounds, flags: 0x4
fsl-gianfar soc:ethernet@2d10000 eth0: mac: 00:04:9f:03:5b:10
fsl-gianfar soc:ethernet@2d10000 eth0: Running with NAPI enabled
fsl-gianfar soc:ethernet@2d10000 eth0: RX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d10000 eth0: RX BD ring size for Q[1]: 256
fsl-gianfar soc:ethernet@2d10000 eth0: TX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d10000 eth0: TX BD ring size for Q[1]: 256
fsl-gianfar soc:ethernet@2d50000: enabled errata workarounds, flags: 0x4
fsl-gianfar soc:ethernet@2d50000 eth1: mac: 00:04:9f:03:5b:11
fsl-gianfar soc:ethernet@2d50000 eth1: Running with NAPI enabled
fsl-gianfar soc:ethernet@2d50000 eth1: RX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d50000 eth1: RX BD ring size for Q[1]: 256
fsl-gianfar soc:ethernet@2d50000 eth1: TX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d50000 eth1: TX BD ring size for Q[1]: 256
fsl-gianfar soc:ethernet@2d90000: enabled errata workarounds, flags: 0x4
fsl-gianfar soc:ethernet@2d90000 eth2: mac: 00:04:9f:03:5b:12
fsl-gianfar soc:ethernet@2d90000 eth2: Running with NAPI enabled
fsl-gianfar soc:ethernet@2d90000 eth2: RX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d90000 eth2: RX BD ring size for Q[1]: 256
fsl-gianfar soc:ethernet@2d90000 eth2: TX BD ring size for Q[0]: 256
fsl-gianfar soc:ethernet@2d90000 eth2: TX BD ring size for Q[1]: 256
pps pps0: new PPS source ptp0
e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f66c hci version 0x100 quirks 0x00010010
xhci-hcd xhci-hcd.0.auto: irq 38, io mem 0x03100000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
ina2xx 0-0040: power monitor ina220 (Rshunt = 1000 uOhm)
ina2xx 0-0041: power monitor ina220 (Rshunt = 1000 uOhm)
watchdog: Invalid min and max timeout values, resetting to 0!
imx2-wdt 2ad0000.watchdog: timeout 60 sec (nowayout=0)
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
sgtl5000 1-000a: sgtl5000 revision 0x11
oprofile: using timer interrupt.
Initializing XFRM netlink socket
NET: Registered protocol family 17
NET: Registered protocol family 15
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
Key type dns_resolver registered
Registering SWP/SWPB emulation handler
hctosys: unable to open rtc device (rtc0)
ALSA device list:
  No soundcards found.
RAMDISK: gzip image found at block 0
usb 1-1: new high-speed USB device number 2 using xhci-hcd
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
EXT4-fs (ram0): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ram0): mounted filesystem without journal. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 2048K (80800000 - 80a00000)
INIT: version 2.88 booting
Starting udev
udevd[106]: starting version 182
Starting Bootlog daemon: bootlogd.
EXT4-fs (ram0): re-mounted. Opts: block_validity,delalloc,barrier,user_xattr
random: dd urandom read with 6 bits of entropy available
Populating dev cache
Configuring network interfaces... udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

Hi Meng, 

Please use plain text mails on mailing lists.

On 2016-05-03 02:26, Meng Yi wrote: 

> Hi, 
> 
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got some log below. And fsl-dcu not works. 
> 
> Since "drm-next" merged some branch , use git bisect had some problem , 
> 
> so I manually checked out that "fsl-dcu" works at d761701c55a99598477f3cb25c03d939a7711e74 

Hm, that commit seems rather unrelated... is that what git bisect told
you?

I guess my last pull request could be related to that, so maybe you can
check those two commits manually:
077d67374e ("drm: rcar-du: Fix compilation warning")
vs.
0449eefe2d ("drm/fsl-dcu: increment version and date")


> 
> And not works now. some log below: 
> 
> [drm] Initialized drm 1.1.0 20060810 
> 
> panel supply power not found, using dummy regulator 
> 
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). 
> 
> [drm] No driver support for vblank timestamp query. 
> 
> ------------[ cut here ]------------ 
> 
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124 
> 
> [CRTC:24] vblank wait timed out 

It seems that interrupt do not work properly. Could it be that work
elsewhere caused that issue? 

--
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Stefan,

> -----Original Message-----
> From: Stefan Agner [mailto:stefan@agner.ch]
> Sent: Wednesday, May 04, 2016 12:08 AM
> To: Meng Yi <meng.yi@nxp.com>
> Cc: dri-devel@lists.freedesktop.org; David Airlie <airlied@linux.ie>;
> airlied@redhat.com
> Subject: Re: fsl-dcu not works on latest "drm-next"
> 
> Hi Meng,
> 
> Please use plain text mails on mailing lists.
> 

Ok, Thanks!

> On 2016-05-03 02:26, Meng Yi wrote:
> 
> > Hi,
> >
> > I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and
> got some log below. And fsl-dcu not works.
> >
> > Since "drm-next" merged some branch , use git bisect had some problem
> > ,
> >
> > so I manually checked out that "fsl-dcu" works at
> > d761701c55a99598477f3cb25c03d939a7711e74
> 
> Hm, that commit seems rather unrelated... is that what git bisect told you?
> 

Yeah, It seems having nothing to do with the issue. 

I manually found that commit, "fsl-dcu" not works at that commit, but works at commit before it.

But I have no idea of this.

> I guess my last pull request could be related to that, so maybe you can check
> those two commits manually:
> 077d67374e ("drm: rcar-du: Fix compilation warning") vs.
> 0449eefe2d ("drm/fsl-dcu: increment version and date")
> 
> 

Thanks, I will check those two commits.

> >
> > And not works now. some log below:
> >
> > [drm] Initialized drm 1.1.0 20060810
> >
> > panel supply power not found, using dummy regulator
> >
> > [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >
> > [drm] No driver support for vblank timestamp query.
> >
> > ------------[ cut here ]------------
> >
> > WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106
> > drm_atomic_helper_wait_for_vblanks+0xff/0x124
> >
> > [CRTC:24] vblank wait timed out
> 
> It seems that interrupt do not work properly. Could it be that work elsewhere
> caused that issue?
> 
I don't know so far.

Thanks,
Meng
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

I found that its regmap endianness issue, so I want to replace the "regmap".

Hi Stefan,
Do you have any idea about this?

Hi Mark,
Regmap endianness issue had caused some other drivers not work, like SPI etc. 
Or this is fixed and I just don't know?

Thanks,
Meng

---------------------------------------------------------------------
From: Meng Yi 
Sent: Tuesday, May 03, 2016 5:27 PM
To: 'dri-devel@lists.freedesktop.org' <dri-devel@lists.freedesktop.org>; David Airlie <airlied@linux.ie>; 'Stefan Agner' <stefan@agner.ch>; 'airlied@redhat.com' <airlied@redhat.com>
Subject: fsl-dcu not works on latest "drm-next"

Hi,


I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr, and got some log below. And fsl-dcu not works.

Since "drm-next" merged some branch , use git bisect had some problem ,

so I manually checked out that "fsl-dcu" works at d761701c55a99598477f3cb25c03d939a7711e74

And not works now. some log below:

--------------------------------------------------------------------

[drm] Initialized drm 1.1.0 20060810
panel supply power not found, using dummy regulator
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106 drm_atomic_helper_wait_for_vblanks+0xff/0x124
[CRTC:24] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
Hardware name: Freescale LS1021A
[<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
[<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
[<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
[<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
[<80211a7f>] (warn_slowpath_fmt) from [<803ca887>] (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
[<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>] (drm_atomic_helper_commit+0x43/0x5c)
[<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>] (restore_fbdev_mode+0xad/0x16e)
[<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
[<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
[<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
[<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
[<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
[<803b6f95>] (do_bind_con_driver) from [<803b7287>] (do_take_over_console+0xcf/0x108)
[<803b7287>] (do_take_over_console) from [<80397549>] (do_fbcon_takeover+0x35/0x7c)
[<80397549>] (do_fbcon_takeover) from [<802229db>] (notifier_call_chain+0x23/0x38)
[<802229db>] (notifier_call_chain) from [<80222b63>] (__blocking_notifier_call_chain+0x27/0x36)
[<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>] (blocking_notifier_call_chain+0xf/0x14)
[<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>] (register_framebuffer+0x179/0x1d0)
[<8039bdf9>] (register_framebuffer) from [<803cd15f>] (drm_fb_helper_initial_config+0x1af/0x200)
[<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>] (drm_fbdev_cma_init+0x67/0xa8)
[<803cd593>] (drm_fbdev_cma_init) from [<803e2269>] (fsl_dcu_fbdev_init+0x11/0x14)
[<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
[<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
[<803d2d51>] (drm_dev_register) from [<803e1ab7>] (fsl_dcu_drm_probe+0x193/0x240)
[<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>] (platform_drv_probe+0x33/0x62)
[<803e6d2d>] (platform_drv_probe) from [<803e5e7d>] (driver_probe_device+0xb9/0x1a4)
[<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
[<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
[<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
[<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
[<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
[<80201517>] (do_one_initcall) from [<80800a61>] (kernel_init_freeable+0xd1/0x168)
[<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
[<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
---[ end trace b7946726c4e290c4 ]---
Console: switching to colour frame buffer device 60x34
fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
[drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0


And full log in the attachment.

does anybody have any idea about this?

Best Regards,
Meng Yi

RE: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-24 19:14, Meng Yi wrote:
> I found that its regmap endianness issue, so I want to replace the "regmap".
Hm, replace with what? Note that we need some kind of endianness
convertion since the IP is big endian on LS1021a and little endian on
Vybrid (vf610).

Is it maybe just an issue with regmap/the big-endian property in the
device tree? Maybe this thread is interesting for you:
https://lkml.org/lkml/2016/3/23/233

[adding Alexander Stein, he might be able to tell more about this issue]

--
Stefan

> 
> Hi Stefan,
> Do you have any idea about this?
> 
> Hi Mark,
> Regmap endianness issue had caused some other drivers not work, like SPI etc. 
> Or this is fixed and I just don't know?
> 
> Thanks,
> Meng
> 
> ---------------------------------------------------------------------
> From: Meng Yi 
> Sent: Tuesday, May 03, 2016 5:27 PM
> To: 'dri-devel@lists.freedesktop.org'
> <dri-devel@lists.freedesktop.org>; David Airlie <airlied@linux.ie>;
> 'Stefan Agner' <stefan@agner.ch>; 'airlied@redhat.com'
> <airlied@redhat.com>
> Subject: fsl-dcu not works on latest "drm-next"
> 
> Hi,
> 
> 
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr,
> and got some log below. And fsl-dcu not works.
> 
> Since "drm-next" merged some branch , use git bisect had some problem ,
> 
> so I manually checked out that "fsl-dcu" works at
> d761701c55a99598477f3cb25c03d939a7711e74
> 
> And not works now. some log below:
> 
> --------------------------------------------------------------------
> 
> [drm] Initialized drm 1.1.0 20060810
> panel supply power not found, using dummy regulator
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106
> drm_atomic_helper_wait_for_vblanks+0xff/0x124
> [CRTC:24] vblank wait timed out
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
> Hardware name: Freescale LS1021A
> [<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
> [<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
> [<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
> [<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
> [<80211a7f>] (warn_slowpath_fmt) from [<803ca887>]
> (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
> [<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>]
> (drm_atomic_helper_commit+0x43/0x5c)
> [<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>]
> (restore_fbdev_mode+0xad/0x16e)
> [<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>]
> (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
> [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from
> [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
> [<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
> [<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
> [<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
> [<803b6f95>] (do_bind_con_driver) from [<803b7287>]
> (do_take_over_console+0xcf/0x108)
> [<803b7287>] (do_take_over_console) from [<80397549>]
> (do_fbcon_takeover+0x35/0x7c)
> [<80397549>] (do_fbcon_takeover) from [<802229db>]
> (notifier_call_chain+0x23/0x38)
> [<802229db>] (notifier_call_chain) from [<80222b63>]
> (__blocking_notifier_call_chain+0x27/0x36)
> [<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>]
> (blocking_notifier_call_chain+0xf/0x14)
> [<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>]
> (register_framebuffer+0x179/0x1d0)
> [<8039bdf9>] (register_framebuffer) from [<803cd15f>]
> (drm_fb_helper_initial_config+0x1af/0x200)
> [<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>]
> (drm_fbdev_cma_init+0x67/0xa8)
> [<803cd593>] (drm_fbdev_cma_init) from [<803e2269>]
> (fsl_dcu_fbdev_init+0x11/0x14)
> [<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
> [<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
> [<803d2d51>] (drm_dev_register) from [<803e1ab7>]
> (fsl_dcu_drm_probe+0x193/0x240)
> [<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>]
> (platform_drv_probe+0x33/0x62)
> [<803e6d2d>] (platform_drv_probe) from [<803e5e7d>]
> (driver_probe_device+0xb9/0x1a4)
> [<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
> [<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
> [<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
> [<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
> [<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
> [<80201517>] (do_one_initcall) from [<80800a61>]
> (kernel_init_freeable+0xd1/0x168)
> [<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
> [<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
> ---[ end trace b7946726c4e290c4 ]---
> Console: switching to colour frame buffer device 60x34
> fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
> [drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0
> 
> 
> And full log in the attachment.
> 
> does anybody have any idea about this?
> 
> Best Regards,
> Meng Yi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-24 19:14, Meng Yi wrote:
> I found that its regmap endianness issue, so I want to replace the "regmap".
Hm, replace with what? Note that we need some kind of endianness
convertion since the IP is big endian on LS1021a and little endian on
Vybrid (vf610).

Is it maybe just an issue with regmap/the big-endian property in the
device tree? Maybe this thread is interesting for you:
https://lkml.org/lkml/2016/3/23/233

[adding Alexander Stein, he might be able to tell more about this issue]

--
Stefan

> 
> Hi Stefan,
> Do you have any idea about this?
> 
> Hi Mark,
> Regmap endianness issue had caused some other drivers not work, like SPI etc. 
> Or this is fixed and I just don't know?
> 
> Thanks,
> Meng
> 
> ---------------------------------------------------------------------
> From: Meng Yi 
> Sent: Tuesday, May 03, 2016 5:27 PM
> To: 'dri-devel@lists.freedesktop.org'
> <dri-devel@lists.freedesktop.org>; David Airlie <airlied@linux.ie>;
> 'Stefan Agner' <stefan@agner.ch>; 'airlied@redhat.com'
> <airlied@redhat.com>
> Subject: fsl-dcu not works on latest "drm-next"
> 
> Hi,
> 
> 
> I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr,
> and got some log below. And fsl-dcu not works.
> 
> Since "drm-next" merged some branch , use git bisect had some problem ,
> 
> so I manually checked out that "fsl-dcu" works at
> d761701c55a99598477f3cb25c03d939a7711e74
> 
> And not works now. some log below:
> 
> --------------------------------------------------------------------
> 
> [drm] Initialized drm 1.1.0 20060810
> panel supply power not found, using dummy regulator
> [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [drm] No driver support for vblank timestamp query.
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1106
> drm_atomic_helper_wait_for_vblanks+0xff/0x124
> [CRTC:24] vblank wait timed out
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3+ #189
> Hardware name: Freescale LS1021A
> [<80209a7b>] (unwind_backtrace) from [<8020755f>] (show_stack+0xb/0xc)
> [<8020755f>] (show_stack) from [<803676a3>] (dump_stack+0x5b/0x74)
> [<803676a3>] (dump_stack) from [<80211a37>] (__warn+0x87/0xb0)
> [<80211a37>] (__warn) from [<80211a7f>] (warn_slowpath_fmt+0x1f/0x28)
> [<80211a7f>] (warn_slowpath_fmt) from [<803ca887>]
> (drm_atomic_helper_wait_for_vblanks+0xff/0x124)
> [<803ca887>] (drm_atomic_helper_wait_for_vblanks) from [<803cb307>]
> (drm_atomic_helper_commit+0x43/0x5c)
> [<803cb307>] (drm_atomic_helper_commit) from [<803cbe51>]
> (restore_fbdev_mode+0xad/0x16e)
> [<803cbe51>] (restore_fbdev_mode) from [<803ccf4d>]
> (drm_fb_helper_restore_fbdev_mode_unlocked+0x19/0x44)
> [<803ccf4d>] (drm_fb_helper_restore_fbdev_mode_unlocked) from
> [<803ccf9d>] (drm_fb_helper_set_par+0x25/0x38)
> [<803ccf9d>] (drm_fb_helper_set_par) from [<80397451>] (fbcon_init+0x1fd/0x2c0)
> [<80397451>] (fbcon_init) from [<803b6051>] (visual_init+0x71/0xb4)
> [<803b6051>] (visual_init) from [<803b6f95>] (do_bind_con_driver+0x105/0x1e4)
> [<803b6f95>] (do_bind_con_driver) from [<803b7287>]
> (do_take_over_console+0xcf/0x108)
> [<803b7287>] (do_take_over_console) from [<80397549>]
> (do_fbcon_takeover+0x35/0x7c)
> [<80397549>] (do_fbcon_takeover) from [<802229db>]
> (notifier_call_chain+0x23/0x38)
> [<802229db>] (notifier_call_chain) from [<80222b63>]
> (__blocking_notifier_call_chain+0x27/0x36)
> [<80222b63>] (__blocking_notifier_call_chain) from [<80222b81>]
> (blocking_notifier_call_chain+0xf/0x14)
> [<80222b81>] (blocking_notifier_call_chain) from [<8039bdf9>]
> (register_framebuffer+0x179/0x1d0)
> [<8039bdf9>] (register_framebuffer) from [<803cd15f>]
> (drm_fb_helper_initial_config+0x1af/0x200)
> [<803cd15f>] (drm_fb_helper_initial_config) from [<803cd593>]
> (drm_fbdev_cma_init+0x67/0xa8)
> [<803cd593>] (drm_fbdev_cma_init) from [<803e2269>]
> (fsl_dcu_fbdev_init+0x11/0x14)
> [<803e2269>] (fsl_dcu_fbdev_init) from [<803e18eb>] (fsl_dcu_load+0x81/0xba)
> [<803e18eb>] (fsl_dcu_load) from [<803d2d51>] (drm_dev_register+0x3d/0x68)
> [<803d2d51>] (drm_dev_register) from [<803e1ab7>]
> (fsl_dcu_drm_probe+0x193/0x240)
> [<803e1ab7>] (fsl_dcu_drm_probe) from [<803e6d2d>]
> (platform_drv_probe+0x33/0x62)
> [<803e6d2d>] (platform_drv_probe) from [<803e5e7d>]
> (driver_probe_device+0xb9/0x1a4)
> [<803e5e7d>] (driver_probe_device) from [<803e5fad>] (__driver_attach+0x45/0x58)
> [<803e5fad>] (__driver_attach) from [<803e4eeb>] (bus_for_each_dev+0x3b/0x46)
> [<803e4eeb>] (bus_for_each_dev) from [<803e5897>] (bus_add_driver+0x7b/0x138)
> [<803e5897>] (bus_add_driver) from [<803e6469>] (driver_register+0x4b/0x76)
> [<803e6469>] (driver_register) from [<80201517>] (do_one_initcall+0xb3/0x138)
> [<80201517>] (do_one_initcall) from [<80800a61>]
> (kernel_init_freeable+0xd1/0x168)
> [<80800a61>] (kernel_init_freeable) from [<80558d13>] (kernel_init+0x7/0xb4)
> [<80558d13>] (kernel_init) from [<80205261>] (ret_from_fork+0x11/0x30)
> ---[ end trace b7946726c4e290c4 ]---
> Console: switching to colour frame buffer device 60x34
> fsl-dcu 2ce0000.dcu: fb0:  frame buffer device
> [drm] Initialized fsl-dcu-drm 1.1.0 20160425 on minor 0
> 
> 
> And full log in the attachment.
> 
> does anybody have any idea about this?
> 
> Best Regards,
> Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> On 2016-05-24 19:14, Meng Yi wrote:
> > I found that its regmap endianness issue, so I want to replace the
> > "regmap".
> Hm, replace with what? Note that we need some kind of endianness
> convertion since the IP is big endian on LS1021a and little endian on
> Vybrid (vf610).

Yep, regmap is required and was broken meanwhile but should be fixed now. See 
linked lkml post.

> Is it maybe just an issue with regmap/the big-endian property in the
> device tree? Maybe this thread is interesting for you:
> https://lkml.org/lkml/2016/3/23/233

AFAICT device tree should not been changed here. The "big-endian" property was 
there fromt he beginning.

> > I just tested the latest drm-next branch on Freescale/NXP ls1021a-twr,
> > and got some log below. And fsl-dcu not works.
> > 
> > Since "drm-next" merged some branch , use git bisect had some problem ,
> > 
> > so I manually checked out that "fsl-dcu" works at
> > d761701c55a99598477f3cb25c03d939a7711e74
> > 
> > And not works now. some log below:

Which commit actually broke your kernel? And where to fetch it from? Is your 
problem really caused by regmap?

Best regards,
Alexander

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Alexander,

> From: Alexander Stein [mailto:alexander.stein@systec-electronic.com]
> Sent: Wednesday, May 25, 2016 4:32 PM
> To: Stefan Agner <stefan@agner.ch>
> Cc: Meng Yi <meng.yi@nxp.com>; dri-devel@lists.freedesktop.org; David Airlie
> <airlied@linux.ie>; airlied@redhat.com; linux-kernel@vger.kernel.org; Mark
> Brown <broonie@kernel.org>
> Subject: Re: fsl-dcu not works on latest "drm-next"
> 
> On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > On 2016-05-24 19:14, Meng Yi wrote:
> > > I found that its regmap endianness issue, so I want to replace the
> > > "regmap".
> > Hm, replace with what? Note that we need some kind of endianness
> > convertion since the IP is big endian on LS1021a and little endian on
> > Vybrid (vf610).
> 
> Yep, regmap is required and was broken meanwhile but should be fixed now.
> See linked lkml post.
> 
> > Is it maybe just an issue with regmap/the big-endian property in the
> > device tree? Maybe this thread is interesting for you:
> > https://lkml.org/lkml/2016/3/23/233
> 
> AFAICT device tree should not been changed here. The "big-endian" property
> was there fromt he beginning.
> 
> > > I just tested the latest drm-next branch on Freescale/NXP
> > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > >
> > > Since "drm-next" merged some branch , use git bisect had some
> > > problem ,
> > >
> > > so I manually checked out that "fsl-dcu" works at
> > > d761701c55a99598477f3cb25c03d939a7711e74
> > >
> > > And not works now. some log below:
> 
> Which commit actually broke your kernel? And where to fetch it from? Is your
> problem really caused by regmap?

Since there are lots of merge commit, I had manually debugged that issue. And yes, it is caused by regmap.
I fetched the kernel from git://people.freedesktop.org/~airlied/linux

Best Regards,
Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

Hi,

On Wednesday 25 May 2016 08:58:31, Meng Yi wrote:
> > On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > > On 2016-05-24 19:14, Meng Yi wrote:
> > > > I found that its regmap endianness issue, so I want to replace the
> > > > "regmap".
> > > 
> > > Hm, replace with what? Note that we need some kind of endianness
> > > convertion since the IP is big endian on LS1021a and little endian on
> > > Vybrid (vf610).
> > 
> > Yep, regmap is required and was broken meanwhile but should be fixed now.
> > See linked lkml post.
> > 
> > > Is it maybe just an issue with regmap/the big-endian property in the
> > > device tree? Maybe this thread is interesting for you:
> > > https://lkml.org/lkml/2016/3/23/233
> > 
> > AFAICT device tree should not been changed here. The "big-endian" property
> > was there fromt he beginning.
> > 
> > > > I just tested the latest drm-next branch on Freescale/NXP
> > > > ls1021a-twr, and got some log below. And fsl-dcu not works.
> > > > 
> > > > Since "drm-next" merged some branch , use git bisect had some
> > > > problem ,
> > > > 
> > > > so I manually checked out that "fsl-dcu" works at
> > > > d761701c55a99598477f3cb25c03d939a7711e74
> > 
> > > > And not works now. some log below:
> > Which commit actually broke your kernel? And where to fetch it from? Is
> > your problem really caused by regmap?
> 
> Since there are lots of merge commit, I had manually debugged that issue.
> And yes, it is caused by regmap. I fetched the kernel from
> git://people.freedesktop.org/~airlied/linux

Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child commit in 
my repo. Both touch only i915 related things. Please do a proper bisect and 
name the offending commit. On which commit you got that backtrace BTW?
>From your backtrace I can't see anything related to regmap.

Best regards,
Alexander

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Alexander,
Thanks for your reply.

> Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> commit in my repo. Both touch only i915 related things. Please do a proper
> bisect and name the offending commit. On which commit you got that
> backtrace BTW?
> From your backtrace I can't see anything related to regmap.
> 

It is weird that using bisect, for the commit log is not linear.
I mean a newer date commit may be merged before an older date commit, when jump to that older date commit, the newer one will be lost, even though it is merged before older one.
So, I think it's difficult to use git bisect.
" d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean between this commit and the next commit, maybe lots of commits are lost. So, it looks like this commit have nothing to do with the problem.

According to the backtrace, looks like the vblank interrupt is not happen or  handled.
Then I found the irq is installed successfully, so the problem seems like the vblank irq is not properly setup. And here is the point , irq initia, irq handler and timing control code are using regmap.

I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" . It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

Since I am not familiar with regmap, hope you can give me some advice.

Thanks,
Best Regards,
Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

On Wednesday 25 May 2016 10:25:29, Meng Yi wrote:
> Hi Alexander,
> Thanks for your reply.
> 
> > Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> > commit in my repo. Both touch only i915 related things. Please do a proper
> > bisect and name the offending commit. On which commit you got that
> > backtrace BTW?
> > From your backtrace I can't see anything related to regmap.
> 
> It is weird that using bisect, for the commit log is not linear.
> I mean a newer date commit may be merged before an older date commit, when
> jump to that older date commit, the newer one will be lost, even though it
> is merged before older one. So, I think it's difficult to use git bisect.
> " d761701c55a99598477f3cb25c03d939a7711e74 " is just an older one, I mean
> between this commit and the next commit, maybe lots of commits are lost.
> So, it looks like this commit have nothing to do with the problem.

Why are commits lost? The order of commit dates is not straightforward, yes, 
but that's not a problem at all.

> According to the backtrace, looks like the vblank interrupt is not happen or
>  handled. Then I found the irq is installed successfully, so the problem
> seems like the vblank irq is not properly setup. And here is the point ,
> irq initia, irq handler and timing control code are using regmap.

>From your backtrace I guess wait_event_timeout is called in some atomic 
context (might_sleep(); is called inside wait_event_timeout). This has nothing 
to do with regmap.

> I read out the value of relevant register using "CodeWarrior TAP", find that
> endianness is not right.
> 
> Then I changed endianness of the value to be written that using "
> regmap_write" . It works. But "regmap_update_bits" still have the problem.
> 
> I had checked log of regmap, and didn't find which commit caused that.

The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923 
("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The commits 
9f9f8b863ad130ec0c25f378bdbad64ba71291de, 
4f7d6dd4df8b388e2056c89b528254cdd79dea2a and 
0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I could 
successfully probe DCU.

Best regards,
Alexander

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Alexander,

> From your backtrace I guess wait_event_timeout is called in some atomic
> context (might_sleep(); is called inside wait_event_timeout). This has nothing
> to do with regmap.
> 

Here is my view of point:
Since IRQ setup codes using regmap, and which is not setup properly, so wait_event_timeout.

> 
> The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> could successfully probe DCU.

Thanks for your information.
DCU was able to  be probed without those patches, and DCU still not works with those patches.

And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

        dcu: dcu@2ce0000 {
            compatible = "fsl,ls1021a-dcu";
            reg = <0x0 0x2ce0000 0x0 0x10000>;
            interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&platform_clk 0>;
            clock-names = "dcu";
            big-endian;
            status = "disabled";
        };

I can't tell the difference of "reg_format_endian" and " val_format_endian ", so I had tried four conditions.

static const struct regmap_config fsl_dcu_regmap_config = {
    .reg_bits = 32,
    .reg_stride = 4,
    .val_bits = 32,
    .cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG,
//  .val_format_endian = REGMAP_ENDIAN_BIG,

    .volatile_reg = fsl_dcu_drm_is_volatile_reg,
};

Thanks,
Best Regards,
Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

On Thursday 26 May 2016 08:18:30, Meng Yi wrote:
> Hi Alexander,
> 
> > From your backtrace I guess wait_event_timeout is called in some atomic
> > context (might_sleep(); is called inside wait_event_timeout). This has
> > nothing to do with regmap.
> 
> Here is my view of point:
> Since IRQ setup codes using regmap, and which is not setup properly, so
> wait_event_timeout.
> > The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> > ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> > commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> > 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> > 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> > could successfully probe DCU.
> 
> Thanks for your information.
> DCU was able to  be probed without those patches, and DCU still not works
> with those patches.

Yes, sure. DCU was probed fine before 
922a9f936e40001f9b921379aab90047d5990923. But this introduced a regression for 
DCU and also DSPI on LS1021A which got fixed by the other 3 named commits.
I didn't try to use DCU for a while, maybe there is another regression.
Please try reverting 2ed94f6fde066fb37bc3553b786edb805561699e
If that helps the device tree probing does not work in regmap_get_val_endian

Best regards,
Alexander

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

On Thursday 26 May 2016 08:18:30, Meng Yi wrote:
> Hi Alexander,
> 
> > From your backtrace I guess wait_event_timeout is called in some atomic
> > context (might_sleep(); is called inside wait_event_timeout). This has
> > nothing to do with regmap.
> 
> Here is my view of point:
> Since IRQ setup codes using regmap, and which is not setup properly, so
> wait_event_timeout.
> > The inital problem came up with 922a9f936e40001f9b921379aab90047d5990923
> > ("regmap: mmio: Convert to regmap_bus and fix accessor usage"). The
> > commits 9f9f8b863ad130ec0c25f378bdbad64ba71291de,
> > 4f7d6dd4df8b388e2056c89b528254cdd79dea2a and
> > 0dbdb76c0ca8e7caf27c9a210f64c4359e2974a4 tried to fix that. With those I
> > could successfully probe DCU.
> 
> Thanks for your information.
> DCU was able to  be probed without those patches, and DCU still not works
> with those patches.

Yes, sure. DCU was probed fine before 
922a9f936e40001f9b921379aab90047d5990923. But this introduced a regression for 
DCU and also DSPI on LS1021A which got fixed by the other 3 named commits.
I didn't try to use DCU for a while, maybe there is another regression.
Please try reverting 2ed94f6fde066fb37bc3553b786edb805561699e
If that helps the device tree probing does not work in regmap_get_val_endian

Best regards,
Alexander

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

On Wed, May 25, 2016 at 02:14:09AM +0000, Meng Yi wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> Regmap endianness issue had caused some other drivers not work, like SPI etc. 
> Or this is fixed and I just don't know?

Without any description of the problem it is difficult to comment.
There were some drivers that were abusing the API by hacking round
things that need fixing (the main one I've seen is reporting things as
big endian instead of native endian to cause two layers of translation
to kick in) and one that was trying to use regmap to represent something
that just fundamentally wasn't a regmap so *any* change in regmap
internals was risky.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

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

On Wed, May 25, 2016 at 02:14:09AM +0000, Meng Yi wrote:

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> Regmap endianness issue had caused some other drivers not work, like SPI etc. 
> Or this is fixed and I just don't know?

Without any description of the problem it is difficult to comment.
There were some drivers that were abusing the API by hacking round
things that need fixing (the main one I've seen is reporting things as
big endian instead of native endian to cause two layers of translation
to kick in) and one that was trying to use regmap to represent something
that just fundamentally wasn't a regmap so *any* change in regmap
internals was risky.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Mark,

> 
> Without any description of the problem it is difficult to comment.
> There were some drivers that were abusing the API by hacking round things
> that need fixing (the main one I've seen is reporting things as big endian
> instead of native endian to cause two layers of translation to kick in) and one
> that was trying to use regmap to represent something that just fundamentally
> wasn't a regmap so *any* change in regmap internals was risky.

I was testing HDMI patches on latest "drm-next" branch, and found that it is not work.
And then I found the base tree was not working too. Then I debugged the base tree.

I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

Then I changed endianness of the value to be written that using " regmap_write" . It works.
But "regmap_update_bits" still have the problem.

I had checked log of regmap, and didn't find which commit caused that.

I am not familiar with regmap, can you give some advices?

Thanks,
Best Regards,
Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 981 bytes --]

On Wed, May 25, 2016 at 09:59:39AM +0000, Meng Yi wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

> Then I changed endianness of the value to be written that using " regmap_write" . It works.
> But "regmap_update_bits" still have the problem.

> I had checked log of regmap, and didn't find which commit caused that.

You've not specifically described the problem here - what are the
endiannesses of both the CPU and the device you're talking to?  What
specifically is the endianess problem you are seeing, what are you
seeing and what do you expect to see?

> I am not familiar with regmap, can you give some advices?

Is the device described in the DT or regmap_config as having the
endianess that it actually has?  

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

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

On Wed, May 25, 2016 at 09:59:39AM +0000, Meng Yi wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> I read out the value of relevant register using "CodeWarrior TAP", find that endianness is not right.

> Then I changed endianness of the value to be written that using " regmap_write" . It works.
> But "regmap_update_bits" still have the problem.

> I had checked log of regmap, and didn't find which commit caused that.

You've not specifically described the problem here - what are the
endiannesses of both the CPU and the device you're talking to?  What
specifically is the endianess problem you are seeing, what are you
seeing and what do you expect to see?

> I am not familiar with regmap, can you give some advices?

Is the device described in the DT or regmap_config as having the
endianess that it actually has?  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Mark,

> You've not specifically described the problem here - what are the endiannesses
> of both the CPU and the device you're talking to?  What specifically is the
> endianess problem you are seeing, what are you seeing and what do you
> expect to see?
> 

The CPU is little endian and the device DCU is big endian, specified big-endian in DTS, 
        
And here is my DTS and regmap_config,

Specified "big-endian" in DTS,

        dcu: dcu@2ce0000 {
            compatible = "fsl,ls1021a-dcu";
            reg = <0x0 0x2ce0000 0x0 0x10000>;
            interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&platform_clk 0>;
            clock-names = "dcu";
            big-endian;
            status = "disabled";
        };

I can't tell the difference of "reg_format_endian" and " val_format_endian ", so I had tried four conditions. And all failed.

static const struct regmap_config fsl_dcu_regmap_config = {
    .reg_bits = 32,
    .reg_stride = 4,
    .val_bits = 32,
    .cache_type = REGCACHE_RBTREE,
//  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian = REGMAP_ENDIAN_BIG,

    .volatile_reg = fsl_dcu_drm_is_volatile_reg, };


I expect that regmap write as big endian, and I am seeing is regmap write as little endian.

Thanks,
Best Regards,
Meng Yi

Re: fsl-dcu not works on latest "drm-next"

[Alexander Stein]

On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
> Hi Mark,
> 
> > You've not specifically described the problem here - what are the
> > endiannesses of both the CPU and the device you're talking to?  What
> > specifically is the endianess problem you are seeing, what are you seeing
> > and what do you expect to see?
> 
> The CPU is little endian and the device DCU is big endian, specified
> big-endian in DTS,
> 
> And here is my DTS and regmap_config,
> 
> Specified "big-endian" in DTS,
> 
>         dcu: dcu@2ce0000 {
>             compatible = "fsl,ls1021a-dcu";
>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>             clocks = <&platform_clk 0>;
>             clock-names = "dcu";
>             big-endian;
>             status = "disabled";
>         };
> 
> I can't tell the difference of "reg_format_endian" and " val_format_endian
> ", so I had tried four conditions. And all failed.
> 
> static const struct regmap_config fsl_dcu_regmap_config = {
>     .reg_bits = 32,
>     .reg_stride = 4,
>     .val_bits = 32,
>     .cache_type = REGCACHE_RBTREE,

This needs to be a flat cache. See https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html or https://lkml.org/lkml/2016/3/24/281
max_register also needs an appropriate value.

> //  .reg_format_endian = REGMAP_ENDIAN_BIG, //  .val_format_endian =
> REGMAP_ENDIAN_BIG,
> 
>     .volatile_reg = fsl_dcu_drm_is_volatile_reg, };
> 
> 
> I expect that regmap write as big endian, and I am seeing is regmap write as
> little endian.

Check your actual regmap reg_write function.

Best regards,
Alexander

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to?  What
>> > specifically is the endianess problem you are seeing, what are you seeing
>> > and what do you expect to see?
>>
>> The CPU is little endian and the device DCU is big endian, specified
>> big-endian in DTS,
>>
>> And here is my DTS and regmap_config,
>>
>> Specified "big-endian" in DTS,
>>
>>         dcu: dcu@2ce0000 {
>>             compatible = "fsl,ls1021a-dcu";
>>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>>             clocks = <&platform_clk 0>;
>>             clock-names = "dcu";
>>             big-endian;
>>             status = "disabled";
>>         };
>>
>> I can't tell the difference of "reg_format_endian" and " val_format_endian
>> ", so I had tried four conditions. And all failed.
>>
>> static const struct regmap_config fsl_dcu_regmap_config = {
>>     .reg_bits = 32,
>>     .reg_stride = 4,
>>     .val_bits = 32,
>>     .cache_type = REGCACHE_RBTREE,
> 
> This needs to be a flat cache. See
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> or https://lkml.org/lkml/2016/3/24/281
> max_register also needs an appropriate value.

FWIW, the latest patch which addresses this issue is Patch 5/6 of this
patchset:
https://lkml.org/lkml/2016/4/19/617

Unfortunately, that patchset missed the 4.7 merge window. I still miss
an Ack for the first patch of this patchset. But should go into the next
release...

--
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to?  What
>> > specifically is the endianess problem you are seeing, what are you seeing
>> > and what do you expect to see?
>>
>> The CPU is little endian and the device DCU is big endian, specified
>> big-endian in DTS,
>>
>> And here is my DTS and regmap_config,
>>
>> Specified "big-endian" in DTS,
>>
>>         dcu: dcu@2ce0000 {
>>             compatible = "fsl,ls1021a-dcu";
>>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>>             clocks = <&platform_clk 0>;
>>             clock-names = "dcu";
>>             big-endian;
>>             status = "disabled";
>>         };
>>
>> I can't tell the difference of "reg_format_endian" and " val_format_endian
>> ", so I had tried four conditions. And all failed.
>>
>> static const struct regmap_config fsl_dcu_regmap_config = {
>>     .reg_bits = 32,
>>     .reg_stride = 4,
>>     .val_bits = 32,
>>     .cache_type = REGCACHE_RBTREE,
> 
> This needs to be a flat cache. See
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> or https://lkml.org/lkml/2016/3/24/281
> max_register also needs an appropriate value.

FWIW, the latest patch which addresses this issue is Patch 5/6 of this
patchset:
https://lkml.org/lkml/2016/4/19/617

Unfortunately, that patchset missed the 4.7 merge window. I still miss
an Ack for the first patch of this patchset. But should go into the next
release...

--
Stefan

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 776 bytes --]

On Thu, May 26, 2016 at 10:54:16PM -0700, Stefan Agner wrote:
> On 2016-05-26 02:11, Alexander Stein wrote:

> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> > or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.

> FWIW, the latest patch which addresses this issue is Patch 5/6 of this
> patchset:
> https://lkml.org/lkml/2016/4/19/617

> Unfortunately, that patchset missed the 4.7 merge window. I still miss
> an Ack for the first patch of this patchset. But should go into the next
> release...

That's another way of addressing it of course, but unless the register
map actually is sparse it's probably still sensible to send the
conversion to flat cache as a fix.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

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

On Thu, May 26, 2016 at 10:54:16PM -0700, Stefan Agner wrote:
> On 2016-05-26 02:11, Alexander Stein wrote:

> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> > or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.

> FWIW, the latest patch which addresses this issue is Patch 5/6 of this
> patchset:
> https://lkml.org/lkml/2016/4/19/617

> Unfortunately, that patchset missed the 4.7 merge window. I still miss
> an Ack for the first patch of this patchset. But should go into the next
> release...

That's another way of addressing it of course, but unless the register
map actually is sparse it's probably still sensible to send the
conversion to flat cache as a fix.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-27 05:20, Mark Brown wrote:
> On Thu, May 26, 2016 at 10:54:16PM -0700, Stefan Agner wrote:
>> On 2016-05-26 02:11, Alexander Stein wrote:
> 
>> > This needs to be a flat cache. See
>> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
>> > or https://lkml.org/lkml/2016/3/24/281
>> > max_register also needs an appropriate value.
> 
>> FWIW, the latest patch which addresses this issue is Patch 5/6 of this
>> patchset:
>> https://lkml.org/lkml/2016/4/19/617
> 
>> Unfortunately, that patchset missed the 4.7 merge window. I still miss
>> an Ack for the first patch of this patchset. But should go into the next
>> release...
> 
> That's another way of addressing it of course, but unless the register
> map actually is sparse it's probably still sensible to send the
> conversion to flat cache as a fix.

The regcache is used for suspend, but the suspend implementation in its
current form is not in not working. Hence I felt it is not worth fixing
part of something which is broken as a whole anyway.

So far I was under the impression the "only" issue using REGCACHE_RBTREE
is that it triggers a warning when enabling lockdep. 

@Alexander, is using REGCACHE_RBTREE an actual problem for the issue
Meng Yi has here?

--
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-27 05:20, Mark Brown wrote:
> On Thu, May 26, 2016 at 10:54:16PM -0700, Stefan Agner wrote:
>> On 2016-05-26 02:11, Alexander Stein wrote:
> 
>> > This needs to be a flat cache. See
>> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
>> > or https://lkml.org/lkml/2016/3/24/281
>> > max_register also needs an appropriate value.
> 
>> FWIW, the latest patch which addresses this issue is Patch 5/6 of this
>> patchset:
>> https://lkml.org/lkml/2016/4/19/617
> 
>> Unfortunately, that patchset missed the 4.7 merge window. I still miss
>> an Ack for the first patch of this patchset. But should go into the next
>> release...
> 
> That's another way of addressing it of course, but unless the register
> map actually is sparse it's probably still sensible to send the
> conversion to flat cache as a fix.

The regcache is used for suspend, but the suspend implementation in its
current form is not in not working. Hence I felt it is not worth fixing
part of something which is broken as a whole anyway.

So far I was under the impression the "only" issue using REGCACHE_RBTREE
is that it triggers a warning when enabling lockdep. 

@Alexander, is using REGCACHE_RBTREE an actual problem for the issue
Meng Yi has here?

--
Stefan

Re: fsl-dcu not works on latest "drm-next"

[Mark Brown]

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

On Fri, May 27, 2016 at 10:36:21AM -0700, Stefan Agner wrote:
> On 2016-05-27 05:20, Mark Brown wrote:

> > That's another way of addressing it of course, but unless the register
> > map actually is sparse it's probably still sensible to send the
> > conversion to flat cache as a fix.

> The regcache is used for suspend, but the suspend implementation in its
> current form is not in not working. Hence I felt it is not worth fixing
> part of something which is broken as a whole anyway.

> So far I was under the impression the "only" issue using REGCACHE_RBTREE
> is that it triggers a warning when enabling lockdep. 

The warning is warning about a real issue that might crop up - it's not
just cosmetic, it's doing allocations inside a spinlock which could
break badly.  Even if it doesn't help this issue I'd recommend getting a
fix in if you can to avoid it blowing up on people (unless the more
complete set of changes can go in as a bugfix of course in which case
it's moot).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to?  What
>> > specifically is the endianess problem you are seeing, what are you seeing
>> > and what do you expect to see?
>>
>> The CPU is little endian and the device DCU is big endian, specified
>> big-endian in DTS,
>>
>> And here is my DTS and regmap_config,
>>
>> Specified "big-endian" in DTS,
>>
>>         dcu: dcu@2ce0000 {
>>             compatible = "fsl,ls1021a-dcu";
>>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>>             clocks = <&platform_clk 0>;
>>             clock-names = "dcu";
>>             big-endian;
>>             status = "disabled";
>>         };
>>
>> I can't tell the difference of "reg_format_endian" and " val_format_endian
>> ", so I had tried four conditions. And all failed.
>>
>> static const struct regmap_config fsl_dcu_regmap_config = {
>>     .reg_bits = 32,
>>     .reg_stride = 4,
>>     .val_bits = 32,
>>     .cache_type = REGCACHE_RBTREE,
> 
> This needs to be a flat cache. See
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> or https://lkml.org/lkml/2016/3/24/281
> max_register also needs an appropriate value.

Ok, since the complete set which switches to the atomic helper is not
stable material (and also won't make it into 4.7 anymore), I created a
seperate bugfix now:
https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html

What I don't quite get yet is the REGCACHE_FLAT influencing the
endianness behavior?

If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch
above?

--
Stefan
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-05-26 02:11, Alexander Stein wrote:
> On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
>> Hi Mark,
>>
>> > You've not specifically described the problem here - what are the
>> > endiannesses of both the CPU and the device you're talking to?  What
>> > specifically is the endianess problem you are seeing, what are you seeing
>> > and what do you expect to see?
>>
>> The CPU is little endian and the device DCU is big endian, specified
>> big-endian in DTS,
>>
>> And here is my DTS and regmap_config,
>>
>> Specified "big-endian" in DTS,
>>
>>         dcu: dcu@2ce0000 {
>>             compatible = "fsl,ls1021a-dcu";
>>             reg = <0x0 0x2ce0000 0x0 0x10000>;
>>             interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>>             clocks = <&platform_clk 0>;
>>             clock-names = "dcu";
>>             big-endian;
>>             status = "disabled";
>>         };
>>
>> I can't tell the difference of "reg_format_endian" and " val_format_endian
>> ", so I had tried four conditions. And all failed.
>>
>> static const struct regmap_config fsl_dcu_regmap_config = {
>>     .reg_bits = 32,
>>     .reg_stride = 4,
>>     .val_bits = 32,
>>     .cache_type = REGCACHE_RBTREE,
> 
> This needs to be a flat cache. See
> https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.html
> or https://lkml.org/lkml/2016/3/24/281
> max_register also needs an appropriate value.

Ok, since the complete set which switches to the atomic helper is not
stable material (and also won't make it into 4.7 anymore), I created a
seperate bugfix now:
https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html

What I don't quite get yet is the REGCACHE_FLAT influencing the
endianness behavior?

If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch
above?

--
Stefan

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Stefan,

Sorry for reply late, I was on PTO. And another PTO on  June 9~11, 2016.UTC+8

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >>     .reg_bits = 32,
> >>     .reg_stride = 4,
> >>     .val_bits = 32,
> >>     .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 

What is bug?

> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 
> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I will test it, and send an e-mail to you by then.

Regards,
Meng

RE: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-06-06 19:16, Meng Yi wrote:
> Hi Stefan,
> 
> Sorry for reply late, I was on PTO. And another PTO on  June 9~11, 2016.UTC+8
> 
>> >> static const struct regmap_config fsl_dcu_regmap_config = {
>> >>     .reg_bits = 32,
>> >>     .reg_stride = 4,
>> >>     .val_bits = 32,
>> >>     .cache_type = REGCACHE_RBTREE,
>> >
>> > This needs to be a flat cache. See
>> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
>> > tml or https://lkml.org/lkml/2016/3/24/281
>> > max_register also needs an appropriate value.
>>
>> Ok, since the complete set which switches to the atomic helper is not stable
>> material (and also won't make it into 4.7 anymore), I created a seperate bugfix
>> now:
>> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
>>
> 
> What is bug?
> 

The bug is that we should not use REGCACHE_RBTREE for MMIO registers...

RE: fsl-dcu not works on latest "drm-next"

[Stefan Agner]

On 2016-06-06 19:16, Meng Yi wrote:
> Hi Stefan,
> 
> Sorry for reply late, I was on PTO. And another PTO on  June 9~11, 2016.UTC+8
> 
>> >> static const struct regmap_config fsl_dcu_regmap_config = {
>> >>     .reg_bits = 32,
>> >>     .reg_stride = 4,
>> >>     .val_bits = 32,
>> >>     .cache_type = REGCACHE_RBTREE,
>> >
>> > This needs to be a flat cache. See
>> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
>> > tml or https://lkml.org/lkml/2016/3/24/281
>> > max_register also needs an appropriate value.
>>
>> Ok, since the complete set which switches to the atomic helper is not stable
>> material (and also won't make it into 4.7 anymore), I created a seperate bugfix
>> now:
>> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
>>
> 
> What is bug?
> 

The bug is that we should not use REGCACHE_RBTREE for MMIO registers...

--
Stefan

RE: fsl-dcu not works on latest "drm-next"

[Meng Yi]

Hi Stefan,

> >> static const struct regmap_config fsl_dcu_regmap_config = {
> >>     .reg_bits = 32,
> >>     .reg_stride = 4,
> >>     .val_bits = 32,
> >>     .cache_type = REGCACHE_RBTREE,
> >
> > This needs to be a flat cache. See
> > https://lists.freedesktop.org/archives/dri-devel/2016-January/099121.h
> > tml or https://lkml.org/lkml/2016/3/24/281
> > max_register also needs an appropriate value.
> 
> Ok, since the complete set which switches to the atomic helper is not stable
> material (and also won't make it into 4.7 anymore), I created a seperate bugfix
> now:
> https://lists.freedesktop.org/archives/dri-devel/2016-June/109625.html
> 
> What I don't quite get yet is the REGCACHE_FLAT influencing the endianness
> behavior?
> 

I think it didn't. And endianness issue have been fixed by regmap maintainer.

> If it is, Meng, can you test again with v4.7-rc1 + the FLAT cache patch above?
> 

I have tested FLAT cache on LS1021A, it works fine. By the way do you have any opinion on LS1021A's
HDMI driver? 

Regards,
Meng