Hi, I'm having a real bad time with this, I've just noticed the strangest thing: The product id on the box changes when loading the firmware: from the initial vid:pid of 03f3:008b to 03f3:008c I guess the same also happens for 03f3:0087 to 03f3:0088 This is way the original firmware loader uses the inital pid in the configuration and the driver module sets the later in the device tab: udev loads the firmware, the pid changes and the driver module gets loaded. So if If I want the driver to request the firmware I have to set both pids and end up with two device entries, the first of which will never get removed since the inital pid is no more :D Is there any solution/ideas on how to handle this behaviour? Also I exctrated the firmware into a ihex file, I see that existing modules use several diferent types of firmware binary files (fw, bin) obtained from the ihex file, some even use ihex directly (request_ihex_firmware), is there a optimal format for this? Regards, Paulo 2009/12/18 Mauro Carvalho Chehab <maurochehab@xxxxxxxxx>: > Devin Heitmueller wrote: >> On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis <pj.assis@xxxxxxxxx> wrote: >>> Hi, > >>> Is there any simpler/standard way of handling these firmware uploads ? >>> >>> Regards, >>> Paulo >> >> Hi Paulo, >> >> I would start by looking at the request_firmware() function, which is >> used by a variety of other v4l cards. > > Yes. Basically, you store all firmwares you need on /lib/firmware and > request_firmware loads them when the driver is loaded. > > You don't need to add any extra udev magic for it to work, since there are > already some userspace programs that handle firmware requests when using > request_firmware(). > > Cheers, > 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
