similar to: [PATCH net-next] xsk: introduce xsk_dma_ops

On Thu, Apr 20, 2023 at 09:18:21AM -0700, Christoph Hellwig wrote: > On Thu, Apr 20, 2023 at 05:11:48PM +0800, Xuan Zhuo wrote: > > I know that the current design of DMA API only supports some physical hardware, > > but can it be modified or expanded? > > I think the important point is that for some cases there is no need > to dma map at all, and upper layers should be

On Wed, Apr 19, 2023 at 09:45:06AM -0700, Jakub Kicinski wrote: > > Can you explain what the actual use case is? > > > > From the original patchset I suspect it is dma mapping something very > > long term and then maybe doing syncs on it as needed? > > In this case yes, pinned user memory, it gets sliced up into MTU sized > chunks, fed into an Rx queue of a

On Tue, 2020-03-10 at 14:05 +0300, Alexander Lobakin wrote: > rproc_serial_id_table lacks an exposure to module devicetable, so > when remoteproc firmware requests VIRTIO_ID_RPROC_SERIAL, no uevent > is generated and no module autoloading occurs. > Add missing MODULE_DEVICE_TABLE() annotation and move the existing > one for VIRTIO_ID_CONSOLE right to the table itself. > >

Add a new API to allocate and free memory that is guaranteed to be addressable by a device, but which potentially is not cache coherent for DMA. To transfer ownership to and from the device, the existing streaming DMA API calls dma_sync_single_for_device and dma_sync_single_for_cpu must be used. For now the new calls are implemented on top of dma_alloc_attrs just like the old-noncoherent API,

Use the new non-coherent DMA API including proper ownership transfers. This also means we can allocate the buffer memory with the proper direction instead of bidirectional. Signed-off-by: Christoph Hellwig <hch at lst.de> --- sound/mips/hal2.c | 58 ++++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/sound/mips/hal2.c

Use the new non-coherent DMA API including proper ownership transfers. This also means we can allocate the memory as DMA_TO_DEVICE instead of bidirectional. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/scsi/sgiwd93.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c index

Use the new non-coherent DMA API including proper ownership transfers. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/scsi/53c700.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c index c59226d7e2f6b5..5117d90ccd9edf 100644 --- a/drivers/scsi/53c700.c +++ b/drivers/scsi/53c700.c @@ -269,18

Use the new non-coherent DMA API including proper ownership transfers. This includes adding additional calls to dma_sync_desc_dev as the old syncing was rather ad-hoc. Thanks to Thomas Bogendoerfer for debugging the ownership transfer issues. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/net/ethernet/seeq/sgiseeq.c | 28 ++++++++++++++++++---------- 1 file changed, 18

This API is the equivalent of alloc_pages, except that the returned memory is guaranteed to be DMA addressable by the passed in device. The implementation will also be used to provide a more sensible replacement for DMA_ATTR_NON_CONSISTENT flag. Additionally dma_alloc_noncoherent is switched over to use dma_alloc_pages as its backend. Signed-off-by: Christoph Hellwig <hch at lst.de> ---

Use the new non-coherent DMA API including proper ownership transfers. This includes adding additional calls to dma_sync_desc_dev as the old syncing was rather ad-hoc. Thanks to Thomas Bogendoerfer for debugging the ownership transfer issues. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/net/ethernet/i825xx/lasi_82596.c | 25 ++--- drivers/net/ethernet/i825xx/lib82596.c

On Thu, Aug 20, 2020 at 12:24:31PM +0200, Tomasz Figa wrote: > > Of course this still uses the scatterlist structure with its annoying > > mix of input and output parametes, so I'd rather not expose it as > > an official API at the DMA layer. > > The problem with the above open coded approach is that it requires > explicit handling of the non-IOMMU and IOMMU cases

Hi Eli, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20200715] url: https://github.com/0day-ci/linux/commits/Eli-Cohen/VDPA-support-for-Mellanox-ConnectX-devices/20200716-155039 base: ca0e494af5edb59002665bf12871e94b4163a257 config: mips-allyesconfig (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build):

OK, some patches in the series add buggy code which is then fixed by follow-up patches, but none of the bugs fixed are severe regressions on common configs (e.g. compiler warnings, lockdep/rt errors, or bugs in new drivers). So I thought it's more important to preserve the credit for the fixes. I had to pull 5 patches from git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux mlx5-next

On Wed, Aug 05, 2020 at 03:40:54PM +0300, Eli Cohen wrote: > On Wed, Aug 05, 2020 at 08:00:55AM -0400, Michael S. Tsirkin wrote: > > On Tue, Aug 04, 2020 at 07:20:36PM +0300, Eli Cohen wrote: > > > Hi Michael, > > > please note that this series depends on mlx5 core device driver patches > > > in mlx5-next branch in > > >

On Tue, Aug 04, 2020 at 07:20:36PM +0300, Eli Cohen wrote: > Hi Michael, > please note that this series depends on mlx5 core device driver patches > in mlx5-next branch in > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git. > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-next > > They also depend Jason Wang's

Hi Eli, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20200715] url: https://github.com/0day-ci/linux/commits/Eli-Cohen/VDPA-support-for-Mellanox-ConnectX-devices/20200716-155039 base: ca0e494af5edb59002665bf12871e94b4163a257 config: i386-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0 reproduce (this is a W=1 build):

On Mon, Nov 02, 2020 at 05:07:59AM +0000, Parav Pandit wrote: > > > > From: Leon Romanovsky <leon at kernel.org> > > Sent: Monday, November 2, 2020 1:46 AM > > > > From: Leon Romanovsky <leonro at nvidia.com> > > > > Remove exposed driver version as it was done in other drivers, so module > > version will work correctly by displaying the

On Tue, Sep 29, 2020 at 09:57:44AM +0300, Eli Cohen wrote: > On Tue, Sep 29, 2020 at 02:51:12AM -0400, Michael S. Tsirkin wrote: > > On Tue, Sep 29, 2020 at 09:34:33AM +0300, Eli Cohen wrote: > > > On Tue, Sep 29, 2020 at 02:26:44AM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Sep 29, 2020 at 09:20:26AM +0300, Eli Cohen wrote: > > > > > On Mon, Sep

On 2020/7/28 ??2:05, Eli Cohen wrote: > Hi Michael, > please note that this series depends on mlx5 core device driver patches > in mlx5-next branch in > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git. > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-next > > They also depend Jason Wang's patches submitted a couple of

On Tue, Jul 28, 2020 at 09:05:29AM +0300, Eli Cohen wrote: > Hi Michael, > please note that this series depends on mlx5 core device driver patches > in mlx5-next branch in > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git. > git pull git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-next > > They also depend Jason Wang's patches