shared memory problem on ARM v5TE using threads

saeed bishara saeed.bishara at gmail.com
Tue Dec 15 02:50:53 EST 2009


On Mon, Dec 14, 2009 at 10:14 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Mon, 14 Dec 2009, christian pellegrin wrote:
>
>> On Mon, Dec 14, 2009 at 3:46 PM, Ronen Shitrit <rshitrit at marvell.com> wrote:
>>
>> > "
>> >
>> > I think your patch doesn't cover the PIO mode...
>> >
>>
>> Has someone a suggestion on how to write a test-case for this?
>
> I don't think there is any peripheral that runs in PIO mode on
> Kirkwood... except the NAND flash.
the sata can be configured to use pio instead of dma, this can be done
by adding libata.force=pio to the command line.
>
>> I tried various forms of mixing read/write syscalls (or a mmap wit
>> MAP_PRIVATE) and access via two mmap with MAP_SHARED aliasing the same
>> address (I checked that adjust_pte was called by them) but didn't get
>> any problem. I have to admit that I really don't understand how PIO in
>> kernel mode can refer to mappings that are aliased (and so market
>> uncacheable) made by user-space programs. Thank you for your patience.
>
> PIO transfer will store data in the kernel direct mapped memory which is
> always cached.  Normally the cache coherency with user space is handled
> by flush_dcache_page(), but that deals only with L1 and data can move to
> L2 where it will be invisible to the uncached user space shared
> mappings.
>
> I don't know off hand how PIO on a page that is already mapped and
> shared in user space may be produced though.
>
>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



More information about the linux-arm-kernel mailing list