If there are no concerns, may I post the v2 of this series, rebasing it on the latest linux-next tree with minor code cleanup and reordering of the patches? On 04/12/23 13:51, Siddharth Vadapalli wrote: > Hello Péter, > > On 22/11/23 20:52, Péter Ujfalusi wrote: >> 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? > > I apologize for the delayed response. Yes, the CPSW instance which shall be in > control of Firmware running on the remote core will not have a DT entry. The > Linux Client driver shall be probed when the Firmware announces its endpoint > over the RPMsg bus, which the Client driver shall register with the RPMsg framework. > >> >>> 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? > > After getting probed, the Client driver communicates with Firmware via RPMsg, > requesting details of the allocated resources including the TX Channels and RX > Flows. Knowing these parameters, the Client driver can use the newly added DMA > APIs to request TX Channel and RX Flows by IDs. The only dependency here is that > the Client driver needs to know which DMA instance to request these resources > from. That information is hard coded in the driver's data in the form of the > compatible used for the DMA instance, thereby allowing the Client driver to get > a reference to the DMA controller node using the of_find_compatible_node() API. > > Since all the resource allocation information comes from Firmware, the > device-specific details will be hard coded in the Firmware while the Client > driver can be used across all K3 SoCs which have the same DMA APIs. > >> >> 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? > > Yes, it is not yet supported in mainline. This series is a dependency for > upstreaming the Client driver. > -- Regards, Siddharth.
