FW: FW: OMAP 3 ISP

FW: FW: OMAP 3 ISP

[Alex Gershgorin]

Thanks for your quick response :-)

Unfortunately, my video source has no additional interfaces.

Best Regards,
Alex Gershgorin
Embedded Software Engineer
E-mail: alexg@meprolight.com

-----Original Message-----
From: Sakari Ailus [mailto:sakari.ailus@iki.fi]
Sent: Thursday, May 19, 2011 2:09 PM
To: Alex Gershgorin
Cc: 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote:
>
>
>
>
>  Hi Sakari,

Hi Alex,

>
>
> We wish to develop video device and use omap3530.
>
> Our video source has an 8-bit raw data, vertical and horizontal signals,
> and has no i2c bus.
>
> I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP)
> and found, that
>
> to register video device I need to provide I2C subdevs board information
> array, but my device does not have i2c information.
>
> I'm asking for your support on this issue.

Does your image data source have some other kind of control interface,
possibly SPI?

Please reply to linux-media@vger.kernel.org and cc myself and
laurent.pinchart@ideasonboard.com.

Regards,

--
Sakari Ailus
sakari dot ailus at iki dot fi


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Thanks Laurent,

My video source is not the video camera and performs many other functions.
For this purpose I have RS232 port.
As for the video, it runs continuously and is not subject to control except for the power supply.

Regards,
Alex Gershgorin


Can the video source be controlled at all, or is it always running?
If it can be controlled, how do you control it?

Regards,
Laurent Pinchart

-----Original Message-----
From: Alex Gershgorin
Sent: Thursday, May 19, 2011 2:36 PM
To: 'linux-media@vger.kernel.org'
Cc: 'sakari.ailus@iki.fi'; 'laurent.pinchart@ideasonboard.com'; 'agersh@rambler.ru'
Subject: FW: FW: OMAP 3 ISP

Thanks for your quick response :-)

Unfortunately, my video source has no additional interfaces.

Best Regards,
Alex Gershgorin
Embedded Software Engineer
E-mail: alexg@meprolight.com

-----Original Message-----
From: Sakari Ailus [mailto:sakari.ailus@iki.fi]
Sent: Thursday, May 19, 2011 2:09 PM
To: Alex Gershgorin
Cc: 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote:
>
>
>
>
>  Hi Sakari,

Hi Alex,

>
>
> We wish to develop video device and use omap3530.
>
> Our video source has an 8-bit raw data, vertical and horizontal signals,
> and has no i2c bus.
>
> I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP)
> and found, that
>
> to register video device I need to provide I2C subdevs board information
> array, but my device does not have i2c information.
>
> I'm asking for your support on this issue.

Does your image data source have some other kind of control interface,
possibly SPI?

Please reply to linux-media@vger.kernel.org and cc myself and
laurent.pinchart@ideasonboard.com.

Regards,

--
Sakari Ailus
sakari dot ailus at iki dot fi


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> Thanks Laurent,
> 
> My video source is not the video camera and performs many other functions.
> For this purpose I have RS232 port.
> As for the video, it runs continuously and is not subject to control except
> for the power supply.

As a quick hack, you can create an I2C driver for your video source that 
doesn't access the device and just returns fixed format and frame size.

The correct fix is to implement support for platform subdevs in the V4L2 core.

-- 
Regards,

Laurent Pinchart

Re: FW: OMAP 3 ISP

[Michael Jones]

On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> Hi Alex,
> 
> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
>> Thanks Laurent,
>>
>> My video source is not the video camera and performs many other functions.
>> For this purpose I have RS232 port.
>> As for the video, it runs continuously and is not subject to control except
>> for the power supply.
> 
> As a quick hack, you can create an I2C driver for your video source that 
> doesn't access the device and just returns fixed format and frame size.
> 
> The correct fix is to implement support for platform subdevs in the V4L2 core.
> 

I recently implemented support for platform V4L2 subdevs.  Now that it
sounds like others would be interested in this, I will try to polish it
up and submit the patch for review in the next week or so.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Michael,

On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> > On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> >> Thanks Laurent,
> >> 
> >> My video source is not the video camera and performs many other
> >> functions. For this purpose I have RS232 port.
> >> As for the video, it runs continuously and is not subject to control
> >> except for the power supply.
> > 
> > As a quick hack, you can create an I2C driver for your video source that
> > doesn't access the device and just returns fixed format and frame size.
> > 
> > The correct fix is to implement support for platform subdevs in the V4L2
> > core.
> 
> I recently implemented support for platform V4L2 subdevs.  Now that it
> sounds like others would be interested in this, I will try to polish it
> up and submit the patch for review in the next week or so.

Great. This has been discussed during the V4L meeting in Warsaw, here are a 
couple of pointers, to make sure we're going in the same direction.

Bridge drivers should not care whether the subdev sits on an I2C, SPI, 
platform or other bus. To achieve that, an abstraction layer must be provided 
by the V4L2 core. Here's what I got in one of my trees:

/* V4L2 core */

struct v4l2_subdev_i2c_board_info {
        struct i2c_board_info *board_info;
        int i2c_adapter_id;
};

enum v4l2_subdev_bus_type {
        V4L2_SUBDEV_BUS_TYPE_NONE,
        V4L2_SUBDEV_BUS_TYPE_I2C,
        V4L2_SUBDEV_BUS_TYPE_SPI,
};

struct v4l2_subdev_board_info {
        enum v4l2_subdev_bus_type type;
        union {
                struct v4l2_subdev_i2c_board_info i2c;
                struct spi_board_info *spi;
        } info;
};

/* OMAP3 ISP  */

struct isp_v4l2_subdevs_group {
        struct v4l2_subdev_board_info *subdevs;
        enum isp_interface_type interface;
        union {
                struct isp_parallel_platform_data parallel;
                struct isp_ccp2_platform_data ccp2;
                struct isp_csi2_platform_data csi2;
        } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
};

struct isp_platform_data {
        struct isp_v4l2_subdevs_group *subdevs;
};

The V4L2 core would need to provide a function to register a subdev based on a 
v4l2_subdev_board_info structure.

