Martyn Welch wrote:
That's one reason for the helper function. If VME bridges are added which sit of on other buses then vme_alloc_consistent can be extended to support this without requiring VME device drivers to be altered to reflect the fact that pci_alloc_consistent might not work for all VME bridges.
But it corresponds to the bridge's code (not to the generic layer) to
know whether the bridge sits on top of PCI or not; hence my comment.
The DMA controller in the tsi-148 can do PCI to PCI; PCI to VME; VME to PCI; VME to VME; Patterns to VME and Patterns to PCI transfers. How do you specify all those options without providing a structure where over 50% of the fields aren't used for any given transfer?
I think a struct where not _every_ field is *always* used is fine.
However requiring your drivers to know about what your bridge
looks like is a mistake; just give them something thin that doesn't
assume anything about what's behind it, and if it's not supported,
return an appropriate error message.
Every bridge I have seen is capable of link-list execution. The API provides the ability to do scatter-gather style DMA transfers, this could be used as part of a "zero-copy" type driver for high speed VME capture devices. How would you support the link-list execution with a single call?
Let me say it again: "Drivers should know *nothing* about the
underlying bridge".
They should work with *any* bridge; or do we care about the PCI
bridge we're plug our PCI device on when writing a driver for it?
I was also looking at the ability to queue DMA transfers if the controller was currently busy - if the consensus is that this is overkill I will happily remove this.
AFAICT the tsi148 has several DMA channels; in our driver we just
try to find a free channel to proceed with the transfer; if there
aren't any then we return EBUSY.
Drawing an analogy with current 'streaming DMA' transfers, we'reYes - my driver checks to see of the transfer has succeeded, I don't see quite what this has to do with the API. How's the API being clever?
told we should check whether they failed or not, so I think
trying to be too clever here it's not worth it.
If there's a better way to do this then fine - I'm happy to use it, however I'm not quite sure how this relates to the API, core VME code or low-level drivers. I think it's up to the authors of the VME device drivers themselves how they approach this. The API uses the standard bind-table approach as best as I could. If you can think of a better approach to this, patches will be welcome.I implemented it using param array, I agree that the arguments might get
quite long with 10 devices, especially if multiple parameters are
required, but I don't see why it shouldn't work.
The fact that 'it works' doesn't make it less ugly or messy.
When referring to code, these two words usually mean "there's
a better way"; so let's just find it.
E.