Sylwester Nawrocki wrote: > 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. 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 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 platform code to do this which is not quite compatible with the idea of the device tree. -- 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
