Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Michael Krufky]

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
>

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Michael Krufky]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Konstantin Dimitrov]

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
>

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Andy Walls]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Michael Krufky]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Michael Krufky]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Mauro Carvalho Chehab]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Michael Krufky]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Andy Walls]

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

Re: [linuxtv-commits] [hg:v4l-dvb] cx25840: fix determining the firmware name

[Steven Toth]

> 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