public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars Hanisch <dvb@flensrocker.de>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Antti Palosaari <crope@iki.fi>,
	"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 19:37:34 +0100	[thread overview]
Message-ID: <4F1EFA6E.50704@flensrocker.de> (raw)
In-Reply-To: <CAGoCfiwZ2_+rQgXxq9DF_veGZ8vqaZf2JtUSi8SyLW_pd6VFAA@mail.gmail.com>

Hi,

Am 24.01.2012 16:16, schrieb Devin Heitmueller:
> On Tue, Jan 24, 2012 at 9:58 AM, Antti Palosaari<crope@iki.fi>  wrote:
>> 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.
>
> For one thing, you cannot use DVB-T and DVB-C at the same time if
> they're on the same demod.  With many of the devices that have S/S2
> and DVB-T, you can be using them both in parallel.  Having multiple
> frontends actually makes sense since you don't want two applications
> talking to the same frontend at the same time but operating on
> different tuners/streams.

  The two frontends of the HVR 4000 can only be open mutually exclusive so I think the recent changes are for those 
devices, aren't they? Sure you can connect DVB-T and DVB-S at the same time to the HVR 4000, but you can't use it in 
parallel.

Lars.

>
> That said, there could be opportunities for consolidation if the
> demods could not be used in parallel, but I believe that would require
> a nontrivial restructuring of the core code and API.  In my opinion
> the entry point for the kernel ABI should *never* have been the
> demodulator but rather the bridge driver (where you can exercise
> greater control over what can be used in parallel).
>
> Devin
>

  parent reply	other threads:[~2012-01-24 18:37 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
2012-01-24 15:16       ` Devin Heitmueller
2012-01-24 15:37         ` Antti Palosaari
2012-01-24 18:37         ` Lars Hanisch [this message]
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=4F1EFA6E.50704@flensrocker.de \
    --to=dvb@flensrocker.de \
    --cc=MARK.HAWES@au.fujitsu.com \
    --cc=crope@iki.fi \
    --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