matthew at mxtelecom
Mar 23, 2005, 7:50 PM
Post #16 of 20
(1614 views)
Permalink
|
Many many thanks for looking into this - I'll give the patch a whirl
tomorrow morning. I'd wondered earlier what the
+ 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 matthew[at]mxtelecom.com 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 matthew[at]mxtelecom.com 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
>> ivtv-devel[at]lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ivtv-devel
>
> --
> ---
> Chris Kennedy / ckennedy[at]kmos.cmsu.edu
> 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
> ivtv-devel[at]lists.sourceforge.net
> 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
ivtv-devel[at]lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
|
