[01/11] xc2028: tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift

  From: Stefan Ringel <stefan.ringel@arcor.de>

Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
  

On Mon, Feb 15, 2010 at 12:37 PM,  <stefan.ringel@arcor.de> wrote:
> From: Stefan Ringel <stefan.ringel@arcor.de>
>
> Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
>
> diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c
> index ed50168..e051caa 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 ((priv->firm_version == 0x0306) &&
> +                       (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 <terrywu2009@gmail.com> for reporting this

I would still like to better understand the origin of this change.
Was the tm6000 board not locking without it?  Was this change based on
any documented source?  What basis are you using when deciding this
issue is specific only to the zl10353 and not all boards using the
xc3028L?

We've got a number of boards already supported which use the xc3028L,
so we need to ensure there is no regression introduced in those boards
just to get yours working.

Devin
  

Am 15.02.2010 19:36, schrieb Devin Heitmueller:
> On Mon, Feb 15, 2010 at 12:37 PM,  <stefan.ringel@arcor.de> wrote:
>   
>> From: Stefan Ringel <stefan.ringel@arcor.de>
>>
>> Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
>>
>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c
>> index ed50168..e051caa 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 ((priv->firm_version == 0x0306) &&
>> +                       (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 <terrywu2009@gmail.com> for reporting this
>>     
> I would still like to better understand the origin of this change.
> Was the tm6000 board not locking without it?  Was this change based on
> any documented source?  What basis are you using when deciding this
> issue is specific only to the zl10353 and not all boards using the
> xc3028L?
>
> We've got a number of boards already supported which use the xc3028L,
> so we need to ensure there is no regression introduced in those boards
> just to get yours working.
>
> Devin
>
>   
Devin here in attachment the firmware table. You see, that it is has two
entries  for ZARLINK456, one for QAM, DTV6 and DTV7, and one for DTV78
and DTV8. The first have a shift from +200, the second doesn't. I can
test for you without this patch to see what for demodulator status is has.

Stefan Ringel
  

Am 15.02.2010 20:19, schrieb Stefan Ringel:
> Am 15.02.2010 19:36, schrieb Devin Heitmueller:
>   
>> On Mon, Feb 15, 2010 at 12:37 PM,  <stefan.ringel@arcor.de> wrote:
>>   
>>     
>>> From: Stefan Ringel <stefan.ringel@arcor.de>
>>>
>>> Signed-off-by: Stefan Ringel <stefan.ringel@arcor.de>
>>>
>>> diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c
>>> index ed50168..e051caa 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 ((priv->firm_version == 0x0306) &&
>>> +                       (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 <terrywu2009@gmail.com> for reporting this
>>>     
>>>       
>> I would still like to better understand the origin of this change.
>> Was the tm6000 board not locking without it?  Was this change based on
>> any documented source?  What basis are you using when deciding this
>> issue is specific only to the zl10353 and not all boards using the
>> xc3028L?
>>
>> We've got a number of boards already supported which use the xc3028L,
>> so we need to ensure there is no regression introduced in those boards
>> just to get yours working.
>>
>> Devin
>>
>>   
>>     
> Devin here in attachment the firmware table. You see, that it is has two
> entries  for ZARLINK456, one for QAM, DTV6 and DTV7, and one for DTV78
> and DTV8. The first have a shift from +200, the second doesn't. I can
> test for you without this patch to see what for demodulator status is has.
>
> Stefan Ringel
>
>   
Darvin,
I have the test result. The first once is with my patch and the second
without my patch.