[PATCH v3] mt9v022: Add support for mt9v024
Driver for mt9v022 camera sensor is fully compatible for mt9v024 camera sensor
with the exception of several registers which have been changed addresses.
mt9v024 also has improved and additional features, but they are currently not
in use.
Signed-off-by: Alex Gershgorin
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 36 +++-
2 files changed, 32 insertions(+), 6 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
Changes for v3:
Added patch descriptions.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate "mt9v022 support"
+ tristate "mt9v022 and mt9v024 support"
depends on SOC_CAMERA && I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..b67ce7f 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
\"monochrome\"");
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
\"monochrome\"");
#define MT9V022_COLUMN_SKIP1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(id) (id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,6 +139,7 @@ struct mt9v022 {
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
+ const struct mt9v02x_register *reg;
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
@@ -185,7 +208,7 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, mt9v022->reg->max_total_shutter_width,
480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,7 +261,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret >= 0) {
if (ret & 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ ret = reg_write(client,
mt9v022->reg->max_total_shutter_width,
rect.height + mt9v022->y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
@@ -573,14 +596,17 @@ static int mt9v022_video_probe(struct i2c_client *client)
/* Read out the chip version register */
data = reg_read(client, MT9V022_CHIP_VERSION);
- /* must be 0x1311 or 0x1313 */
- if (data != 0x1311 && data != 0x1313) {
+ /* must be 0x1311, 0x1313 or 0x1324 */
+ if (data != 0x1311 && data != 0x1313 && data != 0x1324) {
ret = -ENODEV;
dev_info(&client->dev, "No MT9V022 found, ID register 0x%x\n",
data);
goto ei2c;
}
+ mt9
RE: [PATCH v2] mt9v022: Add support for mt9v024
Hi Guennadi,
Thank you for your very detailed comment.
> Hi Alex
> Yes, this looks much better to me now. Still, I'd like to ask you to
> make a couple more changes. First - there are different opinions about how
> really important a patch description is, whether there are at all cases,
> when an empty description is acceptable. I do sometimes myself provide no
> description and accept the same from others, but only in really trivial
> cases, where the single patch subject line perfectly tells it all.
> However, I don't think this is the case here. It would be nice to have a
> couple of words in the patch description, saying, that "mt9v024 is a
> camera sensor, very similar to mt9v022 with just a few differences, namely
> its sensor matrix size is now ... instead of ..., some register locations
> have changed,..."
No problem, I'll add descriptions.
> While at it, please, also change one more thing. Yes, it was my request to
> move chip_id into the private struct, but now with the addition of "struct
> mt9v02x_register" it is not needed anymore. The chip_id is only used in
> the probe function, so, you don't have to save it. Please, if I'm not
> mistaken and I haven't missed some additional uses of chip_id, remove it
> again and just leave the local "data" variable without change.
> Respectively, your is_mt9v024 macro will change to
> #define is_mt9v024(id) (id == 0x1324)
I only have a few doubts about this:
mt9v024 camera sensor has about 20 additional registers that are not supported
in mt9v022 camera sensor.
What should be happened if someone wants to add this registers?
I guess, that in this case we will need to use the chip_id outside of the probe
function.
What do you think?
Regards,
Alex
> Signed-off-by: Alex Gershgorin
> ---
> drivers/media/video/Kconfig |2 +-
> drivers/media/video/mt9v022.c | 45
> 2 files changed, 37 insertions(+), 10 deletions(-)
>
> Changes for v2:
> Fixed comment from Guennadi.
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index c128fac..3ce905c 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
> This driver supports MT9T112 cameras from Aptina.
>
> config SOC_CAMERA_MT9V022
> - tristate "mt9v022 support"
> + tristate "mt9v022 and mt9v024 support"
> depends on SOC_CAMERA && I2C
> select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
> help
> diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
> index 7247924..d46727b 100644
> --- a/drivers/media/video/mt9v022.c
> +++ b/drivers/media/video/mt9v022.c
> @@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
> \"monochrome\"");
> #define MT9V022_AEC_AGC_ENABLE 0xAF
> #define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
>
> +/* mt9v024 partial list register addresses changes with respect to mt9v022 */
> +#define MT9V024_PIXCLK_FV_LV 0x72
> +#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
> +
> /* Progressive scan, master, defaults */
> #define MT9V022_CHIP_CONTROL_DEFAULT 0x188
>
> @@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
> \"monochrome\"");
> #define MT9V022_COLUMN_SKIP 1
> #define MT9V022_ROW_SKIP 4
>
> +#define is_mt9v024(p) (p->chip_id == 0x1324)
> +
> /* MT9V022 has only one fixed colorspace per pixelcode */
> struct mt9v022_datafmt {
> enum v4l2_mbus_pixelcodecode;
> @@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
> mt9v022_monochrome_fmts[] = {
> {V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
> };
>
> +/* only registers with different addresses on different mt9v02x sensors */
> +struct mt9v02x_register {
> + u8 max_total_shutter_width;
> + u8 pixclk_fv_lv;
> +};
> +
> +static const struct mt9v02x_register mt9v022_register = {
> + .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
> + .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
> +};
> +
> +static const struct mt9v02x_register mt9v024_register = {
> + .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
> + .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
> +};
> +
> struct mt9v022 {
> struct v4l2_subdev subdev;
> struct v4l2_ctrl_handler hdl;
> @@ -117,10 +139,12 @@ struct mt9v022 {
> struct v4l2_rect rect; /* Sensor window */
> const struct mt9v022_datafmt *fmt;
&
[PATCH v2] mt9v022: Add support for mt9v024
Signed-off-by: Alex Gershgorin
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 45
2 files changed, 37 insertions(+), 10 deletions(-)
Changes for v2:
Fixed comment from Guennadi.
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..3ce905c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1058,7 +1058,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate "mt9v022 support"
+ tristate "mt9v022 and mt9v024 support"
depends on SOC_CAMERA && I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 7247924..d46727b 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
\"monochrome\"");
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -67,6 +71,8 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
\"monochrome\"");
#define MT9V022_COLUMN_SKIP1
#define MT9V022_ROW_SKIP 4
+#define is_mt9v024(p) (p->chip_id == 0x1324)
+
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
enum v4l2_mbus_pixelcodecode;
@@ -101,6 +107,22 @@ static const struct mt9v022_datafmt
mt9v022_monochrome_fmts[] = {
{V4L2_MBUS_FMT_Y8_1X8, V4L2_COLORSPACE_JPEG},
};
+/* only registers with different addresses on different mt9v02x sensors */
+struct mt9v02x_register {
+ u8 max_total_shutter_width;
+ u8 pixclk_fv_lv;
+};
+
+static const struct mt9v02x_register mt9v022_register = {
+ .max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
+};
+
+static const struct mt9v02x_register mt9v024_register = {
+ .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
+ .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
+};
+
struct mt9v022 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
@@ -117,10 +139,12 @@ struct mt9v022 {
struct v4l2_rect rect; /* Sensor window */
const struct mt9v022_datafmt *fmt;
const struct mt9v022_datafmt *fmts;
+ const struct mt9v02x_register *reg;
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
unsigned short y_skip_top; /* Lines to skip at the top */
+ s32 chip_id;
};
static struct mt9v022 *to_mt9v022(const struct i2c_client *client)
@@ -185,7 +209,7 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, mt9v022->reg->max_total_shutter_width,
480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,7 +262,7 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret >= 0) {
if (ret & 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ ret = reg_write(client,
mt9v022->reg->max_total_shutter_width,
rect.height + mt9v022->y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
@@ -566,21 +590,24 @@ static int mt9v022_video_probe(struct i2c_client *client)
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
- s32 data;
int ret;
unsigned long flags;
/* Read out the chip version register */
- data = reg_read(client, MT9V022_CHIP_VERSION);
+ mt9v022->chip_id = reg_read(client, MT9V022_CHIP_VERSION);
- /* must be 0x1311 or 0x1313 */
- if (data != 0x1311 && data != 0x1313) {
+ /* must be 0x1311, 0x1313 or 0x1324 */
+ if (mt9v022->chip_id != 0x1311 && mt9v022->chip_id != 0x1313 &&
+ mt9v022->chip_id !=
RE: [PATCH v2] media: mx3_camera: buf_init() add buffer state check
From: Alex Gershgorin
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin
[g.liakhovet...@gmx.de: remove mx3_camera_buffer::state completely]
Signed-off-by: Guennadi Liakhovetski
---
> > Hi Alex
> > Thanks for your explanation. Please, check whether this version of your
> > patch also fixes the problem and works in both MMAP and USERPTR modes.
> > Thanks
> > Guennadi
Hi Guennadi,
This is a good upgrade :-)
I tested both modes, it works fine without any problems.
Sincerely,
Alex
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 02d54a0..0af24d0 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -61,15 +61,9 @@
#define MAX_VIDEO_MEM 16
-enum csi_buffer_state {
- CSI_BUF_NEEDS_INIT,
- CSI_BUF_PREPARED,
-};
-
struct mx3_camera_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
- enum csi_buffer_state state;
struct list_headqueue;
/* One descriptot per scatterlist (per frame) */
@@ -285,7 +279,7 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
goto error;
}
- if (buf->state == CSI_BUF_NEEDS_INIT) {
+ if (!buf->txd) {
sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
@@ -298,7 +292,6 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
txd->callback_param = txd;
txd->callback = mx3_cam_dma_done;
- buf->state = CSI_BUF_PREPARED;
buf->txd= txd;
} else {
txd = buf->txd;
@@ -385,7 +378,6 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
/* Doesn't hurt also if the list is empty */
list_del_init(&buf->queue);
- buf->state = CSI_BUF_NEEDS_INIT;
if (txd) {
buf->txd = NULL;
@@ -405,13 +397,13 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
struct mx3_camera_dev *mx3_cam = ici->priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(&buf->queue);
- sg_init_table(&buf->sg, 1);
+ if (!buf->txd) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(&buf->queue);
+ sg_init_table(&buf->sg, 1);
- buf->state = CSI_BUF_NEEDS_INIT;
-
- mx3_cam->buf_total += vb2_plane_size(vb, 0);
+ mx3_cam->buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}--
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: [PATCH] media: mx3_camera: buf_init() add buffer state check
> Hi Guennadi,
>
> > On Mon, 30 Jul 2012, Alex Gershgorin wrote:
>
> > This patch check the state of the buffer when calling buf_init() method.
> > The thread
> > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
> > also includes report witch can show the problem. This patch solved the
> > problem.
> > Both MMAP and USERPTR methods was successfully tested.
> >
> > Signed-off-by: Alex Gershgorin
> > ---
> > drivers/media/video/mx3_camera.c | 12 +++-
> > 1 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/media/video/mx3_camera.c
> > b/drivers/media/video/mx3_camera.c
> > index f13643d..950a8fe 100644
> > --- a/drivers/media/video/mx3_camera.c
> > +++ b/drivers/media/video/mx3_camera.c
> > @@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
>
> >> Sorry, don't understand. As we see in the thread, mentioned above, the
> >> Oops happened in mx3_videobuf_release(). If my analysis was correct in
> >> that thread, that Oops happened, when .buf_cleanup() was called without
> >> .buf_init() being called. This your patch modifies mx3_videobuf_init().
> >> which isn't even called in the problem case. How does this help?
>
> Sorry for not quite a clear explanation, I will explain in more details.
> if you divide the report into two parts:
> 1) USERPTR method Oops happened as a result discontiguous memory allocation
> 2) USERPTR method use framebuffer memory allocation video starting, but after
> a few seconds the video freezes.
> if we consider the first part of the report, your analysis is absolutely
>correct and unfortunately this patch does not solve the problems mentioned
> in the thread.
>This patch solves a problem that is described in the second part of the
> report.
> > Ok, I understand now what this patch fixes, but I still don't understand
> > what the problem is and how this patch fixes it. AFAICS, there should be
> > nothing wrong with calling mx3_videobuf_init() each time a buffer gets
> > queued.
I only see the problem when the user implements USERPTR method :-)
> > I suspect, it's just one of those 4 lines of code, that you put
> > under "if (buf->state != CSI_BUF_PREPARED)", that breaks it. Could you
I think the best way to make sure this solves the problem is to test it, and
that is what I did :-)
> > please try to find out which exactly line it is? Just try to use your "if
> > (...)" with each of them separately. My guess goes for
> > buf->state = CSI_BUF_NEEDS_INIT;
> > but it would help if you could verify it.
mx3_camera uses slave dma API of the dmaengine.
In MMAP and USERPTR methods, the buffer which had been prepared already
have a descriptor for transaction and does not need additional descriptor.
If user implement MMAP method, there is no problem because
mx3_videobuf_init() happens at REQBUFS time
and we have only one descriptor for transaction per video buffer.
As you mentioned, In case of USERPTR method mx3_videobuf_init() happens at QBUF
time.
In my opinion there are two problems:
1) During QBUF there is no need to get a new descriptor for the transaction if
it has been already obtained.
2) The second problem derives from the first as the number of descriptors for
each channel is limited and very quickly
we reach the maximum permitted number of descriptors. As a results of that,
the video freezes.
This patch solves the two problems.
Regards,
Alex
> > struct mx3_camera_dev *mx3_cam = ici->priv;
> > struct mx3_camera_buffer *buf = to_mx3_vb(vb);
> >
> > - /* This is for locking debugging only */
> > - INIT_LIST_HEAD(&buf->queue);
> > - sg_init_table(&buf->sg, 1);
> > + if (buf->state != CSI_BUF_PREPARED) {
> > + /* This is for locking debugging only */
> > + INIT_LIST_HEAD(&buf->queue);
> > + sg_init_table(&buf->sg, 1);
> >
> > - buf->state = CSI_BUF_NEEDS_INIT;
> > + buf->state = CSI_BUF_NEEDS_INIT;
> >
> > - mx3_cam->buf_total += vb2_plane_size(vb, 0);
> > + mx3_cam->buf_total += vb2_plane_size(vb, 0);
> > + }
> >
> > return 0;
> > }
> > --
> > 1.7.0.4
> >
>
> Regards,
> Alex
>
---
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: [PATCH] mt9v022: Add support for mt9v024
Hi Guennadi,
>> Thanks for the patch, comments below.
Thanks for you comments.
>> On Mon, 30 Jul 2012, Alex Gershgorin wrote:
> This patch has been successfully tested
>
> Signed-off-by: Alex Gershgorin
> ---
> drivers/media/video/Kconfig |2 +-
> drivers/media/video/mt9v022.c | 28 ++--
> 2 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 99937c9..38d6944 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112
> This driver supports MT9T112 cameras from Aptina.
>
> config SOC_CAMERA_MT9V022
> - tristate "mt9v022 support"
> + tristate "mt9v022 and mt9v024 support"
> depends on SOC_CAMERA && I2C
> select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
> help
> diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
> index bf63417..d2c1ab1 100644
> --- a/drivers/media/video/mt9v022.c
> +++ b/drivers/media/video/mt9v022.c
> @@ -26,7 +26,7 @@
> * The platform has to define ctruct i2c_board_info objects and link to them
> * from struct soc_camera_link
> */
> -
> +static s32 chip_id;
>> No, this should be per instance. Please, add it to struct mt9v022.
> static char *sensor_type;
> module_param(sensor_type, charp, S_IRUGO);
> MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or \"monochrome\"");
> @@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
> \"monochrome\"");
> #define MT9V022_AEC_AGC_ENABLE 0xAF
> #define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
>
> +/* mt9v024 partial list register addresses changes with respect to mt9v022 */
> +#define MT9V024_PIXCLK_FV_LV 0x72
> +#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
> +
> /* Progressive scan, master, defaults */
> #define MT9V022_CHIP_CONTROL_DEFAULT 0x188
>
> @@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client)
> if (!ret)
> ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
> if (!ret)
> - ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
> + ret = reg_write(client, (chip_id == 0x1324) ?
>> I would use a macro something like
>> #define is_mt9v024(p) (p->chip_id == 0x1324)
>> same everywhere below
> + MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
> + MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
>> Hm, with just 2 registers different it almost isn't worth it, but still...
There is little more than two registers and also added new registers
if you're interested I can send you the document.
>> (1) if someone uses this driver as a template, or (2) if we add more
>> sensors or more registers, whose addresses also are different, I think, we
>> better do it properly. How about
/* only registers with different addresses on different mt9v02x sensors */
>> struct mt9v02x_register {
>> u8 max_total_shutter_width;
>> u8 pixclk_fv_lv;
>>};
>> static const struct mt9v02x_register mt9v022_register = {
>>.max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
>>.pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
>>};
>> static const struct mt9v02x_register mt9v024_register = {
>> .max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
>> .pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
>>};
>> struct mt9v022 {
>>...
>>const struct mt9v02x_register *reg;
>>...
>>};
>> and then in this case just do
>> + ret = reg_write(client,
>> mt9v022->reg->max_total_shutter_width, 480);
>> etc.?
I accept your corrections and suggestions in the near future
I will send an updated version of this patch.
Regards,
Alex
> if (!ret)
> /* default - auto */
> ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
> @@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
> v4l2_crop *a)
> ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
> if (ret >= 0) {
> if (ret & 1) /* Autoexposure */
> - ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
> - rect.height + mt9v022->y_skip_top + 43);
> + ret = reg_write(client, (chip_id == 0x1324) ?
> + MT9V024_MAX_TOTAL_SHUTTER_WID
RE: [PATCH] media: mx3_camera: buf_init() add buffer state check
Hi Guennadi,
> On Mon, 30 Jul 2012, Alex Gershgorin wrote:
> This patch check the state of the buffer when calling buf_init() method.
> The thread
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
> also includes report witch can show the problem. This patch solved the
> problem.
> Both MMAP and USERPTR methods was successfully tested.
>
> Signed-off-by: Alex Gershgorin
> ---
> drivers/media/video/mx3_camera.c | 12 +++-
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/mx3_camera.c
> b/drivers/media/video/mx3_camera.c
> index f13643d..950a8fe 100644
> --- a/drivers/media/video/mx3_camera.c
> +++ b/drivers/media/video/mx3_camera.c
> @@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
>> Sorry, don't understand. As we see in the thread, mentioned above, the
>> Oops happened in mx3_videobuf_release(). If my analysis was correct in
>> that thread, that Oops happened, when .buf_cleanup() was called without
>> .buf_init() being called. This your patch modifies mx3_videobuf_init().
>> which isn't even called in the problem case. How does this help?
Sorry for not quite a clear explanation, I will explain in more details.
if you divide the report into two parts:
1) USERPTR method Oops happened as a result discontiguous memory allocation
2) USERPTR method use framebuffer memory allocation video starting, but after a
few seconds the video freezes.
if we consider the first part of the report, your analysis is absolutely
correct and unfortunately this patch does not solve the problems mentioned
in the thread.
This patch solves a problem that is described in the second part of the
report.
> struct mx3_camera_dev *mx3_cam = ici->priv;
> struct mx3_camera_buffer *buf = to_mx3_vb(vb);
>
> - /* This is for locking debugging only */
> - INIT_LIST_HEAD(&buf->queue);
> - sg_init_table(&buf->sg, 1);
> + if (buf->state != CSI_BUF_PREPARED) {
> + /* This is for locking debugging only */
> + INIT_LIST_HEAD(&buf->queue);
> + sg_init_table(&buf->sg, 1);
>
> - buf->state = CSI_BUF_NEEDS_INIT;
> + buf->state = CSI_BUF_NEEDS_INIT;
>
> - mx3_cam->buf_total += vb2_plane_size(vb, 0);
> + mx3_cam->buf_total += vb2_plane_size(vb, 0);
> + }
>
> return 0;
> }
> --
> 1.7.0.4
>
Regards,
Alex
--
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
[PATCH] media: mx3_camera: buf_init() add buffer state check
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin
---
drivers/media/video/mx3_camera.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
struct mx3_camera_dev *mx3_cam = ici->priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(&buf->queue);
- sg_init_table(&buf->sg, 1);
+ if (buf->state != CSI_BUF_PREPARED) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(&buf->queue);
+ sg_init_table(&buf->sg, 1);
- buf->state = CSI_BUF_NEEDS_INIT;
+ buf->state = CSI_BUF_NEEDS_INIT;
- mx3_cam->buf_total += vb2_plane_size(vb, 0);
+ mx3_cam->buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
1.7.0.4
--
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
[PATCH] mt9v022: Add support for mt9v024
This patch has been successfully tested
Signed-off-by: Alex Gershgorin
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 28 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..38d6944 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate "mt9v022 support"
+ tristate "mt9v022 and mt9v024 support"
depends on SOC_CAMERA && I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index bf63417..d2c1ab1 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -26,7 +26,7 @@
* The platform has to define ctruct i2c_board_info objects and link to them
* from struct soc_camera_link
*/
-
+static s32 chip_id;
static char *sensor_type;
module_param(sensor_type, charp, S_IRUGO);
MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or \"monochrome\"");
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, "Sensor type: \"colour\" or
\"monochrome\"");
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, (chip_id == 0x1324) ?
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret >= 0) {
if (ret & 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
- rect.height + mt9v022->y_skip_top + 43);
+ ret = reg_write(client, (chip_id == 0x1324) ?
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ rect.height + mt9v022->y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
rect.height + mt9v022->y_skip_top + 43);
@@ -566,18 +574,17 @@ static int mt9v022_video_probe(struct i2c_client *client)
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
- s32 data;
int ret;
unsigned long flags;
/* Read out the chip version register */
- data = reg_read(client, MT9V022_CHIP_VERSION);
+ chip_id = reg_read(client, MT9V022_CHIP_VERSION);
/* must be 0x1311 or 0x1313 */
- if (data != 0x1311 && data != 0x1313) {
+ if (chip_id != 0x1311 && chip_id != 0x1313 && chip_id != 0x1324) {
ret = -ENODEV;
dev_info(&client->dev, "No MT9V022 found, ID register 0x%x\n",
-data);
+chip_id);
goto ei2c;
}
@@ -632,7 +639,7 @@ static int mt9v022_video_probe(struct i2c_client *client)
mt9v022->fmt = &mt9v022->fmts[0];
dev_info(&client->dev, "Detected a MT9V022 chip ID %x, %s sensor\n",
-data, mt9v022->model == V4L2_IDENT_MT9V022IX7ATM ?
+chip_id, mt9v022->model == V4L2_IDENT_MT9V022IX7ATM ?
"monochrome" : "colour");
ret = mt9v022_init(client);
@@ -728,7 +735,8 @@ static int mt9v022_s_mbus_config(struct v4l2_subdev *sd,
if (!(flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH))
pixclk |= 0x2;
- ret = reg_write(client, MT9V022_PIXCLK_FV_LV, pixclk);
+ ret = reg_write(client, (chip_id == 0x1324) ? MT9V024_PIXCLK_FV_LV :
+ MT9V022_PIXCLK_FV_LV, pixclk);
if (ret < 0)
return ret;
--
1.7.0.4
--
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: FW: OMAP 3 ISP
Hi Ritesh, Please send in the future CC to laurent.pinch...@ideasonboard.com and linux-media@vger.kernel.org > Hi Alex, > I also started working with OMAP35x torpedo kit, I successful compile Linux > 3.0 and ported on the board. > Device is booting correctly but probe function in omap3isp module not getting > called. > Please help me You have relevant Kernel boot messages? You can also find information in media archives OMAP 3 ISP thread. Regards, Alex -- 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: SoC i.mx35 userptr method failure while running capture-example utility
Hi Guennadi,
Thanks for your quick response.
> ./capture-example -u -f -d /dev/video0
> mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0
> Failed acquiring VMA for vaddr 0x76cd9008
> VIDIOC_QBUF error 22, Invalid arg
>> It doesn't surprise me, that this doesn't work. capture-example allocates
>> absolutely normal user-space buffers, when called with USERPTR, and those
>> buffers are very likely discontiguous. Whereas mx3-camera needs physically
>> contiguous buffers, so, this can only fail. This means, you either have to
>> use MMAP or you need to allocate USERPTR buffers in a special way to
>> guarantee their contiguity.
I have a little progress:-)
In thread "i.mx35 live video" you and Sylvester gave me advice on how to get
the live video
with using the display panning method ... thanks for this invaluable support :-)
I took note of this and I'm currently trying to implement this.
Instead of discontiguous memory allocation I use framebuffer memory allocation
to userspace and this solves the problem.
Now I'm starting to see a live video for 3 seconds, after this video freezes
(it looks like a flickering pause), but the application continues to run
without errors.
can see bellow my strace diagnostic:
ioctl(3, VIDIOC_STREAMON, 0x7ece99f0) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 884508})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 919066})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 918928})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
[snip]
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 87})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {1, 88})
ioctl(3, VIDIOC_DQBUF, 0x7ece990c) = 0
ioctl(4, FBIOPAN_DISPLAY, 0x7ece9854) = 0
ioctl(3, VIDIOC_QBUF or VT_SETACTIVATE, 0x7ece990c) = 0
I do not understand what's the problem, maybe need to implement
FBIO_WAITFORVSYNC ioctl for mx3fb ?
Thanks,
Alex
--
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
SoC i.mx35 userptr method failure while running capture-example utility
Hi everyone, I use user-space utility from http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/contrib/test/capture-example.c I made two small changes in this application and this is running on i.MX35 SoC fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565; fmt.fmt.pix.field = V4L2_FIELD_ANY; When MMAP method is used everything works fine, problem occurs when using USERPTR method this can see bellow : ./capture-example -u -f -d /dev/video0 mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0 Failed acquiring VMA for vaddr 0x76cd9008 VIDIOC_QBUF error 22, Invalid arg Unable to handle kernel NULL pointer dereference at virtual address pgd = 80004000 [] *pgd= Internal error: Oops: 817 [#1] ARM CPU: 0Not tainted (3.4.0-rc5+ #2283 PC is at mx3_videobuf_release+0x9c/0x10c LR is at mx3_videobuf_release+0x20/0x10c pc : [<802cd92c>]lr : [<802cd8b0>]psr: 0093 sp : 86db3e00 ip : 86db3e00 fp : 86db3e2c r10: 86ff6b20 r9 : 86817200 r8 : r7 : 86ff568c r6 : r5 : 8801a000 r4 : 86da3000 r3 : 6013 r2 : 86da3264 r1 : r0 : Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 00c5387d Table: 86dcc008 DAC: 0015 Process capture-example (pid: 52, stack limit = 0x86db2268) Stack: (0x86db3e00 to 0x86db4000) 3e00: 6013 86ff568c 0002 86ff56ac 3e20: 86db3e64 86db3e30 802c8978 802cd89c 80099414 86db3e84 86ff568c 3e40: 86dc9a80 8801a03c 80491828 86817200 86ff6b20 86db3e7c 86db3e68 3e60: 802c9a1c 802c8930 802ce048 86ff5600 86db3e9c 86db3e80 802cca14 802c9a00 3e80: 86ff5800 86dc9a80 0008 86dc9a88 86db3eb4 86db3ea0 802b936c 802cc9d0 3ea0: 86dc9a80 86ff6b20 86db3ef4 86db3eb8 80082f00 802b932c 3ec0: 86d35010 86d7f000 86dc9a80 86d59000 86d90120 000c 3ee0: 86db2000 86db3f14 86db3ef8 8007ff58 80082df0 86d59000 3f00: 0001 86db3f3c 86db3f18 8001c72c 8007fee4 86d59000 86d82000 3f20: 0100 76ef1770 00f8 8000e564 86db3f4c 86db3f40 8001c7a8 8001c6b4 3f40: 86db3f7c 86db3f50 8001dab4 8001c78c 7eb002b8 0001 0004 3f60: 86db3fa4 86db3f70 800824fc 00f8 86db3f94 86db3f80 8001dfc0 8001d8c4 3f80: 000a3d78 86db3fa4 86db3f98 8001e004 8001df4c 86db3fa8 3fa0: 8000e3e0 8001dff8 000a3d78 76ef1770 0001 000a3d64 0008 0001 3fc0: 000a3d78 76ef1770 76ef1770 00f8 76e1d248 9ecc 7eb02954 3fe0: 76f2e000 7eb02908 76de14dc 76e4f3d4 6010 0001 Backtrace: [<802cd890>] (mx3_videobuf_release+0x0/0x10c) from [<802c8978>] (__vb2_queue_free+0x54/0x15c) r8: r7:86ff56ac r6:0002 r5: r4:86ff568c [<802c8924>] (__vb2_queue_free+0x0/0x15c) from [<802c9a1c>] (vb2_queue_release+0x28/0x2c) [<802c99f4>] (vb2_queue_release+0x0/0x2c) from [<802cca14>] (soc_camera_close+0x50/0xac) r4:86ff5600 r3:802ce048 [<802cc9c4>] (soc_camera_close+0x0/0xac) from [<802b936c>] (v4l2_release+0x4c/0x6c) r7:86dc9a88 r6:0008 r5:86dc9a80 r4:86ff5800 [<802b9320>] (v4l2_release+0x0/0x6c) from [<80082f00>] (fput+0x11c/0x204) r5:86ff6b20 r4:86dc9a80 [<80082de4>] (fput+0x0/0x204) from [<8007ff58>] (filp_close+0x80/0x8c) [<8007fed8>] (filp_close+0x0/0x8c) from [<8001c72c>] (put_files_struct+0x84/0xd8) r6:0001 r5: r4:86d59000 r3: [<8001c6a8>] (put_files_struct+0x0/0xd8) from [<8001c7a8>] (exit_files+0x28/0x2c) r8:8000e564 r7:00f8 r6:76ef1770 r5:0100 r4:86d82000 r3:86d59000 [<8001c780>] (exit_files+0x0/0x2c) from [<8001dab4>] (do_exit+0x1fc/0x688) [<8001d8b8>] (do_exit+0x0/0x688) from [<8001dfc0>] (do_group_exit+0x80/0xac) r7:00f8 [<8001df40>] (do_group_exit+0x0/0xac) from [<8001e004>] (sys_exit_group+0x18/0x24) r4:000a3d78 r3: [<8001dfec>] (sys_exit_group+0x0/0x24) from [<8000e3e0>] (ret_fast_syscall+0x0/0x30) Code: 05852024 e5941268 e5940264 e2842f99 (e581) ument ---[ end trace 23ac1073b67b7fc0 ]--- Fixing recursive fault but reboot is needed! Unfortunately I do not have enough knowledge in this kind of problems, any help will be welcomed. Regards, Alex -- 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
[PATCH v2] ARM: i.mx: mx3fb: add overlay support
This work is based on some earlier patch series
"i.MX31: dmaengine and framebuffer drivers" from 2008
by Guennadi Liakhovetski, the patch initializes overlay channel,
adds ioctl for configuring transparency of the overlay and graphics
planes, CONFIG_FB_MX3_OVERLAY is also supported.
In case that CONFIG_FB_MX3_OVERLAY is not defined, mx3fb is completely
backward compatible.
Blend mode, only global alpha blending has been tested.
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Alex Gershgorin
---
Applies to v3.4-rc4
Changes since v1:
*Some fixes after review
*Added ioctl for setting overlay windows position
---
drivers/video/Kconfig |7 +
drivers/video/mx3fb.c | 346
include/linux/mxcfb.h | 40 ++
3 files changed, 364 insertions(+), 29 deletions(-)
create mode 100644 include/linux/mxcfb.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a290be5..acbfccc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2368,6 +2368,13 @@ config FB_MX3
far only synchronous displays are supported. If you plan to use
an LCD display with your i.MX31 system, say Y here.
+config FB_MX3_OVERLAY
+ bool "MX3 Overlay support"
+ default n
+ depends on FB_MX3
+ ---help---
+ Say Y here to enable overlay support
+
config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
depends on FB
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index eec0d7b..09d7885 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -238,6 +239,7 @@ static const struct fb_videomode mx3fb_modedb[] = {
struct mx3fb_data {
struct fb_info *fbi;
+ struct fb_info *fbi_ovl;
int backlight_level;
void __iomem*reg_base;
spinlock_t lock;
@@ -246,6 +248,9 @@ struct mx3fb_data {
uint32_th_start_width;
uint32_tv_start_width;
enum disp_data_mapping disp_data_fmt;
+
+ /* IDMAC / dmaengine interface */
+ struct idmac_channel*idmac_channel[2]; /* We need 2 channels */
};
struct dma_chan_request {
@@ -268,10 +273,19 @@ struct mx3fb_info {
struct dma_async_tx_descriptor *txd;
dma_cookie_tcookie;
struct scatterlist sg[2];
+ struct list_headovl_list; /* overlay buffer list */
u32 sync; /* preserve var->sync flags */
};
+/* Allocated overlay buffer */
+struct mx3fb_alloc_list {
+ struct list_headlist;
+ dma_addr_t phy_addr;
+ void*cpu_addr;
+ size_t size;
+};
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore
file-static. */
@@ -303,7 +317,13 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
struct mx3fb_data *mx3fb = fbi->mx3fb;
uint32_t reg;
- reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
+ reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF) & ~SDC_COM_GWSEL;
+
+ /* Also enable foreground for overlay graphic window is foreground */
+ if (mx3fb->fbi_ovl && fbi == mx3fb->fbi_ovl->par) {
+ reg |= SDC_COM_FG_EN | SDC_COM_GWSEL;
+ INIT_LIST_HEAD(&fbi->ovl_list);
+ }
mx3fb_write_reg(mx3fb, reg | SDC_COM_BG_EN, SDC_COM_CONF);
}
@@ -312,13 +332,24 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
static uint32_t sdc_fb_uninit(struct mx3fb_info *fbi)
{
struct mx3fb_data *mx3fb = fbi->mx3fb;
- uint32_t reg;
+ uint32_t reg, chan_mask;
reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
- mx3fb_write_reg(mx3fb, reg & ~SDC_COM_BG_EN, SDC_COM_CONF);
+ /*
+* Don't we have to automatically disable overlay when disabling
+* background? Attention: cannot test mx3fb->fbi_ovl->par, must
+* test mx3fb->fbi->par, because at the time this function is
+* called for the first time fbi_ovl is not assigned yet.
+*/
+ if (fbi == mx3fb->fbi->par)
+ chan_mask = SDC_COM_BG_EN;
+ else
+ chan_mask = SDC_COM_FG_EN | SDC_COM_GWSEL;
+
+ mx3fb_write_reg(mx3fb, reg & ~chan_mask, SDC_COM_CONF);
- return reg & SDC_COM_BG_EN;
+ return reg & chan_mask;
}
static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
@@ -412,13 +443,33 @@ static void sdc_disable_channel(struct mx3fb_info
*mx3_fbi)
static int sdc_set_window_pos(struct mx3fb_data *mx3fb, enum ipu_channel
channel,
int16_t x_pos, int16_t y_pos)
{
- if (chan
RE: [PATCH v1] ARM: i.mx: mx3fb: add overlay support
Hi Guennadi,
Thanks for your review.
> > Thanks for reviving, fixing and submitting this code!
I think that this code is beneficial :-)
> > On Wed, 18 Apr 2012, Alex Gershgorin wrote:
> This patch is based on the original version submitted by Guennadi
> Liakhovetski,
> the patch initializes overlay channel, adds ioctl for configuring
> transparency of the overlay and graphics planes, CONFIG_FB_MX3_OVERLAY
> is also supported.
>
> In case that CONFIG_FB_MX3_OVERLAY is not defined, mx3fb is completely
> backward compatible.
>
> Blend mode, only global alpha blending has been tested.
>
> Signed-off-by: Alex Gershgorin
> Signed-off-by: Guennadi Liakhovetski
> > Thanks for the credit (;-)), but no, putting my Sob after yours means,
> > that I took your patch and forwarded it on to the next maintainer, which
> > is clearly not the case here:-) The original i.MX31 framebuffer overlay
> > code from my old patches also clearly wasn't written by me, since I didn't
> > have a chance to test it. So, if you like, you can try to trace back
> > original authors of that code and ask them, how they want to be credited
> > here,
I would like to thank all the authors of original code.
unfortunately I can't thank for each one of you separately by name, i hope
that you understand and accept it.
>> otherwise just mentioning, that this work is based on some earlier
> > patch series "i.MX31: dmaengine and framebuffer drivers" from 2008 by ...
> > should be enough.
This option is more suitable, I just correct the description of the patch,
and leave your signature (if you have any objections?) since 2008 patch version.
> > I don't think I can review this patch in sufficient depth, just a couple
> > of minor comments below
> ---
>
> Applies to v3.4-rc3
> ---
> drivers/video/Kconfig |7 +
> drivers/video/mx3fb.c | 318
> -
> include/linux/mxcfb.h | 93 ++
> 3 files changed, 388 insertions(+), 30 deletions(-)
> create mode 100644 include/linux/mxcfb.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index a290be5..acbfccc 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2368,6 +2368,13 @@ config FB_MX3
> far only synchronous displays are supported. If you plan to use
> an LCD display with your i.MX31 system, say Y here.
>
> +config FB_MX3_OVERLAY
> + bool "MX3 Overlay support"
> + default n
> + depends on FB_MX3
> + ---help---
> + Say Y here to enable overlay support
> +
> config FB_BROADSHEET
> tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
> depends on FB
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index eec0d7b..0fb8a72 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -238,6 +239,7 @@ static const struct fb_videomode mx3fb_modedb[] = {
>
> struct mx3fb_data {
> struct fb_info *fbi;
> + struct fb_info *fbi_ovl;
> int backlight_level;
> void __iomem*reg_base;
> spinlock_t lock;
> @@ -246,6 +248,9 @@ struct mx3fb_data {
> uint32_th_start_width;
> uint32_tv_start_width;
> enum disp_data_mapping disp_data_fmt;
> +
> + /* IDMAC / dmaengine interface */
> + struct idmac_channel*idmac_channel[2]; /* We need 2 channels */
> };
>
> struct dma_chan_request {
> @@ -272,6 +277,17 @@ struct mx3fb_info {
> u32 sync; /* preserve var->sync flags */
> };
>
> +/* Allocated overlay buffer */
> +struct mx3fb_alloc_list {
> + struct list_headlist;
> + dma_addr_t phy_addr;
> + void*cpu_addr;
> + size_t size;
> +};
> +
> +/* A list of overlay buffers */
> +static LIST_HEAD(fb_alloc_list);
> > Static variables are evil:-) Which you prove below by protecting this
> > global list-head by a per-device mutex. No, I have no idea whether anyone
> > ever comes up with an SoC with multiple instances of this device, but at
> > least this seems inconsistent to me.
This is descibed bellow... it can will move into struct mx3fb_info ...
> +
> static void mx3fb_dma_done(void *);
>
> /* Used fb-mode and bpp. Can be set on kernel command line, therefore
> file-static. */
> @@ -303,7 +319,11 @@ static void sdc_fb_init(struct mx3fb_info *fbi
[PATCH v1] ARM: i.mx: mx3fb: add overlay support
This patch is based on the original version submitted by Guennadi Liakhovetski,
the patch initializes overlay channel, adds ioctl for configuring
transparency of the overlay and graphics planes, CONFIG_FB_MX3_OVERLAY
is also supported.
In case that CONFIG_FB_MX3_OVERLAY is not defined, mx3fb is completely
backward compatible.
Blend mode, only global alpha blending has been tested.
Signed-off-by: Alex Gershgorin
Signed-off-by: Guennadi Liakhovetski
---
Applies to v3.4-rc3
---
drivers/video/Kconfig |7 +
drivers/video/mx3fb.c | 318 -
include/linux/mxcfb.h | 93 ++
3 files changed, 388 insertions(+), 30 deletions(-)
create mode 100644 include/linux/mxcfb.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index a290be5..acbfccc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2368,6 +2368,13 @@ config FB_MX3
far only synchronous displays are supported. If you plan to use
an LCD display with your i.MX31 system, say Y here.
+config FB_MX3_OVERLAY
+ bool "MX3 Overlay support"
+ default n
+ depends on FB_MX3
+ ---help---
+ Say Y here to enable overlay support
+
config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
depends on FB
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index eec0d7b..0fb8a72 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -238,6 +239,7 @@ static const struct fb_videomode mx3fb_modedb[] = {
struct mx3fb_data {
struct fb_info *fbi;
+ struct fb_info *fbi_ovl;
int backlight_level;
void __iomem*reg_base;
spinlock_t lock;
@@ -246,6 +248,9 @@ struct mx3fb_data {
uint32_th_start_width;
uint32_tv_start_width;
enum disp_data_mapping disp_data_fmt;
+
+ /* IDMAC / dmaengine interface */
+ struct idmac_channel*idmac_channel[2]; /* We need 2 channels */
};
struct dma_chan_request {
@@ -272,6 +277,17 @@ struct mx3fb_info {
u32 sync; /* preserve var->sync flags */
};
+/* Allocated overlay buffer */
+struct mx3fb_alloc_list {
+ struct list_headlist;
+ dma_addr_t phy_addr;
+ void*cpu_addr;
+ size_t size;
+};
+
+/* A list of overlay buffers */
+static LIST_HEAD(fb_alloc_list);
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore
file-static. */
@@ -303,7 +319,11 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
struct mx3fb_data *mx3fb = fbi->mx3fb;
uint32_t reg;
- reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
+ reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF) & ~SDC_COM_GWSEL;
+
+ /* Also enable foreground for overlay graphic window is foreground */
+ if (mx3fb->fbi_ovl && fbi == mx3fb->fbi_ovl->par)
+ reg |= (SDC_COM_FG_EN | SDC_COM_GWSEL);
mx3fb_write_reg(mx3fb, reg | SDC_COM_BG_EN, SDC_COM_CONF);
}
@@ -312,13 +332,24 @@ static void sdc_fb_init(struct mx3fb_info *fbi)
static uint32_t sdc_fb_uninit(struct mx3fb_info *fbi)
{
struct mx3fb_data *mx3fb = fbi->mx3fb;
- uint32_t reg;
+ uint32_t reg, chan_mask;
reg = mx3fb_read_reg(mx3fb, SDC_COM_CONF);
- mx3fb_write_reg(mx3fb, reg & ~SDC_COM_BG_EN, SDC_COM_CONF);
+ /*
+* Don't we have to automatically disable overlay when disabling
+* background? Attention: cannot test mx3fb->fbi_ovl->par, must
+* test mx3fb->fbi->par, because at the time this function is
+* called for the first time fbi_ovl is not assigned yet.
+*/
+ if (fbi == mx3fb->fbi->par)
+ chan_mask = SDC_COM_BG_EN;
+ else
+ chan_mask = SDC_COM_FG_EN | SDC_COM_GWSEL;
+
+ mx3fb_write_reg(mx3fb, reg & ~chan_mask, SDC_COM_CONF);
- return reg & SDC_COM_BG_EN;
+ return reg & chan_mask;
}
static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
@@ -412,13 +443,20 @@ static void sdc_disable_channel(struct mx3fb_info
*mx3_fbi)
static int sdc_set_window_pos(struct mx3fb_data *mx3fb, enum ipu_channel
channel,
int16_t x_pos, int16_t y_pos)
{
- if (channel != IDMAC_SDC_0)
- return -EINVAL;
-
x_pos += mx3fb->h_start_width;
y_pos += mx3fb->v_start_width;
- mx3fb_write_reg(mx3fb, (x_pos << 16) | y_pos, SDC_BG_POS);
+ switch (channel) {
+ case IDMAC_SDC_0:
+ mx3fb_write_reg(mx3fb, (x_pos << 16) | y_pos, SDC_BG_POS);
+
Re: [PATCH v1] i.MX35-PDK: Add Camera support
Hi Fabio, > Good news... > After several number of changes, yesterday the camera started to work :-) > I will prepare some patches and send them. > >Ok, great! Besides your mx35 clock patches: any other patch is > >required to getting the camera to work? Yes, yesterday I sended to Sascha and ARM mailing list another patch i.MX35-PDK-Add-regulator-support, this also will need be used. > > Are you getting the camera image with the correct colors? Now the camera works fine without any problems, except those, who have already eliminated :-) Regards, Alex Gershgorin -- 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: [PATCH] ARM: i.MX35: Add set_rate and round_rate calls to csi_clk
Hi Sascha,
Thanks for you comments.
On Tue, Mar 20, 2012 at 12:29:52PM +0200, Alex Gershgorin wrote:
> This patch add set_rate and round_rate calls to csi_clk. This is needed
> to give mx3-camera control over master clock rate to camera.
> >The file you are patching is scheduled for removal in favour for the
> >common clock framework, so you are flogging a dead horse here. I suggest
> >that you wait some time until I finished the i.MX35 patches for this.
This patch allows me to move forward, without this patch the camera just does
not work. I'll use it as a temporary patch and happily wait for you to finish
your work on i.MX35 patches :-)
> +static int csi_set_rate(struct clk *clk, unsigned long rate)
> +{
> + unsigned long div;
> + unsigned long parent_rate;
> + unsigned long pdr2 = __raw_readl(CCM_BASE + CCM_PDR2);
> +
> + if (pdr2 & (1 << 7))
> + parent_rate = get_rate_arm();
> + else
> + parent_rate = get_rate_ppll();
> +
> + div = parent_rate / rate;
> +
> + /* Set clock divider */
> + pdr2 |= ((div - 1) & 0x3f) << 16;
> >btw you forget to clear the divider bits in pdr2 before
> >setting the new values.
Totally agree with you.
Regards,
Alex Gershgorin
--
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
[PATCH] ARM: i.MX35: Add set_rate and round_rate calls to csi_clk
This patch add set_rate and round_rate calls to csi_clk. This is needed
to give mx3-camera control over master clock rate to camera.
Signed-off-by: Alex Gershgorin
---
arch/arm/mach-imx/clock-imx35.c | 57 +-
1 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/clock-imx35.c b/arch/arm/mach-imx/clock-imx35.c
index ac8238c..3202b56 100644
--- a/arch/arm/mach-imx/clock-imx35.c
+++ b/arch/arm/mach-imx/clock-imx35.c
@@ -254,7 +254,7 @@ static unsigned long get_rate_ssi(struct clk *clk)
return rate / ((div1 + 1) * (div2 + 1));
}
-static unsigned long get_rate_csi(struct clk *clk)
+static unsigned long csi_get_rate(struct clk *clk)
{
unsigned long pdr2 = __raw_readl(CCM_BASE + CCM_PDR2);
unsigned long rate;
@@ -267,6 +267,45 @@ static unsigned long get_rate_csi(struct clk *clk)
return rate / (((pdr2 >> 16) & 0x3f) + 1);
}
+static int csi_set_rate(struct clk *clk, unsigned long rate)
+{
+ unsigned long div;
+ unsigned long parent_rate;
+ unsigned long pdr2 = __raw_readl(CCM_BASE + CCM_PDR2);
+
+ if (pdr2 & (1 << 7))
+ parent_rate = get_rate_arm();
+ else
+ parent_rate = get_rate_ppll();
+
+ div = parent_rate / rate;
+
+ /* Set clock divider */
+ pdr2 |= ((div - 1) & 0x3f) << 16;
+ __raw_writel(pdr2, CCM_BASE + CCM_PDR2);
+
+ return 0;
+}
+
+static unsigned long csi_round_rate(struct clk *clk, unsigned long rate)
+{
+ unsigned long div;
+ unsigned long parent_rate;
+ unsigned long pdr2 = __raw_readl(CCM_BASE + CCM_PDR2);
+
+ if (pdr2 & (1 << 7))
+ parent_rate = get_rate_arm();
+ else
+ parent_rate = get_rate_ppll();
+
+ div = parent_rate / rate;
+
+ if (parent_rate % rate)
+ div++;
+
+ return parent_rate / div;
+}
+
static unsigned long get_rate_otg(struct clk *clk)
{
unsigned long pdr4 = __raw_readl(CCM_BASE + CCM_PDR4);
@@ -353,6 +392,20 @@ static void clk_cgr_disable(struct clk *clk)
.disable= clk_cgr_disable, \
}
+#define DEFINE_CLOCK1(name, i, er, es, getsetround, s, p) \
+ static struct clk name = { \
+ .id = i,\
+ .enable_reg = CCM_BASE + er,\
+ .enable_shift = es, \
+ .get_rate = getsetround##_get_rate, \
+ .set_rate = getsetround##_set_rate, \
+ .round_rate = getsetround##_round_rate, \
+ .enable = clk_cgr_enable, \
+ .disable= clk_cgr_disable, \
+ .secondary = s,\
+ .parent = p,\
+ }
+
DEFINE_CLOCK(asrc_clk, 0, CCM_CGR0, 0, NULL, NULL);
DEFINE_CLOCK(pata_clk,0, CCM_CGR0, 2, get_rate_ipg, NULL);
/* DEFINE_CLOCK(audmux_clk, 0, CCM_CGR0, 4, NULL, NULL); */
@@ -403,7 +456,7 @@ DEFINE_CLOCK(wdog_clk, 0, CCM_CGR2, 24, NULL, NULL);
DEFINE_CLOCK(max_clk,0, CCM_CGR2, 26, NULL, NULL);
DEFINE_CLOCK(audmux_clk, 0, CCM_CGR2, 30, NULL, NULL);
-DEFINE_CLOCK(csi_clk,0, CCM_CGR3, 0, get_rate_csi, NULL);
+DEFINE_CLOCK1(csi_clk,0, CCM_CGR3, 0, csi, NULL, NULL);
DEFINE_CLOCK(iim_clk,0, CCM_CGR3, 2, NULL, NULL);
DEFINE_CLOCK(gpu2d_clk, 0, CCM_CGR3, 4, NULL, NULL);
--
1.7.0.4
--
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: [PATCH v1] i.MX35-PDK: Add Camera support
Hi all, Good news... After several number of changes, yesterday the camera started to work :-) I will prepare some patches and send them. On Mon, Mar 19, 2012 at 07:43:32PM -0300, Fabio Estevam wrote: > Hi Sascha, > > On Mon, Mar 19, 2012 at 7:37 PM, Sascha Hauer wrote: > > > It's scheduled there. I should have responded with an applied message. > > Please apply this one too: http://patchwork.ozlabs.org/patch/144942/ > Regards, Alex Gershgorin -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
[PATCH v1] i.MX35-PDK: Add Camera support
In i.MX35-PDK, OV2640 camera is populated on the
personality board. This camera is registered as a subdevice via soc-camera
interface.
Signed-off-by: Alex Gershgorin
---
arch/arm/mach-imx/mach-mx35_3ds.c | 96 +
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 0af6c9c..a7dd8e6 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -4,6 +4,11 @@
*
* Author: Fabio Estevam
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin
+ *
+ * Modified from i.MX31 3-Stack Development System
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -34,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,6 +47,8 @@
#include
#include
+#include
+
#include "devices-imx35.h"
#define EXPIO_PARENT_INT gpio_to_irq(IMX_GPIO_NR(1, 1))
@@ -120,6 +128,83 @@ static iomux_v3_cfg_t mx35pdk_pads[] = {
/* I2C1 */
MX35_PAD_I2C1_CLK__I2C1_SCL,
MX35_PAD_I2C1_DAT__I2C1_SDA,
+ /* CSI */
+ MX35_PAD_TX1__IPU_CSI_D_6,
+ MX35_PAD_TX0__IPU_CSI_D_7,
+ MX35_PAD_CSI_D8__IPU_CSI_D_8,
+ MX35_PAD_CSI_D9__IPU_CSI_D_9,
+ MX35_PAD_CSI_D10__IPU_CSI_D_10,
+ MX35_PAD_CSI_D11__IPU_CSI_D_11,
+ MX35_PAD_CSI_D12__IPU_CSI_D_12,
+ MX35_PAD_CSI_D13__IPU_CSI_D_13,
+ MX35_PAD_CSI_D14__IPU_CSI_D_14,
+ MX35_PAD_CSI_D15__IPU_CSI_D_15,
+ MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC,
+ MX35_PAD_CSI_MCLK__IPU_CSI_MCLK,
+ MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK,
+ MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC,
+};
+
+/*
+ * Camera support
+*/
+static phys_addr_t mx3_camera_base __initdata;
+#define MX35_3DS_CAMERA_BUF_SIZE SZ_8M
+
+static const struct mx3_camera_pdata mx35_3ds_camera_pdata __initconst = {
+ .flags = MX3_CAMERA_DATAWIDTH_8,
+ .mclk_10khz = 2000,
+};
+
+static int __init imx35_3ds_init_camera(void)
+{
+ int dma, ret = -ENOMEM;
+ struct platform_device *pdev =
+ imx35_alloc_mx3_camera(&mx35_3ds_camera_pdata);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ if (!mx3_camera_base)
+ goto err;
+
+ dma = dma_declare_coherent_memory(&pdev->dev,
+ mx3_camera_base, mx3_camera_base,
+ MX35_3DS_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+
+ if (!(dma & DMA_MEMORY_MAP))
+ goto err;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+err:
+ platform_device_put(pdev);
+
+ return ret;
+}
+
+static const struct ipu_platform_data mx35_3ds_ipu_data __initconst = {
+ .irq_base = MXC_IPU_IRQ_START,
+};
+
+static struct i2c_board_info mx35_3ds_i2c_camera = {
+ I2C_BOARD_INFO("ov2640", 0x30),
+};
+
+static struct soc_camera_link iclink_ov2640 = {
+ .bus_id = 0,
+ .board_info = &mx35_3ds_i2c_camera,
+ .i2c_adapter_id = 0,
+ .power = NULL,
+};
+
+static struct platform_device mx35_3ds_ov2640 = {
+ .name = "soc-camera-pdrv",
+ .id = 0,
+ .dev= {
+ .platform_data = &iclink_ov2640,
+ },
};
static int mx35_3ds_otg_init(struct platform_device *pdev)
@@ -204,6 +289,9 @@ static void __init mx35_3ds_init(void)
pr_warn("Init of the debugboard failed, all "
"devices on the debugboard are unusable.\n");
imx35_add_imx_i2c0(&mx35_3ds_i2c0_data);
+ imx35_add_ipu_core(&mx35_3ds_ipu_data);
+ platform_device_register(&mx35_3ds_ov2640);
+ imx35_3ds_init_camera();
}
static void __init mx35pdk_timer_init(void)
@@ -215,6 +303,13 @@ struct sys_timer mx35pdk_timer = {
.init = mx35pdk_timer_init,
};
+static void __init mx35_3ds_reserve(void)
+{
+ /* reserve MX35_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
+ mx3_camera_base = arm_memblock_steal(MX35_3DS_CAMERA_BUF_SIZE,
+MX35_3DS_CAMERA_BUF_SIZE);
+}
+
MACHINE_START(MX35_3DS, "Freescale MX35PDK")
/* Maintainer: Freescale Semiconductor, Inc */
.atag_offset = 0x100,
@@ -224,5 +319,6 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.handle_irq = imx35_handle_irq,
.timer = &mx35pdk_timer,
.init_machine = mx35_3ds_init,
+ .reserve = mx35_3ds_reserve,
.restart= mxc_restart,
MACHINE_END
--
1.7.0.4
--
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: [PATCH] i.MX35-PDK: Add Camera support
Hi Fabio, On Mon, Mar 12, 2012 at 1:28 PM, Alex wrote: > In i.MX35-PDK, OV2640 Â camera is populated on the > personality board. This camera is registered as a subdevice via soc-camera > interface. > > Signed-off-by: Alex Gershgorin > >Are you able to get the camera working correctly now? > >Or are you still facing the issues you reported earlier? This problem not solved, I'm still doing testing Thanks Alex Gershgorin -- 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: [PATCH] i.MX35-PDK: Add Camera support
Hi Sascha, Thanks for you comments. > In i.MX35-PDK, OV2640 camera is populated on the > personality board. This camera is registered as a subdevice via soc-camera > interface. > > Signed-off-by: Alex Gershgorin > --- > arch/arm/mach-imx/mach-mx35_3ds.c | 87 > + > 1 files changed, 87 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c > b/arch/arm/mach-imx/mach-mx35_3ds.c > > This one does not apply as it is obviously based on (an earlier version > > of) the framebuffer patches of this board. Please always base your stuff > > on some -rc kernel. We can resolve conflicts later upstream, but we > > cannot easily apply a patch when we do not have the correct base. > >Please add the linux arm kernel mailing list next time. Oh what a stupid mistake, I will correct it. Regards, Alex Gershgorin -- 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: I.MX35 PDK
Thanks for your response, > 1. Back resistor 172 to the default value. > > 2. Removed the resistor 146, through which a voltage was applied from a PMIC > (EXT_3V) on "CMOS_VIO". > > 3. Connecting a resistor 147 which supplies power from the LDO_3V3 on > "CMOS_VIO". > >The camera on the FSL BSP works fine with no hardware modification on > >the mx35pdk. > >As I suggested previously you should control the power rails, i2c pad > >settings, etc from software so that the camera can also work in > >mainline without the need of changing the hardware. You're right, currently mainline Linux kernel i.MX35 PDK platform does not support power management devices, probably for this reason was the need for small changes in equipment. > On my display I see snow flickering and unfortunately not a live video from > camera. > >Do you have this patch applied? Yes I need to prepare it. > >http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f910fb8fcd1c97788f2291c8646597bcd87ee061 > >Also, try to isolate the display from this issue. Capture the image to > >a file and try to play it on a PC. Thanks for the tip, I'll think about how I can check it. Regards Alex Gershgorin -- 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: I.MX35 PDK
>On my mx31pdk I get the same dmaengine errors and the ov2640 does work fine. >I think you can go ahead and try to use the camera on the mx35pdk now. >You can try: >gst-launch -v v4l2src device=/dev/video0 ! >video/x-raw-yuv,width=320,height=240,framerate=25/1 ! ffmpegcolorspace >! fbdevsink
RE: I.MX35 PDK
Hi Guennadi, Thanks for you comments... >>>Hi Alex >>>Why is the cc-list mangled again? Why is the V4L list dropped again? >>>What's so difficult about hitting the "reply-to-all" button? You are absolutely right, I hope that now the cc-list valid. > Hi Fabio, > > Thanks for you response... > > > in spite of this I get from ov2640 driver error > > Here Linux Kernel boot message: > > > > "Linux video capture interface: v2.00 > > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > > mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0 > > ov2640 0-0030: Product ID error fb:fb" > > > > I cannot understand what the problem is, if someone tested this? > > >>Looks like a I2C issue. > > >>Check the I2C1 pad settings in the mainline kernel. > > >>On FSL kernel we have: > > #< >>PAD_CTL_PUE_PUD | PAD_CTL_ODE_OpenDrain) > > < < < < > < < > >>Also check if you are getting the proper voltage levels at the I2C1 lines. > > Yes this I2C problem, all I2C slave device need response to Host CPU by pulls > I2C data bus to low, in other words generate ACK, the clock pulse for the > acknowledge bit is always created by the bus master. > > In this case, the camera tries to reset the data bus and generate an ACK, but > the voltage drops to the area of two volts, although it should be reset to > zero. > I replaced R172 with 10K on CPU board and got a good result, but there are > other surprises > > Linux video capture interface: v2.00 > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0 > ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 > i2c i2c-0: OV2640 Probed > mx3-camera mx3-camera.0: MX3 Camera driver detached from camera 0 > dmaengine: failed to get dma1chan0: (-22) > dmaengine: failed to get dma1chan1: (-22) > dmaengine: failed to get dma1chan2: (-22) > dmaengine: failed to get dma1chan3: (-22) >>>First of all it shows, that you're not using the newest kernel: >>>http://thread.gmane.org/gmane.linux.ports.sh.devel/11508 I use Linux version 3.3.0-rc6 it contains the changes. >>>Secondly, as Fabio just pointed out, these messages are not fatal, which >>>is also the reason, why I changed their priority to "debug" Ok >>>Please, describe the actual problem, that you're getting (if any) and do >>>add the v4l list back to the list of recipients! At this stage, for me the problem of this type are actual, for the simple reason that I see it the first time. Thanks for support and patience :-) > What is the problem? > Guennadi please help me understand > Regards, Alex Gershgorin -- 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: I.MX35 PDK
> Yes this I2C problem, all I2C slave device need response to Host CPU by > pulls I2C data bus to low, in other words generate ACK, the clock pulse for > the acknowledge bit is always created by the bus master. > > In this case, the camera tries to reset the data bus and generate an ACK, > but the voltage drops to the area of two volts, although it should be reset > to zero. > I replaced R172 with 10K on CPU board and got a good result, but there are > other surprises >Ok, good. >Can you try to change the I2C1 pad settings in software, so that the >board can work with the original resistor? In the near future I will check this option:-) > > Linux video capture interface: v2.00 > soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 > mx3-camera mx3-camera.0: MX3 Camera driver attached to camera 0 > ov2640 0-0030: ov2640 Product ID 26:42 Manufacturer ID 7f:a2 > i2c i2c-0: OV2640 Probed1 > mx3-camera mx3-camera.0: MX3 Camera driver detached from camera 0 > dmaengine: failed to get dma1chan0: (-22) > dmaengine: failed to get dma1chan1: (-22) > dmaengine: failed to get dma1chan2: (-22) > dmaengine: failed to get dma1chan3: (-22) > dmaengine: failed to get dma1chan4: (-22) > dmaengine: failed to get dma1chan5: (-22) > dmaengine: failed to get dma1chan6: (-22) > dmaengine: failed to get dma1chan7: (-22) > dmaengine: failed to get dma1chan8: (-22) > dmaengine: failed to get dma1chan9: (-22) > dmaengine: failed to get dma1chan10: (-22) > dmaengine: failed to get dma1chan11: (-22) > dmaengine: failed to get dma1chan12: (-22) > dmaengine: failed to get dma1chan13: (-22) > dmaengine: failed to get dma1chan14: (-22) > dmaengine: failed to get dma1chan15: (-22) > dmaengine: failed to get dma1chan16: (-22) > dmaengine: failed to get dma1chan17: (-22) > dmaengine: failed to get dma1chan18: (-22) > dmaengine: failed to get dma1chan19: (-22) > dmaengine: failed to get dma1chan20: (-22) > dmaengine: failed to get dma1chan21: (-22) > dmaengine: failed to get dma1chan22: (-22) > dmaengine: failed to get dma1chan23: (-22) > dmaengine: failed to get dma1chan24: (-22) > dmaengine: failed to get dma1chan25: (-22) > dmaengine: failed to get dma1chan26: (-22) > dmaengine: failed to get dma1chan27: (-22) > dmaengine: failed to get dma1chan28: (-22) > dmaengine: failed to get dma1chan29: (-22) > dmaengine: failed to get dma1chan30: (-22): >This is something that needs to be solved, but it does not prevent the >camera to work though. >On my mx31pdk I get the same dmaengine errors and the ov2640 does work fine. >I think you can go ahead and try to use the camera on the mx35pdk now. >You can try: >gst-launch -v v4l2src device=/dev/video0 ! >video/x-raw-yuv,width=320,height=240,framerate=25/1 ! ffmpegcolorspace >! fbdevsink Thank Fabio I'll try to check it. Regards Alex Gershgorin -- 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: mx3-camera
From: Alex Gershgorin
Sent: Tuesday, March 06, 2012 3:22 PM
To: Guennadi Liakhovetski
Cc: linux-ker...@vger.kernel.org; Linux Media Mailing List; Sascha Hauer
Subject: RE: mx3-camera
Thanks Guennadi,
>Hi Alex
>(adding v4l and Sascha to CC)
>On Tue, 6 Mar 2012, Alex Gershgorin wrote:
> Hi Guennadi,
>
> I'm working on I.MX35 PDK platform with use 3.3.0-rc6 version of the Linux
> Kernel.
> Here is my Kernel boot message
>
> "Linux video capture interface: v2.00
> mx3-camera: probe of mx3-camera.0 failed with error -2"
>
> This error comes from probe function of mx3 camera host driver.
> Precisely in this part of the code:
>
> mx3_cam->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(mx3_cam->clk)) {
> err = PTR_ERR(mx3_cam->clk);
> goto eclkget;
> }
>I think, the reason is, that the i.MX35 platform doesn't register a camera
>clock, similar to i.MX31 (arch/arm/mach-imx/clock-imx31.c):
> _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
In i.MX35 (arch/arm/mach-imx/clock-imx35.c) it looks like this:
_REGISTER_CLOCK(NULL, "csi", csi_clk)
You were right, it should be _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
I checked, now this error not appear :-)
> I will be glad for any help.
Regards,
Alex Gershgorin
--
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: mx3-camera
Thanks Guennadi,
>Hi Alex
>(adding v4l and Sascha to CC)
>On Tue, 6 Mar 2012, Alex Gershgorin wrote:
> Hi Guennadi,
>
> I'm working on I.MX35 PDK platform with use 3.3.0-rc6 version of the Linux
> Kernel.
> Here is my Kernel boot message
>
> "Linux video capture interface: v2.00
> mx3-camera: probe of mx3-camera.0 failed with error -2"
>
> This error comes from probe function of mx3 camera host driver.
> Precisely in this part of the code:
>
> mx3_cam->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(mx3_cam->clk)) {
> err = PTR_ERR(mx3_cam->clk);
> goto eclkget;
> }
>I think, the reason is, that the i.MX35 platform doesn't register a camera
>clock, similar to i.MX31 (arch/arm/mach-imx/clock-imx31.c):
> _REGISTER_CLOCK("mx3-camera.0", NULL, csi_clk)
In i.MX35 (arch/arm/mach-imx/clock-imx35.c) it looks like this:
_REGISTER_CLOCK(NULL, "csi", csi_clk)
> I will be glad for any help.
>
Regards,
Alex Gershgorin
--
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: i.mx35 live video
Hi, On 02/26/2012 09:58 PM, Guennadi Liakhovetski wrote: >>> It might be difficult to completely eliminate the CPU, at the very least >>> you need to queue and dequeue buffers to and from the V4L driver. To avoid >>> even that, in principle, you could try to use only one buffer, but I don't >>> think the current version of the mx3_camera driver would be very happy >>> about that. You could take 2 buffers and use panning, then you'd just have >>> to send queue and dequeue buffers and pan the display. But in any case, >>> you probably will have to process buffers, but your most important >>> advantage is, that you won't have to copy data, you only have to move >>> pointers around. >> >> The method that you describe is exactly what I had in mind. >> It would be more correct to say it is "minimum" CPU intervention and not >> without CPU intervention. > >> As far I understand, I can implement MMAP method for frame buffer device >> and pass this pointer directly to mx3_camera driver with use USERPTR >> method, then send queue and dequeue buffers to mx3_camera driver. >> What is not clear, if it is possible to pass the same pointer of frame >> buffer in mx3_camera, if the driver is using two buffers? frame buffer start) to them. I've seen setups like this working with http://vger.kernel.org/majordomo-info.html
RE: i.mx35 live video
-Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Sunday, February 26, 2012 10:58 PM To: Alex Gershgorin Cc: linux-media@vger.kernel.org Subject: RE: i.mx35 live video On Sun, 26 Feb 2012, Alex Gershgorin wrote: > > Thanks Guennadi for your quick response , > > > > >Hi Alex > > > > > Hi Guennadi, > > > > > > We would like to use I.MX35 processor in new project. > > > An important element of the project is to obtain life video from the > > > camera and display it on display. > > > For these purposes, we want to use mainline Linux kernel which supports > > > all the necessary drivers for the implementation of this task. > > > As I understand that soc_camera is not currently supported userptr > > > method, in which case how I can configure the video pipeline in user space > > > to get the live video on display, without the intervention of the > > > processor. > > > > >soc-camera does support USERPTR, also the mx3_camera driver claims to > > >support it. > > > > I based on soc-camera.txt document. > > > Yeah, I really have to update it... > > > The soc-camera subsystem provides a unified API between camera host drivers > > and > > camera sensor drivers. It implements a V4L2 interface to the user, currently > > only the mmap method is supported. > > > > In any case, I glad that this supported :-) > > > > What do you think it is possible to implement video streaming without > > the intervention of the processor? > > >It might be difficult to completely eliminate the CPU, at the very least > >you need to queue and dequeue buffers to and from the V4L driver. To avoid > >even that, in principle, you could try to use only one buffer, but I don't > >think the current version of the mx3_camera driver would be very happy > >about that. You could take 2 buffers and use panning, then you'd just have > >to send queue and dequeue buffers and pan the display. But in any case, > >you probably will have to process buffers, but your most important > >advantage is, that you won't have to copy data, you only have to move > >pointers around. > > The method that you describe is exactly what I had in mind. > It would be more correct to say it is "minimum" CPU intervention and not > without CPU intervention. > As far I understand, I can implement MMAP method for frame buffer device > and pass this pointer directly to mx3_camera driver with use USERPTR > method, then send queue and dequeue buffers to mx3_camera driver. > What is not clear, if it is possible to pass the same pointer of frame > buffer in mx3_camera, if the driver is using two buffers? http://vger.kernel.org/majordomo-info.html
RE: i.mx35 live video
> Thanks Guennadi for your quick response , > > >Hi Alex > > > Hi Guennadi, > > > > We would like to use I.MX35 processor in new project. > > An important element of the project is to obtain life video from the camera > > and display it on display. > > For these purposes, we want to use mainline Linux kernel which supports all > > the necessary drivers for the implementation of this task. > > As I understand that soc_camera is not currently supported userptr method, > > in which case how I can configure the video pipeline in user space > > to get the live video on display, without the intervention of the processor. > > >soc-camera does support USERPTR, also the mx3_camera driver claims to > >support it. > > I based on soc-camera.txt document. > Yeah, I really have to update it... > The soc-camera subsystem provides a unified API between camera host drivers > and > camera sensor drivers. It implements a V4L2 interface to the user, currently > only the mmap method is supported. > > In any case, I glad that this supported :-) > > What do you think it is possible to implement video streaming without > the intervention of the processor? >It might be difficult to completely eliminate the CPU, at the very least >you need to queue and dequeue buffers to and from the V4L driver. To avoid >even that, in principle, you could try to use only one buffer, but I don't >think the current version of the mx3_camera driver would be very happy >about that. You could take 2 buffers and use panning, then you'd just have >to send queue and dequeue buffers and pan the display. But in any case, >you probably will have to process buffers, but your most important >advantage is, that you won't have to copy data, you only have to move >pointers around. The method that you describe is exactly what I had in mind. It would be more correct to say it is "minimum" CPU intervention and not without CPU intervention. As far I understand, I can implement MMAP method for frame buffer device and pass this pointer directly to mx3_camera driver with use USERPTR method, then send queue and dequeue buffers to mx3_camera driver. What is not clear, if it is possible to pass the same pointer of frame buffer in mx3_camera, if the driver is using two buffers? Thanks, Alex Gershgorin -- 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: i.mx35 live video
Thanks Guennadi for your quick response , >Hi Alex > Hi Guennadi, > > We would like to use I.MX35 processor in new project. > An important element of the project is to obtain life video from the camera > and display it on display. > For these purposes, we want to use mainline Linux kernel which supports all > the necessary drivers for the implementation of this task. > As I understand that soc_camera is not currently supported userptr method, in > which case how I can configure the video pipeline in user space > to get the live video on display, without the intervention of the processor. >soc-camera does support USERPTR, also the mx3_camera driver claims to >support it. I based on soc-camera.txt document. The soc-camera subsystem provides a unified API between camera host drivers and camera sensor drivers. It implements a V4L2 interface to the user, currently only the mmap method is supported. In any case, I glad that this supported :-) What do you think it is possible to implement video streaming without the intervention of the processor? Regards, Alex Gershgorin -- 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: OMAP3ISP boot problem
Hi Laurent, On Saturday 10 December 2011 14:36:17 Alex Gershgorin wrote: > > Hi Sakari, > > > > Thank you for your quick response and sorry for stupid question. > > Yes CONFIG_OMAP_IOMMU and CONFIG_OMAP_IOVMM enabled, > > because OMAP 3 camera controller depends on the CONFIG_OMAP_IOVMM and > > CONFIG_OMAP_IOMMU. Please tell me how I can use dmabuf instead of the > > IOMMU/IOVMM API. > > > >Unfortunately that real fix isn't available yet and won't be for some > >time. Still, it should be fully functional currently. > > > >Looking at the backtrace again, it seems to crash in > >driver_find_device(). That looks fishy. > > > >Do you have the ISP driver compiled into the kernel? I might try it as a > >module, albeit it of course should work when it's linked to the kernel > >as well. > > Yes ISP driver compiled into kernel, but if I back to previos version of > the Linux kernel 3.0.0, that works well. Here part of kernel boot > message... > > > [2.063354] Linux media interface: v0.10 > > [2.068298] Linux video capture interface: v2.00 > > [2.075561] omap3isp omap3isp: Revision 2.0 found > > [2.080932] omap-iommu omap-iommu.0: isp: version 1.1 > > [2.099365] Camera Video probed > > [2.115997] vivi-000: V4L2 device registered as video7 > > Now I plan to start using a newer version of the Linux kernel 3.2.0-rc4, > but unfortunately faced with the problem. That suggest? >I'm quite surprised. I've just tested 3.2-rc2 here, and got no oops when >loading the omap3-isp driver. I've tried compiling the driver in the kernel >and as a module, and both succeeded. I've pushed my code to >http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- >sensors-board if you want to give it a try. >Thanks Laurent, >Tomorrow I'll try to test on Hardware that I have with using kernel 3.2-rc2 >and Tell you about my results. >Regards, >Alex Gershgorin Present result is much better, I tested it on kernel 3.2.0-rc5 and the registration is successful. Here part of my boot message: [1.926635] Linux video capture interface: v2.00 [1.936553] OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec [1.959472] omap-iommu omap-iommu.0: isp registered *** *** *** [2.043945] omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz [2.056945] omap3isp omap3isp: Revision 2.0 found [2.062622] omap-iommu omap-iommu.0: isp: version 1.1 [2.082092] camera 3-0057: Probing CAMERA at address 0x57 [2.088439] camera 3-0057: CAMERA detected at address 0x57 I honestly didn't understand where's the catch . Many thanks to all. Regards, Alex Gershgorin -- 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: OMAP3ISP boot problem
Hi Alex, On Saturday 10 December 2011 14:36:17 Alex Gershgorin wrote: > > Hi Sakari, > > > > Thank you for your quick response and sorry for stupid question. > > Yes CONFIG_OMAP_IOMMU and CONFIG_OMAP_IOVMM enabled, > > because OMAP 3 camera controller depends on the CONFIG_OMAP_IOVMM and > > CONFIG_OMAP_IOMMU. Please tell me how I can use dmabuf instead of the > > IOMMU/IOVMM API. > > > >Unfortunately that real fix isn't available yet and won't be for some > >time. Still, it should be fully functional currently. > > > >Looking at the backtrace again, it seems to crash in > >driver_find_device(). That looks fishy. > > > >Do you have the ISP driver compiled into the kernel? I might try it as a > >module, albeit it of course should work when it's linked to the kernel > >as well. > > Yes ISP driver compiled into kernel, but if I back to previos version of > the Linux kernel 3.0.0, that works well. Here part of kernel boot > message... > > > [2.063354] Linux media interface: v0.10 > > [2.068298] Linux video capture interface: v2.00 > > [2.075561] omap3isp omap3isp: Revision 2.0 found > > [2.080932] omap-iommu omap-iommu.0: isp: version 1.1 > > [2.099365] Camera Video probed > > [2.115997] vivi-000: V4L2 device registered as video7 > > Now I plan to start using a newer version of the Linux kernel 3.2.0-rc4, > but unfortunately faced with the problem. That suggest? I'm quite surprised. I've just tested 3.2-rc2 here, and got no oops when loading the omap3-isp driver. I've tried compiling the driver in the kernel and as a module, and both succeeded. I've pushed my code to http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- sensors-board if you want to give it a try. Thanks Laurent, Tomorrow I'll try to test on Hardware that I have with using kernel 3.2-rc2 and Tell you about my results. Regards, Alex Gershgorin-- 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: OMAP3ISP boot problem
> Hi Sakari, > > Thank you for your quick response and sorry for stupid question. > Yes CONFIG_OMAP_IOMMU and CONFIG_OMAP_IOVMM enabled, > because OMAP 3 camera controller depends on the CONFIG_OMAP_IOVMM and > CONFIG_OMAP_IOMMU. > Please tell me how I can use dmabuf instead of the IOMMU/IOVMM API. >Unfortunately that real fix isn't available yet and won't be for some >time. Still, it should be fully functional currently. >Looking at the backtrace again, it seems to crash in >driver_find_device(). That looks fishy. >Do you have the ISP driver compiled into the kernel? I might try it as a >module, albeit it of course should work when it's linked to the kernel >as well. Yes ISP driver compiled into kernel, but if I back to previos version of the Linux kernel 3.0.0, that works well. Here part of kernel boot message... > [2.063354] Linux media interface: v0.10 > [2.068298] Linux video capture interface: v2.00 > [2.075561] omap3isp omap3isp: Revision 2.0 found > [2.080932] omap-iommu omap-iommu.0: isp: version 1.1 > [2.099365] Camera Video probed > [2.115997] vivi-000: V4L2 device registered as video7 Now I plan to start using a newer version of the Linux kernel 3.2.0-rc4, but unfortunately faced with the problem. That suggest? Thanks, Alex Gershgorin -- 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: OMAP3ISP boot problem
Hi Sakari,
Thank you for your quick response and sorry for stupid question.
Yes CONFIG_OMAP_IOMMU and CONFIG_OMAP_IOVMM enabled,
because OMAP 3 camera controller depends on the CONFIG_OMAP_IOVMM and
CONFIG_OMAP_IOMMU.
Please tell me how I can use dmabuf instead of the IOMMU/IOVMM API.
Regards,
Alex Gershgorin
Hi Alex,
Alex Gershgorin wrote:
> Hi All,
>
> I have problem in booting the Kernel.
> Here the problematic part of the boot message.
> As I understand it happens when isp_probe calling and it calls isp->iommu_dev
> = omap_find_iommu_device("isp");
>
> [1.976715] Linux media interface: v0.10
> [1.981781] Linux video capture interface: v2.00
> [1.989257] omap3isp omap3isp: Revision 2.0 found
> [1.998138] Unable to handle kernel NULL pointer dereference at virtual
> address 0050
> [2.006683] pgd = c0004000
> [2.010009] [0050] *pgd=
> [2.013793] Internal error: Oops: 5 [#1]
> [2.017913] Modules linked in:
> [2.021148] CPU: 0Tainted: GW
> (3.2.0-rc4-2-g2d47fa7-dirty #1304)
> [2.029296] PC is at klist_next+0x10/0xc4
> [2.033508] LR is at next_device+0x8/0x14
> [2.037750] pc : []lr : []psr: 6013
> [2.037750] sp : c7425eb0 ip : c05e080c fp :
> [2.049804] r10: c04b2367 r9 : c058b4f8 r8 : 03ff
> [2.055297] r7 : 000e r6 : r5 : c031827c r4 : c7425ed0
> [2.062164] r3 : c031827c r2 : r1 : c7425ed0 r0 : 0024
> [2.069000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> kernel
> [2.076690] Control: 10c5387d Table: 80004019 DAC: 0015
> [2.082733] Process swapper (pid: 1, stack limit = 0xc74242f0)
> [2.088867] Stack: (0xc7425eb0 to 0xc7426000)
> [2.093444] 5ea0: c031827c c04ae343
> c031827c c05d7650
> [2.102050] 5ec0: 000e c0251e5c c031827c c0251ec8 0024
> c76e8000 74e0
> [2.110656] 5ee0: c058b4f0 c030462c c01181e4 c058b4f8 c0055f04
> c76e8508
> [2.119232] 5f00: c74976c0 c05d4fe4 c058b4f8 c058b52c c05d4fe4
> c05d4fe4
> [2.127838] 5f20: c0252784 c0252770 c02515e4
> c058b4f8
> [2.136444] 5f40: c058b52c c05d4fe4 c0251708 c05d4fe4 c02516a0
> c0250e20
> [2.145050] 5f60: c7420058 c7481490 c05d4fe4 c76c9140 c05c45d0 c0250768
> c04ae33e
> [2.153656] 5f80: c7423340 c05d4fe4 c056e4cc c000dbfc
> c0251d20
> [2.162231] 5fa0: c0583210 c056e4cc c000dbfc c000857c
> c0582dd0 3539
> [2.170837] 5fc0: c000 0013 c0583210 c0582dd0 c000dbfc
> 0013
> [2.179443] 5fe0: c0553204 c7423340 c0553194 c000dbfc
> bf0285ff fb000400
> [2.188049] [] (klist_next+0x10/0xc4) from []
> (next_device+0x8/0x14)
> [2.196563] [] (next_device+0x8/0x14) from []
> (driver_find_device+0x60/0x78)
> [2.205841] [] (driver_find_device+0x60/0x78) from []
> (isp_probe+0x238/0xa5c)
> [2.215179] [] (isp_probe+0x238/0xa5c) from []
> (platform_drv_probe+0x14/0x18)
> [2.224517] [] (platform_drv_probe+0x14/0x18) from []
> (driver_probe_device+0xc8/0x184)
> [2.234680] [] (driver_probe_device+0xc8/0x184) from
> [] (__driver_attach+0x68/0x8c)
> [2.244567] [] (__driver_attach+0x68/0x8c) from []
> (bus_for_each_dev+0x48/0x74)
> [2.254058] [] (bus_for_each_dev+0x48/0x74) from []
> (bus_add_driver+0xa0/0x21c)
> [2.263580] [] (bus_add_driver+0xa0/0x21c) from []
> (driver_register+0xa4/0x130)
> [2.273101] [] (driver_register+0xa4/0x130) from []
> (do_one_initcall+0x98/0x16c)
> [2.282714] [] (do_one_initcall+0x98/0x16c) from []
> (kernel_init+0x70/0x118)
> [2.291992] [] (kernel_init+0x70/0x118) from []
> (kernel_thread_exit+0x0/0x8)
> [2.301208] Code: e92d40f8 e1a04000 e590 e5946004 (e590702c)
> [2.307708] ---[ end trace 1b75b31a2719ed1e ]---
> [2.312652] Kernel panic - not syncing: Attempted to kill init!
>
> I will appreciate any help.
Just a stupid question... do you have CONFIG_OMAP_IOMMU and
CONFIG_OMAP_IOVMM enabled? This is a known problem; the real fix
involves using dmabuf instead of the IOMMU/IOVMM API.
Regards,
--
Sakari Ailus
sakari.ai...@iki.fi--
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: OMAP3ISP boot problem
Hi All,
I have problem in booting the Kernel.
Here the problematic part of the boot message.
As I understand it happens when isp_probe calling and it calls isp->iommu_dev =
omap_find_iommu_device("isp");
[1.976715] Linux media interface: v0.10
[1.981781] Linux video capture interface: v2.00
[1.989257] omap3isp omap3isp: Revision 2.0 found
[1.998138] Unable to handle kernel NULL pointer dereference at virtual
address 0050
[2.006683] pgd = c0004000
[2.010009] [0050] *pgd=
[2.013793] Internal error: Oops: 5 [#1]
[2.017913] Modules linked in:
[2.021148] CPU: 0Tainted: GW
(3.2.0-rc4-2-g2d47fa7-dirty #1304)
[2.029296] PC is at klist_next+0x10/0xc4
[2.033508] LR is at next_device+0x8/0x14
[2.037750] pc : []lr : []psr: 6013
[2.037750] sp : c7425eb0 ip : c05e080c fp :
[2.049804] r10: c04b2367 r9 : c058b4f8 r8 : 03ff
[2.055297] r7 : 000e r6 : r5 : c031827c r4 : c7425ed0
[2.062164] r3 : c031827c r2 : r1 : c7425ed0 r0 : 0024
[2.069000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[2.076690] Control: 10c5387d Table: 80004019 DAC: 0015
[2.082733] Process swapper (pid: 1, stack limit = 0xc74242f0)
[2.088867] Stack: (0xc7425eb0 to 0xc7426000)
[2.093444] 5ea0: c031827c c04ae343
c031827c c05d7650
[2.102050] 5ec0: 000e c0251e5c c031827c c0251ec8 0024
c76e8000 74e0
[2.110656] 5ee0: c058b4f0 c030462c c01181e4 c058b4f8 c0055f04
c76e8508
[2.119232] 5f00: c74976c0 c05d4fe4 c058b4f8 c058b52c c05d4fe4
c05d4fe4
[2.127838] 5f20: c0252784 c0252770 c02515e4
c058b4f8
[2.136444] 5f40: c058b52c c05d4fe4 c0251708 c05d4fe4 c02516a0
c0250e20
[2.145050] 5f60: c7420058 c7481490 c05d4fe4 c76c9140 c05c45d0 c0250768
c04ae33e
[2.153656] 5f80: c7423340 c05d4fe4 c056e4cc c000dbfc
c0251d20
[2.162231] 5fa0: c0583210 c056e4cc c000dbfc c000857c
c0582dd0 3539
[2.170837] 5fc0: c000 0013 c0583210 c0582dd0 c000dbfc
0013
[2.179443] 5fe0: c0553204 c7423340 c0553194 c000dbfc
bf0285ff fb000400
[2.188049] [] (klist_next+0x10/0xc4) from []
(next_device+0x8/0x14)
[2.196563] [] (next_device+0x8/0x14) from []
(driver_find_device+0x60/0x78)
[2.205841] [] (driver_find_device+0x60/0x78) from []
(isp_probe+0x238/0xa5c)
[2.215179] [] (isp_probe+0x238/0xa5c) from []
(platform_drv_probe+0x14/0x18)
[2.224517] [] (platform_drv_probe+0x14/0x18) from []
(driver_probe_device+0xc8/0x184)
[2.234680] [] (driver_probe_device+0xc8/0x184) from []
(__driver_attach+0x68/0x8c)
[2.244567] [] (__driver_attach+0x68/0x8c) from []
(bus_for_each_dev+0x48/0x74)
[2.254058] [] (bus_for_each_dev+0x48/0x74) from []
(bus_add_driver+0xa0/0x21c)
[2.263580] [] (bus_add_driver+0xa0/0x21c) from []
(driver_register+0xa4/0x130)
[2.273101] [] (driver_register+0xa4/0x130) from []
(do_one_initcall+0x98/0x16c)
[2.282714] [] (do_one_initcall+0x98/0x16c) from []
(kernel_init+0x70/0x118)
[2.291992] [] (kernel_init+0x70/0x118) from []
(kernel_thread_exit+0x0/0x8)
[2.301208] Code: e92d40f8 e1a04000 e590 e5946004 (e590702c)
[2.307708] ---[ end trace 1b75b31a2719ed1e ]---
[2.312652] Kernel panic - not syncing: Attempted to kill init!
I will appreciate any help.
Thanks
Alex Gershgorin--
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: Parallel CMOS Image Sensor with UART Control Interface
Hi All, I want to say that in the beginning I encountered the same problem, but with the support of Laurent and other guys, today on my system OMAP3 ISP successfully passes registration. To my yet, I still cannot connect my video source because it's missing, but I successfully configure pipeline with use MC User space API. Regards, Alex Gershgorin -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, July 27, 2011 11:59 AM To: James Cc: Sakari Ailus; linux-media@vger.kernel.org; michael.jo...@matrix-vision.de; Alex Gershgorin Subject: Re: Parallel CMOS Image Sensor with UART Control Interface Hi James, On Wednesday 27 July 2011 07:41:59 James wrote: > On Wed, Jul 27, 2011 at 3:40 AM, Sakari Ailus wrote: > > On Mon, Jul 25, 2011 at 04:43:21PM +0800, James wrote: > >> Dear all, > >> > >> Does anyone came across a v4l2 Linux Device Driver for an Image Sensor > >> that uses Parallel CMOS H/V and can only be control by UART interface > >> instead of the common I2C or SPI interface? > >> > >> A similar sensor is the STMicroelectronics VL5510 Image Sensor > >> although it support all 3 types of control interface. > >> (http://www.st.com/internet/automotive/product/178477.jsp) > >> > >> Most or all the drivers found I found under drivers/media/video uses > >> the I2C or SPI interface instead > >> > >> I'm new to writing driver and need a reference v4l2 driver for this > >> type of image sensor to work with OMAP3530 ISP port on Gumstix's Overo > >> board. > >> > >> I just need a very simple v4l2 driver that can extract the image from > >> the sensor and control over it via the UART control interface. > >> > >> Any help is very much appreciated. > > > > Hi James, > > > > I think there has been a recent discussion on a similar topic under the > > subject "RE: FW: OMAP 3 ISP". The way to do this would be to implement > > platform subdevs in V4L2 core, which I think we don't have quite yet. > > > > Cc Laurent and Michael. > > Hi Sakari, > > Thanks for pointing me to the discussion thread. > > I found it from the archive at > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3270 > 0/focus=32721 > > I read through the threads and see that I'm indeed in similar > situation with Alex. > > We both have sensor that output CMOS H/V image and only have > UART/RS232 for control of the sensor operations via sending/reading > packet of bytes. i.e. AGC, contrast, brightness etc.. > > Since the thread ended on 29-Jun, is there anymore update or information? > > As I've a MT9V032 camera with Gusmtix Overo, I was hoping to rely on > the MT9V032 driver as a starting point and adapt it for the VL5510 > sensor using only the UART interface. As a quick hack, to start with, you can still use an I2C subdev driver. Just remove all I2C-related code from the driver, and register a fake I2C device in board code. That will let you at least develop the driver and test the UART interface. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6327 (20110726) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6328 (20110727) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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: FW: OMAP 3 ISP
Hi Laurent
Good news!
Now registration is successful, many thanks.
Now I can move on to the next stage of work.
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, June 29, 2011 6:55 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; 'Michael Jones'; 'linux-media@vger.kernel.org';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Alex,
On Wednesday 29 June 2011 15:50:54 Alex Gershgorin wrote:
> On Wednesday, June 29, 2011 2:33 PM Laurent Pinchart wrote:
> > On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> > >
> > > From previous correspondence:
> > >
> > > My video source is not the video camera and performs many other
> > > functions.
> > >
> > > For this purpose I have RS232 port.
> > >
> > > As for the video, it runs continuously and is not subject to control
> > > except for the power supply.
> > >
> > > > As a quick hack, you can create an I2C driver for your video source
> > > > that doesn't access the device and just returns fixed format and frame
> > > > size.
> > > >
> > > > The correct fix is to implement support for platform subdevs in the
> > > > V4L2 core.
> > >
> > > Yes, I wrote a simple driver, now it looks like this:
> > >
> > > [2.029754] Linux media interface: v0.10
> > > [2.034851] Linux video capture interface: v2.00
> > > [2.041015] My_probe I2C subdev probed
[snip]
> > > [2.047058] omap3isp omap3isp: Revision 2.0 found
> > > [2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> > > [2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21
> > > -16)
> >
> > Make sure you don't already have an I2C device at address 0x21 on the same
> > bus.
[snip]
> Here is my platform device registration
>
> #define SENSOR_I2C_BUS_NUM3
>
> static struct i2c_board_info __initdata camera_i2c_devices[] = {
> {
> I2C_BOARD_INFO("my-te", 0x21),
> },
> };
>
> static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
> {
> .board_info = &camera_i2c_devices[0],
> .i2c_adapter_id = SENSOR_I2C_BUS_NUM,
> },
> { NULL, 0, },
> };
>
> static struct isp_v4l2_subdevs_group camera_subdevs[] = {
> {
> .subdevs = camera_i2c_subdevs,
> .interface = ISP_INTERFACE_PARALLEL,
> .bus = {
> .parallel = {
> .data_lane_shift = 1,
> .clk_pol = 0,
> .hs_pol = 0,
> .vs_pol = 0,
> .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
> }
> },
> },
> {},
> };
>
> static struct isp_platform_data isp_platform_data = {
> .subdevs = camera_subdevs,
> };
>
> int __init camera_init(void)
> {
> omap_register_i2c_bus(3,camera_i2c_devices,ARRAY_SIZE(camera_i2c_devices))
> ;
Doesn't omap_register_i2c_bus() take 4 arguments ?
Anyway, you must not register the I2C devices here, they will be registered by
the OMAP3 ISP driver. You still need to register the bus though, with the last
two arguments sets to NULL, 0.
> return omap3_init_camera(&isp_platform_data);
> }
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6250 (20110629) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6250 (20110629) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
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: FW: OMAP 3 ISP
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, June 29, 2011 6:55 PM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; 'Michael Jones'; 'linux-media@vger.kernel.org';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Alex,
On Wednesday 29 June 2011 15:50:54 Alex Gershgorin wrote:
> On Wednesday, June 29, 2011 2:33 PM Laurent Pinchart wrote:
> > On Wednesday 29 June 2011 13:18:10 Alex Gershgorin wrote:
> > >
> > > From previous correspondence:
> > >
> > > My video source is not the video camera and performs many other
> > > functions.
> > >
> > > For this purpose I have RS232 port.
> > >
> > > As for the video, it runs continuously and is not subject to control
> > > except for the power supply.
> > >
> > > > As a quick hack, you can create an I2C driver for your video source
> > > > that doesn't access the device and just returns fixed format and frame
> > > > size.
> > > >
> > > > The correct fix is to implement support for platform subdevs in the
> > > > V4L2 core.
> > >
> > > Yes, I wrote a simple driver, now it looks like this:
> > >
> > > [2.029754] Linux media interface: v0.10
> > > [2.034851] Linux video capture interface: v2.00
> > > [2.041015] My_probe I2C subdev probed
[snip]
> > > [2.047058] omap3isp omap3isp: Revision 2.0 found
> > > [2.052307] omap-iommu omap-iommu.0: isp: version 1.1
> > > [2.069854] i2c i2c-3: Failed to register i2c client my-te at 0x21
> > > -16)
> >
> > Make sure you don't already have an I2C device at address 0x21 on the same
> > bus.
[snip]
> Here is my platform device registration
>
> #define SENSOR_I2C_BUS_NUM3
>
> static struct i2c_board_info __initdata camera_i2c_devices[] = {
> {
> I2C_BOARD_INFO("my-te", 0x21),
> },
> };
>
> static struct isp_subdev_i2c_board_info camera_i2c_subdevs[] = {
> {
> .board_info = &camera_i2c_devices[0],
> .i2c_adapter_id = SENSOR_I2C_BUS_NUM,
> },
> { NULL, 0, },
> };
>
> static struct isp_v4l2_subdevs_group camera_subdevs[] = {
> {
> .subdevs = camera_i2c_subdevs,
> .interface = ISP_INTERFACE_PARALLEL,
> .bus = {
> .parallel = {
> .data_lane_shift = 1,
> .clk_pol = 0,
> .hs_pol = 0,
> .vs_pol = 0,
> .bridge = ISPCTRL_PAR_BRIDGE_DISABLE,
> }
> },
> },
> {},
> };
>
> static struct isp_platform_data isp_platform_data = {
> .subdevs = camera_subdevs,
> };
>
> int __init camera_init(void)
> {
> omap_register_i2c_bus(3,camera_i2c_devices,ARRAY_SIZE(camera_i2c_devices))
> ;
Doesn't omap_register_i2c_bus() take 4 arguments ?
Anyway, you must not register the I2C devices here, they will be registered by
the OMAP3 ISP driver. You still need to register the bus though, with the last
two arguments sets to NULL, 0.
> return omap3_init_camera(&isp_platform_data);
> }
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6250 (20110629) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6250 (20110629) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
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: FW: OMAP 3 ISP
Hi Laurent, I recently got the Zoom OMAP35xx Torpedo and began testing OMAP3ISP. Currently I have a problem I can't solve. See Message from booting Kernel: Linux media interface: v0.10 Linux video capture interface: v2.00 omap3isp omap3isp: Revision 2.0 found omap-iommu omap-iommu.0: isp: version 1.1 isp_register_subdev_group: Unable to register subdev What could be the problem, why sub device can't pass a registration? Thanks, Alex Gershgorin -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, May 25, 2011 1:02 PM To: Alex Gershgorin Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP Hi Alex, On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote: > Hi Laurent, > > Unfortunately, at this point I have no Hardware platforms, but in the > next week we should get Zoom OMAP35 Torpedo evaluation kit > and then I can test it. > > I have already applied this patch on the last main line > Kernel version (2.6.39) and continue to work on the platform device for > Zoom OMAP35xx Torpedo. > > Thanks for this patch :-) You're welcome. Please let me know if it works for you when you'll receive the hardware. I will then push the patch to mainline. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6245 (20110627) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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: FW: OMAP 3 ISP
Of course, in any case, you'll be the first who will know the results :-) Regards, Alex Gershgorin -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Wednesday, May 25, 2011 1:02 PM To: Alex Gershgorin Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org'; 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP Hi Alex, On Wednesday 25 May 2011 11:58:58 Alex Gershgorin wrote: > Hi Laurent, > > Unfortunately, at this point I have no Hardware platforms, but in the > next week we should get Zoom OMAP35 Torpedo evaluation kit > and then I can test it. > > I have already applied this patch on the last main line > Kernel version (2.6.39) and continue to work on the platform device for > Zoom OMAP35xx Torpedo. > > Thanks for this patch :-) You're welcome. Please let me know if it works for you when you'll receive the hardware. I will then push the patch to mainline. -- Regards, Laurent Pinchart __ Information from ESET NOD32 Antivirus, version of virus signature database 6149 (20110524) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6150 (20110525) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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: FW: OMAP 3 ISP
Hi Laurent,
Unfortunately, at this point I have no Hardware platforms, but in the
next week we should get Zoom OMAP35 Torpedo evaluation kit
and then I can test it.
I have already applied this patch on the last main line
Kernel version (2.6.39) and continue to work on the platform device for Zoom
OMAP35xx Torpedo.
Thanks for this patch :-)
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, May 25, 2011 10:22 AM
To: Alex Gershgorin
Cc: 'Sakari Ailus'; Michael Jones; 'linux-media@vger.kernel.org';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Alex,
On Tuesday 24 May 2011 16:11:16 Alex Gershgorin wrote:
> Hi All,
>
> I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and
> size. I do not understand who reads these parameters, user application
> through IOCTL or OMAP3 ISP driver uses them regardless of the user space
> application?
Both. media-ctl (and other userspace applications) can use them, and the OMAP3
ISP driver retrieves them when starting the video stream to make sure that the
formats at the "sensor" output and at the CCDC input match.
> Another question, if I need to change polarity of Vertical or Horizontal
> synchronization signals, according struct isp_parallel_platform_data, is
> it not possible?
>
> struct isp_parallel_platform_data {
> unsigned int data_lane_shift:2;
> unsigned int clk_pol:1;
> unsigned int bridge:4;
> };
Could you please try the following patch ?
>From 7f8eff25e63880a93bc283cd97840227cd092622 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart
Date: Wed, 25 May 2011 09:16:28 +0200
Subject: [PATCH] omap3isp: Support configurable HS/VS polarities
Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/omap3isp/isp.h |6 ++
drivers/media/video/omap3isp/ispccdc.c |4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 2620c40..529e582 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -139,6 +139,10 @@ struct isp_reg {
* 3 - CAMEXT[13:6] -> CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
+ * @hs_pol: Horizontal synchronization polarity
+ * 0 - Active high, 1 - Active low
+ * @vs_pol: Vertical synchronization polarity
+ * 0 - Active high, 1 - Active low
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
@@ -147,6 +151,8 @@ struct isp_reg {
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
+ unsigned int hs_pol:1;
+ unsigned int vs_pol:1;
unsigned int bridge:4;
};
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..5e742b2 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1148,6 +1148,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
omap3isp_configure_bridge(isp, ccdc->input, pdata, shift);
ccdc->syncif.datsz = depth_out;
+ ccdc->syncif.hdpol = pdata ? pdata-> hs_pol : 0;
+ ccdc->syncif.vdpol = pdata ? pdata-> vs_pol : 0;
ccdc_config_sync_if(ccdc, &ccdc->syncif);
/* CCDC_PAD_SINK */
@@ -2257,8 +2259,6 @@ int omap3isp_ccdc_init(struct isp_device *isp)
ccdc->syncif.fldout = 0;
ccdc->syncif.fldpol = 0;
ccdc->syncif.fldstat = 0;
- ccdc->syncif.hdpol = 0;
- ccdc->syncif.vdpol = 0;
ccdc->clamp.oblen = 0;
ccdc->clamp.dcsubval = 0;
--
1.7.3.4
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6149 (20110524) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6149 (20110524) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
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: FW: OMAP 3 ISP
Hi All,
I wrote a simple V4L2 subdevs I2C driver which returns a fixed format and size.
I do not understand who reads these parameters, user application through IOCTL
or OMAP3 ISP driver uses them regardless of the user space application?
Another question, if I need to change polarity of Vertical or Horizontal
synchronization signals, according struct isp_parallel_platform_data, is it not
possible?
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
Regards,
Alex Gershgorin
-Original Message-
From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
Sent: Thursday, May 19, 2011 6:33 PM
To: Alex Gershgorin
Cc: 'Laurent Pinchart'; Michael Jones; 'linux-media@vger.kernel.org';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
On Thu, May 19, 2011 at 06:13:28PM +0300, Alex Gershgorin wrote:
> Hi Michael,
>
> I liked the idea of a driver that returns fixed format and frame size.
> It certainly could solve my problem.
> On the other hand, from your correspondence to Laurent, I realized that it
> was already done work on improving V4L2 subdevs.
> Michael patch of which you speak will help solve my problem without writing a
> special driver?
> Advise in what direction to go in my case?
Hi Alex,
You still need a driver, but with the patches you can easily implement that
as a driver for a platform device. The driver itself wouldn't have to do
much more than to return a fixed format and size when queried.
>
> Regards,
>
> Alex Gershgorin
>
>
>
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Thursday, May 19, 2011 5:27 PM
> To: Michael Jones
> Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ai...@iki.fi';
> 'age...@rambler.ru'
> Subject: Re: FW: OMAP 3 ISP
>
> Hi Michael,
>
> On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> > On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> > >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> > >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> > >>>> Thanks Laurent,
> > >>>>
> > >>>> My video source is not the video camera and performs many other
> > >>>> functions. For this purpose I have RS232 port.
> > >>>> As for the video, it runs continuously and is not subject to control
> > >>>> except for the power supply.
> > >>>
> > >>> As a quick hack, you can create an I2C driver for your video source
> > >>> that doesn't access the device and just returns fixed format and frame
> > >>> size.
> > >>>
> > >>> The correct fix is to implement support for platform subdevs in the
> > >>> V4L2 core.
> > >>
> > >> I recently implemented support for platform V4L2 subdevs. Now that it
> > >> sounds like others would be interested in this, I will try to polish it
> > >> up and submit the patch for review in the next week or so.
> > >
> > > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > > a couple of pointers, to make sure we're going in the same direction.
> > >
> > > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > > platform or other bus. To achieve that, an abstraction layer must be
> > > provided by the V4L2 core. Here's what I got in one of my trees:
> > >
> > > /* V4L2 core */
> > >
> > > struct v4l2_subdev_i2c_board_info {
> > >
> > > struct i2c_board_info *board_info;
> > > int i2c_adapter_id;
> > >
> > > };
> > >
> > > enum v4l2_subdev_bus_type {
> > >
> > > V4L2_SUBDEV_BUS_TYPE_NONE,
> > > V4L2_SUBDEV_BUS_TYPE_I2C,
> > > V4L2_SUBDEV_BUS_TYPE_SPI,
> > >
> > > };
> > >
> > > struct v4l2_subdev_board_info {
> > >
> > > enum v4l2_subdev_bus_type type;
> > > union {
> > >
> > > struct v4l2_subdev_i2c_board_info i2c;
> > > struct spi_board_info *spi;
> > >
> > > } info;
> > >
> > > };
> > >
> > > /* OMAP3 ISP */
> > >
> > > struct isp_v4l2_subdevs_group {
> > >
> > > struct v4l2_subdev_board_info *subdevs;
> > > enum isp_interface_type
RE: FW: OMAP 3 ISP
Hi Michael,
I liked the idea of a driver that returns fixed format and frame size.
It certainly could solve my problem.
On the other hand, from your correspondence to Laurent, I realized that it was
already done work on improving V4L2 subdevs.
Michael patch of which you speak will help solve my problem without writing a
special driver?
Advise in what direction to go in my case?
Regards,
Alex Gershgorin
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Thursday, May 19, 2011 5:27 PM
To: Michael Jones
Cc: Alex Gershgorin; 'linux-media@vger.kernel.org'; 'sakari.ai...@iki.fi';
'age...@rambler.ru'
Subject: Re: FW: OMAP 3 ISP
Hi Michael,
On Thursday 19 May 2011 16:24:29 Michael Jones wrote:
> On 05/19/2011 03:56 PM, Laurent Pinchart wrote:
> > On Thursday 19 May 2011 15:44:18 Michael Jones wrote:
> >> On 05/19/2011 03:02 PM, Laurent Pinchart wrote:
> >>> On Thursday 19 May 2011 14:51:16 Alex Gershgorin wrote:
> >>>> Thanks Laurent,
> >>>>
> >>>> My video source is not the video camera and performs many other
> >>>> functions. For this purpose I have RS232 port.
> >>>> As for the video, it runs continuously and is not subject to control
> >>>> except for the power supply.
> >>>
> >>> As a quick hack, you can create an I2C driver for your video source
> >>> that doesn't access the device and just returns fixed format and frame
> >>> size.
> >>>
> >>> The correct fix is to implement support for platform subdevs in the
> >>> V4L2 core.
> >>
> >> I recently implemented support for platform V4L2 subdevs. Now that it
> >> sounds like others would be interested in this, I will try to polish it
> >> up and submit the patch for review in the next week or so.
> >
> > Great. This has been discussed during the V4L meeting in Warsaw, here are
> > a couple of pointers, to make sure we're going in the same direction.
> >
> > Bridge drivers should not care whether the subdev sits on an I2C, SPI,
> > platform or other bus. To achieve that, an abstraction layer must be
> > provided by the V4L2 core. Here's what I got in one of my trees:
> >
> > /* V4L2 core */
> >
> > struct v4l2_subdev_i2c_board_info {
> >
> > struct i2c_board_info *board_info;
> > int i2c_adapter_id;
> >
> > };
> >
> > enum v4l2_subdev_bus_type {
> >
> > V4L2_SUBDEV_BUS_TYPE_NONE,
> > V4L2_SUBDEV_BUS_TYPE_I2C,
> > V4L2_SUBDEV_BUS_TYPE_SPI,
> >
> > };
> >
> > struct v4l2_subdev_board_info {
> >
> > enum v4l2_subdev_bus_type type;
> > union {
> >
> > struct v4l2_subdev_i2c_board_info i2c;
> > struct spi_board_info *spi;
> >
> > } info;
> >
> > };
> >
> > /* OMAP3 ISP */
> >
> > struct isp_v4l2_subdevs_group {
> >
> > struct v4l2_subdev_board_info *subdevs;
> > enum isp_interface_type interface;
> > union {
> >
> > struct isp_parallel_platform_data parallel;
> > struct isp_ccp2_platform_data ccp2;
> > struct isp_csi2_platform_data csi2;
> >
> > } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
> >
> > };
> >
> > struct isp_platform_data {
> >
> > struct isp_v4l2_subdevs_group *subdevs;
> >
> > };
> >
> > The V4L2 core would need to provide a function to register a subdev based
> > on a v4l2_subdev_board_info structure.
> >
> > Is that in line with what you've done ? I can provide a patch that
> > implements this for I2C and SPI, and let you add platform subdevs if
> > that can help you.
>
> Hi Laurent,
>
> Yes, that looks very similar to what I've done. I was going to submit
> SPI support, too, which I also have, but it sounds like you've already
> done that? I'm currently still using a 2.6.38 tree based on an older
> media branch of yours, so I'm not familiar with any new changes there yet.
>
> I just need to know what I should use as my baseline.
Please use mainline, now that the OMAP3 ISP driver has been merged :-)
> I don't need to step on toes and submit something you've already done, so
> maybe you want to point me to a branch with the SPI stuff, and I'll just put
> the platform stuff on top of it?
I'll send the SPI support patches to linux-media, as they haven't been
reviewed publicly yet.
--
Regards,
Laurent Pinchart
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
__ Information from ESET NOD32 Antivirus, version of virus signature
database 6135 (20110519) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
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: FW: OMAP 3 ISP
Thanks Laurent, My video source is not the video camera and performs many other functions. For this purpose I have RS232 port. As for the video, it runs continuously and is not subject to control except for the power supply. Regards, Alex Gershgorin Can the video source be controlled at all, or is it always running? If it can be controlled, how do you control it? Regards, Laurent Pinchart -Original Message- From: Alex Gershgorin Sent: Thursday, May 19, 2011 2:36 PM To: 'linux-media@vger.kernel.org' Cc: 'sakari.ai...@iki.fi'; 'laurent.pinch...@ideasonboard.com'; 'age...@rambler.ru' Subject: FW: FW: OMAP 3 ISP Thanks for your quick response :-) Unfortunately, my video source has no additional interfaces. Best Regards, Alex Gershgorin Embedded Software Engineer E-mail: al...@meprolight.com -Original Message- From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Thursday, May 19, 2011 2:09 PM To: Alex Gershgorin Cc: 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote: > > > > > Hi Sakari, Hi Alex, > > > We wish to develop video device and use omap3530. > > Our video source has an 8-bit raw data, vertical and horizontal signals, > and has no i2c bus. > > I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP) > and found, that > > to register video device I need to provide I2C subdevs board information > array, but my device does not have i2c information. > > I'm asking for your support on this issue. Does your image data source have some other kind of control interface, possibly SPI? Please reply to linux-media@vger.kernel.org and cc myself and laurent.pinch...@ideasonboard.com. Regards, -- Sakari Ailus sakari dot ailus at iki dot fi __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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
FW: FW: OMAP 3 ISP
Thanks for your quick response :-) Unfortunately, my video source has no additional interfaces. Best Regards, Alex Gershgorin Embedded Software Engineer E-mail: al...@meprolight.com -Original Message- From: Sakari Ailus [mailto:sakari.ai...@iki.fi] Sent: Thursday, May 19, 2011 2:09 PM To: Alex Gershgorin Cc: 'age...@rambler.ru' Subject: Re: FW: OMAP 3 ISP On Thu, May 19, 2011 at 12:08:41PM +0300, Alex Gershgorin wrote: > > > > > Hi Sakari, Hi Alex, > > > We wish to develop video device and use omap3530. > > Our video source has an 8-bit raw data, vertical and horizontal signals, > and has no i2c bus. > > I was briefly acquainted with Linux OMAP 3 Image Signal Processor (ISP) > and found, that > > to register video device I need to provide I2C subdevs board information > array, but my device does not have i2c information. > > I'm asking for your support on this issue. Does your image data source have some other kind of control interface, possibly SPI? Please reply to linux-media@vger.kernel.org and cc myself and laurent.pinch...@ideasonboard.com. Regards, -- Sakari Ailus sakari dot ailus at iki dot fi __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6134 (20110519) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- 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
