From: agust@denx.de (Anatolij Gustschin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Date: Sat, 5 Feb 2011 21:04:57 +0100 [thread overview]
Message-ID: <20110205210457.7218ecdc@wker> (raw)
In-Reply-To: <Pine.LNX.4.64.1102051735270.11500@axis700.grange>
On Sat, 5 Feb 2011 17:36:37 +0100 (CET)
Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
...
> > > Verified with both capture.c and mplayer. Could you, please, verify
> > > whether you get the same behaviour and what the problem could be?
> >
> > Now I did some further testing with idmac patch applied and with
> > added debug print in the IDMAC interrupt handler. There is no problem.
> > Testing with capture.c (4 buffers used as default) shows that buffer
> > numbers toggle correctly for all 100 captured frames:
>
> Hm, interesting, I'll have to look at my testing in more detail then
> (once back from FOSDEM). Could you maybe try mplayer too?
I can't try mplayer since I don't have mplayer setup for this.
But looking at the mplayer source I don't see why it should
behave differently. Depending on mode mplayer queues 2 or 6
buffers. Testing with my test app with 6 queued buffers shows
no issues, here the buffer numbers toggle correctly, too.
Anatolij
next prev parent reply other threads:[~2011-02-05 20:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-26 8:49 [PATCH 0/2] Fix issues with frame reception from CSI on i.MX31 Anatolij Gustschin
2011-01-26 8:49 ` [PATCH 1/2] v4l: soc-camera: start stream after queueing the buffers Anatolij Gustschin
2011-01-29 19:16 ` Guennadi Liakhovetski
2011-01-29 19:24 ` Anatolij Gustschin
2011-01-31 12:19 ` [PATCH 1/2 v2] " Anatolij Gustschin
2011-01-26 8:49 ` [PATCH 2/2] dma: ipu_idmac: do not lose valid received data in the irq handler Anatolij Gustschin
2011-01-27 8:22 ` Anatolij Gustschin
2011-01-31 5:56 ` Dan Williams
2011-01-31 12:22 ` [PATCH 2/2 v2] " Anatolij Gustschin
2011-02-03 10:09 ` Guennadi Liakhovetski
2011-02-04 9:19 ` Markus Niebel
2011-02-04 9:37 ` Guennadi Liakhovetski
2011-02-04 11:37 ` Markus Niebel
2011-02-04 9:35 ` Anatolij Gustschin
2011-02-05 13:35 ` Anatolij Gustschin
2011-02-05 16:36 ` Guennadi Liakhovetski
2011-02-05 20:04 ` Anatolij Gustschin [this message]
2011-02-07 11:09 ` Guennadi Liakhovetski
2011-02-07 11:21 ` Anatolij Gustschin
2011-02-07 11:35 ` Guennadi Liakhovetski
2011-02-07 13:01 ` Detlev Zundel
2011-02-07 13:35 ` Guennadi Liakhovetski
2011-02-07 14:43 ` Detlev Zundel
2011-02-07 13:45 ` Anatolij Gustschin
2011-02-07 14:00 ` Guennadi Liakhovetski
2011-02-07 16:49 ` Guennadi Liakhovetski
2011-02-14 9:57 ` Dan Williams
2011-01-28 7:46 ` [PATCH 0/2] Fix issues with frame reception from CSI on i.MX31 Anatolij Gustschin
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=20110205210457.7218ecdc@wker \
--to=agust@denx.de \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).