All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Bell <jonathan-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
To: "Noralf Trønnes" <noralf-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>,
	"Martin Sperl" <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>,
	"Stephen Warren"
	<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-spi <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-rpi-kernel
	<linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH v2] dmaengine: bcm2835: Add slave dma support
Date: Fri, 8 May 2015 12:20:00 +0100	[thread overview]
Message-ID: <554C9BE0.60205@raspberrypi.org> (raw)
In-Reply-To: <554A69D5.90301-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>

On 06/05/2015 20:21, Noralf Trønnes wrote:
>
> Den 01.05.2015 23:07, skrev Martin Sperl:
>> Tests with the initial (and incomplete) version of the spi-bcm2835 
>> driver
>> with DMA transfer support show that the dma-engine works as expected 
>> with
>> this patch.
>>
>> There is one one observation:
>>
>>> On 18.04.2015, at 13:06, Noralf Trønnes <noralf@tronnes.org> wrote:
>>> +static struct dma_async_tx_descriptor *
>>> +bcm2835_dma_prep_slave_sg(struct dma_chan *chan,
>>> +              struct scatterlist *sgl,
>>> +              unsigned int sg_len,
>>> +              enum dma_transfer_direction direction,
>>> +              unsigned long flags, void *context)
>>> +{
>> ...
>>> +            /* Enable */
>>> +            if (i == sg_len - 1 && len - j <= max_size)
>>> +                control_block->info |= BCM2835_DMA_INT_EN;
>> The observation is that an interrupt is always triggered - even in 
>> the case
>> where flags does NOT have DMA_PREP_INTERRUPT set.
>> This may not be necessary and avoid interrupts.
>>
>> So maybe the above if clause should get extended by:
>>     && (flags & DMA_PREP_INTERRUPT)
>> to only trigger an interrupt when really requested.
>>
>> I am not sure if there are any side-effects because of this besides 
>> having the
>> requirement on the client to run dmaengine_terminate_all() on that 
>> specific dma
>> channel without interrupts when the transfer is finished.
>>
>> In the case of SPI we have TX feed the fifo - which finishes early - 
>> , but we
>> only need to the interrupt when RX finishes reading the fifo, which 
>> indicates
>> that the SPI-transfer is fully finished.
>> So having an interrupt on TX is not necessary for the process.
>>
>> The same observations may also apply to bcm2835_dma_prep_dma_cyclic 
>> (which is
>> outside of this patch provided by Noralf).
>
> Jonathan, can you comment on this?
>
>
> Noralf.
>
>
I agree that the interrupt generated would be spurious - in the case 
where it is not required.

However if you do && (flags & DMA_PREP_INTERRUPT) then all users of this 
driver need to explicitly set interrupt flags when doing a 
scatter-gather transfer. As I understand it, currently the only upstream 
client of this driver is the I2S driver which only uses cyclic anyway.

Not requiring an interrupt on completion is a bit of an edge case - the 
default among other dmaengine drivers appears to be to enable interrupts 
unconditionally.




_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Bell <jonathan@raspberrypi.org>
To: "Noralf Trønnes" <noralf@tronnes.org>,
	"Martin Sperl" <kernel@martin.sperl.org>,
	"Stephen Warren" <swarren@wwwdotorg.org>
Cc: <dmaengine@vger.kernel.org>, <vinod.koul@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-rpi-kernel <linux-rpi-kernel@lists.infradead.org>,
	<dan.j.williams@intel.com>, linux-spi <linux-spi@vger.kernel.org>
Subject: Re: [PATCH v2] dmaengine: bcm2835: Add slave dma support
Date: Fri, 8 May 2015 12:20:00 +0100	[thread overview]
Message-ID: <554C9BE0.60205@raspberrypi.org> (raw)
In-Reply-To: <554A69D5.90301@tronnes.org>

On 06/05/2015 20:21, Noralf Trønnes wrote:
>
> Den 01.05.2015 23:07, skrev Martin Sperl:
>> Tests with the initial (and incomplete) version of the spi-bcm2835 
>> driver
>> with DMA transfer support show that the dma-engine works as expected 
>> with
>> this patch.
>>
>> There is one one observation:
>>
>>> On 18.04.2015, at 13:06, Noralf Trønnes <noralf@tronnes.org> wrote:
>>> +static struct dma_async_tx_descriptor *
>>> +bcm2835_dma_prep_slave_sg(struct dma_chan *chan,
>>> +              struct scatterlist *sgl,
>>> +              unsigned int sg_len,
>>> +              enum dma_transfer_direction direction,
>>> +              unsigned long flags, void *context)
>>> +{
>> ...
>>> +            /* Enable */
>>> +            if (i == sg_len - 1 && len - j <= max_size)
>>> +                control_block->info |= BCM2835_DMA_INT_EN;
>> The observation is that an interrupt is always triggered - even in 
>> the case
>> where flags does NOT have DMA_PREP_INTERRUPT set.
>> This may not be necessary and avoid interrupts.
>>
>> So maybe the above if clause should get extended by:
>>     && (flags & DMA_PREP_INTERRUPT)
>> to only trigger an interrupt when really requested.
>>
>> I am not sure if there are any side-effects because of this besides 
>> having the
>> requirement on the client to run dmaengine_terminate_all() on that 
>> specific dma
>> channel without interrupts when the transfer is finished.
>>
>> In the case of SPI we have TX feed the fifo - which finishes early - 
>> , but we
>> only need to the interrupt when RX finishes reading the fifo, which 
>> indicates
>> that the SPI-transfer is fully finished.
>> So having an interrupt on TX is not necessary for the process.
>>
>> The same observations may also apply to bcm2835_dma_prep_dma_cyclic 
>> (which is
>> outside of this patch provided by Noralf).
>
> Jonathan, can you comment on this?
>
>
> Noralf.
>
>
I agree that the interrupt generated would be spurious - in the case 
where it is not required.

However if you do && (flags & DMA_PREP_INTERRUPT) then all users of this 
driver need to explicitly set interrupt flags when doing a 
scatter-gather transfer. As I understand it, currently the only upstream 
client of this driver is the I2S driver which only uses cyclic anyway.

Not requiring an interrupt on completion is a bit of an edge case - the 
default among other dmaengine drivers appears to be to enable interrupts 
unconditionally.




  parent reply	other threads:[~2015-05-08 11:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-18 11:06 [PATCH v2] dmaengine: bcm2835: Add slave dma support Noralf Trønnes
     [not found] ` <1429355160-13657-1-git-send-email-noralf-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>
2015-05-01 21:07   ` Martin Sperl
2015-05-01 21:07     ` Martin Sperl
     [not found]     ` <DC1D0474-515B-4863-85FB-9E60FFA34829-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
2015-05-06 19:21       ` Noralf Trønnes
2015-05-06 19:21         ` Noralf Trønnes
     [not found]         ` <554A69D5.90301-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>
2015-05-08 11:20           ` Jonathan Bell [this message]
2015-05-08 11:20             ` Jonathan Bell
     [not found]             ` <554C9BE0.60205-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2015-05-11  5:11               ` Martin Sperl
2015-05-11  5:11                 ` Martin Sperl
2015-05-04  6:59 ` Martin Sperl
2015-05-12 15:58 ` Noralf Trønnes
     [not found]   ` <5552231A.9010503-L59+Z2yzLopAfugRpC6u6w@public.gmane.org>
2015-05-16 17:31     ` Martin Sperl
2015-05-16 17:31       ` Martin Sperl

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=554C9BE0.60205@raspberrypi.org \
    --to=jonathan-fnsa7b+nu9xbibc87yurow@public.gmane.org \
    --cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=noralf-L59+Z2yzLopAfugRpC6u6w@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.