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

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

On 10/23/2011 10:44 AM, Sakari Ailus wrote:
> Sylwester Nawrocki wrote:
...
>>>> 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?
>>
>> No, I don't like that... :)
>>
>> We would have to standardize the regulator supply names, etc. Such approach
>> would be more difficult to align with runtime/system suspend/resume.
>> Also the sensor drivers should be independent on other drivers. The MIPI-CSI
>> receiver is more specific to the host, rather than a sensor.
>>
>> Not all sensors need MIPI-CSI, some just use parallel video bus.
> 
> The sensor drivers are responsible for the regulators they want to use,
> right? If they need no CSI-2 related regulators then they just ignore

Only for the regulator supplies for their device. In this case the sensor
driver would have to touch MIPI-CSI device regulator supplies.

> them as any other regulators the sensor doesn't need.
> 
> The names of the regulators could come from the platform data, they're
> board specific anyway. I can't see another way to do this without having

No, you don't want regulator supply names in any platform data struct.
The platform code binds regulator supplies to the devices, whether it is DT
based or not.

> platform code to do this which is not quite compatible with the idea of
> the device tree.

Now I just use s_power callback in our drivers and it all works well.

--
Regards,
Sylwester