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
