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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fad47e3-c1e7-4f37-8341-402d2756ea20@suse.de>
Date: Tue, 12 Aug 2025 15:18:45 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Rob Herring <robh@...nel.org>
Cc: Tomeu Vizoso <tomeu@...euvizoso.net>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Oded Gabbay <ogabbay@...nel.org>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Sumit Semwal <sumit.semwal@...aro.org>,
 Christian König <christian.koenig@....com>,
 Robin Murphy <robin.murphy@....com>, Steven Price <steven.price@....com>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-media@...r.kernel.org,
 linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v2 2/2] accel: Add Arm Ethos-U NPU driver

Hi

Am 12.08.25 um 14:56 schrieb Rob Herring:
> On Tue, Aug 12, 2025 at 6:01 AM Thomas Zimmermann <tzimmermann@...e.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) <robh@...nel.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 <tzimmermann@...e.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...

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)