Re: Problems with 2.5.14 PCI reorg and non-PCI architectures

[James Bottomley <James.Bottomley@SteelEye.com>]

greg@kroah.com said:
> No wait, the NCR driver needs Microchannel, is that true? 

Correct. the two drivers (lasi700 and NCR_D700) both use 53c700 to drive the 
chip core, but they take care of interfacing to the local bus, whatever it is. 
 The chip core (which is bus independent) still has to allocate consistent 
memory for the chip mailbox (although I suppose I could alter the bus drivers 
to pass in a pointer to a pre-allocated region).  I can't get away without 
using pci_sync_single et al. in the bus independent driver, though.

> I would like to push back and ask why you are calling a pci_* function
> from a driver that does not need pci.  Yes, I know it's a nice,
> generic function, but that hasn't stopped people from rewriting that
> same function a number of times in different forms in different places
> in the tree:) 

The 53c700 core must be able to use synchronous memory (if it can) on parisc.  
The only global call for this is pci_alloc_consistent (and its use is advised 
in Documentation/DMA-mapping.txt).  Obviously, x86 is fully synchronous 
anyway, so it only needs to support the call as a type of nop.

> In a perfect world, we should probably create a function like:
> 	void *alloc_consistent (int flags, size_t size, dma_addr_t
> *dma_handle); to solve everyone's needs, but I'm not volunteering to
> do that :) 

I agree with this.  Debate around this naming issue came up in the parisc 
groups (again because we need consistent allocations and some legacy machines 
don't have PCI busses).  The official response them was use 
pci_alloc_consistent and don't worry about it seeming to be a pci specific 
function.  Really, it is only legacy machines that are non-pci, so I suppose 
it does make some sense to have them as special cases of pci specific 
functions.

> I'll go move the file and send the changeset to Linus. 

Thanks!

James