From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic
Date: Fri, 30 Apr 2010 08:07:02 -0700 [thread overview]
Message-ID: <1272640022.3051.1534.camel@localhost> (raw)
In-Reply-To: <20100126201239.15382.34792.stgit@baageli.muru.com>
[resend to include RMK]
On Tue, 2010-01-26 at 12:12 -0800, Tony Lindgren wrote:
> Define arch_decomp_setup() the same way as some other
> architectures do. Use arch_id to configure the debug uart
> based on the machine_is by storing it into the uart
> scratchpad register for DEBUG_LL code to use.
>
> Note that to avoid merge conflicts, this patch is using
> hardcoded register r1 until tmp register is being passed
> for all addruart macros.
This patch (now in mainline[1]) has been working well, but has a couple
serious limitations:
1. assumes bootloader has enabled UART1 clocks
2. assumes all OMAPs supported have the same UART1 base
With more platforms using USB-based UARTs, assumption (1) may not be
safe for very long, as bootloaders for these platforms don't really
*need* to enable UART1. Currently, they happen to mainly because of
copied init code from other platforms.
But more importantly, there are more OMAP derivative parts coming soon,
and one in particular coming soon[2] breaks assumption 2 by having a
different UART1 base (yes, it's branded as a DaVinci, but it's an OMAP
core as far as linux is concerned. Don't get me started on TI
branding.)
To fix both problems, maybe we should just use a fixed memory location
to pass this temporary data from uncompress to the kernel. We've had a
similar problem on DaVinci recently and a proposal has been made (and
tested) to use memory just below the page tables[3].)
Any comments on this proposal? or alternative suggestions?
Kevin
[1] commit 0c8219f0302d0d27fda52c790d38406801e547ec
[1] http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml
[2] https://patchwork.kernel.org/patch/94724/
next prev parent reply other threads:[~2010-04-30 15:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 20:12 [PATCH 00/14] omap DEBUG_LL and multiboot changes for 2.6.34 Tony Lindgren
2010-01-26 20:12 ` [PATCH 01/14] omap: Clean the serial port defines Tony Lindgren
2010-01-26 20:12 ` [PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic Tony Lindgren
2010-04-29 14:44 ` Kevin Hilman
2010-04-30 15:07 ` Kevin Hilman [this message]
2010-04-30 16:20 ` Cyril Chemparathy
2010-04-30 16:49 ` Tony Lindgren
2010-04-30 17:18 ` Russell King - ARM Linux
2010-04-30 18:47 ` Tony Lindgren
2010-04-30 21:16 ` Kevin Hilman
2010-01-26 20:12 ` [PATCH 03/14] omap: Remove old DEBUG_LL serial port options Tony Lindgren
2010-01-26 20:12 ` [PATCH 04/14] omap2/3: Make get_irqnr_and_base common for mach-omap2 multiboot Tony Lindgren
2010-01-26 20:12 ` [PATCH 05/14] omap2/3: Multiboot compile fixes to compile in omap2 and omap3 Tony Lindgren
2010-01-26 20:12 ` [PATCH 06/14] omap: Fix dmtimer.c for multi-omap boot Tony Lindgren
2010-01-26 20:12 ` [PATCH 07/14] omap2/3/4: Fix omap2_map_common_io for multi-omap Tony Lindgren
2010-01-26 20:12 ` [PATCH 08/14] omap2/3/4: Fix mbox init " Tony Lindgren
2010-01-26 20:12 ` [PATCH 09/14] omap2: Convert ARCH_OMAP24XX to ARCH_OMAP2 Tony Lindgren
2010-01-26 20:12 ` [PATCH 10/14] omap3: Replace ARCH_OMAP34XX with ARCH_OMAP3 Tony Lindgren
2010-01-26 20:13 ` [PATCH 11/14] omap2/3/4: Replace orred CONFIG_ARCH_OMAP2/3/4 with CONFIG_ARCH_OMAP2PLUS Tony Lindgren
2010-01-26 20:13 ` [PATCH 12/14] omap2/3: Fix initcalls for multi-omap Tony Lindgren
[not found] ` <20100819090313.GC3003@shisha.kicks-ass.net>
2010-08-19 9:35 ` Tony Lindgren
2010-01-26 20:13 ` [PATCH 13/14] omap2/3: Fix powerdomain init for multiomap Tony Lindgren
2010-01-27 2:26 ` Paul Walmsley
2010-01-27 2:29 ` Tony Lindgren
2010-01-26 20:13 ` [PATCH 14/14] omap2/3: Update omap3_defconfig to build in all the 2420 based boards Tony Lindgren
2010-03-24 11:43 ` [PATCH 00/14] omap DEBUG_LL and multiboot changes for 2.6.34 Gadiyar, Anand
2010-04-01 12:13 ` Tony Lindgren
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=1272640022.3051.1534.camel@localhost \
--to=khilman@deeprootsystems.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).