Re: bttv driver questions

[Jean Delvare <jdelvare@xxxxxxx>]

Hi Daniel,

Thanks again for the very useful answers.

Le jeudi 28 août 2008, Daniel Glöckner a écrit :
> On Thu, Aug 28, 2008 at 04:11:38PM +0200, Jean Delvare wrote:
> > My tests with a SECAM
> > source show a rate of 74-78 interrupts/second, which would be 3
> > interrupts per frame. So I guess I a missing a 3rd cause of
> > interrupts. Any idea?
> 
> I checked the code. As soon as the device is opened, the VSYNC interrupt
> is unmasked to count the fields. These interrupts are in addition to the
> interrupts generated for queued buffers.

Ah, right. Instead of trying to guess what the interrupts were, I
enabled irq_debug for a short time and then took a look at the kernel
log. The 3 interrupts I get for every frame are 2 VSYNC and 1 RISCI
which calls bttv_irq_switch_video(). My assumption that there was a
VBI interrupt was wrong, probably because my video source is a VCR
and it doesn't send any information during VBI?

> > I thought that there was only one RISC program
> > loaded at any given time and that it had to be changed twice per
> > frame, which would have taken one additional interrupt.
> 
> There is only one program with jumps that are patched at runtime to
> point to the program fragments for capture.

And this all happens magically inside the BT878 without the bttv
driver having to care? Wow! Tricky.

> > The BT878 has a hint which suggests that the fastest model described
> > by Daniel is probably almost the right one.
> 
> The setup cycles mentioned by Andy and me depend on the target (the host
> bridge). The master must assert IRDY within 8 cycles in all data phases.
>
> As a single Bt878 is able to capture PAL in BGR32 at 4*Fsc (70937900 byte/s
> peak), there must be less than one wait cycle per data phase on average.

In my case there's a PCI Express-to-PCI bridge on the path, so I
presume that this acts as the target. I suppose that the board was
designed that way precisely to make sure that no extra latency would
happen on the PCI bus due to the host being slow/busy. If the bridge
has large enough buffers, it should be easy for it to send the data
down to the host bridge, given that PCI Express x1 is much faster
than PCI.

> > Apparently the bttv driver sets them to relatively large values,
> > instead of the small hardware default (4). This makes sense to me,
> > 4 was very small and would cause the BT878 to request control of the
> > PCI bus every now and then, significantly reducing the available PCI
> > bus bandwidth.
> 
> I think for competing Bt878s the smallest trigger point in combination
> with a high latency counter should perform best.

I don't quite follow you here. Care to explain how you reached this
conclusion?

Thanks,
-- 
Jean Delvare
Suse L3

_______________________________________________
v4l-dvb-maintainer mailing list
v4l-dvb-maintainer@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer