Memory type used for ioremap

Memory type used for ioremap

[Pedanekar, Hemant]

Hello,

I have few doubts regarding the memory type configured when we call ioremap for mapping a region (e.g., on-chip peripheral MMRs):

Please note that this is regarding Cortx A8.

After examining 2nd level page descriptor, I see that the memory type configured for ioremapped region (as per TEX[2:0]=1 and CB=0) is "Outer and Inner Non-cacheable - Normal". Is this correct observation? I thought the ioremap would set memory type as one of the "Device".

What is the recommended method if I want to map some region as "Strongly-ordered" or "Device"?

Thanks
-
Hemant


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100709/0b637f70/attachment.html>

Memory type used for ioremap

[Catalin Marinas]

On Fri, 2010-07-09 at 03:16 +0100, Pedanekar, Hemant wrote:
> I have few doubts regarding the memory type configured when we call
> ioremap for mapping a region (e.g., on-chip peripheral MMRs):
>  
> Please note that this is regarding Cortx A8.
>  
> After examining 2nd level page descriptor, I see that the memory type
> configured for ioremapped region (as per TEX[2:0]=1 and CB=0) is
> "Outer and Inner Non-cacheable - Normal". Is this correct
> observation? I thought the ioremap would set memory type as one of the
> "Device". 
>  
> What is the recommended method if I want to map some region as
> "Strongly-ordered" or "Device"?

If you are trying to ioremap normal RAM, we no longer allow this and
force the memory type to be Normal Non-cacheable. This is an ARM
architecture requirement (otherwise you create mismatched memory
attributes aliases).


-- 
Catalin

Memory type used for ioremap

[Russell King - ARM Linux]

On Fri, Jul 09, 2010 at 07:46:31AM +0530, Pedanekar, Hemant wrote:
> I have few doubts regarding the memory type configured when we call
> ioremap for mapping a region (e.g., on-chip peripheral MMRs):

What's a MMR?

> Please note that this is regarding Cortx A8.
> 
> After examining 2nd level page descriptor, I see that the memory
> type configured for ioremapped region (as per TEX[2:0]=1 and CB=0)

That is correct.  TEX=001 C=0 B=0.

> is "Outer and Inner Non-cacheable - Normal".

I think that's where you're wrong.  TEX=001 C=0 B=0 is device memory.
On ARMv6 with fixed TEX values, this is described in the architecture
reference manual, and is 'shared device'.  On ARMv7 (which Cortex A8 is)
with TEX remapping, we arrange for this bit combination to be 'device'
and the shared-ness of the mapping depends on the S bit.

Memory type used for ioremap

[Pedanekar, Hemant]

Catalin,

I was trying to map peripheral region (memory mapped) nd faced problem with writes not working from kernel (ioremapped address), while writes using user space (devmem2) worked fine.

This prompted me to check if there were any differences in mapping the region when using devmem2 (mmap)and when using ioremap from kernel module. I observed that, when mapped using devmem2, the 2nd level page descriptor had TEX[2:0]=0 while in case of ioremap, the entry had TEX[2:0]=0 (C & B were 0 in both the cases).

As per ARM ARM, TEX=0 is "Strongly-ordered" while TEX=1 is "Normal" memory type, but of course as Russell has explained in the other mail, I had ignored TRE (assumed =0). So what could be wrong here? Why does userspace access work while kernel space doesn't? Of course, after *hacking* 2nd level page descriptor (ioremapped) entry to force TEX=0, I was able to write from kernel module!

Any inputs?

Thanks
-
Hemant
 
 

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com] 
> Sent: Friday, July 09, 2010 5:41 PM
> To: Pedanekar, Hemant
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: Memory type used for ioremap
> 
> On Fri, 2010-07-09 at 03:16 +0100, Pedanekar, Hemant wrote:
> > I have few doubts regarding the memory type configured when we call
> > ioremap for mapping a region (e.g., on-chip peripheral MMRs):
> >  
> > Please note that this is regarding Cortx A8.
> >  
> > After examining 2nd level page descriptor, I see that the 
> memory type
> > configured for ioremapped region (as per TEX[2:0]=1 and CB=0) is
> > "Outer and Inner Non-cacheable - Normal". Is this correct
> > observation? I thought the ioremap would set memory type as 
> one of the
> > "Device". 
> >  
> > What is the recommended method if I want to map some region as
> > "Strongly-ordered" or "Device"?
> 
> If you are trying to ioremap normal RAM, we no longer allow this and
> force the memory type to be Normal Non-cacheable. This is an ARM
> architecture requirement (otherwise you create mismatched memory
> attributes aliases).
> 
> 
> -- 
> Catalin
> 
> 

Memory type used for ioremap

[Russell King - ARM Linux]

On Fri, Jul 09, 2010 at 07:32:46PM +0530, Pedanekar, Hemant wrote:
> Catalin,
> 
> I was trying to map peripheral region (memory mapped) nd faced problem with w
> 
> This prompted me to check if there were any differences in mapping the region
> 
> As per ARM ARM, TEX=0 is "Strongly-ordered" while TEX=1 is "Normal" memory ty

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>

I think your problem might be to do with how the interconnects work.
Each different memory type can have a different memory map.  If your
peripheral is _only_ visible via the strongly ordered memory type,
then it won't be visible via (shared or non-shared) device or memory
like mappings.

We have had devices in the past where certain peripherals are only
visible via non-shared device mappings.  Could this be one of them?

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?

Memory type used for ioremap

[Pedanekar, Hemant]

Thanks for the clarification, I totally missed TRE setting.

(Regarding MMR, I wanted to say Memory Mapped peripheral registers.)

[...]
> On ARMv7 (which Cortex A8 is) with TEX remapping, we arrange for this bit
> combination to be 'device' and the shared-ness of the mapping depends on the S
> bit.

So if TEX[0]=1 with CB=0 is "Device" then what does TEX[0]=0 with CB=0 make the
region?

I am asking this because the first (default) setting didn't work for me
when writing to the mapped region, while setting TEX[0]=0 worked.

I referred the comment in proc-v7.S, but couldn't make out the meaning of
'TEX[0],C,B= 000' (there is just a mention about 'UNCACHED' but with TR-00).

Thanks
-
Hemant

Memory type used for ioremap

[Pedanekar, Hemant]

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:

I was trying to map peripheral region (memory mapped) and faced problem with
writes not working from kernel (ioremapped address), while writes using user
space (devmem2) worked fine.

This prompted me to check if there were any differences in mapping the region
when using devmem2 (mmap)and when using ioremap from kernel module. I observed
that, when mapped using devmem2, the 2nd level page descriptor had TEX[2:0]=0
while in case of ioremap, the entry had TEX[2:0]=0 (C & B were 0 in both the
cases).

As per ARM ARM, TEX=0 is "Strongly-ordered" while TEX=1 is "Normal" memory type,
but of course as Russell has explained in the other mail, I had ignored TRE
(assumed =0). So what could be wrong here? Why does userspace access work while
kernel space doesn't? Of course, after *hacking* 2nd level page descriptor
(ioremapped) entry to force TEX=0, I was able to write from kernel module!

Any inputs?
 
> I think your problem might be to do with how the interconnects work.
> Each different memory type can have a different memory map.  If your
> peripheral is _only_ visible via the strongly ordered memory type,
> then it won't be visible via (shared or non-shared) device or memory like
> mappings. 
> 
> 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.

Thanks
-
Hemant

Memory type used for ioremap

[Pedanekar, Hemant]

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.

Please note that to enable strongly-ordered mapping, I used the patch posted by
Paul Walmsley [1].

Can you please clarify the following?

1) Looks like ioremap() cannot be used for above case. Is there any alternative?
2) If the only way to go is create static mapping, which MT type shall I use? I
don't see anything like STRONGLY_ORDERED in arch/arm/mm/mmu.c
3) Do all ARMv7 have the same behavior regarding non-/posted nature of writes as
per the mapping - or is it implementation dependent?
4) I couldn't find any other mach-* where strongly ordered mapping was used.
Does this mean that strongly ordered access requirement is uncommon?
5) I see that the patch [1] from Paul is not present in arch/arm/mm/mmu.c but
the above mentioned constraint would require something similar (unless there is
better way to achieve this). So can you please suggest how to go about it?

Thanks
-
Hemant

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg02771.html

Memory type used for ioremap

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-
> kernel-bounces at lists.infradead.org] On Behalf Of Pedanekar, Hemant
> Sent: Tuesday, August 03, 2010 11:24 PM
> To: Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: RE: Memory type used for ioremap
> 
> 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

Memory type used for ioremap

[Pedanekar, Hemant]

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

