From: Mark Brown <broonie@kernel.org> To: Doug Anderson <dianders@chromium.org> Cc: Tomasz Figa <tomasz.figa@gmail.com>, Javier Martinez Canillas <javier.martinez@collabora.co.uk>, Will Deacon <will.deacon@arm.com>, "kgene.kim@samsung.com" <kgene.kim@samsung.com>, "olof@lixom.net" <olof@lixom.net>, "rahul.sharma@samsung.com" <rahul.sharma@samsung.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger.kernel.org> Subject: Re: Unable to boot mainline on snow chromebook since 3.15 Date: Mon, 8 Sep 2014 11:20:10 +0100 [thread overview] Message-ID: <20140908102010.GF4015@sirena.org.uk> (raw) In-Reply-To: <CAD=FV=UYDDhL02CrhPUAHPncepwAF2-BgTmXOamy-Mdz80S-vw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2111 bytes --] On Sun, Sep 07, 2014 at 09:36:56PM -0700, Doug Anderson wrote: > On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa <tomasz.figa@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. That would seem to make sense, yes - we're apparently communicating this as a virtual device so we should make sure that virtual device has the resources it needs either directly or by reference to other devices so the driver can keep them on. Ideally we'd be doing this with fallback compatibles or something but this will probably work OK. I'd expect we're also going to run into the same problems with what people are currently doing with the SoC power domains, we also have code to power them off when they're idle, and this whole performance with adding hacks isn't going to be robust or scale - it's essentially just praying that nothing turns off the resources we need as far as I can tell. [-- 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: Mon, 8 Sep 2014 11:20:10 +0100 [thread overview] Message-ID: <20140908102010.GF4015@sirena.org.uk> (raw) In-Reply-To: <CAD=FV=UYDDhL02CrhPUAHPncepwAF2-BgTmXOamy-Mdz80S-vw@mail.gmail.com> On Sun, Sep 07, 2014 at 09:36:56PM -0700, Doug Anderson wrote: > On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa <tomasz.figa@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. That would seem to make sense, yes - we're apparently communicating this as a virtual device so we should make sure that virtual device has the resources it needs either directly or by reference to other devices so the driver can keep them on. Ideally we'd be doing this with fallback compatibles or something but this will probably work OK. I'd expect we're also going to run into the same problems with what people are currently doing with the SoC power domains, we also have code to power them off when they're idle, and this whole performance with adding hacks isn't going to be robust or scale - it's essentially just praying that nothing turns off the resources we need as far as I can tell. -------------- 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/20140908/147040cb/attachment.sig>
next prev parent reply other threads:[~2014-09-08 10:20 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 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 [this message] 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=20140908102010.GF4015@sirena.org.uk \ --to=broonie@kernel.org \ --cc=dianders@chromium.org \ --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=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.