All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Sricharan R <sricharan@codeaurora.org>
Cc: andy.gross@linaro.org, david.brown@linaro.org,
	dan.j.williams@intel.com, linux-arm-msm@vger.kernel.org,
	linux-soc@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors
Date: Sat, 17 Jun 2017 19:07:16 +0530	[thread overview]
Message-ID: <20170617133716.GG19154@localhost> (raw)
In-Reply-To: <004fa3c7-afb9-f56c-8a57-abc0117638eb@codeaurora.org>

On Thu, Jun 15, 2017 at 08:19:48PM +0530, Sricharan R wrote:

> > I am not sure why suppressing callback helps? I think you should still
> > continue filling up FIFO but also ensure interrupt so that callback can be
> > invoked, user thread maybe waiting on that
> > 
> > FWIW waiting for interrupt and submitting is extremely inefficient and
> > shouldn't be done, so that part of this is good.
> > 
> 
>  Thanks for the review.
>  
>  So one part is, adding desc to the FIFO till its full, so the BAM dmaengine is
>  busy  when there are pending descriptors without waiting for interrupt.
> 
>  Another part is, currently, the driver signals the completion of the each
>  descriptor with a interrupt, even though the client has not requested
>  a DMA_PREP_INTERRUPT/registered a callback. Instead if the client has
>  not requested for a interrupt for the completion of a descriptor, then
>  generate a interrupt only for descriptor for which it was requested and
>  also complete all the previous descriptors in that interrupt (means call
>  all callbacks). So we still call all callbacks but at the end of a
>  group of descriptors.

okay that sounds sane, but somehow I was getting the impression that we
might be suppressing, so you might want to update comments

> >>  	async_desc->num_desc = num_alloc;
> >>  	async_desc->curr_desc = async_desc->desc;
> >> @@ -680,13 +684,18 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> >>  static int bam_dma_terminate_all(struct dma_chan *chan)
> >>  {
> >>  	struct bam_chan *bchan = to_bam_chan(chan);
> >> +	struct bam_async_desc *async_desc;
> >>  	unsigned long flag;
> >>  	LIST_HEAD(head);
> >>  
> >>  	/* remove all transactions, including active transaction */
> >>  	spin_lock_irqsave(&bchan->vc.lock, flag);
> >>  	if (bchan->curr_txd) {
> >> -		list_add(&bchan->curr_txd->vd.node, &bchan->vc.desc_issued);
> >> +		list_for_each_entry(async_desc, &bchan->desc_list, desc_node) {
> >> +			bchan->curr_txd = async_desc;
> >> +			list_add(&bchan->curr_txd->vd.node,
> >> +				 &bchan->vc.desc_issued);
> > 
> > that is wrong, terminated should not add to issued list
> 
>  hmm, since it was already done like that, i added the same for list of descriptors now.

Sounds like you should fix existing behaviour too :)

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors
Date: Sat, 17 Jun 2017 19:07:16 +0530	[thread overview]
Message-ID: <20170617133716.GG19154@localhost> (raw)
In-Reply-To: <004fa3c7-afb9-f56c-8a57-abc0117638eb@codeaurora.org>

On Thu, Jun 15, 2017 at 08:19:48PM +0530, Sricharan R wrote:

> > I am not sure why suppressing callback helps? I think you should still
> > continue filling up FIFO but also ensure interrupt so that callback can be
> > invoked, user thread maybe waiting on that
> > 
> > FWIW waiting for interrupt and submitting is extremely inefficient and
> > shouldn't be done, so that part of this is good.
> > 
> 
>  Thanks for the review.
>  
>  So one part is, adding desc to the FIFO till its full, so the BAM dmaengine is
>  busy  when there are pending descriptors without waiting for interrupt.
> 
>  Another part is, currently, the driver signals the completion of the each
>  descriptor with a interrupt, even though the client has not requested
>  a DMA_PREP_INTERRUPT/registered a callback. Instead if the client has
>  not requested for a interrupt for the completion of a descriptor, then
>  generate a interrupt only for descriptor for which it was requested and
>  also complete all the previous descriptors in that interrupt (means call
>  all callbacks). So we still call all callbacks but at the end of a
>  group of descriptors.

okay that sounds sane, but somehow I was getting the impression that we
might be suppressing, so you might want to update comments

> >>  	async_desc->num_desc = num_alloc;
> >>  	async_desc->curr_desc = async_desc->desc;
> >> @@ -680,13 +684,18 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> >>  static int bam_dma_terminate_all(struct dma_chan *chan)
> >>  {
> >>  	struct bam_chan *bchan = to_bam_chan(chan);
> >> +	struct bam_async_desc *async_desc;
> >>  	unsigned long flag;
> >>  	LIST_HEAD(head);
> >>  
> >>  	/* remove all transactions, including active transaction */
> >>  	spin_lock_irqsave(&bchan->vc.lock, flag);
> >>  	if (bchan->curr_txd) {
> >> -		list_add(&bchan->curr_txd->vd.node, &bchan->vc.desc_issued);
> >> +		list_for_each_entry(async_desc, &bchan->desc_list, desc_node) {
> >> +			bchan->curr_txd = async_desc;
> >> +			list_add(&bchan->curr_txd->vd.node,
> >> +				 &bchan->vc.desc_issued);
> > 
> > that is wrong, terminated should not add to issued list
> 
>  hmm, since it was already done like that, i added the same for list of descriptors now.

Sounds like you should fix existing behaviour too :)

-- 
~Vinod

  reply	other threads:[~2017-06-17 13:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-07 12:29 [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors Sricharan R
2017-06-07 12:29 ` Sricharan R
2017-06-15  4:10 ` Vinod Koul
2017-06-15  4:10   ` Vinod Koul
2017-06-15  4:10   ` Vinod Koul
2017-06-15 14:49   ` Sricharan R
2017-06-15 14:49     ` Sricharan R
2017-06-17 13:37     ` Vinod Koul [this message]
2017-06-17 13:37       ` Vinod Koul
2017-08-21 12:16       ` Sricharan R
2017-08-21 12:16         ` Sricharan R

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=20170617133716.GG19154@localhost \
    --to=vinod.koul@intel.com \
    --cc=andy.gross@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=david.brown@linaro.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=sricharan@codeaurora.org \
    /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.