Received-SPF: pass (google.com: domain of linux-kernel+bounces-150544-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 18 Apr 2024 22:38:21 +0530
From: Vinod Koul <vkoul@kernel.org>
To: Lizhi Hou <lizhi.hou@amd.com>
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
Subject: Re: [PATCH V10 1/1] dmaengine: amd: qdma: Add AMD QDMA driver
Message-ID: <ZiFTheOik-2jsfXP@matsya>
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>
 <14402251-5731-1e52-e787-734d3eb3c801@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <14402251-5731-1e52-e787-734d3eb3c801@amd.com>

On 17-04-24, 10:53, Lizhi Hou wrote:
> 
> 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

That would be the right thing to do...

- set parameters and call dmaengine_slave_config()
- prep transfer for vd1 dmaengine_prep_slave_sg()
- set parameters and call dmaengine_slave_config()
- prep transfer for vd2 dmaengine_prep_slave_sg()
- submit vd1
- submit vd2
- issue_pending
        - you see you can issue both as you have space, so do that

This should be done always to maximize the dmaengine thoroughput

> 
> dmaengine_prep_slave_sg() with a lock protection. Is this what you would
> recommend?
> 
> 
> Thanks,
> 
> Lizhi

-- 
~Vinod