Is that in line with what you've done ? I can provide a patch that implements 
this for I2C and SPI, and let you add platform subdevs if that can help you.

-- 
Regards,

Laurent Pinchart

Re: FW: OMAP 3 ISP

[Michael Jones]

On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> Hi Michael,
> 
> On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
>> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
>>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
>>>> Thanks Laurent,
>>>>
>>>> My video source is not the video camera and performs many other
>>>> functions. For this purpose I have RS232 port.
>>>> As for the video, it runs continuously and is not subject to control
>>>> except for the power supply.
>>>
>>> As a quick hack, you can create an I2C driver for your video source that
>>> doesn't access the device and just returns fixed format and frame size.
>>>
>>> The correct fix is to implement support for platform subdevs in the V4L2
>>> core.
>>
>> I recently implemented support for platform V4L2 subdevs.  Now that it
>> sounds like others would be interested in this, I will try to polish it
>> up and submit the patch for review in the next week or so.
> 
> Great. This has been discussed during the V4L meeting in Warsaw, here are a 
> couple of pointers, to make sure we're going in the same direction.
> 
> Bridge drivers should not care whether the subdev sits on an I2C, SPI, 
> platform or other bus. To achieve that, an abstraction layer must be provided 
> by the V4L2 core. Here's what I got in one of my trees:
> 
> /* V4L2 core */
> 
> struct v4l2_subdev_i2c_board_info {
>         struct i2c_board_info *board_info;
>         int i2c_adapter_id;
> };
> 
> enum v4l2_subdev_bus_type {
>         V4L2_SUBDEV_BUS_TYPE_NONE,
>         V4L2_SUBDEV_BUS_TYPE_I2C,
>         V4L2_SUBDEV_BUS_TYPE_SPI,
> };
> 
> struct v4l2_subdev_board_info {
>         enum v4l2_subdev_bus_type type;
>         union {
>                 struct v4l2_subdev_i2c_board_info i2c;
>                 struct spi_board_info *spi;
>         } info;
> };
> 
> /* OMAP3 ISP  */
> 
> struct isp_v4l2_subdevs_group {
>         struct v4l2_subdev_board_info *subdevs;
>         enum isp_interface_type interface;
>         union {
>                 struct isp_parallel_platform_data parallel;
>                 struct isp_ccp2_platform_data ccp2;
>                 struct isp_csi2_platform_data csi2;
>         } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> };
> 
> struct isp_platform_data {
>         struct isp_v4l2_subdevs_group *subdevs;
> };
> 
> The V4L2 core would need to provide a function to register a subdev based on a 
> v4l2_subdev_board_info structure.
> 
> Is that in line with what you've done ? I can provide a patch that implements 
> this for I2C and SPI, and let you add platform subdevs if that can help you.
> 

Hi Laurent,

Yes, that looks very similar to what I've done.  I was going to submit
SPI support, too, which I also have, but it sounds like you've already
done that?  I'm currently still using a 2.6.38 tree based on an older
media branch of yours, so I'm not familiar with any new changes there yet.

I just need to know what I should use as my baseline.  I don't need to
step on toes and submit something you've already done, so maybe you want
to point me to a branch with the SPI stuff, and I'll just put the
platform stuff on top of it?

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Michael,

On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> >>>> Thanks Laurent,
> >>>> 
> >>>> My video source is not the video camera and performs many other
> >>>> functions. For this purpose I have RS232 port.
> >>>> As for the video, it runs continuously and is not subject to control
> >>>> except for the power supply.
> >>> 
> >>> As a quick hack, you can create an I2C driver for your video source
> >>> that doesn't access the device and just returns fixed format and frame
> >>> size.
> >>> 
> >>> The correct fix is to implement support for platform subdevs in the
> >>> V4L2 core.
> >> 
> >> I recently implemented support for platform V4L2 subdevs.  Now that it
> >> sounds like others would be interested in this, I will try to polish it
> >> up and submit the patch for review in the next week or so.
> > 
> > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > a couple of pointers, to make sure we're going in the same direction.
> > 
> > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > platform or other bus. To achieve that, an abstraction layer must be
> > provided by the V4L2 core. Here's what I got in one of my trees:
> > 
> > /* V4L2 core */
> > 
> > struct v4l2_subdev_i2c_board_info {
> > 
> >         struct i2c_board_info *board_info;
> >         int i2c_adapter_id;
> > 
> > };
> > 
> > enum v4l2_subdev_bus_type {
> > 
> >         V4L2_SUBDEV_BUS_TYPE_NONE,
> >         V4L2_SUBDEV_BUS_TYPE_I2C,
> >         V4L2_SUBDEV_BUS_TYPE_SPI,
> > 
> > };
> > 
> > struct v4l2_subdev_board_info {
> > 
> >         enum v4l2_subdev_bus_type type;
> >         union {
> >         
> >                 struct v4l2_subdev_i2c_board_info i2c;
> >                 struct spi_board_info *spi;
> >         
> >         } info;
> > 
> > };
> > 
> > /* OMAP3 ISP  */
> > 
> > struct isp_v4l2_subdevs_group {
> > 
> >         struct v4l2_subdev_board_info *subdevs;
> >         enum isp_interface_type interface;
> >         union {
> >         
> >                 struct isp_parallel_platform_data parallel;
> >                 struct isp_ccp2_platform_data ccp2;
> >                 struct isp_csi2_platform_data csi2;
> >         
> >         } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> > 
> > };
> > 
> > struct isp_platform_data {
> > 
> >         struct isp_v4l2_subdevs_group *subdevs;
> > 
> > };
> > 
> > The V4L2 core would need to provide a function to register a subdev based
> > on a v4l2_subdev_board_info structure.
> > 
> > Is that in line with what you've done ? I can provide a patch that
> > implements this for I2C and SPI, and let you add platform subdevs if
> > that can help you.
> 
> Hi Laurent,
> 
> Yes, that looks very similar to what I've done.  I was going to submit
> SPI support, too, which I also have, but it sounds like you've already
> done that?  I'm currently still using a 2.6.38 tree based on an older
> media branch of yours, so I'm not familiar with any new changes there yet.
> 
> I just need to know what I should use as my baseline.

Please use mainline, now that the OMAP3 ISP driver has been merged :-)

