Received-SPF: pass (google.com: domain of linux-kernel+bounces-149017-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB03.amd.com; pr=C
Message-ID: <14402251-5731-1e52-e787-734d3eb3c801@amd.com>
Date: Wed, 17 Apr 2024 10:53:05 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH V10 1/1] dmaengine: amd: qdma: Add AMD QDMA driver
Content-Language: en-US
To: Vinod Koul <vkoul@kernel.org>
CC: <dmaengine@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Nishad Saraf
	<nishads@amd.com>, <nishad.saraf@amd.com>, <sonal.santan@amd.com>,
	<max.zhen@amd.com>
References: <1709675352-19564-1-git-send-email-lizhi.hou@amd.com>
 <1709675352-19564-2-git-send-email-lizhi.hou@amd.com>
 <ZhKd7CHXHB7FadY0@matsya> <aa6a63c0-7cce-1f49-4ae5-3e5d93f98fe5@amd.com>
 <ZiAA3C4wXaAHcJ1E@matsya>
From: Lizhi Hou <lizhi.hou@amd.com>
In-Reply-To: <ZiAA3C4wXaAHcJ1E@matsya>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: None (SATLEXMB03.amd.com: lizhi.hou@amd.com does not designate
 permitted sender hosts)
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2024 17:53:07.2753
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 825d2b68-81b3-44e4-35e8-08dc5f073d13
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB03.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	DS2PEPF0000343C.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8484


On 4/17/24 10:03, Vinod Koul wrote:
> On 08-04-24, 11:06, Lizhi Hou wrote:
>
>>>> +static void *qdma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
>>>> +				   size_t *payload_len, size_t *max_len)
>>>> +{
>>>> +	struct qdma_mm_vdesc *vdesc;
>>>> +
>>>> +	vdesc = container_of(tx, typeof(*vdesc), vdesc.tx);
>>>> +	if (payload_len)
>>>> +		*payload_len = sizeof(vdesc->dev_addr);
>>>> +	if (max_len)
>>>> +		*max_len = sizeof(vdesc->dev_addr);
>>>> +
>>>> +	return &vdesc->dev_addr;
>>> Can you describe what metadata is being used here for?
>> The metadata is the device address the dma request will transfer
>>
>> data to / from.  Please see the example usage here:
>>
>> https://github.com/houlz0507/XRT-1/blob/qdma_v1_usage/src/runtime_src/core/pcie/driver/linux/xocl/subdev/qdma.c#L311
>>
>> Before dmaengine_submit(), it specifies the device address.
> Hmmm, why is the vaddr passed like this, why not use slave_config for
> this
>
This is because the hardware is capable to process multiple vdesc at one 
kick off.

For example, there are two pending vdesc: vd1 and vd2. If there is 
enough free

space in hardware queue, the vd1 and vd2 can be put in queue, and do one 
kick off

to transfer both vd1 and vd2.

The destination device address of vd1 and vd2 could be any valid device 
address.

desc_metadata_ptr seems helpful for the per vdesc destination device 
address.


If using slave_config, it needs to call dmaengine_slave_config() and

dmaengine_prep_slave_sg() with a lock protection. Is this what you would 
recommend?


Thanks,

Lizhi