Message-ID: <1940932.WxFESz5SgZ@wuerfel>
Date:	Fri, 23 Jan 2015 14:28:24 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linaro-kernel@...ts.linaro.org
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Daniel Thompson <daniel.thompson@...aro.org>,
	"patches@...aro.org" <patches@...aro.org>, spear-devel@...t.st.com,
	Paul Bolle <pebolle@...cali.nl>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v12 00/15] arm: Fix DEBUG_LL for multi-platform kernels (without PL01X)

On Friday 23 January 2015 13:08:37 Russell King - ARM Linux wrote:
> > Hi Arnd,
> > 
> > On Fri, Oct 24, 2014 at 5:46 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > > There is still a related bug that we should also fix, but I'd say let's
> > > take your current patches first and then add whatever is missing
> > > on top. Specifically, a snippet like this
> > >
> > >         default 0xd4017000 if DEBUG_MMP_UART2
> > >         default 0xd4018000 if DEBUG_MMP_UART3
> > >         default 0xe0000000 if ARCH_SPEAR13XX
> > >         default 0xe4007000 if DEBUG_HIP04_UART
> > >         default 0xf0000be0 if ARCH_EBSA110
> > >
> > > still means you get the wrong default when you build a multiplatform
> > > kernel that you want to boot on HIP04 and you set DEBUG_HIP04_UART
> > > but you happen to also have ARCH_SPEAR13XX enabled.
> > >
> > > I have a patch that I use locally for randconfig builds that tries
> > > to fix this. It has some overlaps with your work but most parts are
> > > distinct. See below.
> > 
> > This is still desperately needed for anyone who wants to enable DEBUG_LL
> > on other platforms using multi_v7_defconfig.
> 
> I'd actually prefer to kill all these defaults and let people enter the
> value they want - for exactly this reason.

I think it almost works right and seems fixable, but I agree with your
long-term direction.

> However, I realise that would not be popular, because removing them
> means that people have to refer to some kind of documentation to find
> the correct value, and that's hassle.
> 
> So, the existing defaulting behaviour is my compromise, but as I say,
> I'd much prefer the unpopular move of killing the entire set of defaults.

We can probably remove the defaults after we have had working earlycon
support for at least one kernel release. My feeling is that a lot of
people just enable debug_ll for normal kernels (and pass earlyprintk
in the DTB-provided command line!) because the normal console support
is just too late to spot when things go wrong, and debug_ll is
convenient enough despite the downsides.

earlycon avoids the need for hard configuration and mostly solves the
problem of the normal console being initialized too late, so I think
we should migrate platforms to use that over time. It's not a
problem for backwards compatibility because old dtbs will still work,
just without working earlycon when there is no "stdout-path" property.

With that in place, we can put debug_ll back into its destined place,
which is to debug the extremely early boot stages before earlycon,
and anyone who needs to do that can pick the correct physical addresses
themselves. Picking the right virtual address seems to be harder
for a lot of people, and everyone gets stuck on this when they first
try it. Maybe we can avoid this problem by finding a page into which
to put the mapping by default. The fixmap support we need for earlycon
should make this easier too.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists