Re: [PATCH/RESEND] soc-camera: add runtime pm support for subdevices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Tue, 9 Feb 2010, Hans Verkuil wrote:
>
>>
>> > On Mon, 8 Feb 2010, Mauro Carvalho Chehab wrote:
>> >
>> >> In fact, on all drivers, there are devices that needs to be turn on
>> only
>> >> when
>> >> streaming is happening: sensors, analog TV/audio demods, digital
>> demods.
>> >> Also,
>> >> a few devices (for example: TV tuners) could eventually be on power
>> off
>> >> when
>> >> no device is opened.
>> >>
>> >> As the V4L core knows when this is happening (due to
>> >> open/close/poll/streamon/reqbuf/qbuf/dqbuf hooks, I think the runtime
>> >> management
>> >> can happen at V4L core level.
>> >
>> > Well, we can move it up to v4l core. Should it get any more
>> complicated
>> > than adding
>> >
>> > 	ret = pm_runtime_resume(&vdev->dev);
>> > 	if (ret < 0 && ret != -ENOSYS)
>> > 		return ret;
>> >
>> > to v4l2_open() and
>> >
>> > 	pm_runtime_suspend(&vdev->dev);
>> >
>> > to v4l2_release()?
>>
>> My apologies if I say something stupid as I know little about pm: are
>> you
>> assuming here that streaming only happens on one device node? That may
>> be
>> true for soc-camera, but other devices can have multiple streaming nodes
>> (video, vbi, mpeg, etc). So the call to v4l2_release does not
>> necessarily
>> mean that streaming has stopped.
>
> Of course you're right, and it concerns not only multiple streaming modes,
> but simple cases of multiple openings of one node. I was too fast to
> transfer the implementation from soc-camera to v4l2 - in soc-camera I'm
> counting opens and closes and only calling pm hooks on first open and last
> close. So, if we want to put it in v4l-core, we'd have to do something
> similar, I presume.

I wouldn't mind having such counters. There are more situations where
knowing whether it is the first open or last close comes in handy.

However, in general I think that pm shouldn't be done in the core. It is
just too hardware dependent. E.g. there may both capture and display video
nodes in the driver. And when the last capture stops you can for example
power down the receiver chips. The same with display and transmitter
chips. But if both are controlled by the same driver, then a general open
counter will not work either.

But if you have ideas to improve the core to make it easier to add pm
support to the drivers that need it, then I am all for it.

Regards,

        Hans

>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux