Andrew de Quincey wrote:
It's also not acceptable to need to register a driver id in a common header file. This makes it impossible to write external drivers for a particular hardware without patching the kernel source tree (one of the design criterias for both the v3 and the v4 API -- nearly all STB vendors provide binary-only firmwares and BIOS libraries which are incompatible with the GPL and can't get linked statically into the kernel).On Friday 10 Sep 2004 10:13, Andrew de Quincey wrote:On Thursday 09 Sep 2004 23:54, Gerd Knorr wrote:The cx88 however, sets these to "cx88[0]" - which is unfortunately not useful for the above purpose - and theres no other way of doing it.We should add one then. For analog TV there is the tuner_type field which is passed to tuner.o using some ->command() call. We can (and IMHO should) do that for digital tv cards as well, just matching the name of the card is a bad idea. The cx88 driver can easily figure more details on the card if needed. For analog tv thats actually needed as for example the hauppauge wintv cards may have have different tuners. cx88 can figure that by checking the eeprom with the config info, tuner.o can't do that ...static int dvb_register(struct cx8802_dev *dev) + strlcpy(dev->core->i2c_adap.name,cx88_boards[dev->core->board].name,siz eo f(dev->core->i2c_adap.name));No way. That simply isn't the right place to mess with the name of the i2c device. And as mentioned above IMHO messing with the name for configuration is a bad idea in the first place.+ result = dvb_register_adapter(&dev->core->dvb_adapter, cx88_boards[dev->core->board].name,Same for this one.I suggested adding a field like your "board" identifier to the DVB adapters months ago - people rejected it. Therefore I have to use the device name.
The way I would see it working would be for each piece of hardware to supply a list of the IDS of frontends/tuners drivers it expects to see in its init function. The i2c probing code then only tests those. So the hardware driver is free to probe EEPROMs or whatever to determine its frontend (if it can) and simply supply the id of the one it has chosen, or a list if it cannot.
Of course this would mean all i2c devices had a separate id - currently all the DVB ones are defined to be "I2C_DRIVERID_EXP2".
Maybe this should be extended for all i2c devices? I mean, surely this must happen with other devices as well - simply blasting all i2c drivers when a bus appears isn't really feasible with the number of devices now supported.
A thought for the future: all DVB frontend chips have a tuner i2c device associated with them.nope, that's not true. Motorola and Broadcom tuners are often controlled vie SPI or a 3-wire bus, sometimes also a 8-bit parallel bus. Microtune announced a single-chip tuner/demod a while ago, I have no idea how this is controlled.
Currently we just use probing to identify which tuner specifically is used - but looking at Steve's code shows that this can be probably determined EEPROMs as well. Unfortunately the frontend drivers are two devices in one (demod+tuner PLL) so (ideally) we'd want to supply a sub-id as well... Or we could split the demod and PLL up into separate code -
but that might be more trouble that its worth without Holger's userspace library idea.a userspace library?!? beware!!!