Em 23-04-2012 19:51, Konstantin Dimitrov escreveu: > Antti, i already commented about ds3103 drivers months ago: > also, why Montage tuner code should be spitted from the demodulator > code? is there any evidence that any Montage tuner (ts2020 or ts2022) > can work with 3rd party demodulator different than ds3000 or ds3103? This has nothing to do with Montage devices, but with the way we write those drivers in Kernel. There are _several_ examples where the driver for a single silicon were turned into more than one driver. The biggest examples are the SoC chips, that are transformed into a large series of drivers. Another example is the cx88 driver: due to technical reasons, it was splitted into 4 drivers, one for each different PCI ID exported by it. The cx2341x driver is also an interesting example: while it used to be for a separate chip, the cx2341x functions are now part of IP blocks on newer Conexant chipsets. Those single chips require two drivers to work (cx2341x and the associated media PCI bridge driver). Looking into tuners, there are the tda18271 family of devices, with are supported by several drivers: tda827x, tda8290 and tda18271-fe, depending on how the actual device is mounted. Eventually, the actual tuner may also have a tda9887 inside it. So, there's nothing wrong on splitting it on separate drivers. In a matter of fact, we strongly prefer to have tuners separate from demods. Having them together can only be justified technically, if there are really strong reasons why they should be at the same driver. I probably missed this at my review for ds3000 (that's why it ended by being merged), but, on the review I did on it (accidentally due to m88ds3103 patchset review), it is clear that the tuner has actually a different I2C address (0x60) than the demod, and it is indeed a separate device. Sorry for slipping into it. Anyway, now that this is noticed, tuner and demod drivers should be split, especially since there are some patches floating around to add support for ds3103. As I said before, the right thing to do is: 1) split ds3000 from ts2020 at the existing driver; 2) add support for the newer chips (ds3103/ts2022) to the ds3000 and ds3103 drivers. 3) test if the patches adding support for the newer chips didn't break the support for existing hardware. My proposal is that tasks (1) and (3) should be handled by you. As Max wants to add support for some devices based on ds3103/ts2022, IMO, he can do the patches for (2) in a way that they would be acceptable by you, as the driver maintainer for ds3000/ts2020, testing with their devices. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
