Unable to boot mainline on snow chromebook since 3.15

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?

Cheers,

Will

[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].

Quoted 30 lines · Will Deacon

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.
http://www.spinics.net/lists/dri-devel/msg66740.html
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?

Hi Will,

Quoted 26 lines · Will Deacon

[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].

Quoted 22 lines · Will Deacon

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.
http://www.spinics.net/lists/dri-devel/msg66740.html
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").

Quoted 8 lines

Quoted 8 lines

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?

AFAIK, ARM chromebooks use DRM based display drivers and the required patches are still not merged:
http://www.spinics.net/lists/dri-devel/msg66740.html

Corresponding DT patches are also still not merged:
http://www.spinics.net/lists/arm-kernel/msg358324.html
http://www.spinics.net/lists/arm-kernel/msg358325.html

There is a patch for configs as well:
https://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg35828.html

Try these patches(I hope they will apply directly on 3.17-rc3) and you should be able to use display on snow.

Quoted 18 lines · Ajay kumar

Quoted 7 lines

Quoted 7 lines

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?

AFAIK, ARM chromebooks use DRM based display drivers and the required patches are still not merged:
http://www.spinics.net/lists/dri-devel/msg66740.html

Corresponding DT patches are also still not merged:
http://www.spinics.net/lists/arm-kernel/msg358324.html
http://www.spinics.net/lists/arm-kernel/msg358325.html

There is a patch for configs as well:
https://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg35828.html

Quoted 2 lines

Try these patches(I hope they will apply directly on 3.17-rc3) and you should be able to use display on snow.

We have pushed 3.17-rc3 kernel with above mentioned patches to github [1] Please use that, and in case you have some other requirements let us know.

[1] https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-display

Hi Will,

Quoted 34 lines · Will Deacon

[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].

Quoted 30 lines · Will Deacon

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.
http://www.spinics.net/lists/dri-devel/msg66740.html
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?

AFAIK, ARM chromebooks use DRM based display drivers and the required patches are still not merged:
http://www.spinics.net/lists/dri-devel/msg66740.html

Corresponding DT patches are also still not merged:
http://www.spinics.net/lists/arm-kernel/msg358324.html
http://www.spinics.net/lists/arm-kernel/msg358325.html

There is a patch for configs as well:
https://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg35828.html

Try these patches(I hope they will apply directly on 3.17-rc3) and you should be able to use display on snow.

[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].

Quoted 30 lines · Will Deacon

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?

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

Will,

Quoted 32 lines · Will Deacon

[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].

Quoted 28 lines · Will Deacon

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.

Quoted 2 lines

Quoted 2 lines

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).

He also added the following thoughts:

Quoted 9 lines

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

From bdbb3bc1d69c10dce58affe74e6b64636f7810b5 Mon Sep 17 00:00:00 2001

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.

Quoted 4 lines · Javier Martinez Canillas

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.

Quoted 10 lines

Quoted 9 lines

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.

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)

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

Hello Tomasz,

Quoted 6 lines · Tomasz Figa

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 10 lines

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.

Quoted 6 lines · Javier Martinez Canillas

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

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.

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

Will

Quoted 10 lines · Will Deacon

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

Agreed, I'm preparing a patch-set to prevent the kernel to disable both the clocks and regulators needed for the display, I'll try to post it today or tomorrow at worst.

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

Quoted 4 lines · Will Deacon

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on.

Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform.

Quoted 7 lines · Grant Likely

Quoted 4 lines · Will Deacon

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

Quoted 5 lines

I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on.

For regulators there is essentially a flag in DT already - the regulators should not be described in DT if the OS isn't supposed to be managing them.

Quoted 3 lines

Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform.

This has got to be a blacklist then, and it seems like we've got to fix simplefb to actually support managing the resources it's using. The current plan does not seem at all sensible - we're talking about adding hacks in every subsystem that provides resources and bodging DTs in order to work around simplefb.

Hello Will,

Since many folks don't agree that hacking different subsystems is the way forward I'll hold the patches and don't post them. The sunxi thread [0] already shows how different people have strong opposite positions on the correct approach to handle this.

