RE: [PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi Guennadi,
When I'm refining the patch based on your comments, I met an issue. Could you
please help me?
[snip]
-
/*
* Configure the controller for operation; caller holds the
* device mutex.
@@ -979,11 +1070,32 @@ static void mcam_vb_buf_queue(struct vb2_buffer
*vb) {
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+ struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
+ dma_addr_t dma_handle;
+ u32 base_size = fmt-width * fmt-height;
Shouldn't you be just using bytesperline? Is stride != width * height
supported?
We will update it.
[Libin] What I understand is width is the pixel number perline, so bytesperline
= width * BytePerPixel. This means bytesperline should include Y data and UV
data.
For example, for yuv420 legacy 8-bit, it transfers like below:
U Y Y U Y Y U Y Y U Y Y ..
V Y Y V Y Y V Y Y V Y Y ..
As each Y is one byte, so all Y data length is nuber_Y_per_line * height. While
the nuber_Y_per_line is the pixel_per_line, which is fmt-width.
So for the planner, the first block is saving the Y data, whose length is
nuber_Y_per_line * height, which equals to fmt-width * height.
Do I understand correctly?
The base_size here means the size of Y data, so it should be fmt-width *
fmt-height.
spin_lock_irqsave(cam-dev_lock, flags);
+ dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
Best Regards,
Libin
--
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 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi Libin
On Mon, 3 Dec 2012, Libin Yang wrote:
Hi Guennadi,
When I'm refining the patch based on your comments, I met an issue.
Could you please help me?
[snip]
-
/*
* Configure the controller for operation; caller holds the
* device mutex.
@@ -979,11 +1070,32 @@ static void mcam_vb_buf_queue(struct vb2_buffer
*vb) {
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+ struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
+ dma_addr_t dma_handle;
+ u32 base_size = fmt-width * fmt-height;
Shouldn't you be just using bytesperline? Is stride != width * height
supported?
We will update it.
[Libin] What I understand is width is the pixel number perline, so
bytesperline = width * BytePerPixel. This means bytesperline should
include Y data and UV data.
For example, for yuv420 legacy 8-bit, it transfers like below:
U Y Y U Y Y U Y Y U Y Y ..
V Y Y V Y Y V Y Y V Y Y ..
As each Y is one byte, so all Y data length is nuber_Y_per_line *
height. While the nuber_Y_per_line is the pixel_per_line, which is
fmt-width.
So for the planner, the first block is saving the Y data, whose length
is nuber_Y_per_line * height, which equals to fmt-width * height.
Do I understand correctly?
The base_size here means the size of Y data, so it should be fmt-width
* fmt-height.
Right, in this case you're right. Sorry for a misleading comment. Just a
suggestion, if you prefer, you can keep the name, but maybe a name like
pixel_count or pixel_num or pixel_per_frame would be clearer for that
variable? But keeping the name is also ok with me.
spin_lock_irqsave(cam-dev_lock, flags);
+ dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi Guennadi,
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, December 04, 2012 2:57 PM
To: Libin Yang
Cc: cor...@lwn.net; linux-media@vger.kernel.org
Subject: RE: [PATCH 06/15] [media] marvell-ccic: add new formats support for
marvell-ccic
driver
Hi Libin
On Mon, 3 Dec 2012, Libin Yang wrote:
Hi Guennadi,
When I'm refining the patch based on your comments, I met an issue.
Could you please help me?
[snip]
-
/*
* Configure the controller for operation; caller holds the
* device mutex.
@@ -979,11 +1070,32 @@ static void mcam_vb_buf_queue(struct vb2_buffer
*vb) {
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
+dma_addr_t dma_handle;
+u32 base_size = fmt-width * fmt-height;
Shouldn't you be just using bytesperline? Is stride != width * height
supported?
We will update it.
[Libin] What I understand is width is the pixel number perline, so
bytesperline = width * BytePerPixel. This means bytesperline should
include Y data and UV data.
For example, for yuv420 legacy 8-bit, it transfers like below:
U Y Y U Y Y U Y Y U Y Y ..
V Y Y V Y Y V Y Y V Y Y ..
As each Y is one byte, so all Y data length is nuber_Y_per_line *
height. While the nuber_Y_per_line is the pixel_per_line, which is
fmt-width.
So for the planner, the first block is saving the Y data, whose length
is nuber_Y_per_line * height, which equals to fmt-width * height.
Do I understand correctly?
The base_size here means the size of Y data, so it should be fmt-width
* fmt-height.
Right, in this case you're right. Sorry for a misleading comment. Just a
suggestion, if you prefer, you can keep the name, but maybe a name like
pixel_count or pixel_num or pixel_per_frame would be clearer for that
variable? But keeping the name is also ok with me.
[Libin] OK, I see. Thanks for your suggestion. The name really seems a little
misleading. I will use a more reasonable name in the coming patch.
spin_lock_irqsave(cam-dev_lock, flags);
+dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
Regards,
Libin
--
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 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
On Fri, 23 Nov 2012, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 178
++-
drivers/media/platform/marvell-ccic/mcam-core.h |6 +
2 files changed, 151 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 67d4f2f..c9f7250 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -110,6 +110,30 @@ static struct mcam_format_struct {
.bpp= 2,
},
{
+ .desc = UYVY 4:2:2,
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:2 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV422P,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YUV 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YUV420,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_1_5X8,
+ .bpp= 2,
+ },
+ {
+ .desc = YVU 4:2:0 PLANAR,
+ .pixelformat= V4L2_PIX_FMT_YVU420,
+ .mbus_code = V4L2_MBUS_FMT_YVYU8_1_5X8,
+ .bpp= 2,
+ },
+ {
.desc = RGB 444,
.pixelformat= V4L2_PIX_FMT_RGB444,
.mbus_code = V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE,
@@ -168,6 +192,12 @@ struct mcam_dma_desc {
u32 segment_len;
};
+struct yuv_pointer_t {
+ dma_addr_t y;
+ dma_addr_t u;
+ dma_addr_t v;
+};
+
/*
* Our buffer type for working with videobuf2. Note that the vb2
* developers have decreed that struct vb2_buffer must be at the
@@ -179,6 +209,7 @@ struct mcam_vb_buffer {
struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
dma_addr_t dma_desc_pa; /* Descriptor physical address */
int dma_desc_nent; /* Number of mapped descriptors */
+ struct yuv_pointer_t yuv_p;
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
@@ -465,6 +496,18 @@ static inline int mcam_check_dma_buffers(struct
mcam_camera *cam)
/*
* DMA-contiguous code.
*/
+
+static bool mcam_fmt_is_planar(__u32 pfmt)
+{
+ switch (pfmt) {
+ case V4L2_PIX_FMT_YUV422P:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ return true;
+ }
+ return false;
+}
+
/*
* Set up a contiguous buffer for the given frame. Here also is where
* the underrun strategy is set: if there is no buffer available, reuse
@@ -476,6 +519,8 @@ static inline int mcam_check_dma_buffers(struct
mcam_camera *cam)
static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
{
struct mcam_vb_buffer *buf;
+ struct v4l2_pix_format *fmt = cam-pix_format;
+
/*
* If there are no available buffers, go into single mode
*/
@@ -494,8 +539,13 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
}
cam-vb_bufs[frame] = buf;
- mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
+ mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR, buf-yuv_p.y);
+ if (mcam_fmt_is_planar(fmt-pixelformat)) {
+ mcam_reg_write(cam, frame == 0 ?
+ REG_U0BAR : REG_U1BAR, buf-yuv_p.u);
+ mcam_reg_write(cam, frame == 0 ?
+ REG_V0BAR : REG_V1BAR, buf-yuv_p.v);
+ }
}
/*
@@ -653,49 +703,91 @@ static inline void mcam_sg_restart(struct mcam_camera
*cam)
*/
static void mcam_ctlr_image(struct mcam_camera *cam)
{
- int imgsz;
struct v4l2_pix_format *fmt = cam-pix_format;
+ u32 widthy = 0, widthuv = 0, imgsz_h, imgsz_w;
+
+ cam_dbg(cam, camera: bytesperline = %d; height = %d\n,
+ fmt-bytesperline, fmt-sizeimage / fmt-bytesperline);
+ imgsz_h = (fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK;
+ imgsz_w = fmt-bytesperline IMGSZ_H_MASK;
+
+ if (fmt-pixelformat == V4L2_PIX_FMT_YUV420
+ || fmt-pixelformat == V4L2_PIX_FMT_YVU420)
+ imgsz_w = (fmt-bytesperline * 4 / 3) IMGSZ_H_MASK;
+ else if (fmt-pixelformat == V4L2_PIX_FMT_JPEG)
+ imgsz_h = (fmt-sizeimage / fmt-bytesperline) IMGSZ_V_SHIFT;
+
+ switch (fmt-pixelformat) {
+ case V4L2_PIX_FMT_YUYV:
+ case V4L2_PIX_FMT_UYVY:
+
RE: [PATCH 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Thanks
Albert Wang
86-21-61092656
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, 27 November, 2012 19:45
To: Albert Wang
Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH 06/15] [media] marvell-ccic: add new formats support for
marvell-ccic
driver
On Fri, 23 Nov 2012, Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 178
++-
drivers/media/platform/marvell-ccic/mcam-core.h |6 +
2 files changed, 151 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 67d4f2f..c9f7250 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -110,6 +110,30 @@ static struct mcam_format_struct {
.bpp= 2,
},
{
+.desc = UYVY 4:2:2,
+.pixelformat= V4L2_PIX_FMT_UYVY,
+.mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+.bpp= 2,
+},
+{
+.desc = YUV 4:2:2 PLANAR,
+.pixelformat= V4L2_PIX_FMT_YUV422P,
+.mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+.bpp= 2,
+},
+{
+.desc = YUV 4:2:0 PLANAR,
+.pixelformat= V4L2_PIX_FMT_YUV420,
+.mbus_code = V4L2_MBUS_FMT_YUYV8_1_5X8,
+.bpp= 2,
+},
+{
+.desc = YVU 4:2:0 PLANAR,
+.pixelformat= V4L2_PIX_FMT_YVU420,
+.mbus_code = V4L2_MBUS_FMT_YVYU8_1_5X8,
+.bpp= 2,
+},
+{
.desc = RGB 444,
.pixelformat= V4L2_PIX_FMT_RGB444,
.mbus_code = V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE,
@@ -168,6 +192,12 @@ struct mcam_dma_desc {
u32 segment_len;
};
+struct yuv_pointer_t {
+dma_addr_t y;
+dma_addr_t u;
+dma_addr_t v;
+};
+
/*
* Our buffer type for working with videobuf2. Note that the vb2
* developers have decreed that struct vb2_buffer must be at the @@
-179,6 +209,7 @@ struct mcam_vb_buffer {
struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
dma_addr_t dma_desc_pa; /* Descriptor physical address */
int dma_desc_nent; /* Number of mapped descriptors */
+struct yuv_pointer_t yuv_p;
};
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
@@ -465,6 +496,18 @@ static inline int mcam_check_dma_buffers(struct
mcam_camera *cam)
/*
* DMA-contiguous code.
*/
+
+static bool mcam_fmt_is_planar(__u32 pfmt) {
+switch (pfmt) {
+case V4L2_PIX_FMT_YUV422P:
+case V4L2_PIX_FMT_YUV420:
+case V4L2_PIX_FMT_YVU420:
+return true;
+}
+return false;
+}
+
/*
* Set up a contiguous buffer for the given frame. Here also is where
* the underrun strategy is set: if there is no buffer available,
reuse @@ -476,6 +519,8 @@ static inline int
mcam_check_dma_buffers(struct mcam_camera *cam) static void
mcam_set_contig_buffer(struct mcam_camera *cam, int frame) {
struct mcam_vb_buffer *buf;
+struct v4l2_pix_format *fmt = cam-pix_format;
+
/*
* If there are no available buffers, go into single mode
*/
@@ -494,8 +539,13 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam,
int frame)
}
cam-vb_bufs[frame] = buf;
-mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
-vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
+mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR, buf-yuv_p.y);
+if (mcam_fmt_is_planar(fmt-pixelformat)) {
+mcam_reg_write(cam, frame == 0 ?
+REG_U0BAR : REG_U1BAR, buf-yuv_p.u);
+mcam_reg_write(cam, frame == 0 ?
+REG_V0BAR : REG_V1BAR, buf-yuv_p.v);
+}
}
/*
@@ -653,49 +703,91 @@ static inline void mcam_sg_restart(struct mcam_camera
*cam)
*/
static void mcam_ctlr_image(struct mcam_camera *cam) {
-int imgsz;
struct v4l2_pix_format *fmt = cam-pix_format;
+u32 widthy = 0, widthuv = 0, imgsz_h, imgsz_w;
+
+cam_dbg(cam, camera: bytesperline = %d; height = %d\n,
+fmt-bytesperline, fmt-sizeimage / fmt-bytesperline);
+imgsz_h = (fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK;
+imgsz_w = fmt-bytesperline IMGSZ_H_MASK;
+
+if (fmt-pixelformat == V4L2_PIX_FMT_YUV420
+|| fmt-pixelformat == V4L2_PIX_FMT_YVU420)
+imgsz_w = (fmt-bytesperline * 4 / 3
