Re: [RFC PATCH v1 8/8] misc/arm-cla: Add userspace interface

[Arnd Bergmann]

On Fri, Jul 17, 2026, at 18:21, Ryan Roberts wrote:
> On 17/07/2026 16:31, Arnd Bergmann wrote:
>> 
>> Without concrete implementation examples, I find it hard to imagine
>> how granular the CLA and accelerator blocks are. What I'm interested
>> in is separating things into special character devices when they
>> refer to units that you want to manage separately in userspace.
>> 
>> If you have e.g. one accelerator for tensor operations and one for
>> handling gzip, I would very much want to see those have a separate
>> chardev nodes so a local administrator can give permissions to each
>> one separately, and have device names that are sensible to the
>> functionality underneath.
>
> Unfortunately this doesn't map well to the HW: the MMIO is for the
> CLA interface (each CPU has 1 CLA).

I'm sure you mentioned it in the documentation, but I missed that
there are never multiple CLA instances.

If the CLA is defined only in terms of its MMIO/DMA interface
and listening to TLB broadcast operations, is having a single
instance actually required by the design, or just an implementation
choice?

> Once you have access to that interface, you can
> communicate with all of the accelerators that are connected to the CLA. We could
> potentially use the availability masking control to only expose a single
> accelerator for a given context (which would be chosen based on which file you
> opened), but it wouldn't be possible for (e.g.) 2 different processes to access
> the different accelerators concurrently - they would have to be subject to the
> time slice model.

Right, that sounds a bit awkward. It sounds like this would also get
simpler with a model that ensures the current CLA ttbr0 matches the
CPU ttbr0 and the iotlb_mm setting, since you would never have concurrent
uses of a single CLA from multipel tasks. On the other hand, that
model would make it harder to use multiple accelerators from a
single task, if they have to go through multiple file descriptors
but could be accessed on a single mapping.

>> If you have separate accelerators for AES encryption and decryption,
>> or a large set of identical accelerators that can run concurrently,
>> those would of course get managed as a single device file.
>> 
>> Most importantly, I don't think a global /dev/cla device node
>> is a sensible interface from a management perspective as that
>> would give unprivileged userspace direct control to something
>> that is essentially arbitrary (or buggy) vendor firmware
>> with DMA permissions.
>
> OK I see your point.
>
> While the interface supports up to 8 connected accelerators, we anticpate there
> only being a single compute accelerator in practice. We decided to keep the
> driver interface generic given the CLA spec, but perhaps it would be more
> straightforward to limit the driver implementation to only permitting a single
> accelerator?

Probably, yes. From a kernel perspective, I think we're a bit better
off with an abstraction like

- One CLA MMIO range per /type/ of accelerator on a given CPU
- One firmware node per CLA, possibly spanning multiple CPUs
  if the accelerators behind them are shared.
- One character device per firmware node, named according to the
  type of CLA
- Possibly multiple CLA nodes on a given CPU if multiple
  unrelated accelerators are present
- optionally multiple related accelerators on the eight ports of
  a CLA, if that makes sense for that device type

Not sure how far that is off from what you currently have in
the hardware design.

       Arnd