From: Hans Verkuil <hverkuil@xs4all.nl>
To: Ran Shalit <ranshalit@gmail.com>
Cc: linux-media@vger.kernel.org
Subject: Re: dma start/stop & vb2 APIs
Date: Tue, 19 Jan 2016 08:33:51 +0100 [thread overview]
Message-ID: <569DE6DF.3060508@xs4all.nl> (raw)
In-Reply-To: <CAJ2oMh+BXUnqehqGzaxqQK07+7HiEOpjRf4+GjqDNRbRNb5NKg@mail.gmail.com>
On 01/19/2016 05:45 AM, Ran Shalit wrote:
> On Mon, Jan 18, 2016 at 7:45 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 01/18/2016 05:26 PM, Ran Shalit wrote:
>>> Hello,
>>>
>>> I am trying to understand how to implement dma transfer correctly
>>> using videobuf2 APIs.
>>>
>>> Normally, application will do semthing like this (video test API):
>>>
>>> xioctl(fd, VIDIOC_DQBUF, &buf)
>>> process_image(buffers[buf.index].start, buf.bytesused);
>>> xioctl(fd, VIDIOC_QBUF, &buf)
>>>
>>> Therefore, in the driver below I will assume that:
>>> 1. VIDIOC_DQBUF - trigger dma to start
>>
>> No. DMA typically starts when VIDIOC_STREAMON is called, although depending
>> on the hardware the start of the DMA may be delayed if insufficient buffers
>> have been queued. When the start_streaming op is called you know that STREAMON
>> has been called and that at least min_buffers_needed buffers have been queued.
>>
>>> 2. interrupt handler in driver - stop dma
>>
>> ??? No, this just passes the buffer that has been filled by the DMA engine
>> to vb2 via vb2_buffer_done. The DMA will continue filling the next queued buffer.
>>
>
> Hi,
> Just to be sure I got it all right:
> "The DMA will continue filling the next queued buffer" is usually the
> responsibility of the interrupt handler .
> Interrrupt will get the new buffer from list and trigger next dma
> transaction with that buffer.
> Is that Right ?
Usually that's true. Again, I can't give absolutes because it depends on
the DMA hardware details. There tend to be two main types of DMA:
1) the DMA engine has pointers to the current and next frame: in that case
the irq handler has to update the pointers once the current frame finishes
the DMA.
2) the DMA engine has a list of descriptors describing each frame and that
links each frame to the next one. In that case the list of descriptors is
updated whenever a new buffer is queued. For engines like this the interrupt
function just returns the DMAed buffer and doesn't have to do anything else.
Regards,
Hans
next prev parent reply other threads:[~2016-01-19 7:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 16:26 dma start/stop & vb2 APIs Ran Shalit
2016-01-18 17:45 ` Hans Verkuil
2016-01-19 4:45 ` Ran Shalit
2016-01-19 7:33 ` Hans Verkuil [this message]
2016-01-30 11:55 ` Ran Shalit
2016-01-30 12:26 ` Hans Verkuil
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=569DE6DF.3060508@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=ranshalit@gmail.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