OMAP 3530 camera ISP forks and new media framework

OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

Hello media team,

I want to write a sensor driver for the mt9p031 (not mt9t031) camera
chip and start getting confused about the different kernel forks and
architectural changes that happen in V4L2.
A similar problem was discussed in this mailing list at
http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.

Currently I don't know which branch to follow. Either
http://gitorious.org/omap3camera from Sakari Ailus or the branch
media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
Laurent Pinchart. Both have an folder drivers/media/video/isp and are
written for the new media controller architecture if I am right.

I see in http://gitorious.org/omap3camera/camera-firmware that there
is already an empty placeholder for the mt9t031.
The README of the camera-firmware repository states: "makemodes.pl is
a perl script which converts sensor register lists from FIXME into C
code. dcc-pulautin is a Makefile (mostly) that converts sensor
register lists as C code into binaries understandable to sensor
drivers. The end result is a binary with sensor driver name, sensor
version and bin suffix, for example et8ek8-0002.bin."

So I think the goal is to provide a script framework for camera
systems. You just script some register tables and it creates a binary
that can be read by a sensor driver made for that framework. If the a
camera bridge driver for your chip exists, you are done. Am I right?
Are drivers/media/video/et8ek8.c and
drivers/staging/dream/camera/mt9p012_* such drivers?

So do you think it is the right way to go to use your ISP driver,
adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
write a register list and create a camera firmware for that sensor
driver with makemodes?

I am still quite confused... if I get something wrong, please give me
some hints.

Thanks a lot!

Bastian Hecht

Re: OMAP 3530 camera ISP forks and new media framework

[Sakari Ailus]

Bastian Hecht wrote:
> Hello media team,

Hi Bastian,

> I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> chip and start getting confused about the different kernel forks and
> architectural changes that happen in V4L2.
> A similar problem was discussed in this mailing list at
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> 
> Currently I don't know which branch to follow. Either
> http://gitorious.org/omap3camera from Sakari Ailus or the branch
> media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> written for the new media controller architecture if I am right.

Take Laurent's branch it has all the current patches in it. My gitorious
tree isn't updated anymore. (I just had forgotten to add a note, it's
there now.)

> I see in http://gitorious.org/omap3camera/camera-firmware that there
> is already an empty placeholder for the mt9t031.
> The README of the camera-firmware repository states: "makemodes.pl is
> a perl script which converts sensor register lists from FIXME into C
> code. dcc-pulautin is a Makefile (mostly) that converts sensor
> register lists as C code into binaries understandable to sensor
> drivers. The end result is a binary with sensor driver name, sensor
> version and bin suffix, for example et8ek8-0002.bin."
> 
> So I think the goal is to provide a script framework for camera
> systems. You just script some register tables and it creates a binary
> that can be read by a sensor driver made for that framework. If the a
> camera bridge driver for your chip exists, you are done. Am I right?
> Are drivers/media/video/et8ek8.c and
> drivers/staging/dream/camera/mt9p012_* such drivers?

et8ek8 and smia-sensor currently use the camera-firmware binaries. The
long term goal is to move more things to the sensor driver itself.
Register lists related to a set of sensor settings are not an ideal way
to handle sensor related settings since they could be controlled the
driver instead.

> So do you think it is the right way to go to use your ISP driver,
> adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> write a register list and create a camera firmware for that sensor
> driver with makemodes?

I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
if you want to write a sensor driver to be used with the OMAP 3 ISP
driver. Register lists are not that nice but the v4l2_subdev interface
in that one is one of the good parts you get with that.

I'd also advice against using camera-firmware if you don't necessarily
need that kind of functionality.

> I am still quite confused... if I get something wrong, please give me
> some hints.

I hope this helped. :-)

If you have any further questions feel free to ask.

Cheers,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Bastian,

On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote:
> Bastian Hecht wrote:
>
> > I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> > chip and start getting confused about the different kernel forks and
> > architectural changes that happen in V4L2.
> > A similar problem was discussed in this mailing list at
> > http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> > 
> > Currently I don't know which branch to follow. Either
> > http://gitorious.org/omap3camera from Sakari Ailus or the branch
> > media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> > Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> > written for the new media controller architecture if I am right.
> 
> Take Laurent's branch it has all the current patches in it. My gitorious
> tree isn't updated anymore. (I just had forgotten to add a note, it's
> there now.)
> 
> > I see in http://gitorious.org/omap3camera/camera-firmware that there
> > is already an empty placeholder for the mt9t031.
> > The README of the camera-firmware repository states: "makemodes.pl is
> > a perl script which converts sensor register lists from FIXME into C
> > code. dcc-pulautin is a Makefile (mostly) that converts sensor
> > register lists as C code into binaries understandable to sensor
> > drivers. The end result is a binary with sensor driver name, sensor
> > version and bin suffix, for example et8ek8-0002.bin."
> > 
> > So I think the goal is to provide a script framework for camera
> > systems. You just script some register tables and it creates a binary
> > that can be read by a sensor driver made for that framework. If the a
> > camera bridge driver for your chip exists, you are done. Am I right?
> > Are drivers/media/video/et8ek8.c and
> > drivers/staging/dream/camera/mt9p012_* such drivers?
> 
> et8ek8 and smia-sensor currently use the camera-firmware binaries. The
> long term goal is to move more things to the sensor driver itself.
> Register lists related to a set of sensor settings are not an ideal way
> to handle sensor related settings since they could be controlled the
> driver instead.

To be compatible with the OMAP3 ISP driver, sensor drivers need to provide a 
v4l2_subdev interface and implement the pad-level operations (see the 
media-0003-subdev-pad branch in the repository).

I've written such a driver for the MT9T001. I've pushed it to the media-
mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note that 
the driver is based on a previous version of the subdev pad-level operations 
API, so it won't compile out of the box.

As Sakari stated, the camera-firmware system shouldn't be used by new drivers. 
The driver should instead compute the register values directly from the 
information supplied by userspace (through the v4l2_subdev API) such as the 
frame size and the crop rectangle. Binary lists of register address/value 
pairs are definitely not the way to go.

> > So do you think it is the right way to go to use your ISP driver,
> > adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> > write a register list and create a camera firmware for that sensor
> > driver with makemodes?
> 
> I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
> if you want to write a sensor driver to be used with the OMAP 3 ISP
> driver. Register lists are not that nice but the v4l2_subdev interface
> in that one is one of the good parts you get with that.

Start with the MT9T001 driver, that will be easier.

> I'd also advice against using camera-firmware if you don't necessarily
> need that kind of functionality.

I'd very strongly advice against it as well. Try to forget it even exists, it 
was a development mistake :-)

> > I am still quite confused... if I get something wrong, please give me
> > some hints.
> 
> I hope this helped. :-)
> 
> If you have any further questions feel free to ask.

Ditto :-)

-- 
Regards,

Laurent Pinchart

