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: [PATCH 2/3] msm: add minimal board file for HTC Dream device
Date: Mon, 16 Nov 2009 16:57:16 +0000	[thread overview]
Message-ID: <20091116165716.GD3568@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <a55d774e0911160843h22938604s8966a58ee71992a@mail.gmail.com>

On Mon, Nov 16, 2009 at 08:43:20AM -0800, Brian Swetland wrote:
> What's the best way to handle a situation where there is no valid
> debug uart?  Could the arch/platform require DEBUG_LL be unset via
> Kconfig directives if it is configured in a way where there is no
> valid debug uart?

You're the first to have that issue.  Everyone else has a UART they
can always direct stuff at.

However, I believe you're making the issue far larger than it really is.

1. If you define the DEBUG_LL macros to be empty, printascii() etc will
   not touch any mapping.

2. If no mapping is going to be touched by printascii(), does it matter
   whether a UART is mapped via this early mapping stuff?

The answer to (2) is no.

So, you can still arrange for these fields to be populated with a valid
value even if you don't intend to use the resulting mapping.  And so
there's no need to force DEBUG_LL to be unset.

If you really have no values you can use, make sure you set io_pg_offst
to 0x3ffc - the last offset in the L1 page table.  This will cause the
code to write a single dummy entry at the very top of the page table,
which will then be overwritten by the generic ARM arch code for its own
use.

  reply	other threads:[~2009-11-16 16:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-02 10:49 [PATCH 2/3] msm: add minimal board file for HTC Dream device Pavel Machek
2009-11-16 16:36 ` Russell King - ARM Linux
2009-11-16 16:43   ` Brian Swetland
2009-11-16 16:57     ` Russell King - ARM Linux [this message]
2009-11-16 17:07       ` Brian Swetland
2009-11-16 18:56       ` Robert Jarzmik

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=20091116165716.GD3568@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).