From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> To: Will Deacon <will.deacon@arm.com> Cc: Doug Anderson <dianders@chromium.org>, "kgene.kim@samsung.com" <kgene.kim@samsung.com>, "olof@lixom.net" <olof@lixom.net>, "rahul.sharma@samsung.com" <rahul.sharma@samsung.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger.kernel.org>, Mark Brown <broonie@kernel.org> Subject: Re: Unable to boot mainline on snow chromebook since 3.15 Date: Sun, 07 Sep 2014 11:06:54 +0200 [thread overview] Message-ID: <540C202E.2060009@collabora.co.uk> (raw) In-Reply-To: <CAD=FV=VfioJf9VYoSYL0QBk-bN93-Ecx3=0n9hb5Q4rcx43-_g@mail.gmail.com> [adding Mark Brown to cc since regulators are involved] Hello Will, On 09/05/2014 10:25 PM, Doug Anderson wrote: > Will, > > On Fri, Sep 5, 2014 at 5:22 AM, Will Deacon <will.deacon@arm.com> wrote: >> [Looks like it's not just Rutland that can't spell the address of the >> mailing list today. Fixed here, so please use this post in any replies]. >> >> On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote: >>> Hi all, >>> >>> I'm one of the few, foolish people to try running mainline on my 5250-based >>> Samsung Chromebook (snow). I can live without wireless, usb3 and video >>> acceleration, so actually it makes a reasonable development platform for >>> doing A15-based (micro)-architectural work. >>> >>> However, since 3.15 I've not been able to boot *any* mainline kernels on >>> this board. I did mean to report this earlier, but I have other machines >>> that can run mainline so this has fallen by the wayside. >>> >>> The problems started with 3.16, where simple-fb would fail to initialise >>> and I lost my display. Note that I don't have a serial console on this >>> machine (I looked at the PCB and there's no way I can solder one of those >>> myself :) I bisected the issue at the time, and I could get my display back >>> by removing some of the new regulator and hdmi properties from the DT. At >>> that point, I could boot, but DMA didn't initialise for the MMC controller >>> so I couldn't mount my root filesystem. >>> >>> With 3.17-rc3, it seems a lot worse -- I don't get any output after nv-uboot >>> (i.e. the nv-uboot screen just remains on the display, with the last line >>> reading "Stashed 20 records"). >>> >>> I'd usually try to debug this a bit further, but without a console it's >>> really painful to get anywhere. I've been working with 3.15, but now I'm >>> having to backport patches when I want to test them, which is more effort >>> than I can be bothered with. >>> >>> Is anybody else running mainline on this device and are these known/fixed >>> problems? > > I've added Javier, who says he'll try to take a look at the problem on > Monday. He's got a snow and I think he's got a serial console hooked > up to it (but I don't think he's tried the simplefb workflow). > I'm back from holidays with access to the machine again so I was able to look at your issue. > > He also added the following thoughts: > >> Have you seen the very long "[PATCH 4/4] simplefb: add clock handling >> code" thread [0]?. I wonder if the problem is that the display clocks were >> not known to the kernel before 3.15 but now are getting disabled and thus >> the simplefb driver not working? >> >> So probably is worth to try passing clk_ignore_unused as a parameter to >> the kernel command line. >> >> [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html > So my assumptions was correct and the issue is that the kernel disables the resources (clocks and regulators) needed to have display working and because the simplefb expects the display hardware to have been already initialized by the bootloader/firmware, it simply fails. You didn't face this issue before 3.15 because the default bootargs set by nv_uboot-snow already includes the "clk_ignore_unused" parameter and the kernel didn't know about the regulators but the later changed with commit: b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow") This was included in 3.16, so the mentioned commit is what "broke" your workflow since now the kernel is aware of the tps65090 fet1 and fet6 regulators (used as supply for the the backlight and panel respectively) and disables them because nothing uses them from a kernel POV. You will have the same issue even with 3.15 if you don't pass the "clk_ignore_unused" parameter to the kernel command line. The sunxi folks faced the same issue and tried to solve it by making the simplefb driver to claim the needed resources thus preventing the kernel to disable them due not used. But that spawn the very long thread [0] mentioned above and I've zero interest in joining that discussion... So, following is a workaround patch [1] that just forces the needed regulators to be always-on but I don't think this is the proper solution. The right thing to do IMHO is to use the needed Exynos DRM/KMS patches as Ajay mentioned before since AFAIU the simplefb is only to have a frame-buffer console working on platforms where a KMS/DRM driver is not available yet. But maybe we could add a boot argument similar to "clk_ignore_unused" but for regulators? Something like "regulator_ignore_unused" that would prevent the regulator core to disable unused regulators? If Mark agrees with that idea I'll be glad to propose a patch. Best regards, Javier [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html [1]: >From bdbb3bc1d69c10dce58affe74e6b64636f7810b5 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Date: Sun, 7 Sep 2014 10:58:29 +0200 Subject: [PATCH 1/1] ARM: dts: prevent exynos5250-snow display regulators to be disabled The tps65090 fet1 and fet6 regulators are used in the Exynos5250 based Snow as power supplies for the PWM backlight and LCD panel respectively. The bootloader enables those regulators in order to have display working but the kernel still doesn't support the eDP to LVDS bridge used in the Snow and the display device nodes are not present in the Device Tree so these regulators are disabled. The problem is that the simple frame-buffer driver can't be used anymore since this driver assumes that the display hardware has been initialized before the kernel boots and does not claim any needed resources (regulators, clocks, etc) so the subsystems disabled them if they are not used. This used to work before just because support for the tps65090 PMU was not present in the DT so the kernel didn't know about it. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> --- arch/arm/boot/dts/exynos5250-snow.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts index 2a62459..6a29b44 100644 --- a/arch/arm/boot/dts/exynos5250-snow.dts +++ b/arch/arm/boot/dts/exynos5250-snow.dts @@ -196,6 +196,7 @@ }; fet1 { regulator-name = "vcd_led"; + regulator-always-on; ti,overcurrent-wait = <3>; }; tps65090_fet2: fet2 { @@ -219,6 +220,7 @@ }; fet6 { regulator-name = "lcd_vdd"; + regulator-always-on; ti,overcurrent-wait = <3>; }; tps65090_fet7: fet7 { -- 2.1.0
WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas) To: linux-arm-kernel@lists.infradead.org Subject: Unable to boot mainline on snow chromebook since 3.15 Date: Sun, 07 Sep 2014 11:06:54 +0200 [thread overview] Message-ID: <540C202E.2060009@collabora.co.uk> (raw) In-Reply-To: <CAD=FV=VfioJf9VYoSYL0QBk-bN93-Ecx3=0n9hb5Q4rcx43-_g@mail.gmail.com> [adding Mark Brown to cc since regulators are involved] Hello Will, On 09/05/2014 10:25 PM, Doug Anderson wrote: > Will, > > On Fri, Sep 5, 2014 at 5:22 AM, Will Deacon <will.deacon@arm.com> wrote: >> [Looks like it's not just Rutland that can't spell the address of the >> mailing list today. Fixed here, so please use this post in any replies]. >> >> On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote: >>> Hi all, >>> >>> I'm one of the few, foolish people to try running mainline on my 5250-based >>> Samsung Chromebook (snow). I can live without wireless, usb3 and video >>> acceleration, so actually it makes a reasonable development platform for >>> doing A15-based (micro)-architectural work. >>> >>> However, since 3.15 I've not been able to boot *any* mainline kernels on >>> this board. I did mean to report this earlier, but I have other machines >>> that can run mainline so this has fallen by the wayside. >>> >>> The problems started with 3.16, where simple-fb would fail to initialise >>> and I lost my display. Note that I don't have a serial console on this >>> machine (I looked at the PCB and there's no way I can solder one of those >>> myself :) I bisected the issue at the time, and I could get my display back >>> by removing some of the new regulator and hdmi properties from the DT. At >>> that point, I could boot, but DMA didn't initialise for the MMC controller >>> so I couldn't mount my root filesystem. >>> >>> With 3.17-rc3, it seems a lot worse -- I don't get any output after nv-uboot >>> (i.e. the nv-uboot screen just remains on the display, with the last line >>> reading "Stashed 20 records"). >>> >>> I'd usually try to debug this a bit further, but without a console it's >>> really painful to get anywhere. I've been working with 3.15, but now I'm >>> having to backport patches when I want to test them, which is more effort >>> than I can be bothered with. >>> >>> Is anybody else running mainline on this device and are these known/fixed >>> problems? > > I've added Javier, who says he'll try to take a look at the problem on > Monday. He's got a snow and I think he's got a serial console hooked > up to it (but I don't think he's tried the simplefb workflow). > I'm back from holidays with access to the machine again so I was able to look at your issue. > > He also added the following thoughts: > >> Have you seen the very long "[PATCH 4/4] simplefb: add clock handling >> code" thread [0]?. I wonder if the problem is that the display clocks were >> not known to the kernel before 3.15 but now are getting disabled and thus >> the simplefb driver not working? >> >> So probably is worth to try passing clk_ignore_unused as a parameter to >> the kernel command line. >> >> [0]: https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06623.html > So my assumptions was correct and the issue is that the kernel disables the resources (clocks and regulators) needed to have display working and because the simplefb expects the display hardware to have been already initialized by the bootloader/firmware, it simply fails. You didn't face this issue before 3.15 because the default bootargs set by nv_uboot-snow already includes the "clk_ignore_unused" parameter and the kernel didn't know about the regulators but the later changed with commit: b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow") This was included in 3.16, so the mentioned commit is what "broke" your workflow since now the kernel is aware of the tps65090 fet1 and fet6 regulators (used as supply for the the backlight and panel respectively) and disables them because nothing uses them from a kernel POV. You will have the same issue even with 3.15 if you don't pass the "clk_ignore_unused" parameter to the kernel command line. The sunxi folks faced the same issue and tried to solve it by making the simplefb driver to claim the needed resources thus preventing the kernel to disable them due not used. But that spawn the very long thread [0] mentioned above and I've zero interest in joining that discussion... So, following is a workaround patch [1] that just forces the needed regulators to be always-on but I don't think this is the proper solution. The right thing to do IMHO is to use the needed Exynos DRM/KMS patches as Ajay mentioned before since AFAIU the simplefb is only to have a frame-buffer console working on platforms where a KMS/DRM driver is not available yet. But maybe we could add a boot argument similar to "clk_ignore_unused" but for regulators? Something like "regulator_ignore_unused" that would prevent the regulator core to disable unused regulators? If Mark agrees with that idea I'll be glad to propose a patch. Best regards, Javier [0]: https://www.mail-archive.com/linux-sunxi at googlegroups.com/msg06623.html [1]: >From bdbb3bc1d69c10dce58affe74e6b64636f7810b5 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Date: Sun, 7 Sep 2014 10:58:29 +0200 Subject: [PATCH 1/1] ARM: dts: prevent exynos5250-snow display regulators to be disabled The tps65090 fet1 and fet6 regulators are used in the Exynos5250 based Snow as power supplies for the PWM backlight and LCD panel respectively. The bootloader enables those regulators in order to have display working but the kernel still doesn't support the eDP to LVDS bridge used in the Snow and the display device nodes are not present in the Device Tree so these regulators are disabled. The problem is that the simple frame-buffer driver can't be used anymore since this driver assumes that the display hardware has been initialized before the kernel boots and does not claim any needed resources (regulators, clocks, etc) so the subsystems disabled them if they are not used. This used to work before just because support for the tps65090 PMU was not present in the DT so the kernel didn't know about it. Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> --- arch/arm/boot/dts/exynos5250-snow.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts index 2a62459..6a29b44 100644 --- a/arch/arm/boot/dts/exynos5250-snow.dts +++ b/arch/arm/boot/dts/exynos5250-snow.dts @@ -196,6 +196,7 @@ }; fet1 { regulator-name = "vcd_led"; + regulator-always-on; ti,overcurrent-wait = <3>; }; tps65090_fet2: fet2 { @@ -219,6 +220,7 @@ }; fet6 { regulator-name = "lcd_vdd"; + regulator-always-on; ti,overcurrent-wait = <3>; }; tps65090_fet7: fet7 { -- 2.1.0
next prev parent reply other threads:[~2014-09-07 9:07 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-05 11:57 Unable to boot mainline on snow chromebook since 3.15 Will Deacon 2014-09-05 12:22 ` Will Deacon 2014-09-05 12:22 ` Will Deacon 2014-09-05 13:46 ` Ajay kumar 2014-09-05 13:46 ` Ajay kumar 2014-09-05 13:56 ` Vivek Gautam 2014-09-05 13:56 ` Vivek Gautam 2014-09-08 11:17 ` Will Deacon 2014-09-08 11:17 ` Will Deacon 2014-09-05 14:12 ` Marc Zyngier 2014-09-05 14:12 ` Marc Zyngier 2014-09-05 20:25 ` Doug Anderson 2014-09-05 20:25 ` Doug Anderson 2014-09-07 9:06 ` Javier Martinez Canillas [this message] 2014-09-07 9:06 ` Javier Martinez Canillas 2014-09-07 15:01 ` Mark Brown 2014-09-07 15:01 ` Mark Brown 2014-09-07 15:51 ` Javier Martinez Canillas 2014-09-07 15:51 ` Javier Martinez Canillas 2014-09-07 15:52 ` Tomasz Figa 2014-09-07 15:52 ` Tomasz Figa 2014-09-07 16:12 ` Javier Martinez Canillas 2014-09-07 16:12 ` Javier Martinez Canillas 2014-09-07 16:19 ` Tomasz Figa 2014-09-07 16:19 ` Tomasz Figa 2014-09-07 16:40 ` Javier Martinez Canillas 2014-09-07 16:40 ` Javier Martinez Canillas 2014-09-08 11:21 ` Will Deacon 2014-09-08 11:21 ` Will Deacon 2014-09-08 11:55 ` Javier Martinez Canillas 2014-09-08 11:55 ` Javier Martinez Canillas 2014-09-08 12:46 ` Will Deacon 2014-09-08 12:46 ` Will Deacon 2014-09-08 12:20 ` Grant Likely 2014-09-08 12:20 ` Grant Likely 2014-09-08 13:49 ` Mark Brown 2014-09-08 13:49 ` Mark Brown 2014-09-08 14:05 ` Javier Martinez Canillas 2014-09-08 14:05 ` Javier Martinez Canillas 2014-09-10 11:17 ` Will Deacon 2014-09-10 11:17 ` Will Deacon 2014-09-10 16:03 ` Doug Anderson 2014-09-10 16:03 ` Doug Anderson 2014-09-10 16:23 ` Will Deacon 2014-09-10 16:23 ` Will Deacon 2014-09-08 15:58 ` Doug Anderson 2014-09-08 15:58 ` Doug Anderson 2014-09-08 19:40 ` Grant Likely 2014-09-08 19:40 ` Grant Likely 2014-09-10 13:06 ` Olof Johansson 2014-09-10 13:06 ` Olof Johansson 2014-09-10 14:31 ` Mark Brown 2014-09-10 14:31 ` Mark Brown 2014-09-10 14:56 ` Grant Likely 2014-09-10 14:56 ` Grant Likely 2014-09-10 15:39 ` Mark Brown 2014-09-10 15:39 ` Mark Brown 2014-09-10 16:29 ` Grant Likely 2014-09-10 16:29 ` Grant Likely 2014-09-10 16:45 ` Doug Anderson 2014-09-10 16:45 ` Doug Anderson 2014-09-10 19:45 ` Mark Brown 2014-09-10 19:45 ` Mark Brown 2014-09-10 19:51 ` Doug Anderson 2014-09-10 19:51 ` Doug Anderson 2014-09-10 16:57 ` Mark Brown 2014-09-10 16:57 ` Mark Brown 2014-09-11 9:22 ` Grant Likely 2014-09-11 9:22 ` Grant Likely 2014-09-11 18:03 ` Mark Brown 2014-09-11 18:03 ` Mark Brown 2014-09-11 22:54 ` Doug Anderson 2014-09-11 22:54 ` Doug Anderson 2014-09-29 12:57 ` Thierry Reding 2014-09-29 12:57 ` Thierry Reding 2014-09-29 13:12 ` Grant Likely 2014-09-29 13:12 ` Grant Likely 2014-09-29 16:37 ` Mark Brown 2014-09-29 16:37 ` Mark Brown 2014-09-30 6:12 ` Thierry Reding 2014-09-30 6:12 ` Thierry Reding 2014-09-29 20:46 ` Maxime Ripard 2014-09-29 20:46 ` Maxime Ripard 2014-09-10 16:36 ` Olof Johansson 2014-09-10 16:36 ` Olof Johansson 2014-09-10 18:17 ` Mark Brown 2014-09-10 18:17 ` Mark Brown 2014-09-11 9:06 ` Grant Likely 2014-09-11 9:06 ` Grant Likely 2014-09-11 16:16 ` Mark Brown 2014-09-11 16:16 ` Mark Brown 2014-09-08 4:36 ` Doug Anderson 2014-09-08 4:36 ` Doug Anderson 2014-09-08 6:09 ` Javier Martinez Canillas 2014-09-08 6:09 ` Javier Martinez Canillas 2014-09-08 15:55 ` Doug Anderson 2014-09-08 15:55 ` Doug Anderson 2014-09-08 16:07 ` Will Deacon 2014-09-08 16:07 ` Will Deacon 2014-09-08 16:12 ` Doug Anderson 2014-09-08 16:12 ` Doug Anderson 2014-09-08 10:20 ` Mark Brown 2014-09-08 10:20 ` Mark Brown 2014-09-08 4:43 ` Doug Anderson 2014-09-08 4:43 ` Doug Anderson 2015-01-30 4:56 bruce m beach
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=540C202E.2060009@collabora.co.uk \ --to=javier.martinez@collabora.co.uk \ --cc=broonie@kernel.org \ --cc=dianders@chromium.org \ --cc=kgene.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=olof@lixom.net \ --cc=rahul.sharma@samsung.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.