From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: gennarone@gmail.com
Cc: linux-media list <linux-media@vger.kernel.org>
Subject: Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Date: Wed, 07 Dec 2011 13:05:19 -0200 [thread overview]
Message-ID: <4EDF80AF.5060709@redhat.com> (raw)
In-Reply-To: <4EDF7DF3.1080007@gmail.com>
On 07-12-2011 12:53, Gianluca Gennari wrote:
> Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
>> On 07-12-2011 11:47, Gianluca Gennari wrote:
>>> Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
>>>> On 06-12-2011 12:33, Gianluca Gennari wrote:
>>>>> Hi All,
>>>>>
>>>>> I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042).
>>>>> This device is made of the following components:
>>>>> - Empiatech em2880 USB bridge;
>>>>> - Zarlink zl10353 demodulator;
>>>>> - Xceive XC3028 tuner;
>>>>>
>>>>> For this device, the ZARLINK456 define is set to true so it is using
>>>>> the
>>>>> firmwares with type D2633 for the XC3028 tuner.
>>>>>
>>>>> I found out that:
>>>>> 1) the DTV7 firmware works fine in VHF band (bw=7MHz);
>>>>> 2) the DTV8 firmware works fine in UHF band (bw=8MHz);
>>>>> 3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
>>>>> work at all in VHF band (bw=7MHz);
>>>>>
>>>>> In fact, when the DTV78 firmware is loaded and I try to tune a VHF
>>>>> channel, the frequency lock is ciclically acquired for a second and
>>>>> immediately lost.
>>>>> So the proposed patch forces a reload of the DTV7 firmware every time a
>>>>> 7MHz channel is requested.
>>>>> The only drawback is that channel change from VHF to UHF or
>>>>> viceversa is
>>>>> slightly slower.
>>>>> Devices using the D2620 firmwares are unaffected.
>>>>
>>>> Hi Gianluca,
>>>>
>>>> The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
>>>> do,
>>>> we end by having troubles, as the issue is Country-dependent. For
>>>> example,
>>>> Australia requires a different firmware than Germany, due to the
>>>> differences
>>>> on the VHF/UHF bands.
>>>>
>>>> I prefer if you could work into a patch that would add some modprobe
>>>> parameter
>>>> to disable the current "autodetection" way, allowing to override the
>>>> firmware
>>>> used for VHF and UHF.
>>>>
>>>> Thanks,
>>>> Mauro
>>>>
>>>
>>> Hi Mauro,
>>> thanks for the feedback. Unfortunately I do not have any info on which
>>> kind of firmware is needed on other parts of the world. All I know is
>>> what is happening here in Italy, and what I can understand reading the
>>> code. I suppose my findings can be extended to the rest of Europe, and
>>> maybe Africa and Middle-East.
>>
>> Even in Europe, there are some differences.
>>
>
> OK, so the validity of my findings are restricted to Italy.
>
>>> Can you provide a reference about problems in other continents like
>>> Australia?
>>
>> All I know is from the constant reports at the ML from users. We used to
>> have a developer in Australia, but he moved away, and it seems that he lost
>> interest on DVB development, as we were unable to contact him ever since.
>>>
>>> Do you think a simple module parameters that allows to enable/disable
>>> the usage of the DTV78 firmware would do the trick?
>>
>> Perhaps one or two module parameters to allow forcing a certain firmware
>> for
>> VHF and UHF.
>
> Seems reasonable.
>
>>> Eventually, do you agree that the default solution should be to DISABLE
>>> DTV78 firmware, since this seems to be the more robust solution, and let
>>> the user enable it through the kernel parameter if it is working in his
>>> country? Or do you prefer the other way around, so by default DTV78
>>> firmware is enabled, and users with problems can disable it through the
>>> kernel module parameter?
>>
>> AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
>> default doesn't look a good idea, as it will cause regressions, if the new
>> way is not backward-compatible.
>
> With the proposed patch DTV78 will be used in UHF band, while DTV7 in
> VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
> What about a kernel parameter to specify the country?
> Something like:
>
> country={0-4}
>
> DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
>
> Then we could specify a well-defined behavior for each country, hiding
> the firmware-related problems to the user (which will have problems
> understanding parameters like force-DTV7-firmware-in-VHF-band).
>
> All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.
As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio demodulation standard,
due to the same reasons.
Regards,
Mauro
next prev parent reply other threads:[~2011-12-07 15:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 14:33 [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator Gianluca Gennari
2011-12-06 14:34 ` [PATCH 1/1] " Gianluca Gennari
2011-12-07 13:12 ` [PATCH 0/1] " Mauro Carvalho Chehab
2011-12-07 13:47 ` Gianluca Gennari
2011-12-07 14:20 ` Mauro Carvalho Chehab
[not found] ` <4EDF7DF3.1080007@gmail.com>
2011-12-07 15:05 ` Mauro Carvalho Chehab [this message]
[not found] ` <4EDF8A22.6020201@gmail.com>
2011-12-07 15:51 ` Gianluca Gennari
2011-12-07 16:21 ` Mauro Carvalho Chehab
2011-12-07 17:25 ` Gianluca Gennari
2011-12-07 18:58 ` Mauro Carvalho Chehab
[not found] ` <4EDFBF17.5040407@gmail.com>
2011-12-07 19:49 ` Mauro Carvalho Chehab
2011-12-07 21:54 ` Christoph Pfister
2011-12-08 10:04 ` Mauro Carvalho Chehab
-- strict thread matches above, loose matches on Subject: below --
2011-12-08 1:36 Gianluca Gennari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDF80AF.5060709@redhat.com \
--to=mchehab@redhat.com \
--cc=gennarone@gmail.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).