public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Glöckner" <daniel-gl@gmx.net>
To: Andy Walls <awalls@radix.net>
Cc: video4linux-list@redhat.com, v4l-dvb-maintainer@linuxtv.org,
	Jean Delvare <jdelvare@suse.de>
Subject: Re: [v4l-dvb-maintainer] bttv driver questions
Date: Wed, 27 Aug 2008 01:29:13 +0200	[thread overview]
Message-ID: <20080826232913.GA2145@daniel.bse> (raw)
In-Reply-To: <1219711251.2796.47.camel@morgan.walls.org>

On Mon, Aug 25, 2008 at 08:40:51PM -0400, Andy Walls wrote:
> On Mon, 2008-08-25 at 14:45 +0200, Jean Delvare wrote:
> > * When is the bttv IRQ handler called? At the end of every frame?

yes

> > At the end of the VBI?

yes

> > Between the odd field and even field sequences for full resolution frames?

no, in-between only if fields are captured independently

> > * Does the bttv driver have anything special to do for full
> >   resolution frames, that it doesn't have to do for half resolution
> >   ones? In particular, I wonder if the BT878 DMA engine knows how to
> >   interlace fields when writing to the memory, or if the bttv driver
> >   must take care of reordering the fields properly afterwards. I
> >   suspect the latter.

The driver fills buffers with instructions for the DMA engine, one buffer
for the top field and one for the bottom field. These instructions tell
the engine where to write a specific pixel. For interlaced video the
instructions for the top field write to line 0, 2, 4, ... in memory and for
the bottom field to line 1, 3, 5, ... .

> > * How longs are the blocks written by the BT878 DMA engine to memory?
> >   Obviously it can't send more than the FIFO size (128 bytes) at
> >   once.

The FIFO is bigger. In packed modes it is 140x4 bytes. In planar modes
it is 70x4 bytes for luma and 35x4 bytes for each chroma FIFO.

> IF I'm reading the PCI 2.2 spec correctly, targets are allowed an
> initial (start of burst) latency of up to 16 cycles before they must be
> ready for the first data transfer in a burst.  Host bridges as targets
> are allowed an additional 16 cycles setup time (for a total of 32) if
> the transfer is to a modified cache line.  For subsequent transfers in
> the burst, the target is only allowed 8 setup cycles max.
> 
> So with a BT878 latency timer of 32 cycles, a 128 byte burst could be
> sent as 2 transactions, assuming a maximum target setup time for the
> host bridge, with a transfer that doesn't hit a modified cache line,
> assuming transparent arbitration:
> 
> 1 addr cycle + 16 setup cycles + 15 data cycles  (60 bytes transferred)
> 1 turn around cycle (I think...)
> 1 addr cycle + 8 setup cycles + 17 data cycles (68 bytes transferred)
> 1 turn around cycle

I think worst case for slow targets is more like

1 addr cycle
15 setup cycles (unsure if initial latency includes addr cycle...)
1 data cycle
7 setup cycles
1 data cycle
7 setup cycles <-- latency timer of 32 expires, assuming GNT# is deasserted
1 data cycle <-- can't deassert FRAME# yet
7 setup cycles <-- FRAME# deasserted
1 data cycle
1 turnaround cycle
--------------------
16 bytes in 42 cycles

With fast targets we have

1 addr cycle
31 data cycles
(more data cycles as long as GNT# is asserted)
1 data cycle with FRAME# deasserted
1 turnaround cycle
--------------------
128 bytes in 34 cycles

> >  I am curious if there is a minimum FIFO usage for the
> >   BT878 to request the PCI bus. Couldn't find anything related to
> >   this in the datasheet.

There are FIFO trigger points settable in the GPIO_DMA_CTL register.
They can be set to 4, 8, 16, or 32 DWORDS.

> A PCI latency timer is the maximum amount of cycles a master is allowed
> to have the bus before it must request another grant.

The master may request extended/another grant before its timer expires.
Furthermore the arbiter may grant the bus without it being requested (bus
parking).

Making use of both features can be turned off in the Bt878 by the EN_TBFX and
EN_VSFX bits respectively to cope with bad chipsets.

Jean, is v4l-dvb-maintainer the right place to discuss these things?

  Daniel

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

  reply	other threads:[~2008-08-26 23:30 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 [this message]
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
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=20080826232913.GA2145@daniel.bse \
    --to=daniel-gl@gmx.net \
    --cc=awalls@radix.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