Am 30.01.24 um 11:40 schrieb Daniel Vetter:
On Tue, Jan 30, 2024 at 10:48:23AM +0100, Paul Cercueil wrote:
Le mardi 30 janvier 2024 à 10:23 +0100, Christian König a écrit :
I would say we start with the DMA-API by getting away from sg_tables
to something cleaner and state oriented.
FYI I am already adding a 'dma_vec' object in my IIO DMABUF patchset,
which is just a dead simple
struct dma_vec {
dma_addr_t addr;
size_t len;
};
(The rationale for introducing it in the IIO DMABUF patchset was that
the "scatterlist" wouldn't allow me to change the transfer size.)
So I believe a new "sg_table"-like could just be an array of struct
dma_vec + flags.
Yeah that's pretty much the proposal I've seen, split the sg table into
input data (struct page + len) and output data (which is the dma_addr_t +
len you have above).
I would extend that a bit and say we have an array with
dma_addr+power_of_two_order and a header structure with lower bit offset
and some DMA transaction flags.
But this is something which can be worked as an optimization later on.
For a start this proposal here looks good to me as well.
The part I don't expect to ever happen, because it hasn't the past 20 or
so years, is that the dma-api will give us information about what is
needed to keep the buffers coherency between various devices and the cpu.
Well maybe that's what we are doing wrong.
Instead of asking the dma-api about the necessary information we should
give the API the opportunity to work for us.
In other words we don't need the information about buffer coherency what
we need is that the API works for as and fulfills the requirements we have.
So the question is really what should we propose to change on the
DMA-api side to get this working as expected?
Regards,
Christian.
-Sima