> I don't need to step on toes and submit something you've already done, so
> maybe you want to point me to a branch with the SPI stuff, and I'll just put
> the platform stuff on top of it?

I'll send the SPI support patches to linux-media, as they haven't been 
reviewed publicly yet.

-- 
Regards,

Laurent Pinchart

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Michael,

I liked the idea of a driver that returns fixed format and frame size.
It certainly could solve my problem.
On the other hand, from your correspondence to Laurent, I realized that it was already done work on improving V4L2 subdevs.
Michael patch of which you speak will help solve my problem without writing a special driver?
Advise in what direction to go in my case?

Regards,

Alex Gershgorin



-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Thursday, May 19, 2011 5:27 PM
To: Michael Jones
Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ailus@iki.fi'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Michael,

On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> >>>> Thanks Laurent,
> >>>>
> >>>> My video source is not the video camera and performs many other
> >>>> functions. For this purpose I have RS232 port.
> >>>> As for the video, it runs continuously and is not subject to control
> >>>> except for the power supply.
> >>>
> >>> As a quick hack, you can create an I2C driver for your video source
> >>> that doesn't access the device and just returns fixed format and frame
> >>> size.
> >>>
> >>> The correct fix is to implement support for platform subdevs in the
> >>> V4L2 core.
> >>
> >> I recently implemented support for platform V4L2 subdevs.  Now that it
> >> sounds like others would be interested in this, I will try to polish it
> >> up and submit the patch for review in the next week or so.
> >
> > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > a couple of pointers, to make sure we're going in the same direction.
> >
> > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > platform or other bus. To achieve that, an abstraction layer must be
> > provided by the V4L2 core. Here's what I got in one of my trees:
> >
> > /* V4L2 core */
> >
> > struct v4l2_subdev_i2c_board_info {
> >
> >         struct i2c_board_info *board_info;
> >         int i2c_adapter_id;
> >
> > };
> >
> > enum v4l2_subdev_bus_type {
> >
> >         V4L2_SUBDEV_BUS_TYPE_NONE,
> >         V4L2_SUBDEV_BUS_TYPE_I2C,
> >         V4L2_SUBDEV_BUS_TYPE_SPI,
> >
> > };
> >
> > struct v4l2_subdev_board_info {
> >
> >         enum v4l2_subdev_bus_type type;
> >         union {
> >
> >                 struct v4l2_subdev_i2c_board_info i2c;
> >                 struct spi_board_info *spi;
> >
> >         } info;
> >
> > };
> >
> > /* OMAP3 ISP  */
> >
> > struct isp_v4l2_subdevs_group {
> >
> >         struct v4l2_subdev_board_info *subdevs;
> >         enum isp_interface_type interface;
> >         union {
> >
> >                 struct isp_parallel_platform_data parallel;
> >                 struct isp_ccp2_platform_data ccp2;
> >                 struct isp_csi2_platform_data csi2;
> >
> >         } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> >
> > };
> >
> > struct isp_platform_data {
> >
> >         struct isp_v4l2_subdevs_group *subdevs;
> >
> > };
> >
> > The V4L2 core would need to provide a function to register a subdev based
> > on a v4l2_subdev_board_info structure.
> >
> > Is that in line with what you've done ? I can provide a patch that
> > implements this for I2C and SPI, and let you add platform subdevs if
> > that can help you.
>
> Hi Laurent,
>
> Yes, that looks very similar to what I've done.  I was going to submit
> SPI support, too, which I also have, but it sounds like you've already
> done that?  I'm currently still using a 2.6.38 tree based on an older
> media branch of yours, so I'm not familiar with any new changes there yet.
>
> I just need to know what I should use as my baseline.

Please use mainline, now that the OMAP3 ISP driver has been merged :-)

> I don't need to step on toes and submit something you've already done, so
> maybe you want to point me to a branch with the SPI stuff, and I'll just put
> the platform stuff on top of it?

I'll send the SPI support patches to linux-media, as they haven't been
reviewed publicly yet.

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: FW: OMAP 3 ISP

[Sakari Ailus]

On Thu, May 19, 2011 at 06:13:28PM +0300, Alex Gershgorin wrote:
> Hi Michael,
> 
> I liked the idea of a driver that returns fixed format and frame size.
> It certainly could solve my problem.
> On the other hand, from your correspondence to Laurent, I realized that it was already done work on improving V4L2 subdevs.
> Michael patch of which you speak will help solve my problem without writing a special driver?
> Advise in what direction to go in my case?

Hi Alex,

You still need a driver, but with the patches you can easily implement that
as a driver for a platform device. The driver itself wouldn't have to do
much more than to return a fixed format and size when queried.

> 
> Regards,
> 
> Alex Gershgorin
> 
> 
> 
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> Sent: Thursday, May 19, 2011 5:27 PM
> To: Michael Jones
> Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ailus@iki.fi'; 'agersh@rambler.ru'
> Subject: Re: FW: OMAP 3 ISP
> 
> Hi Michael,
> 
> On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> > On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> > >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> > >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> > >>>> Thanks Laurent,
> > >>>>
> > >>>> My video source is not the video camera and performs many other
> > >>>> functions. For this purpose I have RS232 port.
> > >>>> As for the video, it runs continuously and is not subject to control
> > >>>> except for the power supply.
> > >>>
> > >>> As a quick hack, you can create an I2C driver for your video source
> > >>> that doesn't access the device and just returns fixed format and frame
> > >>> size.
> > >>>
> > >>> The correct fix is to implement support for platform subdevs in the
> > >>> V4L2 core.
> > >>
> > >> I recently implemented support for platform V4L2 subdevs.  Now that it
> > >> sounds like others would be interested in this, I will try to polish it
> > >> up and submit the patch for review in the next week or so.
> > >
> > > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > > a couple of pointers, to make sure we're going in the same direction.
> > >
> > > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > > platform or other bus. To achieve that, an abstraction layer must be
> > > provided by the V4L2 core. Here's what I got in one of my trees:
> > >
> > > /* V4L2 core */
> > >
> > > struct v4l2_subdev_i2c_board_info {
> > >
> > >         struct i2c_board_info *board_info;
> > >         int i2c_adapter_id;
> > >
> > > };
> > >
> > > enum v4l2_subdev_bus_type {
> > >
> > >         V4L2_SUBDEV_BUS_TYPE_NONE,
> > >         V4L2_SUBDEV_BUS_TYPE_I2C,
> > >         V4L2_SUBDEV_BUS_TYPE_SPI,
> > >
> > > };
> > >
> > > struct v4l2_subdev_board_info {
> > >
> > >         enum v4l2_subdev_bus_type type;
> > >         union {
> > >
> > >                 struct v4l2_subdev_i2c_board_info i2c;
> > >                 struct spi_board_info *spi;
> > >
> > >         } info;
> > >
> > > };
> > >
> > > /* OMAP3 ISP  */
> > >
> > > struct isp_v4l2_subdevs_group {
> > >
> > >         struct v4l2_subdev_board_info *subdevs;
> > >         enum isp_interface_type interface;
> > >         union {
> > >
> > >                 struct isp_parallel_platform_data parallel;
> > >                 struct isp_ccp2_platform_data ccp2;
> > >                 struct isp_csi2_platform_data csi2;
> > >
> > >         } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> > >
> > > };
> > >
> > > struct isp_platform_data {
> > >
> > >         struct isp_v4l2_subdevs_group *subdevs;
> > >
> > > };
> > >
> > > The V4L2 core would need to provide a function to register a subdev based
> > > on a v4l2_subdev_board_info structure.
> > >
> > > Is that in line with what you've done ? I can provide a patch that
> > > implements this for I2C and SPI, and let you add platform subdevs if
> > > that can help you.
> >
> > Hi Laurent,
> >
> > Yes, that looks very similar to what I've done.  I was going to submit
> > SPI support, too, which I also have, but it sounds like you've already
> > done that?  I'm currently still using a 2.6.38 tree based on an older
> > media branch of yours, so I'm not familiar with any new changes there yet.
> >
> > I just need to know what I should use as my baseline.
> 
> Please use mainline, now that the OMAP3 ISP driver has been merged :-)
> 
> > I don't need to step on toes and submit something you've already done, so
> > maybe you want to point me to a branch with the SPI stuff, and I'll just put
> > the platform stuff on top of it?
> 
> I'll send the SPI support patches to linux-media, as they haven't been
> reviewed publicly yet.
> 
> --
> Regards,
> 
> Laurent Pinchart
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

-- 
Sakari Ailus
sakari dot ailus at iki dot fi

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi All,

I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and size.
I do not understand who reads these parameters, user application through IOCTL or OMAP3 ISP driver uses them regardless of the user space application?

Another question, if I need to change polarity of Vertical or Horizontal synchronization signals, according struct isp_parallel_platform_data, is it not possible?

struct isp_parallel_platform_data {
        unsigned int data_lane_shift:2;
        unsigned int clk_pol:1;
        unsigned int bridge:4;
};

Regards,
Alex Gershgorin


-----Original Message-----
From: Sakari Ailus [mailto:sakari.ailus@iki.fi]
Sent: Thursday, May 19, 2011 6:33 PM
To: Alex Gershgorin
Cc: 'Laurent Pinchart'; Michael Jones; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

On Thu, May 19, 2011 at 06:13:28PM +0300, Alex Gershgorin wrote:
> Hi Michael,
>
> I liked the idea of a driver that returns fixed format and frame size.
> It certainly could solve my problem.
> On the other hand, from your correspondence to Laurent, I realized that it was already done work on improving V4L2 subdevs.
> Michael patch of which you speak will help solve my problem without writing a special driver?
> Advise in what direction to go in my case?

Hi Alex,

You still need a driver, but with the patches you can easily implement that
as a driver for a platform device. The driver itself wouldn't have to do
much more than to return a fixed format and size when queried.

>
> Regards,
>
> Alex Gershgorin
>
>
>
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
> Sent: Thursday, May 19, 2011 5:27 PM
> To: Michael Jones
> Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ailus@iki.fi'; 'agersh@rambler.ru'
> Subject: Re: FW: OMAP 3 ISP
>
> Hi Michael,
>
> On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> > On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> > >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> > >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> > >>>> Thanks Laurent,
> > >>>>
> > >>>> My video source is not the video camera and performs many other
> > >>>> functions. For this purpose I have RS232 port.
> > >>>> As for the video, it runs continuously and is not subject to control
> > >>>> except for the power supply.
> > >>>
> > >>> As a quick hack, you can create an I2C driver for your video source
> > >>> that doesn't access the device and just returns fixed format and frame
> > >>> size.
> > >>>
> > >>> The correct fix is to implement support for platform subdevs in the
> > >>> V4L2 core.
> > >>
> > >> I recently implemented support for platform V4L2 subdevs.  Now that it
> > >> sounds like others would be interested in this, I will try to polish it
> > >> up and submit the patch for review in the next week or so.
> > >
> > > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > > a couple of pointers, to make sure we're going in the same direction.
> > >
> > > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > > platform or other bus. To achieve that, an abstraction layer must be
> > > provided by the V4L2 core. Here's what I got in one of my trees:
> > >
> > > /* V4L2 core */
> > >
> > > struct v4l2_subdev_i2c_board_info {
> > >
> > >         struct i2c_board_info *board_info;
> > >         int i2c_adapter_id;
> > >
> > > };
> > >
> > > enum v4l2_subdev_bus_type {
> > >
> > >         V4L2_SUBDEV_BUS_TYPE_NONE,
> > >         V4L2_SUBDEV_BUS_TYPE_I2C,
> > >         V4L2_SUBDEV_BUS_TYPE_SPI,
> > >
> > > };
> > >
> > > struct v4l2_subdev_board_info {
> > >
> > >         enum v4l2_subdev_bus_type type;
> > >         union {
> > >
> > >                 struct v4l2_subdev_i2c_board_info i2c;
> > >                 struct spi_board_info *spi;
> > >
> > >         } info;
> > >
> > > };
> > >
> > > /* OMAP3 ISP  */
> > >
> > > struct isp_v4l2_subdevs_group {
> > >
> > >         struct v4l2_subdev_board_info *subdevs;
> > >         enum isp_interface_type interface;
> > >         union {
> > >
> > >                 struct isp_parallel_platform_data parallel;
> > >                 struct isp_ccp2_platform_data ccp2;
> > >                 struct isp_csi2_platform_data csi2;
> > >
> > >         } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> > >
> > > };
> > >
> > > struct isp_platform_data {
> > >
> > >         struct isp_v4l2_subdevs_group *subdevs;
> > >
> > > };
> > >
> > > The V4L2 core would need to provide a function to register a subdev based
> > > on a v4l2_subdev_board_info structure.
> > >
> > > Is that in line with what you've done ? I can provide a patch that
> > > implements this for I2C and SPI, and let you add platform subdevs if
> > > that can help you.
> >
> > Hi Laurent,
> >
> > Yes, that looks very similar to what I've done.  I was going to submit
> > SPI support, too, which I also have, but it sounds like you've already
> > done that?  I'm currently still using a 2.6.38 tree based on an older
> > media branch of yours, so I'm not familiar with any new changes there yet.
> >
> > I just need to know what I should use as my baseline.
>
> Please use mainline, now that the OMAP3 ISP driver has been merged :-)
>
> > I don't need to step on toes and submit something you've already done, so
> > maybe you want to point me to a branch with the SPI stuff, and I'll just put
> > the platform stuff on top of it?
>
> I'll send the SPI support patches to linux-media, as they haven't been
> reviewed publicly yet.
>
> --
> Regards,
>
> Laurent Pinchart
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>

