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@xxxxxx -- 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