RE: OMAP 3530 camera ISP forks and new media framework

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> owner@vger.kernel.org] On Behalf Of Laurent Pinchart
> Sent: Thursday, October 07, 2010 6:58 PM
> To: Sakari Ailus
> Cc: Bastian Hecht; Linux Media Mailing List
> Subject: Re: OMAP 3530 camera ISP forks and new media framework
> 
> Hi Bastian,
> 
> On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote:
> > Bastian Hecht wrote:
> >
> > > I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> > > chip and start getting confused about the different kernel forks and
> > > architectural changes that happen in V4L2.
> > > A similar problem was discussed in this mailing list at
> > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> > >
> > > Currently I don't know which branch to follow. Either
> > > http://gitorious.org/omap3camera from Sakari Ailus or the branch
> > > media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> > > Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> > > written for the new media controller architecture if I am right.
> >
> > Take Laurent's branch it has all the current patches in it. My gitorious
> > tree isn't updated anymore. (I just had forgotten to add a note, it's
> > there now.)
> >
> > > I see in http://gitorious.org/omap3camera/camera-firmware that there
> > > is already an empty placeholder for the mt9t031.
> > > The README of the camera-firmware repository states: "makemodes.pl is
> > > a perl script which converts sensor register lists from FIXME into C
> > > code. dcc-pulautin is a Makefile (mostly) that converts sensor
> > > register lists as C code into binaries understandable to sensor
> > > drivers. The end result is a binary with sensor driver name, sensor
> > > version and bin suffix, for example et8ek8-0002.bin."
> > >
> > > So I think the goal is to provide a script framework for camera
> > > systems. You just script some register tables and it creates a binary
> > > that can be read by a sensor driver made for that framework. If the a
> > > camera bridge driver for your chip exists, you are done. Am I right?
> > > Are drivers/media/video/et8ek8.c and
> > > drivers/staging/dream/camera/mt9p012_* such drivers?
> >
> > et8ek8 and smia-sensor currently use the camera-firmware binaries. The
> > long term goal is to move more things to the sensor driver itself.
> > Register lists related to a set of sensor settings are not an ideal way
> > to handle sensor related settings since they could be controlled the
> > driver instead.
> 
> To be compatible with the OMAP3 ISP driver, sensor drivers need to provide
> a
> v4l2_subdev interface and implement the pad-level operations (see the
> media-0003-subdev-pad branch in the repository).
> 
> I've written such a driver for the MT9T001. I've pushed it to the media-
> mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note
> that
> the driver is based on a previous version of the subdev pad-level
> operations
> API, so it won't compile out of the box.
> 


Just to add ontop of this, you can find couple of more sensor (MT9V113 & MT9T111) sub-dev driver at 

http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/omap3cam-mc-devel


Also I have already ported these sensor drivers to latest sub-dev pad level operations but have not tested and pushed to the Repository which I will do by this weekend.

Thanks,
Vaibhav

> As Sakari stated, the camera-firmware system shouldn't be used by new
> drivers.
> The driver should instead compute the register values directly from the
> information supplied by userspace (through the v4l2_subdev API) such as
> the
> frame size and the crop rectangle. Binary lists of register address/value
> pairs are definitely not the way to go.
> 
> > > So do you think it is the right way to go to use your ISP driver,
> > > adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> > > write a register list and create a camera firmware for that sensor
> > > driver with makemodes?
> >
> > I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
> > if you want to write a sensor driver to be used with the OMAP 3 ISP
> > driver. Register lists are not that nice but the v4l2_subdev interface
> > in that one is one of the good parts you get with that.
> 
> Start with the MT9T001 driver, that will be easier.
> 
> > I'd also advice against using camera-firmware if you don't necessarily
> > need that kind of functionality.
> 
> I'd very strongly advice against it as well. Try to forget it even exists,
> it
> was a development mistake :-)
> 
> > > I am still quite confused... if I get something wrong, please give me
> > > some hints.
> >
> > I hope this helped. :-)
> >
> > If you have any further questions feel free to ask.
> 
> Ditto :-)
> 
> --
> Regards,
> 
> Laurent Pinchart
> --
> 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: OMAP 3530 camera ISP forks and new media framework

[Guennadi Liakhovetski]

On Thu, 7 Oct 2010, Hiremath, Vaibhav wrote:

> 
> > -----Original Message-----
> > From: linux-media-owner@vger.kernel.org [mailto:linux-media-
> > owner@vger.kernel.org] On Behalf Of Laurent Pinchart
> > Sent: Thursday, October 07, 2010 6:58 PM
> > To: Sakari Ailus
> > Cc: Bastian Hecht; Linux Media Mailing List
> > Subject: Re: OMAP 3530 camera ISP forks and new media framework
> > 
> > Hi Bastian,
> > 
> > On Thursday 07 October 2010 12:58:53 Sakari Ailus wrote:
> > > Bastian Hecht wrote:
> > >
> > > > I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> > > > chip and start getting confused about the different kernel forks and

There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if 
mt9t031 and mt9p031 are indeed similar enough, I think, the right way is 
to join efforts to port soc-camera over to the new "pad-level" API and 
re-use the driver.

Thanks
Guennadi

> > > > architectural changes that happen in V4L2.
> > > > A similar problem was discussed in this mailing list at
> > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> > > >
> > > > Currently I don't know which branch to follow. Either
> > > > http://gitorious.org/omap3camera from Sakari Ailus or the branch
> > > > media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> > > > Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> > > > written for the new media controller architecture if I am right.
> > >
> > > Take Laurent's branch it has all the current patches in it. My gitorious
> > > tree isn't updated anymore. (I just had forgotten to add a note, it's
> > > there now.)
> > >
> > > > I see in http://gitorious.org/omap3camera/camera-firmware that there
> > > > is already an empty placeholder for the mt9t031.
> > > > The README of the camera-firmware repository states: "makemodes.pl is
> > > > a perl script which converts sensor register lists from FIXME into C
> > > > code. dcc-pulautin is a Makefile (mostly) that converts sensor
> > > > register lists as C code into binaries understandable to sensor
> > > > drivers. The end result is a binary with sensor driver name, sensor
> > > > version and bin suffix, for example et8ek8-0002.bin."
> > > >
> > > > So I think the goal is to provide a script framework for camera
> > > > systems. You just script some register tables and it creates a binary
> > > > that can be read by a sensor driver made for that framework. If the a
> > > > camera bridge driver for your chip exists, you are done. Am I right?
> > > > Are drivers/media/video/et8ek8.c and
> > > > drivers/staging/dream/camera/mt9p012_* such drivers?
> > >
> > > et8ek8 and smia-sensor currently use the camera-firmware binaries. The
> > > long term goal is to move more things to the sensor driver itself.
> > > Register lists related to a set of sensor settings are not an ideal way
> > > to handle sensor related settings since they could be controlled the
> > > driver instead.
> > 
> > To be compatible with the OMAP3 ISP driver, sensor drivers need to provide
> > a
> > v4l2_subdev interface and implement the pad-level operations (see the
> > media-0003-subdev-pad branch in the repository).
> > 
> > I've written such a driver for the MT9T001. I've pushed it to the media-
> > mt9t001 branch on http://git.linuxtv.org/pinchartl/media.git. Please note
> > that
> > the driver is based on a previous version of the subdev pad-level
> > operations
> > API, so it won't compile out of the box.
> > 
> 
> 
> Just to add ontop of this, you can find couple of more sensor (MT9V113 & MT9T111) sub-dev driver at 
> 
> http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/omap3cam-mc-devel
> 
> 
> Also I have already ported these sensor drivers to latest sub-dev pad level operations but have not tested and pushed to the Repository which I will do by this weekend.
> 
> Thanks,
> Vaibhav
> 
> > As Sakari stated, the camera-firmware system shouldn't be used by new
> > drivers.
> > The driver should instead compute the register values directly from the
> > information supplied by userspace (through the v4l2_subdev API) such as
> > the
> > frame size and the crop rectangle. Binary lists of register address/value
> > pairs are definitely not the way to go.
> > 
> > > > So do you think it is the right way to go to use your ISP driver,
> > > > adapt drivers/staging/dream/camera/mt9p012_* to suit my mt9p031 and
> > > > write a register list and create a camera firmware for that sensor
> > > > driver with makemodes?
> > >
> > > I would go with drivers/media/video/et8ek8.c in Laurent's tree instead
> > > if you want to write a sensor driver to be used with the OMAP 3 ISP
> > > driver. Register lists are not that nice but the v4l2_subdev interface
> > > in that one is one of the good parts you get with that.
> > 
> > Start with the MT9T001 driver, that will be easier.
> > 
> > > I'd also advice against using camera-firmware if you don't necessarily
> > > need that kind of functionality.
> > 
> > I'd very strongly advice against it as well. Try to forget it even exists,
> > it
> > was a development mistake :-)
> > 
> > > > I am still quite confused... if I get something wrong, please give me
> > > > some hints.
> > >
> > > I hope this helped. :-)
> > >
> > > If you have any further questions feel free to ask.
> > 
> > Ditto :-)
> > 
> > --
> > Regards,
> > 
> > Laurent Pinchart

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

