re: CVS commit: src/sys/dev/pci

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Mon, 12 Dec 2011, matthew green wrote:

> > On Mon, Dec 12, 2011 at 03:54:57PM +1100, matthew green wrote:
> > > 
> > > > On Mon, Dec 12, 2011 at 02:44:15AM +0000, Jonathan A. Kollasch wrote:
> > > > > Module Name:  src
> > > > > Committed By: jakllsch
> > > > > Date:         Mon Dec 12 02:44:15 UTC 2011
> > > > > 
> > > > > Modified Files:
> > > > >       src/sys/dev/pci: if_sip.c
> > > > > 
> > > > > Log Message:
> > > > > Using BUS_DMA_NOCACHE for bus_dmamem_map() causes issues on (at 
> > > > > least) sparc64.
> > > > 
> > > > What kind of issues?
> > > 
> > > this is maping normal memory uncached.  attempting to access this
> > > mapping causes data faults.
> > 
> > Jonathan, please add some explanation to the commit message.
> > 
> > Isn't this just covering a bug in the sparc64 bus_dma(9) implementation?
> 
> that's what i have been wondering since writing the above.
> 
> eeh, should we turn off CP/CV and E bits for ram BUS_DMA_NOCACHE
> addresses, instead of device memory?

Hm.  Let me look at that commit....  (cvsweb is slooooo today...)  

Let's see... BUS_DMA_NOCACHE went into the man page in 2003 based on an 
x86 machine specific bit...  It was added to the sparc64 bus_dma.h at the 
same time...  Replacing an existing MD BUS_DMA_NOCACHE that was added to 
in 2000...

I can't figure out what the happened in x86 land... it seems to have moved 
across half a dozen files.

So...  The original BUS_DMA_NOCACHE for sparc64 had different semantics.  
It was supposed to be used for memory that is attached to the system 
through an I/O bus, such as the framebuffer on a PCI I/O card.

The options are:

1)  Remove the inherently MD BUS_DMA_NOCACHE flag from the man page so 
it's not used by people who don't understand why it's needed.

2)  Properly define the semantics of BUS_DMA_NOCACHE so people know when 
it needs to be used.

3)  Redefine that bit for sparc64.

Eduardo