Messages in this thread | | | Date | Wed, 22 Nov 2023 17:22:47 +0200 | Subject | Re: [PATCH 0/4] Add APIs to request TX/RX DMA channels by ID | From | Péter Ujfalusi <> |
| |
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
| |