Re: [v4l-dvb-maintainer] bttv driver questions

Re: [v4l-dvb-maintainer] bttv driver questions

[Andy Walls]

On Mon, 2008-08-25 at 14:45 +0200, Jean Delvare wrote:
> Hi Mauro, hi Trent,
> 
> I'm back with more questions about the bttv driver:
> 
> * When is the bttv IRQ handler called? At the end of every frame? At
>   the end of the VBI? Between the odd field and even field sequences
>   for full resolution frames?
> 
> * 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.
> 
> * 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. With the default PCI latency value (32) it seems that a
>   maximum of 96 bytes can actually be sent at once (8 cycles for
>   setup and 24 cycles for data on a 32-bit PCI bus -> 96 bytes per
>   transfer.)

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 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.
> 
> * In continuation of the above, am I correct assuming that setting
>   the latency timer of the BT878 above 40 doesn't make sense? 40 PCI
>   cycles is enough to empty the FIFO completely,

It can make sense, especially if it's the only high bandwidth card in
the system.  Set the timer too high for any one card though, and you
will start to starve other devices off the bus when that one card is
busy.  The cards that are held off the bus too long, may have their
FIFOs or buffers overrun....

Setting latency timers for a system is a balancing act between the needs
of individual devices and the system's need for the shared PCI bus to
support the maximum anticipated burst or sustained activity on the bus
by all the devices that could be active at once.


>  and then there's no
>   data left to send. But I'm curious how the BT878 behaves if it is
>   granted more time than it needs. Can it return the PCI bus control
>   earlier?

A PCI latency timer is the maximum amount of cycles a master is allowed
to have the bus before it must request another grant.  It is not the
amount of cycles the master must use the bus.  So yes a bus master can,
and often does, release the bus before it's latency timer expires: it's
a normal circumstance.  What an actual BT878 does, I'll leave to the
experts, who may know about any potential quirks it may have.


> Or is it keeping control of the bus and sending more data
>   as it becomes (slowly) available? The later would be bad for both
>   latency and throughput.

During the time an initiator (a bus master like the BT878) has FRAME
asserted, the initiator can deassert IRDY or the target can deassert
TRDY to insert wait states according to the PCI spec.  So theoretically
a BT878 could do such a thing, but I'm unsure why a chip would do such a
thing if it had little or nothing to send.  Of course every wait cycle
counts against the latency timer too.  Again, that's what's possible,
but I defer to BT878 experts on what the chip actually does.



> If anyone can help me answer these questions, I would be grateful.
> Thanks!

PCI-X and PCIe are of course slightly different from PCI.  I do not know
how much of the above applies for those busses.

Regards,
Andy

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Daniel Glöckner]

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1872 bytes --]

On Wed, 27 Aug 2008, Daniel [iso-8859-1] Glöckner wrote:
> 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:
> > > * 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, ... .

Keep in mind that _either_ field can be transmitted first.  I.e., in some
cases one first writes lines 1,3,5 then lines 0,2,4.  I'm not sure if bttv
supports both field dominances or not, but I think it does.

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

Isn't the latency timer in units of 250 ns, not PCI cycles?

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Robert William Fuller]

Trent Piepho wrote:
> On Wed, 27 Aug 2008, Daniel [iso-8859-1] Gl�ckner wrote:
>> 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:

<snipped>

>> 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, ... .
> 
> Keep in mind that _either_ field can be transmitted first.  I.e., in some
> cases one first writes lines 1,3,5 then lines 0,2,4.  I'm not sure if bttv
> supports both field dominances or not, but I think it does.

My particular board always returns top field first on capture.  I don't 
know if that helps.

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Trent Piepho]

On Tue, 26 Aug 2008, Robert William Fuller wrote:
> Trent Piepho wrote:
> >> 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, ... .
> >
> > Keep in mind that _either_ field can be transmitted first.  I.e., in some
> > cases one first writes lines 1,3,5 then lines 0,2,4.  I'm not sure if bttv
> > supports both field dominances or not, but I think it does.
>
> My particular board always returns top field first on capture.  I don't
> know if that helps.

