Memory type used for ioremap

Pedanekar, Hemant hemantp at ti.com
Wed Aug 4 08:01:15 EDT 2010


Shilimkar, Santosh wrote:
>> Pedanekar, Hemant wrote:
>>> Russell King - ARM Linux wrote:
>>>> On Fri, Jul 09, 2010 at 07:32:46PM +0530, Pedanekar,
> Hemant wrote:
>>>>> Catalin,
>>>> 
>>>> It'd help if I could see more of your mail than just the above when
>>>> replying to it.  Please wrap your messages rather than typing entire
>>>> paragraphs on one single line.
>>>> 
>>>> <save this message, go back and read your original, re-edit reply>
>>>> 
>>> 
>>> Sorry for that. Here is the earlier reply:
>>> 
>> [...]
>>>> 
>>>> We have had devices in the past where certain peripherals are only
>>>> visible via non-shared device mappings.  Could this be one of them?
>>>> 
>>> 
>>> If I wanted to have mapping for "Strongly-ordered" memory type, is there
>>> any function that I can use from driver? I guess 'ioremap' won't help
>>> here? Probably I need to use MT_MEMORY_NONCACHED and do a static mapping?
>>> 
>>>> Without knowing more about the device you're using, in particular
>>>> how the bus matrix is setup, there's no way to comment definitively.
>>>> What does the documentation for your device say about the type of
>>>> mappings required for this peripheral?
>>> 
>>> I will confirm and update but looks like I need to have "Strongly-
>>> ordered" type. 
>>> 
>> 
>> Russell,
>> 
>> I have confirmed that with mapping the concerned region as "Strongly
>> Ordered", the write accesses work fine.
>> 
>> Following are the observations and particulars:
>> 
>> 1) The peripheral region has constraint that it requires writes to be
>> non-posted. Posted writes are not supported.
>> 2) On my system, writes to the region mapped as MT_DEVICE or
>> MT_DEVICE_NONSHARED are posted and hence do not work in this case.
>> 3) While writes on "Strongly Ordered" region are non-posted and work fine.
>> 
> DEVICE attributes with proper ordering(barriers) also should work. If you
> use recent series from Catalin the ordering is more or less taken care from
> CPU point of view.
> 
> For interconnect ordering, you need to a read back in some cases. This is
> better option from performance point of view than SO.
> SO is very good to figure out ordering BUGS though.
> 
> Regards,
> Santosh

Santosh,

Can you please point me to the patch series you mentioned? I will give it a
try.

Regarding read-back, the writes themselves are not successful as the peripheral 
has specific requirement for non-posted writes. So reading back after write 
Always returns old value.

Thanks
-
Hemant




More information about the linux-arm-kernel mailing list