Hi Sakari, On 10/23/2011 10:07 AM, Sakari Ailus wrote: > 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? 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. > >>>> 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. Last time I checked, a reference platform migration to common clk struct was being prepared for OMAP. So hopefully we are close to the agreement. I think there is a speech about this during ELCE. -- Regards, Sylwester -- 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