V4L2 allows the application to select the field dominance,
V4L2_FIELD_INTERLACED_TB vs V4L2_FIELD_INTERLACED_BT.  The bt878 chip can
support both, but I don't know if the bttv driver has support for it.

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Andy Walls]

On Tue, 2008-08-26 at 19:20 -0700, Trent Piepho wrote:
> On Wed, 27 Aug 2008, Daniel [iso-8859-1] Glckner wrote:

> Isn't the latency timer in units of 250 ns, not PCI cycles?

Latency timer is in PCI clock cycles.  Most devices ignore the 3 least
significant bits of the setting (as allowed/suggested by the PCI spec),
making most latency timers as multiple of 8 PCI clock cycles.  

MIN_GNT and MAX_LAT are in units of 250 ns according to the PCI spec.
I'm assuming it's no coincidence that 8 PCI clock cycles = 8/33 MHZ =
242.4 ns or approximately 250 ns.

-Andy

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Trent Piepho]

On Tue, 26 Aug 2008, Andy Walls wrote:
> On Tue, 2008-08-26 at 19:20 -0700, Trent Piepho wrote:
> > On Wed, 27 Aug 2008, Daniel [iso-8859-1] Glckner wrote:
>
> > Isn't the latency timer in units of 250 ns, not PCI cycles?
>
> Latency timer is in PCI clock cycles.  Most devices ignore the 3 least
> significant bits of the setting (as allowed/suggested by the PCI spec),
> making most latency timers as multiple of 8 PCI clock cycles.

I bet I was reading a datasheet for a device that did this.  They probably
dropped three bits from the field width and said it was 250 ns units.

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

Re: bttv driver questions

[Daniel Glöckner]

On Thu, Aug 28, 2008 at 04:11:38PM +0200, Jean Delvare wrote:
> What determines whether fields are captured independently?

Right now I can only think of V4L2_FIELD_ALTERNATE causing this.

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

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

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

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

> > The master may request extended/another grant before its timer expires.
> 
> Do you happen to know if the BT878 does that? Couldn't find any
> mention in the datasheet.

Well, if they give us a bit to turn it off, I assume it is done.
Read the section about the 430FX Compatibility Mode.

> > Jean, is v4l-dvb-maintainer the right place to discuss these things?
> 
> I thought so. At least I received pertinent answers to my questions,
> so it seems that I have reached the right persons. But if you think I
> am abusing this list, I don't want to make anyone angry, so we can
> either continue this discussion in private, or on another list you
> think would be more appropriate.

Trent started CCing video4linux-list and from linux/MAINTAINERS I read
that v4l-dvb-maintainer is mainly for patches..
I'm only subscribed to video4linux-list, so I don't know what is customary
on the maintainer list.

  Daniel

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

Re: bttv driver questions

[hermann pitton]

Hello,

Am Donnerstag, den 28.08.2008, 22:20 +0200 schrieb Daniel Glöckner:
> On Thu, Aug 28, 2008 at 04:11:38PM +0200, Jean Delvare wrote:
> > What determines whether fields are captured independently?
> 
> Right now I can only think of V4L2_FIELD_ALTERNATE causing this.
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > > The master may request extended/another grant before its timer expires.
> > 
> > Do you happen to know if the BT878 does that? Couldn't find any
> > mention in the datasheet.
> 
> Well, if they give us a bit to turn it off, I assume it is done.
> Read the section about the 430FX Compatibility Mode.
> 
> > > Jean, is v4l-dvb-maintainer the right place to discuss these things?
> > 
> > I thought so. At least I received pertinent answers to my questions,
> > so it seems that I have reached the right persons. But if you think I
> > am abusing this list, I don't want to make anyone angry, so we can
> > either continue this discussion in private, or on another list you
> > think would be more appropriate.
> 
> Trent started CCing video4linux-list and from linux/MAINTAINERS I read
> that v4l-dvb-maintainer is mainly for patches..
> I'm only subscribed to video4linux-list, so I don't know what is customary
> on the maintainer list.
> 
>   Daniel
> 

for me it seems all lists are right and even linux-dvb should be added.

We had quite a lot of reports during the last years concerning bttv
throughput on certain hardware and often there was no quick solution.

It is nice to see how many are still aware of the driver's details.

