Re: [RFC] subdevice PM: .s_power() deprecation?

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

 



Hi Sylwester,

On Monday 17 October 2011 23:26:28 Sylwester Nawrocki wrote:
> On 10/17/2011 05:23 PM, Guennadi Liakhovetski wrote:
> > On Mon, 17 Oct 2011, Sylwester Nawrocki wrote:
> >> On 10/17/2011 03:49 PM, Guennadi Liakhovetski wrote:
> >>> On Mon, 17 Oct 2011, Sylwester Nawrocki wrote:
> >>>> On 10/17/2011 10:06 AM, Guennadi Liakhovetski wrote:
> >>>>> On Sun, 9 Oct 2011, Sakari Ailus wrote:
> >>>>>> On Mon, Oct 03, 2011 at 12:57:10PM +0200, Guennadi Liakhovetski 
wrote:
> >> ...
> >> 
> >>>>>> The bridge driver can't (nor should) know about the power management
> >>>>>> requirements of random subdevs. The name of the s_power op is rather
> >>>>>> poitless in its current state.
> >>>>>> 
> >>>>>> The power state of the subdev probably even never matters to the
> >>>>>> bridge ---
> >>>>> 
> >>>>> Exactly, that's the conclusion I come to in this RFC too.
> >>>>> 
> >>>>>> or do we really have an example of that?
> >>>>>> 
> >>>>>> In my opinion the bridge driver should instead tell the bridge
> >>>>>> drivers what they can expect to hear from the bridge --- for
> >>>>>> example that the bridge can issue set / get controls or fmt ops to
> >>>>>> the subdev. The subdev may or may not need to be powered for those:
> >>>>>> only the subdev driver knows.
> >>>>> 
> >>>>> Hm, why should the bridge driver tell the subdev driver (I presume,
> >>>>> that's a typo in your above sentence) what to _expect_? Isn't just
> >>>>> calling those operations enough?
> >>>>> 
> >>>>>> This is analogous to opening the subdev node from user space.
> >>>>>> Anything else except streaming is allowed. And streaming, which for
> >>>>>> sure requires powering on the subdev, is already nicely handled by
> >>>>>> the s_stream op.
> >>>>>> 
> >>>>>> What do you think?
> >>>>>> 
> >>>>>> In practice the name of s_power should change, as well as possible
> >>>>>> implementatio on subdev drivers.
> >>>>> 
> >>>>> But why do we need it at all?
> >>>> 
> >>>> AFAICS in some TV card drivers it is used to put the analog tuner into
> >>>> low power state.
> >>>> So core.s_power op provides the mans to suspend/resume a sub-device.
> >>>> 
> >>>> If the bridge driver only implements a user space interface for the
> >>>> subdev, it may want to bring a subdev up in some specific moment,
> >>>> before video.s_stream, e.g. in some ioctl or at device open(), etc.
> >>>> 
> >>>> Let's imagine bringing the sensor up takes appr. 700 ms, often we
> >>>> don't want the sensor driver to be doing this before every
> >>>> s_stream().
> >>> 
> >>> Sorry, I still don't understand, how the bridge driver knows better,
> >>> than the subdev driver, whether the user will resume streaming in
> >>> 500ms or in 20s? Maybe there's some such information available with
> >>> tuners, which I'm just unaware about?
> >> 
> >> What I meant was that if the bridge driver assumes in advance that
> >> enabling sensor's power and getting it fully operational takes long
> >> time, it can enable sensor's power earlier than it's really necessary,
> >> to avoid excessive latencies during further actions.
> > 
> > Where would a bridge driver get this information from? And how would it
> > know in advance, when power would be "really needed" to enable it
> > "earlier?"...
> 
> I don't think this information could now be retrieved from a subdev in
> standard way.
>
> If a bridge driver wants low latencies it can simply be coded to issue
> s_power(1) before any other op call, and s_power(0) when it's done with a
> subdev.
> 
> >> The bridge driver could also choose to keep the sensor powered on,
> >> whenever it sees appropriate, to avoid re-enabling the sensor to often.
> > 
> > On what basis would the bridge driver make these decisions? How would it
> > know in advance, when it'll have to re-enable the subdev next time?
> 
> Re-enabling by allowing a subdev driver to entirely control the power
> state. The sensor might implement "lowest power consumption" policy, while
> the user might want "highest performance".

Exactly, that's a policy decision. Would PM QoS help here ?

> I'm referring only to camera sensor subdevs, as I don't have much experience
> with other ones.
> 
> Also there are some devices where you want to model power control
> explicitly, and it is critical to overall system operation. The s5p-tv
> driver is one example of these. The host driver knows exactly how the
> power state of its subdevs should be handled.

The host probably knows about how to handle the power state of its internal 
subdevs, but what about external ones ?

> The situation with single subdev and a bridge driver may look like it could
> get away without s_power(), but where multiple subdevs are involved I
> expect the driver writers will want to be able to control the power state.
> 
> It seems s_power() is now used not only in suspend/resume paths so removing
> it for new core.suspend/resume callbacks IMHO would leave some
> functionality not covered.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux