Subject: Re: memory mapping

From: Philip Blundell <[email-masked]>
Date: Thu, 03 Sep 1998 13:44:43 +0100

>You have to read from PCI to flush it. I know.

Indeed, and that can take quite a long time.  PCI reads are a slow business.

>I want to calculate a depth buffer. Each depth takes some time to calculate.
>After it has been calculated it must simply be put in the shared memory
>segment.  I never have to read this segment from the sa.

If you can guarantee never to read from that area then it can be a win to map 
it cacheable so that you take advantage of burst writes.  The 21285 data sheet 
does admittedly say that you mustn't do this but I'm not sure whether it 
really means it.

>	Changing the kernel mapping for your particular application is
>	probably OK, 
>
>Can you tell me if this would be much work ? Do i also have to modify
>the dynamic linker and possibly other tools ?

No.  The dynamic linker only cares about user space and it mmap()s the 
libraries in so the kernel can impose its own address restrictions there.  
None of the other tools know anything about addressing.

There are some definitions in include/asm-arm/proc-armv that would need to be 
changed (probably the best thing would be to push them into an arch/ include) 
but that's about it.

p.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Mark van Doesburg <[email-masked]>
Date: Thu, 3 Sep 1998 15:40:09 +0200

>After having this setup i would add shared memory segments. These would
	>be located on the host, which has cache coherency hardware.

	Be warned that posted-write FIFOs and the like can still screw
	you up even if you have cache coherency in the chipset.

You have to read from PCI to flush it. I know. I've read the entire datasheet
of the 21285 to make sure i wouldn't get any unwanted surprises. The only
unwanted surprise is that i cannot access the entire PCI memory space, this
can be solved i guess.

	>I want to map the PCI memory space uncached. That would not give a
	>preformance penalty for me.

	Are you sure?  The StrongARM never performs burst accesses to
	uncacheable regions and this can be quite a hit.

I want to calculate a depth buffer. Each depth takes some time to calculate.
After it has been calculated it must simply be put in the shared memory segment.
I never have to read this segment from the sa.

	>If it really is a bad idea to change the kernel mapping, i guess i'll
	>just have to use the DMA channel.

	though you might consider using the 21285's DMA engine anyway as
	you might well get better performance that way.

I was actually planning to implement both and let the packet size determine
if the DMA channel should be used or not.

I would also have trouble with the messages passing if i don't map all
PCI space. Nothing that can't be solved with a small preformance penalty
however.

Using the DMA channel for all sa->sa communication doesn't look that bad
after all.

	p.

Mark.