Re: [PATCH v2 2/2] accel: Add Arm Ethos-U NPU driver

[Thomas Zimmermann]

Hi

Am 12.08.25 um 14:56 schrieb Rob Herring:
> On Tue, Aug 12, 2025 at 6:01 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> > Hi
> >
> > Am 11.08.25 um 23:05 schrieb Rob Herring (Arm):
> > > Add a driver for Arm Ethos-U65/U85 NPUs. The Ethos-U NPU has a
> > > relatively simple interface with single command stream to describe
> > > buffers, operation settings, and network operations. It supports up to 8
> > > memory regions (though no h/w bounds on a region). The Ethos NPUs
> > > are designed to use an SRAM for scratch memory. Region 2 is reserved
> > > for SRAM (like the downstream driver stack and compiler). Userspace
> > > doesn't need access to the SRAM.
> > >
> > > The h/w has no MMU nor external IOMMU and is a DMA engine which can
> > > read and write anywhere in memory without h/w bounds checks. The user
> > > submitted command streams must be validated against the bounds of the
> > > GEM BOs. This is similar to the VC4 design which validates shaders.
> > >
> > > The job submit is based on the rocket driver for the Rockchip NPU
> > > utilizing the GPU scheduler. It is simpler as there's only 1 core rather
> > > than 3.
> > >
> > > Tested on i.MX93 platform (U65) with WIP Mesa Teflon support.
> > >
> > > Signed-off-by: Rob Herring (Arm) <robh@xxxxxxxxxx>
> > I've looked over this patch and it looks good to me. There's a
> > dev_info() in ethos_init() of which I think it should become drm_dbg().
> > Anyway
> I prefer to print out what h/w we've discovered. That's a fairly
> common pattern for drivers (and more useful than announcing drivers
> that only loaded).
>
> > Acked-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
> Thanks!
>
> > Side note: I noticed that there's buffer-allocation code here that
> > reinvents dumb buffers. We've ocationally talked about creating a better
> > dumb-buffers ioctl interface and this drivers could be another use case.
> Yeah. In the past I got told don't use dumb buffers APIs for anything
> but dumb scanout buffers. I guess with enough copies opinions
> change...

That advice wasn't wrong. But the current dumb-buffer ioctls don't 
support scanout buffers well either. If we build something new, we can 
try to cover additional use cases as well.

Best regards
Thomas

> Rob

--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)