All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Michael Krufky <mkrufky@kernellabs.com>
Cc: linux-media <linux-media@vger.kernel.org>
Subject: Re: [RFC] Allow bridge drivers to have better control over DVB frontend operations
Date: Fri, 04 Sep 2009 18:11:19 +0300	[thread overview]
Message-ID: <4AA12E17.4080006@iki.fi> (raw)
In-Reply-To: <37219a840909012132l6c04af65hddecd2d52e196bcb@mail.gmail.com>

On 09/02/2009 07:32 AM, Michael Krufky wrote:
> Over the course of the past year, a number of developers have
> expressed a need for giving the bridge drivers better control over
> dvb_frontend operations.  Specifically, there is a need for the bridge
> driver to receive a DVB frontend IOCTL and have the opportunity to
> allow or deny the IOCTL to proceed, as resources permit.
>
> For instance, in the case of a hybrid device, only the bridge driver
> knows whether the analog functionality is presently being used.  If
> the driver is currently in analog mode, serving video frames, the
> driver will have a chance to deny the DVB frontend ioctl request
> before dvb-core passes the request on to the frontend driver,
> potentially damaging the analog video stream already in progress.
>
> In some cases, the bridge driver might have to perform a setup
> operation to use a feature specific to the device.  For instance, the
> bridge device may be in a low powered state - this new capability
> allows the driver to wake up before passing the command on to the
> frontend driver.  This new feature will allow LinuxTV developers to
> finally get working on actual power management support within the
> v4l/dvb subsystem, without the fear of breaking devices with hybrid
> analog / digital functionality.
>
> In other cases, there may be situations in which multiple RF
> connectors are available to the tuner, but only the bridge driver will
> be aware of this, as this type of thing is specific to the device's
> hardware implementation.  As there are many tuners capable of multiple
> RF spigots, not all devices actually employ this feature - only the
> bridge driver knows what implementations support such features, and
> how to enable / disable them.
>
> The possibilities are endless.  I actually did all the heavy lifting
> involved in this a few months ago, but haven't had a moment to write
> up this RFC until now.
>
> The change to dvb-core that allows this new functionality is posted to
> my development repository on kernellabs.com.  I have also included an
> example of how this can be used on a digital tuner board with multiple
> RF inputs.  The multiple RF input switching is already supported in
> today's code, but I promised Mauro that I would present a better
> method of doing this before the upcoming merge window.  For your
> review and comments, please take a look at the topmost changesets,
> starting with "create a standard method for dvb adapter drivers to
> override frontend ioctls":
>
> http://kernellabs.com/hg/~mkrufky/fe_ioctl_override

Idea looks very good! I tested one DVB USB device need blocking IOCTLs 
when demod and tuner are power save and didn't saw functionality problems.

However, it was a little bit hard to add callback to DVB USB driver. 
Could that callback be added to the struct dvb_usb_adapter_properties 
for simplify things? I have feeling that this callback will be useful 
most DVb USB devices - setting GPIOs and clock settings for power save.

Name fe_ioctl_override sounds like whole IOCTL will be replaced with new 
one which is not true. Still, I don't know which could be better name.

Antti
-- 
http://palosaari.fi/

  parent reply	other threads:[~2009-09-04 15:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  4:32 [RFC] Allow bridge drivers to have better control over DVB frontend operations Michael Krufky
2009-09-02 22:19 ` hermann pitton
2009-09-04 15:11 ` Antti Palosaari [this message]
2009-09-04 15:28   ` Michael Krufky
2009-09-07 16:55     ` Michael Krufky
2009-09-08 16:41       ` Steven Toth

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=4AA12E17.4080006@iki.fi \
    --to=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=mkrufky@kernellabs.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.