RFC: Use of s_std calling s_freq when tuner powered down

RFC: Use of s_std calling s_freq when tuner powered down

[Devin Heitmueller]

Hello all,

Here's the scenario:

1.  I have a USB device that supports both an analog tuner and
composite/s-video inputs
2.  The bridge is smart enough to power down the tuner when capturing
on composite/s-video
3.  Changing the video standard appears to send set_freq() calls to
the tuner, which in i2c fail because it's powered down.

So I looked at the tuner-core code, and I'm seeing that tuner_s_std()
will call set_freq() if the tuner->tv_freq field is nonzero.  This
seems reasonable, except as far as I can tell there is no way to set
it to zero (because the places that set the value to zero will return
failure because zero is outside the tuning range).

This behavior happens with tvtime, which always does a tuning on
startup, before switching to the A/V inputs.  While I agree that I
should probably fix tvtime so it doesn't do this, it seems strange
that there is no way to reset tv_freq to zero when toggling away from
the tuner input, so that these errors don't occur.

Any thoughts?  Obviously I would like to eliminate the i2c errors from
littering the dmesg log when there is no real failure condition.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: RFC: Use of s_std calling s_freq when tuner powered down

[Andy Walls]

On Fri, 2010-07-09 at 14:09 -0400, Devin Heitmueller wrote:
> Hello all,
> 
> Here's the scenario:
> 
> 1.  I have a USB device that supports both an analog tuner and
> composite/s-video inputs
> 2.  The bridge is smart enough to power down the tuner when capturing
> on composite/s-video
> 3.  Changing the video standard appears to send set_freq() calls to
> the tuner, which in i2c fail because it's powered down.
> 
> So I looked at the tuner-core code, and I'm seeing that tuner_s_std()
> will call set_freq() if the tuner->tv_freq field is nonzero.  This
> seems reasonable, except as far as I can tell there is no way to set
> it to zero (because the places that set the value to zero will return
> failure because zero is outside the tuning range).
> 
> This behavior happens with tvtime, which always does a tuning on
> startup, before switching to the A/V inputs.  While I agree that I
> should probably fix tvtime so it doesn't do this, it seems strange
> that there is no way to reset tv_freq to zero when toggling away from
> the tuner input, so that these errors don't occur.
> 
> Any thoughts?

At the risk of missing something obvious:

In your bridge driver's VIDIOC_S_STD ioctl()

a. power up the analog tuner if it is not already
b. call s_std for the subdevices (including the tuner),
c. power down that analog tuner if not using the tuner input.

No I2C errors in the log and the tuner is powered down when not in use,

IMO, VIDIOC_S_STD is not a timing critical operation from userspace and
it doesn't happen that often.  You can also filter the cases when
VIDIOC_S_STD is called on the same input, but the standard is not being
changed.

Regards,
Andy

>   Obviously I would like to eliminate the i2c errors from
> littering the dmesg log when there is no real failure condition.


> Devin

Re: RFC: Use of s_std calling s_freq when tuner powered down

[Devin Heitmueller]

Hi Andy,

On Sun, Jul 11, 2010 at 9:23 AM, Andy Walls <awalls@md.metrocast.net> wrote:
> At the risk of missing something obvious:
>
> In your bridge driver's VIDIOC_S_STD ioctl()
>
> a. power up the analog tuner if it is not already
> b. call s_std for the subdevices (including the tuner),
> c. power down that analog tuner if not using the tuner input.
>
> No I2C errors in the log and the tuner is powered down when not in use,
>
> IMO, VIDIOC_S_STD is not a timing critical operation from userspace and
> it doesn't happen that often.  You can also filter the cases when
> VIDIOC_S_STD is called on the same input, but the standard is not being
> changed.

Thanks for taking the time to provide feedback.

It's not timing critical, but on some tuners initialization can take
several seconds (e.g. tda18271, xc5000).  I'm not thrilled about it
taking 3-5 seconds to change the standard (something which some
applications may very well do on every channel change).

I'm tempted to just jam a zero into the tuner->tv_freq when powering
down the tuner, but that's not a very clean solution obviously.

The tuner core makes decisions based on tuner->tv_freq not being zero,
so I believe tuner_core should provide some way to reset it back to
zero as needed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com