On Tue, Aug 12, 2025 at 6:01 AM Thomas Zimmermann <tzimmerm...@suse.de> 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) <r...@kernel.org> > > 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 <tzimmerm...@suse.de> 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... Rob
