On Mon, Feb 7, 2011 at 8:49 AM, Guennadi Liakhovetski
wrote:
> Ok, I've found the reason. Buffer number repeats, when there is an
> underrun, which is happening in my tests, when frames are arriving quickly
> enough, but the user-space is not fast enough to process them, e.g., when
> it is writing
On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
> On Mon, 7 Feb 2011 12:35:44 +0100 (CET)
> Guennadi Liakhovetski wrote:
>
> > On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
> >
> > > On Mon, 7 Feb 2011 12:09:15 +0100 (CET)
> > > Guennadi Liakhovetski wrote:
> > > ...
> > > > > I can't try mplaye
Hi Guennadi,
> Hi Detlev
>
> On Mon, 7 Feb 2011, Detlev Zundel wrote:
>
>> Hi Guennadi,
>>
>> >> How small are the frames in you test? What is the highest fps value in
>> >> your test?
>> >
>> > QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think.
>> > Just try different fra
On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
> On Mon, 7 Feb 2011 12:35:44 +0100 (CET)
> Guennadi Liakhovetski wrote:
>
> > On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
> >
> > > On Mon, 7 Feb 2011 12:09:15 +0100 (CET)
> > > Guennadi Liakhovetski wrote:
> > > ...
> > > > > I can't try mplaye
On Mon, 7 Feb 2011 12:35:44 +0100 (CET)
Guennadi Liakhovetski wrote:
> On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
>
> > On Mon, 7 Feb 2011 12:09:15 +0100 (CET)
> > Guennadi Liakhovetski wrote:
> > ...
> > > > I can't try mplayer since I don't have mplayer setup for this.
> > > > But looking
Hi Detlev
On Mon, 7 Feb 2011, Detlev Zundel wrote:
> Hi Guennadi,
>
> >> How small are the frames in you test? What is the highest fps value in
> >> your test?
> >
> > QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think.
> > Just try different frams sizes, go down to 64x48
Hi Guennadi,
>> How small are the frames in you test? What is the highest fps value in
>> your test?
>
> QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think.
> Just try different frams sizes, go down to 64x48 or something.
Is this a "real" usage scenario? It feels that this
On Mon, 7 Feb 2011, Anatolij Gustschin wrote:
> On Mon, 7 Feb 2011 12:09:15 +0100 (CET)
> Guennadi Liakhovetski wrote:
> ...
> > > 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 o
On Mon, 7 Feb 2011 12:09:15 +0100 (CET)
Guennadi Liakhovetski wrote:
...
> > 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 t
On Sat, 5 Feb 2011, Anatolij Gustschin wrote:
> On Sat, 5 Feb 2011 17:36:37 +0100 (CET)
> Guennadi Liakhovetski 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 di
On Sat, 5 Feb 2011 17:36:37 +0100 (CET)
Guennadi Liakhovetski 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
> >
On Sat, 5 Feb 2011, Anatolij Gustschin wrote:
> Hi Guennadi,
>
> On Thu, 3 Feb 2011 11:09:54 +0100 (CET)
> Guennadi Liakhovetski wrote:
>
> > Hi Anatolij
> >
> > On Mon, 31 Jan 2011, Anatolij Gustschin wrote:
> >
> > I'm afraid there seems to be a problem with your patch. I have no idea
> >
Hi Guennadi,
On Thu, 3 Feb 2011 11:09:54 +0100 (CET)
Guennadi Liakhovetski wrote:
> Hi Anatolij
>
> On Mon, 31 Jan 2011, Anatolij Gustschin wrote:
>
> I'm afraid there seems to be a problem with your patch. I have no idea
> what is causing it, but I'm just observing some wrong behaviour, that
Hello Guennadi,
sorry, forget to explicitly write it in my mail, I also applied the
patch in question:
dma: ipu_idmac: do not lose valid received data in the irq handler
Will try the other way round without the patch later ...
Thanks
Markus
Am 04.02.2011 10:37, schrieb Guennadi Liakhovetski:
Hi Markus
On Fri, 4 Feb 2011, Markus Niebel wrote:
> Hello Guennadi, hello Anatolij
>
> I've tried that with my setup:
>
> Hardware: i.MX35, special CCD camera over FPGA
> Kernel: 2.6.34
>
> patch v4l: soc-camera: start stream after queueing the buffers is applied and
> our camera driver handl
Hi all,
On Thu, 3 Feb 2011 11:09:54 +0100 (CET)
Guennadi Liakhovetski wrote:
...
> Yes, the first interrupt is different, that's where I'm dropping /
> postponing it. With your patch only N (equal to the number of buffers
> used, I think) first interrupts toggle, then always only one buffer is
Hello Guennadi, hello Anatolij
I've tried that with my setup:
Hardware: i.MX35, special CCD camera over FPGA
Kernel: 2.6.34
patch v4l: soc-camera: start stream after queueing the buffers is
applied and our camera driver handles streamon / streamoff so that no
sync signal / clock is provided,
Hi Anatolij
On Mon, 31 Jan 2011, Anatolij Gustschin wrote:
I'm afraid there seems to be a problem with your patch. I have no idea
what is causing it, but I'm just observing some wrong behaviour, that is
not there without it. Namely, I added a debug print to the IDMAC interrupt
handler
Currently when two or more buffers are queued by the camera driver
and so the double buffering is enabled in the idmac, we lose one
frame comming from CSI since the reporting of arrival of the first
frame is deferred by the DMAIC_7_EOF interrupt handler and reporting
of the arrival of the last fram
19 matches
Mail list logo
