linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: Unable to boot mainline on snow chromebook since 3.15
Date: Sun, 07 Sep 2014 18:19:03 +0200	[thread overview]
Message-ID: <540C8577.2070907@gmail.com> (raw)
In-Reply-To: <540C83DE.10505@collabora.co.uk>

On 07.09.2014 18:12, Javier Martinez Canillas wrote:
> Hello Tomasz,
> 
> On 09/07/2014 05:52 PM, Tomasz Figa wrote:
>>
>> So I believe we've got a process issue here. If you don't have normal
>> support for display hardware, but you want to keep the display
>> operational thanks to bootloader already initializing it, you should not
>> add anything to the kernel which breaks it, until full support comes in.
>>
>> This means that respective regulators should be either always-on or not
>> listed at all (I'd favor the former)
> 
> So that means that do you think that the workaround patch I shared on the
> previous email could be considered as a correct solution? In that case I can
> post it as a proper patch.

Right.

> 
>> somehow enabled at boot-up or completely ignored, including all their
>> parents capable of being gated.
>>
> 
> AFAIU from the thread I mentioned before, Nvidia folks proposed the same to
> fix the simplefb issue on sunxi, to avoid the clocks in question being turned
> off at boot by modifying the sunxi clock driver.

OK.

> 
>> Now with regulators this is pretty straightforward, but with clocks I
>> believe it's an open issue. AFAIR we've discussed this on MLs some time
>> ago (at least I remember Doug commenting on that topic) and kind of
>> concluded that SoC clock drivers could include lists of clocks to be
>> enabled at boot-up (as a HACK to enable things like simplefb until
>> proper support for respective features are added).
>>
>> I believe this would be the proper solution for $subject.
>>
> 
> Clocks is not an issue at least on this machine since the bootloader already
> passes the clk_ignore_unused parameter to the kernel command line so in that
> sense there isn't a regression comparing with older kernels. If possible I
> would prefer to leave this way instead of adding quirks to the clock driver,
> specially since there are proposed patches to have the display working using
> the Exynos DRM driver on this machine.

Well, clk_ignore_unused seems a bit too coarse grained to me. Also
forcing the user to add it in his bootloader (or any other way) is not
really the best practice IMHO.

At least for next 3.17-rc I'd suggest fixing this up in respective clock
driver and dropping the hack only after Exynos DRM patches are merged
and confirmed working.

Best regards,
Tomasz

  reply	other threads:[~2014-09-07 16:19 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 [this message]
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
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=540C8577.2070907@gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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: link
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;
as well as URLs for NNTP newsgroup(s).