Chris
I think that vsync wants removing whatever. Since X is currently
doing 2 calls for large screen updates it means that a full screen X update
takes 2 vsync's which is bad.
I think in time it should possibly be an option to the prep frame call to
request a vsync'ed transfer, but for now I think this patch is correct.
John
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:ivtv-devel-
> [EMAIL PROTECTED] On Behalf Of Chris Kennedy
> Sent: 23 March 2005 18:28
> To: [email protected]
> Subject: Re: [ivtv-devel] #0.3.2l minor code cleanup
>
> Try this patch to 0.3.2l, maybe will help, I don't think we need the
> vsync wait anymore for OSD DMA. The actual thing that seems to have
> fixed this on my VIA and looks like a very promising fix, and the thing
> I've been chasing for a very long time, is setting a pci register
> different than the default. I just started looking closer at the
> data sheet Axel Thimm sent us (thanks for that), for the cx23416,
> which Conexant allowed Hauppauge to release to us finally a few months
> back. That had in it, on page 66, the pci register values for PCI Bus
> configuration. Well register 0x40 is very interesting, it's the
> Retry TImeout and also the TRDY Timeout for PCI transfers, ties into
> the DMA timeouts on VIA and certain motherboards, and DMA errors. It
> makes sense logically, I checked the windows driver, looked at the
> system with a pci bus tool, and saw there the values are 0xff for
> both, or 0x0000ffff for register 0x40, ours in linux (the default
> acording to the datasheet) happens to be 0x00008080. So I maxed this
> out, haven't had a DMA error or system lockup on my VIA system since.
>
> So that's the reasoning, I think anyone out there who has had problems,
> or says this chip isn't good at DMA, should now try this new version.
> I think it will change your mind for the most part (admit there could be
> other things, but this was the *BIG* one I've been chasing for a very
> long time). Basically, we do DMA xfers, the PCI bus interface was set
> to timeout at a low value and retry a small number of times, at least for
> some motherboards (Intel ones seem fine, must have been what the default
> values were tuned for), so the PCI bus was timing out in the middle of our
> DMA xfers, retrying, and playing a game of random catastrophys depending
> on our luck (which doesn't seem to be a good thing to stop the DMA xfer
> in mid run and retry it multiple times, when waiting just a bit longer
> would allow it to work, like twice as long it seems). That's my
> explanation,
> of course just the datasheet and a windows pci probe shows the hard facts
> of it being a setting changed by the windows driver, and my experience now
> shows me it works perfectly under high DMA loads on a system which crashed
> every time under certain tests it now works fine on.
>
>
> diff -BurN ivtv-0.3.2l/driver/ivtv-osd.c ivtv-0.3.2m/driver/ivtv-osd.c
> --- ivtv-0.3.2l/driver/ivtv-osd.c 2005-03-22 10:08:09.000000000 -
> 0600
> +++ ivtv-0.3.2m/driver/ivtv-osd.c 2005-03-23 12:16:50.000000000 -
> 0600
> @@ -1331,22 +1331,22 @@
>
> /* Send DMA */
> if (cmd == IVTVFB_IOCTL_PREP_FRAME) {
> - if (wait_event_interruptible(itv->vsync_w_osd,
> + /*if (wait_event_interruptible(itv->vsync_w_osd,
> atomic_read(&itv->
>
> dec_dma_stat.
>
> vsync_flag_osd)))
> {
> ret = -ERESTARTSYS;
> } else {
> - atomic_set(&itv-
> >dec_dma_stat.vsync_flag_osd,
> + atomic_set(&itv-
> >dec_dma_stat.vsync_flag_osd,*/
> 0);
> ret =
> ivtv_fb_prep_frame(itv,
> (args.dest_offset),
> (args.source),
> args.count);
> - }
> + //}
> } else if (cmd == IVTVFB_IOCTL_PREP_FRAME_BUF) {
> - if (wait_event_interruptible(itv->vsync_w_osd,
> + /*if (wait_event_interruptible(itv->vsync_w_osd,
> atomic_read(&itv->
>
> dec_dma_stat.
>
> vsync_flag_osd)))
> @@ -1354,13 +1354,13 @@
> ret = -ERESTARTSYS;
> } else {
> atomic_set(&itv-
> >dec_dma_stat.vsync_flag_osd,
> - 0);
> + 0);*/
> ret =
> ivtv_fb_prep_frame_buf(itv,
>
> (args.dest_offset),
> (args.source),
> args.count);
> - }
> + //}
> } else if (cmd == IVTVFB_IOCTL_PREP_FRAME_YUV) {
> if (wait_event_interruptible(itv->vsync_w_osd,
> atomic_read(&itv->
>
>
>
> Thanks,
> Chris
> On Wed, Mar 23, 2005 at 06:04:52PM +0000, Matthew Hodgson wrote:
> > Hi,
> >
> > Chris Kennedy wrote:
> > >This cleans up a bit more of the DMA code, removes some more unused
> code.
> > >Please test this if you have had DMA problems, and if having VIA
> > >motherboard
> > >problems in the past, or any other DMA errors.
> >
> > I'm afraid this hasn't fixed the issue I'm having with OSD performance
> on
> > my PVR-350 significantly reducing after DMAing to the decoder; on
> loading
> > 0.3.2l ivtvfbctl -prepdma gives 33fps when displaying a 720x576 screen.
> I
> > then cat something.mpeg > /dev/video16, and then running the same
> ivtvfbctl
> > -prepdma gives 25fps.
> >
> > Something I did notice, however, is that when running -prepdma with a
> > 720x480 size frame, the problem doesn't present itself. In fact, it's
> only
> > when the DMA size gets to around the 720x520 mark that the fps starts to
> > fluctuate between 25fps and 33fps.
> >
> > I've tried ramping up the PCI latency for the PVR-350 to maximum, but it
> > doesn't seem to make any difference. Likewise splitting the transfer
> into
> > two 720x288 chunks - or using PREP_DMA_BUF rather than PREP_DMA.
> >
> > The only time it's worked recently has been with 0.3.2b using
> PREP_DMA_BUF
> > - but DMA then became unstable after a few days.
> >
> > Can you think of anything which would be causing this? Perhaps a
> > difference between the number of DMA buffers that can be used of PAL
> size
> > rather than NTSC? For what it's worth, I'm not currently using the
> mpeg2
> > encoder on the card - is there any chance that it might be somehow
> > interfering with the OSD, and if so, how do I turn it off?
> >
> > cheers;
> >
> > Matthew.
> >
> > --
> > ______________________________________________________________
> > Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778
> > Systems Analyst, MX Telecom Ltd.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
> 2005
> > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> > Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> > Register
> > by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> > _______________________________________________
> > ivtv-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ivtv-devel
>
> --
> ---
> Chris Kennedy / [EMAIL PROTECTED]
> Engineer KMOS-TV/KTBG-FM
> Broadcasting Services Department
> Central Missouri State University
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> Register
> by 3/29 & save $300
> http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ivtv-devel
-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
