Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
Stefan Ringel wrote:
> Am 08.02.2010 12:27, schrieb Mauro Carvalho Chehab:
>> stefan.rin...@arcor.de wrote:
>>
>>> From: Stefan Ringel
>>>
>>> Signed-off-by: Stefan Ringel
>>> ---
>>> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
>>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
>>> b/drivers/media/common/tuners/tuner-xc2028.c
>>> index ed50168..fcf19cc 100644
>>> --- a/drivers/media/common/tuners/tuner-xc2028.c
>>> +++ b/drivers/media/common/tuners/tuner-xc2028.c
>>> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>>>
>>> /* All S-code tables need a 200kHz shift */
>>> if (priv->ctrl.demod) {
>>> - demod = priv->ctrl.demod + 200;
>>> + if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
>>> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
>>> + ((type & DTV78) || (type & DTV8)))
>>> + demod = priv->ctrl.demod;
>>> + else
>>> + demod = priv->ctrl.demod + 200;
>>> /*
>>> * The DTV7 S-code table needs a 700 kHz shift.
>>> * Thanks to Terry Wu for reporting this
>>>
>> The idea behind this patch is right, but you should be testing it against
>> priv->firm_version, instead comparing with a file name.
>>
>> Also, this will likely cause regressions on other drivers, since the offsets
>> for
>> v3.6 firmwares were handled on a different way on other drivers. I prefer to
>> postpone
>> this patch and the discussion behind it after having tm6000 driver ready,
>> since
>> it makes no sense to cause regressions or request changes on existing
>> drivers due
>> to a driver that is not ready yet.
>>
>> So, please hold your patch on your queue for now.
>>
>> My suggestion is that you should use git and have this patch on a separate
>> branch where you
>> do your tests, having a branch without this patch for upstream submission.
>>
>>
> In this firmware is for ZARLINK two parts, first for QAM, DTV6 and DTV7
> with shift 200 kHz, and second for DTV78 and DTV8. I check the firmware
> 2.7 this use for ZARLINK for all this mode a 200 kHz shift. For the next
> source part it says that DTV7 have 700 kHz shift.
> That not for all firmware correct.
>
>
>From what we know, the name "zarlink" for the firmware is bogus: the firmware
>has nothing
special to work with zarlink, except for the IF offset. You may or select a
firmware with
-200 KHz IF offset or to do the adjustment by adding 200 KHz for firmwares up
to 2.7.
The problem is that the driver that originally added the v3.6 implemented it on
a different
place. So, we need to fix all the drivers at the patch that we're changing its
behavior,
to avoid breakages.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
Am 08.02.2010 12:27, schrieb Mauro Carvalho Chehab:
> stefan.rin...@arcor.de wrote:
>
>> From: Stefan Ringel
>>
>> Signed-off-by: Stefan Ringel
>> ---
>> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
>> 1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
>> b/drivers/media/common/tuners/tuner-xc2028.c
>> index ed50168..fcf19cc 100644
>> --- a/drivers/media/common/tuners/tuner-xc2028.c
>> +++ b/drivers/media/common/tuners/tuner-xc2028.c
>> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>>
>> /* All S-code tables need a 200kHz shift */
>> if (priv->ctrl.demod) {
>> -demod = priv->ctrl.demod + 200;
>> +if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
>> +(priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
>> +((type & DTV78) || (type & DTV8)))
>> +demod = priv->ctrl.demod;
>> +else
>> +demod = priv->ctrl.demod + 200;
>> /*
>> * The DTV7 S-code table needs a 700 kHz shift.
>> * Thanks to Terry Wu for reporting this
>>
> The idea behind this patch is right, but you should be testing it against
> priv->firm_version, instead comparing with a file name.
>
> Also, this will likely cause regressions on other drivers, since the offsets
> for
> v3.6 firmwares were handled on a different way on other drivers. I prefer to
> postpone
> this patch and the discussion behind it after having tm6000 driver ready,
> since
> it makes no sense to cause regressions or request changes on existing drivers
> due
> to a driver that is not ready yet.
>
> So, please hold your patch on your queue for now.
>
> My suggestion is that you should use git and have this patch on a separate
> branch where you
> do your tests, having a branch without this patch for upstream submission.
>
>
In this firmware is for ZARLINK two parts, first for QAM, DTV6 and DTV7
with shift 200 kHz, and second for DTV78 and DTV8. I check the firmware
2.7 this use for ZARLINK for all this mode a 200 kHz shift. For the next
source part it says that DTV7 have 700 kHz shift.
That not for all firmware correct.
--
Stefan Ringel
list action
firmware file name: xc3028-v27.fw
firmware name: xc2028 firmware
version:2.7 (519)
standards: 80
Firmware 0, type: BASE FW F8MHZ (0x0003), id: (), size:
8718
Firmware 1, type: BASE FW F8MHZ MTS (0x0007), id: (),
size: 8712
Firmware 2, type: BASE FW FM (0x0401), id: (), size: 8562
Firmware 3, type: BASE FW FM INPUT1 (0x0c01), id: (),
size: 8576
Firmware 4, type: BASE FW (0x0001), id: (), size: 8706
Firmware 5, type: BASE FW MTS (0x0005), id: (), size:
8682
Firmware 6, type: STD FW(0x), id: PAL/BG A2/A (00010007),
size: 161
Firmware 7, type: STD FWMTS (0x0004), id: PAL/BG A2/A
(00010007), size: 169
Firmware 8, type: STD FW(0x), id: PAL/BG A2/B (00020007),
size: 161
Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG A2/B
(00020007), size: 169
Firmware 10, type: STD FW(0x), id: PAL/BG NICAM/A
(00040007), size: 161
Firmware 11, type: STD FWMTS (0x0004), id: PAL/BG NICAM/A
(00040007), size: 169
Firmware 12, type: STD FW(0x), id: PAL/BG NICAM/B
(00080007), size: 161
Firmware 13, type: STD FWMTS (0x0004), id: PAL/BG NICAM/B
(00080007), size: 169
Firmware 14, type: STD FW(0x), id: PAL/DK A2 (000300e0),
size: 161
Firmware 15, type: STD FWMTS (0x0004), id: PAL/DK A2
(000300e0), size: 169
Firmware 16, type: STD FW(0x), id: PAL/DK NICAM (000c00e0),
size: 161
Firmware 17, type: STD FWMTS (0x0004), id: PAL/DK NICAM
(000c00e0), size: 169
Firmware 18, type: STD FW(0x), id: SECAM/K1 (0020),
size: 161
Firmware 19, type: STD FWMTS (0x0004), id: SECAM/K1 (0020),
size: 169
Firmware 20, type: STD FW(0x), id: SECAM/K3 (0400),
size: 161
Firmware 21, type: STD FWMTS (0x0004), id: SECAM/K3 (0400),
size: 169
Firmware 22, type: STD FWD2633 DTV6 ATSC (0x00010030), id:
(), size: 149
Firmware 23, type: STD FWD2620 DTV6 QAM (0x0068), id:
(), size: 149
Firmware 24, type: STD FWD2633 DTV6 QAM (0x0070), id:
(), size: 149
Firmware 25, type: STD FWD2620 DTV7 (0x0088), id: (),
size: 149
Firmware 26, type: STD FWD2633 DTV7 (0x0090), id: (),
size: 149
Firmware 27, type: STD FWD2620 DTV78 (0x0108), id: (),
size: 149
Firmware 28, type: STD FWD2633 DTV78 (0x00
Re: [PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
stefan.rin...@arcor.de wrote:
> From: Stefan Ringel
>
> Signed-off-by: Stefan Ringel
> ---
> drivers/media/common/tuners/tuner-xc2028.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c
> b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..fcf19cc 100644
> --- a/drivers/media/common/tuners/tuner-xc2028.c
> +++ b/drivers/media/common/tuners/tuner-xc2028.c
> @@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
>
> /* All S-code tables need a 200kHz shift */
> if (priv->ctrl.demod) {
> - demod = priv->ctrl.demod + 200;
> + if ((strcmp (priv->ctrl.fname, "xc3028L-v36.fw") == 0) &&
> + (priv->ctrl.demod == XC3028_FE_ZARLINK456) &&
> + ((type & DTV78) || (type & DTV8)))
> + demod = priv->ctrl.demod;
> + else
> + demod = priv->ctrl.demod + 200;
> /*
>* The DTV7 S-code table needs a 700 kHz shift.
>* Thanks to Terry Wu for reporting this
The idea behind this patch is right, but you should be testing it against
priv->firm_version, instead comparing with a file name.
Also, this will likely cause regressions on other drivers, since the offsets for
v3.6 firmwares were handled on a different way on other drivers. I prefer to
postpone
this patch and the discussion behind it after having tm6000 driver ready, since
it makes no sense to cause regressions or request changes on existing drivers
due
to a driver that is not ready yet.
So, please hold your patch on your queue for now.
My suggestion is that you should use git and have this patch on a separate
branch where you
do your tests, having a branch without this patch for upstream submission.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
