public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Glöckner" <daniel-gl@gmx.net>
To: Jean Delvare <jdelvare@suse.de>
Cc: video4linux-list@redhat.com, v4l-dvb-maintainer@linuxtv.org
Subject: Re: bttv driver questions
Date: Sat, 30 Aug 2008 17:12:33 +0200	[thread overview]
Message-ID: <20080830151233.GA221@daniel.bse> (raw)
In-Reply-To: <200808301201.47561.jdelvare@suse.de>

On Sat, Aug 30, 2008 at 12:01:47PM +0200, Jean Delvare wrote:
> 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?

When there is an application requesting VBI capture, there will be a
VBI interrupt, regardless of the content in those lines.

> > 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.

No, this is how bttv does it.
Other implementations may use a single loop without jumps.

> 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.

It's not that much faster. Of the 250MB/s a lot is lost to overhead,
especially when there are mostly short packets. And there may be other
bottlenecks before the data reaches the RAM.

> > 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?

A smaller trigger point will make the PCI bus less idle but the average
FIFO fill will be lower.

Yesterday I wrote a small program that simulates a number of PCI masters
with constant data rate filling their FIFOs. There is a simple round
robin arbiter and neither the target nor the master needs wait cycles.

For 5 masters with 24.2MB/s each (peak data rate of YUY2 640x480 NTSC),
a latency counter of 254, and a FIFO trigger of 4, the bus is never idle.
The maximum FIFO fill is 16 DWords. With a latency counter below 20,
the FIFO fill rises infinitely.

With a FIFO trigger of 32 and a latency counter of 254, the maximum fill
is 33 DWords and the bus is 4.5% idle.

Those 17 less FIFO entries in the 4-entry-trigger case can buffer for 93
PCI cycles. The 4.5% idle cycles in the 32-entry-trigger case are wasted
if there is no other master on the bus, as is the case when the Bt878s are
behind a bridge.

In reality there are always idle phases during syncs and additional
traffic will be generated to fetch RISC instructions and to access
registers.

  Daniel

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  parent reply	other threads:[~2008-08-30 15:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200808251445.22005.jdelvare@suse.de>
2008-08-26  0:40 ` [v4l-dvb-maintainer] bttv driver questions Andy Walls
2008-08-26 23:29   ` Daniel Glöckner
2008-08-27  2:20     ` Trent Piepho
2008-08-27  2:59       ` Robert William Fuller
2008-08-28 19:43         ` Trent Piepho
2008-08-27  3:45       ` Andy Walls
2008-08-28 19:48         ` Trent Piepho
     [not found]     ` <200808281611.38241.jdelvare@suse.de>
2008-08-28 20:20       ` Daniel Glöckner
2008-08-28 21:42         ` hermann pitton
     [not found]         ` <200808301201.47561.jdelvare@suse.de>
2008-08-30 15:12           ` Daniel Glöckner [this message]
2008-08-31 16:37             ` Andy Walls
     [not found]             ` <200809011144.54233.jdelvare@suse.de>
2008-09-01 12:35               ` Daniel Glöckner
     [not found]                 ` <200809012126.06532.jdelvare@suse.de>
2008-09-01 22:54                   ` Daniel Glöckner
     [not found]                     ` <200809021109.31007.jdelvare@suse.de>
     [not found]                       ` <200809021305.12318.jdelvare@suse.de>
2008-09-03 22:29                         ` Daniel Glöckner
     [not found]                           ` <200809051436.18549.jdelvare@suse.de>
2008-09-05 15:51                             ` Daniel Glöckner
2008-09-05 19:16                       ` [v4l-dvb-maintainer] " Trent Piepho
     [not found]   ` <200808281658.28151.jdelvare@suse.de>
2008-08-29 12:09     ` Andy Walls
2008-08-29 22:23       ` Trent Piepho
2008-08-30  0:10         ` Daniel Glöckner
     [not found]           ` <200808300954.19361.jdelvare@suse.de>
2008-08-30 16:44             ` Daniel Glöckner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080830151233.GA221@daniel.bse \
    --to=daniel-gl@gmx.net \
    --cc=jdelvare@suse.de \
    --cc=v4l-dvb-maintainer@linuxtv.org \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox