Brooktree Bt878: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 7: Line 7:
It supports both 'software' and 'hardware' [[i2c Protocol]]s. Software means that you write to the SCL & SDA lines directly and the CPU/driver has to time everything itself. Hardware means you give it a byte or two to read/write and it goes away and does that and gets back to you with an interrupt when it's done. Unfortunately the hardware i2c does not support writing just one byte (the address byte but no data) so you cannot do safe write or read probes of i2c client addresses (it could confuse an i2c client that does not have sub addresses - e.g. a [[PLL]]).
It supports both 'software' and 'hardware' [[i2c Protocol]]s. Software means that you write to the SCL & SDA lines directly and the CPU/driver has to time everything itself. Hardware means you give it a byte or two to read/write and it goes away and does that and gets back to you with an interrupt when it's done. Unfortunately the hardware i2c does not support writing just one byte (the address byte but no data) so you cannot do safe write or read probes of i2c client addresses (it could confuse an i2c client that does not have sub addresses - e.g. a [[PLL]]).


''We should mention here that i2c probing on a per-address basis is inale since most DVB i2c devices have configurable i2c addresses (not to mention that the basic i2c spec only allows 7-bit addresses, so in theory only 127 different devices would be allowed on the market). unfortunately Linux kernel-i2c folks and their addicted fans don't really like the idea of direct access to the i2c Bus like it is common in [[STB]]s and mobile devices. So this "missing feature" or "bug" of the BT878 is not really a chip design flaw but more a misinterpretation of the [[I2c Protocol]] Specification of the kernel-i2c folks and has been the cause of some mail threads fighted with religious persuasion. See the relevant section in [[Philosophy and holy Wars]].''
''We should mention here that i2c probing on a per-address basis is inale since most DVB i2c devices have configurable i2c addresses (not to mention that the basic i2c spec only allows 7-bit addresses, so in theory only 127 different devices would be allowed on the market). unfortunately Linux kernel-i2c folks and their addicted fans don't really like the idea of direct access to the i2c Bus like it is common in [[STB]]s and mobile devices. So this "missing feature" or "bug" of the BT878 is not really a chip design flaw but more a misinterpretation of the [[I2c Protocol]] Specification of the kernel-i2c folks that had been the cause of some mail threads fighted with religious persuasion in the past. See the relevant section in [[Philosophy and holy Wars]] or check the linux-dvb mailing list archives.''


After the [[Brooktree Corporation]] had been aquired by [[Conexant Systems, Inc.]], a version of this chip called ''Conexant Fusion 878'' has been released.
After the [[Brooktree Corporation]] had been aquired by [[Conexant Systems, Inc.]], a version of this chip called ''Conexant Fusion 878'' has been released.

Revision as of 21:09, 23 September 2004

Started off life as a good old analogue audio+video chip in the BT848 days, used by stacks of different cards (just look at video4linux). When DVB came along, I guess the manufacturers of the TV cards were used to working with this chip so the digital audio input interface was co-opted to take the MPEG2 transport stream.

It has a pretty nice programmable DMA engine. You basically build a very simple RISC program (very RISC - has about 8 instructions) that copies data between the BT848 and your RAM. Like the SAA7146-based DVB PCI card designs this chipset misuses the analog video input of the chip to sample the MPEG2 Transport Stream in video lines of the framebuffer, programming this is kind of a pain. The original idea behind it was that when you had a window obscured on your display, or you wanted to crop a bit of the input image, you could build a RISC program that just copied the parts of the video lines you wanted, and thus not waste any PCI bandwidth.

The BT878 provides one function each for Video and Audio onto the PCI bus. The two functions have different memory mappings although they have many similar registers - e.g. the i2c bus is only available via the video function and the DVB stream is only available via the audio function. ('function' is a PCI term ... most PCI devices have only one of them...)

It supports both 'software' and 'hardware' i2c Protocols. Software means that you write to the SCL & SDA lines directly and the CPU/driver has to time everything itself. Hardware means you give it a byte or two to read/write and it goes away and does that and gets back to you with an interrupt when it's done. Unfortunately the hardware i2c does not support writing just one byte (the address byte but no data) so you cannot do safe write or read probes of i2c client addresses (it could confuse an i2c client that does not have sub addresses - e.g. a PLL).

We should mention here that i2c probing on a per-address basis is inale since most DVB i2c devices have configurable i2c addresses (not to mention that the basic i2c spec only allows 7-bit addresses, so in theory only 127 different devices would be allowed on the market). unfortunately Linux kernel-i2c folks and their addicted fans don't really like the idea of direct access to the i2c Bus like it is common in STBs and mobile devices. So this "missing feature" or "bug" of the BT878 is not really a chip design flaw but more a misinterpretation of the I2c Protocol Specification of the kernel-i2c folks that had been the cause of some mail threads fighted with religious persuasion in the past. See the relevant section in Philosophy and holy Wars or check the linux-dvb mailing list archives.

After the Brooktree Corporation had been aquired by Conexant Systems, Inc., a version of this chip called Conexant Fusion 878 has been released.