Re: bttv driver questions

["Daniel Glöckner" <daniel-gl@gmx.net>]

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