Google
  Web www.spinics.net

Re: bttv driver questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Daniel,

Le mardi 02 septembre 2008, Daniel Glöckner a écrit :
> 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.

Ah, one more thing I didn't know. Thanks for the info :)

> When the data rate is below 16.7 MB/s, the next DWord will 
> not be ready in time.

Well, actually, NTSC 640x480 in YUY2 format peaks at 24.5 MB/s if
I'm not mistaken. That's more than 16.7 MB/s so the BT878 could keep
control of the bus and transmit slowly. I'm not saying it does, just
that it probably could. Without a PCI bus analyzer I don't think we
can rule it out.

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

OK.

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

Given that the word "merge" doesn't appear anywhere in the datasheet,
I'd guess not.

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

OK, I get the idea now.

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

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
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
it to test either. If someone could suggest a tool which would let me
capture the video in a given pixel format and watch it afterwards,
I'd be grateful.

Anyway, my customer are encoding their video stream in MJPEG
afterwards, and I fear that MJPEG compression will look bad after
dithering. So I didn't even suggest that possibility yet.

-- 
Jean Delvare
Suse L3

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


[Linux Media]     [Older V4L]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [SSH]     [Linux USB]

-->
Add to Google Powered by Linux

Google PageRank Checking tool