From: Antti Palosaari <crope@iki.fi>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: "Hawes, Mark" <MARK.HAWES@au.fujitsu.com>, linux-media@vger.kernel.org
Subject: Re: HVR 4000 hybrid card still producing multiple frontends for single adapter
Date: Tue, 24 Jan 2012 16:58:45 +0200 [thread overview]
Message-ID: <4F1EC725.7090204@iki.fi> (raw)
In-Reply-To: <CAGoCfizF=aO-JTLLCAK=QgsPSVP13SzbB9j6wCFfVzGXc4hnfw@mail.gmail.com>
On 01/24/2012 04:49 PM, Devin Heitmueller wrote:
> On Tue, Jan 24, 2012 at 6:48 AM, Antti Palosaari<crope@iki.fi> wrote:
>> On 01/24/2012 06:41 AM, Hawes, Mark wrote:
>>>
>>> Hi,
>>>
>>> I have a HVR 4000 hybrid card which provides both DVB-S2 and DVB-T
>>> capabilities on the one adapter. Using the current media tree build updated
>>> with the contents of the linux media drivers tarball dated 22/01/2012 the
>>> drivers for this card are still generating two frontends on the adapter as
>>> below:
>>>
>>>> Jan 23 12:16:44 Nutrigrain kernel: [ 9.346240] DVB: registering
>>>> adapter 1 frontend 0 (Conexant CX24116/CX24118)...
>>>> Jan 23 12:16:44 Nutrigrain kernel: [ 9.349110] DVB: registering
>>>> adapter 1 frontend 1 (Conexant CX22702 DVB-T)...
>>>
>>>
>>> I understand that this behaviour is now deprecated and that the correct
>>> behaviour should be to generate one front end with multiple capabilities.
>>> Can this please be corrected.
>>
>>
>> Same applies for many other devices too. For example some older Anysee E7
>> models have two chip and two frontends whilst new one have only one. Also
>> TechnoTrend CT3650 and Hauppauge WinTV.
>>
>> Maybe it those are implemented later as one frontend, it not clear for me.
>
> The merging of frontends is something that is only done if there are
> multiple modulation types on the same demodulator chip. As the
> HVR-4000 has separate demods for DVB-T versus DVB-S2, they will always
> be represented by two separate frontends (for the foreseeable future).
>
> In other words, the recent work doesn't apply to this card (and others like it).
So what was the actual benefit then just introduce one way more to
implement same thing. As I sometime understood from Manu's talk there
will not be difference if my device is based of DVB-T + DVB-C demod
combination or just single chip that does same. Now there is devices
that have same characteristics but different interface.
regards
Antti
--
http://palosaari.fi/
next prev parent reply other threads:[~2012-01-24 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 4:41 HVR 4000 hybrid card still producing multiple frontends for single adapter Hawes, Mark
2012-01-24 11:48 ` Antti Palosaari
2012-01-24 14:49 ` Devin Heitmueller
2012-01-24 14:58 ` Antti Palosaari [this message]
2012-01-24 15:16 ` Devin Heitmueller
2012-01-24 15:37 ` Antti Palosaari
2012-01-24 18:37 ` Lars Hanisch
2012-01-24 17:14 ` Manu Abraham
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=4F1EC725.7090204@iki.fi \
--to=crope@iki.fi \
--cc=MARK.HAWES@au.fujitsu.com \
--cc=dheitmueller@kernellabs.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