[PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3

Tony Lindgren tony at atomide.com
Fri Apr 30 19:30:02 EDT 2010


* Kevin Hilman <khilman at deeprootsystems.com> [100430 14:56]:
> "Pandita, Vikram" <vikram.pandita at ti.com> writes:
> 
> [...]
> 
> >>>> > --- a/arch/arm/kernel/head.S
> >>>> > +++ b/arch/arm/kernel/head.S
> >>>> > @@ -328,6 +328,16 @@ __create_page_tables:
> >>>> >  	add	r0, r4, #0xd8000000 >> 18
> >>>> >  	str	r3, [r0]
> >>>> >  #endif
> >>>> > +#if defined(CONFIG_MACH_OMAP_ZOOM2) ||
> >>defined(CONFIG_MACH_OMAP_ZOOM3)
> >>>> > +	/*
> >>>> > +	 * Zoom2 and Zoom3 have UARTs only on the debug board.
> >>>> > +	 * The debug board is connected to the GPMC.
> >>>> > +	 */
> >>>> > +	add	r0, r4, #0xfa000000 >> 18
> >>>> > +	orr	r0, r0, #0x00400000 >> 18	@ ZOOM_UART_VIRT
> >>>> > +	orr	r3, r7, #0x10000000		@ ZOOM_UART_BASE
> >>>> > +	str	r3, [r0]
> >>>> > +#endif
> >>>>
> >>>> I don't see why this part is needed.  The same mapping is done using
> >>>> the .io_pg_offset in the machine description which is done just before
> >>>> this in head.S
> >>>
> >>> That mapping does not cover the GPMC area where this UART is.
> >>
> >>Hmm, then shouldn't that be fixed?  I understood the .phys_io and and
> >>.io_pg_offset fields of the mach_desc to be specifically for mapping
> >>the early UART, and nothing else.
> >
> > Here is the problem - with current approach we need two mappings to
> > happen and the MACHINE_START() code allows for only one via
> > .io_pg_offset and .phys_io
> >
> > Why:
> 
> > Tony's approach is to pass the information about the debug uart
> > number from the UART1 Scratchpad register.
> >
> > this introduces a dependency that 
> > UART1 registers also be mapped (virt<->phy).
> >
> > So for Tony's approach to work, .phys_io/.io_pg_offset continued to
> > have 0x4800000 based mapping and for external uart zoom3 port,
> > create this extra mapping.
> >
> > So find a better way from compressed.S to pass the uart number to
> > kernel, and we can solve the problem.
> 
> Ah, yet another reason to use a memory location instead of UART1 SCR
> to pass the UART info (c.f. [1])

That should work if we don't need to access any L4 registers
early on before .map_io.

Regards,

Tony

 
> Kevin
> 
> [1] http://marc.info/?l=linux-omap&m=127266219130713&w=2



More information about the linux-arm-kernel mailing list