From: Grant Likely <grant.likely@secretlab•ca>
To: Rob Herring <robherring2@gmail•com>
Cc: Vineet Gupta <Vineet.Gupta1@synopsys•com>,
linux-next <linux-next@vger•kernel.org>,
Anton Kolesov <Anton.Kolesov@synopsys•com>,
lkml <linux-kernel@vger•kernel.org>,
greg Kroah-Hartman <gregkh@linuxfoundation•org>,
"linux-serial@vger•kernel.org" <linux-serial@vger•kernel.org>,
"devicetree@vger•kernel.org" <devicetree@vger•kernel.org>
Subject: Re: ARC fails to boot on linux-next of 20140711
Date: Wed, 30 Jul 2014 21:25:27 -0600 [thread overview]
Message-ID: <20140731032527.D2C5AC40A02@trevor.secretlab.ca> (raw)
In-Reply-To: <CAL_JsqLR65PcLhoQR6VaQvrLLbPOR1tLx9oLEinYkkATSKxbKQ@mail.gmail.com>
On Sat, 26 Jul 2014 15:10:28 -0500, Rob Herring <robherring2@gmail•com> wrote:
> On Sat, Jul 26, 2014 at 11:50 AM, Grant Likely
> <grant.likely@secretlab•ca> wrote:
> > On Sat, 26 Jul 2014 06:52:36 +0000, Vineet Gupta <Vineet.Gupta1@synopsys•com> wrote:
> >> Hi Rob,
> >>
> >> On Friday 25 July 2014 07:45 PM, Rob Herring wrote:
> >> > On Fri, Jul 25, 2014 at 6:02 AM, Vineet Gupta
> >> > <Vineet.Gupta1@synopsys•com> wrote:
> >> >> > Hi Grant,
> >> >> >
> >> >> > linux-next has a series for arc_uart (via tty tree) which converts it to generic
> >> >> > earlycon and specifies console via /chosen/stdout-path vs. an explicit param in
> >> >> > /chose/bootargs
> >> >> >
> >> >> > 2014-06-24 9da433c0a0b5 ARC: [arcfpga] stdout-path now suffices for earlycon/console
> >> >> >
> >> >> > This relied on prev commit of yours (from linux next of 20140711), which seem to
> >> >> > have disappeared now.
> >> >> >
> >> >> > 2014-03-27 a9296cf2d0b6 of: Create of_console_check() for selecting a console
> >> >> > specified in /chosen
> >> >> > 2014-03-27 cfa9cacc5dd3 of: Enable console on serial ports specified by
> >> >> > /chosen/stdout-path
> >> >> >
> >> >> > Is there a specific reason for dropping these patches (or perhaps a merge to be
> >> >> > merged). I cherry-picked both but still doesn't work.
> >> >> >
> >> >> > Can you please advise next step forward, before I go off debugging with those
> >> >> > patches in.
> >> > There's an issue that if you have stdout-path and "earlycon" on the
> >> > command line, the kernel will switch to tty0 and disable the earlycon.
> >> >
> >> > This is the "fix", but I don't like adding the DT dependency into generic code:
> >> >
> >> > @@ -2382,7 +2386,7 @@ void register_console(struct console *newcon)
> >> > if (newcon->setup == NULL ||
> >> > newcon->setup(newcon, NULL) == 0) {
> >> > newcon->flags |= CON_ENABLED;
> >> > - if (newcon->device) {
> >> > + if (newcon->device && !of_stdout) {
> >> > newcon->flags |= CON_CONSDEV;
> >> > preferred_console = 0;
> >> > }
> >>
> >> The DT settings relevant for ARC, which enable generic-earlycon and
> >> console-with-stdout-path are as follows
> >>
> >> chosen {
> >> bootargs = "earlycon";
> >> stdout-path = &arcuart0;
> >> };
> >>
> >> ....
> >> arcuart0: serial@c0fc1000 {
> >> compatible = "snps,arc-uart";
> >>
> >> And it works w/o above hunk, provided the 2 patches from Grant exist in linux-next
> >> which they don't at the moment. I'm pretty confused how the hunk above comes into
> >> picture.
> >>
> >> And if not then I will have to get the ARC std-out patch reverted in tty-next as
> >> it is broken.
> >
> > You need to revert it anyway, the dependency chain is broken. Just
> > because something is in linux-next doesn't mean it will be merged.
> > Dependencies must always be in the branch to which you commit.
> >
> > If that doesn't happen (like here) then bisecting is broken and the
> > dependencies may not actually get merged.
> >
> > When this happens, what you're supposed to do is tell the maintainers
> > what commits the patch depends on so that it can be applied to the
> > correct tree. In this case I could take it through my devicetree branch
> > that contains the console patches.
> >
> > If a patch depends on commits in several branches then it is a bit more
> > complex. What we usually do is create a new branch that merges in each
> > branch that is depended on, and then apply the commit on top of that.
> >
> > As for the console patches, I'm only going to be putting them back if I
> > can devise a good fix for the earlycon duplication issue.
>
> There is also a simple work-around. You have to specify the console
> when you use earlycon. For example, you can add "earlycon
> console=ttyAMA0" instead of just earlycon. To summarize, this is the
> state of combinations of console params:
>
> Working:
> stdout-path
> console=blah
> stdout-path + console=blah
> earlycon=blah
>
> Not working:
> stdout-path + earlycon
>
> Also, it is a developer only feature which is new. You will be aware
> of an issue because the earlycon starts output and then stops on
> switching to tty0 versus complete silence which could be anything.
Fair enough. Okay, I'm going to put it back into linux-next. The proper
fix can come later.
> There are other landmines in this area already. For example, setting
> earlycon on ARM will break the boot because an ioremap is attempted
> before paging_init. This is nothing new, but has always been the case
> if the 8250 driver was enabled.
We should not allow earlycon to be selectable on ARM until this is
fixed. Can you do a patch for this?
g.
next prev parent reply other threads:[~2014-07-31 3:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 11:02 ARC fails to boot on linux-next of 20140711 Vineet Gupta
2014-07-25 11:26 ` Vineet Gupta
2014-07-25 14:15 ` Rob Herring
2014-07-26 5:33 ` Grant Likely
2014-07-26 6:53 ` Vineet Gupta
2014-07-26 15:17 ` Guenter Roeck
2014-07-26 6:52 ` Vineet Gupta
2014-07-26 16:50 ` Grant Likely
2014-07-26 20:10 ` Rob Herring
2014-07-31 3:25 ` Grant Likely [this message]
[not found] ` <20140731032527.D2C5AC40A02-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-07-31 15:12 ` Rob Herring
2014-07-28 4:38 ` Vineet Gupta
2014-07-30 23:53 ` Grant Likely
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=20140731032527.D2C5AC40A02@trevor.secretlab.ca \
--to=grant.likely@secretlab$(echo .)ca \
--cc=Anton.Kolesov@synopsys$(echo .)com \
--cc=Vineet.Gupta1@synopsys$(echo .)com \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=gregkh@linuxfoundation$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=linux-serial@vger$(echo .)kernel.org \
--cc=robherring2@gmail$(echo .)com \
/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