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
> I'll go move the file and send the changeset to Linus.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/