public inbox for dmaengine@vger.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Kelvin.Cao@microchip.com
Cc: dmaengine@vger.kernel.org, George.Ge@microchip.com,
	christophe.jaillet@wanadoo.fr, hch@infradead.org,
	linux-kernel@vger.kernel.org, logang@deltatee.com
Subject: Re: [PATCH v6 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver
Date: Fri, 6 Oct 2023 16:00:14 +0530	[thread overview]
Message-ID: <ZR/htuZSKGJP1wgU@matsya> (raw)
In-Reply-To: <b0dc3da623dee479386e7cb75841b8b7913c9890.camel@microchip.com>

On 05-10-23, 18:35, Kelvin.Cao@microchip.com wrote:

> > > > +static struct dma_async_tx_descriptor *
> > > > +switchtec_dma_prep_wimm_data(struct dma_chan *c, dma_addr_t
> > > > dma_dst, u64 data,
> > > > +                          unsigned long flags)
> > > 
> > > can you please explain what this wimm data refers to...
> > > 
> > > I think adding imm callback was a mistake, we need a better
> > > justification for another user for this, who programs this, what
> > > gets
> > > programmed here
> > 
> > Sure. I think it's an alternative method to prep_mem and would be
> > more
> > convenient to use when the write is 8-byte and the data to be moved
> > is
> > not in a DMA mapped memory location. For example, we write to a
> > doorbell register with the value from a local variable which is not
> > associated with a DMA address to notify the receiver to consume the
> > data, after confirming that the previously initiated DMA transactions
> > of the data have completed. I agree that the use scenario would be
> > very
> > limited.

Can you please explain more about this 'value' where is it derived from?
Who programs it and how...

> > > > +     /* set sq/cq */
> > > > +     writel(lower_32_bits(swdma_chan->dma_addr_sq), &chan_fw-
> > > > > sq_base_lo);
> > > > +     writel(upper_32_bits(swdma_chan->dma_addr_sq), &chan_fw-
> > > > > sq_base_hi);
> > > > +     writel(lower_32_bits(swdma_chan->dma_addr_cq), &chan_fw-
> > > > > cq_base_lo);
> > > > +     writel(upper_32_bits(swdma_chan->dma_addr_cq), &chan_fw-
> > > > > cq_base_hi);
> > > > +
> > > > +     writew(SWITCHTEC_DMA_SQ_SIZE, &swdma_chan->mmio_chan_fw-
> > > > > sq_size);
> > > > +     writew(SWITCHTEC_DMA_CQ_SIZE, &swdma_chan->mmio_chan_fw-
> > > > > cq_size);
> > > 
> > > what is write happening in the descriptor alloc callback, that does
> > > not
> > > sound correct to me
> > 
> > All the queue descriptors of a channel are pre-allocated, so I think
> > it's proper to convey the queue address/size to hardware at this
> > point.
> > After this initialization, we only need to assign cookie in submit
> > and
> > update queue head to hardware in issue_pending.

Sorry that is not right, you can prepare multiple descriptors and then
submit. Only at submit is the cookie assigned which is in order, so this
should be moved to when we start the txn and not in this call

-- 
~Vinod

  reply	other threads:[~2023-10-06 10:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28 20:03 [PATCH v6 0/1] Switchtec Switch DMA Engine Driver Kelvin Cao
2023-07-28 20:03 ` [PATCH v6 1/1] dmaengine: switchtec-dma: Introduce Switchtec DMA engine PCI driver Kelvin Cao
2023-07-31  7:08   ` Christoph Hellwig
2023-07-31 23:07     ` Kelvin.Cao
2023-08-01 18:42   ` Vinod Koul
2023-08-03  3:15     ` Kelvin.Cao
2023-08-21 23:44       ` Kelvin.Cao
2023-10-05 18:35       ` Kelvin.Cao
2023-10-06 10:30         ` Vinod Koul [this message]
2023-10-06 22:34           ` Kelvin.Cao
2023-10-09  5:38             ` Vinod Koul
2023-10-10 21:23               ` Kelvin.Cao
2023-10-11 11:48                 ` Vinod Koul
2023-10-11 16:36                   ` Kelvin.Cao
2023-10-23 17:14                     ` Kelvin.Cao
2023-12-12 17:53                       ` Kelvin.Cao
2023-12-21 16:17                         ` Vinod Koul
2023-07-31 15:49 ` [PATCH v6 0/1] Switchtec Switch DMA Engine Driver Logan Gunthorpe
2023-07-31 23:07   ` Kelvin.Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZR/htuZSKGJP1wgU@matsya \
    --to=vkoul@kernel.org \
    --cc=George.Ge@microchip.com \
    --cc=Kelvin.Cao@microchip.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dmaengine@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=logang@deltatee.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox