Re: Unable to boot mainline on snow chromebook since 3.15
[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.dea...@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.marti...@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
Re: Unable to boot mainline on snow chromebook since 3.15
On Sun, Sep 07, 2014 at 11:06:54AM +0200, Javier Martinez Canillas wrote: 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. I'm not all that sympathetic to the idea; we already have quite enough quality problems with the way people hook up regulators without providing yet another way for them to hack around things, I'm concerned it'll just make things more fragile as people require magic command line arguments to get things working. signature.asc Description: Digital signature
Re: Unable to boot mainline on snow chromebook since 3.15
Hello Mark, On 09/07/2014 05:01 PM, Mark Brown wrote: On Sun, Sep 07, 2014 at 11:06:54AM +0200, Javier Martinez Canillas wrote: 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. I'm not all that sympathetic to the idea; we already have quite enough quality problems with the way people hook up regulators without providing yet another way for them to hack around things, I'm concerned it'll just make things more fragile as people require magic command line arguments to get things working. I understand your position and I fully agree, I just was thinking aloud. It seems the simplefb approach is somewhat fragile since the driver relies on the bootloader to correctly setup the display hardware and its needed resources (clock, regulators, etc) but also relies on the kernel to not disable those resources even when they are unused from its point of view. So, the best option for Will is to just use Ajay's proposed in-flight Exynos DRM patches or if he really wants to have simplefb working then he can carry the patch I shared to force tps65090 fet1 and fet6 regulators to be always on. 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: Unable to boot mainline on snow chromebook since 3.15
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. So I believe we've got a process issue here. If you don't have normal support for display hardware, but you want to keep the display operational thanks to bootloader already initializing it, you should not add anything to the kernel which breaks it, until full support comes in. This means that respective regulators should be either always-on or not listed at all (I'd favor the former) and respective clocks either somehow enabled at boot-up or completely ignored, including all their parents capable of being gated. Now with regulators this is pretty straightforward, but with clocks I believe it's an open issue. AFAIR we've discussed this on MLs some time ago (at least I remember Doug commenting on that topic) and kind of concluded that SoC clock drivers could include lists of clocks to be enabled at boot-up (as a HACK to enable things like simplefb until proper support for respective features are added). I believe this would be the proper solution for $subject. Best regards, Tomasz -- 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: Unable to boot mainline on snow chromebook since 3.15
Hello Tomasz, On 09/07/2014 05:52 PM, Tomasz Figa wrote: So I believe we've got a process issue here. If you don't have normal support for display hardware, but you want to keep the display operational thanks to bootloader already initializing it, you should not add anything to the kernel which breaks it, until full support comes in. This means that respective regulators should be either always-on or not listed at all (I'd favor the former) So that means that do you think that the workaround patch I shared on the previous email could be considered as a correct solution? In that case I can post it as a proper patch. somehow enabled at boot-up or completely ignored, including all their parents capable of being gated. AFAIU from the thread I mentioned before, Nvidia folks proposed the same to fix the simplefb issue on sunxi, to avoid the clocks in question being turned off at boot by modifying the sunxi clock driver. Now with regulators this is pretty straightforward, but with clocks I believe it's an open issue. AFAIR we've discussed this on MLs some time ago (at least I remember Doug commenting on that topic) and kind of concluded that SoC clock drivers could include lists of clocks to be enabled at boot-up (as a HACK to enable things like simplefb until proper support for respective features are added). I believe this would be the proper solution for $subject. Clocks is not an issue at least on this machine since the bootloader already passes the clk_ignore_unused parameter to the kernel command line so in that sense there isn't a regression comparing with older kernels. If possible I would prefer to leave this way instead of adding quirks to the clock driver, specially since there are proposed patches to have the display working using the Exynos DRM driver on this machine. Best regards, Tomasz 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: Unable to boot mainline on snow chromebook since 3.15
On 07.09.2014 18:12, Javier Martinez Canillas wrote: Hello Tomasz, On 09/07/2014 05:52 PM, Tomasz Figa wrote: So I believe we've got a process issue here. If you don't have normal support for display hardware, but you want to keep the display operational thanks to bootloader already initializing it, you should not add anything to the kernel which breaks it, until full support comes in. This means that respective regulators should be either always-on or not listed at all (I'd favor the former) So that means that do you think that the workaround patch I shared on the previous email could be considered as a correct solution? In that case I can post it as a proper patch. Right. somehow enabled at boot-up or completely ignored, including all their parents capable of being gated. AFAIU from the thread I mentioned before, Nvidia folks proposed the same to fix the simplefb issue on sunxi, to avoid the clocks in question being turned off at boot by modifying the sunxi clock driver. OK. Now with regulators this is pretty straightforward, but with clocks I believe it's an open issue. AFAIR we've discussed this on MLs some time ago (at least I remember Doug commenting on that topic) and kind of concluded that SoC clock drivers could include lists of clocks to be enabled at boot-up (as a HACK to enable things like simplefb until proper support for respective features are added). I believe this would be the proper solution for $subject. Clocks is not an issue at least on this machine since the bootloader already passes the clk_ignore_unused parameter to the kernel command line so in that sense there isn't a regression comparing with older kernels. If possible I would prefer to leave this way instead of adding quirks to the clock driver, specially since there are proposed patches to have the display working using the Exynos DRM driver on this machine. Well, clk_ignore_unused seems a bit too coarse grained to me. Also forcing the user to add it in his bootloader (or any other way) is not really the best practice IMHO. At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Best regards, Tomasz -- 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: Unable to boot mainline on snow chromebook since 3.15
Hello Tomasz, On 09/07/2014 06:19 PM, Tomasz Figa wrote: On 07.09.2014 18:12, Javier Martinez Canillas wrote: Clocks is not an issue at least on this machine since the bootloader already passes the clk_ignore_unused parameter to the kernel command line so in that sense there isn't a regression comparing with older kernels. If possible I would prefer to leave this way instead of adding quirks to the clock driver, specially since there are proposed patches to have the display working using the Exynos DRM driver on this machine. Well, clk_ignore_unused seems a bit too coarse grained to me. Also forcing the user to add it in his bootloader (or any other way) is not really the best practice IMHO. Fair enough. At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Ok, I'll prepare a patch to add the CLK_IGNORE_UNUSED flag to the needed clocks in drivers/clk/samsung/clk-exynos5250.c. That will be a more fine-grained solution since the clk_ignore_unused kernel parameter won't be needed. Best regards, Tomasz 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: Unable to boot mainline on snow chromebook since 3.15
Hi, On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote: So I believe we've got a process issue here. If you don't have normal support for display hardware, but you want to keep the display operational thanks to bootloader already initializing it, you should not add anything to the kernel which breaks it, until full support comes in. This means that respective regulators should be either always-on or not listed at all (I'd favor the former) and respective clocks either somehow enabled at boot-up or completely ignored, including all their parents capable of being gated. It seems slightly broken to hack the device tree in this way. I'll be the first to admit that I often list regulators as always-on during bringup when not everything is done, and I guess it's not that different. ...but given everything going on upstream (and people working on Suspend/Resume, DRM, etc) it seems like it might be a bit of a pain. ...but if that's what everyone agrees on, I won't disagree too strongly. One (ugly?) solution would be to add a feature to your bootloader to modify the device tree to mark regulators as always-on. Since the booloader gets to touch the device tree and the bootloader is involved in communicating into about SimpleFB, it kinda makes sense. -- 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: Unable to boot mainline on snow chromebook since 3.15
Hi, On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Now with regulators this is pretty straightforward, but with clocks I believe it's an open issue. AFAIR we've discussed this on MLs some time ago (at least I remember Doug commenting on that topic) and kind of concluded that SoC clock drivers could include lists of clocks to be enabled at boot-up (as a HACK to enable things like simplefb until proper support for respective features are added). I think my old problem was with earlyprintk and a core clock getting disabled. See (44ff025 clk: exynos5420: Remove aclk66_peric from the clock tree description). I think I've seen others solve the same problem with the concept of critical clocks. I agree that regulator and clock frameworks allow very different hacks. ;) -Doug -- 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
