Hi, Am Montag, den 09.11.2009, 09:37 -0200 schrieb Mauro Carvalho Chehab: > Em Mon, 09 Nov 2009 03:02:49 +0100 > hermann pitton <hermann-pitton@xxxxxxxx> escreveu: > > > > > Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab: > > > Em Mon, 09 Nov 2009 00:32:29 +0100 > > > hermann pitton <hermann-pitton@xxxxxxxx> escreveu: > > > > > > > > I agree. An interesting case happens with devices that uses tda10046 DVB demods. > > > > > They have the firmware stored internally on their eeprom. Those firmwares can be > > > > > replaced by a different version loaded in ram, but, in general, they work > > > > > properly with the eeprom one. So, even having the firmware load code there, > > > > > the firmware at /lib/firmware is optional. > > > > > > > > Mauro, that could lead to some misunderstanding of the current use > > > > conditions, at least on saa7134. > > > > > > > > Minor annotations, the tda10046 does not store firmware internally, but > > > > there are cards which have an extra eeprom to store such firmware. > > > > > > > > If such a firmware eeprom is found and correctly configured, the driver > > > > in all cases will load the firmware from that eeprom and all other > > > > firmware in /lib/firmware is ignored. > > > > > > > > If not, the firmware will be loaded from /lib/firmware. > > > > > > > > For all what I know, firmware revisions 26 and 29 are both valid > > > > "enough", correspondents to what we can load either from TechnoTrend or > > > > LifeView with the getfirmware script, and might be either stored in an > > > > extra eeprom or loaded from host/file. > > > > > > > > Prior revisions had issues with missing freqs, in what combination ever. > > > > > > > > We also can't totally exclude, given the whole mass of such, that in > > > > some cases firmware eeproms might exist on some boards, but are not > > > > correctly configured and load from host only because of that. > > > > > > > > The tendency seen overall is that competitors save the few cents for an > > > > extra firmware eeprom these days ... > > > > > > Yes, I know. I have myself a Cardbus device with such eeprom (I think it has > > > revision 29 stored at the eeprom). > > > > > > The point is that it is not mandatory for such devices to have a firmware > > > at the filesystem for the device to work. So, a static indication that > > > devices with tda10046 need firmware is wrong, since some devices don't need > > > it. > > > > There are of course lots of devices needing the firmware mandatory at > > the file system. I try to tell that it is not a mistake, in case the > > device has no firmware on an extra eeprom, to store latest revision > > in /lib/firmware. Or tell me better ... > > > > But also, OEMs a little bit more motivated on new hardware will not > > count the costs of an extra firmware eeprom, if being first in having > > substantial amounts of chips and get a good deal for such. But that was > > the past. > > > > > Cheers, > > > Mauro > > > > Else I do totally agree. > > > > I do just point to some ambiguous conditions we should stay aware of. > > > > It is very unlikely that we can "talk" them away. > > > > Do we have all firmware loaded from eeproms possibly existing on cards > > is only one minor question. > > > > Maybe we miss some. > > > > Should we not even better avoid such, since still no official update for > > firmware eeprom flashing? > > > > To restore the bridge eeprom we seem to be not such bad now, but also > > the reasons for a possible corruption are far from clearly identified in > > case we should be involved in it. > > > > Despite of legal issues, we should have the latest revision of the > > tda10046 firmware at the host. As said, those having it at an extra > > eeprom will load it anyway from there. > > Hermann, maybe you missed the point here: the driver will keep dynamically > loading the modules at the right place, for the devices that really need > firmwares to run. > > The issue I'm seeing is that the MODULE_FIRMWARE series of patches is adding an > static meta-tag that indicates that the devices associated with a driver will > need one or more firmwares, with the specified names at the tag. > > While it is not clear on Ben's proposal how those userspace tools will be, > considering that he is concerning about initramfs and that there are devices > (like for example rtl8192u) that needs several firmwares to run, in order to > properly work for initramfs, the tools should assume that all firmwares using > the tag will be needed for that device, to be sure that the machine won't hang > during the boot. > > In the case of the v4l-dvb devices, the firmware needs are dynamic. > > For example, in the case of tuner-xc2028, you need _OR_ xc3028 _OR_ xc3028l > firmwares (and, if considering tm6000 devices, you may need firmware version 1 > for older devices). In the case of tda10046, some devices will need a firmware, > while others won't need. > > So, you'll only know what firmware is really needed at runtime. > > An alternative for a static table would be to associate the firmware needs > to the USB and PCI ID's, but even the USB/PCI ID tables will also have some > troubles. For example, the flexcop driver supports 7 different versions of a > device, all sharing the same PCI ID, but each version requires a different > frontend. The driver only knows what frontend is needed at runtime, after > probing the i2c bus at the device. sorry, if I did not follow up close enough. The flexcop driver is really a good example. > So, the main point here is that a tag like this is useless for the devices under > drivers/media. The only way to really know for sure what firmware is needed on > a particular hardware is to catch the firmware requests. If such check is > really needed, the better is to add a hook at the userspace, catching all > requests for firmwares for the detected hardware. Such usage will get 100% of > the cases and won't require any kernel changes. > > That's said, I can fully understand the utility of that having a tag like that > for block and network devices that needs to load a firmware during boot time, > at initramfs. As you need to access the hard disk or the network in order to > mount the file system, having the proper firmware there is mandatory. > > Except for those kind of devices, we shouldn't be adding MODULE_FIRMWARE to > other random devices, especially where the firmware requirements cannot be > specified by a static rule. > > Cheers, > Mauro I for sure don't vote for having v4l-dvb firmware at boot available. My maybe a little narrowed view is focused on the question, if we can have latest tda10046 firmware at /lib/firmware and if there are any cases known, like on other drivers, not to have it there. If there are no known issues with latest, we should ask Philips/NXP if we are allowed to distribute it with the kernel. Cheers, Hermann -- 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
