I have mmap_device_memory()'d some registers for a device but it seems that
the device isn’t receiving the values all the time. ie… the cache isn’t
being flushed.
I read in the mmap_device_memory doc that PPC may have to use eieio(). I
can’t find documentation on this. I blindly put the call after my writes
and it didn’t seem to help.
I also tried mmap_device_io() with the in* out* calls. I got similiar
results.
This code works on x86 as is. But shows this behavior on PPC. (yes,
byteswapping is taken care of).
How can I flush this cache? And what is eieio()?
Thanks…
Dan.
Daniel S. Chivers <dchivers@systran.com> wrote:
I have mmap_device_memory()'d some registers for a device but it seems that
the device isn’t receiving the values all the time. ie… the cache isn’t
being flushed.
Doesn’t it make more sense to map it non-cache ?
mmap_device_memory(…, PROT_READ | PROT_WRITE | PROT_NONCACHE, …);
-xtang
I read in the mmap_device_memory doc that PPC may have to use eieio(). I
can’t find documentation on this. I blindly put the call after my writes
and it didn’t seem to help.
I also tried mmap_device_io() with the in* out* calls. I got similiar
results.
This code works on x86 as is. But shows this behavior on PPC. (yes,
byteswapping is taken care of).
How can I flush this cache? And what is eieio()?
Thanks…
Dan.
Daniel S. Chivers <dchivers@systran.com> wrote:
I have mmap_device_memory()'d some registers for a device but it seems that
the device isn’t receiving the values all the time. ie… the cache isn’t
being flushed.
I read in the mmap_device_memory doc that PPC may have to use eieio(). I
can’t find documentation on this. I blindly put the call after my writes
and it didn’t seem to help.
I also tried mmap_device_io() with the in* out* calls. I got similiar
results.
This code works on x86 as is. But shows this behavior on PPC. (yes,
byteswapping is taken care of).
How can I flush this cache? And what is eieio()?
Isn’t that what Old MacDonald said down on his farm? 
Try grep eieio
/usr/include// and you’ll see that there is an inline assembly call for
eieio on the various platforms. Looks like eieio is an assembly instruction
on ppc (the equivalent on mips is “sync”). I don’t have the ppc definition
but on mips it’s “load/store barrier” It looks like it’s for multi-processor
(and non-strongly ordered) machines to ensure that all load/stores done before
the sync will be seen before any load/store started afterwards. Man, this
“See Mips Run” is a cool book…
As far as your application is concerned, I’m not sure if this will take care
of flushing between device memory…it looks to me like it’s only for
memory accesses between CPU’s and pipelines.
cheers,
Kris
Thanks…
Dan.
–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“Computer science is no more about computers than astronomy is about telescopes”
–E.W.Dijkstra
Isn’t that what Old MacDonald said down on his farm? > > Try grep eieio
/usr/include// and you’ll see that there is an inline assembly call
for eieio on the various platforms. Looks like eieio is an assembly
instruction on ppc (the equivalent on mips is “sync”). I don’t have the
ppc definition but on mips it’s “load/store barrier” It looks like it’s
for multi-processor (and non-strongly ordered) machines to ensure that
all load/stores done before the sync will be seen before any load/store
started afterwards. Man, this “See Mips Run” is a cool book…>
As far as your application is concerned, I’m not sure if this will take
care of flushing between device memory…it looks to me like it’s only
for memory accesses between CPU’s and pipelines. cheers,
Kris
Thanks Kris, this makes sense… And is the case. The reason my cache
looked as if it wasn’t being flushed was actually behavior of my DMA
controller gone wrong when it fails to read memory. mphys is returning a
bad address and the DMA controller just sits on it as if I never told it not
to “go”. I still haven’t solved the mphys problem on Power PC. I simply
get the wrong address. (DMAs are going elsewhere).
I used a PCI bus analyser to find out what was happening.
I tried to do a linear search on /dev/mem to see if I can find my buffer
and come up with the virtual->physical mapping myself but /dev/mem seems to be extremely
buggy on PowerPC and crashes the system.
Has anyone DMA’d on PowerPC? And how did you get that DMA address?
Dan.
Thanks Kris, this makes sense… And is the case. The reason my cache
looked as if it wasn’t being flushed was actually behavior of my DMA
controller gone wrong when it fails to read memory. mphys is returning a
bad address and the DMA controller just sits on it as if I never told it not
to “go”. I still haven’t solved the mphys problem on Power PC. I simply
get the wrong address. (DMAs are going elsewhere).
This is really very odd. Nearly all the PCI ethernet devices that we have
PPC drivers for have the PCI device DMA packet data right into host memory
and there is no PPC specific code. Can you post both your call to mmap()
and mphys() that you are using (along with variables types for any variables
being used).
chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
“Chris McKillop” <cdm@qnx.com> wrote in message
news:9uqp4d$i1o$1@nntp.qnx.com…
Thanks Kris, this makes sense… And is the case. The reason my cache
looked as if it wasn’t being flushed was actually behavior of my DMA
controller gone wrong when it fails to read memory. mphys is returning
a
bad address and the DMA controller just sits on it as if I never told it
not
to “go”. I still haven’t solved the mphys problem on Power PC. I
simply
get the wrong address. (DMAs are going elsewhere).
This is really very odd. Nearly all the PCI ethernet devices that we have
PPC drivers for have the PCI device DMA packet data right into host memory
and there is no PPC specific code. Can you post both your call to mmap()
and mphys() that you are using (along with variables types for any
variables
being used).
Could this be an endian issue? The DMA controller could expect a different
endian type?
chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
OK… I got it working (finally). You have to add the CpuBmstrTranslation to the mphys returned
physical address to get the DMA address.
CpuBmstrTranslation is a member of pci_dev_info passed to
pci_attach_device().
Of course this value happens to be 0x0 on Intel.
Something very different on PowerPC.
Thanks all for your help.
Dan.