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: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140905115704.GO13515@arm.com>
2014-09-05 12:22 ` Unable to boot mainline on snow chromebook since 3.15 Will Deacon
2014-09-05 13:46 ` Ajay kumar
2014-09-05 13:56 ` Vivek Gautam
2014-09-08 11:17 ` Will Deacon
2014-09-05 14:12 ` Marc Zyngier
2014-09-05 20:25 ` Doug Anderson
2014-09-07 9:06 ` Javier Martinez Canillas
2014-09-07 15:01 ` Mark Brown
2014-09-07 15:51 ` Javier Martinez Canillas
2014-09-07 15:52 ` Tomasz Figa
2014-09-07 16:12 ` Javier Martinez Canillas
2014-09-07 16:19 ` Tomasz Figa
2014-09-07 16:40 ` Javier Martinez Canillas
2014-09-08 11:21 ` Will Deacon
2014-09-08 11:55 ` Javier Martinez Canillas
2014-09-08 12:46 ` Will Deacon
2014-09-08 12:20 ` Grant Likely
2014-09-08 13:49 ` Mark Brown
2014-09-08 14:05 ` Javier Martinez Canillas
2014-09-10 11:17 ` Will Deacon
2014-09-10 16:03 ` Doug Anderson
2014-09-10 16:23 ` Will Deacon
2014-09-08 15:58 ` Doug Anderson
2014-09-08 19:40 ` Grant Likely
2014-09-10 13:06 ` Olof Johansson
2014-09-10 14:31 ` Mark Brown
2014-09-10 14:56 ` Grant Likely
2014-09-10 15:39 ` Mark Brown
2014-09-10 16:29 ` Grant Likely
2014-09-10 16:45 ` Doug Anderson
2014-09-10 19:45 ` Mark Brown
2014-09-10 19:51 ` Doug Anderson
2014-09-10 16:57 ` Mark Brown
2014-09-11 9:22 ` Grant Likely
2014-09-11 18:03 ` Mark Brown
2014-09-11 22:54 ` Doug Anderson
2014-09-29 12:57 ` Thierry Reding
2014-09-29 13:12 ` Grant Likely
2014-09-29 16:37 ` Mark Brown
2014-09-30 6:12 ` Thierry Reding
2014-09-29 20:46 ` Maxime Ripard
2014-09-10 16:36 ` Olof Johansson
2014-09-10 18:17 ` Mark Brown
2014-09-11 9:06 ` Grant Likely
2014-09-11 16:16 ` Mark Brown
2014-09-08 4:36 ` Doug Anderson
2014-09-08 6:09 ` Javier Martinez Canillas
2014-09-08 15:55 ` Doug Anderson
2014-09-08 16:07 ` Will Deacon
2014-09-08 16:12 ` Doug Anderson
2014-09-08 10:20 ` Mark Brown [this message]
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$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox