Hi Laurent, On 08/08/2011 05:44 PM, Laurent Pinchart wrote: > Hi Sylwester, > > On Monday 08 August 2011 17:36:32 Sylwester Nawrocki wrote: >> Hi everyone, >> >> Nowadays many of the V4L2 camera device drivers heavily depend on the board >> code to set up voltage supplies, clocks, and some control signals, like >> 'reset' and 'standby' signals for the sensors. Those things are often >> being done by means of the driver specific platform data callbacks. >> >> There has been recently quite a lot effort on ARM towards migration to the >> device tree. Unfortunately the custom platform data callbacks effectively >> prevent the boards to be booted and configured through the device tree >> bindings. >> >> The following is usually handled in the board files: >> >> 1) sensor/frontend power supply >> 2) sensor's master clock (provided by the host device) >> 3) reset and standby signals (GPIO) >> 4) other signals applied by the host processor to the sensor device, e.g. >> I2C level shifter enable, etc. >> >> For 1), the regulator API should possibly be used. It should be applicable >> for most, if not all cases. >> 3) and 4) are a bit hard as there might be huge differences across boards >> as how many GPIOs are used, what are the required delays between changes >> of their states, etc. Still we could try to find a common description of >> the behaviour and pass such information to the drivers. >> >> For 2) I'd like to propose adding a callback to struct v4l2_device, for >> instance as in the below patch. The host driver would implement such an >> operation and the sensor subdev driver would use it in its s_power op. > > What about using a struct clk object ? There has been lots of work in the ARM > tree to make struct clk generic. I'm not sure if all patches have been pushed > to mainline yet, but I think that's the direction we should follow. But is the 'struct clk' tried to be unified across all archs, not only ARM ? I'm afraid it's not the case. By "using a struct clk object" do you also mean implementing some/all ops of this object by the driver which exports it ? I suppose we can't rely only on the clock controller functionality exposed through the clock API. Some devices may need to be brought to an active state before the clock can be used outside. Some may have internal frequency dividers which need to be handled in addition to the clock path in the clock controller. For instance, on Exynos4 the FIMC devices belong to a power domain that needs to be enabled so the clock is not blocked, and this is done through the runtime PM calls. Normally the host device driver runtime resumes the device when /dev/video* is opened. But we might want to use the clock before it happens, when only a /dev/v4l-subdev* is opened, to play with the sensor device only. In this situation the host device needs to be runtime resumed first. Thus the driver would need to (re)implement the clock ops to also handle the details which are not covered by the clock controller driver. I also wonder how could we support the boards which choose to use some extra external oscillator to provide clock to the sensors, rather than the one derived from the host. Thanks, -- Sylwester Nawrocki Samsung Poland R&D Center -- 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
