Re: CEU / Camera Driver Question
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt() option,
I setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function to
do the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width= p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field= p-format.field;
return 0;
}
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the call
is made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Thank you,
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Tuesday, May 04, 2010 1:43 AM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org; Magnus Damm
magnus.d...@gmail.com
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Mon, 3 May 2010, Charles D. Krebs wrote:
Guennadi,
As per your recommendation I reviewed the soc_camera_platform driver,
and
have chosen to implement the new camera by simply modifying it.
Sure enough, I can boot up and properly register a device under
/dev/video0.
The camera provides 8-bit Grayscale data corresponding to pixel format
V4L2_PIX_FMT_GREY. I can't seem to find any example of a device driver
that
uses this format, so I've been taking my best guess as how to setup
soc_camera_platform_info. So far I have:
static struct soc_camera_platform_info mycam_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_YUYV8_2X8_BE,
No, you should be using V4L2_MBUS_FMT_GREY8_1X8 for grey.
.colorspace = V4L2_COLORSPACE_JPEG,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
};
It looks like I'll need to modify soc_camera_platform it in a way to at
least add a fourcc field that can be interpreted by the ceu driver for
the
sh_mobile_ceu_set_bus_param call to setup the hardware correctly.
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
But regardless of how I set this structure up, I don't see any direct
support
Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt() option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code= p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CEU / Camera Driver Question
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Friday, May 14, 2010 3:38 PM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about
fourcc
codes, that belongs to the user side of the pixel format handling API.
The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch
welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt()
option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function
to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
You're right - It's not a whole lot different other than I didn't add the
scaling functions to the sub commands.
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in
its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from
the
information I have received from Renesas, I'm not seeing any reason
why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there
are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image
data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the
call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
I have that structure setup as follows:
static struct soc_camera_platform_info mycamera_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_GREY8_1X8,
.colorspace = V4L2_COLORSPACE_JPEG, //V4L2_COLORSPACE_SMPTE170M,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
.set_capture = mycamera_camera_set_capture,
};
I would have thought that the pixel format information would have filtered
back thorough the stack to the host driver, but...
In sh_mobile_ceu_set_fmt we have:
static int sh_mobile_ceu_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
{
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
struct sh_mobile_ceu_cam *cam = icd-host_priv;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_mbus_framefmt mf;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd-dev.parent;
__u32 pixfmt = pix-pixelformat;
const struct soc_camera_format_xlate *xlate;
struct v4l2_crop cam_crop;
struct v4l2_rect
Re: CEU / Camera Driver Question
Guennadi,
Thank you for making me aware of the patch that Morimoto-San composed.
Implementing the remaining sub commands fixes the issues I was seeing. It's
rather ironic that he was working on that at the same time I was.
I'm now working through a minor userspace application issue and expect to
have the overall demo application working shortly to stream video with this
new camera. Thanks for all of your help and patience.
If I need to make changes to either soc_camera_platform or the ceu driver,
I'll be sure to submit patch proposals to that effect.
Best regards,
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Friday, May 14, 2010 3:38 PM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Fri, 14 May 2010, Charles D. Krebs wrote:
Guennadi,
No, subdevice drivers, using the mediabus API, know nothing about
fourcc
codes, that belongs to the user side of the pixel format handling API.
The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch
welcome.
In trying to figure out how to best patch the lacking .s_mbus_fmt()
option, I
setup:
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.try_mbus_fmt = soc_camera_platform_try_fmt,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
.g_mbus_fmt = soc_camera_platform_try_fmt,
.s_mbus_fmt = soc_camera_platform_try_fmt,
};
Is there any reason I can't reuse a slightly modified try_fmt function
to do
the set?
Here's what I currently have:
static int soc_camera_platform_try_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
mf-width = p-format.width;
mf-height = p-format.height;
mf-code = p-format.code;
mf-colorspace = p-format.colorspace;
mf-field = p-format.field;
return 0;
}
How is this different from this patch from Morimoto-san:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19191
But regardless of how I set this structure up, I don't see any direct
support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in
its
list
of fourcc formats. Yet based on the 7724 hardware manual, and from
the
information I have received from Renesas, I'm not seeing any reason
why
this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
After thoroughly reviewing the register documentation for the CEU, there
are
several changes I'm implementing. This camera doesn't put out any color
sampling, so the registers in the CEU must be configured to use image
data
fetch mode.
Where I'm currently struggling is in sh_mobile_ceu_set_fmt where the
call is
made to soc_camera_xlate_by_fourcc(icd, pixfmt).
I'm still trying to figure out where the data needs to be defined that
eventually becomes pixfmt. Should this be setup as an additional
parameter
from inside soc_camera_platform_try_fmt?
What's the relationship between v4l2_format and v4l2_mbus_framefmt?
Have you set up platform data similar to struct soc_camera_link
camera_link in arch/sh/boards/mach-ap325rxa/setup.c. The
soc_camera_platform.c driver should be getting pixel format information
from the static struct soc_camera_platform_info, doesn't this work for
you?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CEU / Camera Driver Question
Hi Charles
On Mon, 3 May 2010, Charles D. Krebs wrote:
Guennadi,
As per your recommendation I reviewed the soc_camera_platform driver, and
have chosen to implement the new camera by simply modifying it.
Sure enough, I can boot up and properly register a device under /dev/video0.
The camera provides 8-bit Grayscale data corresponding to pixel format
V4L2_PIX_FMT_GREY. I can't seem to find any example of a device driver that
uses this format, so I've been taking my best guess as how to setup
soc_camera_platform_info. So far I have:
static struct soc_camera_platform_info mycam_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_YUYV8_2X8_BE,
No, you should be using V4L2_MBUS_FMT_GREY8_1X8 for grey.
.colorspace = V4L2_COLORSPACE_JPEG,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
};
It looks like I'll need to modify soc_camera_platform it in a way to at
least add a fourcc field that can be interpreted by the ceu driver for the
sh_mobile_ceu_set_bus_param call to setup the hardware correctly.
No, subdevice drivers, using the mediabus API, know nothing about fourcc
codes, that belongs to the user side of the pixel format handling API. The
path, e.g., for the VIDIOC_S_FMT ioctl() is
soc_camera.c::soc_camera_s_fmt_vid_cap(V4L2_PIX_FMT_GREY)
sh_mobile_ceu_camera.c::sh_mobile_ceu_set_fmt(V4L2_PIX_FMT_GREY)
the latter will try to call the .s_mbus_fmt() method from
soc_camera_platform.c and will fail, because that got lost during the
v4l2-subdev conversion, which is a bug and has to be fixed, patch welcome.
But regardless of how I set this structure up, I don't see any direct support
for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Sure, that's what the pass-through mode with a standard soc-mbus format
conversion is for (see soc_mbus_get_fmtdesc()).
Any suggestions on how I might go about implementing support? I'm having
trouble seeing the dataflow through the driver at the moment...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CEU / Camera Driver Question
Guennadi,
As per your recommendation I reviewed the soc_camera_platform driver, and
have chosen to implement the new camera by simply modifying it.
Sure enough, I can boot up and properly register a device under /dev/video0.
The camera provides 8-bit Grayscale data corresponding to pixel format
V4L2_PIX_FMT_GREY. I can't seem to find any example of a device driver that
uses this format, so I've been taking my best guess as how to setup
soc_camera_platform_info. So far I have:
static struct soc_camera_platform_info mycam_camera_info = {
.format_name = GREY,
.format_depth = 8,
.format = {
.code = V4L2_MBUS_FMT_YUYV8_2X8_BE,
.colorspace = V4L2_COLORSPACE_JPEG,
.field = V4L2_FIELD_NONE,
.width = 320,
.height = 240,
},
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
};
It looks like I'll need to modify soc_camera_platform it in a way to at
least add a fourcc field that can be interpreted by the ceu driver for the
sh_mobile_ceu_set_bus_param call to setup the hardware correctly.
But regardless of how I set this structure up, I don't see any direct
support for a Grayscale mode data capture in the ceu driver. For example,
sh_mobile_ceu_set_bus_param does not contain V4L2_PIX_FMT_GREY in its list
of fourcc formats. Yet based on the 7724 hardware manual, and from the
information I have received from Renesas, I'm not seeing any reason why this
format should not be supported.
Is grayscale somehow supported under the current CEU driver?
Any suggestions on how I might go about implementing support? I'm having
trouble seeing the dataflow through the driver at the moment...
Thank you!
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Wednesday, April 14, 2010 1:38 AM
To: Charles D. Krebs ckr...@therealtimegroup.com
Cc: Linux Media Mailing List linux-media@vger.kernel.org
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Tue, 13 Apr 2010, Charles D. Krebs wrote:
Guennadi,
Thank you for the response and explanation. It falls perfectly in line
with
what we had been suspecting on our end.
We ended up basing the driver off mt9t112.c, which is an I2C camera.
The
major issues have been figuring out how to remove the I2C components.
The driver (attached for reference) currently registers a device under
/sys/bus/platform/drivers/testcam. However, udev does not populate a
video0 entry under /dev, so it seems the V4L2 registration wasn't
done
correctly.
All my comments will base on the current kernel, so, if you prefer to stay
with an older one, they will not be (entirely) applicable.
I'm fairly sure the problem falls under testcam_probe or
testcam_module_init.
Since we are not I2C, should we call platform_driver_register from
testcam_module_init?
Do we need to fill out a link structure from the SOC Camera driver
(soc_camera_link)? I noticed that this is used in all the I2C cameras.
As I see, your driver is just a dummy, that only specifies camera's
capabilities. That's also ok, you certainly can make a driver for a
completely fixed-parameter camera, but then a few methods from your driver
should either disappear, or return an unsupported error, or return the
fixed configuration of the sensor (like s_fmt, try_fmt). Please, have a
look at drivers/media/video/soc_camera_platform.c, that's an example of an
soc-camera client driver, not using i2c. I'm not sure if it's working
presently, it's use kind of discouraged, but you can certainly use it as
an example. If you don't plan to mainline your driver, you can even
actually use soc_camera_platform.c, then you'll just need to add some
platform data for it (see arch/sh/boards/mach-ap325rxa/setup.c and struct
soc_camera_link camera_link in it for an example). You might have to fix
that driver slightly, but that shouldn't be too difficult.
Thanks
Guennadi
Unfortunately, I still need to figure out how to best integrate with the
sh_mobile_ceu_camera driver since I am mid migration from 2.6.31-rc7 to
2.6.33. It appears that quite a lot has changed... The Kernel change
has
spawned a plethora of issues, which has unfortunately delayed development
on
this driver until now.
Thanks for your input!
Charles Krebs, Embedded Solutions Developer
The Realtime Group
--
From: Guennadi Liakhovetski g.liakhovet...@gmx.de
Sent: Thursday, April 08, 2010 1:39 AM
To: Magnus Damm magnus.d...@gmail.com
Cc: Charles D. Krebs ckr...@therealtimegroup.com
Subject: Re: CEU / Camera Driver Question
Hi Charles
On Thu, 8 Apr 2010, Magnus Damm wrote:
Hi Charles,
Thanks for your email. I am afraid I know too little about the
current
Re: CEU / Camera Driver Question
Hi Charles On Tue, 13 Apr 2010, Charles D. Krebs wrote: Guennadi, Thank you for the response and explanation. It falls perfectly in line with what we had been suspecting on our end. We ended up basing the driver off mt9t112.c, which is an I2C camera. The major issues have been figuring out how to remove the I2C components. The driver (attached for reference) currently registers a device under /sys/bus/platform/drivers/testcam. However, udev does not populate a video0 entry under /dev, so it seems the V4L2 registration wasn't done correctly. All my comments will base on the current kernel, so, if you prefer to stay with an older one, they will not be (entirely) applicable. I'm fairly sure the problem falls under testcam_probe or testcam_module_init. Since we are not I2C, should we call platform_driver_register from testcam_module_init? Do we need to fill out a link structure from the SOC Camera driver (soc_camera_link)? I noticed that this is used in all the I2C cameras. As I see, your driver is just a dummy, that only specifies camera's capabilities. That's also ok, you certainly can make a driver for a completely fixed-parameter camera, but then a few methods from your driver should either disappear, or return an unsupported error, or return the fixed configuration of the sensor (like s_fmt, try_fmt). Please, have a look at drivers/media/video/soc_camera_platform.c, that's an example of an soc-camera client driver, not using i2c. I'm not sure if it's working presently, it's use kind of discouraged, but you can certainly use it as an example. If you don't plan to mainline your driver, you can even actually use soc_camera_platform.c, then you'll just need to add some platform data for it (see arch/sh/boards/mach-ap325rxa/setup.c and struct soc_camera_link camera_link in it for an example). You might have to fix that driver slightly, but that shouldn't be too difficult. Thanks Guennadi Unfortunately, I still need to figure out how to best integrate with the sh_mobile_ceu_camera driver since I am mid migration from 2.6.31-rc7 to 2.6.33. It appears that quite a lot has changed... The Kernel change has spawned a plethora of issues, which has unfortunately delayed development on this driver until now. Thanks for your input! Charles Krebs, Embedded Solutions Developer The Realtime Group -- From: Guennadi Liakhovetski g.liakhovet...@gmx.de Sent: Thursday, April 08, 2010 1:39 AM To: Magnus Damm magnus.d...@gmail.com Cc: Charles D. Krebs ckr...@therealtimegroup.com Subject: Re: CEU / Camera Driver Question Hi Charles On Thu, 8 Apr 2010, Magnus Damm wrote: Hi Charles, Thanks for your email. I am afraid I know too little about the current status of the CEU driver and camera sensor integration. I do however know one guy that can help you. Guennadi, can you please give us some recommendations? Charles is using 2.6.33 on sh7724, see below. Thanks! / magnus On Apr 6, 2010 10:35 AM, Charles D. Krebs ckr...@therealtimegroup.com wrote: Magnus, We have been working on integrating our camera into the 7724 platform. I think we are pretty close to having the camera up and working at this point, but there are a few outstanding concerns. In the open-source community it is customary to discuss related topics and ask questions on respective mailing lists. So, I'll just give a very brief answer to this your mail, if you get more questions, please CC Linux Media Mailing List linux-media@vger.kernel.org in your naxt mail. The basic objective is to interface a very dumb video camera that connects directly to CEU driver in the SH7724 processor. This camera needs no control interface (the interface is actually RS232, which I plan to drive completely from user space), but has 8 bit parallel video (Grayscale). The camera driver was patterned after the the soc_camera driver, using the platform interface. Our camera driver is mostly dummy code because of the simplicity. The current Linux kernel mainline implementation of the video capture function on several embedded SoCs, including CEU-based SuperH platforms, is a V4L2 driver stack, consisting of 1. a host driver (in this case sh_mobile_ceu_camera.c), using the soc-camera API to integrate itself into the V4L framework 2. the soc-camera core 3. client drivers, using the v4l2-subdev API for most V4L2 communication, the mediabus API for pixel-format negotiation and a couple of soc-camera API extensions. So, all you need is use the existing sh_mobile_ceu_camera.c driver, the soc-camera framework and add a new driver for your camera-sensor, which in your case would be very simple, as you say. Just use any platform, currently in the mainline (e.g., ecovec) as an example for your platform bindings, and any
Re: CEU / Camera Driver Question
Guennadi, Thank you for the response and explanation. It falls perfectly in line with what we had been suspecting on our end. We ended up basing the driver off mt9t112.c, which is an I2C camera. The major issues have been figuring out how to remove the I2C components. The driver (attached for reference) currently registers a device under /sys/bus/platform/drivers/testcam. However, udev does not populate a video0 entry under /dev, so it seems the V4L2 registration wasn't done correctly. I'm fairly sure the problem falls under testcam_probe or testcam_module_init. Since we are not I2C, should we call platform_driver_register from testcam_module_init? Do we need to fill out a link structure from the SOC Camera driver (soc_camera_link)? I noticed that this is used in all the I2C cameras. Unfortunately, I still need to figure out how to best integrate with the sh_mobile_ceu_camera driver since I am mid migration from 2.6.31-rc7 to 2.6.33. It appears that quite a lot has changed... The Kernel change has spawned a plethora of issues, which has unfortunately delayed development on this driver until now. Thanks for your input! Charles Krebs, Embedded Solutions Developer The Realtime Group -- From: Guennadi Liakhovetski g.liakhovet...@gmx.de Sent: Thursday, April 08, 2010 1:39 AM To: Magnus Damm magnus.d...@gmail.com Cc: Charles D. Krebs ckr...@therealtimegroup.com Subject: Re: CEU / Camera Driver Question Hi Charles On Thu, 8 Apr 2010, Magnus Damm wrote: Hi Charles, Thanks for your email. I am afraid I know too little about the current status of the CEU driver and camera sensor integration. I do however know one guy that can help you. Guennadi, can you please give us some recommendations? Charles is using 2.6.33 on sh7724, see below. Thanks! / magnus On Apr 6, 2010 10:35 AM, Charles D. Krebs ckr...@therealtimegroup.com wrote: Magnus, We have been working on integrating our camera into the 7724 platform. I think we are pretty close to having the camera up and working at this point, but there are a few outstanding concerns. In the open-source community it is customary to discuss related topics and ask questions on respective mailing lists. So, I'll just give a very brief answer to this your mail, if you get more questions, please CC Linux Media Mailing List linux-media@vger.kernel.org in your naxt mail. The basic objective is to interface a very dumb video camera that connects directly to CEU driver in the SH7724 processor. This camera needs no control interface (the interface is actually RS232, which I plan to drive completely from user space), but has 8 bit parallel video (Grayscale). The camera driver was patterned after the the soc_camera driver, using the platform interface. Our camera driver is mostly dummy code because of the simplicity. The current Linux kernel mainline implementation of the video capture function on several embedded SoCs, including CEU-based SuperH platforms, is a V4L2 driver stack, consisting of 1. a host driver (in this case sh_mobile_ceu_camera.c), using the soc-camera API to integrate itself into the V4L framework 2. the soc-camera core 3. client drivers, using the v4l2-subdev API for most V4L2 communication, the mediabus API for pixel-format negotiation and a couple of soc-camera API extensions. So, all you need is use the existing sh_mobile_ceu_camera.c driver, the soc-camera framework and add a new driver for your camera-sensor, which in your case would be very simple, as you say. Just use any platform, currently in the mainline (e.g., ecovec) as an example for your platform bindings, and any soc-camera client driver (e.g., mt9m001, or ov772x) as a template for your camera driver. There is one point, where you will have to be careful: your camera is not using I2C. soc-camera should support this too, but it hasn't been tested or used for a while, so, something might have bitrotted there. So, I would suggest - write a driver, test it and post to the mailing list (you can CC me too, if you like). If you have any questions in the meantime - don't hesitate to ask, but please cc the list. Regarding your intension to control the sensor from the user-space, however simple that controlling might be, I would seriously consider writing a line discipline for it, which would allow you then use any standard V4L(2) application with your system. The only addition you would have is a tiny app, that would open the serial port, set the required line discipline for it and keep it open for the whole time your video driver is going to be used. Thanks Guennadi Questions: 1. Is soc_camera a reasonable driver to use as a starting point, or is there a better choice? 2. How is the CEU driver associated with the camera driver? 3. Is there a special bus type ID that needs to be claimed by the camera driver? Standard or custom? 4. In /arch/sh/boards/mach-ecovec24/setup.c - I made