Such a thing even caused the foundation of the v4l wiki, since David
Liontooth was on some affected bttv hardware mix times back and had to
dig into on which hardware best to start for his upcoming teaching.

Unrelated not yet working saa713x NTSC closed captions were fixed in
following attempts too.

But it sheds also a light on the saa713x restrictions, when DVB-T and/or
DVB-S on hybrid cards is in use already and why in such a case analog
video can only use packed formats at once, but no planar.

A user friendly solution still needs to be found and this here seems to
be a good point to start.

Cheers,
Hermann










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

Re: bttv driver questions

[Daniel Glöckner]

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

Re: bttv driver questions

[Andy Walls]

On Sat, 2008-08-30 at 17:12 +0200, Daniel Glöckner wrote:


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

Modeling, simulation and analysis.  Very cool. :)

Regards,
Andy

>   Daniel
> 


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

Re: bttv driver questions

[Daniel Glöckner]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

On Mon, Sep 01, 2008 at 11:44:53AM +0200, Jean Delvare wrote:
> > It's not that much faster. Of the 250MB/s a lot is lost to overhead,
> > especially when there are mostly short packets.
> 
> The very same is true of the PCI side, isn't it? Out of the 133 MB/s
> of PCI bandwith I don't expect to get more than 100 MB/s effective.

You are right. PCI is only faster for transfers of 4 bytes or less.
The throughput formula for memory writes without waitstates on PCI is
  400/3*x/(x+8) MB
and for memory writes with infinite credit without ECRC on PCIe
  250*x/(x+20) MB,
where x is the burst size and must be a multiple of four in both
protocols.

> Actually there may be up to 8 masters. Latency counter values of 254
> and 20 are rather extreme values.

The equilibrium pattern for latency values between 20 and 254 at a
trigger of 4 in my simulation is the same.

> I guess that your computations assume that the BT878 returns the bus
> control as soon as its FIFO is empty?

Yes

> Not sure what you call "maximum fill"? If the FIFO triggers at 32, I
> have a hard time believing that it always gets the control within the
> next 0.17 µs (2 pixels).

There is an initial phase of about 2000 PCI cycles where the FIFO fill
may be higher (this is not the case for a trigger of 4). Afterwards they
acquire the bus in a uniform pattern and stay below the quoted values.
At a trigger of 32 the bus is idle between requests, so access is granted
immediately.

> Again, I fail to see how we care about the idle cycles. I agree that
> we don't have to pay attention to having  a lot of them, because the
> BT878s are alone on that side of the bridge, but we also don't need
> to maximize the "raw" bus usage. What matters is that the bus can
> take the bandwidth peaks and that the FIFOs do never overflow.

It's not about maximizing the bus usage. I suggest to use a low trigger
to keep the FIFO usage low. The high bus usage is just a side effect,
which can be neglected if the Bt878s are on a secondary bus (and either
the primary bus is faster or the bridge can merge writes).

> Care to share your simulation tool with me? This seems to be a very
> valuable tool for the problem I am trying to solve.

Attached.
Cycle description, FIFO overflows and periodic bus idleness estimations
on stderr. FIFO fill for all masters in every cycle on stdout.

  Daniel

