On 7/26/24 7:38 AM, Rob Herring wrote:
> 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@xxxxxxxxxxxx>
>> ---
>>
>> 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.
OK
Meanwhile, we are working on some other ADCs (without SPI offload) and
finding that they are using basically the same sorts of triggers. And
on the driver side of things in this series, I'm getting feedback that
we should have some sort of generic trigger device rather than using,
e.g. a clk directly. If we need this same sort of trigger abstraction
for both SPI offloads and IIO device, it does seems like we might want
to consider something like a new trigger subsystem.
>
>>
>> 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.
OK
>
>>
>> 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?
Correct. And in the case of the AXI SPI Engine, the offload is
part of the controller IP block in hardware as well.
> 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.
Yes, the SPI peripheral driver would be the one needing to know
what sort of data processing unit it is connected to so it knows
how to configure the chip and how to interpret the received data
or other signals from the data processing unit.
>
> OTOH, maybe this isn't any different than offload?
Also true since the SPI peripheral needs to know what kind of
capabilities that the offload itself has.
>
> Rob
