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 14:16:22 -0700 [thread overview]
Message-ID: <874oisiqu1.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20100430184712.GF29604@atomide.com> (Tony Lindgren's message of "Fri\, 30 Apr 2010 11\:47\:12 -0700")
Tony Lindgren <tony@atomide•com> writes:
> * Russell King - ARM Linux <linux@arm•linux.org.uk> [100430 10:13]:
>> On Fri, Apr 30, 2010 at 12:20:35PM -0400, Cyril Chemparathy wrote:
>> > Hi,
>> >
>> > [...]
>> > > 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].)
>> >
>> > Essentially both of these approaches (internal scratch register and
>> > fixed address) implement a weird back-channel communication scheme
>> > between the decompresser and the debug macros.
>> >
>> > A more elegant solution may be as follows:
>> > - pass machine_arch_type as an argument into addruart.
>>
>> Unfortunately, that breaks addruart. Firstly, addruart is used from
>> assembly code where very limited registers are available (the fewer
>> registers it clobbers the less likely debug is going to cause stuff
>> to break.)
>
> Right, this would be tricky.
>
>> Secondly, the places that addruart may be called from, the location
>> of the machine type number is indeterminent. Remember that this
>> macro can be called when the MMU is on or off, and can be called
>> before the machine_arch_type has been initialized.
>
> Another good point here.
>
>> > - move the uart base lookup logic to addruart using macros similar
>> > to DEBUG_LL_*, except that these expand to assembly code this
>> > time.
>> > - reuse these debug-macros in uncompress.h and implement putc() and
>> > flush() using addruart(), senduart(), etc.
>>
>> Given what I've said above about the debug macros, this is definitely the
>> wrong solution.
>>
>> Having the decompressor macros work whatever the machine type is
>> reasonable, and the machine_is_xxx() macros already work at that point,
>> so there shouldn't be much of an issue there.
>
> Just to bring it up, there's one issue to consider here though.
> When the bootloader passes a wrong machine id, chances are things
> break with no debug output.
>
>> As far as the debug macros go, I think we're at the point where it's
>> basically just far easier to leave these macros as a developer debugging
>> tool and we'll just have to put up with it being something that an OMAP
>> developer has to edit according to his platform to make work.
>>
>> After all, _NO_ production kernel what so ever should be using this
>> debug support.
>
> Things work now for mach-omap2, but we assume the first uart is always
> in the same location. If this changes, then using some fixed memory
> location for storing the debug configuration is probably the best way
> to go considering the issues Russell mentioned.
I agree, using a fixed memory location seems the best way to keep this
working across new devices with different UART1 base.
Kevin
next prev parent reply other threads:[~2010-04-30 21:16 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
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 [this message]
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=874oisiqu1.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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