Memory type used for ioremap

[Shilimkar, Santosh]

> -----Original Message-----
> From: Pedanekar, Hemant
> Sent: Wednesday, August 04, 2010 5:31 PM
> To: Shilimkar, Santosh; Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: RE: Memory type used for ioremap
> 
> 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,
> >>>>

> Santosh,
> 
> Can you please point me to the patch series you mentioned? I will give it
> a
> try.
http://www.spinics.net/lists/arm-kernel/msg93218.html

> 
> 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.
> 
Are you sure about this behaviour? 

Memory type used for ioremap

[Pedanekar, Hemant]

Shilimkar, Santosh wrote on Wednesday, August 04, 2010 5:35 PM:

>> -----Original Message-----
>> From: Pedanekar, Hemant
>> Sent: Wednesday, August 04, 2010 5:31 PM
>> To: Shilimkar, Santosh; Russell King - ARM Linux
>> Cc: linux-arm-kernel at lists.infradead.org
>> Subject: RE: Memory type used for ioremap
>> 
>> 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,
>>>>>> 
> 
>> Santosh,
>> 
>> Can you please point me to the patch series you mentioned? I will give it a
>> try.
> http://www.spinics.net/lists/arm-kernel/msg93218.html
>

Thanks for the link. I applied the patches and used writel/readl but no luck.
The MT_DEVICE mappings still result into writes not getting through.
 
>> 
>> 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.
>> 
> Are you sure about this behaviour?

Yes. The writes are not going through with MT_DEVICE mappings as the target
peripheral has requirement for non-posted writes.

Looks like only strongly ordered mapping is resulting into non-posted writes
which works. Is there any specific reason the strongly order mapping patch is
not accepted/applied?

Thanks
-
Hemant

Memory type used for ioremap

[Shilimkar, Santosh]

> -----Original Message-----
> From: Pedanekar, Hemant
> Sent: Wednesday, August 11, 2010 6:25 PM
> To: Shilimkar, Santosh; Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: RE: Memory type used for ioremap
> 
> Shilimkar, Santosh wrote on Wednesday, August 04, 2010 5:35 PM:
> 
> >> -----Original Message-----
> >> From: Pedanekar, Hemant
> >> Sent: Wednesday, August 04, 2010 5:31 PM
> >> To: Shilimkar, Santosh; Russell King - ARM Linux
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Subject: RE: Memory type used for ioremap
> >>
> >> 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,
> >>>>>>
> >
> >> Santosh,
> >>
> >> Can you please point me to the patch series you mentioned? I will give
> it a
> >> try.
> > http://www.spinics.net/lists/arm-kernel/msg93218.html
> >
> 
> Thanks for the link. I applied the patches and used writel/readl but no
> luck.
> The MT_DEVICE mappings still result into writes not getting through.
> 
> >>
> >> 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.
> >>
> > Are you sure about this behaviour?
> 
> Yes. The writes are not going through with MT_DEVICE mappings as the
> target
> peripheral has requirement for non-posted writes.
> 
> Looks like only strongly ordered mapping is resulting into non-posted
> writes
> which works. Is there any specific reason the strongly order mapping patch
> is
> not accepted/applied?

Attaching one which is I use for debugging. This is only for OMAP3/4
Hope this is useful to you.

I suggest only the device which has non-posted requirement
you convert it to SO

Regards,
Santosh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-OMAP3-4-Enable-IO-posting.patch
Type: application/octet-stream
Size: 7074 bytes
Desc: 0001-OMAP3-4-Enable-IO-posting.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100811/6b57000a/attachment-0001.obj>

Memory type used for ioremap

[Pedanekar, Hemant]

Shilimkar, Santosh wrote on Wednesday, August 11, 2010 6:34 PM:

