From: Philip B. <ph...@bo...> - 2003-03-03 06:43:55
|
Could someone explain what exactly DRM_READMEMORYBARRIER is supposed to do, in the kernel driver level, please? I was initially thinking that it did some kind of "enable bus memory mapping" OS call. However, it is used inconsistently. mga_drv.h and radeon_drv.h use it , each at only one place in the code. mga seems to use it consistently before all DRM_READ8() type calls, via an inline func _MGA_READ() However, radeon_drv.h only uses it before the READ8 call in COMMIT_RING() [and radeon is consistent in lots of other ways, too. Some places it uses RADEON_READ(), other places, DRM_READ32(). Maybe this is the cause of some of the radeon problems?] Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel space.... which still leaves the question of, what does DRM_READMEMORYBARRIER() do? |
From: Michel <mi...@da...> - 2003-03-03 13:53:41
|
On Mon, 2003-03-03 at 07:43, Philip Brown wrote: > Could someone explain what exactly DRM_READMEMORYBARRIER is supposed to do, > in the kernel driver level, please? > > I was initially thinking that it did some kind of > "enable bus memory mapping" OS call. > However, it is used inconsistently. > > mga_drv.h and radeon_drv.h use it , each at only one place in the code. > > mga seems to use it consistently before all DRM_READ8() type calls, > via an inline func _MGA_READ() > > > However, radeon_drv.h only uses it before the READ8 call in > COMMIT_RING() > > [and radeon is consistent in lots of other ways, too. > Some places it uses RADEON_READ(), other places, DRM_READ32(). > Maybe this is the cause of some of the radeon problems?] No. Basically, RADEON_READ() is for chip register reads, DRM_READ32 for reading little endian words from PCI space. If you care to look up the definition of RADEON_READ() though, you see that it uses DRM_READ32(). > Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel > space.... which still leaves the question of, what does > DRM_READMEMORYBARRIER() do? As the name says, it issues a memory barrier. :) It prevents the compiler or CPU from reordering memory access beyond the barrier. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Philip B. <ph...@bo...> - 2003-03-03 18:48:55
|
On Mon, Mar 03, 2003 at 02:48:32PM +0100, Michel Dänzer wrote: > ... > > Besides which, DRM(ioremap) seems to do the *actual* mapping to kernel > > space.... which still leaves the question of, what does > > DRM_READMEMORYBARRIER() do? > > As the name says, it issues a memory barrier. :) I beg to differ... there is no verb in it, so it does _not_ say "issues a memory barrier" :-) Now, if it were called DRM_SET_MEMORYBARRIER(), that would be different. But anyway, sounds like I can NOP it out, I guess. |
From: Alan Y. <ay...@te...> - 2003-03-04 01:42:59
|
On Mon, 3 Mar 2003 10:48:54 -0800 Philip Brown <ph...@bo...> wrote: > > But anyway, sounds like I can NOP it out, I guess. You may be able to NOP it if your platform does not require it. I know the Alpha uses memory barriers. I think PPC may use them too. Here's a bit from the Alpha Architecture Handbook on the Alpha's memory barrier instruction: "Description: The use of the Memory Barrier (MB) instruction is required only in multiprocessor systems. In the absence of an MB instruction, loads and stores to different physical locations are allowed to complete out of order on the issuing processor as observed by other processors. The MB instruction allows memory accesses to be serialized on the issuing processor as observed by other processors. See Chapter 5 for details on using the MB instruction to serialize these accesses. Chapter 5 also details coordinating memory accesses across processors. Note that MB ensures serialization only; it does not necessarily accelerate the progress of memory operations." While the handbook indicates it's only required on multprocessor systems, they are used on single processor systems to ensure write(s) are committed before the next read or re-read. Alan |
From: Philip B. <ph...@bo...> - 2003-03-04 04:19:27
|
On Mon, Mar 03, 2003 at 05:42:24PM -0800, Alan Young wrote: > On Mon, 3 Mar 2003 10:48:54 -0800 Philip Brown <ph...@bo...> wrote: > > > > But anyway, sounds like I can NOP it out, I guess. > > You may be able to NOP it if your platform does not require > it. I know the Alpha uses memory barriers. I think PPC may > use them too. > > Here's a bit from the Alpha Architecture Handbook on the Alpha's > memory barrier instruction: > ... ah. Thanks for the extra info. [someone might want to comment the thing in the header files] Solaris handles it differently. It specifies a particular memory mapping as needing sequential access, at map time, I believe. |
From: Benjamin H. <be...@ke...> - 2003-03-04 20:15:37
|
On Tue, 2003-03-04 at 05:19, Philip Brown wrote: > ah. Thanks for the extra info. > [someone might want to comment the thing in the header files] > > Solaris handles it differently. It specifies a particular memory mapping as > needing sequential access, at map time, I believe. The purpose of this barrier isn not to ensure sequential access on either the MMIO mapping (card registers) nor the actual ring buffer memory mapping (could be IOs, or just real memory with PCI GART). It's here to actually sync those 2 between each other. That is make sure the writes to the ring are completed before the chip is actually kicked. This is a nasty corner case often overlooked in drivers, see a mail I just posted to lkml '[RFC] IO vs. DMA and barriers' Ben. |
From: Philip B. <ph...@bo...> - 2003-03-04 23:07:09
|
On Tue, Mar 04, 2003 at 09:18:40PM +0100, Benjamin Herrenschmidt wrote: > > The purpose of this barrier isn not to ensure sequential access on > either the MMIO mapping (card registers) nor the actual ring buffer > memory mapping (could be IOs, or just real memory with PCI GART). > > It's here to actually sync those 2 between each other. That is make > sure the writes to the ring are completed before the chip is actually > kicked. This is a nasty corner case often overlooked in drivers, see > a mail I just posted to lkml '[RFC] IO vs. DMA and barriers' Ooo. Quite different. So that sounds like I'll want DRM_READMEMORYBARRIER() to call ddi_dma_sync() [ you've probably never seen that function before in your life, but I think it's a heck of a lot more self-documenting than "DRM_READMEMORYBARRIER()" , "mb()", or even "bus_space_barrier()" ;-) ] |
From: Alan C. <al...@lx...> - 2003-03-04 12:40:15
|
On Tue, 2003-03-04 at 01:42, Alan Young wrote: > While the handbook indicates it's only required on multprocessor > systems, they are used on single processor systems to ensure > write(s) are committed before the next read or re-read. You also need to know the ordering rules three ways between your PCI bus (including posting), your AGP gart and your CPU/memory. |