[PATCH 0/3] Allow late mdesc detection, v3

[Shilimkar, Santosh]

Jeremy,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Saturday, July 31, 2010 2:55 PM
> To: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org; Tony
> Lindgren
> Subject: Fwd: [PATCH 0/3] Allow late mdesc detection, v3
> 
> Forwarding for OMAP people - as there's outstanding questions about this
> change for their platforms.
> 
> ----- Forwarded message from Jeremy Kerr <jeremy.kerr at canonical.com> -----
> 
> Date: Fri, 30 Jul 2010 17:22:11 +0800
> From: Jeremy Kerr <jeremy.kerr at canonical.com>
> To: linux-arm-kernel at lists.infradead.org
> Subject: [PATCH 0/3] Allow late mdesc detection, v3
> Delivery-date: Sat, 31 Jul 2010 01:25:58 +0100
> 
> Hi all,
> 
> Currently, we probe for a mdesc early in boot. At this early stage, the
> only thing we use the mdesc for is to determine the debug page mapping.
> 
> However, the debug addresses (phys and virt) need to be coded into the
> addruart macro anyway; the dynamic probing is only going to tell us what
> we already know.
> 
> These changes allow us to use the addruart macros to find the debug
> mapping addresses, rather than pulling them out of the mdesc. This means
> that the addresses are only kept in the one place, and that we don't
> need the mdesc nearly as early.
> 
> The first change updates all of the addruart macros to return both
> physical and virtual addresses. I've used 'rp' and 'rv' as the macro
> arguments to indicate which address goes where
> 
> The second change updates the debug setup routine to use the addruart
> macro to establish the debug mapping, now that we can invoke the macro
> to find the phyical and virtual addresses.
> 
> This allows us to delay the requirement to have a mdesc available until
> much later. For example, we can parse one from the device tree once
> we've reached C code.
> 
> May break OMAP1/2, as the addruart macros are more complex on these
> platforms. I'd appreciate input from OMAP folks who may well tell me
> that this isn't possible.
> 
Just tried this on OMAP4, and indeed it breaks OMAP2PLUS low level debug
support.

Tony recently revamped the complete debug code, so that we can dynamically
set correct debug port based on machine ID passed by boot-loaders. Based
on this , the debug code determines the the correct debug port based on
this using a scratch pad register.

Tony can comment better on this issue.

Regards,
Santosh