Re: DT bindings for subdevices

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi,

On Wednesday 02 January 2013 11:19:04 Guennadi Liakhovetski wrote:
> On Wed, 2 Jan 2013, Prabhakar Lad wrote:
> > Hi,
> > 
> > This is my first step towards DT support for media, Question might be
> > bit amateur :)
> 
> No worries, we're all doing our first steps in this direction right at the
> moment. These two recent threads should give you an idea as to where we
> stand atm:
> 
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646
> 
> and (optionally, to a lesser extent)
> 
> http://www.spinics.net/lists/linux-media/index.html#57836
> 
> > In the video pipeline there will be external devices (decoders/camera)
> > connected via i2c, spi, csi. This sub-devices take platform data. So
> > question is moving ahead and adding DT support for this subdevices how
> > should this platform data be passed through. Should it be different
> > properties for different devices.
> 
> Mostly, yes.
> 
> > For example the mt9t001 sensor takes following platform data:
> > struct mt9t001_platform_data {
> > 
> > 	unsigned int clk_pol:1;
> 
> This would presumably be the standard "pclk-sample" property from the
> first of the above two quoted threads
> 
> > 	unsigned int ext_clk;
> 
> Is this the frequency? This should be replaced by a phandle, linking to a
> clock device-tree node, assuming, your platform is implementing the
> generic clock API. If it isn't yet, not a problem either:-) In either case
> your sensor driver shall be using the v4l2_clk API to retrieve the clock
> rate and your camera host driver should be providing a matching v4l2_clk
> instance and implementing its methods, including retrieving the frequency.
> 
> > };
> > similarly mt9p031 takes following platform data:
> > 
> > struct mt9p031_platform_data {
> > 
> > 	int (*set_xclk)(struct v4l2_subdev *subdev, int hz);
> 
> Not sure what the xclk is, but, presumable, this should be ported to
> v4l2_clk too.

I'm porting the OMAP3 ISP driver to the common clock framework and have ported 
the mt9p031 driver in the process. I still need to test the patches, I'll then 
post them.

> > 	int reset;
> 
> This is a GPIO number, used to reset the chip. You should use a property,
> probably, calling it "reset-gpios", specifying the desired GPIO.
> 
> > 	int ext_freq;
> > 	int target_freq;
> 
> Presumably, ext_freq should be retrieved, using v4l2_clk_get_rate() and
> target_freq could be a proprietary property of your device.
> 
> Thanks
> Guennadi
> 
> > };
> > 
> > should this all be individual properties ?

-- 
Regards,

Laurent Pinchart