--
Sakari Ailus
sakari dot ailus at iki dot fi


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6135 (20110519) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6147 (20110524) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Tuesday 24 May 2011 16:11:16 Alex Gershgorin wrote:
> Hi All,
> 
> I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and
> size. I do not understand who reads these parameters, user application
> through IOCTL or OMAP3 ISP driver uses them regardless of the user space
> application?

Both. media-ctl (and other userspace applications) can use them, and the OMAP3
ISP driver retrieves them when starting the video stream to make sure that the
formats at the "sensor" output and at the CCDC input match.

> Another question, if I need to change polarity of Vertical or Horizontal
> synchronization signals, according struct isp_parallel_platform_data, is
> it not possible?
> 
> struct isp_parallel_platform_data {
>         unsigned int data_lane_shift:2;
>         unsigned int clk_pol:1;
>         unsigned int bridge:4;
> };

Could you please try the following patch ?

>From 7f8eff25e63880a93bc283cd97840227cd092622 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Wed, 25 May 2011 09:16:28 +0200
Subject: [PATCH] omap3isp: Support configurable HS/VS polarities

Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/media/video/omap3isp/isp.h     |    6 ++++++
 drivers/media/video/omap3isp/ispccdc.c |    4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap3isp/isp.h b/drivers/media/video/omap3isp/isp.h
index 2620c40..529e582 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -139,6 +139,10 @@ struct isp_reg {
  *		3 - CAMEXT[13:6] -> CAM[7:0]
  * @clk_pol: Pixel clock polarity
  *		0 - Non Inverted, 1 - Inverted
+ * @hs_pol: Horizontal synchronization polarity
+ *		0 - Active high, 1 - Active low
+ * @vs_pol: Vertical synchronization polarity
+ *		0 - Active high, 1 - Active low
  * @bridge: CCDC Bridge input control
  *		ISPCTRL_PAR_BRIDGE_DISABLE - Disable
  *		ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
@@ -147,6 +151,8 @@ struct isp_reg {
 struct isp_parallel_platform_data {
 	unsigned int data_lane_shift:2;
 	unsigned int clk_pol:1;
+	unsigned int hs_pol:1;
+	unsigned int vs_pol:1;
 	unsigned int bridge:4;
 };
 
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..5e742b2 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1148,6 +1148,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
 	omap3isp_configure_bridge(isp, ccdc->input, pdata, shift);
 
 	ccdc->syncif.datsz = depth_out;
+	ccdc->syncif.hdpol = pdata ? pdata-> hs_pol : 0;
+	ccdc->syncif.vdpol = pdata ? pdata-> vs_pol : 0;
 	ccdc_config_sync_if(ccdc, &ccdc->syncif);
 
 	/* CCDC_PAD_SINK */
@@ -2257,8 +2259,6 @@ int omap3isp_ccdc_init(struct isp_device *isp)
 	ccdc->syncif.fldout = 0;
 	ccdc->syncif.fldpol = 0;
 	ccdc->syncif.fldstat = 0;
-	ccdc->syncif.hdpol = 0;
-	ccdc->syncif.vdpol = 0;
 
 	ccdc->clamp.oblen = 0;
 	ccdc->clamp.dcsubval = 0;
-- 
1.7.3.4

-- 
Regards,

Laurent Pinchart

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Laurent,

Unfortunately, at this point I have no Hardware platforms, but in the
next week we should get Zoom OMAP35 Torpedo evaluation kit
and then I can test it.

I have already applied this patch on the last main line
Kernel version (2.6.39) and continue to work on the platform device for Zoom OMAP35xx Torpedo.

Thanks for this patch :-)

Regards,
Alex Gershgorin

-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Wednesday, May 25, 2011 10:22 AM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Tuesday 24 May 2011 16:11:16 Alex Gershgorin wrote:
> Hi All,
>
> I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and
> size. I do not understand who reads these parameters, user application
> through IOCTL or OMAP3 ISP driver uses them regardless of the user space
> application?

Both. media-ctl (and other userspace applications) can use them, and the OMAP3
ISP driver retrieves them when starting the video stream to make sure that the
formats at the "sensor" output and at the CCDC input match.

> Another question, if I need to change polarity of Vertical or Horizontal
> synchronization signals, according struct isp_parallel_platform_data, is
> it not possible?
>
> struct isp_parallel_platform_data {
>         unsigned int data_lane_shift:2;
>         unsigned int clk_pol:1;
>         unsigned int bridge:4;
> };

Could you please try the following patch ?

>From 7f8eff25e63880a93bc283cd97840227cd092622 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date: Wed, 25 May 2011 09:16:28 +0200
Subject: [PATCH] omap3isp: Support configurable HS/VS polarities

Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/media/video/omap3isp/isp.h     |    6 ++++++
 drivers/media/video/omap3isp/ispccdc.c |    4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap3isp/isp.h b/drivers/media/video/omap3isp/isp.h
index 2620c40..529e582 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -139,6 +139,10 @@ struct isp_reg {
  *             3 - CAMEXT[13:6] -> CAM[7:0]
  * @clk_pol: Pixel clock polarity
  *             0 - Non Inverted, 1 - Inverted
+ * @hs_pol: Horizontal synchronization polarity
+ *             0 - Active high, 1 - Active low
+ * @vs_pol: Vertical synchronization polarity
+ *             0 - Active high, 1 - Active low
  * @bridge: CCDC Bridge input control
  *             ISPCTRL_PAR_BRIDGE_DISABLE - Disable
  *             ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
@@ -147,6 +151,8 @@ struct isp_reg {
 struct isp_parallel_platform_data {
        unsigned int data_lane_shift:2;
        unsigned int clk_pol:1;
+       unsigned int hs_pol:1;
+       unsigned int vs_pol:1;
        unsigned int bridge:4;
 };

diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..5e742b2 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1148,6 +1148,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
        omap3isp_configure_bridge(isp, ccdc->input, pdata, shift);

        ccdc->syncif.datsz = depth_out;
+       ccdc->syncif.hdpol = pdata ? pdata-> hs_pol : 0;
+       ccdc->syncif.vdpol = pdata ? pdata-> vs_pol : 0;
        ccdc_config_sync_if(ccdc, &ccdc->syncif);

        /* CCDC_PAD_SINK */
@@ -2257,8 +2259,6 @@ int omap3isp_ccdc_init(struct isp_device *isp)
        ccdc->syncif.fldout = 0;
        ccdc->syncif.fldpol = 0;
        ccdc->syncif.fldstat = 0;
-       ccdc->syncif.hdpol = 0;
-       ccdc->syncif.vdpol = 0;

        ccdc->clamp.oblen = 0;
        ccdc->clamp.dcsubval = 0;
--
1.7.3.4

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote:
> Hi Laurent,
> 
> Unfortunately, at this point I have no Hardware platforms, but in the
> next week we should get Zoom OMAP35 Torpedo evaluation kit
> and then I can test it.
> 
> I have already applied this patch on the last main line
> Kernel version (2.6.39) and continue to work on the platform device for
> Zoom OMAP35xx Torpedo.
> 
> Thanks for this patch :-)

You're welcome. Please let me know if it works for you when you'll receive the 
hardware. I will then push the patch to mainline.

-- 
Regards,

Laurent Pinchart

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Of course, in any case, you'll be the first who will know the results :-)

Regards,

Alex Gershgorin

-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Wednesday, May 25, 2011 1:02 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote:
> Hi Laurent,
>
> Unfortunately, at this point I have no Hardware platforms, but in the
> next week we should get Zoom OMAP35 Torpedo evaluation kit
> and then I can test it.
>
> I have already applied this patch on the last main line
> Kernel version (2.6.39) and continue to work on the platform device for
> Zoom OMAP35xx Torpedo.
>
> Thanks for this patch :-)

You're welcome. Please let me know if it works for you when you'll receive the
hardware. I will then push the patch to mainline.

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6150 (20110525) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Laurent,

I recently got the Zoom OMAP35xx Torpedo and began testing OMAP3ISP.
Currently I have a problem I can't solve.
See Message from booting Kernel:

Linux media interface: v0.10
Linux video capture interface: v2.00
omap3isp omap3isp: Revision 2.0 found
omap-iommu omap-iommu.0: isp: version 1.1
isp_register_subdev_group: Unable to register subdev

What could be the problem, why sub device can't pass a registration?

Thanks,

Alex Gershgorin


-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com] Sent: Wednesday, May 25, 2011 1:02 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote:
> Hi Laurent,
>
> Unfortunately, at this point I have no Hardware platforms, but in the
> next week we should get Zoom OMAP35 Torpedo evaluation kit
> and then I can test it.
>
> I have already applied this patch on the last main line
> Kernel version (2.6.39) and continue to work on the platform device for
> Zoom OMAP35xx Torpedo.
>
> Thanks for this patch :-)

You're welcome. Please let me know if it works for you when you'll receive the
hardware. I will then push the patch to mainline.

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6245 (20110627) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Tuesday 28 June 2011 09:47:07 Alex Gershgorin wrote:
> Hi Laurent,
> 
> I recently got the Zoom OMAP35xx Torpedo and began testing OMAP3ISP.
> Currently I have a problem I can't solve.
> See Message from booting Kernel:
> 
> Linux media interface: v0.10
> Linux video capture interface: v2.00
> omap3isp omap3isp: Revision 2.0 found
> omap-iommu omap-iommu.0: isp: version 1.1
> isp_register_subdev_group: Unable to register subdev
> 
> What could be the problem, why sub device can't pass a registration?

This means the v4l2_i2c_new_subdev_board() failed. Do you have a driver for 
the subdev ? Does it get loaded ? Does its probe() function get called ?

-- 
Regards,

Laurent Pinchart

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> Hi Laurent,
> 
> From previous correspondence:
> 
> My video source is not the video camera and performs many other functions.
> For this purpose I have RS232 port.
> As for the video, it runs continuously and is not subject to control except
> for the power supply.
> 
> > As a quick hack, you can create an I2C driver for your video source that
> > doesn't access the device and just returns fixed format and frame size.
> > 
> > The correct fix is to implement support for platform subdevs in the V4L2
> > core.
> 
> Yes, I wrote a simple driver, now it looks like this:
> 
> [    2.029754] Linux media interface: v0.10
> [    2.034851] Linux video capture interface: v2.00
> [    2.041015] My_probe I2C subdev probed

Are you sure that's the probe method ? Isn't it the init method ?

