[RFC] Hybrid cards was Re: [linux-dvb] Re: backwards compatability
-was- actual cvs broken?
abraham.manu at gmail.com
Thu Nov 3 23:17:24 CET 2005
Hartmut Hackmann wrote:
> Hi, all
> I don't know how bt878 handles the transport stream, maybe it does some
> funny thing similar to the saa7146. But speaking from saa713x point of
> view, there is only little conflict:
> The chips have a separate transport stream interface and the interface
> occupies a rarely used DMA channel. The chips can stream analog video,
> sound and dvb parallel, only the planar mode is impossible.
Well in most cases this does not create too much of hassles, but for the
878, one can have either DVB/ATSC or CVBS/Analog at a time. You cannot
have both of them simultaeneously though. It would be nice if you don't
> Most of the cards available are hybrid ones, they can do analog and dvb.
> Many share a single tuner. this of corse causes a conflict. But besides
> this even parallel analog and dvb works in linux.
> So - where do these cards belog?
This is a real question, which baffled me, since it is incomplete the
way as it is in either V4L or DVB. But that is not my issue.
> I think we should leave things as they are. Most of the driver code is
> initializing and handling of the PCI bridge, setting up and handling
> the DMA, I2c etc. This would be needed in both, v4l and dvb and at least
> be very similar. But even if we had it duplicated, handling hybrid cards
> would be extremely difficult because we can have the PCI code only
> once in this case.
Handling the PCI code too is okay. The real issue here is that the
actual control of the Analog part is not with the 878 but with the MCU
which is a part of DVB itself.
> But this can be different for bt8xx and cx88.
You can imagine something like this.
| tuner |
| MCU |------- F/W control of Analog + DVB + CVBS + Audio + NTSC + ATSC
| gpio + i2c
| |--------- CVBS
| 878 |--------- Audio
| PCI bus
The controlling device (the device what i am working upon) is the dst.
This is part of the dvb-kernel. the 878 part is partly in dvb-kernel and
partly in V4L. Probably i need to extend dvb-bt8xx or include bttv
headers which are in V4l to the dst in dvb-kernel. I was wondering
whether this would be a sane approach. But for the V4L API to control
the MCU, that would mean including the relevant header/callbacks
somewhere else in V4l.
To me it looks like a bit of mess, if someone has a better suggestion,
that would be helpful.
> Best regards
> Manu Abraham wrote:
>> Edgar Toernig wrote:
>>> Speaking about the BT878 based cards, the connection is already
>>> pretty loose. The BT878 has two functional blocks - video capture
>>> and audio capture which show up as two different PCI devices.
>>> The bttv driver handles the video capture part and works fine
>>> without the dvb-driver. The DVB "receiver" is connected to the
>>> audio part. Unfortunately, the DVB receiver usually needs the I2C
>>> bus and some GPIO pins which are both part of the "video"-function
>>> of the BT878. So the DVB driver has to contact the bttv driver
>>> whenever it wants access to these pins.
>> There can be even more complicated issues. Imagine the bttv(878) is
>> connected to an ASIC. This ASIC controls both Analog and Digital.
>> but the pronounced operations are all DVB. The analog operations are
>> quite minimal. something like mute audio etc. Now it would look like
>> the DVB parts is now handling the analog part too. For example how
>> would this mute_audio be called, since there is no mute audio under
>> So where should this module belong ?
>> If someone comments on this, i would be interested in havinging a
>> feedback on this. At present i have a few cards that have DVB-T +
>> CVBS on the dst, as well ATSC + NTSC.
More information about the linux-dvb