Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
3295 discussions

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

by Leon Romanovsky

On Mon, Jul 28, 2025 at 10:12:31AM -0600, Logan Gunthorpe wrote: > > > On 2025-07-27 13:05, Jason Gunthorpe wrote: > > On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote: > >> > >> > >> On 2025-07-24 02:13, Leon Romanovsky wrote: > >>> On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote: > >>>> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote: > >>>>> From: Leon Romanovsky <leonro(a)nvidia.com> > >>>>> > >>>>> Export the pci_p2pdma_map_type() function to allow external modules > >>>>> and subsystems to determine the appropriate mapping type for P2PDMA > >>>>> transfers between a provider and target device. > >>>> > >>>> External modules have no business doing this. > >>> > >>> VFIO PCI code is built as module. There is no way to access PCI p2p code > >>> without exporting functions in it. > >> > >> The solution that would make more sense to me would be for either > >> dma_iova_try_alloc() or another helper in dma-iommu.c to handle the > >> P2PDMA case. > > > > This has nothing to do with dma-iommu.c, the decisions here still need > > to be made even if dma-iommu.c is not compiled in. > > Doesn't it though? Every single call in patch 10 to the newly exported > PCI functions calls into the the dma-iommu functions. If there were > non-iommu paths then I would expect the code would use the regular DMA > api directly which would then call in to dma-iommu. If p2p type is PCI_P2PDMA_MAP_BUS_ADDR, there will no dma-iommu and DMA at all. +static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, + struct dma_buf_attachment *attachment) +{ + struct vfio_pci_dma_buf *priv = dmabuf->priv; + + if (!attachment->peer2peer) + return -EOPNOTSUPP; + + if (priv->revoked) + return -ENODEV; + + switch (pci_p2pdma_map_type(priv->vdev->provider, attachment->dev)) { + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE: + break; + case PCI_P2PDMA_MAP_BUS_ADDR: + /* + * There is no need in IOVA at all for this flow. + * We rely on attachment->priv == NULL as a marker + * for this mode. + */ + return 0; + default: + return -EINVAL; + } + + attachment->priv = kzalloc(sizeof(struct dma_iova_state), GFP_KERNEL); + if (!attachment->priv) + return -ENOMEM; + + dma_iova_try_alloc(attachment->dev, attachment->priv, 0, priv->phys_vec.len); + return 0; +}

5 months, 4 weeks

[PATCH v3] Documentation: dma-buf: heaps: Add naming guidelines

by Maxime Ripard

We've discussed a number of times of how some heap names are bad, but not really what makes a good heap name. Let's document what we expect the heap names to look like. Reviewed-by: Bagas Sanjaya <bagasdotme(a)gmail.com> Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v3: - Grammar, spelling fixes - Remove the cacheable / uncacheable name suggestion - Link to v2: https://lore.kernel.org/r/20250616-dma-buf-heap-names-doc-v2-1-8ae43174cdbf… Changes in v2: - Added justifications for each requirement / suggestions - Added a mention and example of buffer attributes - Link to v1: https://lore.kernel.org/r/20250520-dma-buf-heap-names-doc-v1-1-ab31f74809ee… --- Documentation/userspace-api/dma-buf-heaps.rst | 35 +++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst index 535f49047ce6450796bf4380c989e109355efc05..3ee4e7961fe390ba356a2125d53b060546c3e4a6 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -21,5 +21,40 @@ following heaps: usually created either through the kernel commandline through the `cma` parameter, a memory region Device-Tree node with the `linux,cma-default` property set, or through the `CMA_SIZE_MBYTES` or `CMA_SIZE_PERCENTAGE` Kconfig options. Depending on the platform, it might be called ``reserved``, ``linux,cma``, or ``default-pool``. + +Naming Convention +================= + +``dma-buf`` heaps name should meet a number of constraints: + +- The name must be stable, and must not change from one version to the other. + Userspace identifies heaps by their name, so if the names ever change, we + would be likely to introduce regressions. + +- The name must describe the memory region the heap will allocate from, and + must uniquely identify it in a given platform. Since userspace applications + use the heap name as the discriminant, it must be able to tell which heap it + wants to use reliably if there's multiple heaps. + +- The name must not mention implementation details, such as the allocator. The + heap driver will change over time, and implementation details when it was + introduced might not be relevant in the future. + +- The name should describe properties of the buffers that would be allocated. + Doing so will make heap identification easier for userspace. Such properties + are: + + - ``contiguous`` for physically contiguous buffers; + + - ``protected`` for encrypted buffers not accessible the OS; + +- The name may describe intended usage. Doing so will make heap identification + easier for userspace applications and users. + +For example, assuming a platform with a reserved memory region located at the +RAM address 0x42000000, intended to allocate video framebuffers, physically +contiguous, and backed by the CMA kernel allocator, good names would be +``memory@42000000-cacheable-contiguous`` or ``video@42000000``, but +``cma-video`` wouldn't. --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250520-dma-buf-heap-names-doc-31261aa0cfe6 Best regards, -- Maxime Ripard <mripard(a)kernel.org>