> [    2.047058] omap3isp omap3isp: Revision 2.0 found
> [    2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> [    2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21 -16)

Make sure you don't already have an I2C device at address 0x21 on the same 
bus.

> [    2.077301] isp_register_subdev_group: Unable to register subdev my-te
> 
> I see now that, subdev probed but the same problem stays.
> 
> Really I do not have a physical I2C address 0x21, he was selected for
> registration
> 
> may be a 'problem in this?

-- 
Regards,

Laurent Pinchart

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Alex,

On Wednesday 29 June 2011 15:50:54 Alex Gershgorin wrote:
> On Wednesday, June 29, 2011 2:33 PM Laurent Pinchart wrote:
> > On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> > > 
> > > From previous correspondence:
> > > 
> > > My video source is not the video camera and performs many other
> > > functions.
> > > 
> > > For this purpose I have RS232 port.
> > > 
> > > As for the video, it runs continuously and is not subject to control
> > > except for the power supply.
> > > 
> > > > As a quick hack, you can create an I2C driver for your video source
> > > > that doesn't access the device and just returns fixed format and frame
> > > > size.
> > > > 
> > > > The correct fix is to implement support for platform subdevs in the
> > > > V4L2 core.
> > > 
> > > Yes, I wrote a simple driver, now it looks like this:
> > > 
> > > [    2.029754] Linux media interface: v0.10
> > > [    2.034851] Linux video capture interface: v2.00
> > > [    2.041015] My_probe I2C subdev probed

[snip]

> > > [    2.047058] omap3isp omap3isp: Revision 2.0 found
> > > [    2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> > > [    2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21
> > > -16)
> > 
> > Make sure you don't already have an I2C device at address 0x21 on the same
> > bus.

[snip]

> Here is my platform device registration
> 
> #define SENSOR_I2C_BUS_NUM    3
> 
> static struct i2c_board_info __initdata camera_i2c_devices[] = {
>       {
>              I2C_BOARD_INFO("my-te", 0x21),
>       },
> };
> 
> static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
>       {
>             .board_info = &camera_i2c_devices[0],
>             .i2c_adapter_id = SENSOR_I2C_BUS_NUM,
>       },
>       { NULL, 0, },
> };
> 
> static struct isp_v4l2_subdevs_group camera_subdevs[] = {
>       {
>             .subdevs = camera_i2c_subdevs,
>             .interface = ISP_INTERFACE_PARALLEL,
>             .bus = {
>                   .parallel = {
>                         .data_lane_shift = 1,
>                         .clk_pol = 0,
>                         .hs_pol  = 0,
>                         .vs_pol  = 0,
>                         .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
>                   }
>             },
>       },
>       {},
> };
> 
> static struct isp_platform_data isp_platform_data = {
>       .subdevs = camera_subdevs,
> };
> 
> int __init camera_init(void)
> {       
> omap_register_i2c_bus(3,camera_i2c_devices,ARRAY_SIZE(camera_i2c_devices))
> ;

Doesn't omap_register_i2c_bus() take 4 arguments ?

Anyway, you must not register the I2C devices here, they will be registered by 
the OMAP3 ISP driver. You still need to register the bus though, with the last 
two arguments sets to NULL, 0.

> return omap3_init_camera(&isp_platform_data);
> }

-- 
Regards,

Laurent Pinchart

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Wednesday, June 29, 2011 6:55 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; 'Michael Jones'; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Wednesday 29 June 2011 15:50:54 Alex Gershgorin wrote:
> On Wednesday, June 29, 2011 2:33 PM Laurent Pinchart wrote:
> > On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> > >
> > > From previous correspondence:
> > >
> > > My video source is not the video camera and performs many other
> > > functions.
> > >
> > > For this purpose I have RS232 port.
> > >
> > > As for the video, it runs continuously and is not subject to control
> > > except for the power supply.
> > >
> > > > As a quick hack, you can create an I2C driver for your video source
> > > > that doesn't access the device and just returns fixed format and frame
> > > > size.
> > > >
> > > > The correct fix is to implement support for platform subdevs in the
> > > > V4L2 core.
> > >
> > > Yes, I wrote a simple driver, now it looks like this:
> > >
> > > [    2.029754] Linux media interface: v0.10
> > > [    2.034851] Linux video capture interface: v2.00
> > > [    2.041015] My_probe I2C subdev probed

[snip]

> > > [    2.047058] omap3isp omap3isp: Revision 2.0 found
> > > [    2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> > > [    2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21
> > > -16)
> >
> > Make sure you don't already have an I2C device at address 0x21 on the same
> > bus.

[snip]

> Here is my platform device registration
>
> #define SENSOR_I2C_BUS_NUM    3
>
> static struct i2c_board_info __initdata camera_i2c_devices[] = {
>       {
>              I2C_BOARD_INFO("my-te", 0x21),
>       },
> };
>
> static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
>       {
>             .board_info = &camera_i2c_devices[0],
>             .i2c_adapter_id = SENSOR_I2C_BUS_NUM,
>       },
>       { NULL, 0, },
> };
>
> static struct isp_v4l2_subdevs_group camera_subdevs[] = {
>       {
>             .subdevs = camera_i2c_subdevs,
>             .interface = ISP_INTERFACE_PARALLEL,
>             .bus = {
>                   .parallel = {
>                         .data_lane_shift = 1,
>                         .clk_pol = 0,
>                         .hs_pol  = 0,
>                         .vs_pol  = 0,
>                         .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
>                   }
>             },
>       },
>       {},
> };
>
> static struct isp_platform_data isp_platform_data = {
>       .subdevs = camera_subdevs,
> };
>
> int __init camera_init(void)
> {
> omap_register_i2c_bus(3,camera_i2c_devices,ARRAY_SIZE(camera_i2c_devices))
> ;

Doesn't omap_register_i2c_bus() take 4 arguments ?

Anyway, you must not register the I2C devices here, they will be registered by
the OMAP3 ISP driver. You still need to register the bus though, with the last
two arguments sets to NULL, 0.

> return omap3_init_camera(&isp_platform_data);
> }

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6250 (20110629) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6250 (20110629) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Laurent

Good news!
Now registration is successful, many thanks.
Now I can move on to the next stage of work.

Regards,

Alex Gershgorin


-----Original Message-----
From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com]
Sent: Wednesday, June 29, 2011 6:55 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; 'Michael Jones'; 'linux-media@vger.kernel.org'; 'agersh@rambler.ru'
Subject: Re: FW: OMAP 3 ISP

