* Re: DT bindings for subdevices
2013-01-02 10:19 ` Guennadi Liakhovetski
@ 2013-01-03 5:00 ` Prabhakar Lad
2013-01-03 10:46 ` Laurent Pinchart
2013-01-04 13:04 ` Prabhakar Lad
2 siblings, 0 replies; 6+ messages in thread
From: Prabhakar Lad @ 2013-01-03 5:00 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-media, Sylwester Nawrocki, Laurent Pinchart, Hans Verkuil,
Sakari Ailus
Hi Guennadi,
Thanks for your response!
On Wed, Jan 2, 2013 at 3:49 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> Hi Prabhakar
>
> 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
>
Thanks for the links.
>> 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.
>
Ok
>> 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
Yes its the external clock frequency.
> 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.
>
Ok.
>> };
>> 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.
>
>> 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.
>
Ok.
Regards,
--Prabhakar
> Thanks
> Guennadi
>
>> };
>>
>> should this all be individual properties ?
>>
>> Regards,
>> --Prabhakar
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: DT bindings for subdevices
2013-01-02 10:19 ` Guennadi Liakhovetski
2013-01-03 5:00 ` Prabhakar Lad
@ 2013-01-03 10:46 ` Laurent Pinchart
2013-01-04 13:04 ` Prabhakar Lad
2 siblings, 0 replies; 6+ messages in thread
From: Laurent Pinchart @ 2013-01-03 10:46 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Prabhakar Lad, linux-media, Sylwester Nawrocki, Hans Verkuil,
Sakari Ailus
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: DT bindings for subdevices
2013-01-02 10:19 ` Guennadi Liakhovetski
2013-01-03 5:00 ` Prabhakar Lad
2013-01-03 10:46 ` Laurent Pinchart
@ 2013-01-04 13:04 ` Prabhakar Lad
2013-01-04 13:21 ` Guennadi Liakhovetski
2 siblings, 1 reply; 6+ messages in thread
From: Prabhakar Lad @ 2013-01-04 13:04 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: linux-media, Sylwester Nawrocki, Laurent Pinchart, Hans Verkuil,
Sakari Ailus
Hi Guennadi,
On Wed, Jan 2, 2013 at 3:49 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> Hi Prabhakar
>
> 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.
>
Few more doubts:
1: The vl42-async/deferred probing would be required for all the devices
implementing FDT if I am not wrong ?
Regards,
--Prabhakar
>> };
>> 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.
>
>> 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,
>> --Prabhakar
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: DT bindings for subdevices
2013-01-04 13:04 ` Prabhakar Lad
@ 2013-01-04 13:21 ` Guennadi Liakhovetski
0 siblings, 0 replies; 6+ messages in thread
From: Guennadi Liakhovetski @ 2013-01-04 13:21 UTC (permalink / raw)
To: Prabhakar Lad
Cc: linux-media, Sylwester Nawrocki, Laurent Pinchart, Hans Verkuil,
Sakari Ailus
On Fri, 4 Jan 2013, Prabhakar Lad wrote:
> Hi Guennadi,
>
> On Wed, Jan 2, 2013 at 3:49 PM, Guennadi Liakhovetski
> <g.liakhovetski@gmx.de> wrote:
> > Hi Prabhakar
> >
> > 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.
> >
> Few more doubts:
> 1: The vl42-async/deferred probing would be required for all the devices
> implementing FDT if I am not wrong ?
There is, of course, more than one way to do it, but that's how we want to
have it, yes. We want your I2C camera sensors be specified in the DT in a
standard way - as children of the respective I2C adapter DT node, which
means they can be probed at any time. And we do want their probing
functions to have the ability to really access the hardware, if all the
conditions are satisfied, e.g. if all resources are available. Which is
exactly why we need asynchronous probing.
Thanks
Guennadi
> Regards,
> --Prabhakar
>
> >> };
> >> 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.
> >
> >> 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,
> >> --Prabhakar
> >
> > ---
> > Guennadi Liakhovetski, Ph.D.
> > Freelance Open-Source Software Developer
> > http://www.open-technology.de/
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply [flat|nested] 6+ messages in thread