>> -----Original Message-----
>> From: Pedanekar, Hemant
>> Sent: Wednesday, August 11, 2010 6:25 PM
>> To: Shilimkar, Santosh; Russell King - ARM Linux
>> Cc: linux-arm-kernel at lists.infradead.org
>> Subject: RE: Memory type used for ioremap
>> 
>> Shilimkar, Santosh wrote on Wednesday, August 04, 2010 5:35 PM:
>> 
>>>> -----Original Message-----
>>>> From: Pedanekar, Hemant
>>>> Sent: Wednesday, August 04, 2010 5:31 PM
>>>> To: Shilimkar, Santosh; Russell King - ARM Linux
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Subject: RE: Memory type used for ioremap
>>>> 
>>>> 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,
>>>>>>>> 
>>> 
>>>> Santosh,
>>>> 
>>>> Can you please point me to the patch series you mentioned? I will give
>>>> it a try.
>>> http://www.spinics.net/lists/arm-kernel/msg93218.html
>>> 
>> 
>> Thanks for the link. I applied the patches and used writel/readl but no
>> luck. The MT_DEVICE mappings still result into writes not getting through.
>> 
>>>> 
>>>> 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.
>>>> 
>>> Are you sure about this behaviour?
>> 
>> Yes. The writes are not going through with MT_DEVICE mappings as the target
>> peripheral has requirement for non-posted writes.
>> 
>> Looks like only strongly ordered mapping is resulting into non-posted
>> writes which works. Is there any specific reason the strongly order
>> mapping patch is not accepted/applied?
> 
> Attaching one which is I use for debugging. This is only for OMAP3/4 Hope
> this is useful to you. 
> 
> I suggest only the device which has non-posted requirement
> you convert it to SO
> 
> Regards,
> Santosh

Thanks again... yes the writes work fine with SO.

Is this patch accepted or under review? I don't see it on omap yet.

Thanks
-
Hemant

Memory type used for ioremap

[Russell King - ARM Linux]

On Wed, Aug 11, 2010 at 08:28:00PM +0530, Pedanekar, Hemant wrote:
> Is this patch accepted or under review? I don't see it on omap yet.

It's not something that would be accepted as its a local debugging
measure only.

What you could do is setup a static mapping using MT_UNCACHED instead,
which is what IOP platforms do for their PCI registers which are
explicitly stated to be SO.

Memory type used for ioremap

[Shilimkar, Santosh]

> -----Original Message-----
> From: Pedanekar, Hemant
> Sent: Wednesday, August 11, 2010 8:28 PM
> To: Shilimkar, Santosh; Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: RE: Memory type used for ioremap
> 
> Shilimkar, Santosh wrote on Wednesday, August 11, 2010 6:34 PM:
> 
> >> -----Original Message-----
> >> From: Pedanekar, Hemant
> >> Sent: Wednesday, August 11, 2010 6:25 PM
> >> To: Shilimkar, Santosh; Russell King - ARM Linux
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Subject: RE: Memory type used for ioremap
> >>
> >> Shilimkar, Santosh wrote on Wednesday, August 04, 2010 5:35 PM:
> >>
> >>>> -----Original Message-----
> >>>> From: Pedanekar, Hemant
> >>>> Sent: Wednesday, August 04, 2010 5:31 PM
> >>>> To: Shilimkar, Santosh; Russell King - ARM Linux
> >>>> Cc: linux-arm-kernel at lists.infradead.org
> >>>> Subject: RE: Memory type used for ioremap
> >>>>
> >>>> 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,
> >>>>>>>>
> >>>
> >>>> Santosh,
> >>>>
> >>>> Can you please point me to the patch series you mentioned? I will
> give
> >>>> it a try.
> >>> http://www.spinics.net/lists/arm-kernel/msg93218.html
> >>>
> >>
> >> Thanks for the link. I applied the patches and used writel/readl but no
> >> luck. The MT_DEVICE mappings still result into writes not getting
> through.
> >>
> >>>>
> >>>> 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.
> >>>>
> >>> Are you sure about this behaviour?
> >>
> >> Yes. The writes are not going through with MT_DEVICE mappings as the
> target
> >> peripheral has requirement for non-posted writes.
> >>
> >> Looks like only strongly ordered mapping is resulting into non-posted
> >> writes which works. Is there any specific reason the strongly order
> >> mapping patch is not accepted/applied?
> >
> > Attaching one which is I use for debugging. This is only for OMAP3/4
> Hope
> > this is useful to you.
> >
> > I suggest only the device which has non-posted requirement
> > you convert it to SO
> >
> > Regards,
> > Santosh
> 
> Thanks again... yes the writes work fine with SO.
> 
> Is this patch accepted or under review? I don't see it on omap yet.
> 
Last time this was shot down on the basis that barriers and read backs
should fix most of the ordering issues. I am surprised that correct 
barrier + readbacks, didn't work for you.

Can you explain which device has such a requirement with more details.
Most surprising part is, you are observering that a readback is returning
to the write-buffer contents which looks really weird to me.