From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v12 00/15] arm: Fix DEBUG_LL for multi-platform kernels (without PL01X)
Date: Fri, 23 Jan 2015 09:14:05 -0800 [thread overview]
Message-ID: <20150123171404.GQ7696@atomide.com> (raw)
In-Reply-To: <1940932.WxFESz5SgZ@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [150123 05:32]:
> 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@arndb.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.
Totally agree, let's make debug_ll use super limited.
The reasons for why people need debug_ll are currently because of all
the custom initcall levels. So far for all the cases I've seen, there
should not be any need for custom initcall levels any longer with the
deferred probe. The existing cases are all for legacy reasons and
should not be needed at all on anything done over past five years
or so.
The solution to removing the dependency to debug_ll is SoC specific
earlyprintk support. And to initialize everything else later, not
earlier.
Cheers,
Tony
next prev parent reply other threads:[~2015-01-23 17:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 10:54 [PATCH v12 00/15] arm: Fix DEBUG_LL for multi-platform kernels (without PL01X) Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 01/15] arm: cnx3xxxx: Remove spurious default for DEBUG_CNS3XXX Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 02/15] arm: iop32x: Enable DEBUG_LL_UART_8250 Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 03/15] arm: iop33x: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 04/15] arm: ixp4xx: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 05/15] arm: lpc32xx: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 06/15] arm: mv78xx0: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 07/15] arm: orion5x: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 08/15] arm: rpc: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 09/15] arm: Remove DEBUG_LL_UART_NONE Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 10/15] arm: ks8695: Migrate debug_ll macros to shared directory Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S Daniel Thompson
2014-11-16 0:29 ` Aaro Koskinen
2014-11-17 9:07 ` Daniel Thompson
2014-11-17 14:24 ` Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 12/15] arm: netx: Migrate DEBUG_LL macros to shared directory Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 13/15] arm: sa1100: " Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 14/15] arm: Seperate DEBUG_UART_PHYS from DEBUG_LL on EP93XX Daniel Thompson
2014-10-24 10:54 ` [PATCH v12 15/15] arm: Fix DEBUG_LL for multi-platform kernels (without PL01X) Daniel Thompson
2014-10-24 15:46 ` [PATCH v12 00/15] " Arnd Bergmann
2014-11-12 14:48 ` Daniel Thompson
2015-01-23 13:05 ` Geert Uytterhoeven
2015-01-23 13:08 ` Russell King - ARM Linux
2015-01-23 13:28 ` Arnd Bergmann
2015-01-23 17:14 ` Tony Lindgren [this message]
2015-01-23 13:31 ` Geert Uytterhoeven
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=20150123171404.GQ7696@atomide.com \
--to=tony@atomide.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).