6 months

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

by Jason Gunthorpe

On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote: > > > On 2025-07-24 02:13, Leon Romanovsky wrote: > > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote: > >> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote: > >>> From: Leon Romanovsky <leonro(a)nvidia.com> > >>> > >>> Export the pci_p2pdma_map_type() function to allow external modules > >>> and subsystems to determine the appropriate mapping type for P2PDMA > >>> transfers between a provider and target device. > >> > >> External modules have no business doing this. > > > > VFIO PCI code is built as module. There is no way to access PCI p2p code > > without exporting functions in it. > > The solution that would make more sense to me would be for either > dma_iova_try_alloc() or another helper in dma-iommu.c to handle the > P2PDMA case. This has nothing to do with dma-iommu.c, the decisions here still need to be made even if dma-iommu.c is not compiled in. It could be exported from the main dma code, but I think it would just be a 1 line wrapper around the existing function? I'd rather rename the functions and leave them in the p2pdma.c files... Jason

6 months

Re: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO regions

by Leon Romanovsky

On Fri, Jul 25, 2025 at 05:34:40AM +0000, Kasireddy, Vivek wrote: > Hi Leon, > > > Subject: Re: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO > > regions > > > > > > > > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > > > > > Add support for exporting PCI device MMIO regions through dma-buf, > > > > enabling safe sharing of non-struct page memory with controlled > > > > lifetime management. This allows RDMA and other subsystems to > > import > > > > dma-buf FDs and build them into memory regions for PCI P2P > > operations. > > > > > > > > The implementation provides a revocable attachment mechanism using > > > > dma-buf move operations. MMIO regions are normally pinned as BARs > > > > don't change physical addresses, but access is revoked when the VFIO > > > > device is closed or a PCI reset is issued. This ensures kernel > > > > self-defense against potentially hostile userspace. > > > > > > > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > > > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> > > > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > > > --- > > > > drivers/vfio/pci/Kconfig | 20 ++ > > > > drivers/vfio/pci/Makefile | 2 + > > > > drivers/vfio/pci/vfio_pci_config.c | 22 +- > > > > drivers/vfio/pci/vfio_pci_core.c | 25 ++- > > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 321 > > +++++++++++++++++++++++++++++ > > > > drivers/vfio/pci/vfio_pci_priv.h | 23 +++ > > > > include/linux/dma-buf.h | 1 + > > > > include/linux/vfio_pci_core.h | 3 + > > > > include/uapi/linux/vfio.h | 19 ++ > > > > 9 files changed, 431 insertions(+), 5 deletions(-) > > > > create mode 100644 drivers/vfio/pci/vfio_pci_dmabuf.c > > > > <...> > > > > > > +static int validate_dmabuf_input(struct vfio_pci_core_device *vdev, > > > > + struct vfio_device_feature_dma_buf > > *dma_buf) > > > > +{ > > > > + struct pci_dev *pdev = vdev->pdev; > > > > + u32 bar = dma_buf->region_index; > > > > + u64 offset = dma_buf->offset; > > > > + u64 len = dma_buf->length; > > > > + resource_size_t bar_size; > > > > + u64 sum; > > > > + > > > > + /* > > > > + * For PCI the region_index is the BAR number like everything else. > > > > + */ > > > > + if (bar >= VFIO_PCI_ROM_REGION_INDEX) > > > > + return -ENODEV; > > > > <...> > > > > > > +/** > > > > + * Upon VFIO_DEVICE_FEATURE_GET create a dma_buf fd for the > > > > + * regions selected. > > > > + * > > > > + * open_flags are the typical flags passed to open(2), eg O_RDWR, > > > > O_CLOEXEC, > > > > + * etc. offset/length specify a slice of the region to create the dmabuf > > from. > > > > + * nr_ranges is the total number of (P2P DMA) ranges that comprise the > > > > dmabuf. > > > Any particular reason why you dropped the option (nr_ranges) of creating > > a > > > single dmabuf from multiple ranges of an MMIO region? > > > > I did it for two reasons. First, I wanted to simplify the code in order > > to speed-up discussion over the patchset itself. Second, I failed to > > find justification for need of multiple ranges, as the number of BARs > > are limited by VFIO_PCI_ROM_REGION_INDEX (6) and same functionality > > can be achieved by multiple calls to DMABUF import. > I don't think the same functionality can be achieved by multiple calls to > dmabuf import. AFAIU, a dmabuf (as of today) is backed by a SGL that can > have multiple entries because it represents a scattered buffer (multiple > non-contiguous entries in System RAM or an MMIO region). I don't know all the reasons why SG was chosen, but one of the main reasons is that DMA SG API was the only one possible way to handle p2p transfers (peer2peer flag). > But in this patch you are constraining it such that only one entry associated with a > buffer would be included, which effectively means that we cannot create > a dmabuf to represent scattered buffers (located in a single MMIO region > such as VRAM or other device memory) anymore. Yes > > > > > > > > > Restricting the dmabuf to a single range (or having to create multiple > > dmabufs > > > to represent multiple regions/ranges associated with a single scattered > > buffer) > > > would be very limiting and may not work in all cases. For instance, in my > > use-case, > > > I am trying to share a large (4k mode) framebuffer (FB) located in GPU's > > VRAM > > > between two (p2p compatible) GPU devices. And, this would probably not > > work > > > given that allocating a large contiguous FB (nr_ranges = 1) in VRAM may > > not be > > > feasible when there is memory pressure. > > > > Can you please help me and point to the place in the code where this can > > fail? > > I'm probably missing something basic as there are no large allocations > > in the current patchset. > Sorry, I was not very clear. What I meant is that it is not prudent to assume that > there will only be one range associated with an MMIO region which we need to > consider while creating a dmabuf. And, I was pointing out my use-case as an > example where vfio-pci needs to create a dmabuf for a large buffer (FB) that > would likely be scattered (and not contiguous) in an MMIO region (such as VRAM). > > Let me further explain with my use-case. Here is a link to my Qemu-based test: > https://gitlab.freedesktop.org/Vivek/qemu/-/commit/b2bdb16d9cfaf55384c95b1f… Ohh, thanks. I'll add nr_ranges in next version. I see that you are using same region_index for all ranges and this is how I would like to keep it: "multiple nr_ranges, same region_index". Thanks

