Am 19.02.2013 21:03, schrieb Mauro Carvalho Chehab: > Em Tue, 19 Feb 2013 20:45:21 +0100 > Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: > >> Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab: >>> Em Tue, 19 Feb 2013 19:45:29 +0100 >>> Frank Schäfer <fschaefer.oss@xxxxxxxxxxxxxx> escreveu: >>> >>>>> I don't like the idea of merging those two entries. As far as I remember >>>>> there are devices that works out of the box with >>>>> EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can break >>>>> the driver for them. >>>> As described above, there is a good chance to break devices with both >>>> solutions. >>>> >>>> What's your suggestion ? ;-) >>>> >>> As I said, just leave it as-is (documenting at web) >> That seems to be indeed the only 100%-regression-safe solution. >> But also _no_ solution for this device. >> A device which works only with a special module parameter passed on >> driver loading isn't much better than an unsupported device. > That's not true. There are dozens of devices that only work with > modprobe parameter (even ones with their own USB or PCI address). So the fact that we handle plenty devices this way makes the situation for the user better ? ;-) Not really ! > The thing > is that crappy vendors don't provide any way for a driver to detect what's > there, as their driver rely on some *.inf config file with those parameters > hardcoded. > > We can't do any better than what's provided by the device. > >> It comes down to the following question: >> Do we want to refuse fixing known/existing devices for the sake of >> avoiding regression for unknown devices which even might not exist ? ;-) > HUH? As I said: there are devices that work with the other board entry. > If you remove the other entry, _then_ you'll be breaking the driver. Which devices _with_audio_support_ are working with EM2860_BOARD_SAA711X_REFERENCE_DESIGN ? AFAIK, the existence of such a device is pure theory at the moment. But the Easycap DC-60 is reality ! > >> I have no strong and final opinion yet. Still hoping someone knows how >> the Empia driver handles these cases... > What do you mean? The original driver? The parameters are hardcoded at the > *.inf file. Once you get the driver, the *.inf file contains all the > parameters for it to work there. If you have two empia devices with > different models, you can only use the second one after removing the > install for the first one. Are you sure about that ? That's the worst case. > >>> or to use the AC97 >>> chip ID as a hint. This works fine for devices that don't come with >>> Empiatech em202, but with something else, like the case of the Realtek >>> chip found on this device. The reference design for sure uses em202. >> How could the AC97 chip ID help us in this situation ? >> As far as I understand, it doesn't matter which AC97 IC is used. >> They are all compatible and at least our driver uses the same code for >> all of them. > The em28xx Kernel driver uses a hint code to try to identify the device > model. That hint code is not perfect, but it is the better we can do. > > There are two hint codes there, currently: > 1) device's eeprom hash, used when the device has an eeprom, but the > USB ID is not unique; > > 2) I2C scan bus hash: sometimes, different devices use different I2C > addresses. ??? Again, how can the AC97 chip ID help us in this situation ? You just described the current board hint mechanism which clearly fails in this case. > >> So even if you are are right and the Empia reference design uses an EMP202, >> EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with other >> AC97-ICs, too. > The vast majority of devices use emp202. There are very few ones using > different models. > > The proposal here is to add a third hint code, that would distinguish > the devices based on the ac97 ID. I already explained why this is a potential source for regressions, too. Regards, Frank > >> We should also expect manufacturers to switch between them whenever they >> want (e.g. because of price changes). > Yes, and then we'll need other entries at the hint table. > > 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
