| Message ID | 20240223-iio-dmabuf-v7-0-78cfaad117b9@analog.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: new DMABUF based API | expand |
On Fri, 23 Feb 2024 13:13:58 +0100 Nuno Sa <nuno.sa@analog.com> wrote: > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be > honest, we're hoping to get this merged this for the 6.9 merge window. > Main reason is because the USB part is already in (so it would be nice > to get the whole thing in). Moreover, the changes asked in v6 were simple > (even though I'm not quite sure in one of them) and Paul has no access to > it's laptop so he can't send v7 himself. So he kind of said/asked for me to do it. So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we can sneak this in. However, I need an Ack from Vinod for the dma engine changes first. Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!) Seems that the other side got resolved in the USB gadget, but last we heard form Daniel and Christian looks to have been back on v5. I'd like them to confirm they are fine with the changes made as a result. I've been happy with the IIO parts for a few versions now but my ability to review the DMABUF and DMA engine bits is limited. A realistic path to get this in is rc8 is happening, is all Acks in place by Wednesday, I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday and Greg is feeling particularly generous to take one on the day he normally closes his trees. Whilst I'll cross my fingers, looks like 6.10 material to me :( I'd missed the progress on the USB side so wasn't paying enough attention. Sorry! Jonathan > > v6: > * https://lore.kernel.org/linux-iio/20240129170201.133785-1-paul@crapouillou.net/ > > v7: > - Patch 1 > * Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec(); > * Added a new flag parameter to the function as agreed between Paul > and Vinod. I renamed the first parameter to prep_flags as it's supposed to > be used (I think) with enum dma_ctrl_flags. I'm not really sure how that API > can grow but I was thinking in just having a bool cyclic parameter (as the > first intention of the flags is to support cyclic transfers) but ended up > "respecting" the previously agreed approach. > - Patch 2 > * Adapted patch for the changes made in patch 1. > - Patch 5 > * Adapted patch for the changes made in patch 1. > > Patchset based on next-20240223. > > --- > Paul Cercueil (6): > dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() > dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec > iio: core: Add new DMABUF interface infrastructure > iio: buffer-dma: Enable support for DMABUFs > iio: buffer-dmaengine: Support new DMABUF based userspace API > Documentation: iio: Document high-speed DMABUF based API > > Documentation/iio/dmabuf_api.rst | 54 +++ > Documentation/iio/index.rst | 2 + > drivers/dma/dma-axi-dmac.c | 40 ++ > drivers/iio/buffer/industrialio-buffer-dma.c | 181 +++++++- > drivers/iio/buffer/industrialio-buffer-dmaengine.c | 59 ++- > drivers/iio/industrialio-buffer.c | 462 +++++++++++++++++++++ > include/linux/dmaengine.h | 27 ++ > include/linux/iio/buffer-dma.h | 31 ++ > include/linux/iio/buffer_impl.h | 33 ++ > include/uapi/linux/iio/buffer.h | 22 + > 10 files changed, 894 insertions(+), 17 deletions(-) > --- > base-commit: 33e1d31873f87d119e5120b88cd350efa68ef276 > change-id: 20240223-iio-dmabuf-5ee0530195ca > -- > > Thanks! > - Nuno Sá >
On Sun, 2024-03-03 at 17:42 +0000, Jonathan Cameron wrote: > On Fri, 23 Feb 2024 13:13:58 +0100 > Nuno Sa <nuno.sa@analog.com> wrote: > > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be > > honest, we're hoping to get this merged this for the 6.9 merge window. > > Main reason is because the USB part is already in (so it would be nice > > to get the whole thing in). Moreover, the changes asked in v6 were simple > > (even though I'm not quite sure in one of them) and Paul has no access to > > it's laptop so he can't send v7 himself. So he kind of said/asked for me to > > do it. > > So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we > can sneak this in. However, I need an Ack from Vinod for the dma engine > changes first. > > Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!) > > Seems that the other side got resolved in the USB gadget, but last we heard > form > Daniel and Christian looks to have been back on v5. I'd like them to confirm > they are fine with the changes made as a result. > I can ask Christian or Daniel for some acks but my feeling (I still need, at some point, to get really familiar with all of this) is that this should be pretty similar to the USB series (from a DMABUF point of view) as they are both importers. > I've been happy with the IIO parts for a few versions now but my ability to > review > the DMABUF and DMA engine bits is limited. > > A realistic path to get this in is rc8 is happening, is all Acks in place by > Wednesday, > I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday > and Greg > is feeling particularly generous to take one on the day he normally closes his > trees. > Well, it looks like we still have a shot. I'll try to see if Vinod is fine with the DMAENGINE stuff. - Nuno Sá
On Mon, 04 Mar 2024 08:59:47 +0100 Nuno Sá <noname.nuno@gmail.com> wrote: > On Sun, 2024-03-03 at 17:42 +0000, Jonathan Cameron wrote: > > On Fri, 23 Feb 2024 13:13:58 +0100 > > Nuno Sa <nuno.sa@analog.com> wrote: > > > > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be > > > honest, we're hoping to get this merged this for the 6.9 merge window. > > > Main reason is because the USB part is already in (so it would be nice > > > to get the whole thing in). Moreover, the changes asked in v6 were simple > > > (even though I'm not quite sure in one of them) and Paul has no access to > > > it's laptop so he can't send v7 himself. So he kind of said/asked for me to > > > do it. > > > > So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we > > can sneak this in. However, I need an Ack from Vinod for the dma engine > > changes first. > > > > Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!) > > > > Seems that the other side got resolved in the USB gadget, but last we heard > > form > > Daniel and Christian looks to have been back on v5. I'd like them to confirm > > they are fine with the changes made as a result. > > > > I can ask Christian or Daniel for some acks but my feeling (I still need, at > some point, to get really familiar with all of this) is that this should be > pretty similar to the USB series (from a DMABUF point of view) as they are both > importers. > > > I've been happy with the IIO parts for a few versions now but my ability to > > review > > the DMABUF and DMA engine bits is limited. > > > > A realistic path to get this in is rc8 is happening, is all Acks in place by > > Wednesday, > > I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday > > and Greg > > is feeling particularly generous to take one on the day he normally closes his > > trees. > > > > Well, it looks like we still have a shot. I'll try to see if Vinod is fine with > the DMAENGINE stuff. > Sadly, looks like rc7 was at the end of a quiet week, so almost certain to not be an rc8 in the end. Let's aim to get this in at the start of the next cycle so we can build on it from there. Jonathan > - Nuno Sá > >
Hi Jonathan, Le mardi 05 mars 2024 à 10:07 +0000, Jonathan Cameron a écrit : > On Mon, 04 Mar 2024 08:59:47 +0100 > Nuno Sá <noname.nuno@gmail.com> wrote: > > > On Sun, 2024-03-03 at 17:42 +0000, Jonathan Cameron wrote: > > > On Fri, 23 Feb 2024 13:13:58 +0100 > > > Nuno Sa <nuno.sa@analog.com> wrote: > > > > > > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, > > > > to be > > > > honest, we're hoping to get this merged this for the 6.9 merge > > > > window. > > > > Main reason is because the USB part is already in (so it would > > > > be nice > > > > to get the whole thing in). Moreover, the changes asked in v6 > > > > were simple > > > > (even though I'm not quite sure in one of them) and Paul has no > > > > access to > > > > it's laptop so he can't send v7 himself. So he kind of > > > > said/asked for me to > > > > do it. > > > > > > So, we are cutting this very fine. If Linus hints strongly at an > > > rc8 maybe we > > > can sneak this in. However, I need an Ack from Vinod for the dma > > > engine > > > changes first. > > > > > > Also I'd love a final 'looks ok' comment from DMABUF folk (Ack > > > even better!) > > > > > > Seems that the other side got resolved in the USB gadget, but > > > last we heard > > > form > > > Daniel and Christian looks to have been back on v5. I'd like them > > > to confirm > > > they are fine with the changes made as a result. > > > > > > > I can ask Christian or Daniel for some acks but my feeling (I still > > need, at > > some point, to get really familiar with all of this) is that this > > should be > > pretty similar to the USB series (from a DMABUF point of view) as > > they are both > > importers. > > > > > I've been happy with the IIO parts for a few versions now but my > > > ability to > > > review > > > the DMABUF and DMA engine bits is limited. > > > > > > A realistic path to get this in is rc8 is happening, is all Acks > > > in place by > > > Wednesday, > > > I get apply it and hits Linux-next Thursday, Pull request to Greg > > > on Saturday > > > and Greg > > > is feeling particularly generous to take one on the day he > > > normally closes his > > > trees. > > > > > > > Well, it looks like we still have a shot. I'll try to see if Vinod > > is fine with > > the DMAENGINE stuff. > > > > Sadly, looks like rc7 was at the end of a quiet week, so almost > certain to not > be an rc8 in the end. Let's aim to get this in at the start of the > next cycle > so we can build on it from there. And it looks like I'll need a V8 for the few things noted by Christian. Having it in 6.9 would have been great but having it eventually merged is all that matters - so I'm fine to have it queued for 6.10 instead. Cheers, -Paul
Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be honest, we're hoping to get this merged this for the 6.9 merge window. Main reason is because the USB part is already in (so it would be nice to get the whole thing in). Moreover, the changes asked in v6 were simple (even though I'm not quite sure in one of them) and Paul has no access to it's laptop so he can't send v7 himself. So he kind of said/asked for me to do it. v6: * https://lore.kernel.org/linux-iio/20240129170201.133785-1-paul@crapouillou.net/ v7: - Patch 1 * Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec(); * Added a new flag parameter to the function as agreed between Paul and Vinod. I renamed the first parameter to prep_flags as it's supposed to be used (I think) with enum dma_ctrl_flags. I'm not really sure how that API can grow but I was thinking in just having a bool cyclic parameter (as the first intention of the flags is to support cyclic transfers) but ended up "respecting" the previously agreed approach. - Patch 2 * Adapted patch for the changes made in patch 1. - Patch 5 * Adapted patch for the changes made in patch 1. Patchset based on next-20240223. --- Paul Cercueil (6): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation/iio/dmabuf_api.rst | 54 +++ Documentation/iio/index.rst | 2 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/buffer/industrialio-buffer-dma.c | 181 +++++++- drivers/iio/buffer/industrialio-buffer-dmaengine.c | 59 ++- drivers/iio/industrialio-buffer.c | 462 +++++++++++++++++++++ include/linux/dmaengine.h | 27 ++ include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 33 ++ include/uapi/linux/iio/buffer.h | 22 + 10 files changed, 894 insertions(+), 17 deletions(-) --- base-commit: 33e1d31873f87d119e5120b88cd350efa68ef276 change-id: 20240223-iio-dmabuf-5ee0530195ca -- Thanks! - Nuno Sá