For now you can just disable the tps65090 PMIC support by not enabling the CONFIG_REGULATOR_TPS65090 kconfig symbol on your kernel config. That will give you exactly the same behavior that before tps65090 support was added to the Snow DT on commit b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow") which AFAIU was good enough for your workflow.

Quoted 1 line · Javier Martinez Canillas

Hello Will,

Hi Javier,

Quoted 5 lines

Since many folks don't agree that hacking different subsystems is the way forward I'll hold the patches and don't post them. The sunxi thread [0] already shows how different people have strong opposite positions on the correct approach to handle this.

Quoted 5 lines

For now you can just disable the tps65090 PMIC support by not enabling the CONFIG_REGULATOR_TPS65090 kconfig symbol on your kernel config. That will give you exactly the same behavior that before tps65090 support was added to the Snow DT on commit b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow") which AFAIU was good enough for your workflow.

Disabling the regulator support gives me my framebuffer back, thanks.

I
then get stuck mounting my root filesystem over sd card because it's reported as read-only. The following hack solved the issue, but I'm not exactly sure where this regression has come from (whether this is a board quirk or pinctrl is really misconfigured).

Quoted 12 lines · Will Deacon

Quoted 10 lines · Javier Martinez Canillas

Since many folks don't agree that hacking different subsystems is the way forward I'll hold the patches and don't post them. The sunxi thread [0] already shows how different people have strong opposite positions on the correct approach to handle this.

For now you can just disable the tps65090 PMIC support by not enabling the CONFIG_REGULATOR_TPS65090 kconfig symbol on your kernel config. That will give you exactly the same behavior that before tps65090 support was added to the Snow DT on commit b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow") which AFAIU was good enough for your workflow.

Quoted 1 line

Disabling the regulator support gives me my framebuffer back, thanks.

Yay! Is this good enough to tide you over until DRM support lands?

Quoted 5 lines

I
then get stuck mounting my root filesystem over sd card because it's reported as read-only. The following hack solved the issue, but I'm not exactly sure where this regression has come from (whether this is a board quirk or pinctrl is really misconfigured).

This is a regression that was introduced by:

9795a84 mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()

In "exynos5250-cros-common.dtsi" you can see that the "wp-gpios = <&gpc2 1 0>;" is still listed under the slot node. Nobody is looking there anymore.

This is fixed in linux-next by:

aaa25a5 ARM: dts: unuse the slot-node and deprecate the supports-highspeed for dw-mmc in exynos

I'll let Kukjin decide what he wants to do about the regression in v3.17 (how to deal with conflicts, backporting, etc).

Quoted 9 lines · Will Deacon

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on.

Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform.

Grant,

Quoted 17 lines · Grant Likely

Quoted 9 lines · Will Deacon

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on.

Quoted 3 lines

Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform.

In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a "DO NOT SUBMIT" patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See
<https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c>
as I mentioned above.

Is this really a device tree that we need to guarantee backward compatibility with?

Quoted 32 lines · Doug Anderson

Grant,

Quoted 17 lines · Grant Likely

Quoted 9 lines · Will Deacon

Quoted 3 lines · Tomasz Figa

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.

Whilst I'm sympathetic to people working to enable DRM, I think this is the right solution to the problem. The transition from simplefb to DRM shouldn't break display for a bunch of kernel revisions whilst the code is in flux.

I would go further. The kernel behaviour has changed, and we have to deal with platforms that assume the old behaviour. That means either defaulting to leaving enabled regulators/clocks alone unless there is a flag in the DT saying they can be power managed, or black listing platforms that are known to depend on the regulator being on.

Quoted 3 lines

Updating the device tree must not be required to get the kernel to boot, but it is valid to require a DT upgrade to get better performance (battery life) out of the platform.

In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a "DO NOT SUBMIT" patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See
<https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c>
as I mentioned above.

Quoted 2 lines

Is this really a device tree that we need to guarantee backward compatibility with?

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 4 lines

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

Quoted 3 lines · Mark Brown

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