[-- Attachment #2: pcisim.c --]
[-- Type: text/plain, Size: 2891 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

static int busstate;
static int nextbusstate;
static int gnt;
static unsigned long long clk;

#define N 5

static struct master {
  int req;
  int fifofill;
  int trigger;
  int latval;
  int latcnt;
  int phase;
  unsigned long long step; /* fixed point 32 bit mantissa */
  unsigned long long accu;
} masters[N];

static void simulate(int i)
{
  masters[i].fifofill+=masters[i].accu>>32;
  masters[i].accu&=0xffffffff;
  if(masters[i].fifofill>140) {
    fprintf(stderr,"%llu [%i dropped %i]\n",clk,i,masters[i].fifofill-140);
    masters[i].fifofill=140;
  }
  if(busstate==0 && gnt==i && masters[i].fifofill>=masters[i].trigger) {
    nextbusstate=1;
    masters[i].phase=1;
  }
  if(busstate==1) {
    switch(masters[i].phase) {
      case 1:
	masters[i].phase=2;
	masters[i].latval=masters[i].latcnt;
	fprintf(stderr,"%llu %i addr\n",clk,i);
	break;
      case 2:
	masters[i].fifofill--;
	fprintf(stderr,"%llu %i data, %i remaining\n",clk,i,masters[i].fifofill);
    }
    if(masters[i].latval>0)
      masters[i].latval--;
    if(masters[i].phase && (masters[i].fifofill==1 || (!masters[i].latval && gnt!=i)))
      nextbusstate=2;
  }
  if(busstate==2 && masters[i].phase) {
    masters[i].fifofill--;
    fprintf(stderr,"%llu %i final data, %i remaining\n",clk,i,masters[i].fifofill);
    if(gnt==i && masters[i].fifofill>=masters[i].trigger) {
      nextbusstate=1;
      masters[i].phase=1;
    } else {
      nextbusstate=0;
      masters[i].phase=0;
    }
  }
  masters[i].req=(masters[i].fifofill>=masters[i].trigger || (masters[i].phase && nextbusstate==1 && masters[i].fifofill>1));
  masters[i].accu+=masters[i].step;
}

int main()
{
  int i;
  unsigned long long idle;
  int wasactive;
  
  clk=idle=0;
  
  busstate=0;
  gnt=0;
  wasactive=0;
  srandom(time(0));
  for(i=0;i<N;i++) {
    masters[i].req=0;
    masters[i].trigger=4;
    masters[i].fifofill=random()%masters[i].trigger;
    masters[i].latcnt=64;
    masters[i].phase=0;
#define PAL(w) (((unsigned long long)(w)<<31)*3/5200)
#define NTSC(w) (((unsigned long long)(w)<<31)*30/52856)
    masters[i].step=NTSC(640);
    masters[i].accu=random()%masters[i].step;
  }
  while(1) {
    int nextgnt=gnt;
    if(wasactive) {
      for(nextgnt=(gnt+1)%N;nextgnt!=gnt;nextgnt=(nextgnt+1)%N)
        if(masters[nextgnt].req)
          break;
      if(nextgnt!=gnt)
	wasactive=0;
    }
    for(i=0;i<N;i++) {
      printf("%i%c",masters[i].fifofill,i+1==N?'\n':'\t');
      simulate(i);
    }
    gnt=nextgnt;
    if(!busstate && nextbusstate)
      wasactive=1;
    clk++;
    if(!nextbusstate) {
      if(busstate)
	fprintf(stderr,"%llu turnaround\n",clk);
      else {
	fprintf(stderr,"%llu idle\n",clk);
	idle++;
      }
    }
    if(!(clk&511))
      fprintf(stderr,"[%llu bus idle %f%%]\n",clk,100.0*idle/clk);
    busstate=nextbusstate;
  }
  return 0;
}

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

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

Re: bttv driver questions

[Daniel Glöckner]

On Mon, Sep 01, 2008 at 09:26:06PM +0200, Jean Delvare wrote:
> This is because each master never needs its full grant, the FIFO is
> empty before and they return the bus control early. If each master
> was to keep control of the bus for as long as control was originally
> granted, things would be much different. Would it be difficult to
> modify your simulation tool to allow this case?

It is impossible to extend a transaction by an arbitrary number of
cycles without violating the spec. Every DWord must be ready in 8
cycles. When the data rate is below 16.7 MB/s, the next DWord will
not be ready in time.

> I would also like to be able to add an arbitrary number of setup
> cycles at the beginning of every transaction. Your assumption that
> there are no such cycles wasted is a bit optimistic, and I'd like
> to get more realistic figures.

It's not like the bridge has to fetch a cachline from memory.
It just needs to decode the address. Either there are buffers waiting
or it can't accept data (in which case it will probably signal RETRY).
Address decoding is specified as medium DEVSEL timing, which equals
1 wait cycle worst case.

> Which raises a question... do you know if the XIO2000 can merge
> writes?

I don't know. TI support might be able to answer this.

> And do you know how much of a buffer it has?

The XIO2000A FAQ says a PCIe transaction payload can be 512 bytes
maximum. It furthermore says that Intel chipsets accept only transactions
up to 128 bytes. The number of buffers would be interesting, too.
And if the second VC has the same number of buffers...

> The problem I have with low trigger is that it means many short
> transactions, which in turn means small effective bandwidth, and I
> know that in my case we can't have too much bandwidth.

When the bus is loaded, transaction lengths will grow automatically
above the trigger point up to the latency counter value.
The simulation for 5 masters required a minimum latency of 20 even
though the trigger was 4.

> I think your code assumes YUY2 as a capture format, i.e. 2 bytes
> per pixel? I already know that 8 masters can't do that concurrently
> over the same PCI bus, no matter how we tweak the PCI settings. I'll
> have to change the code to assume Y8 as a capture format.

8 masters doing Y8 is less traffic with more FIFOs than 5 masters doing
YUY2. It probably works out of the box.

If grayscale is not what your customer wants, there is a 8 bit color
mode V4L2_PIX_FMT_HI240.

  Daniel

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

Re: bttv driver questions

[Daniel Glöckner]

On Tue, Sep 02, 2008 at 01:05:12PM +0200, Jean Delvare wrote:
> I couldn't find a format for HI24 though, maybe it's not standard
> enough and ffmpeg doesn't support it.

I've written a small program that captures in HI240 and converts to
YCbCr 4:2:0. The output is either PGM as generated by mpeg2dec or Y4M
as expected by the mjpegtools. The HI240 to RGB formula is from
xawdecode.

You can find it at
http://www.stud.uni-hannover.de/~daniel/hi240.c


While skipping through the Fusion 878A datasheet, I found a sentence
which made me realize that the problems associated with switching from
one GNT to another in idle state are not limited to IDSEL stepping.
Inserting a cycle with all GNTs deasserted is required because a device
parked on an idle bus must drive the AD and C/BE# lines. This is not
correctly modeled in the simulation.

  Daniel

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

Re: bttv driver questions

[Daniel Glöckner]

On Fri, Sep 05, 2008 at 02:36:18PM +0200, Jean Delvare wrote:
> > I've written a small program that captures in HI240 and converts to
> > YCbCr 4:2:0. The output is either PGM as generated by mpeg2dec or Y4M
> > as expected by the mjpegtools. The HI240 to RGB formula is from
> > xawdecode.
> 
> I've never heard of PGM nor Y4M. Can either mplayer or ffmpeg decode
> either format?

FFmpeg knows how to deal with both formats.
For Y4M:
ffmpeg -f yuv4mpegpipe -i -
For PGM:
ffmpeg -f image2pipe -vcodec pgmyuv -i -

> This doesn't build for me. Your code makes use of keyword "restricted"
> which I've never seen before and my version of gcc (4.1.2) doesn't
> know about.

"restrict" is C99. Either compile with -std=c99, replace "restrict" with
"__restrict", or delete it completely.

  Daniel

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Trent Piepho]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1251 bytes --]

