Re: [PATCH RFC v3 5/9] spi: dt-bindings: axi-spi-engine: document spi-offloads

[Rob Herring <robh@kernel.org>]

On Mon, Jul 22, 2024 at 04:57:12PM -0500, David Lechner wrote:
> The AXI SPI Engine has support for hardware offloading capabilities.
> There can be up to 32 offload instances per SPI controller, so the
> bindings limit the value accordingly.
> 
> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
> 
> RFC: I have a few questions about this one...
> 
> 1.  The trigger-source properties are borrowed from the leds bindings.
>     Do we want to promote this to a generic binding that can be used by
>     any type of device?

I would make it specific to spi-offload.

> 
> 2.  Some folks are working on adding DMA to TX stream support to the
>     AXI SPI Engine hardware. I assume that the `dmas` property is like
>     others where the order/index in the phandle array matters. So this
>     would mean that for device that only uses 1 out of the 32 offloads
>     and only uses 1 TX DMA channel, we would have to have 32 <0>s for
>     each of the possible RX dmas in the array. Any way to do some kind
>     of mapping to avoid this?

That's why -names exists.

> 
> 3.  In v2, we discussed about having some sort of data processing unit
>     between the AXI SPI Engine RX stream interface and the DMA channel
>     interface on the DMA controller. I haven't included this in the
>     bindings yet because we don't have a user yet. But it was suggested
>     that we could use the graph bindings for this. So here is what that
>     might look like:
> 
>     Additional property for the AXI SPI Engine controller bindings:
> 
>         out-ports:
>             $ref: /schemas/graph.yaml#/properties/ports
>             unevaluatedProperties: false
>             patternProperties:
>             "^port@1?[0-9a-f]$":
>                 $ref: /schemas/graph.yaml#/properties/port
>                 unevaluatedProperties: false
> 
>     And this would be connected to a device node similar to this:
> 
>         ip-block@3000 {
>             // Something similar to, but not exactly like
>             // http://analogdevicesinc.github.io/hdl/library/util_extract/index.html
>             compatible = "adi,crc-check";
>             // clock that runs this IP block
>             clocks = <&sysclk 15>;
>             // interrupt raised on bad CRC
>             interrupts = <&intc 99>;
>             interrupt-names = "crc";
>             // output stream with CRC byte removed piped to DMA
>             dmas = <&adc_dma 0>;
>             dma-names = "rx";
> 
>             port {
>                 adc_crc_check: endpoint {
>                     remote-endpoint: <&offload0_rx>;
>                 };
>             };
>         };
> 
>     Does this sound reasonable?

Shrug.

Unlike the offload which is internal to the controller driver?, isn't 
this specific to the device because it needs to be aware of any 
processing done or not done. Or maybe it wants to configure the 
processing.

OTOH, maybe this isn't any different than offload?

Rob