From: santosh.shilimkar@ti•com (Santosh Shilimkar)
To: linux-arm-kernel@lists•infradead.org
Subject: Please help with the OMAP static mapping mess
Date: Wed, 05 Oct 2011 11:46:24 +0530 [thread overview]
Message-ID: <4E8BF638.1000507@ti.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1110042232380.9106@xanadu.home>
On Wednesday 05 October 2011 08:09 AM, Nicolas Pitre wrote:
> On Tue, 4 Oct 2011, Rob Herring wrote:
>
>> On 10/04/2011 04:21 PM, Nicolas Pitre wrote:
>>> 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.
>>>
I didn't investigate further on it but may be it was because of the
ordering as you pointed out. The new __arm_ioremap_exe() seems to me
a good idea and should solve the problem.
Regards
Santosh
next prev parent reply other threads:[~2011-10-05 6:16 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
2011-10-05 2:09 ` Rob Herring
2011-10-05 2:39 ` Nicolas Pitre
2011-10-05 6:16 ` Santosh Shilimkar [this message]
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=4E8BF638.1000507@ti.com \
--to=santosh.shilimkar@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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