On Tue, 2 Sep 2008, Jean Delvare wrote:
> Le mardi 02 septembre 2008, Daniel Glöckner a écrit :
> > If grayscale is not what your customer wants, there is a 8 bit color
> > mode V4L2_PIX_FMT_HI240.
>
> I've seen this, and BT878 supports that format. But I don't know how
> to check how it looks like visually... mplayer doesn't seem to

It looks "ok".  I used to use it when I watched tv with overlay and a video
card in 8-bit pseudocolor.  It will probably compress very poorly.  You can
turn dithering on and off, on looks better, but jpeg compress will probably
be much worse with dithering.

> support that pixel format. Apparently ffmpeg forces the format to
> YUV 4:2:0 planar (a pretty bad choice if you ask me), so I can't use

Most codecs operate on planar 4:2:0, so it makes the most sense to request
the right format from the hardware, instead of converting from packed to
planar in software.  ffmpeg doesn't know that DMA of planar formats is
harder for the bt8x8 and that you are running out of PCI bandwidth but
might have lots of memory bandwidth and CPU cycles to use.

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Andy Walls]

On Thu, 2008-08-28 at 16:58 +0200, Jean Delvare wrote:
> Hi Andy,

> In the specific case I am studying, there are 8 BT878 chips, so each
> one definitely can't be considered the only "high bandwith card in
> the system". And it seems to me that latency matters as much as
> bandwith here... A high latency timer on one card will hurt bus
> latency at least as much as bus banwidth as I understand it.
> 
> > Setting latency timers for a system is a balancing act between the needs
> > of individual devices and the system's need for the shared PCI bus to
> > support the maximum anticipated burst or sustained activity on the bus
> > by all the devices that could be active at once.
> 
> We agree on that. With 8 BT878 chips, the problem is that both bus
> latency and bus bandwidth are potentially problematic. So the balance
> isn't an easy one to find. Which is exactly why I am asking all these
> questions.

