Re: [RFC PATCH v1 1/8] misc/arm-cla: Add driver skeleton and documentation

[Arnd Bergmann]

On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
> From: Jean-Philippe Brucker <jpb@xxxxxxxxxx>
>
> Add the initial Kconfig and build-system plumbing for the Arm Core Local
> Accelerator driver.
>
> Introduce the common driver header and register definitions used by
> later CLA support. The definitions cover the CLA MMIO frame, launch
> response and status fields, standard accelerator registers, launch
> opcodes, error codes and memory translation context state.
>
> Add documentation describing the CLA programming model, its CPU-local
> MMIO access rules, userspace assignment model, domain grouping and
> expected boot state.

I have a few more questions here. Most of the description and
the design decisions make perfect sense to me, but there are
a few things I don't understand from your current document.

> +The CLA supports up to 8 attached accelerators, which are accessed by
> +programming the CLA's MMIO registers. Operations are launched to an 
> accelerator
> +and are polled for completion. CLA does not raise interrupts.
> +
> +            CPU                     CLA              Accel
> +             |--- write DATA[7:0] -->|                 |
> +             |--- write LAUNCH ----->|---- launch ---->|
> +             |<--- poll LRESP -------|                 |
> +             |                       |                 |
> +             |<--- poll STATUS ------|<--- complete ---|
> +
> +Each operation can take a 512-bit payload in the DATA registers. After handling
> +a LAUNCH write, CLA indicates the launch status in the LRESP register. A further
> +operation can only be launched after LRESP indicates completion of the previous
> +launch.

This sounds a lot like st64bv or st64bv0, passing an 8-word payload and returning
a single word per accelerator operation with shared addressing.

Why are there now two interfaces to do the same thing?

Can a user process use st64bv to do the four steps in a
single instruction?

> +Some operations continue to run asynchronously on the accelerator after launch
> +completion. In this case progress is tracked by polling the STATUS register.
> +When the CLA updates the STATUS register, it also raises an event which will
> +wake an in-progress WFE (wait for event) instruction on the local CPU.

The asynchronous interface seems very confusing.

How are page faults from the SVA master resolved during an
asynchronous operation?

Can a CPU start multiple asynchronous operations concurrently?

Do these continue to run if the starting process is scheduled out
and another process also tries to use CLA?

> +Faults during address translation are reported by the accelerator in its
> +registers and in STATUS. While polling for work completion, software fixes up
> +the faults and notifies the accelerator with RESOLVE operations.

I would like to understand the faulting part better. Which instruction
specifically causes the fault, is that the poll STATUS read?

> +Inter-Accelerator Communication
> +-------------------------------
> +
> +On some platforms, multiple accelerators, each attached to a separate CLA within
> +a cluster, are also directly connected to each other via a shared bus to
> +accelerate cooperation between accelerators. The accelerators sharing a bus
> +cannot be isolated from each other. When collaborative operations are launched
> +on each of the participating accelerators, they synchronize over the bus,
> +stalling until all are ready.

Could you give an example what this model might be good for?

Does this mean a user may have to start one operation on each CPU
from a thread of the same process in order to get a result efficiently
across a shared accelerator?

I assume this will become clearer once you can show an example userspace
application that uses this type of accelerator.

> +Intended SW Usage Model
> +=======================
> +
> +CLA is designed for its PL0 MMIO frame to be mapped into user space  and for user
> +space to directly launch accelerator operations and poll for completion. It has
> +been observed that for some use cases, the operation execution time is small and
> +a trip through the kernel would consume a significant amount of the CPU budget
> +for preparing the next operation leading to a significant reduction in bandwidth
> +through the accelerator.

Do you have any plans for in-kernel usage of the accelerators?
I would assume that for things like cryptographic features, these
make sense to be exposed to the kernel itself.

> +User space software is expected to create a thread to drive each CLA it is
> +using, and for each thread to be pinned to the CLA's local CPU.

What happens if multiple processes have the same chardev open and
each mmap() that, e.g. after a fork()? Does each process see its
own virtual instance of the accelerator and interact with it through
the same physical MMIO register range but its own process address space,
or do you have to rely on the registers being mapped only into a
single mm_struct to prevent a process from messing with another process
data?

> +Saving and restoring the internal state of the accelerator is an optional
> +feature. Current platforms only support it when the accelerator is idle, so
> +preempting an accelerator causes work cancellation. Software must carefully
> +consider how to balance forward-progress guarantees with preemption 
> latency.

I'm not sure I understand this point. Do you mean any async operation
that was started on an accelerator may fail due to preemption, so user
space must be able to restart it?

     Arnd