* Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
@ 2015-07-21 13:19 Krzysztof Kozlowski
2015-07-22 2:02 ` Joonyoung Shim
0 siblings, 1 reply; 8+ messages in thread
From: Krzysztof Kozlowski @ 2015-07-21 13:19 UTC (permalink / raw)
To: Inki Dae, Joonyoung Shim, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
Hi,
Today's linux-next (next-20150721) encounters boot failures on Exynos
Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
commit d80167b85024982c5f18d0481a5c248100360118
Author: Joonyoung Shim <jy0922.shim@samsung.com>
Date: Thu Jul 2 21:49:39 2015 +0900
drm/exynos: remove drm_iommu_attach_device_if_possible
Already drm_iommu_attach_device checks whether support iommu internally.
It should clear channels always regardless iommu support. We didn't know
because we can detect the problem when iommu is enabled, so we don't
have to use drm_iommu_attach_device_if_possible and then we can remove
drm_iommu_attach_device_if_possible and clear_channels function pointer.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
:040000 040000 83379efbf4960f58d680371628ec04387935bd53
da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
Config: exynos
Boot log from Odroid XU3-Lite attached.
Any hints or ideas?
Best regards,
Krzysztof
[-- Attachment #2: odroid-xu3-boot-fail-bisect.txt --]
[-- Type: text/plain, Size: 21307 bytes --]
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x100
[ 0.000000] Linux version 4.2.0-rc2-00314-gd80167b85024 (kozik@kozik-lap) (gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #766 SMP PREEMPT Tue Jul 21 22:12:16 KST 2015
[ 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine model: Hardkernel Odroid XU3 Lite
[ 0.000000] cma: Reserved 64 MiB at 0xba800000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Samsung CPU ID: 0xe5422001
[ 0.000000] Running under secure firmware.
[ 0.000000] PERCPU: Embedded 11 pages/cpu @ee77f000 s15040 r8192 d21824 u45056
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 513040
[ 0.000000] Kernel command line: console=tty1 console=ttySAC2,115200n8 root=/dev/mmcblk0p1 rootwait rw smsc95xx.macaddr=00:1e:06:61:7a:93
[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Memory: 1957712K/2058240K available (6176K kernel code, 314K rwdata, 2232K rodata, 412K init, 8223K bss, 34992K reserved, 65536K cma-reserved, 1230848K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc083e2e8 (8409 kB)
[ 0.000000] .init : 0xc083f000 - 0xc08a6000 ( 412 kB)
[ 0.000000] .data : 0xc08a6000 - 0xc08f4b68 ( 315 kB)
[ 0.000000] .bss : 0xc08f7000 - 0xc10fef60 (8224 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[ 0.000000] Running RCU self tests
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU lockdep checking is enabled.
[ 0.000000] Additional per-CPU info printed with stalls.
[ 0.000000] Build-time adjustment of leaf fanout to 32.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] GIC physical location is 0x10481000
[ 0.000000] L2C: failed to init: -19
[ 0.000000] Switching to timer-based delay loop, resolution 41ns
[ 0.000000] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000008] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000986] Console: colour dummy device 80x30
[ 0.003960] console [tty1] enabled
[ 0.004000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.004063] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.004102] ... MAX_LOCK_DEPTH: 48
[ 0.004140] ... MAX_LOCKDEP_KEYS: 8191
[ 0.004179] ... CLASSHASH_SIZE: 4096
[ 0.004218] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.004258] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.004297] ... CHAINHASH_SIZE: 32768
[ 0.004336] memory used by lock dependency info: 5167 kB
[ 0.004379] per task-struct memory footprint: 1536 bytes
[ 0.004471] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[ 0.004557] pid_max: default: 32768 minimum: 301
[ 0.005348] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.005410] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.008857] CPU: Testing write buffer coherency: ok
[ 0.010644] CPU0: update cpu_capacity 448
[ 0.010702] CPU0: thread -1, cpu 0, socket 1, mpidr 80000100
[ 0.011086] Setting up static identity map for 0x40008280 - 0x400082d8
[ 0.011859] ARM CCI driver probed
[ 0.012195] Exynos MCPM support installed
[ 0.031541] CPU1: update cpu_capacity 1535
[ 0.031549] CPU1: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.036171] CPU2: update cpu_capacity 1535
[ 0.036178] CPU2: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.041090] CPU3: update cpu_capacity 1535
[ 0.041098] CPU3: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.046107] CPU4: update cpu_capacity 1535
[ 0.046115] CPU4: thread -1, cpu 3, socket 0, mpidr 80000003
[ 1.050140] CPU5: failed to come online
[ 1.056187] CPU6: update cpu_capacity 448
[ 1.056197] CPU6: thread -1, cpu 2, socket 1, mpidr 80000102
[ 2.060024] CPU7: failed to come online
[ 2.060216] Brought up 6 CPUs
[ 2.060261] SMP: Total of 6 processors activated (288.00 BogoMIPS).
[ 2.060315] CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x13)
[ 2.060390] CPU: This may indicate a broken bootloader or firmware.
[ 2.063966] devtmpfs: initialized
[ 2.132864] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 3
[ 2.136468] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns
[ 2.140694] pinctrl core: initialized pinctrl subsystem
[ 2.147406] NET: Registered protocol family 16
[ 2.151905] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 2.200134] cpuidle: using governor ladder
[ 2.245028] cpuidle: using governor menu
[ 2.290164] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[ 2.312198] EXYNOS5420 PMU initialized
[ 2.418870] SCSI subsystem initialized
[ 2.420133] usbcore: registered new interface driver usbfs
[ 2.420436] usbcore: registered new interface driver hub
[ 2.421041] usbcore: registered new device driver usb
[ 2.423235] s3c-i2c 12c80000.i2c: slave address 0x00
[ 2.423305] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[ 2.425486] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[ 2.428573] Advanced Linux Sound Architecture Driver Initialized.
[ 2.434156] cfg80211: Calling CRDA to update world regulatory domain
[ 2.435854] clocksource: Switched to clocksource mct-frc
[ 2.493234] NET: Registered protocol family 2
[ 2.495452] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[ 2.495642] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[ 2.498631] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.498799] UDP hash table entries: 512 (order: 3, 40960 bytes)
[ 2.499209] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes)
[ 2.500468] NET: Registered protocol family 1
[ 2.501791] RPC: Registered named UNIX socket transport module.
[ 2.501827] RPC: Registered udp transport module.
[ 2.501856] RPC: Registered tcp transport module.
[ 2.501884] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.511572] futex hash table entries: 2048 (order: 5, 131072 bytes)
[ 2.569584] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[ 2.572635] bounce: pool size: 64 pages
[ 2.572779] io scheduler noop registered
[ 2.572837] io scheduler deadline registered
[ 2.572990] io scheduler cfq registered (default)
[ 2.582301] 12100000.phy supply vbus not found, using dummy regulator
[ 2.582923] 12100000.phy supply vbus-boost not found, using dummy regulator
[ 2.584497] 12500000.phy supply vbus not found, using dummy regulator
[ 2.584769] 12500000.phy supply vbus-boost not found, using dummy regulator
[ 2.600547] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
[ 2.600623] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
[ 2.618206] dma-pl330 121a0000.pdma: Loaded driver for PL330 DMAC-241330
[ 2.618282] dma-pl330 121a0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 2.634973] dma-pl330 121b0000.pdma: Loaded driver for PL330 DMAC-241330
[ 2.635047] dma-pl330 121b0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 2.639911] dma-pl330 10800000.mdma: Loaded driver for PL330 DMAC-241330
[ 2.639982] dma-pl330 10800000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[ 2.952059] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 2.959908] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 58, base_baud = 0) is a S3C6400/10
[ 2.962388] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 59, base_baud = 0) is a S3C6400/10
[ 2.964282] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 60, base_baud = 0) is a S3C6400/10
[ 3.719809] console [ttySAC2] enabled
[ 3.724629] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 61, base_baud = 0) is a S3C6400/10
[ 3.736215] [drm] Initialized drm 1.1.0 20060810
[ 3.746042] exynos-hdmi 14530000.hdmi: Failed to get supply 'vdd': -517
[ 3.751239] [drm:hdmi_probe] *ERROR* failed to get regulators
[ 3.756951] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
[ 3.801430] brd: module loaded
[ 3.826677] loop: module loaded
[ 3.831052] usbcore: registered new interface driver asix
[ 3.835164] usbcore: registered new interface driver ax88179_178a
[ 3.841318] usbcore: registered new interface driver cdc_ether
[ 3.847171] usbcore: registered new interface driver smsc75xx
[ 3.852881] usbcore: registered new interface driver smsc95xx
[ 3.858550] usbcore: registered new interface driver net1080
[ 3.864180] usbcore: registered new interface driver cdc_subset
[ 3.870060] usbcore: registered new interface driver zaurus
[ 3.875714] usbcore: registered new interface driver cdc_ncm
[ 3.883193] usb@12000000 supply vdd33 not found, using dummy regulator
[ 3.888538] usb@12000000 supply vdd10 not found, using dummy regulator
[ 4.099182] usb@12400000 supply vdd33 not found, using dummy regulator
[ 4.104563] usb@12400000 supply vdd10 not found, using dummy regulator
[ 4.318480] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 4.322987] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[ 4.331019] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 4.338967] xhci-hcd xhci-hcd.2.auto: irq 133, io mem 0x12000000
[ 4.345823] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 4.351578] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.358774] usb usb1: Product: xHCI Host Controller
[ 4.363612] usb usb1: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 xhci-hcd
[ 4.370992] usb usb1: SerialNumber: xhci-hcd.2.auto
[ 4.379685] hub 1-0:1.0: USB hub found
[ 4.382297] hub 1-0:1.0: 1 port detected
[ 4.388940] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[ 4.393091] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[ 4.401427] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 4.407424] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.414634] usb usb2: Product: xHCI Host Controller
[ 4.419465] usb usb2: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 xhci-hcd
[ 4.426844] usb usb2: SerialNumber: xhci-hcd.2.auto
[ 4.434244] hub 2-0:1.0: USB hub found
[ 4.436690] hub 2-0:1.0: 1 port detected
[ 4.442455] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 4.446649] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 3
[ 4.454920] xhci-hcd xhci-hcd.5.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 4.462992] xhci-hcd xhci-hcd.5.auto: irq 134, io mem 0x12400000
[ 4.469319] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[ 4.475585] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.482787] usb usb3: Product: xHCI Host Controller
[ 4.488828] usb usb3: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 xhci-hcd
[ 4.494967] usb usb3: SerialNumber: xhci-hcd.5.auto
[ 4.502335] hub 3-0:1.0: USB hub found
[ 4.504710] hub 3-0:1.0: 1 port detected
[ 4.510195] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[ 4.514305] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 4
[ 4.522534] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[ 4.528641] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.535840] usb usb4: Product: xHCI Host Controller
[ 4.540648] usb usb4: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 xhci-hcd
[ 4.548525] usb usb4: SerialNumber: xhci-hcd.5.auto
[ 4.555261] hub 4-0:1.0: USB hub found
[ 4.557659] hub 4-0:1.0: 1 port detected
[ 4.563285] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 4.568430] ehci-exynos: EHCI EXYNOS driver
[ 4.573391] exynos-ehci 12110000.usb: EHCI Host Controller
[ 4.578075] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 5
[ 4.586154] exynos-ehci 12110000.usb: irq 115, io mem 0x12110000
[ 4.600911] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[ 4.606729] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[ 4.612247] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.619439] usb usb5: Product: EHCI Host Controller
[ 4.624282] usb usb5: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 ehci_hcd
[ 4.631658] usb usb5: SerialNumber: 12110000.usb
[ 4.638575] hub 5-0:1.0: USB hub found
[ 4.640991] hub 5-0:1.0: 3 ports detected
[ 4.647897] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 4.652699] ohci-exynos: OHCI EXYNOS driver
[ 4.657370] exynos-ohci 12120000.usb: USB Host Controller
[ 4.662627] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 6
[ 4.670120] exynos-ohci 12120000.usb: irq 115, io mem 0x12120000
[ 4.735443] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 4.740813] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.748570] usb usb6: Product: USB Host Controller
[ 4.752762] usb usb6: Manufacturer: Linux 4.2.0-rc2-00314-gd80167b85024 ohci_hcd
[ 4.760133] usb usb6: SerialNumber: 12120000.usb
[ 4.767058] hub 6-0:1.0: USB hub found
[ 4.769428] hub 6-0:1.0: 3 ports detected
[ 4.776426] usbcore: registered new interface driver usb-storage
[ 4.783077] mousedev: PS/2 mouse device common for all mice
[ 4.790134] s3c-rtc 101e0000.rtc: failed to find rtc source clock
[ 4.795705] i2c /dev entries driver
[ 4.831113] vdd_ldo9: ramp_delay not set
[ 4.847044] vdd_ldo13: ramp_delay not set
[ 4.856549] vdd_ldo15: ramp_delay not set
[ 4.870938] vdd_sd: ramp_delay not set
[ 4.946567] s5m-rtc s2mps14-rtc: rtc core: registered s5m-rtc as rtc0
[ 4.955885] usb 5-1: new high-speed USB device number 2 using exynos-ehci
[ 4.966030] thermal thermal_zone0: failed to read out thermal zone (-22)
[ 4.971375] 10060000.tmu supply vtmu not found, using dummy regulator
[ 4.978490] thermal thermal_zone1: failed to read out thermal zone (-22)
[ 4.984448] 10064000.tmu supply vtmu not found, using dummy regulator
[ 4.991512] thermal thermal_zone2: failed to read out thermal zone (-22)
[ 4.997527] 10068000.tmu supply vtmu not found, using dummy regulator
[ 5.004654] thermal thermal_zone3: failed to read out thermal zone (-22)
[ 5.010609] 1006c000.tmu supply vtmu not found, using dummy regulator
[ 5.018204] thermal thermal_zone4: failed to read out thermal zone (-22)
[ 5.023698] 100a0000.tmu supply vtmu not found, using dummy regulator
[ 5.034329] s3c2410-wdt 101d0000.watchdog: watchdog inactive, reset disabled, irq disabled
[ 5.043796] device-mapper: ioctl: 4.32.0-ioctl (2015-6-26) initialised: dm-devel@redhat.com
[ 5.051898] sdhci: Secure Digital Host Controller Interface driver
[ 5.056863] sdhci: Copyright(c) Pierre Ossman
[ 5.061733] Synopsys Designware Multimedia Card Interface Driver
[ 5.068617] dwmmc_exynos 12200000.mmc: num-slots property not found, assuming 1 slot is available
[ 5.076385] dwmmc_exynos 12200000.mmc: IDMAC supports 32-bit address mode.
[ 5.083058] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[ 5.089315] dwmmc_exynos 12200000.mmc: Version ID is 250a
[ 5.094798] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 90, 64 bit host data width, 64 deep fifo
[ 5.104616] dwmmc_exynos 12200000.mmc: No vmmc regulator found
[ 5.109973] usb 5-1: New USB device found, idVendor=0424, idProduct=9514
[ 5.116615] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 5.116675] dwmmc_exynos 12200000.mmc: No vqmmc regulator found
[ 5.116900] dwmmc_exynos 12200000.mmc: Got CD GPIO
[ 5.117588] dwmmc_exynos 12200000.mmc: allocated mmc-pwrseq
[ 5.143306] hub 5-1:1.0: USB hub found
[ 5.145853] hub 5-1:1.0: 5 ports detected
[ 5.146970] dwmmc_exynos 12200000.mmc: 1 slots initialized
[ 5.148244] dwmmc_exynos 12220000.mmc: num-slots property not found, assuming 1 slot is available
[ 5.148479] dwmmc_exynos 12220000.mmc: IDMAC supports 32-bit address mode.
[ 5.148630] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[ 5.148647] dwmmc_exynos 12220000.mmc: Version ID is 250a
[ 5.148847] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 91, 64 bit host data width, 64 deep fifo
[ 5.148945] dwmmc_exynos 12220000.mmc: No vmmc regulator found
[ 5.148955] dwmmc_exynos 12220000.mmc: No vqmmc regulator found
[ 5.176230] dwmmc_exynos 12220000.mmc: 1 slots initialized
[ 5.181849] usbcore: registered new interface driver usbhid
[ 5.181864] usbhid: USB HID core driver
[ 5.208875] NET: Registered protocol family 10
[ 5.210215] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[ 5.210415] mmc1: new high speed SDHC card at address 0001
[ 5.214325] mmcblk0: mmc1:0001 00000 29.8 GiB
[ 5.214964] NET: Registered protocol family 17
[ 5.215090] NET: Registered protocol family 15
[ 5.216009] Registering SWP/SWPB emulation handler
[ 5.216191] big.LITTLE switcher initializing
[ 5.216201] CPU0 paired with CPU4
[ 5.216214] CPU6 paired with CPU3
[ 5.216226] GIC ID for CPU 0 cluster 1 is 4
[ 5.216237] GIC ID for CPU 0 cluster 0 is 0
[ 5.219472] mmcblk0: p1 p2
[ 5.331816] IRQ50 no longer affine to CPU1
[ 5.332495]
[ 5.332500] ===============================
[ 5.332505] [ INFO: suspicious RCU usage. ]
[ 5.332512] 4.2.0-rc2-00314-gd80167b85024 #766 Not tainted
[ 5.332516] -------------------------------
[ 5.332523] ../kernel/sched/fair.c:5032 suspicious rcu_dereference_check() usage!
[ 5.332528]
[ 5.332528] other info that might help us debug this:
[ 5.332528]
[ 5.332534]
[ 5.332534] RCU used illegally from offline CPU!
[ 5.332534] rcu_scheduler_active = 1, debug_locks = 0
[ 5.332541] 3 locks held by swapper/1/0:
[ 5.332579] #0: ((cpu_died).wait.lock){......}, at: [<c005d140>] complete+0x14/0x44
[ 5.332608] #1: (&p->pi_lock){-.-.-.}, at: [<c00481f4>] try_to_wake_up+0x28/0x384
[ 5.332634] #2: (rcu_read_lock){......}, at: [<c0050d50>] select_task_rq_fair+0x5c/0xa04
[ 5.332639]
[ 5.332639] stack backtrace:
[ 5.332648] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-00314-gd80167b85024 #766
[ 5.332653] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5.332673] [<c0015e9c>] (unwind_backtrace) from [<c0012bd8>] (show_stack+0x10/0x14)
[ 5.332688] [<c0012bd8>] (show_stack) from [<c05d6b08>] (dump_stack+0x70/0xbc)
[ 5.332699] [<c05d6b08>] (dump_stack) from [<c00513d4>] (select_task_rq_fair+0x6e0/0xa04)
[ 5.332711] [<c00513d4>] (select_task_rq_fair) from [<c00482b8>] (try_to_wake_up+0xec/0x384)
[ 5.332723] [<c00482b8>] (try_to_wake_up) from [<c005c940>] (__wake_up_common+0x4c/0x80)
[ 5.332735] [<c005c940>] (__wake_up_common) from [<c005c988>] (__wake_up_locked+0x14/0x1c)
[ 5.332747] [<c005c988>] (__wake_up_locked) from [<c005d160>] (complete+0x34/0x44)
[ 5.332762] [<c005d160>] (complete) from [<c05d0e64>] (cpu_die+0x24/0x84)
[ 5.332775] [<c05d0e64>] (cpu_die) from [<c005d540>] (cpu_startup_entry+0x1fc/0x26c)
[ 5.332786] [<c005d540>] (cpu_startup_entry) from [<4000954c>] (0x4000954c)
[ 5.332821] CPU1: shutdown
[ 5.536906] GIC ID for CPU 1 cluster 0 is 1
[ 5.575879] cfg80211: Calling CRDA to update world regulatory domain
[ 5.596169] IRQ51 no longer affine to CPU2
[ 5.596634] CPU2: shutdown
[ 5.630984] GIC ID for CPU 2 cluster 0 is 2
[ 5.691113] IRQ52 no longer affine to CPU3
[ 5.691534] CPU3: shutdown
[ 5.696908] usb 5-1.1: new high-speed USB device number 3 using exynos-ehci
[ 5.730115] GIC ID for CPU 3 cluster 0 is 3
[ 5.791067] IRQ53 no longer affine to CPU4
[ 5.791482] CPU4: shutdown
[ 5.806427] usb 5-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 5.811944] usb 5-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 5.823573] smsc95xx v1.0.4
[ 5.824502] GIC ID for CPU 2 cluster 1 is 6
[ 5.834471] big.LITTLE switcher initialized
[ 5.840774] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi@14530000[0]' - status (0)
[ 5.851148] 14530000.hdmi supply hdmi-en not found, using dummy regulator
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-21 13:19 Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible" Krzysztof Kozlowski
@ 2015-07-22 2:02 ` Joonyoung Shim
2015-07-22 4:55 ` Inki Dae
0 siblings, 1 reply; 8+ messages in thread
From: Joonyoung Shim @ 2015-07-22 2:02 UTC (permalink / raw)
To: Krzysztof Kozlowski, Inki Dae, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
> Hi,
>
> Today's linux-next (next-20150721) encounters boot failures on Exynos
> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>
> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
> commit d80167b85024982c5f18d0481a5c248100360118
> Author: Joonyoung Shim <jy0922.shim@samsung.com>
> Date: Thu Jul 2 21:49:39 2015 +0900
>
> drm/exynos: remove drm_iommu_attach_device_if_possible
>
> Already drm_iommu_attach_device checks whether support iommu internally.
> It should clear channels always regardless iommu support. We didn't know
> because we can detect the problem when iommu is enabled, so we don't
> have to use drm_iommu_attach_device_if_possible and then we can remove
> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>
> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>
> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>
>
> Config: exynos
> Boot log from Odroid XU3-Lite attached.
>
> Any hints or ideas?
The point that hangs is when accesses fimd register in
fimd_clear_channels function, so i doubt clock setting for fimd.
It's gone something that hangs after i enable gating for ACLK_200_DISP1
clock.
If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
support. Any ideas?
Thanks.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 2:02 ` Joonyoung Shim
@ 2015-07-22 4:55 ` Inki Dae
2015-07-22 8:12 ` Joonyoung Shim
0 siblings, 1 reply; 8+ messages in thread
From: Inki Dae @ 2015-07-22 4:55 UTC (permalink / raw)
To: Joonyoung Shim, Krzysztof Kozlowski, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>
>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>> commit d80167b85024982c5f18d0481a5c248100360118
>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>> Date: Thu Jul 2 21:49:39 2015 +0900
>>
>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>
>> Already drm_iommu_attach_device checks whether support iommu internally.
>> It should clear channels always regardless iommu support. We didn't know
>> because we can detect the problem when iommu is enabled, so we don't
>> have to use drm_iommu_attach_device_if_possible and then we can remove
>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>
>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>
>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>
>>
>> Config: exynos
>> Boot log from Odroid XU3-Lite attached.
>>
>> Any hints or ideas?
>
> The point that hangs is when accesses fimd register in
> fimd_clear_channels function, so i doubt clock setting for fimd.
>
> It's gone something that hangs after i enable gating for ACLK_200_DISP1
> clock.
>
> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
> support. Any ideas?
I think bootloader should have enabled ACLK_200_DISP1 clock and also
device driver should enable all relevant clocks before the device
accesses its own registers.
Best way would be that the clock is enabled by common clock framework
but it seems there is no anything that the clock framework can do it. So
I think what we have to do is to add the clock support to device tree.
Other idea?
Thanks,
Inki Dae
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 4:55 ` Inki Dae
@ 2015-07-22 8:12 ` Joonyoung Shim
2015-07-22 8:22 ` Inki Dae
0 siblings, 1 reply; 8+ messages in thread
From: Joonyoung Shim @ 2015-07-22 8:12 UTC (permalink / raw)
To: Inki Dae, Krzysztof Kozlowski, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 07/22/2015 01:55 PM, Inki Dae wrote:
> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>
>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>> commit d80167b85024982c5f18d0481a5c248100360118
>>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>>> Date: Thu Jul 2 21:49:39 2015 +0900
>>>
>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>
>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>> It should clear channels always regardless iommu support. We didn't know
>>> because we can detect the problem when iommu is enabled, so we don't
>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>
>>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>
>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>
>>>
>>> Config: exynos
>>> Boot log from Odroid XU3-Lite attached.
>>>
>>> Any hints or ideas?
>>
>> The point that hangs is when accesses fimd register in
>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>
>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>> clock.
>>
>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>> support. Any ideas?
>
> I think bootloader should have enabled ACLK_200_DISP1 clock and also
> device driver should enable all relevant clocks before the device
> accesses its own registers.
>
> Best way would be that the clock is enabled by common clock framework
> but it seems there is no anything that the clock framework can do it. So
> I think what we have to do is to add the clock support to device tree.
It's not easy problem to me. Should we add which clock? I think we
cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
hierarchy, right? Then we should control gate clocks, but we have not
controlled any gate clocks using BTS_ prefix.
The clock hierarchy from Exynos5422 user manual,
ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1
Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
just it should be controlled by connector drivers, e.g. dsi, dp because
fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
about this, just i thought that Exynos5 SoCs don't have any gpios for
dpi, so they cannot use dpi, right?).
It needs to probe connector driver like dsi or dp earlier than fimd and
fimd_bind function should return error if connector driver like dsi or
dp was not probed. This is also not easy to me.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 8:12 ` Joonyoung Shim
@ 2015-07-22 8:22 ` Inki Dae
2015-07-22 8:42 ` Joonyoung Shim
0 siblings, 1 reply; 8+ messages in thread
From: Inki Dae @ 2015-07-22 8:22 UTC (permalink / raw)
To: Joonyoung Shim, Krzysztof Kozlowski, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
> On 07/22/2015 01:55 PM, Inki Dae wrote:
>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>> Hi,
>>>>
>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>
>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>>>> Date: Thu Jul 2 21:49:39 2015 +0900
>>>>
>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>
>>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>>> It should clear channels always regardless iommu support. We didn't know
>>>> because we can detect the problem when iommu is enabled, so we don't
>>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>>
>>>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>
>>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>
>>>>
>>>> Config: exynos
>>>> Boot log from Odroid XU3-Lite attached.
>>>>
>>>> Any hints or ideas?
>>>
>>> The point that hangs is when accesses fimd register in
>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>
>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>> clock.
>>>
>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>> support. Any ideas?
>>
>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>> device driver should enable all relevant clocks before the device
>> accesses its own registers.
>>
>> Best way would be that the clock is enabled by common clock framework
>> but it seems there is no anything that the clock framework can do it. So
>> I think what we have to do is to add the clock support to device tree.
>
> It's not easy problem to me. Should we add which clock? I think we
> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
> hierarchy, right? Then we should control gate clocks, but we have not
> controlled any gate clocks using BTS_ prefix.
>
> The clock hierarchy from Exynos5422 user manual,
> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
> HDMI PHY
> MIC1
> DSIM1
> DPTX LINK
> MDNIE1
> SYSMMU_MIXER
> SYSMMU_FIMD1_M0
> SYSMMU_FIMD1_M1
> BTS_TVM0
> BTS_TVM1
> BTS_FIMD1_M0
> BTS_FIMD1_M1
>
> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
> just it should be controlled by connector drivers, e.g. dsi, dp because
> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
> about this, just i thought that Exynos5 SoCs don't have any gpios for
> dpi, so they cannot use dpi, right?).
>
> It needs to probe connector driver like dsi or dp earlier than fimd and
> fimd_bind function should return error if connector driver like dsi or
> dp was not probed. This is also not easy to me.
In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
should be enabled. So I guess the problem would be due to below line of
clk-exynos5420.c,
GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
Can you check it again after modifying it like below?,
GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),
Thanks,
Inki Dae
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 8:22 ` Inki Dae
@ 2015-07-22 8:42 ` Joonyoung Shim
2015-07-22 10:08 ` Inki Dae
0 siblings, 1 reply; 8+ messages in thread
From: Joonyoung Shim @ 2015-07-22 8:42 UTC (permalink / raw)
To: Inki Dae, Krzysztof Kozlowski, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 07/22/2015 05:22 PM, Inki Dae wrote:
> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>>> Hi,
>>>>>
>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>
>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>> Date: Thu Jul 2 21:49:39 2015 +0900
>>>>>
>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>
>>>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>>>> It should clear channels always regardless iommu support. We didn't know
>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>>>
>>>>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>>
>>>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>
>>>>>
>>>>> Config: exynos
>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>
>>>>> Any hints or ideas?
>>>>
>>>> The point that hangs is when accesses fimd register in
>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>
>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>> clock.
>>>>
>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>> support. Any ideas?
>>>
>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>> device driver should enable all relevant clocks before the device
>>> accesses its own registers.
>>>
>>> Best way would be that the clock is enabled by common clock framework
>>> but it seems there is no anything that the clock framework can do it. So
>>> I think what we have to do is to add the clock support to device tree.
>>
>> It's not easy problem to me. Should we add which clock? I think we
>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>> hierarchy, right? Then we should control gate clocks, but we have not
>> controlled any gate clocks using BTS_ prefix.
>>
>> The clock hierarchy from Exynos5422 user manual,
>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>> HDMI PHY
>> MIC1
>> DSIM1
>> DPTX LINK
>> MDNIE1
>> SYSMMU_MIXER
>> SYSMMU_FIMD1_M0
>> SYSMMU_FIMD1_M1
>> BTS_TVM0
>> BTS_TVM1
>> BTS_FIMD1_M0
>> BTS_FIMD1_M1
>>
>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>> just it should be controlled by connector drivers, e.g. dsi, dp because
>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
>> about this, just i thought that Exynos5 SoCs don't have any gpios for
>> dpi, so they cannot use dpi, right?).
>>
>> It needs to probe connector driver like dsi or dp earlier than fimd and
>> fimd_bind function should return error if connector driver like dsi or
>> dp was not probed. This is also not easy to me.
>
> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
> should be enabled. So I guess the problem would be due to below line of
> clk-exynos5420.c,
>
> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
>
> Can you check it again after modifying it like below?,
> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),
No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 8:42 ` Joonyoung Shim
@ 2015-07-22 10:08 ` Inki Dae
2015-07-24 7:34 ` Inki Dae
0 siblings, 1 reply; 8+ messages in thread
From: Inki Dae @ 2015-07-22 10:08 UTC (permalink / raw)
To: Joonyoung Shim, Krzysztof Kozlowski, Seung-Woo Kim
Cc: dri-devel, Kyungmin Park, Kukjin Kim, linux-samsung-soc,
linux-kernel, Marek Szyprowski
On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
> On 07/22/2015 05:22 PM, Inki Dae wrote:
>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>>
>>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>>> Date: Thu Jul 2 21:49:39 2015 +0900
>>>>>>
>>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>>
>>>>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>>>>> It should clear channels always regardless iommu support. We didn't know
>>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>>>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>>>>
>>>>>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>>>
>>>>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>>
>>>>>>
>>>>>> Config: exynos
>>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>>
>>>>>> Any hints or ideas?
>>>>>
>>>>> The point that hangs is when accesses fimd register in
>>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>>
>>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>>> clock.
>>>>>
>>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>>> support. Any ideas?
>>>>
>>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>>> device driver should enable all relevant clocks before the device
>>>> accesses its own registers.
>>>>
>>>> Best way would be that the clock is enabled by common clock framework
>>>> but it seems there is no anything that the clock framework can do it. So
>>>> I think what we have to do is to add the clock support to device tree.
>>>
>>> It's not easy problem to me. Should we add which clock? I think we
>>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>>> hierarchy, right? Then we should control gate clocks, but we have not
>>> controlled any gate clocks using BTS_ prefix.
>>>
>>> The clock hierarchy from Exynos5422 user manual,
>>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>>> HDMI PHY
>>> MIC1
>>> DSIM1
>>> DPTX LINK
>>> MDNIE1
>>> SYSMMU_MIXER
>>> SYSMMU_FIMD1_M0
>>> SYSMMU_FIMD1_M1
>>> BTS_TVM0
>>> BTS_TVM1
>>> BTS_FIMD1_M0
>>> BTS_FIMD1_M1
>>>
>>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>>> just it should be controlled by connector drivers, e.g. dsi, dp because
>>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
>>> about this, just i thought that Exynos5 SoCs don't have any gpios for
>>> dpi, so they cannot use dpi, right?).
>>>
>>> It needs to probe connector driver like dsi or dp earlier than fimd and
>>> fimd_bind function should return error if connector driver like dsi or
>>> dp was not probed. This is also not easy to me.
>>
>> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
>> should be enabled. So I guess the problem would be due to below line of
>> clk-exynos5420.c,
>>
>> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
>>
>> Can you check it again after modifying it like below?,
>> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),
>
> No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
Yes, I checked just it through exynos5420 and exynos5422 document. I
just guessed. So do you mean that aclk200_disp1 affects FIMD controller
even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
strange.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
2015-07-22 10:08 ` Inki Dae
@ 2015-07-24 7:34 ` Inki Dae
0 siblings, 0 replies; 8+ messages in thread
From: Inki Dae @ 2015-07-24 7:34 UTC (permalink / raw)
To: Joonyoung Shim, Krzysztof Kozlowski, Seung-Woo Kim
Cc: linux-samsung-soc, linux-kernel, dri-devel, Kyungmin Park,
Kukjin Kim, Marek Szyprowski
On 2015년 07월 22일 19:08, Inki Dae wrote:
> On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
>> On 07/22/2015 05:22 PM, Inki Dae wrote:
>>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>>>
>>>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>>>> Author: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>>>> Date: Thu Jul 2 21:49:39 2015 +0900
>>>>>>>
>>>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>>>
>>>>>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>>>>>> It should clear channels always regardless iommu support. We didn't know
>>>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>>>>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>>>>>
>>>>>>> Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
>>>>>>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>>>>>>>
>>>>>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>>>
>>>>>>>
>>>>>>> Config: exynos
>>>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>>>
>>>>>>> Any hints or ideas?
>>>>>>
>>>>>> The point that hangs is when accesses fimd register in
>>>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>>>
>>>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>>>> clock.
>>>>>>
>>>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>>>> support. Any ideas?
>>>>>
>>>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>>>> device driver should enable all relevant clocks before the device
>>>>> accesses its own registers.
>>>>>
>>>>> Best way would be that the clock is enabled by common clock framework
>>>>> but it seems there is no anything that the clock framework can do it. So
>>>>> I think what we have to do is to add the clock support to device tree.
>>>>
>>>> It's not easy problem to me. Should we add which clock? I think we
>>>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>>>> hierarchy, right? Then we should control gate clocks, but we have not
>>>> controlled any gate clocks using BTS_ prefix.
>>>>
>>>> The clock hierarchy from Exynos5422 user manual,
>>>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>>>> HDMI PHY
>>>> MIC1
>>>> DSIM1
>>>> DPTX LINK
>>>> MDNIE1
>>>> SYSMMU_MIXER
>>>> SYSMMU_FIMD1_M0
>>>> SYSMMU_FIMD1_M1
>>>> BTS_TVM0
>>>> BTS_TVM1
>>>> BTS_FIMD1_M0
>>>> BTS_FIMD1_M1
>>>>
>>>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>>>> just it should be controlled by connector drivers, e.g. dsi, dp because
>>>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
>>>> about this, just i thought that Exynos5 SoCs don't have any gpios for
>>>> dpi, so they cannot use dpi, right?).
>>>>
>>>> It needs to probe connector driver like dsi or dp earlier than fimd and
>>>> fimd_bind function should return error if connector driver like dsi or
>>>> dp was not probed. This is also not easy to me.
>>>
>>> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
>>> should be enabled. So I guess the problem would be due to below line of
>>> clk-exynos5420.c,
>>>
>>> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
>>>
>>> Can you check it again after modifying it like below?,
>>> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),
>>
>> No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
>
> Yes, I checked just it through exynos5420 and exynos5422 document. I
> just guessed. So do you mean that aclk200_disp1 affects FIMD controller
> even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
> strange.
Root problem was because it had tried to access FIMD registers before
crtc and connector driver binding is completed.
ACLK200_DISP1 will be enabled by connector driver - MIPI-DSI - of FIMD
like above clock hierarchy commented by Joonyoung.
So all we have to do would be,
1. to put off clearing channel and attaching iommu just after the
binding completion between crtc and connector drivers - in case of
Exynos drm driver, the binding is done before modeset operation.
Or 2. to enable FIMD relevant clock gates, BTS_FIMD1_M0/1 in FIMD driver.
In case of number 1, we would need to add a new interface which can
notify that crtc drivers enable their iommu units just after the binding
completion.
In case of number 2, it would mean we should consider to enable relevant
clock gates for other crtc drivers - decon drivers for Exynos5433 and
Exynos7.
I tend to proper number 2 because it's easier way than number 1.
Thanks,
Inki Dae
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-24 7:34 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-21 13:19 Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible" Krzysztof Kozlowski
2015-07-22 2:02 ` Joonyoung Shim
2015-07-22 4:55 ` Inki Dae
2015-07-22 8:12 ` Joonyoung Shim
2015-07-22 8:22 ` Inki Dae
2015-07-22 8:42 ` Joonyoung Shim
2015-07-22 10:08 ` Inki Dae
2015-07-24 7:34 ` Inki Dae
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).