No it probably isn't easy.  With a static analysis (spreadheet),
assuming worst case conditions, you will likely end up with the
conclusion that the PCI bus can't handle the worst case load, so you'll
need to model with higher fidelity and different assumptions than worst
case.

Consistently meeting the real-time communications needs of the 8 BT878's
and the disks on the PCI bus could well be impossible with (the very
common) round robin arbiters.

You may find this thesis paper interesting:

http://os.inf.tu-dresden.de/papers_ps/schoenberg-phd.pdf

Which addresses the problem by proposing a different arbiter.


This, much shorter paper:

http://www.irisa.fr/manifestations/2004/wcet2004/Papers/Stohr.pdf

proposes that the Master Enable bit of devices be switched on and off to
ensure deterministic times across the bus.  (I'm not sure if I'd want to
do that though...)


Regards,
Andy

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Trent Piepho]

On Fri, 29 Aug 2008, Andy Walls wrote:
> On Thu, 2008-08-28 at 16:58 +0200, Jean Delvare wrote:
> Consistently meeting the real-time communications needs of the 8 BT878's
> and the disks on the PCI bus could well be impossible with (the very
> common) round robin arbiters.

Trying to capture 8 full resolution streams on one PCI bus is probably
impossible, but with a NIC or HD controller on the same bus, forget it.

You'd need to get a chipset with multiple busses and put the capture card
on its own bus.

Or get something like viewcast's multi-bttv cards that use a PCI to PCI-E
bridge.

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

Re: [v4l-dvb-maintainer] bttv driver questions

[Daniel Glöckner]

On Fri, Aug 29, 2008 at 03:23:16PM -0700, Trent Piepho wrote:
> Or get something like viewcast's multi-bttv cards that use a PCI to PCI-E
> bridge.

The DVC-5215 card Jean mentioned in his first post is a PCIe card.
The bridge visible on the card must be a TI XIO2000A with external
PCI arbiter. It allows to tweak some QoS parameters for PCIe traffic
that might be helpful.

Btw., for cards with PCI-PCI bridge the latency counter of the bridge
on the main bus should be set to a high value to give it an advantage
to flush its buffers.

  Daniel

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

Re: bttv driver questions

[Daniel Glöckner]

On Sat, Aug 30, 2008 at 09:54:18AM +0200, Jean Delvare wrote:
> But I have to admit that I'm not really sure how the different PCI
> Express slots relate to each other. Does each slot have its own bus
> and thus bandwidth? Or is the same PCI Express bus shared by all
> slots as is usually the case for PCI?

Each slot has the full bandwidth, but the receiving end can stop the
transmitter if it has no space left in its buffer.

> And what about the motherboards
> which have both PCI and PCI Express slots/on-board devices?

There will be a PCI-PCIe bridge. Both busses will be independent as
long as they don't exchange data.

> I see no reference to the XIO2000 in the kernel source tree. If I am
> supposed to tweak QoS parameters, how would I do that?

Having read the XIO2000 datasheet I would try to use the second VC with
a higher traffic class for access from the PCI bus to memory.
The configuration of the bridge should be modifiable with setpci.
Other chips might need tweaking too for this to have effect.

> According to "lspci -vv" the latency timer of the bridge is set to 0.

The latency timer is meaningless for PCIe.
The secondary, PCI bus has a separate latency timer, but I wouldn't set
that one to a high value.

> As far as I remember, all PCI-PCI bridges I've ever seen always had
> their latency timer set to 0.

0 is the default for a bridge after reset.

  Daniel

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