linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: Forcing DEBUG_UART_{PHYS, VIRT} changes when switching between v7 platforms?
Date: Thu, 20 Mar 2014 10:11:27 +0000	[thread overview]
Message-ID: <20140320101127.GN7528@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <8099777.qvOx0M5YBS@wuerfel>

On Thu, Mar 20, 2014 at 08:07:52AM +0100, Arnd Bergmann wrote:
> On Wednesday 19 March 2014 16:38:45 Florian Fainelli wrote:
> > Hi,
> > 
> > When switching between different Multi v7 platform which all select
> > DEBUG_UART_8250, whichever platform managed to set
> > DEBUG_UART_{PHYS,VIRT} first will end-up forcing its value to the
> > others.
> > 
> > What I am seeing at the moment is for instance enabling BCM_MOBILE
> > will set DEBUG_UART_PHYS to 0x3e000000, disabling BCM_MOBILE and now
> > enabling MVEBU won't force a new DEBUG_UART_PHYS address to be
> > re-computed.
> > 
> > Should we add some sort of specific annotation to the Kconfig symbol
> > to force a recalculation of the UART PHYS address?
> 
> Russell has plans to change the Konfig logic in the future, removing the
> platform specific options. With the current code, you could probably
> do something along the lines of

The only reason the default values are there is to provide an easy way
for people to locate the values they need for the time being.  The
plan is to kill them off, so you have to enter them manually.  The
issue with that is it becomes quite painful if you have to keep searching
around for the right values when something breaks.

(Personally, I've ended up a number of times searching around for the
right address to generate uImage's for various target platforms which
can only load uImages... but I've now ended up with a script which has
that information stored in it...)

So yes, eventually these will have to be specified manually.  I'm
probably going to move them into file(s) in Documentation/arm/
so that we retain the information in an easily accessible form.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

  reply	other threads:[~2014-03-20 10:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-19 23:38 Forcing DEBUG_UART_{PHYS, VIRT} changes when switching between v7 platforms? Florian Fainelli
2014-03-20  7:07 ` Arnd Bergmann
2014-03-20 10:11   ` Russell King - ARM Linux [this message]
2014-03-20 11:45     ` Arnd Bergmann
2014-03-20 12:46       ` Russell King - ARM Linux
2014-04-14 14:25         ` Domenico Andreoli
2014-03-20 18:22   ` Florian Fainelli
2014-03-20 18:26     ` Russell King - ARM Linux
2014-03-20 13:36 ` Rob Herring

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=20140320101127.GN7528@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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).