Quoted 10 lines · Grant Likely

Quoted 3 lines · Mark Brown

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

That bit is fine - I definitely think it's reasonable to have things like this where the device is initialized prior to the kernel starting and we use some simplified subset. What I think is a big problem here is that we're not being told what parts of the system state are relevant to this initialization (worse, we're being told things that are actively wrong for some of the resources). This seems inherently fragile.

Quoted 10 lines

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

I think saying that it's a good idea to have an simplefb node without resource management is exactly the problem here - if we start from the assumption that this is a good idea we do get dragged down this path but it seems like we took a wrong turn going that way in the first place.

It's not just regulators - we've got exactly the same problem with clocks on this system for example, they're also getting disabled because they seem unused and users have to pass in a kernel command line bodge to avoid that. We'd also have an issue if something decided to change the rates of some of the clocks, and power domains have the same problem (Ulf's patches to genericise their code has the same behaviour with regard to powering off unused domains, some of the existing implementations do that already).

Quoted 9 lines

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

Right, I agree with what you're saying here but what I'm saying is that the way to ensure that the resources are protected is for the simplefb node to tell the kernel what resources are being used, otherwise it seems like we're just guessing and will fall over ourselves sooner or later.

We can't use initcall hacks as these only work in cases where we will at some point hand over to a real driver and there seems to be a clear use case for using simplefb prior to that driver being written; even where we will hand over to a real driver we can't put a definite timescale on that happening since in the distro case it might be being loaded from disk at some point after userspace is running.

Quoted 60 lines · Mark Brown

Quoted 10 lines · Grant Likely

Quoted 3 lines · Mark Brown

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

That bit is fine - I definitely think it's reasonable to have things like this where the device is initialized prior to the kernel starting and we use some simplified subset. What I think is a big problem here is that we're not being told what parts of the system state are relevant to this initialization (worse, we're being told things that are actively wrong for some of the resources). This seems inherently fragile.

Quoted 10 lines

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

I think saying that it's a good idea to have an simplefb node without resource management is exactly the problem here - if we start from the assumption that this is a good idea we do get dragged down this path but it seems like we took a wrong turn going that way in the first place.

It's not just regulators - we've got exactly the same problem with clocks on this system for example, they're also getting disabled because they seem unused and users have to pass in a kernel command line bodge to avoid that. We'd also have an issue if something decided to change the rates of some of the clocks, and power domains have the same problem (Ulf's patches to genericise their code has the same behaviour with regard to powering off unused domains, some of the existing implementations do that already).

Quoted 9 lines

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

Right, I agree with what you're saying here but what I'm saying is that the way to ensure that the resources are protected is for the simplefb node to tell the kernel what resources are being used, otherwise it seems like we're just guessing and will fall over ourselves sooner or later.

Quoted 6 lines

We can't use initcall hacks as these only work in cases where we will at some point hand over to a real driver and there seems to be a clear use case for using simplefb prior to that driver being written; even where we will hand over to a real driver we can't put a definite timescale on that happening since in the distro case it might be being loaded from disk at some point after userspace is running.

What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit.

I don't want to build knowledge of resource dependencies into the simple case. We'll simply frequently get it wrong. For example: A future kernel will have better PM and will turn off more devices which isn't accounted for in an older DT.

Right now I know that clock disabling is supposed to be inhibited during the early boot process. I think regulators too?

Quoted 2 lines · Doug Anderson

Right now I know that clock disabling is supposed to be inhibited during the early boot process. I think regulators too?

No, for regulators we'll quite happily disable anything a consumer asks us to at any point but we'll only do a sweep for regulators that were enabled on startup then not subsequently referenced and turn them off in late_initcall.

What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit.

I don't want to build knowledge of resource dependencies into the simple case. We'll simply frequently get it wrong. For example: A future kernel will have better PM and will turn off more devices which isn't accounted for in an older DT.

Quoted 5 lines · Grant Likely

What we can do is have an inhibit flag for simplefb/simpleuart/simplewhatever that holds off PM. When a real driver, or a stub that understands parsing the resource dependencies, takes ownership of the device (or userspace tells the kernel to stop caring) it can clear the inhibit.

It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency.

Quoted 8 lines · Mark Brown

It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency.

I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints.

Quoted 11 lines · Grant Likely

Quoted 8 lines · Mark Brown

It's not quite as simple as just disabling PM - for example in the clocks case we've also got to worry about what happens with rate changes (which is going to get more and more risky as we get smarter about being able to push configuration changes back up the tree), regulators have a similar thing with voltage changes. With simple enables and disables we have to worry about things like handling users who actively want to power things on and and off but may potentially be sharing a resource with an undeclared dependency.

Quoted 7 lines

I think we can be okay with the above. This is a best-effort situation where we don't want to tear down how firmware has set up the board if it can be reasonably assumed that something depends on it (simplefb). However, if clocks or regulators are shared with other devices and those drivers ask for other settings, then there is simply no recourse. In that situation there must be a driver for the video device that takes care of any constraints.

When things break I'm not sure that users are going to understand that something that used to work for them was only provided on a best effort basis, I think they will expect things to carry on working.

Quoted 29 lines · Mark Brown

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 8 lines

Quoted 4 lines

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

Quoted 55 lines · Grant Likely

Quoted 29 lines · Mark Brown

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 8 lines

Quoted 4 lines

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

Quoted 9 lines

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

I posted a patch[0] earlier to do this for the clock framework in "that other thread". The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver.

Something similar could be done other frameworks.

One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about.

Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available.

On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding

Quoted 8 lines

Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available.

When simplefb is the only framebuffer to get a platform working, it is reasonable to have a placeholder driver that grabs the resources and nothing else. When a real driver is implemented, and merged, the placeholder driver should drop compatibility with the device node at the same time.

Quoted 8 lines · Thierry Reding

Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available.

When simplefb is the only framebuffer to get a platform working, it is reasonable to have a placeholder driver that grabs the resources and nothing else. When a real driver is implemented, and merged, the placeholder driver should drop compatibility with the device node at the same time.

Quoted 55 lines · Grant Likely

Quoted 29 lines · Mark Brown

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 8 lines

Quoted 4 lines

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

No, I don't think we can... there is a certain amount of "firmware got things working for us, and we're going to use it for a while" that is absolutely reasonable. simplefb is a good example, but there are certainly others.

I /do/ think it would be better for the simplefb data to get embedded or linked into the node of the graphics controller so that it can be torn down appropriately, and we need a rule for how long boot-state can be considered valid so that a proper driver can either reserve the resources for a given SoC, or do a full handoff from the simplefb. Even without that though, we need to be able to handle the case of an anonymous simplefb node with no regulator information. If that means the default simplefb behaviour is to inhibit runtime pm on all resources until a real driver show up, then that might just be what we need to do.

Quoted 9 lines

Two things should probably be changed from the current setup. 1) simplefb shouldn't be a platform driver. It is a boot thing that handles initial state from the graphics chip. By implementing it as a platform driver, it prevents the real driver from binding to the real device if the simplefb data embedded into it. 2) make sure that an SoC driver can protect the needed resources before they are automatically disabled. Either by putting them in an earlier initcall, or handling it in the subsystem code. I don't know enough about the regulator and clock runtime PM to know what the best way to do this is.

I posted a patch[0] earlier to do this for the clock framework in "that other thread". The idea is that shim drivers for these types of firmware devices can tell the various subsystems that they might need resources that aren't explicitly requested. The current implementation simply uses the existing infrastructure already present for the clk_ignore_unused command-line argument and allows drivers to declare this requirement. It also allows these drivers to retire the request once they've properly handed off to the real driver.

Something similar could be done other frameworks.

One of the objections to that in the other thread is that it won't prevent clocks from being disabled if some other driver was using those same clocks and doing a clk_enable()/clk_disable() on them. But quite frankly I don't think that's something we need to worry about.

Though there are two cases: one is to use simplefb as a means to have early boot messages on a graphical display (and optionally hand off to a real driver). The other is to use simplefb as the only framebuffer driver until a proper driver has been implemented. The latter would have the disadvantage of not allowing unused resources from being garbage collected at all. Then again, I don't think power consumption is going to be a very big issue on hardware where no proper display driver is available.

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 4 lines

Much better would have been if the DRM changes worked when they landed, so that the migration form simplefb to drm was invisible to the user. Or at least, to get them working ASAP since they're still broken. :(

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

Quoted 7 lines · Mark Brown

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

I'm strongly against doing this outside of the kernel, since they're closely tied together today. We've always had the quirk tables for devices in the kernel, and we used to do this a long time ago on powerpc as well (we did it before we built the flat DT out of the OF equivalent there, most of the time).

Quoted 3 lines

As far as I can tell the problem here is coming from the decision to have simplefb use resources without knowing about them - can we agree that this is a bad idea?

As already argued, there are good reasons to sometimes allow this, as long as it can be expected that it's something that's just used during early boot. For example, having DEBUG_LL output on a pre-mapped framebuffer could be really useful. Once DRM comes up, it'll tear down the existing one.

Quoted 9 lines · Olof Johansson

Quoted 6 lines · Grant Likely

Well, lets see... We've got a real user complaining about a platform that used to work on mainline, and no longer does. The only loophole for ignoring breakage is if there nobody cares that it is broken. That currently isn't the case. So even though it's based on a patch that has "DO NOT SUBMIT" in large friendly letters on the front cover, it doesn't change the situation that mainline has a regression.

Quoted 6 lines

Yeah, I'm with you on this Grant, it doesn't matter what the patch is labelled as.

One way to deal with this could be to add a quirk at boot time -- looking for the simplefb and if found, modifies the regulators to keep them on. That'd go in the kernel, not in firmware.

Well, we should also be fixing simplefb to manage the resources it uses though that doesn't clean up after the broken DTs that are currently deployed.

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

Quoted 7 lines · Mark Brown

As well as the regulators we'll also need to fix the clocks. If we're going to start adding these fixups perhaps we want to consider having a wrapper stage that deals with rewriting DTs prior to trying to use them? I'm not sure if it makes much difference but there's overlap with other tools like the ATAGs conversion wrapper and building separately would let the fixup code run early without directly going into the early init code (which seems a bit scary).

We've already got a dt fixup hook in the machine struct, created for exactly this reason. Fixing an incorrect DT provided by firmware:

arch/arm/include/asm/mach/arch.h:

struct machine_desc {
	...
	void (*dt_fixup)(void);
	...

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.

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.

Hello Doug,

Quoted 6 lines · Doug Anderson

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.

I can't say I like to mark the regulators as always-on on the DT and that's why I copied the patch in the response instead of posting it as a proper patch but I think relying in the bootloaders to modify the DT is not better.

IMHO U-boot should only modify the strictly necessary like the /chosen branch even though lately I've seen some attempts in the OMAP community to (ab)use U-Boot's fdt command to mangle the DT before passing to the kernel in order to support different Beagle Bone Black capes.

So "simple-framebuffer" is added to the device tree here:

https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c

That's one of the two patches to build your own U-Boot for enabling simplefb. You'll notice that's not a super official thing. It's a "DO NOT SUBMIT" patch sitting in a gerrit code review server, so I wouldn't exactly call it a stable ABI that we can't break. It's not something shipping in real products and it's not even landed in a git tree (I suppose maybe someone somewhere landed it, but...).

Quoted 10 lines · Doug Anderson

So "simple-framebuffer" is added to the device tree here:

https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c

That's one of the two patches to build your own U-Boot for enabling simplefb. You'll notice that's not a super official thing. It's a "DO NOT SUBMIT" patch sitting in a gerrit code review server, so I wouldn't exactly call it a stable ABI that we can't break. It's not something shipping in real products and it's not even landed in a git tree (I suppose maybe someone somewhere landed it, but...).

I just took the uboot image linked to from the chromium.org page here:

http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook#TOC-Getting-nv-U-Boot

Quoted 9 lines · Tomasz Figa

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.

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).