linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: nico@fluxnic.net (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: Please help with the OMAP static mapping mess
Date: Tue, 04 Oct 2011 17:21:01 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.02.1110041458500.9106@xanadu.home> (raw)
In-Reply-To: <4E8AAFF9.3090600@ti.com>

On Tue, 4 Oct 2011, Santosh Shilimkar wrote:

> On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [111003 14:36]:
> >> On Mon, 3 Oct 2011, Tony Lindgren wrote:
> >>
> >>> Having the SRAM base address move around with different sizes also
> >>> requires the SoC detection.. Otherwise we can end up mapping wrong
> >>> size and end up trying to access secure SRAM that will hang the system.
> >>>
> >>> The way to fix it is to move SRAM init happen much later so we don't
> >>> have to map it early. I guess now we could use ioremap for SRAM,
> >>> although we may not want device attributes for the executable code?
> >>> Got any suggestions here on how we should map SRAM later on?
> >>
> >> You can use a variant of ioremap() such as __arm_ioremap() which let you 
> >> specify the memory attribute.
> > 
> > OK, I'll take a look at that.
> > 
> I have tried __arm_ioremap_pfn() for some DDR mapping and it didn't
> work as expected. The mapping was not getting created.

Did you investigate why it wasn't created?  Must have been a trivial 
issue surely?  But you have to wait until memory management is fully 
initialized to call the real ioremap() though, which happens later 
during the boot.

> Needless to say this can't be an IO memory. I later managed to get 
> around with it by using iotable_init() though downside is I have to 
> pick a static virtual address for the mapping.

You are using either MT_MEMORY or MT_MEMORY_NONCACHED in your map_desc 
entry.  So using e.g. __arm_ioremap(phys_addr, size, MT_MEMORY) should 
give you what you need, given that this is called late enough of course.

> But I agree that SRAM mapping can be moved further down. We
> just need to ensure that it's ready before we initialise SDRC
> and PM code. SDRC reconfigure of DDR needs to be executed from
> SRAM and of-course the PM WFI routine. Today we do SDRC init early
> and that's the reason SRAM is mapped before that. So both of them
> needs to be moved down in the boot to make it work.

Note that it is best not to call iotable_init() outside of the 
mdesc->map_io call path.  So either you reshuffle the initialization 
order so that the static mappings alre always in place before doing the 
ioremap() trick, or you use __arm_ioremap() later on.


Nicolas

  reply	other threads:[~2011-10-04 21:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 18:59 Please help with the OMAP static mapping mess Nicolas Pitre
2011-10-03 20:56 ` Tony Lindgren
2011-10-03 22:09   ` Nicolas Pitre
2011-10-03 22:38     ` Tony Lindgren
2011-10-04  7:04       ` Santosh Shilimkar
2011-10-04 21:21         ` Nicolas Pitre [this message]
2011-10-05  2:09           ` Rob Herring
2011-10-05  2:39             ` Nicolas Pitre
2011-10-05  6:16               ` Santosh Shilimkar
2011-10-03 22:39     ` Nicolas Pitre
2011-10-03 22:59       ` Tony Lindgren
2011-10-04  6:18         ` Shilimkar, Santosh
2011-10-04 17:50           ` Tony Lindgren
2011-10-03 22:44     ` Russell King - ARM Linux
2011-10-04 21:10       ` Nicolas Pitre
2011-10-04 22:54         ` Russell King - ARM Linux
2011-10-04 23:20           ` Nicolas Pitre
2011-10-05  0:42             ` Tony Lindgren
2011-10-05  0:57               ` Nicolas Pitre
2011-10-05  1:35                 ` 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=alpine.LFD.2.02.1110041458500.9106@xanadu.home \
    --to=nico@fluxnic.net \
    --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).