Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Hell Krzysztof, On 11/22/2014 11:21 AM, Krzysztof Kozlowski wrote: By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Oh crap... I'll look at it on Monday. However I don't have Peach Pi so any information would be useful. Can you post dmesg and your config? (is it exynos_defconfig?) Yes, I'm using exynos_defconfig. I'm testing with latest linux-next, HEAD: commit ed6778a (Add linux-next specific files for 20141121) The boot log of the hang in the Exynos5420 Peach Pit is sent as an attachment. CONFIG_SND_SOC_SNOW was enabled and without clk_ignore_unused. Additionally can you boot the board with DMATEST enabled (without reverting my commit so probably with clk_ignore_unsed and with SND_SNOW disabled) and run dmatest on all channels? Something like: echo 2000 /sys/module/dmatest/parameters/timeout echo 2 /sys/module/dmatest/parameters/iterations for i in `ls /sys/class/dma/` do echo $i /sys/module/dmatest/parameters/channel echo 1 /sys/module/dmatest/parameters/run done ... and post these results also. I'm attaching the log of the tests as well. To run the test CONFIG_SND_SOC_SNOW was disabled and booted with clk_ignore_unused. I will test it on Arndale Octa, maybe the cause is the same. Unfortunately it seems Arndale Octa does not have any sound enabled in DTS so it may be hard to test I2S bus (which is used by audio). Ok, please let me know if you need anything else from me. Best regards, Krzysztof Best regards, Javier U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach CPU:Exynos5420@1800MHz Board: Google Peach Pit, rev 9.0 I2C: ready DRAM: 2 GiB PMIC max77802-pmic initialized CPU:Exynos5420@1800MHz TPS65090 PMIC EC init MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB In:cros-ec-keyb Out: lcd Err: lcd SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB ELOG: Event(17) added with size 13 Net: No ethernet found. Hit any key to stop autoboot: 0 reading uImage 3336553 bytes read in 163 ms (19.5 MiB/s) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux Created: 2014-11-24 8:30:31 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3336489 Bytes = 3.2 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK Loading Kernel Image ... OK Starting kernel ... Timer summary in microseconds: MarkElapsed Stage 0 0 reset 3,471,164 3,471,164 board_init_f 3,567,283 96,119 board_init_r 3,712,040144,757 id=64 3,714,761 2,721 main_loop 4,063,547348,786 bootm_start 4,063,549 2 id=1 4,069,252 5,703 id=2 4,069,254 2 id=3 4,123,769 54,515 id=4 4,123,770 1 id=5 4,123,772 2 id=6 4,123,773 1 id=14 4,225,455101,682 id=7 4,225,465 10 id=15 4,229,519 4,054 start_kernel Accumulated time: 6,956 SPI read cleanup_before_linux_select: Console recording failed (1) [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.18.0-rc5-next-20141121 (javier@minerva) (gcc vers ion 4.6.3 (Debian 4.6.3-14) ) #87 SMP PREEMPT Mon Nov 24 09:09:36 CET 2014 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: Google Peach Pit Rev 6+ [0.00] Ignoring memory range 0x2000 - 0x4000 [0.00] cma: Reserved 64 MiB at 0x9c00 [0.00] Memory policy: Data cache writealloc [0.00] On node 0 totalpages: 393216 [0.00] free_area_init_node: node 0, pgdat c067a000, node_mem_map eebf600 0 [0.00] Normal zone: 1520 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 194560 pages, LIFO batch:31 [0.00] HighMem zone: 1552 pages used for memmap [0.00] HighMem zone: 198656 pages, LIFO batch:31 [0.00] PERCPU: Embedded 9 pages/cpu @eeb7e000 s7616 r8192 d21056 u36864 [0.00] pcpu-alloc: s7616 r8192 d21056 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [0.00] Built 1 zonelists in
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On 11/24/2014 10:38 AM, Javier Martinez Canillas wrote: Hell Krzysztof An unfortunate typo, this was Hello of course :-) Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pią, 2014-11-21 at 21:49 +0100, Javier Martinez Canillas wrote: Hello Kevin, On 11/21/2014 05:38 PM, Kevin Hilman wrote: So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot failures in next-20141121 on the exynos5420-arndale-octa[1]. Adding clk_ignore_unused gets things booting there as well. What's interesting is that my exynos5422-odroid-xu3 is booting fine as well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as exynos5410-smdk5410) Whatever the issue, it definietly seems like a problem that was came through a driver/subsystem tree because that these boards are all booting fine with Kukjin's for-next, arm-soc/for-next and mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without clk_ignore_unused.) For example, just looking at peach-pi across all these trees[2], you can see that it's only failing in linux-next. By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? OK, I got some ideas (no need to run tests mentioned in my previous email). Apparently the mout_audss clock (or one of its parents up to EPLL clock) must be enabled. Configuration like this works: $ cat /sys/kernel/debug/clk/clk_summary fout_epll 11 1 0 0 mout_sclk_epll 11 1 0 0 mout_mau_epll_clk 11 1 0 0 mau_epll 11 1 0 0 mout_audss12 1 0 0 dout_srp 01 1 0 0 adma01 1 0 0 srp_clk 00 1 0 0 dout_aud_bus 00 1 0 0 i2s_bus 00 1 0 0 mout_i2s 00 1 0 0 dout_i2s00 1 0 0 sclk_i2s 00 1 0 0 Reverting my patch enables the adma clock which effectively enables mout_audss. Now I have to find the answer which driver uses epll/audss without enabling it explicitly... Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Ajay, On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: On 11/21/2014 06:32 PM, Ajay kumar wrote: Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I tested your ToT patches on top of next-20141121, this is my git log: 93fe3d7 Revert Revert ARM: exynos_defconfig: Enable options for display panel support 552f74e ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints dbbc293 ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge f29a649 Documentation: bridge: Add documentation for ps8622 DT properties 6ade887 Documentation: devicetree: Add vendor prefix for parade d81c42d Documentation: drm: bridge: move to video/bridge 50b9828 drm/bridge: ptn3460: use gpiod interface 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach f3cf063 drm/bridge: ptn3460: support drm_panel cab682b drm/exynos: dp: support drm_bridge 6e78916 drm/bridge: ptn3460: Convert to i2c driver model 93f4b5f drm/bridge: make bridge registration independent of drm flow 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init eb6996e drm/bridge: ptn3460: Few trivial cleanups c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 51b2c75 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Display works but I needed to revert the mentioned commit, otherwise the boot hangs as reported before. I'm using exynos_defconfig and this kernel command line: console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 10:38 +0100, Javier Martinez Canillas wrote: Hell Krzysztof, On 11/22/2014 11:21 AM, Krzysztof Kozlowski wrote: By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Oh crap... I'll look at it on Monday. However I don't have Peach Pi so any information would be useful. Can you post dmesg and your config? (is it exynos_defconfig?) Yes, I'm using exynos_defconfig. I'm testing with latest linux-next, HEAD: commit ed6778a (Add linux-next specific files for 20141121) The boot log of the hang in the Exynos5420 Peach Pit is sent as an attachment. CONFIG_SND_SOC_SNOW was enabled and without clk_ignore_unused. Additionally can you boot the board with DMATEST enabled (without reverting my commit so probably with clk_ignore_unsed and with SND_SNOW disabled) and run dmatest on all channels? Something like: echo 2000 /sys/module/dmatest/parameters/timeout echo 2 /sys/module/dmatest/parameters/iterations for i in `ls /sys/class/dma/` do echo $i /sys/module/dmatest/parameters/channel echo 1 /sys/module/dmatest/parameters/run done ... and post these results also. I'm attaching the log of the tests as well. To run the test CONFIG_SND_SOC_SNOW was disabled and booted with clk_ignore_unused. I will test it on Arndale Octa, maybe the cause is the same. Unfortunately it seems Arndale Octa does not have any sound enabled in DTS so it may be hard to test I2S bus (which is used by audio). Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Hello Krzysztof, On 11/24/2014 11:13 AM, Krzysztof Kozlowski wrote: Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, On 11/24/2014 11:13 AM, Krzysztof Kozlowski wrote: Ok, please let me know if you need anything else from me. Thanks! I replied before seeing your response. Anyway the dmatests are the same I got on Arndale Octa. It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
[adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On Mon, Nov 24, 2014 at 6:46 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: [adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. We are using one from Google's build-bot: U-Boot 2013.04-g1eced1c (Nov 20 2014 - 21:27:46) for Peach Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? But yes, doing *sound init* do trigger the hang. Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
On pon, 2014-11-24 at 14:16 +0100, Javier Martinez Canillas wrote: [adding Tushar Behera and Doug Anderson to cc list] Hello, On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote: On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, It seems that mau_epll has to be enabled... or something is wrong with clock hierarchy. Another strange thing is that the problem does not happen for some people using the same board, kernel and config options. For example Vivek and Ajay report that they can't reproduce the issue on a Peach Pi using next-20141121 and exynos_defconfig without using clk_ignore_unused. Maybe they have different bootloader which messes here by enabling some clock? Anyway it is reproducible on at least some Arndale Octa (Kevin's and mine) and Peach Pi boards (yours). This issue started to look extremely familiar to me so I searched in my mail inbox and found that the same problem was previously reported by Kevin a couple of months ago [0] and Tushar provided a fix [1]. I tested linux-next + [1] and that indeed fixes the hang on Peach. To save you a click, the problem as explained by Tushar is that the AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when the output of AUDSS mux is gated, no operations can be made on the clocks provided by MAU block. For some reason the kernel just oops so it seems to be a H/W errata? Mike was not fond about the solution proposed in [1] but something along those lines would be needed maybe Tushar can comment on that. Vivek and Ajay, As explained in [0], you are not facing this issue because your RW U-Boot seems to predate when audio support was enabled by default. Can you try executing sound init in the U-Boot prompt and see if that triggers the hang for you? Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html Thank you for digging this out. It looks like mau_epll is needed to keep audio powered on... Disabling the adma device (from DT) helps. But then $ cat /sys/kernel/debug/clk/clk_summary stops working. Just like ISP clocks (need to keep ISP domain on to read clk_summary). When mau_epll is disabled all of reads and writes to Audio registers fail. When system tries to disable unused adma clock it stucks because Audio domain is off... Still this is strange. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Andreas, On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber afaer...@suse.de wrote: Hi, Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas: On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote: On 11/21/2014 06:32 PM, Ajay kumar wrote: I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I tested your ToT patches on top of next-20141121, this is my git log: 93fe3d7 Revert Revert ARM: exynos_defconfig: Enable options for display panel support 552f74e ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints dbbc293 ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints d8687f8 drm/bridge: Add i2c based driver for ps8622/ps8625 bridge f29a649 Documentation: bridge: Add documentation for ps8622 DT properties 6ade887 Documentation: devicetree: Add vendor prefix for parade d81c42d Documentation: drm: bridge: move to video/bridge 50b9828 drm/bridge: ptn3460: use gpiod interface 1274c56 drm/bridge: ptn3460: probe connector at the end of bridge attach f3cf063 drm/bridge: ptn3460: support drm_panel cab682b drm/exynos: dp: support drm_bridge 6e78916 drm/bridge: ptn3460: Convert to i2c driver model 93f4b5f drm/bridge: make bridge registration independent of drm flow 81a038f drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init eb6996e drm/bridge: ptn3460: Few trivial cleanups c41fa5d arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 51b2c75 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Display works but I needed to revert the mentioned commit, otherwise the boot hangs as reported before. I'm using exynos_defconfig and this kernel command line: console=ttySAC3,115200N8 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw I tested Spring with next-20141124, and finally got it to work! :) That's great to hear! Thanks a lot, Ajay and Javier! To be on the safe side, I reverted the patch pointed out by Javier and was still using clk_ignore_unused. Ajay, note that your rebased Snow patch has the last hunk indented one level too deep. Ahh, right. I just saw that. I am not sure if these patches go in just like this, or I need to rebase on top of kukjin's for-next or some other branch/tree! Will take care of this, then. I'll post a cleaned-up bridge patch for Spring later. Ok, AFAIK, peach_pit DT properties can be reused. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
W dniu 21.11.2014 o 21:49, Javier Martinez Canillas pisze: Hello Kevin, On 11/21/2014 05:38 PM, Kevin Hilman wrote: So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot failures in next-20141121 on the exynos5420-arndale-octa[1]. Adding clk_ignore_unused gets things booting there as well. What's interesting is that my exynos5422-odroid-xu3 is booting fine as well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as exynos5410-smdk5410) Whatever the issue, it definietly seems like a problem that was came through a driver/subsystem tree because that these boards are all booting fine with Kukjin's for-next, arm-soc/for-next and mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without clk_ignore_unused.) For example, just looking at peach-pi across all these trees[2], you can see that it's only failing in linux-next. By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Oh crap... I'll look at it on Monday. However I don't have Peach Pi so any information would be useful. Can you post dmesg and your config? (is it exynos_defconfig?) Additionally can you boot the board with DMATEST enabled (without reverting my commit so probably with clk_ignore_unsed and with SND_SNOW disabled) and run dmatest on all channels? Something like: echo 2000 /sys/module/dmatest/parameters/timeout echo 2 /sys/module/dmatest/parameters/iterations for i in `ls /sys/class/dma/` do echo $i /sys/module/dmatest/parameters/channel echo 1 /sys/module/dmatest/parameters/run done ... and post these results also. I will test it on Arndale Octa, maybe the cause is the same. Unfortunately it seems Arndale Octa does not have any sound enabled in DTS so it may be hard to test I2S bus (which is used by audio). Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 06:01 PM, Inki Dae wrote: Ah, sorry. There was my misunderstanding. drm-next already is merged to linux-next so I think we can do the integration test if exynos-drm-next is merged to drm-next earlier. Anyway, I will try to consider your opinion. Cool, having exynos-drm-next in linux-next will be very useful indeed. BTW, I didn't have time to forward port $subject yesterday but Gustavo did and posted a series [0] that supersedes $subjects and also solves other issues. It would be great if you can take a loot to those patches. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39306.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Am 21.11.2014 um 00:49 schrieb Paolo Pisati: vanilla kgene/for-next as of today: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. On Spring, I am able to boot my kgene/for-next based queue with just: mfd: syscon: Decouple syscon interface from platform devices arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the config, while using simplefb rather than the Exynos DRM and thus clk_ignore_unused. Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable module-loading, which is missing in kgene/for-next and -rc5 but is in linux-next.git - it might uncover problems that previously went unnoticed: https://patchwork.kernel.org/patch/5235951/ exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't have it. Regards, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
[adding Kukjin as cc and dropping dri-devel] Hello Kevin, On 11/20/2014 07:22 PM, Kevin Hilman wrote: My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. True, I'm renaming the thread subject to track these issues separately of the original Exynos DRM bug since these are unrelated. So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. Might I also suggest that folks have their default command-line to *not* use clk_ignore_unused, since it's primary job is to workaround clock bugs. Agreed, I disabled now as well to catch regressions early. I carried those parameters from Snow since I needed clk_ignore_unused to have simplefb working on that machine. Kevin Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: [adding Kukjin as cc and dropping dri-devel] Hello Kevin, On 11/20/2014 07:22 PM, Kevin Hilman wrote: My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. True, I'm renaming the thread subject to track these issues separately of the original Exynos DRM bug since these are unrelated. So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot failures in next-20141121 on the exynos5420-arndale-octa[1]. Adding clk_ignore_unused gets things booting there as well. What's interesting is that my exynos5422-odroid-xu3 is booting fine as well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as exynos5410-smdk5410) Whatever the issue, it definietly seems like a problem that was came through a driver/subsystem tree because that these boards are all booting fine with Kukjin's for-next, arm-soc/for-next and mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without clk_ignore_unused.) For example, just looking at peach-pi across all these trees[2], you can see that it's only failing in linux-next. Kevin [1] http://status.armcloud.us/boot/?next-2014112?exynos [2] http://status.armcloud.us/boot/?exynos5800-peach-pi NOTE: the exynos5422-odroid-xu3 is shown as exynos5420-smdk5420 since that's the DTS being used, and exynos5410-odroid-xu is shown as exynos5410-smdk5410, again due to the DTS being used. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Regards, Ajay Kumar On Fri, Nov 21, 2014 at 5:03 PM, Andreas Färber afaer...@suse.de wrote: Am 21.11.2014 um 00:49 schrieb Paolo Pisati: vanilla kgene/for-next as of today: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. On Spring, I am able to boot my kgene/for-next based queue with just: mfd: syscon: Decouple syscon interface from platform devices arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy with DRM_EXYNOS*=y (except IOMMU) and SND_SOC_SNOW=m enabled in the config, while using simplefb rather than the Exynos DRM and thus clk_ignore_unused. Regarding SND_SOC_SNOW: Note that I recently submitted a patch to enable module-loading, which is missing in kgene/for-next and -rc5 but is in linux-next.git - it might uncover problems that previously went unnoticed: https://patchwork.kernel.org/patch/5235951/ exynos_defconfig has SND_SOC_SNOW=y, whereas multi_v7_defconfig doesn't have it. Regards, Andreas -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Tot.tar.bz2 Description: BZip2 compressed data
Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)
Hello Kevin, On 11/21/2014 05:38 PM, Kevin Hilman wrote: So, I see two different boot failures on the Peach Pi[t] Chromebooks: 1) next20141121 boot fails due snd-soc-snow Disabling CONFIG_SND_SOC_SNOW makes the boot to got a little further but still fails with the second issue: 2) next20141121 boot hangs if unused clocks are disabled. I tried to root cause these two issues but didn't see anything evident so I'll find a last known good commit and bisect. If anyone has an idea of the possible causes for these issues that would be appreciated. FWIW, in addition to the failures on 5800/peach-pi, I'm also seeing boot failures in next-20141121 on the exynos5420-arndale-octa[1]. Adding clk_ignore_unused gets things booting there as well. What's interesting is that my exynos5422-odroid-xu3 is booting fine as well as the exynos5420-arndale and the exynos5410-odroid-xu (shown as exynos5410-smdk5410) Whatever the issue, it definietly seems like a problem that was came through a driver/subsystem tree because that these boards are all booting fine with Kukjin's for-next, arm-soc/for-next and mainline/v3.18-rc5 (all with just plain exynos_defconfig, and without clk_ignore_unused.) For example, just looking at peach-pi across all these trees[2], you can see that it's only failing in linux-next. By bisecting I found that the commit introducing both regressions is: ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) By reverting ae43b32, next-20141121 boots with both CONFIG_SND_SOC_SNOW=y and *without* clk_ignore_unused. Krzysztof, I see you are the author of the patch, maybe you can take a look why this is causing regressions in some Exynos boards? Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Ajay, On 11/21/2014 06:32 PM, Ajay kumar wrote: Hi, I have rebased my bridge series on top of linux-next. This is my git log: 4b38a6f Revert Revert ARM: exynos_defconfig: Enable options for display panel support 6fb39a7 ARM: dts: peach-pit: represent the connection between bridge and panel using videoport and endpoints aee649c ARM: dts: snow: represent the connection between bridge and panel using videoport and endpoints 5b76d8d drm/bridge: Add i2c based driver for ps8622/ps8625 bridge 581257f Documentation: bridge: Add documentation for ps8622 DT properties 178e8b9 Documentation: devicetree: Add vendor prefix for parade 0ceea75 Documentation: drm: bridge: move to video/bridge f143e2e drm/bridge: ptn3460: use gpiod interface 2d5cb9d drm/bridge: ptn3460: probe connector at the end of bridge attach 32ac563 drm/bridge: ptn3460: support drm_panel 91c6c30 drm/exynos: dp: support drm_bridge 7eea7eb drm/bridge: ptn3460: Convert to i2c driver model 602f343 drm/bridge: make bridge registration independent of drm flow 14c7143 drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init 2c01ac4 drm/bridge: ptn3460: Few trivial cleanups 7415f6c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 28655d1 drm/exynos: Move platform drivers registration to module init ed6778a Add linux-next specific files for 20141121 I have attached the rebased patches as well. I tested it on snow, peach_pit and peach_pi without *clk_ignore_unused*. Display is totally fine with exynos_defconfig (booting is fine even with CONFIG_SND_SOC_SNOW=y) Thanks for forward porting your patches to linux-next. Unfortunately I won't have time to test them until Monday but I wonder why you didn't have the boot issues that we have with next-20141121. I found that the commit ae43b32 (ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12) had to be reverted in order to boot linux-next. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Javier, On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The only reason i see this fails is since PMU is now requesting the entire memory region with base 0x1004. We should convert the mipi-phy pmu register handling too through syscon. even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Javier,
On 2014년 11월 18일 22:53, Javier Martinez Canillas wrote:
The Exynos DRM driver register its sub-devices platform drivers in
the probe function but after commit 43c0767 (of/platform: Move
platform devices under /sys/devices/platform), this is causing
a deadlock in __driver_attach(). Fix this by moving the platform
drivers registration to exynos_drm_init().
Could you re-base this patch on top of exynos-drm-next? I tried to
separate sub drivers into independent drivers but it seems that we need
more times. So I will merge your patch.
Thanks,
Inki Dae
Suggested-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].
Inki Dae said that he will fix it property by separating the Exynos DRM
driver in different sub-modules but I post this patch as RFC anyways so
others can test if this fixes their boot issue.
[0]: https://lkml.org/lkml/2014/11/6/125
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
drivers/gpu/drm/exynos/exynos_drm_drv.c | 163
1 file changed, 79 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e277d4f..5386fea 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -559,15 +559,58 @@ static const struct component_master_ops exynos_drm_ops
= {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
struct component_match *match;
- int ret;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
+ match = exynos_drm_match_add(pdev-dev);
+ if (IS_ERR(match))
+ return PTR_ERR(match);
+
+ return component_master_add_with_match(pdev-dev, exynos_drm_ops,
+match);
+}
+
+static int exynos_drm_platform_remove(struct platform_device *pdev)
+{
+ component_master_del(pdev-dev, exynos_drm_ops);
+ return 0;
+}
+
+static struct platform_driver exynos_drm_platform_driver = {
+ .probe = exynos_drm_platform_probe,
+ .remove = exynos_drm_platform_remove,
+ .driver = {
+ .name = exynos-drm,
+ .pm = exynos_drm_pm_ops,
+ },
+};
+
+static int exynos_drm_init(void)
+{
+ int ret;
+
+ /*
+ * Register device object only in case of Exynos SoC.
+ *
+ * Below codes resolves temporarily infinite loop issue incurred
+ * by Exynos drm driver when using multi-platform kernel.
+ * So these codes will be replaced with more generic way later.
+ */
+ if (!of_machine_is_compatible(samsung,exynos3)
+ !of_machine_is_compatible(samsung,exynos4)
+ !of_machine_is_compatible(samsung,exynos5))
+ return -ENODEV;
+
+ exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
+ NULL, 0);
+ if (IS_ERR(exynos_drm_pdev))
+ return PTR_ERR(exynos_drm_pdev);
+
#ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(fimd_driver);
if (ret 0)
- return ret;
+ goto err_unregister_pdev;
#endif
#ifdef CONFIG_DRM_EXYNOS_DP
@@ -591,21 +634,10 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_mixer_drv;
#endif
- match = exynos_drm_match_add(pdev-dev);
- if (IS_ERR(match)) {
- ret = PTR_ERR(match);
- goto err_unregister_hdmi_drv;
- }
-
- ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
- match);
- if (ret 0)
- goto err_unregister_hdmi_drv;
-
#ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(g2d_driver);
if (ret 0)
- goto err_del_component_master;
+ goto err_unregister_hdmi_drv;
#endif
#ifdef CONFIG_DRM_EXYNOS_FIMC
@@ -636,9 +668,27 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- return ret;
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+ ret = exynos_drm_probe_vidi();
+ if (ret 0)
+ goto err_unregister_ipp_dev;
+#endif
+
+ ret = platform_driver_register(exynos_drm_platform_driver);
+ if (ret)
+ goto err_remove_vidi;
+
+ return 0;
+
+err_remove_vidi:
+#ifdef CONFIG_DRM_EXYNOS_VIDI
+ exynos_drm_remove_vidi();
+err_unregister_pd:
+#endif
#ifdef CONFIG_DRM_EXYNOS_IPP
+err_unregister_ipp_dev:
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(ipp_driver);
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On 20 November 2014 15:22, Vivek Gautam gautamvivek1...@gmail.com wrote: Hi Javier, On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices This patch has landed in mfd/for-next and linux-next. Without this on kgene/for-next, any driver seeking PMU register via syscon API will fail to get regmap handles. Thanks, Pankaj Dubey So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The only reason i see this fails is since PMU is now requesting the entire memory region with base 0x1004. We should convert the mipi-phy pmu register handling too through syscon. even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 03:07 PM, Inki Dae wrote: Could you re-base this patch on top of exynos-drm-next? I tried to separate sub drivers into independent drivers but it seems that we need more times. So I will merge your patch. Sure, I'll rebase on top of exynos-drm-next and re-post so you can apply it. BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks, Inki Dae Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 04:06 PM, Inki Dae wrote: BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks for information. Actually, I received a similar email privately before. However, exynos-drm-next should go to drm-next first and than to mainline by Dave who is DRM subsystem maintainer. I think all vendor specific drm drivers would need to be checked by drm subsystem maintainer because these changes might be affect drm subsystem or other vendor specific drm drivers before go to mainline. This is orthogonal to the normal upstreaming path. linux-next is an integration tree that is created daily. So all the remote branches are merged and a git tag published. The branch does not get rebased and history is not preserved between two published linux-next tags. This is just to test the integration of different subsystems to be sure that a commit in one tree does not cause a regression in another one so issues can be spot earlier. For example in the case of $subject, a change in the OF caused a regression in the Exynos DRM driver. If needed, I will make a new branch, which is based on top of linux-next so other people can check their systems. You don't really need another branch, git will take care of merge everything in linux-next :) Thanks, Inki Dae Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 are you using a clean exynos_defconfig? don't you need Javier's drm/exynos: Move platform drivers registration to module init patch too? kgene/for-next at: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support plus: 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support hangs with a black screen (albeit backlight seems to be on) on boot. I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW but that didn't help). -- bye, p. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Vivek,
Vivek Gautam gautamvivek1...@gmail.com writes:
[...]
I tested linux-next on Exynos5800 peach-pi board with linux-next and and the
two
patches $Subject and [0].
Below is my git hash:
4d9e6ee drm/exynos: Move platform drivers registration to module init
4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp
phy
36391a5 Add linux-next specific files for 20141119
9b1ced1 Merge branch 'akpm/master'
282497e mm: add strictlimit knob
With this display works for me.
Without $Subject patch i get lookup in drm.
The current linux-next (next-20141120) is still not fully booting for
me. I do see the penguins come up on the display, but it doesn't finish
booting. Full boot log below.
I'm building using exynos_defconfig with CONFIG_SND_SOC_SNOW=n due to
other errors previously reported. (Vivek, BTW, I'm curious how your peach-pi
is booting with the audio support enabled.)
Here's how I'm creating the tree, which appears to be the same as what
you guys are doing, but just to be thorough:
$ git reset --hard next/master
HEAD is now at 5b83d7ad9106 Add linux-next specific files for 20141120
$ pwclient git-am 5197701
Applying patch #5197701 using 'git am'
Description: [v2,2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for
dp phy
Applying: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
$ pwclient git-am 5328881
Applying patch #5328881 using 'git am'
Description: [RFC,1/1] drm/exynos: Move platform drivers registration to module
init
Applying: drm/exynos: Move platform drivers registration to module init
$ git log --oneline -n5
b16800da58a3 drm/exynos: Move platform drivers registration to module init
87541edf8a17 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
5b83d7ad9106 Add linux-next specific files for 20141120
fd7e97b09f45 Merge branch 'akpm/master'
11729160b2d7 mm: add strictlimit knob
Kevin
[1]
Connected to chromebook2 console [channel connected] (~$quit to exit)
(user:khilman) is already connected
# PYBOOT: console: connected.
~$hardreset
Command(chromebook2 console) hardreset
(user:khilman) Reboot chromebook2
Reboot: chromebook2 ; phidget 4 2 : ('off', 1, 'on')
U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach
CPU:Exynos5422@1800MHz
Board: Google Peach Pi, rev 13.6
I2C: ready
DRAM: 3.5 GiB
PMIC max77802-pmic initialized
CPU:Exynos5422@1800MHz
TPS65090 PMIC EC init
MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:cros-ec-keyb
Out: serial
Err: lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net: No ethernet found.
Hit any key to stop autoboot: 2
# PYBOOT: u-boot: taking control.
0
Exynos DP init done
Peach #
Peach setenv stdout serial
# setenv stdout serialversion
Peach # versionsetenv preboot usb start; sleep 1
U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.7.2_cos_gg_c8f69e0) 4.7.x-google 20130114
(prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22
Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1
console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait
rootfstype=ext3
Peach # setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk
rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3if test -n ${initenv}; then run
initenv; fi
Peach # if test -n ${initenv}; then run initenv; fiif test -n ${preboot}; then
run preboot; fi
Peach # if test -n ${preboot}; then run preboot; fisetenv autoload no; setenv
autoboot no
(Re)start USB...
USB0: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
Peach # dhcp
dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.110
Peach # setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
Peach # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
Peach # tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.110
Filename 'tmp/chromebook2-3T8ptb/uImage-48m8WK'.
Load address: 0x4100
Loading: *#
#
#
##
1.2 MiB/s
done
Bytes transferred = 3473930 (35020a hex)
Peach # printenv bootargs
printenv bootargs
bootargs=console=tty1
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Paolo, On 11/20/2014 04:57 PM, Paolo Pisati wrote: On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 are you using a clean exynos_defconfig? don't you need Javier's drm/exynos: Move platform drivers registration to module init patch too? Since Kukjin's for-next is based on Linux 3.18-rc5, the OF patch that causes the Exynos DRM deadlock is not there. That commit landed in next20141105. kgene/for-next at: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support plus: 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support hangs with a black screen (albeit backlight seems to be on) on boot. I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW but that didn't help). I only tested with next20141120 but Vivek tested with Kukjin for-next AFAIU. What's your kernel command line and u-boot env vars? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
2014-11-21 0:26 GMT+09:00 Javier Martinez Canillas javier.marti...@collabora.co.uk: Hello Inki, On 11/20/2014 04:06 PM, Inki Dae wrote: BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks for information. Actually, I received a similar email privately before. However, exynos-drm-next should go to drm-next first and than to mainline by Dave who is DRM subsystem maintainer. I think all vendor specific drm drivers would need to be checked by drm subsystem maintainer because these changes might be affect drm subsystem or other vendor specific drm drivers before go to mainline. This is orthogonal to the normal upstreaming path. linux-next is an integration tree that is created daily. So all the remote branches are merged and a git tag published. The branch does not get rebased and history is not preserved between two published linux-next tags. This is just to test the integration of different subsystems to be sure that a commit in one tree does not cause a regression in another one so issues can be spot earlier. For example in the case of $subject, a change in the OF caused a regression in the Exynos DRM driver. If needed, I will make a new branch, which is based on top of linux-next so other people can check their systems. You don't really need another branch, git will take care of merge everything in linux-next :) Ah, sorry. There was my misunderstanding. drm-next already is merged to linux-next so I think we can do the integration test if exynos-drm-next is merged to drm-next earlier. Anyway, I will try to consider your opinion. Thanks, Inki Dae Thanks, Inki Dae Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Now, the question is why this does not happen with 3.18-rc+? My guess is that the clock been disabled by the common clock framework got added recently and it used to be unmanaged and left with the state set by the bootloader since the kernel didn't know about it. That's why clk_ignore_unused was not needed. Any ideas? Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. Might I also suggest that folks have their default command-line to *not* use clk_ignore_unused, since it's primary job is to workaround clock bugs. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On Thu, Nov 20, 2014 at 10:22:54AM -0800, Kevin Hilman wrote: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. Might I also suggest that folks have their default command-line to *not* use clk_ignore_unused, since it's primary job is to workaround clock bugs. i'm testing kgene/for-next (not linux-next), with: flag@peachpi:~/linux$ cat /proc/cmdline console=tty1 console=ttySAC3,115200 debug earlyprintk rw rootwait root=/dev/mmcblk1p3 adding clk_ignore_unused didn't make any difference: it hangs on boot showing a black screen with backlight on. vanilla kgene/for-next as of today: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. -- bye, p. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Kevin, On 11/18/2014 11:46 PM, Kevin Hilman wrote: Is anyone at Samsung testing linux-next? If so, on what platforms? It would really be nice if your linux-next work was tested on these publically-available 542x/5800 platforms (peach-pi, peach-pit, odroid-xu3) which would also allow lots of others to help you test and validate. It would also be good to add drm-exynos-next to the daily linux-next build. Currently drm-exynos-next is ahead of linux-next. This patch from Javier for example only applies on linux-next. Which tree is the drm-exynos-next branch in? It is in Inki Dae's drm-exynos tree: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
[adding Paolo and Vivek as cc] Hello, On 11/18/2014 07:41 PM, Kevin Hilman wrote: It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Paolo Pisati pointed out in another thread that he needed the patch [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy is also needed to get display working for exynos on linux-next. I've pinged Kukjin to apply this as a -rc fix since is needed after a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register) landed in 3.18 which broke the Exynos Display Port PHY: exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just $subject and [0] should be enough to have display working on Peach Pi with linux-next but it fails to me with: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The same issue was reported by Paolo a couple of days ago [1]. Vivek, Any idea what could cause this regression on linux-next? As reported by Paolo this works well for me in 3.18-rc5. Best regards, Javier [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: [adding Paolo and Vivek as cc] Hello, On 11/18/2014 07:41 PM, Kevin Hilman wrote: It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Paolo Pisati pointed out in another thread that he needed the patch [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy is also needed to get display working for exynos on linux-next. I've pinged Kukjin to apply this as a -rc fix since is needed after a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register) landed in 3.18 which broke the Exynos Display Port PHY: exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just $subject and [0] should be enough to have display working on Peach Pi Yes, with those two patches, peach-pi display working on v3.18-rc5 for me. with linux-next but it fails to me with: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The same issue was reported by Paolo a couple of days ago [1]. For me, with linux-next, I'm still getting the DRM deadlock. Trying your patch that moves things to module_init gets past the deadlock, but still doesn't boot unless I disable CONFIG_SND_SOC_SNOW. Doing that I see the same video-phy error though. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Kevin Hilman khil...@kernel.org writes: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: [adding Paolo and Vivek as cc] Hello, On 11/18/2014 07:41 PM, Kevin Hilman wrote: It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Paolo Pisati pointed out in another thread that he needed the patch [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy is also needed to get display working for exynos on linux-next. I've pinged Kukjin to apply this as a -rc fix since is needed after a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register) landed in 3.18 which broke the Exynos Display Port PHY: exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just $subject and [0] should be enough to have display working on Peach Pi Yes, with those two patches, peach-pi display working on v3.18-rc5 for me. with linux-next but it fails to me with: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The same issue was reported by Paolo a couple of days ago [1]. For me, with linux-next, I'm still getting the DRM deadlock. Trying your patch that moves things to module_init gets past the deadlock, but still doesn't boot unless I disable CONFIG_SND_SOC_SNOW. Doing that I see the same video-phy error though. Another interesting data point is that the 2 patches which get things working on v3.18-rc5, when applied on Kukjin's for-next branch, result in a kernel that boots (which is better than linux-next), but without a working display. :( Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi, On Thu, Nov 20, 2014 at 12:36 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: Hi Javier, Kevin, On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: [adding Paolo and Vivek as cc] Hello, On 11/18/2014 07:41 PM, Kevin Hilman wrote: It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Paolo Pisati pointed out in another thread that he needed the patch [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy is also needed to get display working for exynos on linux-next. I've pinged Kukjin to apply this as a -rc fix since is needed after a5ec598 (phy: exynos-dp-video: Use syscon support to control pmu register) landed in 3.18 which broke the Exynos Display Port PHY: exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just $subject and [0] should be enough to have display working on Peach Pi with linux-next but it fails to me with: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The same issue was reported by Paolo a couple of days ago [1]. Vivek, Any idea what could cause this regression on linux-next? As reported by Paolo this works well for me in 3.18-rc5. I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig With this display works for me. Without $Subject patch i get lookup in drm. Javier can you tell me your git hash. Was it on yesterday's linux-next ? With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The Exynos DRM driver register its sub-devices platform drivers in the probe function but after commit 43c0767 (of/platform: Move platform devices under /sys/devices/platform), this is causing a deadlock in __driver_attach(). Fix this by moving the platform drivers registration to exynos_drm_init(). Suggested-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1]. Inki Dae said that he will fix it property by separating the Exynos DRM driver in different sub-modules but I post this patch as RFC anyways so others can test if this fixes their boot issue. It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Is anyone at Samsung testing linux-next? If so, on what platforms? It would really be nice if your linux-next work was tested on these publically-available 542x/5800 platforms (peach-pi, peach-pit, odroid-xu3) which would also allow lots of others to help you test and validate. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
2014-11-18 Kevin Hilman khil...@kernel.org: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The Exynos DRM driver register its sub-devices platform drivers in the probe function but after commit 43c0767 (of/platform: Move platform devices under /sys/devices/platform), this is causing a deadlock in __driver_attach(). Fix this by moving the platform drivers registration to exynos_drm_init(). Suggested-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1]. Inki Dae said that he will fix it property by separating the Exynos DRM driver in different sub-modules but I post this patch as RFC anyways so others can test if this fixes their boot issue. It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Is anyone at Samsung testing linux-next? If so, on what platforms? It would really be nice if your linux-next work was tested on these publically-available 542x/5800 platforms (peach-pi, peach-pit, odroid-xu3) which would also allow lots of others to help you test and validate. It would also be good to add drm-exynos-next to the daily linux-next build. Currently drm-exynos-next is ahead of linux-next. This patch from Javier for example only applies on linux-next. Gustavo -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Gustavo Padovan gust...@padovan.org writes: 2014-11-18 Kevin Hilman khil...@kernel.org: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: The Exynos DRM driver register its sub-devices platform drivers in the probe function but after commit 43c0767 (of/platform: Move platform devices under /sys/devices/platform), this is causing a deadlock in __driver_attach(). Fix this by moving the platform drivers registration to exynos_drm_init(). Suggested-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1]. Inki Dae said that he will fix it property by separating the Exynos DRM driver in different sub-modules but I post this patch as RFC anyways so others can test if this fixes their boot issue. It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then it proceeds to panic in the workqueue code called by the asoc max98090 codec[1]. If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell, but I still don't have display output. Is anyone at Samsung testing linux-next? If so, on what platforms? It would really be nice if your linux-next work was tested on these publically-available 542x/5800 platforms (peach-pi, peach-pit, odroid-xu3) which would also allow lots of others to help you test and validate. It would also be good to add drm-exynos-next to the daily linux-next build. Currently drm-exynos-next is ahead of linux-next. This patch from Javier for example only applies on linux-next. Which tree is the drm-exynos-next branch in? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