Hi Alex,

On Wednesday 29 June 2011 15:50:54 Alex Gershgorin wrote:
> On Wednesday, June 29, 2011 2:33 PM Laurent Pinchart wrote:
> > On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> > >
> > > From previous correspondence:
> > >
> > > My video source is not the video camera and performs many other
> > > functions.
> > >
> > > For this purpose I have RS232 port.
> > >
> > > As for the video, it runs continuously and is not subject to control
> > > except for the power supply.
> > >
> > > > As a quick hack, you can create an I2C driver for your video source
> > > > that doesn't access the device and just returns fixed format and frame
> > > > size.
> > > >
> > > > The correct fix is to implement support for platform subdevs in the
> > > > V4L2 core.
> > >
> > > Yes, I wrote a simple driver, now it looks like this:
> > >
> > > [    2.029754] Linux media interface: v0.10
> > > [    2.034851] Linux video capture interface: v2.00
> > > [    2.041015] My_probe I2C subdev probed

[snip]

> > > [    2.047058] omap3isp omap3isp: Revision 2.0 found
> > > [    2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> > > [    2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21
> > > -16)
> >
> > Make sure you don't already have an I2C device at address 0x21 on the same
> > bus.

[snip]

> Here is my platform device registration
>
> #define SENSOR_I2C_BUS_NUM    3
>
> static struct i2c_board_info __initdata camera_i2c_devices[] = {
>       {
>              I2C_BOARD_INFO("my-te", 0x21),
>       },
> };
>
> static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
>       {
>             .board_info = &camera_i2c_devices[0],
>             .i2c_adapter_id = SENSOR_I2C_BUS_NUM,
>       },
>       { NULL, 0, },
> };
>
> static struct isp_v4l2_subdevs_group camera_subdevs[] = {
>       {
>             .subdevs = camera_i2c_subdevs,
>             .interface = ISP_INTERFACE_PARALLEL,
>             .bus = {
>                   .parallel = {
>                         .data_lane_shift = 1,
>                         .clk_pol = 0,
>                         .hs_pol  = 0,
>                         .vs_pol  = 0,
>                         .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
>                   }
>             },
>       },
>       {},
> };
>
> static struct isp_platform_data isp_platform_data = {
>       .subdevs = camera_subdevs,
> };
>
> int __init camera_init(void)
> {
> omap_register_i2c_bus(3,camera_i2c_devices,ARRAY_SIZE(camera_i2c_devices))
> ;

Doesn't omap_register_i2c_bus() take 4 arguments ?

Anyway, you must not register the I2C devices here, they will be registered by
the OMAP3 ISP driver. You still need to register the bus though, with the last
two arguments sets to NULL, 0.

> return omap3_init_camera(&isp_platform_data);
> }

--
Regards,

Laurent Pinchart


__________ Information from ESET NOD32 Antivirus, version of virus signature database 6250 (20110629) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6250 (20110629) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

RE: FW: OMAP 3 ISP

[Alex Gershgorin]

Hi Ritesh,

Please send in the future CC to laurent.pinchart@ideasonboard.com and linux-media@vger.kernel.org

> Hi Alex,
> I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board.
> Device is booting correctly but probe function in omap3isp module not getting called.
> Please help me

You have relevant Kernel boot messages? 
You can also find information in media archives OMAP 3 ISP thread.

Regards,
Alex

Re: FW: OMAP 3 ISP

[jean-philippe francois]

2012/5/29 Alex Gershgorin <alexg@meprolight.com>:
>
> Hi Ritesh,
>
> Please send in the future CC to laurent.pinchart@ideasonboard.com and linux-media@vger.kernel.org
>
>> Hi Alex,
>> I also started working with OMAP35x torpedo kit, I successful compile Linux 3.0 and ported on the board.
>> Device is booting correctly but probe function in omap3isp module not getting called.
>> Please help me
>
> You have relevant Kernel boot messages?
> You can also find information in media archives OMAP 3 ISP thread.
>
> Regards,
> Alex
>

Hi, I had a similar problem with a 2.6.39 kernel, that was solved with
a 3.2 kernel.
When compiled as a module, the probe function was called, but was failing later.

The single message I would see was "ISP revision x.y found" [1]

When compiled in the kernel image, everything was fine.


[1] http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2103

Jean-Philippe François

>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FW: OMAP 3 ISP

[Laurent Pinchart]

Hi Enrico,

On Tuesday 29 May 2012 12:08:43 Enrico wrote:
> On Tue, May 29, 2012 at 10:15 AM, jean-philippe francois wrote:
> > 2012/5/29 Alex Gershgorin <alexg@meprolight.com>:
> >> Hi Ritesh,
> >> 
> >> Please send in the future CC to laurent.pinchart@ideasonboard.com and
> >> linux-media@vger.kernel.org>> 
> >>> Hi Alex,
> >>> I also started working with OMAP35x torpedo kit, I successful compile
> >>> Linux 3.0 and ported on the board. Device is booting correctly but
> >>> probe function in omap3isp module not getting called. Please help me
> >> 
> >> You have relevant Kernel boot messages?
> >> You can also find information in media archives OMAP 3 ISP thread.
> >> 
> >> Regards,
> >> Alex
> > 
> > Hi, I had a similar problem with a 2.6.39 kernel, that was solved with
> > a 3.2 kernel.
> > When compiled as a module, the probe function was called, but was failing
> > later.
> > 
> > The single message I would see was "ISP revision x.y found" [1]
> > 
> > When compiled in the kernel image, everything was fine.
> > 
> > 
> > [1]
> > http://lxr.linux.no/linux+v2.6.39.4/drivers/media/video/omap3isp/isp.c#L2
> > 103
> I think with kernel version 3.0 i had the same problem, i had to
> modprobe iommu2 before omap3isp, removing (if already loaded) iommu.
> Probably later on it was fixed and you don't need that anymore.

That's right. The OMAP3 ISP driver indirectly depended on the iommu2 module, 
which wasn't loaded automatically. Nowadays OMAP IOMMU support is a boolean 
option, so it will get compiled in the kernel directly.

-- 
Regards,

Laurent Pinchart