[PATCH 02/14] omap: Make uncompress code and DEBUG_LL code generic

[Kevin Hilman]

Tony Lindgren <tony at atomide.com> writes:

> * Russell King - ARM Linux <linux at 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