6 months

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

by Leon Romanovsky

On Fri, Jul 25, 2025 at 01:12:35PM -0600, Logan Gunthorpe wrote: > > > On 2025-07-25 12:54, Leon Romanovsky wrote: > >> The solution that would make more sense to me would be for either > >> dma_iova_try_alloc() or another helper in dma-iommu.c to handle the > >> P2PDMA case. dma-iommu.c already uses those same interfaces and thus > >> there would be no need to export the low level helpers from the p2pdma code. > > > > I had same idea in early versions of DMA phys API discussion and it was > > pointed (absolutely right) that this is layering violation. > > Respectfully, I have to disagree with this. Having the layer (ie. > dma-iommu) that normally checks how to handle a P2PDMA request now check > how to handle these DMA requests is the exact opposite of a layering > violation. I'm aware of your implementation and have feeling that it was very influenced by NVMe requirements, so the end result is very tailored for it. Other users have very different paths if p2p is taken. Just see last VFIO patch in this series, it skips all DMA logic. > Expecting every driver that wants to do P2PDMA to have to > figure out for themselves how to map the memory before calling into the > DMA API doesn't seem like a good design choice to me. We had this discussion earlier too on previous versions. The summary is that p2p capable devices are very special anyway. They need to work with p2p natively. BTW, the implementation is not supposed to be in the drivers, but in their respective subsystems. > > > So unfortunately, I think that dma*.c|h is not right place for p2p > > type check. > > dma*.c is already where those checks are done. I'm not sure patches to > remove the code from that layer and put it into the NVMe driver would > make a lot of sense (and then, of course, we'd have to put it into every > other driver that wants to participate in p2p transactions). I don't have plans to remove existing checks right now, but NVMe was already converted to new DMA phys API. Thanks > > Logan > >