>> > > Bastian Hecht wrote:
>> > >
>> > > > I want to write a sensor driver for the mt9p031 (not mt9t031) camera
>> > > > chip and start getting confused about the different kernel forks and
>
> There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if
> mt9t031 and mt9p031 are indeed similar enough, I think, the right way is
> to join efforts to port soc-camera over to the new "pad-level" API and
> re-use the driver.
>
> Thanks
> Guennadi
>

That would be wonderful. As this is my first contact with v4l2 in the
kernel I keep reading through the docs and the sources to get a firmer
grasp of all the stuff here.

Thanks,

Bastian

http://www.symplektikon.de/

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

So... let's see if i got some things right, please let me now if you disagree:

- I do want to use the omap34xxcam.c driver as it is for the newest
framework and I get most support for it

- The camera sensor driver must implement the v4l2-subdev and the new
pad-level api. As the register list of mt9t031 and mt9p031 sensors are
identical, I could copy the subdev-part. But the existing mt9t031
driver stacks on top of soc_camera. soc_camera creates a v4l2 device.
omap34xxcam also creates a v4l2 dev. Obviously they are competing
architectures.
Guennadi wrote:
> There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if
> mt9t031 and mt9p031 are indeed similar enough, I think, the right way is
> to join efforts to port soc-camera over to the new "pad-level" API and
> re-use the driver.
This confuses me a bit now. Guennadi, is your idea to update the
soc_camera interface for pad-level support and port omap34xxcam to a
soc_camera_omap34xxcam?
I don't think I am capable of writing a new host bridge driver, so I
would prefer touching only the sensor driver part. Or do you think it
is better to remove the soc_camera dependency and fit the camera
sensor driver to omap34xxcam directly?

- If I do the later, I take Laurent's approach and look at his MT9T001
sensor driver for Sakari's omap34xxcam host driver and adapt it for my
needs. I can look for more subdev pad-level examples in Vaibhav's
repository.


So long, thanks for all your help,

Bastian

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Bastian,

On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
> So... let's see if i got some things right, please let me now if you
> disagree:
> 
> - I do want to use the omap34xxcam.c driver as it is for the newest
> framework and I get most support for it

That's a bad start. With the latest driver, omap34xxcam.c doesn't exist 
anymore :-)

> - The camera sensor driver must implement the v4l2-subdev and the new
> pad-level api. As the register list of mt9t031 and mt9p031 sensors are
> identical, I could copy the subdev-part. But the existing mt9t031
> driver stacks on top of soc_camera. soc_camera creates a v4l2 device.
> omap34xxcam also creates a v4l2 dev. Obviously they are competing
> architectures.
> 
> Guennadi wrote:
> > There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if
> > mt9t031 and mt9p031 are indeed similar enough, I think, the right way is
> > to join efforts to port soc-camera over to the new "pad-level" API and
> > re-use the driver.
> 
> This confuses me a bit now. Guennadi, is your idea to update the
> soc_camera interface for pad-level support and port omap34xxcam to a
> soc_camera_omap34xxcam?
> I don't think I am capable of writing a new host bridge driver, so I
> would prefer touching only the sensor driver part. Or do you think it
> is better to remove the soc_camera dependency and fit the camera
> sensor driver to omap34xxcam directly?

You can either

- Take the mt9t031 driver, add support for the mt9p031 chip, make the soc-
camera dependency optional and add the pad-level operations. Adding support 
for the mt9p031 and adding pad-level operations (in addition to the existing 
subdev format operations) should be quite straightforward. Remove the soc-
camera dependency might be more difficult, I'm less experienced on that 
subject.

- Take the mt9t001 driver and add support for the mt9p031 chip. Register lists 
are quite similar, so that shouldn't be overly difficult. You would have to 
remove the hardcoded image sizes and make them configurable. Use the 
driver_data field in struct i2c_device_id mt9t001_id[] to store model-specific 
parameters. Different field sizes in some registers might make this approach a 
bit difficult.

> - If I do the later, I take Laurent's approach and look at his MT9T001
> sensor driver for Sakari's omap34xxcam host driver and adapt it for my
> needs. I can look for more subdev pad-level examples in Vaibhav's
> repository.

In the long term drivers should support both soc-camera and non soc-camera use 
cases, but we're not there yet.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bastian,
>
> On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
>> So... let's see if i got some things right, please let me now if you
>> disagree:
>>
>> - I do want to use the omap34xxcam.c driver as it is for the newest
>> framework and I get most support for it
>
> That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
> anymore :-)

Nice :S

I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
your framework is too much for me to start with). So in this driver I
tell the framework that I can do i2c probing, some subdev_core_ops and
some subdev_video_ops. I define these functions that mostly do some
basic i2c communication to the sensor chip. I guess I can handle that
as there are so many examples out there.

But where do I stack that on top? On the camera bridge host, but if it
isn't omap34xxcam, which driver can I use? How are they connected?

Thanks,

 Bastian

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Bastian,

On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
> >> So... let's see if i got some things right, please let me now if you
> >> disagree:
> >> 
> >> - I do want to use the omap34xxcam.c driver as it is for the newest
> >> framework and I get most support for it
> > 
> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
> > anymore :-)
> 
> Nice :S
> 
> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
> your framework is too much for me to start with). So in this driver I
> tell the framework that I can do i2c probing, some subdev_core_ops and
> some subdev_video_ops. I define these functions that mostly do some
> basic i2c communication to the sensor chip. I guess I can handle that
> as there are so many examples out there.

The best solution would be to add mt9p031 support to the mt9t001 driver. If 
that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify 
the driver as needed and merge the two drivers when you will be satisfied with 
the result.

> But where do I stack that on top? On the camera bridge host, but if it
> isn't omap34xxcam, which driver can I use? How are they connected?

http://gitorious.org/maemo-multimedia/omap3isp-rx51

The omap34xxcam.ko and isp-mod.ko modules have been merged into a single 
omap3-isp.ko module. All the driver code is now in drivers/media/video/isp.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Guennadi Liakhovetski]

On Mon, 11 Oct 2010, Bastian Hecht wrote:

> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > Hi Bastian,
> >
> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
> >> So... let's see if i got some things right, please let me now if you
> >> disagree:
> >>
> >> - I do want to use the omap34xxcam.c driver as it is for the newest
> >> framework and I get most support for it
> >
> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
> > anymore :-)
> 
> Nice :S
> 
> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
> your framework is too much for me to start with).

AFAIR, you said, that register sets of mt9t031 and mt9p031 are identical, 
so, I think, I will be against mainlining a new driver for the "same" 
hardware for the pad-level ops, duplicating an soc-camera driver. Apart 
from creating a one-off redundancy, this looks like an extremely negative 
precedent to me.

That said, please, double check your estimate as "identical." If there are 
differences, say, even in only 10% of registers, it might still be 
justified to make a new driver. mt9m001 and mt9t031 are also "very 
similar," still, it appeared to me at that time, that a new driver would 
be cleaner, than a single driver full of forks or other indirections.

Thanks
Guennadi

> So in this driver I
> tell the framework that I can do i2c probing, some subdev_core_ops and
> some subdev_video_ops. I define these functions that mostly do some
> basic i2c communication to the sensor chip. I guess I can handle that
> as there are so many examples out there.
> 
> But where do I stack that on top? On the camera bridge host, but if it
> isn't omap34xxcam, which driver can I use? How are they connected?
> 
> Thanks,
> 
>  Bastian
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

2010/10/11 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Mon, 11 Oct 2010, Bastian Hecht wrote:
>
>> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> > Hi Bastian,
>> >
>> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
>> >> So... let's see if i got some things right, please let me now if you
>> >> disagree:
>> >>
>> >> - I do want to use the omap34xxcam.c driver as it is for the newest
>> >> framework and I get most support for it
>> >
>> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
>> > anymore :-)
>>
>> Nice :S
>>
>> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
>> your framework is too much for me to start with).
>
> AFAIR, you said, that register sets of mt9t031 and mt9p031 are identical,
> so, I think, I will be against mainlining a new driver for the "same"
> hardware for the pad-level ops, duplicating an soc-camera driver. Apart
> from creating a one-off redundancy, this looks like an extremely negative
> precedent to me.
>
> That said, please, double check your estimate as "identical." If there are
> differences, say, even in only 10% of registers, it might still be
> justified to make a new driver. mt9m001 and mt9t031 are also "very
> similar," still, it appeared to me at that time, that a new driver would
> be cleaner, than a single driver full of forks or other indirections.
>
> Thanks
> Guennadi
>

The point is, I will jump around my office for a full day when I get
out a single picture of my camera PCB. After that I will gladly work
towards uncluttering the driver duplication. I will see if it fits
better the mt9t001 or mt9t031 and integrate it in there.

Cheers,

 Bastian


>> So in this driver I
>> tell the framework that I can do i2c probing, some subdev_core_ops and
>> some subdev_video_ops. I define these functions that mostly do some
>> basic i2c communication to the sensor chip. I guess I can handle that
>> as there are so many examples out there.
>>
>> But where do I stack that on top? On the camera bridge host, but if it
>> isn't omap34xxcam, which driver can I use? How are they connected?
>>
>> Thanks,
>>
>>  Bastian
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

Hello Laurent,

2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bastian,
>
> On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
>> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
>> >> So... let's see if i got some things right, please let me now if you
>> >> disagree:
>> >>
>> >> - I do want to use the omap34xxcam.c driver as it is for the newest
>> >> framework and I get most support for it
>> >
>> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
>> > anymore :-)
>>
>> Nice :S
>>
>> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
>> your framework is too much for me to start with). So in this driver I
>> tell the framework that I can do i2c probing, some subdev_core_ops and
>> some subdev_video_ops. I define these functions that mostly do some
>> basic i2c communication to the sensor chip. I guess I can handle that
>> as there are so many examples out there.
>
> The best solution would be to add mt9p031 support to the mt9t001 driver. If
> that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify
> the driver as needed and merge the two drivers when you will be satisfied with
> the result.
>

OK, now I built the nokia kernel for the omap3-isp and made your
mt9t001.c work for it.
In mt9t001.c you call i2c_add_driver(&mt9t001_driver);
As far I as I figured out the driver core system looks for matches
between registered devices in arch/arm/omap/devices.c and appropriate
drivers.
Is the next step to include a static struct platform_device into
devices.c? Or is there a special i2c_device struct that I have to use?

Thanks so much,

 Bastian



>> But where do I stack that on top? On the camera bridge host, but if it
>> isn't omap34xxcam, which driver can I use? How are they connected?
>
> http://gitorious.org/maemo-multimedia/omap3isp-rx51
>
> The omap34xxcam.ko and isp-mod.ko modules have been merged into a single
> omap3-isp.ko module. All the driver code is now in drivers/media/video/isp.
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Bastian,

On Tuesday 12 October 2010 14:10:00 Bastian Hecht wrote:
> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
> >> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> >> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
> >> >> So... let's see if i got some things right, please let me now if you
> >> >> disagree:
> >> >> 
> >> >> - I do want to use the omap34xxcam.c driver as it is for the newest
> >> >> framework and I get most support for it
> >> > 
> >> > That's a bad start. With the latest driver, omap34xxcam.c doesn't
> >> > exist anymore :-)
> >> 
> >> Nice :S
> >> 
> >> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
> >> your framework is too much for me to start with). So in this driver I
> >> tell the framework that I can do i2c probing, some subdev_core_ops and
> >> some subdev_video_ops. I define these functions that mostly do some
> >> basic i2c communication to the sensor chip. I guess I can handle that
> >> as there are so many examples out there.
> > 
> > The best solution would be to add mt9p031 support to the mt9t001 driver.
> > If that's too difficult to start with, you can copy mt9t001 to mt9p031
> > and modify the driver as needed and merge the two drivers when you will
> > be satisfied with the result.
> 
> OK, now I built the nokia kernel for the omap3-isp and made your
> mt9t001.c work for it.
> In mt9t001.c you call i2c_add_driver(&mt9t001_driver);
> As far I as I figured out the driver core system looks for matches
> between registered devices in arch/arm/omap/devices.c and appropriate
> drivers.

The driver core looks for matches between registered drivers and registered 
devices. Devices are registered in lots of places, arch/arm/omap/devices.c is 
only one of them. Board-specific devices are registered (or at least declared) 
in a board file located (for this architecture) in arch/arm/mach-omap2/.

> Is the next step to include a static struct platform_device into
> devices.c? Or is there a special i2c_device struct that I have to use?

The OMAP3 ISP driver requires platform data that contain, among other 
information, the list of I2C subdevices. Have a look at arch/arm/mach-
omap2/board-rx51-camera.c.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

2010/10/12 Bastian Hecht <hechtb@googlemail.com>:
> Hello Laurent,
>
> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> Hi Bastian,
>>
>> On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
>>> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>>> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
>>> >> So... let's see if i got some things right, please let me now if you
>>> >> disagree:
>>> >>
>>> >> - I do want to use the omap34xxcam.c driver as it is for the newest
>>> >> framework and I get most support for it
>>> >
>>> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist
>>> > anymore :-)
>>>
>>> Nice :S
>>>
>>> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
>>> your framework is too much for me to start with). So in this driver I
>>> tell the framework that I can do i2c probing, some subdev_core_ops and
>>> some subdev_video_ops. I define these functions that mostly do some
>>> basic i2c communication to the sensor chip. I guess I can handle that
>>> as there are so many examples out there.
>>
>> The best solution would be to add mt9p031 support to the mt9t001 driver. If
>> that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify
>> the driver as needed and merge the two drivers when you will be satisfied with
>> the result.
>>
>
> OK, now I built the nokia kernel for the omap3-isp and made your
> mt9t001.c work for it.
> In mt9t001.c you call i2c_add_driver(&mt9t001_driver);
> As far I as I figured out the driver core system looks for matches
> between registered devices in arch/arm/omap/devices.c and appropriate
> drivers.
> Is the next step to include a static struct platform_device into
> devices.c? Or is there a special i2c_device struct that I have to use?
>
> Thanks so much,
>
>  Bastian
>

I now use the board-rx51-camera.c as scaffold and try to integrate my
camera chip device information.

>
>>> But where do I stack that on top? On the camera bridge host, but if it
>>> isn't omap34xxcam, which driver can I use? How are they connected?
>>
>> http://gitorious.org/maemo-multimedia/omap3isp-rx51
>>
>> The omap34xxcam.ko and isp-mod.ko modules have been merged into a single
>> omap3-isp.ko module. All the driver code is now in drivers/media/video/isp.
>>
>> --
>> Regards,
>>
>> Laurent Pinchart
>>
>

Re: OMAP 3530 camera ISP forks and new media framework

[Eino-Ville Talvala]

 Hi Laurent, linux-media,

We've been working on porting our OMAP3 ISP/mt9p031 Frankencamera framework forward to the current kernel versions (currently, we're using the N900 ISP driver codebase, which is rather old by now).  We'd been following Sakari's omap3camera tree, but as is clear from this discussion, that's a bad idea now.

(I'd love to just send out our mt9p031 driver code, but we still haven't sorted out whether we're free to do so - since we're rewriting it a great deal anyway, it hasn't been a priority to sort out.)

I've been handing off dev work on this to the next set of students on the project, so I haven't been paying much attention to the mailing lists recently, and I apologize if these questions have had clear answers already.

Assuming one has a driver that works fine on the old v4l2_int_framework back in .28-n900 kernel version - what is the best way forward to move it to the 'current best option' framework, whatever that's currently considered to be for the OMAP3 ISP?  And for whatever option that is, is there a document somewhere describing what needs to hooked up to what to make that go, or is the best way to just look at the *-rx51 / et8ek8 code in the right git repository?

Any advice would be appreciated!

Eino-Ville Talvala
Camera 2.0 Project
Stanford University

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Eino-Ville,

On Thursday 14 October 2010 00:03:33 Eino-Ville Talvala wrote:
>  Hi Laurent, linux-media,
> 
> We've been working on porting our OMAP3 ISP/mt9p031 Frankencamera framework
> forward to the current kernel versions (currently, we're using the N900
> ISP driver codebase, which is rather old by now). We'd been following
> Sakari's omap3camera tree, but as is clear from this discussion, that's a
> bad idea now.
> 
> (I'd love to just send out our mt9p031 driver code, but we still haven't
> sorted out whether we're free to do so - since we're rewriting it a great
> deal anyway, it hasn't been a priority to sort out.)
> 
> I've been handing off dev work on this to the next set of students on the
> project, so I haven't been paying much attention to the mailing lists
> recently, and I apologize if these questions have had clear answers
> already.
> 
> Assuming one has a driver that works fine on the old v4l2_int_framework
> back in .28-n900 kernel version - what is the best way forward to move it
> to the 'current best option' framework, whatever that's currently
> considered to be for the OMAP3 ISP?  And for whatever option that is, is
> there a document somewhere describing what needs to hooked up to what to
> make that go, or is the best way to just look at the *-rx51 / et8ek8 code
> in the right git repository?

First of all, you need to get the latest OMAP3 ISP driver sources.

The most recent OMAP3 ISP driver for the N900 can be found in the omap3isp-
rx51 git tree on gitorious.org (devel branch from 
http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the tree 
used by MeeGo for the OMAP3 ISP camera driver. The driver has been ported to 
the media controller framework, but the latest changes to the framework are 
not present in that tree as they break the driver ABI and API. This should be 
fixed in the future, but I can't give you any time estimate at the moment.

The most recent OMAP3 ISP driver and media controller framework can be found 
in the pinchartl/media git tree on linuxtv.org (media-0004-omap3isp branch 
from http://git.linuxtv.org/pinchartl/media.git). This is the tree used for 
upstream submission of the media controller and OMAP3 ISP driver. The OMAP3 
ISP driver implements the latest media controller API, but the tree doesn't 
contain RX51 camera support.

As I assume you need RX51 camera support (arch/arm/mach-omap2/board-rx51-
camera.c, drivers/media/video/et8ek8.c, ...), the easiest solution is to go 
for the gitorious.org tree. You will need to modify your code later when the 
OMAP3 ISP driver will hit upstream, but the modifications will be very small 
(mostly a matter of renaming constants or structure fields).

If you want to play with the latest media controller API, you could go for the 
linuxtv.org tree and port the RX51 camera support from the gitorious.org tree. 
That shouldn't be difficult, but time is unfortunately a scarce resource.

For userspace API documentation, run "make htmldocs" on the linuxtv.org tree 
to generate HTML documentation, and navigate to 
Documentation/DocBook/media/media_controller.html and 
Documentation/DocBook/media/subdev.html.

Regarding the v4l2_int framework, your kernel drivers will need to be ported 
to the V4L2 subdev framework and use pad-level operations. The et8ek8 driver 
should be a good example. You can also have a look at the mt9t001 driver in 
the media-mt9t001 branch from the linuxtv.org tree. The subdev pad-level 
userspace API documentation will also help you understand the in-kernel API.

I hope this information will help you. Feel free to contact me if you have 
further questions.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Eino-Ville Talvala]

On 10/13/2010 3:58 PM, Laurent Pinchart wrote:
> Hi Eino-Ville,
>
> On Thursday 14 October 2010 00:03:33 Eino-Ville Talvala wrote:
>>   Hi Laurent, linux-media,
>>
>> We've been working on porting our OMAP3 ISP/mt9p031 Frankencamera framework
>> forward to the current kernel versions (currently, we're using the N900
>> ISP driver codebase, which is rather old by now). We'd been following
>> Sakari's omap3camera tree, but as is clear from this discussion, that's a
>> bad idea now.
>>
>> (I'd love to just send out our mt9p031 driver code, but we still haven't
>> sorted out whether we're free to do so - since we're rewriting it a great
>> deal anyway, it hasn't been a priority to sort out.)
>>
>> I've been handing off dev work on this to the next set of students on the
>> project, so I haven't been paying much attention to the mailing lists
>> recently, and I apologize if these questions have had clear answers
>> already.
>>
>> Assuming one has a driver that works fine on the old v4l2_int_framework
>> back in .28-n900 kernel version - what is the best way forward to move it
>> to the 'current best option' framework, whatever that's currently
>> considered to be for the OMAP3 ISP?  And for whatever option that is, is
>> there a document somewhere describing what needs to hooked up to what to
>> make that go, or is the best way to just look at the *-rx51 / et8ek8 code
>> in the right git repository?
> First of all, you need to get the latest OMAP3 ISP driver sources.
>
> The most recent OMAP3 ISP driver for the N900 can be found in the omap3isp-
> rx51 git tree on gitorious.org (devel branch from
> http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the tree
> used by MeeGo for the OMAP3 ISP camera driver. The driver has been ported to
> the media controller framework, but the latest changes to the framework are
> not present in that tree as they break the driver ABI and API. This should be
> fixed in the future, but I can't give you any time estimate at the moment.
>
> The most recent OMAP3 ISP driver and media controller framework can be found
> in the pinchartl/media git tree on linuxtv.org (media-0004-omap3isp branch
> from http://git.linuxtv.org/pinchartl/media.git). This is the tree used for
> upstream submission of the media controller and OMAP3 ISP driver. The OMAP3
> ISP driver implements the latest media controller API, but the tree doesn't
> contain RX51 camera support.
>
> As I assume you need RX51 camera support (arch/arm/mach-omap2/board-rx51-
> camera.c, drivers/media/video/et8ek8.c, ...), the easiest solution is to go
> for the gitorious.org tree. You will need to modify your code later when the
> OMAP3 ISP driver will hit upstream, but the modifications will be very small
> (mostly a matter of renaming constants or structure fields).
>
> If you want to play with the latest media controller API, you could go for the
> linuxtv.org tree and port the RX51 camera support from the gitorious.org tree.
> That shouldn't be difficult, but time is unfortunately a scarce resource.
>
> For userspace API documentation, run "make htmldocs" on the linuxtv.org tree
> to generate HTML documentation, and navigate to
> Documentation/DocBook/media/media_controller.html and
> Documentation/DocBook/media/subdev.html.
>
> Regarding the v4l2_int framework, your kernel drivers will need to be ported
> to the V4L2 subdev framework and use pad-level operations. The et8ek8 driver
> should be a good example. You can also have a look at the mt9t001 driver in
> the media-mt9t001 branch from the linuxtv.org tree. The subdev pad-level
> userspace API documentation will also help you understand the in-kernel API.
>
> I hope this information will help you. Feel free to contact me if you have
> further questions.
>
Thanks for the reply!

We're not terribly set on requiring rx51 support right - at least, I'm 
assuming we couldn't just use the latest codebase for the ISP/et8ek8 
drivers and get those to compile with the N900's release kernel, and we 
don't want to ask end users to reflash their phone kernels to use our 
programs and API.

Mostly, I just want to make sure that we try to ensure the fewest number 
of substantial driver changes in the future, once we've gotten ourselves 
up to the present. So if one of the two options you listed is the way 
things will end up, I'd rather go with that and have a bit more work to 
do if we need to support some other device that looks more like the rx51 
in the future.

I gather the linux-tv branch is more like how things should end up 
looking like, once the dust settles for a bit.  So we port our driver 
over to that, using the mt9t001 driver as an example of how everything 
should be coded up, that should put us on a track of reasonable stability?

Also, is there a board file that has the needed sensor device 
registration/power management/etc bits in that tree?

Thanks,

Eino-Ville

Re: OMAP 3530 camera ISP forks and new media framework

[Bastian Hecht]

Hi Laurent,

2010/10/12 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Bastian,
>
> On Tuesday 12 October 2010 14:10:00 Bastian Hecht wrote:
>> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> > On Monday 11 October 2010 16:58:35 Bastian Hecht wrote:
>> >> 2010/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> >> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote:
>> >> >> So... let's see if i got some things right, please let me now if you
>> >> >> disagree:
>> >> >>
>> >> >> - I do want to use the omap34xxcam.c driver as it is for the newest
>> >> >> framework and I get most support for it
>> >> >
>> >> > That's a bad start. With the latest driver, omap34xxcam.c doesn't
>> >> > exist anymore :-)
>> >>
>> >> Nice :S
>> >>
>> >> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying
>> >> your framework is too much for me to start with). So in this driver I
>> >> tell the framework that I can do i2c probing, some subdev_core_ops and
>> >> some subdev_video_ops. I define these functions that mostly do some
>> >> basic i2c communication to the sensor chip. I guess I can handle that
>> >> as there are so many examples out there.
>> >
>> > The best solution would be to add mt9p031 support to the mt9t001 driver.
>> > If that's too difficult to start with, you can copy mt9t001 to mt9p031
>> > and modify the driver as needed and merge the two drivers when you will
>> > be satisfied with the result.
>>
>> OK, now I built the nokia kernel for the omap3-isp and made your
>> mt9t001.c work for it.
>> In mt9t001.c you call i2c_add_driver(&mt9t001_driver);
>> As far I as I figured out the driver core system looks for matches
>> between registered devices in arch/arm/omap/devices.c and appropriate
>> drivers.
>
> The driver core looks for matches between registered drivers and registered
> devices. Devices are registered in lots of places, arch/arm/omap/devices.c is
> only one of them. Board-specific devices are registered (or at least declared)
> in a board file located (for this architecture) in arch/arm/mach-omap2/.
>
>> Is the next step to include a static struct platform_device into
>> devices.c? Or is there a special i2c_device struct that I have to use?
>
> The OMAP3 ISP driver requires platform data that contain, among other
> information, the list of I2C subdevices. Have a look at arch/arm/mach-
> omap2/board-rx51-camera.c.
>

OK, I am closing in :)

I registered the OMAP_ISP device in my board-module. The driver kicks in
[  205.686248] omap3isp omap3isp: Revision 2.0 found

and I can see the device in /sys/devices/platform/omap3isp.
I loaded your slightly modified mt9t001 module under the name mt9p031
and I can find it under
/sys/bus/i2c/drivers/mt9p031
/sys/module/laurentcam/drivers/i2c:mt9p031

But this subdevice-driver doesn't get active (I added alot printk in
the sensor module code, but no probing, nothing happens except the
registration). I have not connected anything to the camera isp
physically, but I think it should find out when probing?
I also see no /dev/videox device from the isp. Can you guide me to
next step? Your help makes it so much easier and I really appreciate
it :)

Thanks,

 Bastian


Here my board code:

static struct mt9t001_platform_data bastix_mt9p031_platform_data = {
        .clk_pol        = 0,
};


static struct i2c_board_info bastix_camera_i2c_devices[] = {
        {
                I2C_BOARD_INFO(MT9P031_NAME, MT9P031_I2C_ADDR), /*
name is "mt9p031" and i2caddr is fantasy number */
                .platform_data = &bastix_mt9p031_platform_data,
        },
};

static struct v4l2_subdev_i2c_board_info bastix_camera_mt9p031[] = {
        {
                .board_info = &bastix_camera_i2c_devices[0],
                .i2c_adapter_id = BASTIX_CAM_I2C_BUS_NUM, /* busnum is 2 */
                .module_name = "mt9p031",
        },
        { NULL, 0, NULL, },
};

static struct isp_v4l2_subdevs_group bastix_camera_subdevs[] = {
        {
                .subdevs = bastix_camera_mt9p031,
                .interface = ISP_INTERFACE_CCP2B_PHY1,
                .bus = { .ccp2 = {
                        .strobe_clk_pol         = 0,
                        .crc                    = 1,
                        .ccp2_mode              = 1,
                        .phy_layer              = 1,
                        .vpclk_div              = 1,
                } },
        },
        { NULL, 0, },
};

static struct isp_platform_data bastix_isp_platform_data = {
        .subdevs = bastix_camera_subdevs,
};

module_init() {
...
omap3isp_device.dev.platform_data = &bastix_isp_platform_data;
return platform_device_register(&omap3isp_device);
}

> --
> Regards,
>
> Laurent Pinchart
>

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Bastian,

On Thursday 14 October 2010 15:10:46 Bastian Hecht wrote:
> 2010/10/12 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:

[snip]

> > The OMAP3 ISP driver requires platform data that contain, among other
> > information, the list of I2C subdevices. Have a look at arch/arm/mach-
> > omap2/board-rx51-camera.c.
> 
> OK, I am closing in :)
> 
> I registered the OMAP_ISP device in my board-module. The driver kicks in
> [  205.686248] omap3isp omap3isp: Revision 2.0 found
> 
> and I can see the device in /sys/devices/platform/omap3isp.
> I loaded your slightly modified mt9t001 module under the name mt9p031
> and I can find it under
> /sys/bus/i2c/drivers/mt9p031
> /sys/module/laurentcam/drivers/i2c:mt9p031

The module should be loaded automatically. Make sure you modify the 
mt9t001_id[] array to replace "mt9t001" with "mt9p031".

> But this subdevice-driver doesn't get active (I added alot printk in
> the sensor module code, but no probing, nothing happens except the
> registration). I have not connected anything to the camera isp
> physically, but I think it should find out when probing?

Yes. The sensor driver probe function will try to access the sensor and will 
fail. This will in turn make the OMAP3 ISP driver fail, but you should at 
least get error messages.

> I also see no /dev/videox device from the isp. Can you guide me to
> next step? Your help makes it so much easier and I really appreciate
> it :)
> 
> Here my board code:
> 
> static struct mt9t001_platform_data bastix_mt9p031_platform_data = {
>         .clk_pol        = 0,
> };
> 
> 
> static struct i2c_board_info bastix_camera_i2c_devices[] = {
>         {
>                 I2C_BOARD_INFO(MT9P031_NAME, MT9P031_I2C_ADDR), /*
> name is "mt9p031" and i2caddr is fantasy number */

You need to provide a correct I2C address.

>                 .platform_data = &bastix_mt9p031_platform_data,
>         },
> };
> 
> static struct v4l2_subdev_i2c_board_info bastix_camera_mt9p031[] = {
>         {
>                 .board_info = &bastix_camera_i2c_devices[0],
>                 .i2c_adapter_id = BASTIX_CAM_I2C_BUS_NUM, /* busnum is 2 */
>                 .module_name = "mt9p031",

This field has disappeared recently. Please upgrade to the latest OMAP3 ISP 
driver version.

>         },
>         { NULL, 0, NULL, },
> };
> 
> static struct isp_v4l2_subdevs_group bastix_camera_subdevs[] = {
>         {
>                 .subdevs = bastix_camera_mt9p031,
>                 .interface = ISP_INTERFACE_CCP2B_PHY1,
>                 .bus = { .ccp2 = {
>                         .strobe_clk_pol         = 0,
>                         .crc                    = 1,
>                         .ccp2_mode              = 1,
>                         .phy_layer              = 1,
>                         .vpclk_div              = 1,
>                 } },

The mt9p031 is a parallel sensor, not a serial sensor. Use the following code 
(and replace the data_lane_shift and clk_pol variable depending on your 
hardware).

                .interface = ISP_INTERFACE_PARALLEL,
                .bus = { .parallel = {
                        .data_lane_shift        = 1,
                        .clk_pol                = 1,
                        .bridge                 = ISPCTRL_PAR_BRIDGE_DISABLE,
                } },

>         },
>         { NULL, 0, },
> };
> 
> static struct isp_platform_data bastix_isp_platform_data = {
>         .subdevs = bastix_camera_subdevs,
> };
> 
> module_init() {
> ...
> omap3isp_device.dev.platform_data = &bastix_isp_platform_data;
> return platform_device_register(&omap3isp_device);
> }

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Eino-Ville,

On Thursday 14 October 2010 07:18:01 Eino-Ville Talvala wrote:
> On 10/13/2010 3:58 PM, Laurent Pinchart wrote:
> > On Thursday 14 October 2010 00:03:33 Eino-Ville Talvala wrote:
> >>   Hi Laurent, linux-media,
> >> 
> >> We've been working on porting our OMAP3 ISP/mt9p031 Frankencamera
> >> framework forward to the current kernel versions (currently, we're
> >> using the N900 ISP driver codebase, which is rather old by now). We'd
> >> been following Sakari's omap3camera tree, but as is clear from this
> >> discussion, that's a bad idea now.
> >> 
> >> (I'd love to just send out our mt9p031 driver code, but we still haven't
> >> sorted out whether we're free to do so - since we're rewriting it a
> >> great deal anyway, it hasn't been a priority to sort out.)
> >> 
> >> I've been handing off dev work on this to the next set of students on
> >> the project, so I haven't been paying much attention to the mailing
> >> lists recently, and I apologize if these questions have had clear
> >> answers already.
> >> 
> >> Assuming one has a driver that works fine on the old v4l2_int_framework
> >> back in .28-n900 kernel version - what is the best way forward to move
> >> it to the 'current best option' framework, whatever that's currently
> >> considered to be for the OMAP3 ISP?  And for whatever option that is,
> >> is there a document somewhere describing what needs to hooked up to
> >> what to make that go, or is the best way to just look at the *-rx51 /
> >> et8ek8 code in the right git repository?
> > 
> > First of all, you need to get the latest OMAP3 ISP driver sources.
> > 
> > The most recent OMAP3 ISP driver for the N900 can be found in the
> > omap3isp- rx51 git tree on gitorious.org (devel branch from
> > http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the
> > tree used by MeeGo for the OMAP3 ISP camera driver. The driver has been
> > ported to the media controller framework, but the latest changes to the
> > framework are not present in that tree as they break the driver ABI and
> > API. This should be fixed in the future, but I can't give you any time
> > estimate at the moment.
> > 
> > The most recent OMAP3 ISP driver and media controller framework can be
> > found in the pinchartl/media git tree on linuxtv.org
> > (media-0004-omap3isp branch from
> > http://git.linuxtv.org/pinchartl/media.git). This is the tree used for
> > upstream submission of the media controller and OMAP3 ISP driver. The
> > OMAP3 ISP driver implements the latest media controller API, but the
> > tree doesn't contain RX51 camera support.
> > 
> > As I assume you need RX51 camera support (arch/arm/mach-omap2/board-rx51-
> > camera.c, drivers/media/video/et8ek8.c, ...), the easiest solution is to
> > go for the gitorious.org tree. You will need to modify your code later
> > when the OMAP3 ISP driver will hit upstream, but the modifications will
> > be very small (mostly a matter of renaming constants or structure
> > fields).
> > 
> > If you want to play with the latest media controller API, you could go
> > for the linuxtv.org tree and port the RX51 camera support from the
> > gitorious.org tree. That shouldn't be difficult, but time is
> > unfortunately a scarce resource.
> > 
> > For userspace API documentation, run "make htmldocs" on the linuxtv.org
> > tree to generate HTML documentation, and navigate to
> > Documentation/DocBook/media/media_controller.html and
> > Documentation/DocBook/media/subdev.html.
> > 
> > Regarding the v4l2_int framework, your kernel drivers will need to be
> > ported to the V4L2 subdev framework and use pad-level operations. The
> > et8ek8 driver should be a good example. You can also have a look at the
> > mt9t001 driver in the media-mt9t001 branch from the linuxtv.org tree.
> > The subdev pad-level userspace API documentation will also help you
> > understand the in-kernel API.
> > 
> > I hope this information will help you. Feel free to contact me if you
> > have further questions.
> 
> Thanks for the reply!

You're welcome.

> We're not terribly set on requiring rx51 support right - at least, I'm
> assuming we couldn't just use the latest codebase for the ISP/et8ek8
> drivers and get those to compile with the N900's release kernel, and we
> don't want to ask end users to reflash their phone kernels to use our
> programs and API.

The V4L core and media controller frameworks could be ported to the N900's 
release kernel, but I'm not sure it would be worth it. You can use the latest 
OMAP3 ISP driver on the N900 with MeeGo though.

> Mostly, I just want to make sure that we try to ensure the fewest number
> of substantial driver changes in the future, once we've gotten ourselves
> up to the present. So if one of the two options you listed is the way
> things will end up, I'd rather go with that and have a bit more work to
> do if we need to support some other device that looks more like the rx51
> in the future.
> 
> I gather the linux-tv branch is more like how things should end up
> looking like, once the dust settles for a bit.  So we port our driver
> over to that, using the mt9t001 driver as an example of how everything
> should be coded up, that should put us on a track of reasonable stability?

That's correct.

> Also, is there a board file that has the needed sensor device
> registration/power management/etc bits in that tree?

There's the RX51 board code in the gitorious tree. It shouldn't be difficult 
to adapt it to a parallel sensor.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Michael Jones]

Sakari Ailus wrote:
> Bastian Hecht wrote:
>> Hello media team,
> 
> Hi Bastian,
> 
>> I want to write a sensor driver for the mt9p031 (not mt9t031) camera
>> chip and start getting confused about the different kernel forks and
>> architectural changes that happen in V4L2.
>> A similar problem was discussed in this mailing list at
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
>>
>> Currently I don't know which branch to follow. Either
>> http://gitorious.org/omap3camera from Sakari Ailus or the branch
>> media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
>> Laurent Pinchart. Both have an folder drivers/media/video/isp and are
>> written for the new media controller architecture if I am right.
> 
> Take Laurent's branch it has all the current patches in it. My gitorious
> tree isn't updated anymore. (I just had forgotten to add a note, it's
> there now.)
> 

Will Laurent's media-0004-omap3isp branch at linuxtv.org then continue to get updated?  Or will the existing commits be rebased at some point?  I'm trying to understand/decide what the best approach is with git if I continue doing development on top of the media controller and want to stay up to date.

<snip>

thanks,

-- 
Michael Jones

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

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Michael,

On Friday 22 October 2010 15:54:59 Michael Jones wrote:
> Sakari Ailus wrote:
> > Bastian Hecht wrote:
> >> I want to write a sensor driver for the mt9p031 (not mt9t031) camera
> >> chip and start getting confused about the different kernel forks and
> >> architectural changes that happen in V4L2.
> >> A similar problem was discussed in this mailing list at
> >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg19084.html.
> >> 
> >> Currently I don't know which branch to follow. Either
> >> http://gitorious.org/omap3camera from Sakari Ailus or the branch
> >> media-0004-omap3isp at http://git.linuxtv.org/pinchartl/media.git from
> >> Laurent Pinchart. Both have an folder drivers/media/video/isp and are
> >> written for the new media controller architecture if I am right.
> > 
> > Take Laurent's branch it has all the current patches in it. My gitorious
> > tree isn't updated anymore. (I just had forgotten to add a note, it's
> > there now.)
> 
> Will Laurent's media-0004-omap3isp branch at linuxtv.org then continue to
> get updated?  Or will the existing commits be rebased at some point?  I'm
> trying to understand/decide what the best approach is with git if I
> continue doing development on top of the media controller and want to stay
> up to date.

The media-0004-omap3isp branch in the media repository on linuxtv.org will be 
updated regularly until the driver is merged in the mainline Linux kernel (in 
the meantime I will rebase the branch every time a major kernel version comes 
out). Development will then move to mainline.

-- 
Regards,

Laurent Pinchart

Re: OMAP 3530 camera ISP forks and new media framework

[Michael Jones]

Hi Laurent,

Laurent Pinchart wrote:

> 
> First of all, you need to get the latest OMAP3 ISP driver sources.
> 
> The most recent OMAP3 ISP driver for the N900 can be found in the omap3isp-
> rx51 git tree on gitorious.org (devel branch from 
> http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the tree 
> used by MeeGo for the OMAP3 ISP camera driver. The driver has been ported to 
> the media controller framework, but the latest changes to the framework are 
> not present in that tree as they break the driver ABI and API. This should be 
> fixed in the future, but I can't give you any time estimate at the moment.
> 
> The most recent OMAP3 ISP driver and media controller framework can be found 
> in the pinchartl/media git tree on linuxtv.org (media-0004-omap3isp branch 
> from http://git.linuxtv.org/pinchartl/media.git). This is the tree used for 
> upstream submission of the media controller and OMAP3 ISP driver. The OMAP3 
> ISP driver implements the latest media controller API, but the tree doesn't 
> contain RX51 camera support.
>

You say "the most recent OMAP3 ISP driver for the N900" is on gitorious but "the most recent OMAP3 ISP driver and media controller framework" is your branch.  I'm confused about where I find "the most recent OMAP3 ISP driver".  To take a concrete example, in media-0004-omap3isp, media_device_register() WARNs if mdev doesn't have a model name (I get the warning).  On the Meego branch, it WARNs only if it's missing both a model name and a parent dev pointer.  If I understood you correctly above, media-0004-omap3isp has the newer framework, so the newer framework requires a model name?

I don't need RX51 camera support, but I would like to have a reasonably up-to-date OMAP3 ISP driver.  Laurent said before that media-0004-omap3isp will be updated regularly.  Do these updates come from a cherry-pick of the gitorious branch?  I anticipate sending a patch based on media-0004-omap3isp someday (like one addressing my WARN_ON issue) and getting as a reply, "yeah, we already did that on meego.gitorious.org".

I appreciate your help so far.

-- 
Michael Jones

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

Re: OMAP 3530 camera ISP forks and new media framework

[Laurent Pinchart]

Hi Michael,

On Thursday 28 October 2010 12:28:46 Michael Jones wrote:
> Laurent Pinchart wrote:
> > First of all, you need to get the latest OMAP3 ISP driver sources.
> > 
> > The most recent OMAP3 ISP driver for the N900 can be found in the
> > omap3isp- rx51 git tree on gitorious.org (devel branch from
> > http://meego.gitorious.org/maemo-multimedia/omap3isp-rx51). This is the
> > tree used by MeeGo for the OMAP3 ISP camera driver. The driver has been
> > ported to the media controller framework, but the latest changes to the
> > framework are not present in that tree as they break the driver ABI and
> > API. This should be fixed in the future, but I can't give you any time
> > estimate at the moment.
> > 
> > The most recent OMAP3 ISP driver and media controller framework can be
> > found in the pinchartl/media git tree on linuxtv.org
> > (media-0004-omap3isp branch from
> > http://git.linuxtv.org/pinchartl/media.git). This is the tree used for
> > upstream submission of the media controller and OMAP3 ISP driver. The
> > OMAP3 ISP driver implements the latest media controller API, but the
> > tree doesn't contain RX51 camera support.
> 
> You say "the most recent OMAP3 ISP driver for the N900" is on gitorious but
> "the most recent OMAP3 ISP driver and media controller framework" is your
> branch. I'm confused about where I find "the most recent OMAP3 ISP driver".

The OMAP3 ISP driver on linuxtv is the most recent one, but doesn't support 
the N900 as it lacks sensor drivers and board code. The gitorious tree has 
full N900 camera support but is based on 2.6.35 and on an older media 
controller API.

> To take a concrete example, in media-0004-omap3isp, media_device_register()
> WARNs if mdev doesn't have a model name (I get the warning).  On the Meego
> branch, it WARNs only if it's missing both a model name and a parent dev
> pointer. If I understood you correctly above, media-0004-omap3isp has the
> newer framework, so the newer framework requires a model name?

That's correct.

> I don't need RX51 camera support, but I would like to have a reasonably
> up-to-date OMAP3 ISP driver.

Then go for the linuxtv tree.

> Laurent said before that media-0004-omap3isp will be updated regularly.  Do
> these updates come from a cherry-pick of the gitorious branch?

Both the gitorious and the linuxtv tree are updated from an internal 
development tree.

> I anticipate sending a patch based on media-0004-omap3isp someday (like one
> addressing my WARN_ON issue) and getting as a reply, "yeah, we already did
> that on meego.gitorious.org".

It would be the other way around, patches against the gitorious tree could fix 
problems already fixed on linuxtv.

> I appreciate your help so far.

You're welcome.

-- 
Regards,

Laurent Pinchart