Re: [PATCH 0/4] Add APIs to request TX/RX DMA channels by ID

["Péter Ujfalusi" <peter.ujfalusi@gmail.com>]

Hi Siddharth,

On 17/11/2023 07:55, Siddharth Vadapalli wrote:
>> I would really like to follow a standard binding since what will happen
>> if the firmware will start to provision channels/flows for DMAengine
>> users? It is not that simple to hack that around.
> 
> Please consider the following use-case for which the APIs are being added by
> this series. I apologize for not explaining the idea behind the APIs in more
> detail earlier.
> 
> Firmware running on a remote core is in control of a peripheral (CPSW Ethernet
> Switch for example) and shares the peripheral across software running on
> different cores. The control path between the Firmware and the Clients on
> various cores is via RPMsg, while the data path used by the Clients is the DMA
> Channels. In the example where Clients send data to the shared peripheral over
> DMA, the Clients send RPMsg based requests to the Firmware to obtain the
> allocated thead IDs. Firmware allocates the thread IDs by making a request to
> TISCI Resource Manager followed by sharing the thread IDs to the Clients.
> 
> In such use cases, the Linux Client is probed by RPMsg endpoint discovery over
> the RPMsg bus. Therefore, there is no device-tree corresponding to the Client
> device. The Client knows the DMA Channel IDs as well as the RX Flow details from
> the Firmware. Knowing these details, the Client can request the configuration of
> the TX and RX Channels/Flows by using the DMA APIs which this series adds.

I see, so the CPSW will be probed in a similar way as USB peripherals
for example? The CPSW does not have a DT entry at all? Is this correct?

> Please let me know in case of any suggestions for an implementation which shall
> address the above use-case.

How does the driver knows how to request a DMA resource from the remote
core? How that scales with different SoCs and even with changes in the
firmware?

You are right, this is in a grey area. The DMA channel as it is
controlled by the remote processor, it lends a thread to clients on
other cores (like Linux) via RPMsg.
Well, it is similar to how non DT is working in a way.

This CPSW type is not yet supported mainline, right?

-- 
Péter