> Vassili Leonov wrote:
> > We're using ZR36067 - much better chip. And MJPEG codec is ZR36060.
> >
> > And for my case bandwisth is only:
> > 60 fields/sec * 720 pix/line * 240 lines * 2 bytes/pixel (4:2:2)
> > ---------------------------------------------------------------- = 6Mb/sec
> > 3 compression
> >
> > But I can set comression to 6 if needed. I can't set it less then 3 that is.
> > I can set it to 30 if I'm really bad.
> >
> > So, you think that 6Mb/sec would compete with memcp_tofs?
I completely ignore how the thing works, but speaking about PCI traffic,
if the code accesses PCI memory ranges from the the CPU, then single DWORD
transactions will have the following maximum througput:
PCI write: 4 cycle min
PCI read: 5 cycles min (4+1 turn-around cycle after address phase to
avoid contention on BUS lines that have to be
furtherly driven by the target)
For DWORD at a time access, bandwidth is no more that:
- 33 MB/s for write.
- 26 MB/s for read.
If for WORD and BYTE access, the bridge will use single PCI transactions
without coalescing nor prefetching, then you must divide the bandwidth
accordingly, For example:
- 13 MB/s for 16 bit Word read.
All the above are maxima.
> Yes. (My -=*guess*=- is that the CPU can overwhelm the memory
> interface. So the CPU gets "stopped", and the PCI master gets a
> chance. First thing it does, is write to the memory again. So the
> burst transfer gets aborted, and the CPU gets a chance again. Lo and
> behold: more memory writes. This way the PCI master would only get to
> write a single word at a time, which is very inefficient.)
If the host bridge uses optimizations for accesses from the BUS, then
bandwidth will not be wasted. (Data prefetching, posted write, ...)
Since we may think that the CPU has some higher priority than the
PCI BUS to gain access to the memory, if you are using algorithms that are
not well cached, then the memory bandwidth as seen from the PCI BUS may be
very low even when using reasonnable bursts.
> But, in a later message, you say you don't use the VIDEO pipeline for
> this datastream, but the Codec pipline.
If these pipelines are read from the CPU, then BUS bandwidth have chance
to be wasted a LOT (13MB/s bandwidth for 16 bit read at a time using
single data phase PCI transactions per 16 bit word).
> The Video pipeline is designed for 0 to 20Mb (Warning: wild guess!)
No guess needed for the maximum if we know how data is accessed through
the PCI.
> per second datastreams. The codec pipeline is designed for much slower
> datastreams. So it has less "high performance" features. That's from
> the point-of-view of the PCI interface chip.
If it needs to be read from the CPU and it is slow, then it is just a
resource-waster.
> You suggested to wire the "dataerr" line to a general IRQ line on the
> '67. That's not neccesary, provided you've wired the '60 JIRQ line to
> somwhere where you can catch it. (Section 6.11.1 of the '60 datasheet).
>
>
> You said that there was a significant buffer. In the '60 I see a 512
> byte buffer. That's quite large. The question is, is the '67 capable
> of stopping the data-transfer there, if its FIFO is full?
Catching data overrun in order to gracefully recover is a good point, but
a video input device that experience data overrun is highly broken in my
opinion anyway. If you want to tune buffering, then you must have some
accurate estimations of what is actually happens in the system.
BTW, large buffering my hide real problems, doing right buffering is the
way to go.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/