* DT bindings for subdevices
@ 2013-01-02 9:17 Prabhakar Lad
2013-01-02 10:19 ` Guennadi Liakhovetski
0 siblings, 1 reply; 6+ messages in thread
From: Prabhakar Lad @ 2013-01-02 9:17 UTC (permalink / raw)
To: linux-media
Cc: Guennadi Liakhovetski, Sylwester Nawrocki, Laurent Pinchart,
Hans Verkuil, Sakari Ailus
Hi,
This is my first step towards DT support for media, Question might be
bit amateur :)
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.
For example the mt9t001 sensor takes following platform data:
struct mt9t001_platform_data {
unsigned int clk_pol:1;
unsigned int ext_clk;
};
similarly mt9p031 takes following platform data:
struct mt9p031_platform_data {
int (*set_xclk)(struct v4l2_subdev *subdev, int hz);
int reset;
int ext_freq;
int target_freq;
};
should this all be individual properties ?
Regards,
--Prabhakar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DT bindings for subdevices
2013-01-02 9:17 DT bindings for subdevices Prabhakar Lad
@ 2013-01-02 10:19 ` Guennadi Liakhovetski
2013-01-03 5:00 ` Prabhakar Lad
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Guennadi Liakhovetski @ 2013-01-02 10:19 UTC (permalink / raw)
To: Prabhakar Lad
Cc: linux-media, Sylwester Nawrocki, Laurent Pinchart, Hans Verkuil,
Sakari Ailus
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.
> };
> 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-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
end of thread, other threads:[~2013-01-04 13:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-02 9:17 DT bindings for subdevices Prabhakar Lad
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).