linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Date: Fri, 30 Apr 2010 18:37:51 -0700	[thread overview]
Message-ID: <20100501013751.GL29604@atomide.com> (raw)
In-Reply-To: <87sk6c8osn.fsf@deeprootsystems.com>

* Kevin Hilman <khilman@deeprootsystems.com> [100430 17:05]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * Kevin Hilman <khilman@deeprootsystems.com> [100430 14:56]:
> >> "Pandita, Vikram" <vikram.pandita@ti.com> writes:
> >> >
> >> > 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.
> 
> I'd say if we're accessing L4 regs before .map_io, it's a bug that
> needs to be fixed, but I don't think we are.  If we were, we'd notice
> a hang when !CONFIG_DEBUG_LL since the .phys_io and .io_pg_offst are
> only mapped in when CONFIG_DEBUG_LL=y.

Yeah the current approach uses both, but only when CONFIG_DEBUG_LL=y
as you noted.
 
> I think we've been using .phys_io/.io_pg_offset incorrectly in OMAP as
> an early mapping of all the IO space, when it is intended just for use
> as early UART access, indicated by the comments in head.S and the
> fact that it's only used when CONFIG_DEBUG_LL=y

That's probably just a left over from when we could map L3 and L4 with
one mapping..

Anyways, here's an experimental patch for using a memory address instead
of UART1 for storing the debug port configuration in uncompress.h.

So far only tested on n900, will give it a try also on zoom3 after
updating the zoom3 related patch.

Now the real question is: Is it safe to use the fixed memory address?

#define OMAP_UART_INFO	(PHYS_OFFSET + 0x3ff8)

Also, another thing that needs to be checked is what happens if nothing
calls printk early and the debug port address configuration is not
set early.. Needs to be tested by adding printascii call only later
on.

Regards,

Tony

  reply	other threads:[~2010-05-01  1:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-30 20:33 [PATCH 00/11] omap2/3/4: Multi-omap updates to boot test with omap3_defconfig Tony Lindgren
2010-04-30 20:33 ` [PATCH 01/11] omap2/3/4: Fix multi.h when omap3 and omap4 are selected without omap2 Tony Lindgren
2010-04-30 20:33 ` [PATCH 02/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 Tony Lindgren
2010-04-30 20:55   ` Kevin Hilman
2010-04-30 21:02     ` Tony Lindgren
2010-04-30 21:20       ` Kevin Hilman
2010-04-30 21:37         ` Pandita, Vikram
2010-04-30 21:53           ` Pandita, Vikram
2010-04-30 22:00           ` Kevin Hilman
2010-04-30 23:30             ` Tony Lindgren
2010-05-01  0:10               ` Kevin Hilman
2010-05-01  1:37                 ` Tony Lindgren [this message]
2010-05-01  1:50                   ` Tony Lindgren
2010-05-03 22:10                     ` Pandita, Vikram
2010-05-04  0:40                       ` Tony Lindgren
2010-05-04  0:57                         ` [PATCH 02a/11] omap: Use a memory address for storing the debug port info instead of UART1 scratchpad Tony Lindgren
2010-05-04  0:58                         ` [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 Tony Lindgren
2010-05-04 17:33                           ` Pandita, Vikram
2010-05-04 23:09                             ` Tony Lindgren
2010-04-30 20:33 ` [PATCH 03/11] omap3: Fix compile for board-cm-t35 Tony Lindgren
2010-04-30 20:33 ` [PATCH 04/11] omap3: Remove non-muxable ball entries for 3630 Tony Lindgren
2010-04-30 20:33 ` [PATCH 05/11] omap4: Fix multiboot with CONFIG_PM and CONFIG_ARCH_OMAP3 selected Tony Lindgren
2010-04-30 20:33 ` [PATCH 06/11] omap4: Fix omap_l2_cache_init not to run for other omaps Tony Lindgren
2010-05-01  6:18   ` Shilimkar, Santosh
2010-05-01 17:46     ` Tony Lindgren
2010-04-30 20:34 ` [PATCH 07/11] omap2/3/4: Add new boards to omap3_defconfig Tony Lindgren
2010-04-30 20:34 ` [PATCH 08/11] omap2/3/4: Make omap3_defconfig usable on Nokia boards Tony Lindgren
2010-04-30 20:34 ` [PATCH 09/11] omap2/3/4: Update PMIC options for TWL and Menelaus chips Tony Lindgren
2010-04-30 20:34 ` [PATCH 10/11] omap2/3/4: Dissable CONFIG_PM_VERBOSE in omap3_defconfig Tony Lindgren
2010-04-30 20:34 ` [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP " Tony Lindgren
2010-04-30 20:50   ` Tony Lindgren
2010-05-04  0:52     ` Tony Lindgren
2010-05-04  7:26       ` Tomi Valkeinen
2010-05-04 14:40         ` Tony Lindgren
2010-05-04 14:50           ` Tomi Valkeinen
2010-05-04 19:23             ` Tony Lindgren
2010-05-05 17:32   ` Old DSS code broken as module (was "RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig") Aguirre, Sergio
2010-05-05 17:43     ` Tony Lindgren
2010-05-05 18:23       ` Aguirre, Sergio
2010-05-06  8:07     ` Tomi Valkeinen

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=20100501013751.GL29604@atomide.com \
    --to=tony@atomide.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).