* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name [not found] <E1MiTfS-0001LQ-SU@mail.linuxtv.org> @ 2009-09-04 18:05 ` Michael Krufky 2009-09-07 5:10 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Michael Krufky @ 2009-09-04 18:05 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List Mauro, This fix should really go to Linus before 2.6.31 is released, if possible. It also should be backported to stable, but I need it in Linus' tree before it will be accepted into -stable. Do you think you can slip this in before the weekend? As I understand, Linus plans to release 2.6.31 on Saturday, September 5th. If you dont have time for it, please let me know and I will send it in myself. Thanks & regards, Mike Krufky On Tue, Sep 1, 2009 at 9:45 AM, Patch from Hans Verkuil<hg-commit@linuxtv.org> wrote: > The patch number 12613 was added via Hans Verkuil <hverkuil@xs4all.nl> > to http://linuxtv.org/hg/v4l-dvb master development tree. > > Kernel patches in this development tree may be modified to be backward > compatible with older kernels. Compatibility modifications will be > removed before inclusion into the mainstream Kernel > > If anyone has any objections, please let us know by sending a message to: > Linux Media Mailing List <linux-media@vger.kernel.org> > > ------ > > From: Hans Verkuil <hverkuil@xs4all.nl> > cx25840: fix determining the firmware name > > > Depending on the model there are three different firmwares to choose from. > Unfortunately if a cx23885 is loaded first, then the global firmware name > is overwritten with that firmware and if ivtv is loaded next, then it > tries to load the wrong firmware. In addition, the original approach would > also overwrite any firmware that the user specified explicitly. > > Priority: normal > > Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> > CC: Jarod Wilson <jarod@wilsonet.com> > > > --- > > linux/drivers/media/video/cx25840/cx25840-firmware.c | 35 ++++++----- > 1 file changed, 22 insertions(+), 13 deletions(-) > > diff -r f69cb015dc77 -r 36a81289010d linux/drivers/media/video/cx25840/cx25840-firmware.c > --- a/linux/drivers/media/video/cx25840/cx25840-firmware.c Mon Aug 31 22:21:04 2009 +0200 > +++ b/linux/drivers/media/video/cx25840/cx25840-firmware.c Mon Aug 31 22:57:52 2009 +0200 > @@ -24,10 +24,6 @@ > > #include "cx25840-core.h" > > -#define FWFILE "v4l-cx25840.fw" > -#define FWFILE_CX23885 "v4l-cx23885-avcore-01.fw" > -#define FWFILE_CX231XX "v4l-cx231xx-avcore-01.fw" > - > /* > * Mike Isely <isely@pobox.com> - The FWSEND parameter controls the > * size of the firmware chunks sent down the I2C bus to the chip. > @@ -41,11 +37,11 @@ > > #define FWDEV(x) &((x)->dev) > > -static char *firmware = FWFILE; > +static char *firmware = ""; > > module_param(firmware, charp, 0444); > > -MODULE_PARM_DESC(firmware, "Firmware image [default: " FWFILE "]"); > +MODULE_PARM_DESC(firmware, "Firmware image to load"); > > static void start_fw_load(struct i2c_client *client) > { > @@ -66,6 +62,19 @@ > cx25840_write(client, 0x803, 0x03); > } > > +static const char *get_fw_name(struct i2c_client *client) > +{ > + struct cx25840_state *state = to_state(i2c_get_clientdata(client)); > + > + if (firmware[0]) > + return firmware; > + if (state->is_cx23885) > + return "v4l-cx23885-avcore-01.fw"; > + if (state->is_cx231xx) > + return "v4l-cx231xx-avcore-01.fw"; > + return "v4l-cx25840.fw"; > +} > + > static int check_fw_load(struct i2c_client *client, int size) > { > /* DL_ADDR_HB DL_ADDR_LB */ > @@ -73,11 +82,13 @@ > s |= cx25840_read(client, 0x800); > > if (size != s) { > - v4l_err(client, "firmware %s load failed\n", firmware); > + v4l_err(client, "firmware %s load failed\n", > + get_fw_name(client)); > return -EINVAL; > } > > - v4l_info(client, "loaded %s firmware (%d bytes)\n", firmware, size); > + v4l_info(client, "loaded %s firmware (%d bytes)\n", > + get_fw_name(client), size); > return 0; > } > > @@ -97,26 +108,24 @@ > const struct firmware *fw = NULL; > u8 buffer[FWSEND]; > const u8 *ptr; > + const char *fwname = get_fw_name(client); > int size, retval; > int MAX_BUF_SIZE = FWSEND; > u32 gpio_oe = 0, gpio_da = 0; > > if (state->is_cx23885) { > - firmware = FWFILE_CX23885; > /* Preserve the GPIO OE and output bits */ > gpio_oe = cx25840_read(client, 0x160); > gpio_da = cx25840_read(client, 0x164); > } > - else if (state->is_cx231xx) > - firmware = FWFILE_CX231XX; > > if ((state->is_cx231xx) && MAX_BUF_SIZE > 16) { > v4l_err(client, " Firmware download size changed to 16 bytes max length\n"); > MAX_BUF_SIZE = 16; /* cx231xx cannot accept more than 16 bytes at a time */ > } > > - if (request_firmware(&fw, firmware, FWDEV(client)) != 0) { > - v4l_err(client, "unable to open firmware %s\n", firmware); > + if (request_firmware(&fw, fwname, FWDEV(client)) != 0) { > + v4l_err(client, "unable to open firmware %s\n", fwname); > return -EINVAL; > } > > > > --- > > Patch is available at: http://linuxtv.org/hg/v4l-dvb/rev/36a81289010d614758a64bd757ee37c8c154ad4b > > _______________________________________________ > linuxtv-commits mailing list > linuxtv-commits@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-04 18:05 ` [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name Michael Krufky @ 2009-09-07 5:10 ` Mauro Carvalho Chehab 2009-09-07 5:20 ` Michael Krufky 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 5:10 UTC (permalink / raw) To: Michael Krufky Cc: linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List Em Fri, 4 Sep 2009 14:05:31 -0400 Michael Krufky <mkrufky@kernellabs.com> escreveu: > Mauro, > > This fix should really go to Linus before 2.6.31 is released, if > possible. It also should be backported to stable, but I need it in > Linus' tree before it will be accepted into -stable. > > Do you think you can slip this in before the weekend? As I > understand, Linus plans to release 2.6.31 on Saturday, September 5th. > > If you dont have time for it, please let me know and I will send it in myself. > This patch doesn't apply upstream: $ patch -p1 -i 12613.patch patching file drivers/media/video/cx25840/cx25840-firmware.c Hunk #5 FAILED at 107. 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 5:10 ` Mauro Carvalho Chehab @ 2009-09-07 5:20 ` Michael Krufky 2009-09-07 6:06 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Michael Krufky @ 2009-09-07 5:20 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho Chehab<mchehab@infradead.org> wrote: > Em Fri, 4 Sep 2009 14:05:31 -0400 > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> Mauro, >> >> This fix should really go to Linus before 2.6.31 is released, if >> possible. It also should be backported to stable, but I need it in >> Linus' tree before it will be accepted into -stable. >> >> Do you think you can slip this in before the weekend? As I >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. >> >> If you dont have time for it, please let me know and I will send it in myself. >> > > This patch doesn't apply upstream: > > $ patch -p1 -i 12613.patch > patching file drivers/media/video/cx25840/cx25840-firmware.c > Hunk #5 FAILED at 107. > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re OK, this is going to need a manual backport. This does fix an issue in 2.6.31, and actually affects all kernels since the appearance of the cx23885 driver, but I can wait until you push it to Linus in the 2.6.32 merge window, then I'll backport & test it for -stable. Thanks & regards, -Mike ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 5:20 ` Michael Krufky @ 2009-09-07 6:06 ` Mauro Carvalho Chehab 2009-09-07 7:44 ` Konstantin Dimitrov 2009-09-07 16:19 ` Andy Walls 0 siblings, 2 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 6:06 UTC (permalink / raw) To: Michael Krufky Cc: linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List Em Mon, 7 Sep 2009 01:20:33 -0400 Michael Krufky <mkrufky@kernellabs.com> escreveu: > On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho > Chehab<mchehab@infradead.org> wrote: > > Em Fri, 4 Sep 2009 14:05:31 -0400 > > Michael Krufky <mkrufky@kernellabs.com> escreveu: > > > >> Mauro, > >> > >> This fix should really go to Linus before 2.6.31 is released, if > >> possible. It also should be backported to stable, but I need it in > >> Linus' tree before it will be accepted into -stable. > >> > >> Do you think you can slip this in before the weekend? As I > >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. > >> > >> If you dont have time for it, please let me know and I will send it in myself. > >> > > > > This patch doesn't apply upstream: > > > > $ patch -p1 -i 12613.patch > > patching file drivers/media/video/cx25840/cx25840-firmware.c > > Hunk #5 FAILED at 107. > > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re > > > OK, this is going to need a manual backport. This does fix an issue > in 2.6.31, and actually affects all kernels since the appearance of > the cx23885 driver, but I can wait until you push it to Linus in the > 2.6.32 merge window, then I'll backport & test it for -stable. Ok. I think I asked you once, but let me re-ask again: from what I was told, the latest cx25840 firmware (the one that Conexant give us the distribution rights) seems to be common to several cx25840-based chips. It would be really good if we can test it with all devices, especially since distros will add it on their firmware packages, as they are at the firmware -git Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 6:06 ` Mauro Carvalho Chehab @ 2009-09-07 7:44 ` Konstantin Dimitrov 2009-09-07 12:53 ` Mauro Carvalho Chehab 2009-09-07 16:19 ` Andy Walls 1 sibling, 1 reply; 16+ messages in thread From: Konstantin Dimitrov @ 2009-09-07 7:44 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Michael Krufky, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, Sep 7, 2009 at 9:06 AM, Mauro Carvalho Chehab<mchehab@infradead.org> wrote: > Em Mon, 7 Sep 2009 01:20:33 -0400 > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho >> Chehab<mchehab@infradead.org> wrote: >> > Em Fri, 4 Sep 2009 14:05:31 -0400 >> > Michael Krufky <mkrufky@kernellabs.com> escreveu: >> > >> >> Mauro, >> >> >> >> This fix should really go to Linus before 2.6.31 is released, if >> >> possible. It also should be backported to stable, but I need it in >> >> Linus' tree before it will be accepted into -stable. >> >> >> >> Do you think you can slip this in before the weekend? As I >> >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. >> >> >> >> If you dont have time for it, please let me know and I will send it in myself. >> >> >> > >> > This patch doesn't apply upstream: >> > >> > $ patch -p1 -i 12613.patch >> > patching file drivers/media/video/cx25840/cx25840-firmware.c >> > Hunk #5 FAILED at 107. >> > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re >> >> >> OK, this is going to need a manual backport. This does fix an issue >> in 2.6.31, and actually affects all kernels since the appearance of >> the cx23885 driver, but I can wait until you push it to Linus in the >> 2.6.32 merge window, then I'll backport & test it for -stable. > > Ok. I think I asked you once, but let me re-ask again: from what I was told, the > latest cx25840 firmware (the one that Conexant give us the distribution rights) > seems to be common to several cx25840-based chips. It would be really good if i also noticed that 3 firmwares with different file names and used by different drivers: - "v4l-cx23418-dig.fw" used by "cx18" driver, available here: http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz and includes notice about distribution permission from Conexant too - "v4l-cx23885-avcore-01.fw" used by "cx23885" driver - "v4l-cx25840.fw" used by "cx25840" driver have exactly the same md5sum: b3704908fd058485f3ef136941b2e513 and actually are the same firmware. > we can test it with all devices, especially since distros will add it on their > firmware packages, as they are at the firmware -git > > > > Cheers, > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 7:44 ` Konstantin Dimitrov @ 2009-09-07 12:53 ` Mauro Carvalho Chehab 2009-09-07 18:42 ` Mike Isely 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 12:53 UTC (permalink / raw) To: Konstantin Dimitrov Cc: Michael Krufky, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List, Mike Isely Em Mon, 7 Sep 2009 10:44:11 +0300 Konstantin Dimitrov <kosio.dimitrov@gmail.com> escreveu: > On Mon, Sep 7, 2009 at 9:06 AM, Mauro Carvalho > Chehab<mchehab@infradead.org> wrote: > > Em Mon, 7 Sep 2009 01:20:33 -0400 > > Michael Krufky <mkrufky@kernellabs.com> escreveu: > > > >> On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho > >> Chehab<mchehab@infradead.org> wrote: > >> > Em Fri, 4 Sep 2009 14:05:31 -0400 > >> > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> > > >> >> Mauro, > >> >> > >> >> This fix should really go to Linus before 2.6.31 is released, if > >> >> possible. It also should be backported to stable, but I need it in > >> >> Linus' tree before it will be accepted into -stable. > >> >> > >> >> Do you think you can slip this in before the weekend? As I > >> >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. > >> >> > >> >> If you dont have time for it, please let me know and I will send it in myself. > >> >> > >> > > >> > This patch doesn't apply upstream: > >> > > >> > $ patch -p1 -i 12613.patch > >> > patching file drivers/media/video/cx25840/cx25840-firmware.c > >> > Hunk #5 FAILED at 107. > >> > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re > >> > >> > >> OK, this is going to need a manual backport. This does fix an issue > >> in 2.6.31, and actually affects all kernels since the appearance of > >> the cx23885 driver, but I can wait until you push it to Linus in the > >> 2.6.32 merge window, then I'll backport & test it for -stable. > > > > Ok. I think I asked you once, but let me re-ask again: from what I was told, the > > latest cx25840 firmware (the one that Conexant give us the distribution rights) > > seems to be common to several cx25840-based chips. It would be really good if > > i also noticed that 3 firmwares with different file names and used by > different drivers: > > - "v4l-cx23418-dig.fw" used by "cx18" driver, available here: > http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz Conexant sent me in March a set of firmwares, that are available at both firmware -git tree and at: http://linuxtv.org/downloads/firmware/ They sent it together with the distribution rights as stated at the README file. However, the firmware versions have a different md5sum: a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx231xx-avcore-01.fw a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-avcore-01.fw a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-enc.fw (the three above are the same firmware and are 3 different names supported at cx23885 driver) dadb79e9904fc8af96e8111d9cb59320 v4l-cx25840.fw This one is different. Maybe a better strategy would be to name the firmware by versions, since maybe the differences are just the firmware version for each. > and includes notice about distribution permission from Conexant too > > - "v4l-cx23885-avcore-01.fw" used by "cx23885" driver > > - "v4l-cx25840.fw" used by "cx25840" driver > > have exactly the same md5sum: b3704908fd058485f3ef136941b2e513 and > actually are the same firmware. Yes. That's the point. So, a patch like this is incomplete or useless due to one of the reasons bellow: 1) the firmware doesn't work with some devices that could require a different version; 2) some earlier steppings of some chips require a different firmware; 3) Some of the firmwares supplied by the vendor are incorrect; 4) The new firmware works fine with all devices. So, we need to test the firmware with md5sum: b3704908fd058485f3ef136941b2e513 with all device types to be sure and to provide the proper fix that could require renaming some of those firmwares or just use one firmware name for all. I remember I asked both Mikes (Michael Krufky and Mike Isely) on March for some tests with the new firmware. I'm not sure if they had some time for testing it. It would be interesting the feedback also from the users to report if the March, 2009 firmwares work with their devices and, if not, what firmwares work. Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 12:53 ` Mauro Carvalho Chehab @ 2009-09-07 18:42 ` Mike Isely 2009-09-07 21:41 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Mike Isely @ 2009-09-07 18:42 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Konstantin Dimitrov, Michael Krufky, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List, Mike Isely On Mon, 7 Sep 2009, Mauro Carvalho Chehab wrote: [...] > > I remember I asked both Mikes (Michael Krufky and Mike Isely) on March for some > tests with the new firmware. I'm not sure if they had some time for testing it. Yes, I remember this exchange. At the time you had mentioned only the 3 files with identical MD5 sums (not that other one with the dadb79... sum). Here's the message I sent in response at that time: <CUT_HERE> >From isely@isely.net Tue Mar 31 21:17:58 2009 From: Mike Isely <isely@isely.net> To: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Hans Verkuil <hverkuil@xs4all.nl>, Michael Krufky <mkrufky@linuxtv.org>, Mike Isely at pobox <isely@pobox.com> Date: Tue, 31 Mar 2009 21:17:54 -0500 (CDT) Subject: Re: Conexant firmwares Reply-To: Mike Isely <isely@pobox.com> On Tue, 24 Mar 2009, Mike Isely wrote: > On Mon, 23 Mar 2009, Mauro Carvalho Chehab wrote: > > > Hi Hans and Mike I., > > > > Conexant officially sent us their firmwares. Due to that, I've added the > > firmwares at linuxtv.org and included at the get_dvb_firmware script. > > > > I'll also make sure that they'll be added at kernel-firmware -git and > > included in Fedora. > > > > As Michael K. noticed, the cx25840 firmwares are identical, for 3 different > > models: > > > > a9f8f5d901a7fb42f552e1ee6384f3bb cx23885 firmware/v4l-cx23885-enc.fw > > a9f8f5d901a7fb42f552e1ee6384f3bb cx25840 firmwares/v4l-cx231xx-avcore-01.fw > > a9f8f5d901a7fb42f552e1ee6384f3bb cx25840 firmwares/v4l-cx23885-avcore-01.fw > > > > Could you please test if those firmwares work well for the ivtv and pvrusb2 > > models? > > > > All those firmwares are available at linuxtv.org downloads/firmware dir. > > > > I imagine that they will all work just fine. But I'll let you know once > I've positively verified that fact. > > -Mike Yes, it works fine. I tested an HVR-1950 and a PVR-USB2 24xxx series model. Both work with the new firmware. Given that the 3 firmware images are identical, then what's the point of there being 3 different names? -Mike </CUT_HERE> -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 18:42 ` Mike Isely @ 2009-09-07 21:41 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 21:41 UTC (permalink / raw) To: Mike Isely Cc: Konstantin Dimitrov, Michael Krufky, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List, Mike Isely Em Mon, 7 Sep 2009 13:42:15 -0500 (CDT) Mike Isely <isely@isely.net> escreveu: > On Mon, 7 Sep 2009, Mauro Carvalho Chehab wrote: > > > [...] > > > > > I remember I asked both Mikes (Michael Krufky and Mike Isely) on March for some > > tests with the new firmware. I'm not sure if they had some time for testing it. > > Yes, I remember this exchange. At the time you had mentioned only the 3 > files with identical MD5 sums (not that other one with the dadb79... > sum). Here's the message I sent in response at that time: Hmm... I never received your answer, sorry. Probably some email issue. > > <CUT_HERE> > > From isely@isely.net Tue Mar 31 21:17:58 2009 > From: Mike Isely <isely@isely.net> > To: Mauro Carvalho Chehab <mchehab@infradead.org> > Cc: Hans Verkuil <hverkuil@xs4all.nl>, Michael Krufky <mkrufky@linuxtv.org>, Mike Isely at pobox <isely@pobox.com> > Date: Tue, 31 Mar 2009 21:17:54 -0500 (CDT) > Subject: Re: Conexant firmwares > Reply-To: Mike Isely <isely@pobox.com> > > On Tue, 24 Mar 2009, Mike Isely wrote: > > > On Mon, 23 Mar 2009, Mauro Carvalho Chehab wrote: > > > > > Hi Hans and Mike I., > > > > > > Conexant officially sent us their firmwares. Due to that, I've added the > > > firmwares at linuxtv.org and included at the get_dvb_firmware script. > > > > > > I'll also make sure that they'll be added at kernel-firmware -git and > > > included in Fedora. > > > > > > As Michael K. noticed, the cx25840 firmwares are identical, for 3 different > > > models: > > > > > > a9f8f5d901a7fb42f552e1ee6384f3bb cx23885 firmware/v4l-cx23885-enc.fw > > > a9f8f5d901a7fb42f552e1ee6384f3bb cx25840 firmwares/v4l-cx231xx-avcore-01.fw > > > a9f8f5d901a7fb42f552e1ee6384f3bb cx25840 firmwares/v4l-cx23885-avcore-01.fw > > > > > > Could you please test if those firmwares work well for the ivtv and pvrusb2 > > > models? > > > > > > All those firmwares are available at linuxtv.org downloads/firmware dir. > > > > > > > I imagine that they will all work just fine. But I'll let you know once > > I've positively verified that fact. > > > > -Mike > > Yes, it works fine. I tested an HVR-1950 and a PVR-USB2 24xxx series > model. Both work with the new firmware. > > Given that the 3 firmware images are identical, then what's the point of > there being 3 different names? Good to know! > > -Mike > > </CUT_HERE> > > Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 6:06 ` Mauro Carvalho Chehab 2009-09-07 7:44 ` Konstantin Dimitrov @ 2009-09-07 16:19 ` Andy Walls 2009-09-07 16:25 ` Michael Krufky 1 sibling, 1 reply; 16+ messages in thread From: Andy Walls @ 2009-09-07 16:19 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Michael Krufky, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, 2009-09-07 at 03:06 -0300, Mauro Carvalho Chehab wrote: > Em Mon, 7 Sep 2009 01:20:33 -0400 > Michael Krufky <mkrufky@kernellabs.com> escreveu: > > > On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho > > Chehab<mchehab@infradead.org> wrote: > > > Em Fri, 4 Sep 2009 14:05:31 -0400 > > > Michael Krufky <mkrufky@kernellabs.com> escreveu: > > > > > >> Mauro, > > >> > > >> This fix should really go to Linus before 2.6.31 is released, if > > >> possible. It also should be backported to stable, but I need it in > > >> Linus' tree before it will be accepted into -stable. > > >> > > >> Do you think you can slip this in before the weekend? As I > > >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. > > >> > > >> If you dont have time for it, please let me know and I will send it in myself. > > >> > > > > > > This patch doesn't apply upstream: > > > > > > $ patch -p1 -i 12613.patch > > > patching file drivers/media/video/cx25840/cx25840-firmware.c > > > Hunk #5 FAILED at 107. > > > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re > > > > > > OK, this is going to need a manual backport. This does fix an issue > > in 2.6.31, and actually affects all kernels since the appearance of > > the cx23885 driver, but I can wait until you push it to Linus in the > > 2.6.32 merge window, then I'll backport & test it for -stable. > > Ok. I think I asked you once, but let me re-ask again: from what I was told, the > latest cx25840 firmware (the one that Conexant give us the distribution rights) > seems to be common to several cx25840-based chips. Well, I know they are all very similar. I also know that the firmware for the CX23418's integrated A/V Core *is different* from the CX2584[0123]'s firmware. The differences are subtle, but it is different. For example, compare cx25840/cx25840-core.c:log_audio_status() with cx18/cx18-av-core.c:log_audio_status(). I know the CX23418 A/V Core firmware isn't at issue with this change, but the situation between the CX2584[0123], CX2388[578], and CX2310[12] firmwares is likely similar. Even if the firmwares are identical now, there is nothting inhbiting Conexant from releasing firmware fixes for the CX2310[12] that are not applicable to, and just wrong for, the CX25843 for example. > It would be really good if > we can test it with all devices, especially since distros will add it on their > firmware packages, as they are at the firmware -git Working through the set of test vectors, that includes all the Worldwide audio standards, while looking for subtle differences or malfunctions, is likely more work than any perceived savings of using a single firmware image. How can anyone even tell if anything is misdetected without professional TV standards signal generation equipment? What if using the wrong firmware introduces only an intermittent audio standard misdetection on that core? I'll assert we'll never be able to declare a reasonable testing success for using an audio standard autodetection firmware not specifically designated by Conexant to be for a particular Conexant A/V digitizer core. The core always ends up with subtle differences when integrated into another chip. I suppose one exception is if a "cmp" of two officially designated firmware images show the images as being identical, then obviously that images can be shared between those cores. I assume licensing is really the issue here. It is unfortunate. However, in my opinion, it is better for the user to know that his device is "broken" until he fetches the right firmware, than to spend hours debugging mystery audio problems because the user thinks he is using the "right" firmware when he is not. Oh well, I'll stop rambling now... Regards, Andy > Cheers, > Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 16:19 ` Andy Walls @ 2009-09-07 16:25 ` Michael Krufky 2009-09-07 21:36 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Michael Krufky @ 2009-09-07 16:25 UTC (permalink / raw) To: Andy Walls Cc: Mauro Carvalho Chehab, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, Sep 7, 2009 at 12:19 PM, Andy Walls<awalls@radix.net> wrote: > On Mon, 2009-09-07 at 03:06 -0300, Mauro Carvalho Chehab wrote: >> Em Mon, 7 Sep 2009 01:20:33 -0400 >> Michael Krufky <mkrufky@kernellabs.com> escreveu: >> >> > On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho >> > Chehab<mchehab@infradead.org> wrote: >> > > Em Fri, 4 Sep 2009 14:05:31 -0400 >> > > Michael Krufky <mkrufky@kernellabs.com> escreveu: >> > > >> > >> Mauro, >> > >> >> > >> This fix should really go to Linus before 2.6.31 is released, if >> > >> possible. It also should be backported to stable, but I need it in >> > >> Linus' tree before it will be accepted into -stable. >> > >> >> > >> Do you think you can slip this in before the weekend? As I >> > >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. >> > >> >> > >> If you dont have time for it, please let me know and I will send it in myself. >> > >> >> > > >> > > This patch doesn't apply upstream: >> > > >> > > $ patch -p1 -i 12613.patch >> > > patching file drivers/media/video/cx25840/cx25840-firmware.c >> > > Hunk #5 FAILED at 107. >> > > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re >> > >> > >> > OK, this is going to need a manual backport. This does fix an issue >> > in 2.6.31, and actually affects all kernels since the appearance of >> > the cx23885 driver, but I can wait until you push it to Linus in the >> > 2.6.32 merge window, then I'll backport & test it for -stable. >> >> Ok. I think I asked you once, but let me re-ask again: from what I was told, the >> latest cx25840 firmware (the one that Conexant give us the distribution rights) >> seems to be common to several cx25840-based chips. > > Well, I know they are all very similar. I also know that the firmware > for the CX23418's integrated A/V Core *is different* from the > CX2584[0123]'s firmware. The differences are subtle, but it is > different. For example, compare > cx25840/cx25840-core.c:log_audio_status() with > cx18/cx18-av-core.c:log_audio_status(). > > I know the CX23418 A/V Core firmware isn't at issue with this change, > but the situation between the CX2584[0123], CX2388[578], and CX2310[12] > firmwares is likely similar. > > Even if the firmwares are identical now, there is nothting inhbiting > Conexant from releasing firmware fixes for the CX2310[12] that are not > applicable to, and just wrong for, the CX25843 for example. > > >> It would be really good if >> we can test it with all devices, especially since distros will add it on their >> firmware packages, as they are at the firmware -git > > Working through the set of test vectors, that includes all the Worldwide > audio standards, while looking for subtle differences or malfunctions, > is likely more work than any perceived savings of using a single > firmware image. How can anyone even tell if anything is misdetected > without professional TV standards signal generation equipment? What if > using the wrong firmware introduces only an intermittent audio standard > misdetection on that core? > > I'll assert we'll never be able to declare a reasonable testing success > for using an audio standard autodetection firmware not specifically > designated by Conexant to be for a particular Conexant A/V digitizer > core. The core always ends up with subtle differences when integrated > into another chip. > > I suppose one exception is if a "cmp" of two officially designated > firmware images show the images as being identical, then obviously that > images can be shared between those cores. > > > I assume licensing is really the issue here. It is unfortunate. > However, in my opinion, it is better for the user to know that his > device is "broken" until he fetches the right firmware, than to spend > hours debugging mystery audio problems because the user thinks he is > using the "right" firmware when he is not. > > Oh well, I'll stop rambling now... > > Regards, > Andy Thanks, Andy -- That's exactly what I wanted to say, but you found the words before I did. I haven't played much with the cx231xx stuff yet to be able to comment, but I already know for a fact that there is some stuff in the cx23885 version of the firmware that does not apply to the other variants. While you might be able to make a device work by using the wrong firmware, it wont necessarily work for all permutations of that device, and wont necessarily support all features. Best off to leave it as-is. Do not attempt to merge the firmware's into one. Let the device driver maintainer make that decision. If the cx231xx driver were compatible with the default cx25840 firmware, then they wouldn't have created a new filename for it. cx23885 certainly needs a newer version of the firmware, which happens to be backwards compatible with the older cx25840 parts, but just as Andy mentioned, who is to say that a newer firmware might not come out that causes problem with legacy components? Regards, Mike ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 16:25 ` Michael Krufky @ 2009-09-07 21:36 ` Mauro Carvalho Chehab 2009-09-07 22:21 ` Michael Krufky 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 21:36 UTC (permalink / raw) To: Michael Krufky Cc: Andy Walls, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List Em Mon, 7 Sep 2009 12:25:15 -0400 Michael Krufky <mkrufky@kernellabs.com> escreveu: > On Mon, Sep 7, 2009 at 12:19 PM, Andy Walls<awalls@radix.net> wrote: > > On Mon, 2009-09-07 at 03:06 -0300, Mauro Carvalho Chehab wrote: > >> Em Mon, 7 Sep 2009 01:20:33 -0400 > >> Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> > >> > On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho > >> > Chehab<mchehab@infradead.org> wrote: > >> > > Em Fri, 4 Sep 2009 14:05:31 -0400 > >> > > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> > > > >> > >> Mauro, > >> > >> > >> > >> This fix should really go to Linus before 2.6.31 is released, if > >> > >> possible. It also should be backported to stable, but I need it in > >> > >> Linus' tree before it will be accepted into -stable. > >> > >> > >> > >> Do you think you can slip this in before the weekend? As I > >> > >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. > >> > >> > >> > >> If you dont have time for it, please let me know and I will send it in myself. > >> > >> > >> > > > >> > > This patch doesn't apply upstream: > >> > > > >> > > $ patch -p1 -i 12613.patch > >> > > patching file drivers/media/video/cx25840/cx25840-firmware.c > >> > > Hunk #5 FAILED at 107. > >> > > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re > >> > > >> > > >> > OK, this is going to need a manual backport. This does fix an issue > >> > in 2.6.31, and actually affects all kernels since the appearance of > >> > the cx23885 driver, but I can wait until you push it to Linus in the > >> > 2.6.32 merge window, then I'll backport & test it for -stable. > >> > >> Ok. I think I asked you once, but let me re-ask again: from what I was told, the > >> latest cx25840 firmware (the one that Conexant give us the distribution rights) > >> seems to be common to several cx25840-based chips. > > > > Well, I know they are all very similar. I also know that the firmware > > for the CX23418's integrated A/V Core *is different* from the > > CX2584[0123]'s firmware. The differences are subtle, but it is > > different. For example, compare > > cx25840/cx25840-core.c:log_audio_status() with > > cx18/cx18-av-core.c:log_audio_status(). > > > > I know the CX23418 A/V Core firmware isn't at issue with this change, > > but the situation between the CX2584[0123], CX2388[578], and CX2310[12] > > firmwares is likely similar. > > > > Even if the firmwares are identical now, there is nothting inhbiting > > Conexant from releasing firmware fixes for the CX2310[12] that are not > > applicable to, and just wrong for, the CX25843 for example. > > > > > >> It would be really good if > >> we can test it with all devices, especially since distros will add it on their > >> firmware packages, as they are at the firmware -git > > > > Working through the set of test vectors, that includes all the Worldwide > > audio standards, while looking for subtle differences or malfunctions, > > is likely more work than any perceived savings of using a single > > firmware image. How can anyone even tell if anything is misdetected > > without professional TV standards signal generation equipment? What if > > using the wrong firmware introduces only an intermittent audio standard > > misdetection on that core? > > > > I'll assert we'll never be able to declare a reasonable testing success > > for using an audio standard autodetection firmware not specifically > > designated by Conexant to be for a particular Conexant A/V digitizer > > core. The core always ends up with subtle differences when integrated > > into another chip. > > > > I suppose one exception is if a "cmp" of two officially designated > > firmware images show the images as being identical, then obviously that > > images can be shared between those cores. > > > > > > I assume licensing is really the issue here. It is unfortunate. > > However, in my opinion, it is better for the user to know that his > > device is "broken" until he fetches the right firmware, than to spend > > hours debugging mystery audio problems because the user thinks he is > > using the "right" firmware when he is not. > > > > Oh well, I'll stop rambling now... > > > > Regards, > > Andy > > Thanks, Andy -- That's exactly what I wanted to say, but you found the > words before I did. > > I haven't played much with the cx231xx stuff yet to be able to > comment, but I already know for a fact that there is some stuff in the > cx23885 version of the firmware that does not apply to the other > variants. > > While you might be able to make a device work by using the wrong > firmware, it wont necessarily work for all permutations of that > device, and wont necessarily support all features. The point is that there are three _identical_ firmwares, officially released by Conexant, with different names, for the same driver. To be worse, on some places, different versions than the last official set is being used. IMO, using a different version than the last official one can be the real cause of troubles that such patch wants to address. I never said we should try to use a different firmware than what's provided by the manufacturer. I'm saying just the reverse: let's trust on the firmwares provided by them, but, as we found that there are different versions on it, we need to rename them to be sure that the right firmware version will be used. Also, while we have identical firmwares, we should identify identical firmwares identically. > Best off to leave it as-is. Do not attempt to merge the firmware's > into one. Let the device driver maintainer make that decision. If > the cx231xx driver were compatible with the default cx25840 firmware, > then they wouldn't have created a new filename for it. cx23885 > certainly needs a newer version of the firmware, which happens to be > backwards compatible with the older cx25840 parts, but just as Andy > mentioned, who is to say that a newer firmware might not come out that > causes problem with legacy components? >From what we know: a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx231xx-avcore-01.fw a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-avcore-01.fw a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-enc.fw dadb79e9904fc8af96e8111d9cb59320 v4l-cx25840.fw cx23885-enc, cx23885-avcore1 and cx231xx-avcore-01 are just three different names for the same firmware. So, while Conexant doesn't ship a different firmware for one of those devices, IMO, we should rename all of them to one unique name, adding a version note after the name. So, if Conexant provides us some revision tag, the better is to use it: v4l-cx25840 ===> cx25840-x0.y0.z0.fw (dadb79e9904fc8af96e8111d9cb59320) v4l-cx23* ===> cx23xxx-x1.y1.z1.fw (a9f8f5d901a7fb42f552e1ee6384f3bb) (being x0.y0.z0 and x1.y1.z1 the revision marks from the manufacturer) As a fallback alternative, we could add a "yearmonth" tag at the end of the firmware name, being the date where Conexant sent us the firmware. So, as we've received this firmware in Mar, 18 2009, we could name them as: v4l-cx25840 ===> cx25840-200903.fw (dadb79e9904fc8af96e8111d9cb59320) v4l-cx23* ===> cx23xxx-200903.fw (a9f8f5d901a7fb42f552e1ee6384f3bb) Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 21:36 ` Mauro Carvalho Chehab @ 2009-09-07 22:21 ` Michael Krufky 2009-09-07 22:40 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 16+ messages in thread From: Michael Krufky @ 2009-09-07 22:21 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Andy Walls, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, Sep 7, 2009 at 5:36 PM, Mauro Carvalho Chehab<mchehab@infradead.org> wrote: > Em Mon, 7 Sep 2009 12:25:15 -0400 > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> On Mon, Sep 7, 2009 at 12:19 PM, Andy Walls<awalls@radix.net> wrote: >> > On Mon, 2009-09-07 at 03:06 -0300, Mauro Carvalho Chehab wrote: >> >> Em Mon, 7 Sep 2009 01:20:33 -0400 >> >> Michael Krufky <mkrufky@kernellabs.com> escreveu: >> >> >> >> > On Mon, Sep 7, 2009 at 1:10 AM, Mauro Carvalho >> >> > Chehab<mchehab@infradead.org> wrote: >> >> > > Em Fri, 4 Sep 2009 14:05:31 -0400 >> >> > > Michael Krufky <mkrufky@kernellabs.com> escreveu: >> >> > > >> >> > >> Mauro, >> >> > >> >> >> > >> This fix should really go to Linus before 2.6.31 is released, if >> >> > >> possible. It also should be backported to stable, but I need it in >> >> > >> Linus' tree before it will be accepted into -stable. >> >> > >> >> >> > >> Do you think you can slip this in before the weekend? As I >> >> > >> understand, Linus plans to release 2.6.31 on Saturday, September 5th. >> >> > >> >> >> > >> If you dont have time for it, please let me know and I will send it in myself. >> >> > >> >> >> > > >> >> > > This patch doesn't apply upstream: >> >> > > >> >> > > $ patch -p1 -i 12613.patch >> >> > > patching file drivers/media/video/cx25840/cx25840-firmware.c >> >> > > Hunk #5 FAILED at 107. >> >> > > 1 out of 5 hunks FAILED -- saving rejects to file drivers/media/video/cx25840/cx25840-firmware.c.re >> >> > >> >> > >> >> > OK, this is going to need a manual backport. This does fix an issue >> >> > in 2.6.31, and actually affects all kernels since the appearance of >> >> > the cx23885 driver, but I can wait until you push it to Linus in the >> >> > 2.6.32 merge window, then I'll backport & test it for -stable. >> >> >> >> Ok. I think I asked you once, but let me re-ask again: from what I was told, the >> >> latest cx25840 firmware (the one that Conexant give us the distribution rights) >> >> seems to be common to several cx25840-based chips. >> > >> > Well, I know they are all very similar. I also know that the firmware >> > for the CX23418's integrated A/V Core *is different* from the >> > CX2584[0123]'s firmware. The differences are subtle, but it is >> > different. For example, compare >> > cx25840/cx25840-core.c:log_audio_status() with >> > cx18/cx18-av-core.c:log_audio_status(). >> > >> > I know the CX23418 A/V Core firmware isn't at issue with this change, >> > but the situation between the CX2584[0123], CX2388[578], and CX2310[12] >> > firmwares is likely similar. >> > >> > Even if the firmwares are identical now, there is nothting inhbiting >> > Conexant from releasing firmware fixes for the CX2310[12] that are not >> > applicable to, and just wrong for, the CX25843 for example. >> > >> > >> >> It would be really good if >> >> we can test it with all devices, especially since distros will add it on their >> >> firmware packages, as they are at the firmware -git >> > >> > Working through the set of test vectors, that includes all the Worldwide >> > audio standards, while looking for subtle differences or malfunctions, >> > is likely more work than any perceived savings of using a single >> > firmware image. How can anyone even tell if anything is misdetected >> > without professional TV standards signal generation equipment? What if >> > using the wrong firmware introduces only an intermittent audio standard >> > misdetection on that core? >> > >> > I'll assert we'll never be able to declare a reasonable testing success >> > for using an audio standard autodetection firmware not specifically >> > designated by Conexant to be for a particular Conexant A/V digitizer >> > core. The core always ends up with subtle differences when integrated >> > into another chip. >> > >> > I suppose one exception is if a "cmp" of two officially designated >> > firmware images show the images as being identical, then obviously that >> > images can be shared between those cores. >> > >> > >> > I assume licensing is really the issue here. It is unfortunate. >> > However, in my opinion, it is better for the user to know that his >> > device is "broken" until he fetches the right firmware, than to spend >> > hours debugging mystery audio problems because the user thinks he is >> > using the "right" firmware when he is not. >> > >> > Oh well, I'll stop rambling now... >> > >> > Regards, >> > Andy >> >> Thanks, Andy -- That's exactly what I wanted to say, but you found the >> words before I did. >> >> I haven't played much with the cx231xx stuff yet to be able to >> comment, but I already know for a fact that there is some stuff in the >> cx23885 version of the firmware that does not apply to the other >> variants. >> >> While you might be able to make a device work by using the wrong >> firmware, it wont necessarily work for all permutations of that >> device, and wont necessarily support all features. > > The point is that there are three _identical_ firmwares, officially released by > Conexant, with different names, for the same driver. To be worse, on some > places, different versions than the last official set is being used. IMO, using > a different version than the last official one can be the real cause of > troubles that such patch wants to address. > > I never said we should try to use a different firmware than what's provided by > the manufacturer. I'm saying just the reverse: let's trust on the firmwares > provided by them, but, as we found that there are different versions on it, > we need to rename them to be sure that the right firmware version will be used. > > Also, while we have identical firmwares, we should identify identical firmwares > identically. > >> Best off to leave it as-is. Do not attempt to merge the firmware's >> into one. Let the device driver maintainer make that decision. If >> the cx231xx driver were compatible with the default cx25840 firmware, >> then they wouldn't have created a new filename for it. cx23885 >> certainly needs a newer version of the firmware, which happens to be >> backwards compatible with the older cx25840 parts, but just as Andy >> mentioned, who is to say that a newer firmware might not come out that >> causes problem with legacy components? > > From what we know: > a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx231xx-avcore-01.fw > a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-avcore-01.fw > a9f8f5d901a7fb42f552e1ee6384f3bb v4l-cx23885-enc.fw > dadb79e9904fc8af96e8111d9cb59320 v4l-cx25840.fw > > cx23885-enc, cx23885-avcore1 and cx231xx-avcore-01 are just three different > names for the same firmware. So, while Conexant doesn't ship a different > firmware for one of those devices, IMO, we should rename all of them to one > unique name, adding a version note after the name. > > So, if Conexant provides us some revision tag, the better is to use it: > > v4l-cx25840 ===> cx25840-x0.y0.z0.fw (dadb79e9904fc8af96e8111d9cb59320) > v4l-cx23* ===> cx23xxx-x1.y1.z1.fw (a9f8f5d901a7fb42f552e1ee6384f3bb) > > (being x0.y0.z0 and x1.y1.z1 the revision marks from the manufacturer) > > As a fallback alternative, we could add a "yearmonth" tag at the end of the > firmware name, being the date where Conexant sent us the firmware. > > So, as we've received this firmware in Mar, 18 2009, we could name them as: > > v4l-cx25840 ===> cx25840-200903.fw (dadb79e9904fc8af96e8111d9cb59320) > v4l-cx23* ===> cx23xxx-200903.fw (a9f8f5d901a7fb42f552e1ee6384f3bb) Mauro, For the Conexant *reference designs* the firmwares are identical, yes. If you look at the windows drivers, there are some additional bits used for separate firmwares depending on which actual silicon is present. This is specific to the implementation by the vendors. Not everybody is using the firmware images that you are pointing at... There is in fact a need to keep the filenames separate. Some firmware for one silicon may conflict with firmware for other silicon. -Mike ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 22:21 ` Michael Krufky @ 2009-09-07 22:40 ` Mauro Carvalho Chehab 2009-09-08 1:22 ` Michael Krufky 0 siblings, 1 reply; 16+ messages in thread From: Mauro Carvalho Chehab @ 2009-09-07 22:40 UTC (permalink / raw) To: Michael Krufky Cc: Andy Walls, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List Em Mon, 7 Sep 2009 18:21:01 -0400 Michael Krufky <mkrufky@kernellabs.com> escreveu: > Mauro, > > For the Conexant *reference designs* the firmwares are identical, yes. > > If you look at the windows drivers, there are some additional bits > used for separate firmwares depending on which actual silicon is > present. This is specific to the implementation by the vendors. If firmware versions are vendor-specific, then the patch "cx25840: fix determining the firmware name" doesn't work, since people may have two boards with the same silicon from different vendors, each requiring his own vendor-specific firmware. The solution seems to have a setup parameter with the firmware name, adding the firmware name at the *-cards.c, like what's done with xc3028 firmwares. This also means that we need vendor's rights to distribute the specific firmwares. > > Not everybody is using the firmware images that you are pointing at... > There is in fact a need to keep the filenames separate. Some > firmware for one silicon may conflict with firmware for other silicon. > > -Mike > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Mauro ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-07 22:40 ` Mauro Carvalho Chehab @ 2009-09-08 1:22 ` Michael Krufky 2009-09-08 2:30 ` Andy Walls 0 siblings, 1 reply; 16+ messages in thread From: Michael Krufky @ 2009-09-08 1:22 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Andy Walls, linuxtv-commits, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, Sep 7, 2009 at 6:40 PM, Mauro Carvalho Chehab<mchehab@infradead.org> wrote: > Em Mon, 7 Sep 2009 18:21:01 -0400 > Michael Krufky <mkrufky@kernellabs.com> escreveu: > >> Mauro, >> >> For the Conexant *reference designs* the firmwares are identical, yes. >> >> If you look at the windows drivers, there are some additional bits >> used for separate firmwares depending on which actual silicon is >> present. This is specific to the implementation by the vendors. > > If firmware versions are vendor-specific, then the patch "cx25840: fix > determining the firmware name" doesn't work, since people may have two boards > with the same silicon from different vendors, each requiring his own > vendor-specific firmware. > > The solution seems to have a setup parameter with the firmware name, adding the > firmware name at the *-cards.c, like what's done with xc3028 firmwares. This > also means that we need vendor's rights to distribute the specific firmwares. >> >> Not everybody is using the firmware images that you are pointing at... >> There is in fact a need to keep the filenames separate. Some >> firmware for one silicon may conflict with firmware for other silicon. >> >> -Mike Let me clarify: As far as I understand, there are some additional bits in the cx23885 firmware for use with certain vendor-specific stuff. That cx23885 firmware is compatible with all other cx23885 firmware, but not necessarily the cx25840. Likewise, there are some additional bits in the cx25840 firmware for certain vendor-specific stuff, that is compatible with all other cx25840 firmware, but not necessarily the cx23885. As I understand, if additional bits are added for a specific product, they might be added to the firmware in addition to the other bits already present for *that* firmware image. This means, any cx23885 firmware is OK to use for any cx23885, and any cx25840 firmware is OK to use for any cx25840. You will notice that most of these images can be interchanged between one another, but the additional bits are specific to the flavor of the silicon. There is no actual vendor-specific firmware -- all firmware for these parts are uniform for that part. However, there are some cx23885-specific bits that only apply to the cx23885, just as there may be some cx25840-specific bits that only apply to the cx25840. I dont know how to explain this any clearer. One thing that might be a good idea -- perhaps the bridge-level driver that needs to attach the cx25840 module should specify to the cx25840 module the filename of the firmware that should be requested. A module option would *not* be the best idea -- we should not expect users to know about this. Perhaps a default firmware filename could be named by cx25840. *but* we should not simply cause every driver to all use the same filename unless the original driver author can vouch for this as the appropriate course of action. Regards, Mike ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-08 1:22 ` Michael Krufky @ 2009-09-08 2:30 ` Andy Walls 2009-09-08 16:24 ` Steven Toth 0 siblings, 1 reply; 16+ messages in thread From: Andy Walls @ 2009-09-08 2:30 UTC (permalink / raw) To: Michael Krufky Cc: Mauro Carvalho Chehab, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List On Mon, 2009-09-07 at 21:22 -0400, Michael Krufky wrote: > On Mon, Sep 7, 2009 at 6:40 PM, Mauro Carvalho > Chehab<mchehab@infradead.org> wrote: > > Em Mon, 7 Sep 2009 18:21:01 -0400 > > Michael Krufky <mkrufky@kernellabs.com> escreveu: > > > >> Mauro, > >> > >> For the Conexant *reference designs* the firmwares are identical, yes. > >> > >> If you look at the windows drivers, there are some additional bits > >> used for separate firmwares depending on which actual silicon is > >> present. This is specific to the implementation by the vendors. > > > > If firmware versions are vendor-specific, then the patch "cx25840: fix > > determining the firmware name" doesn't work, since people may have two boards > > with the same silicon from different vendors, each requiring his own > > vendor-specific firmware. > > > > The solution seems to have a setup parameter with the firmware name, adding the > > firmware name at the *-cards.c, like what's done with xc3028 firmwares. This > > also means that we need vendor's rights to distribute the specific firmwares. > >> > >> Not everybody is using the firmware images that you are pointing at... > >> There is in fact a need to keep the filenames separate. Some > >> firmware for one silicon may conflict with firmware for other silicon. > >> > >> -Mike > > Let me clarify: > > As far as I understand, there are some additional bits in the cx23885 > firmware for use with certain vendor-specific stuff. That cx23885 > firmware is compatible with all other cx23885 firmware, but not > necessarily the cx25840. > > Likewise, there are some additional bits in the cx25840 firmware for > certain vendor-specific stuff, that is compatible with all other > cx25840 firmware, but not necessarily the cx23885. > > As I understand, if additional bits are added for a specific product, > they might be added to the firmware in addition to the other bits > already present for *that* firmware image. This means, any cx23885 > firmware is OK to use for any cx23885, and any cx25840 firmware is OK > to use for any cx25840. > > You will notice that most of these images can be interchanged between > one another, but the additional bits are specific to the flavor of the > silicon. > > There is no actual vendor-specific firmware -- all firmware for these > parts are uniform for that part. However, there are some > cx23885-specific bits that only apply to the cx23885, just as there > may be some cx25840-specific bits that only apply to the cx25840. > > I dont know how to explain this any clearer. Might I add a slightly off-topic rant: the cx25840 module is a maintenance headache due to the desire to handle all these different devices with "common code". If you take a look at the code, there's a good deal that's not in common, and I'm wondering what the benefit of the common code base is exactly. Maintenance-wise, the cx25840 module takes a lot more thought and testing to modify properly. For example, just changing the module to get the Video Clock for the CX23888 set properly took a ridiculous amount of effort: http://linuxtv.org/hg/~awalls/cx23888-ir/rev/70bde4976fc3 http://linuxtv.org/hg/~awalls/cx23888-ir/rev/c3d2791d89f3 http://linuxtv.org/hg/~awalls/cx23888-ir/rev/b42e0af29652 http://linuxtv.org/hg/~awalls/cx23888-ir/rev/caf03e99d49f http://linuxtv.org/hg/~awalls/cx23888-ir/rev/7078cafc3d44 Especially in this change to separate out the configuration of the audio clocks for the individual families: http://linuxtv.org/hg/~awalls/cx23888-ir/rev/b42e0af29652 it became very obvious how much of the analog audio functionality isn't complete for the CX2388[578] and CX2310[12]. It wasn't really visible before. I also swept up a minor inconsistency/bug in that change. If you look, the SA_MCLK_DIV was not being set properly for 32 ksps serial audio for CX2583[67] chips due to a conditional check for a cx2583x chip type. Did it matter for a CX2583x chip that doesn't have audio? No, but it was being set for the CX2583x for all the other cases by the conditional code at the top of the function. This inconsistency/bug was invisible due to being buried in the mess of conditional code paths to accommodate multiple cores. BTW, the cx25840 module still needs some work. Things that spring to mind: 1. Allowing the bridge driver to specify GPIO settings cleanly. At least one LeadTek board needs this. 2. Adding IR controller functionality for the CX23885 (and CX2584x and CX2310x if anyone has a device with it hooked up). 3. Adding event notifications to alert the bridge driver when the audio format and mode has changed (in hopes of clearing up the PVR-150 and PVR-500 tinny audio problem). 4. At least the cx23885 driver and cx231xx driver break the abstraction of separation by accessing A/V core registers directly from the bridge driver. The cx23885 module does it to configure the AUX_PLL for NetUP cards, IIRC. The cx231xx driver does it to set up the analog frontend input mux, IIRC. The biggest maintenance problem with this module is the regression testing when changing a common code path used by all the cores. Those common code paths I perceive as very fragile. What is the exact benefit we're after here by making things common between all these cores? Code reuse is not a benefit, if it leads to more expensive maintenance. I had considered moving the cx18-av code from the cx18 module into the cx25840 module, but could never find a reason to undertake all the work. Memory footprint isn't a good reason: desktop PC memory is cheap and embedded systems would likely only use one type of card anyway. The return on investment seems like it would be less than 0. OK. I'm done ranting... Regards, Andy > One thing that might be a good idea -- perhaps the bridge-level driver > that needs to attach the cx25840 module should specify to the cx25840 > module the filename of the firmware that should be requested. A > module option would *not* be the best idea -- we should not expect > users to know about this. Perhaps a default firmware filename could > be named by cx25840. *but* we should not simply cause every driver > to all use the same filename unless the original driver author can > vouch for this as the appropriate course of action. > Regards, > > Mike ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name 2009-09-08 2:30 ` Andy Walls @ 2009-09-08 16:24 ` Steven Toth 0 siblings, 0 replies; 16+ messages in thread From: Steven Toth @ 2009-09-08 16:24 UTC (permalink / raw) To: Andy Walls, Mauro Carvalho Chehab Cc: Michael Krufky, Jarod Wilson, Hans Verkuil via Mercurial, Linux Media Mailing List > What is the exact benefit we're after here by making things common > between all these cores? Code reuse is not a benefit, if it leads to > more expensive maintenance. We'll, it diverged for the 23885 because the register addressed change for some registers, it's not the same part. Certainly for the video decoder, not necessarily for the audio encoder. I know Andy knows this, I'm just pointing it out for the record. This, coupled with the 'don't screw up other boards' approach leads to a unified driver, not so much internally. The 25840 driver does 'just enough' to get by, Andy has taken it to the next level and done the stuff that I should have done for the cx23885 merge (although I did 'just enough' to get by). The notion of flexible clocks pays big dividends thanks to Andy, but is largely a positive change that falls outside of this discussion topic (firmware filename). > > I had considered moving the cx18-av code from the cx18 module into the > cx25840 module, but could never find a reason to undertake all the work. > Memory footprint isn't a good reason: desktop PC memory is cheap and > embedded systems would likely only use one type of card anyway. The > return on investment seems like it would be less than 0. Hmm. You should check out the cx23102 driver, whole crap, massive cx25840 overlap, massive superset in terms of functionality. > > OK. I'm done ranting... A great pity, you were getting me fired up along the same train of thought :) Andy, you have the support and full access to the resources of KernelLabs if you need help (directly or indirectly) with regression testing. Your work is very positive and a much needed overhaul. Mauro, my pitch: Let's leave the firmwares unique for the time being, which indeed they are. So, leave the firmware detection code as is, it's working for everyone. Let's rethink this discussion after Andy's massive patch series. It sounds like the cx25840 driver is 'getting a new owner' and we'll look at the driver differently once the overhaul is complete. -- Steven Toth - Kernel Labs http://www.kernellabs.com ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-09-08 16:24 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1MiTfS-0001LQ-SU@mail.linuxtv.org>
2009-09-04 18:05 ` [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name Michael Krufky
2009-09-07 5:10 ` Mauro Carvalho Chehab
2009-09-07 5:20 ` Michael Krufky
2009-09-07 6:06 ` Mauro Carvalho Chehab
2009-09-07 7:44 ` Konstantin Dimitrov
2009-09-07 12:53 ` Mauro Carvalho Chehab
2009-09-07 18:42 ` Mike Isely
2009-09-07 21:41 ` Mauro Carvalho Chehab
2009-09-07 16:19 ` Andy Walls
2009-09-07 16:25 ` Michael Krufky
2009-09-07 21:36 ` Mauro Carvalho Chehab
2009-09-07 22:21 ` Michael Krufky
2009-09-07 22:40 ` Mauro Carvalho Chehab
2009-09-08 1:22 ` Michael Krufky
2009-09-08 2:30 ` Andy Walls
2009-09-08 16:24 ` Steven Toth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox