All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dmaengine@vger.kernel.org, Michal Simek <michal.simek@xilinx.com>,
	Hyun Kwon <hyun.kwon@xilinx.com>,
	Tejas Upadhyay <tejasu@xilinx.com>,
	Satish Kumar Nagireddy <SATISHNA@xilinx.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: [PATCH v6 4/6] dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver
Date: Wed, 15 Jul 2020 16:29:06 +0530	[thread overview]
Message-ID: <20200715105906.GI34333@vkoul-mobl> (raw)
In-Reply-To: <20200708201906.4546-5-laurent.pinchart@ideasonboard.com>

On 08-07-20, 23:19, Laurent Pinchart wrote:

> +static struct dma_async_tx_descriptor *
> +xilinx_dpdma_prep_interleaved_dma(struct dma_chan *dchan,
> +				  struct dma_interleaved_template *xt,
> +				  unsigned long flags)
> +{
> +	struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan);
> +	struct xilinx_dpdma_tx_desc *desc;
> +
> +	if (xt->dir != DMA_MEM_TO_DEV)
> +		return NULL;
> +
> +	if (!xt->numf || !xt->sgl[0].size)
> +		return NULL;
> +
> +	if (!(flags & DMA_PREP_REPEAT))
> +		return NULL;

is the hw be not capable of supporting single interleave txn?

Also as replied the comment to Peter, we should check chan->running here
and see that DMA_PREP_LOAD_EOT is set. There can still be a case where
descriptor is submitted but not issued causing you to miss, but i guess
that might be overkill for your scenarios

> +static int xilinx_dpdma_config(struct dma_chan *dchan,
> +			       struct dma_slave_config *config)
> +{
> +	struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan);
> +	unsigned long flags;
> +
> +	/*
> +	 * The destination address doesn't need to be specified as the DPDMA is
> +	 * hardwired to the destination (the DP controller). The transfer
> +	 * width, burst size and port window size are thus meaningless, they're
> +	 * fixed both on the DPDMA side and on the DP controller side.
> +	 */

But we are not doing peripheral transfers, this is memory to memory
(interleave) here right?

> +
> +	spin_lock_irqsave(&chan->lock, flags);
> +
> +	/*
> +	 * Abuse the slave_id to indicate that the channel is part of a video
> +	 * group.
> +	 */
> +	if (chan->id >= ZYNQMP_DPDMA_VIDEO0 && chan->id <= ZYNQMP_DPDMA_VIDEO2)
> +		chan->video_group = config->slave_id != 0;

Okay looking closely here, the video_group is used to tie different
channels together to ensure sync operation is that right? And this seems
to be only reason for DMA_SLAVE capabilities, i don't think I saw slave
ops

> +static int xilinx_dpdma_terminate_all(struct dma_chan *dchan)
> +{
> +	struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan);
> +	struct xilinx_dpdma_device *xdev = chan->xdev;
> +	LIST_HEAD(descriptors);
> +	unsigned long flags;
> +	unsigned int i;
> +
> +	/* Pause the channel (including the whole video group if applicable). */
> +	if (chan->video_group) {
> +		for (i = ZYNQMP_DPDMA_VIDEO0; i <= ZYNQMP_DPDMA_VIDEO2; i++) {
> +			if (xdev->chan[i]->video_group &&
> +			    xdev->chan[i]->running) {
> +				xilinx_dpdma_chan_pause(xdev->chan[i]);

so there is no terminate here, only pause?
-- 
~Vinod

  parent reply	other threads:[~2020-07-15 10:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-08 20:19 [PATCH v6 0/6] dma: Add Xilinx ZynqMP DPDMA driver Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 1/6] dt: bindings: dma: xilinx: dpdma: DT bindings for Xilinx DPDMA Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 2/6] dmaengine: virt-dma: Use lockdep to check locking requirements Laurent Pinchart
2020-07-09 13:07   ` Peter Ujfalusi
2020-07-11 19:53     ` Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 3/6] dmaengine: Add support for repeating transactions Laurent Pinchart
2020-07-09 13:25   ` Peter Ujfalusi
2020-07-08 20:19 ` [PATCH v6 4/6] dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver Laurent Pinchart
2020-07-09 13:21   ` Peter Ujfalusi
2020-07-11 22:16     ` Laurent Pinchart
2020-07-15  6:54       ` Vinod Koul
2020-07-15 10:59   ` Vinod Koul [this message]
2020-07-16  0:41     ` Laurent Pinchart
2020-07-16  5:21       ` Vinod Koul
2020-07-16 13:46         ` Laurent Pinchart
2020-07-17  5:59           ` Vinod Koul
2020-07-08 20:19 ` [PATCH v6 5/6] dmaengine: xilinx: dpdma: Add debugfs support Laurent Pinchart
2020-07-15 11:01   ` Vinod Koul
2020-07-16  0:42     ` Laurent Pinchart
2020-07-08 20:19 ` [PATCH v6 6/6] arm64: dts: zynqmp: Add DPDMA node Laurent Pinchart

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=20200715105906.GI34333@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=SATISHNA@xilinx.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=hyun.kwon@xilinx.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=michal.simek@xilinx.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=tejasu@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.