On Wednesday, June 15, 2011 22:49:39 Devin Heitmueller wrote:
> On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil <hverk...@xs4all.nl> wrote:
> > But the driver has that information, so it should act accordingly.
> >
> > So on first open you can check whether the current input has a tuner and
> > power on the tuner in that case. On S_INPUT you can also poweron/off
> > accordingly
> > (bit iffy against the spec, though). So in that case the first use case
> > would
> > actually work. It does require that tuner-core.c supports s_power(1), of
> > course.
>
> This will get messy, and is almost certain to get screwed up and cause
> regressions at least on some devices.
I don't see why this should be messy. Anyway, this is all theoretical as long
as tuner-core doesn't support s_power(1). Let's get that in first.
> > BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner
> > when called. I think it should be added, even though most (all?) tuners will
> > need time before they can return anything sensible.
>
> Bear in mind that some tuners can take several seconds to load
> firmware when powered up. You don't want a situation where the tuner
> is reloading firmware continuously, the net result being that calls to
> v4l2-ctl that used to take milliseconds now take multiple seconds.
Yes, but calling VIDIOC_G_TUNER is a good time to wake up the tuner :-)
> > BTW2: it's not a good idea to just broadcast s_power to all subdevs. That
> > should
> > be done to the tuner(s) only since other subdevs might also implement
> > s_power.
> > For now it's pretty much just tuners and some sensors, though.
> >
> > You know, this really needs to be a standardized module option and/or sysfs
> > entry: 'always on', 'wake up on first open', 'wake up on first use'.
>
> That would definitely be useful, but it shouldn't be a module option
> since you can have multiple devices using the same module.
Of course, I forgot about that.
> It really
> should be an addition to the V4L API.
This would actually for once be a good use of sysfs.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
