+ pci_write_config_dword(dev, 0x40, 0xffff);
line was doing in ivtv-driver.c in 0.3.2l, but never xreffed Axel's datasheet. It appeared to improve the stability of the framerate when writing to the OSD (especially combined with cranking up the PCI latency to 248 from 64), but not the actual transfer rate (or my core problem of OSD performance taking a serious hit after opening/writing/closing the decoder MPEG stream). This is on an 2.8GHz P4 reference Intel motherboard, however, so I've probably never suffered the same problems as everyone with VIA chipsets.
Anyway, thanks again for the vsyncless patch - I'll post back my findings tomorrow.
cheers;
M.
--
______________________________________________________________
Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778
Systems Analyst, MX Telecom Ltd.On Wed, 23 Mar 2005, Chris Kennedy wrote:
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
