Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Message-ID: <08e04ee2-b6e7-4da6-87f4-6d111dc25286@ti.com>
Date:   Mon, 11 Dec 2023 14:30:21 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
CC:     <vkoul@kernel.org>, <dmaengine@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <srk@ti.com>,
        <vigneshr@ti.com>, <s-vadapalli@ti.com>
Subject: Re: [PATCH 0/4] Add APIs to request TX/RX DMA channels by ID
Content-Language: en-US
To:     =?UTF-8?Q?P=C3=A9ter_Ujfalusi?= <peter.ujfalusi@gmail.com>
References: <20231114083906.3143548-1-s-vadapalli@ti.com>
 <9d465de4-3930-4856-9d8e-7deb567a628f@gmail.com>
 <c693efec-ab67-44bb-8871-a40dc408f278@ti.com>
 <ed1d0221-d0ee-4a7d-8955-d5973027d113@gmail.com>
 <a4ca48fb-2e87-494a-bc71-8970d7f8c6a0@ti.com>
From:   Siddharth Vadapalli <s-vadapalli@ti.com>
In-Reply-To: <a4ca48fb-2e87-494a-bc71-8970d7f8c6a0@ti.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.