From: Mark Brown <broonie@kernel.org> To: Grant Likely <grant.likely@secretlab.ca> Cc: Olof Johansson <olof@lixom.net>, Doug Anderson <dianders@chromium.org>, Will Deacon <will.deacon@arm.com>, Tomasz Figa <tomasz.figa@gmail.com>, "kgene.kim@samsung.com" <kgene.kim@samsung.com>, "linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger.kernel.org>, Javier Martinez Canillas <javier.martinez@collabora.co.uk>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "rahul.sharma@samsung.com" <rahul.sharma@samsung.com>, Prashanth G <prashanth.g@samsung.com> Subject: Re: Unable to boot mainline on snow chromebook since 3.15 Date: Wed, 10 Sep 2014 16:39:19 +0100 [thread overview] Message-ID: <20140910153919.GH7960@sirena.org.uk> (raw) In-Reply-To: <CACxGe6u=QkGTKGfaE_jJ5VFMhdVKQNggp3qVBUgNP7rDbZss_A@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 4078 bytes --] On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: > On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown <broonie@kernel.org> wrote: > > 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. > 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). > 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. There's not a lot the subsystem can do without breaking other users or making the system substantially worse if we don't tell it what resources are affected, we'll end up being forced to tend too far towards being conservative about what we allow to happen. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown) To: linux-arm-kernel@lists.infradead.org Subject: Unable to boot mainline on snow chromebook since 3.15 Date: Wed, 10 Sep 2014 16:39:19 +0100 [thread overview] Message-ID: <20140910153919.GH7960@sirena.org.uk> (raw) In-Reply-To: <CACxGe6u=QkGTKGfaE_jJ5VFMhdVKQNggp3qVBUgNP7rDbZss_A@mail.gmail.com> On Wed, Sep 10, 2014 at 03:56:16PM +0100, Grant Likely wrote: > On Wed, Sep 10, 2014 at 3:31 PM, Mark Brown <broonie@kernel.org> wrote: > > 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. > 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). > 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. There's not a lot the subsystem can do without breaking other users or making the system substantially worse if we don't tell it what resources are affected, we'll end up being forced to tend too far towards being conservative about what we allow to happen. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140910/e19ad105/attachment.sig>
next prev parent reply other threads:[~2014-09-10 15:39 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 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 [this message] 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=20140910153919.GH7960@sirena.org.uk \ --to=broonie@kernel.org \ --cc=dianders@chromium.org \ --cc=grant.likely@secretlab.ca \ --cc=javier.martinez@collabora.co.uk \ --cc=kgene.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=olof@lixom.net \ --cc=prashanth.g@samsung.com \ --cc=rahul.sharma@samsung.com \ --cc=tomasz.figa@gmail.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.