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

[Sakari Ailus <sakari.ailus@iki.fi>]

Hi Sylwester,

Sylwester Nawrocki wrote:
...
>> I understand what you're saying, but can you give us a specific example,
>> when a subdev driver (your SoC internal subdev, that is) doesn't have a
>> way to react to an event itself and only the bridge driver gets called
>> into at that time? Something like an interrupt or an internal timer or
>> some other internal event?
> 
> 1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises
>  of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV Out.
>  For instance the master video clock is during normal operation derived from
>  (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can
>  switch to this clock only when the HDMI-PHY (subdev) power and clocks are enabled.
>  And it should be done before .s_stream(), to do some H/W configuration earlier
>  in the pipeline, before streaming is enabled. Perhaps Tomasz could give some
>  further explanation of what the s_power() op does and why in the driver. 
>  
> 2. In some of our camera pipeline setups - "Sensor - MIPI-CSI receiver - host/DMA",
>  the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So the  
>  MIPI-CSI receiver must always be powered on before the sensor. With the subdevs
>  doing their own magic wrt to power control the situation is getting slightly
>  out of control. 

How about this: CSI-2 receiver implements a few new regulators which the
sensor driver then requests to be enabled. Would that work for you?

>>> I guess we all agree the power requirements of external subdevs are generally
>>> unknown to the hosts.
>>>
>>> For these it might make lot of sense to let the subdev driver handle the device
>>> power supplies on basis of requests like, s_ctrl, s_stream, etc.
>>
>> Yes, right, so, most "external" (sensor, decoder,...) subdev drivers
>> should never need to implement .s_power(), regardless of whether we decide
>> to keep it or not. Well, ok, no, put it differently - in those drivers
>> .s_power() should only really be called during system-wide suspend /
>> resume.
> 
> Yes, I agree with that. But before we attempt to remove .s_power() or deprecate 
> it on "external" subdevs, I'd like to get solved the issue with sensor master clock 
> provided by the bridge. As these two are closely related - the sensor controller 
> won't boot if the clock is disabled. And there are always advantages of not keeping
> the clock always enabled. 

I guess we'll need to wait awhile before the clock framework would
support this. I don't know what's the status of this; probably worth
checking.

Regards,

-- 
Sakari Ailus
sakari.ailus@iki.fi