6 months

Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function

by Leon Romanovsky

On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote: > > > On 2025-07-24 02:13, Leon Romanovsky wrote: > > On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote: > >> On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote: > >>> From: Leon Romanovsky <leonro(a)nvidia.com> > >>> > >>> Export the pci_p2pdma_map_type() function to allow external modules > >>> and subsystems to determine the appropriate mapping type for P2PDMA > >>> transfers between a provider and target device. > >> > >> External modules have no business doing this. > > > > VFIO PCI code is built as module. There is no way to access PCI p2p code > > without exporting functions in it. > > The solution that would make more sense to me would be for either > dma_iova_try_alloc() or another helper in dma-iommu.c to handle the > P2PDMA case. dma-iommu.c already uses those same interfaces and thus > there would be no need to export the low level helpers from the p2pdma code. I had same idea in early versions of DMA phys API discussion and it was pointed (absolutely right) that this is layering violation. At that time, that remark wasn't such clear to me because HMM code performs check for p2p on every page and has call to dma_iova_try_alloc() before that check. But this VFIO DMABUF code shows it much more clearer. The p2p check is performed before any DMA calls and in case of PCI_P2PDMA_MAP_BUS_ADDR p2p type between DMABUF exporter device and DMABUF importer device, we don't call dma_iova_try_alloc() or any DMA API at all. So unfortunately, I think that dma*.c|h is not right place for p2p type check. Thanks > > Logan >

6 months

Re: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO regions

by Leon Romanovsky

On Thu, Jul 24, 2025 at 05:13:49AM +0000, Kasireddy, Vivek wrote: > Hi Leon, > > > Subject: [PATCH 10/10] vfio/pci: Add dma-buf export support for MMIO > > regions > > > > From: Leon Romanovsky <leonro(a)nvidia.com> > > > > Add support for exporting PCI device MMIO regions through dma-buf, > > enabling safe sharing of non-struct page memory with controlled > > lifetime management. This allows RDMA and other subsystems to import > > dma-buf FDs and build them into memory regions for PCI P2P operations. > > > > The implementation provides a revocable attachment mechanism using > > dma-buf move operations. MMIO regions are normally pinned as BARs > > don't change physical addresses, but access is revoked when the VFIO > > device is closed or a PCI reset is issued. This ensures kernel > > self-defense against potentially hostile userspace. > > > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy(a)intel.com> > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > --- > > drivers/vfio/pci/Kconfig | 20 ++ > > drivers/vfio/pci/Makefile | 2 + > > drivers/vfio/pci/vfio_pci_config.c | 22 +- > > drivers/vfio/pci/vfio_pci_core.c | 25 ++- > > drivers/vfio/pci/vfio_pci_dmabuf.c | 321 +++++++++++++++++++++++++++++ > > drivers/vfio/pci/vfio_pci_priv.h | 23 +++ > > include/linux/dma-buf.h | 1 + > > include/linux/vfio_pci_core.h | 3 + > > include/uapi/linux/vfio.h | 19 ++ > > 9 files changed, 431 insertions(+), 5 deletions(-) > > create mode 100644 drivers/vfio/pci/vfio_pci_dmabuf.c <...> > > +static int validate_dmabuf_input(struct vfio_pci_core_device *vdev, > > + struct vfio_device_feature_dma_buf *dma_buf) > > +{ > > + struct pci_dev *pdev = vdev->pdev; > > + u32 bar = dma_buf->region_index; > > + u64 offset = dma_buf->offset; > > + u64 len = dma_buf->length; > > + resource_size_t bar_size; > > + u64 sum; > > + > > + /* > > + * For PCI the region_index is the BAR number like everything else. > > + */ > > + if (bar >= VFIO_PCI_ROM_REGION_INDEX) > > + return -ENODEV; <...> > > +/** > > + * Upon VFIO_DEVICE_FEATURE_GET create a dma_buf fd for the > > + * regions selected. > > + * > > + * open_flags are the typical flags passed to open(2), eg O_RDWR, > > O_CLOEXEC, > > + * etc. offset/length specify a slice of the region to create the dmabuf from. > > + * nr_ranges is the total number of (P2P DMA) ranges that comprise the > > dmabuf. > Any particular reason why you dropped the option (nr_ranges) of creating a > single dmabuf from multiple ranges of an MMIO region? I did it for two reasons. First, I wanted to simplify the code in order to speed-up discussion over the patchset itself. Second, I failed to find justification for need of multiple ranges, as the number of BARs are limited by VFIO_PCI_ROM_REGION_INDEX (6) and same functionality can be achieved by multiple calls to DMABUF import. > > Restricting the dmabuf to a single range (or having to create multiple dmabufs > to represent multiple regions/ranges associated with a single scattered buffer) > would be very limiting and may not work in all cases. For instance, in my use-case, > I am trying to share a large (4k mode) framebuffer (FB) located in GPU's VRAM > between two (p2p compatible) GPU devices. And, this would probably not work > given that allocating a large contiguous FB (nr_ranges = 1) in VRAM may not be > feasible when there is memory pressure. Can you please help me and point to the place in the code where this can fail? I'm probably missing something basic as there are no large allocations in the current patchset. > > Furthermore, since you are adding a new UAPI with this patch/feature, as you know, > we cannot go back and tweak it (to add support for nr_ranges > 1) should there > be a need in the future, but you can always use nr_ranges = 1 anytime. Therefore, > I think it makes sense to be flexible in terms of the number of ranges to include > while creating a dmabuf instead of restricting ourselves to one range. I'm not a big fan of over-engineering. Let's first understand if this case is needed. Thanks > > Thanks, > Vivek > > > + * > > + * Return: The fd number on success, -1 and errno is set on failure. > > + */ > > +#define VFIO_DEVICE_FEATURE_DMA_BUF 11 > > + > > +struct vfio_device_feature_dma_buf { > > + __u32 region_index; > > + __u32 open_flags; > > + __u64 offset; > > + __u64 length; > > +}; > > + > > /* -------- API for Type1 VFIO IOMMU -------- */ > > > > /** > > -- > > 2.50.1 >

6 months

Re: [PATCH v6 2/2] i2c: i2c-qcom-geni: Add Block event interrupt support

by Vinod Koul

On 22-07-25, 15:46, Dmitry Baryshkov wrote: > On Tue, Jul 22, 2025 at 05:50:08PM +0530, Jyothi Kumar Seerapu wrote: > > On 7/19/2025 3:27 PM, Dmitry Baryshkov wrote: > > > On Mon, Jul 07, 2025 at 09:58:30PM +0530, Jyothi Kumar Seerapu wrote: > > > > On 7/4/2025 1:11 AM, Dmitry Baryshkov wrote: > > > > > On Thu, 3 Jul 2025 at 15:51, Jyothi Kumar Seerapu [Folks, would be nice to trim replies] > > > > Could you please confirm if can go with the similar approach of unmap the > > > > processed TREs based on a fixed threshold or constant value, instead of > > > > unmapping them all at once? > > > > > > I'd still say, that's a bad idea. Please stay within the boundaries of > > > the DMA API. > > > > > I agree with the approach you suggested—it's the GPI's responsibility to > > manage the available TREs. > > > > However, I'm curious whether can we set a dynamic watermark value perhaps > > half the available TREs) to trigger unmapping of processed TREs ? This would > > allow the software to prepare the next set of TREs while the hardware > > continues processing the remaining ones, enabling better parallelism and > > throughput. > > Let's land the simple implementation first, which can then be improved. > However I don't see any way to return 'above the watermark' from the DMA > controller. You might need to enhance the API. Traditionally, we set the dma transfers for watermark level and we get a interrupt. So you might want to set the callback for watermark level and then do mapping/unmapping etc in the callback. This is typical model for dmaengines, we should follow that well BR -- ~Vinod

6 months

[PATCH RFC 0/2] accel: Add Arm Ethos-U NPU

by Rob Herring (Arm)

The Arm Ethos-U65/85 NPUs are designed for edge AI inference applications[0]. The driver works with Mesa Teflon. WIP support is available here[1]. The UAPI should also be compatible with the downstream driver stack[2] and Vela compiler though that has not been implemented. Testing so far has been on i.MX93 boards with Ethos-U65. Support for U85 is still todo. Only minor changes on driver side will be needed for U85 support. A git tree is here[3]. Rob [0] https://www.arm.com/products/silicon-ip-cpu?families=ethos%20npus [1] https://gitlab.freedesktop.org/tomeu/mesa.git ethos [2] https://gitlab.arm.com/artificial-intelligence/ethos-u/ [3] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ethos Signed-off-by: Rob Herring (Arm) <robh(a)kernel.org> --- Rob Herring (Arm) (2): dt-bindings: npu: Add Arm Ethos-U65/U85 accel: Add Arm Ethos-U NPU driver .../devicetree/bindings/npu/arm,ethos.yaml | 79 +++ MAINTAINERS | 9 + drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 1 + drivers/accel/ethos/Kconfig | 10 + drivers/accel/ethos/Makefile | 4 + drivers/accel/ethos/ethos_device.h | 186 ++++++ drivers/accel/ethos/ethos_drv.c | 412 ++++++++++++ drivers/accel/ethos/ethos_drv.h | 15 + drivers/accel/ethos/ethos_gem.c | 707 +++++++++++++++++++++ drivers/accel/ethos/ethos_gem.h | 46 ++ drivers/accel/ethos/ethos_job.c | 527 +++++++++++++++ drivers/accel/ethos/ethos_job.h | 41 ++ include/uapi/drm/ethos_accel.h | 262 ++++++++ 14 files changed, 2300 insertions(+) --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250715-ethos-3fdd39ef6f19 Best regards, -- Rob Herring (Arm) <robh(a)kernel.org>

6 months

Re: [PATCH v9 00/10] New DRM accel driver for Rockchip's RKNN NPU

by Heiko Stübner

Hi Jeff, Am Montag, 21. Juli 2025, 16:55:01 Mitteleuropäische Sommerzeit schrieb Jeff Hugo: > On 7/21/2025 3:17 AM, Tomeu Vizoso wrote: > > This series adds a new driver for the NPU that Rockchip includes in its > > newer SoCs, developed by them on the NVDLA base. > > > > In its current form, it supports the specific NPU in the RK3588 SoC. > > > > The userspace driver is part of Mesa and an initial draft can be found at: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29698 > > > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > > This (and the userspace component) appear ready for merge from what I > can tell. Tomeu is still working on his drm-misc access so I've offered > to merge on his behalf. Planning on waiting until Friday for any final > feedback to come in before doing so. sounds great. Just to make sure, you're planning to merge patches 1-6 (driver + binding) into drm-misc and I'll pick up the "arm64: dts: " patches 7-10 afterwards? Heiko

6 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig