Re: [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
Hi Javier,
Thanks for the patch.
On Sunday 09 October 2011 04:37:33 Javier Martinez Canillas wrote:
The ITU-R BT.656 standard data format provides interlaced video data.
This patch adds to the ISP CCDC driver the ability to deinterlace the
video data and send progressive frames to user-space applications.
The changes are:
- Maintain two buffers (struct isp_buffer), current and last.
- Decouple next buffer obtaining from last buffer releasing.
- Move most of the logic to the VD1 interrupt handler since the
ISP is not busy there.
Could you please explain why this is needed ?
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 195
++-- drivers/media/video/omap3isp/ispccdc.h |
6 +
include/media/omap3isp.h |3 +
3 files changed, 146 insertions(+), 58 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c index c25db54..fff1ae1 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,7 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -893,7 +894,7 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc, ISPCCDC_SDOFST_FINV);
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
+ ISPCCDC_SDOFST_FOFST_1L);
Are you sure this is needed ? isp_reg_clr() clears the bits (which are as far
as I see not set anyway).
switch (oddeven) {
case EVENEVEN:
@@ -1010,6 +1011,9 @@ static void ccdc_config_sync_if(struct
isp_ccdc_device *ccdc, if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
Addition and usage of the fldmode field can be split to a patch of its own.
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1119,10 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1193,44 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) }
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ if (pdata-bt656) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3 - 1;
+ nph = format-width * 2 - 1;
Isn't this applicable to interlaced non-BT.656 modes as well ? Same for the
other bt656 checks you introduce below.
+ } else {
+ vd0 = nlv = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ nph = format-width - 1;
+ }
+
/* Generate VD0 on the last line of the image and VD1 on the
* 2/3 height line.
*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
-((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+(vd1 ISPCCDC_VDINT_1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
-((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+(nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
+ isp_reg_writel(isp, nlv ISPCCDC_VERT_LINES_NLV_SHIFT,
+OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV0_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- isp_reg_writel(isp, (format-height - 1)
- ISPCCDC_VERT_LINES_NLV_SHIFT,
-OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
+ isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV1_SHIFT,
+OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
+
+ if (pdata-bt656) {
+ ccdc_config_outlineoffset(ccdc, nph, EVENEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, EVENODD, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDODD, 1);
+ } else
+
[PATCH 1/1] update az6027 firmware URL
From: Renzo Dani aro...@gmail.com
Signed-off-by: Renzo Dani aro...@gmail.com
---
Documentation/dvb/get_dvb_firmware | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index c466f58..06456d0 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -575,19 +575,10 @@ sub ngene {
}
sub az6027{
-my $file = AZ6027_Linux_Driver.tar.gz;
-my $url = http://linux.terratec.de/files/$file;;
my $firmware = dvb-usb-az6027-03.fw;
+my $url = http://linux.terratec.de/files/TERRATEC_S7/$firmware;;
-wgetfile($file, $url);
-
-#untar
-if( system(tar xzvf $file $firmware)){
-die failed to untar firmware;
-}
-if( system(rm $file)){
-die (unable to remove unnecessary files);
-}
+wgetfile($firmware, $url);
$firmware;
}
--
1.7.3.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 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 12:02 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Thanks for the patch.
Hi Laurent, I'm so glad that you are providing feedback on this :)
On Sunday 09 October 2011 04:37:33 Javier Martinez Canillas wrote:
The ITU-R BT.656 standard data format provides interlaced video data.
This patch adds to the ISP CCDC driver the ability to deinterlace the
video data and send progressive frames to user-space applications.
The changes are:
- Maintain two buffers (struct isp_buffer), current and last.
- Decouple next buffer obtaining from last buffer releasing.
- Move most of the logic to the VD1 interrupt handler since the
ISP is not busy there.
Could you please explain why this is needed ?
Well, reading the TRM I came to the conclusion (I may be wrong with
this assumption) that it is not correct to do the buffer management
for the CCDC on the VD0 interrupt handler. Since by the time you are
processing the end of frame interrupt handler a new frame has already
started.
The ISP shadowed registers values can't be updated there because the
values written to them will not take effect until the start of the
next frame. But since a new frame has already started, by the time we
are setting for example the CCDC_SDR_ADDR register, this means that
the frame already being processed will use the last value and not the
one we expect it to use.
For me, made more sense to move all the buffer management code to the
VD1 interrupt handler. Since this occurs before a frame ends, if we
update there the shadowed registers, the values will take effect when
the next frame starts.
But you can't release the las buffer yet, since the ISP is still
processing the frame and copying to memory. We have to release the
last buffer (and wake the pending process) either on the VD0 handler
when the frame processing finish or during the VD1 handler when the
next frame has already started.
This means that the next buffer obtaining and the last buffer
releasing occur at different moment. So, we have to decouple these two
actions.
I hope I made myself clear with this. Am I right or completely lost with this?
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 195
++-- drivers/media/video/omap3isp/ispccdc.h |
6 +
include/media/omap3isp.h | 3 +
3 files changed, 146 insertions(+), 58 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c index c25db54..fff1ae1 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,7 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -893,7 +894,7 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc, ISPCCDC_SDOFST_FINV);
isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
+ ISPCCDC_SDOFST_FOFST_1L);
Are you sure this is needed ? isp_reg_clr() clears the bits (which are as far
as I see not set anyway).
The value 0x0 on the FOFST field configures the line offset value to
+1. But looking at the TRM now this is the default value so you are
right, this is not needed and I'll remove it.
switch (oddeven) {
case EVENEVEN:
@@ -1010,6 +1011,9 @@ static void ccdc_config_sync_if(struct
isp_ccdc_device *ccdc, if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
Addition and usage of the fldmode field can be split to a patch of its own.
Ok, will do.
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1119,10 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1193,44 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) }
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ if (pdata-bt656) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3 - 1;
+ nph = format-width * 2 - 1;
Isn't this applicable to interlaced non-BT.656 modes as well ? Same for the
other bt656 checks you introduce below.
You are right, I will check pdata-fldmode instead. The only one that
is BT.656 specific is width * 2
Re: Stream degrades when going through CAM
Roger Mårtensson skrev 2011-10-08 12:32: Hej(Hello)! The hardware I got is a mystique DVB-C Card but it seems to a KNC1 TV-Station MK3 clone. 08:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) Subsystem: KNC One Device [1894:0028] Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at fbeffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av The CAM is a SMIT CONAX. Kernel Used: 2.6.38(2.6.38-11-generic. Ubuntu 11.04 SMP) Drivers tested: from latest media_build git I noticed now that my board seems to be using a tda10024. It's wired the same as a tda10023 in the code so it seems compatible to 10023? Whenever I insert the cam and starts a capture I get this error in the dmesg: [8.019398] budget_av: cam inserted A [8.689753] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 15.061237] eth0: no IPv6 routers present [ 92.831735] budget_av: cam inserted A [ 92.832713] DVB: TDA10023(0): tda10023_writereg, writereg error (reg == 0x2a, val == 0x02, ret == -121) [ 93.499511] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 161.695810] budget_av: cam ejected 5 This is after a reboot and one capture with gnutv. If I unplug the CAM the error does not show. Can it be related to the corrupt mpg-stream I see whenever the CAM is inserted? -- 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 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 12:02 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Laurent, apart from the specific comments on Javier code, did you have a look at Deepthy patches too? I say this because asking Javier for fixes means (to me) that you are going to merge his patches (if testing will confirm it works of course). Am i wrong? Btw i'm trying to get these patches on 3.1.0rc9 (from igep repository, that should be just like mainline 3.1.0rc9 with some bsp patches), i hope i will report good news. Enrico -- 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 0/2] Add support to ITU-R BT.656 video data format
Hello folks, This is a v2 patch-set that aims to add support to the ISP CCDC driver to process video in interlaced mode. The patch-set contains the following patches: [PATCH v2 1/3] omap3isp: ccdc: Add interlaced field mode to platform data [PATCH v2 2/3] omap3isp: ccdc: Add interlaced count field to isp_ccdc_device [PATCH v2 3/3] omap3isp: ccdc: Add support to ITU-R BT.656 video data format This is based on one of the earlier changes we made. This doesn't move the buffer management logic to the VD1 interrupt handler so is less intrusive than v1 patch-set. Also, based on Laurent's comments I check not if we are in BT.656 but if the ISP CCDC is configured to operate in interlaced mode (fldmode == 1). Again, this patch-set is a proof-of-concept and was only compile tested since I don't have the hardware to test right now. It is a forward porting, on top of Laurent's omap3isp-omap3isp-yuv tree, of the changes we made to the ISP driver to get interlaced video working. And this is one of the earlier changes we made. It is not intended to be merged, I'm posting here only for review and feedback. Best regards, -- 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 1/3] omap3isp: ccdc: Add interlaced field mode to platform data
The fldmode field from the CCDC_SYN_MODE register configure the ISP CCDC
between progresive and interlaced mode.
Adding this field to the platform data, allows boards to configure accordingly.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
include/media/omap3isp.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 3b2d2b7..0f215de 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -61,6 +61,8 @@ enum {
* 0 - Normal, 1 - One's complement
* @bt656: ITU-R BT656 embedded synchronization
* 0 - HS/VS sync, 1 - BT656 sync
+ * @fldmode: Field mode
+ * 0 - progressive, 1 - Interlaced
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
@@ -69,6 +71,7 @@ struct isp_parallel_platform_data {
unsigned int vs_pol:1;
unsigned int data_pol:1;
unsigned int bt656:1;
+ unsigned int fldmode:1;
};
enum {
--
1.7.4.1
--
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 2/3] omap3isp: ccdc: Add interlaced count field to isp_ccdc_device
When configured in interlaced field mode, the ISP CCDC has to know which
sub-frame of the current frame is processing.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.h
b/drivers/media/video/omap3isp/ispccdc.h
index 54811ce..8863eea 100644
--- a/drivers/media/video/omap3isp/ispccdc.h
+++ b/drivers/media/video/omap3isp/ispccdc.h
@@ -134,6 +134,7 @@ struct ispccdc_lsc {
* @wait: Wait queue used to stop the module
* @stopping: Stopping state
* @ioctl_lock: Serializes ioctl calls and LSC requests freeing
+ * @interlaced_cnt: Sub-frame count for an interlaced video frame
*/
struct isp_ccdc_device {
struct v4l2_subdev subdev;
@@ -164,6 +165,7 @@ struct isp_ccdc_device {
wait_queue_head_t wait;
unsigned int stopping;
struct mutex ioctl_lock;
+ unsigned int interlaced_cnt;
};
struct isp_device;
--
1.7.4.1
--
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 3/3] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
This patch adds to the ISP CCDC driver the ability to deinterlace video
data when configured in interlaced mode and send progressive frames to
user-space V4L2 applications.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 104 ++--
1 files changed, 85 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index c25db54..7907081 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,8 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+static bool ccdc_input_is_fldmode(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -889,12 +891,6 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc,
isp_reg_writel(isp, offset 0x,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HSIZE_OFF);
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FINV);
-
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
-
switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
@@ -1010,6 +1006,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1114,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1188,49 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
}
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ /* In BT.656 a pixel is representd using two bytes */
+ if (pdata-bt656)
+ nph = format-width * 2 - 1;
+ else
+ nph = format-width - 1;
+
+ /* In interlaced mode a frame is composed fo two subrames */
+ if (pdata-fldmode) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3;
+ } else {
+ vd0 = nlv = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ }
+
/* Generate VD0 on the last line of the image and VD1 on the
* 2/3 height line.
*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+ (vd1 ISPCCDC_VDINT_1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
- ((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+ (nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV0_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- isp_reg_writel(isp, (format-height - 1)
-ISPCCDC_VERT_LINES_NLV_SHIFT,
+ isp_reg_writel(isp, nlv ISPCCDC_VERT_LINES_NLV_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
+ isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV1_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
+
+ if (pdata-fldmode) {
+ ccdc_config_outlineoffset(ccdc, nph, EVENEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, EVENODD, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDODD, 1);
+ } else
+ ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0,
0);
/* CCDC_PAD_SOURCE_VP */
format = ccdc-formats[CCDC_PAD_SOURCE_VP];
@@ -1495,10 +1521,30 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
goto done;
}
- buffer = omap3isp_video_buffer_next(ccdc-video_out, ccdc-error);
- if (buffer != NULL) {
-
Re: [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 2:58 PM, Enrico ebut...@users.berlios.de wrote: On Sun, Oct 9, 2011 at 12:02 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Laurent, apart from the specific comments on Javier code, did you have a look at Deepthy patches too? I say this because asking Javier for fixes means (to me) that you are going to merge his patches (if testing will confirm it works of course). Am i wrong? I don't think these patches are in merge-able state because I only compile tested. Now based on Laurent's comments I just sent a v2 patch-set based in one of our earlier changes. This was before we decide to move the logic to VD1 so the patch-set is less intrusive and will be easier to review. Also, now I check for fldmode not bt656, Laurent's is right that bt.656 is interlaced but not every interlaced video is bt.656. Btw i'm trying to get these patches on 3.1.0rc9 (from igep repository, that should be just like mainline 3.1.0rc9 with some bsp patches), i hope i will report good news. Enrico Great, thank you very much for your efforts Enrico. Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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 v2 3/3] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 3:26 PM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
This patch adds to the ISP CCDC driver the ability to deinterlace video
data when configured in interlaced mode and send progressive frames to
user-space V4L2 applications.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 104
++--
1 files changed, 85 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index c25db54..7907081 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,8 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+static bool ccdc_input_is_fldmode(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -889,12 +891,6 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc,
isp_reg_writel(isp, offset 0x,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HSIZE_OFF);
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FINV);
-
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
-
switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
@@ -1010,6 +1006,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1114,10 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc)
unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1188,49 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc)
}
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ /* In BT.656 a pixel is representd using two bytes */
+ if (pdata-bt656)
+ nph = format-width * 2 - 1;
+ else
+ nph = format-width - 1;
+
+ /* In interlaced mode a frame is composed fo two subrames */
+ if (pdata-fldmode) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3;
+ } else {
+ vd0 = nlv = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ }
+
/* Generate VD0 on the last line of the image and VD1 on the
* 2/3 height line.
*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+ (vd1 ISPCCDC_VDINT_1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
- ((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+ (nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV0_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- isp_reg_writel(isp, (format-height - 1)
- ISPCCDC_VERT_LINES_NLV_SHIFT,
+ isp_reg_writel(isp, nlv ISPCCDC_VERT_LINES_NLV_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
+ isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV1_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
+
+ if (pdata-fldmode) {
+ ccdc_config_outlineoffset(ccdc, nph, EVENEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, EVENODD, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDODD, 1);
+ } else
+ ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0,
0);
/* CCDC_PAD_SOURCE_VP */
format = ccdc-formats[CCDC_PAD_SOURCE_VP];
@@ -1495,10 +1521,30 @@ static int ccdc_isr_buffer(struct isp_ccdc_device
*ccdc)
[PATCH v2 1/3] omap3isp: ccdc: Add interlaced field mode to platform data
The fldmode field from the CCDC_SYN_MODE register configure the ISP CCDC
between progresive and interlaced mode.
Adding this field to the platform data, allows boards to configure accordingly.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
include/media/omap3isp.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 3b2d2b7..0f215de 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -61,6 +61,8 @@ enum {
* 0 - Normal, 1 - One's complement
* @bt656: ITU-R BT656 embedded synchronization
* 0 - HS/VS sync, 1 - BT656 sync
+ * @fldmode: Field mode
+ * 0 - progressive, 1 - Interlaced
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
@@ -69,6 +71,7 @@ struct isp_parallel_platform_data {
unsigned int vs_pol:1;
unsigned int data_pol:1;
unsigned int bt656:1;
+ unsigned int fldmode:1;
};
enum {
--
1.7.4.1
--
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 2/3] omap3isp: ccdc: Add interlaced count field to isp_ccdc_device
When configured in interlaced field mode, the ISP CCDC has to know which
sub-frame of the current frame is processing.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.h
b/drivers/media/video/omap3isp/ispccdc.h
index 54811ce..8863eea 100644
--- a/drivers/media/video/omap3isp/ispccdc.h
+++ b/drivers/media/video/omap3isp/ispccdc.h
@@ -134,6 +134,7 @@ struct ispccdc_lsc {
* @wait: Wait queue used to stop the module
* @stopping: Stopping state
* @ioctl_lock: Serializes ioctl calls and LSC requests freeing
+ * @interlaced_cnt: Sub-frame count for an interlaced video frame
*/
struct isp_ccdc_device {
struct v4l2_subdev subdev;
@@ -164,6 +165,7 @@ struct isp_ccdc_device {
wait_queue_head_t wait;
unsigned int stopping;
struct mutex ioctl_lock;
+ unsigned int interlaced_cnt;
};
struct isp_device;
--
1.7.4.1
--
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 3/3] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
This patch adds to the ISP CCDC driver the ability to deinterlace video
data when configured in interlaced mode and send progressive frames to
user-space V4L2 applications.
Signed-off-by: Javier Martinez Canillas martinez.jav...@gmail.com
---
drivers/media/video/omap3isp/ispccdc.c | 104 ++--
1 files changed, 85 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index c25db54..7907081 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -40,6 +40,8 @@
static struct v4l2_mbus_framefmt *
__ccdc_get_format(struct isp_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
unsigned int pad, enum v4l2_subdev_format_whence which);
+static bool ccdc_input_is_bt656(struct isp_ccdc_device *ccdc);
+static bool ccdc_input_is_fldmode(struct isp_ccdc_device *ccdc);
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
@@ -889,12 +891,6 @@ static void ccdc_config_outlineoffset(struct
isp_ccdc_device *ccdc,
isp_reg_writel(isp, offset 0x,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HSIZE_OFF);
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FINV);
-
- isp_reg_clr(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
- ISPCCDC_SDOFST_FOFST_4L);
-
switch (oddeven) {
case EVENEVEN:
isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SDOFST,
@@ -1010,6 +1006,9 @@ static void ccdc_config_sync_if(struct isp_ccdc_device
*ccdc,
if (pdata pdata-vs_pol)
syn_mode |= ISPCCDC_SYN_MODE_VDPOL;
+ if (pdata pdata-fldmode)
+ syn_mode |= ISPCCDC_SYN_MODE_FLDMODE;
+
isp_reg_writel(isp, syn_mode, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_SYN_MODE);
if (format-code == V4L2_MBUS_FMT_UYVY8_2X8)
@@ -1115,6 +1114,10 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
unsigned int shift;
u32 syn_mode;
u32 ccdc_pattern;
+ u32 nph;
+ u32 nlv;
+ u32 vd0;
+ u32 vd1;
pad = media_entity_remote_source(ccdc-pads[CCDC_PAD_SINK]);
sensor = media_entity_to_v4l2_subdev(pad-entity);
@@ -1185,26 +1188,49 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
}
ccdc_config_imgattr(ccdc, ccdc_pattern);
+ /* In BT.656 a pixel is representd using two bytes */
+ if (pdata-bt656)
+ nph = format-width * 2 - 1;
+ else
+ nph = format-width - 1;
+
+ /* In interlaced mode a frame is composed fo two subrames */
+ if (pdata-fldmode) {
+ vd0 = nlv = format-height / 2 - 1;
+ vd1 = format-height / 3;
+ } else {
+ vd0 = nlv = format-height - 2;
+ vd1 = format-height * 2 / 3;
+ }
+
/* Generate VD0 on the last line of the image and VD1 on the
* 2/3 height line.
*/
- isp_reg_writel(isp, ((format-height - 2) ISPCCDC_VDINT_0_SHIFT) |
- ((format-height * 2 / 3) ISPCCDC_VDINT_1_SHIFT),
+ isp_reg_writel(isp, (vd0 ISPCCDC_VDINT_0_SHIFT) |
+ (vd1 ISPCCDC_VDINT_1_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VDINT);
/* CCDC_PAD_SOURCE_OF */
format = ccdc-formats[CCDC_PAD_SOURCE_OF];
isp_reg_writel(isp, (0 ISPCCDC_HORZ_INFO_SPH_SHIFT) |
- ((format-width - 1) ISPCCDC_HORZ_INFO_NPH_SHIFT),
+ (nph ISPCCDC_HORZ_INFO_NPH_SHIFT),
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_HORZ_INFO);
isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV0_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- isp_reg_writel(isp, (format-height - 1)
-ISPCCDC_VERT_LINES_NLV_SHIFT,
+ isp_reg_writel(isp, nlv ISPCCDC_VERT_LINES_NLV_SHIFT,
OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_LINES);
+ isp_reg_writel(isp, 0 ISPCCDC_VERT_START_SLV1_SHIFT,
+ OMAP3_ISP_IOMEM_CCDC, ISPCCDC_VERT_START);
- ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0, 0);
+
+ if (pdata-fldmode) {
+ ccdc_config_outlineoffset(ccdc, nph, EVENEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, EVENODD, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDEVEN, 1);
+ ccdc_config_outlineoffset(ccdc, nph, ODDODD, 1);
+ } else
+ ccdc_config_outlineoffset(ccdc, ccdc-video_out.bpl_value, 0,
0);
/* CCDC_PAD_SOURCE_VP */
format = ccdc-formats[CCDC_PAD_SOURCE_VP];
@@ -1495,10 +1521,30 @@ static int ccdc_isr_buffer(struct isp_ccdc_device *ccdc)
goto done;
}
- buffer = omap3isp_video_buffer_next(ccdc-video_out, ccdc-error);
- if (buffer != NULL) {
-
Re: [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 2:58 PM, Enrico ebut...@users.berlios.de wrote: On Sun, Oct 9, 2011 at 12:02 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patch. Laurent, apart from the specific comments on Javier code, did you have a look at Deepthy patches too? I say this because asking Javier for fixes means (to me) that you are going to merge his patches (if testing will confirm it works of course). Am i wrong? Btw i'm trying to get these patches on 3.1.0rc9 (from igep repository, that should be just like mainline 3.1.0rc9 with some bsp patches), i hope i will report good news. Enrico I just created a repository on my personal github account to keep the patches [1] and make it more easily accessible to people that want to try. These already have the fix to the fact that ccdc_input_is_fldmode() was returning pdata-bt655 instead of pdata-fldmode. I will try to test the patches tomorrow when I have access to the hardware but I can't promise because I have lots of other tasks to do. [1]: https://github.com/martinezjavier/omap3isp/tree/master/omap3isp-yuv-patches Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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 0/2] Add support to ITU-R BT.656 video data format
Hi Javier, Thanks for the patches. On Sunday 09 October 2011 04:37:31 Javier Martinez Canillas wrote: This patch-set aims to add support to the ISP CCDC driver to process interlaced video data in ITU-R BT.656 format. The patch-set contains the following patches: [PATCH 1/2] omap3isp: video: Decouple buffer obtaining and set ISP entities format [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format The first patch decouples next frame buffer obtaining from the last frame buffer releasing. This change is needed by the second patch that moves most of the CCDC buffer management logic to the VD1 interrupt handler. This patch-set is a proof-of-concept and was only compile tested since I don't have the hardware to test right now. It is a forward porting, on top of Laurent's omap3isp-omap3isp-yuv tree, of the changes we made to the ISP driver to get interlaced video working. Also, the patch will brake other configurations since the resizer and previewer also make use of omap3isp_video_buffer() function that now has a different semantic. That's an issue you need to address :-) I'm posting even when the patch-set is not in a merge-able state so you can review what we were doing and make comments. You should split your patches differently. Even if we ignore the above issue, your first patch will break the CCDC. In order to ease bissection patches should be self-contained and not introduce regressions if possible. Please see my comments to the second patch. These are not all our changes since we also modified the ISP to forward the [G | S]_FMT and [G | S]_STD V4L2 ioctl commands to the TVP5151 and to only copy the active lines, but those changes are not relevant with the ghosting effect. With these changes we could get the 25 fps but with some sort of artifacts on the images. -- Regards, Laurent Pinchart -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Oct 9 19:00:18 CEST 2011 git hash:e30528854797f057aa6ffb6dc9f890e923c467fd gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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 0/2] Add support to ITU-R BT.656 video data format
On Sun, Oct 9, 2011 at 7:12 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, Thanks for the patches. On Sunday 09 October 2011 04:37:31 Javier Martinez Canillas wrote: This patch-set aims to add support to the ISP CCDC driver to process interlaced video data in ITU-R BT.656 format. The patch-set contains the following patches: [PATCH 1/2] omap3isp: video: Decouple buffer obtaining and set ISP entities format [PATCH 2/2] omap3isp: ccdc: Add support to ITU-R BT.656 video data format The first patch decouples next frame buffer obtaining from the last frame buffer releasing. This change is needed by the second patch that moves most of the CCDC buffer management logic to the VD1 interrupt handler. This patch-set is a proof-of-concept and was only compile tested since I don't have the hardware to test right now. It is a forward porting, on top of Laurent's omap3isp-omap3isp-yuv tree, of the changes we made to the ISP driver to get interlaced video working. Also, the patch will brake other configurations since the resizer and previewer also make use of omap3isp_video_buffer() function that now has a different semantic. That's an issue you need to address :-) Hi Laurent, Yes, I know :-) The first version of the patch-set was only mean so you can review it but then I understood that your idea is to actually merge some code I send a few ours ago a v2 of the patch-set [1]. This v2 is a simpler code that doesn't move any of the logic to the VD1 interrupt handler so it won't brake others components (resizer, previewer, etc). So first we can focus to have a working version of the interlaced video data support in the driver and then try to fix the artifact effect issue. It is based on an early version of our patch and also I've address all the issues you called out on the second patch. The fact that the code to address interlaced video is not bt656 but fldmode dependent. Also I split the patches in atomic operations so it can be applied incrementally without breaking the driver. Please let me know if you got the v2 patches or I can resend them if it is easier for you. [1]: http://www.spinics.net/lists/linux-media/msg38973.html I'm posting even when the patch-set is not in a merge-able state so you can review what we were doing and make comments. You should split your patches differently. Even if we ignore the above issue, your first patch will break the CCDC. In order to ease bissection patches should be self-contained and not introduce regressions if possible. Please see my comments to the second patch. These are not all our changes since we also modified the ISP to forward the [G | S]_FMT and [G | S]_STD V4L2 ioctl commands to the TVP5151 and to only copy the active lines, but those changes are not relevant with the ghosting effect. With these changes we could get the 25 fps but with some sort of artifacts on the images. -- Regards, Laurent Pinchart Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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: omap3-isp status
On Sat, Oct 8, 2011 at 6:11 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Yes, I'll cook a patch today on top on your omap3isp-yuv and send for review. I won't be able to test neither since I don't have proper hardware at home. But at least you will get an idea of the approach we are using to solve this and can point possible flaws. I made some tests and unfortunately there are some problems. Note: i made these tests picking some patches from omap3isp-yuv branch and applying to igep 3.1.0rc9 kernel (more or less like mainline + some bsp patches) so maybe i made some mistakes (the tvp5150 driver is patched too), but due to the nature of the problems i don't think this is the case. Javier patches v1: i can grab frames with yavta but i get only garbage. Javier patches v2: i cannot grab frames with yavta (it hangs). I see only 2 interrupts on the isp, then stops. I compared Javier-v2 registers setup with Deepthy's patches and there are some differences. Moreover i remember that in Deepthy patches vd1 interrupt was not used (and in fact i had the same yavta-hanging problem before, and Deepthy patches solved it). I think Javier-v1 patches didn't hang the isp because they changed vd0/vd1 logic too, so maybe there were only some wrong isp registers but the logic was correct. Now i wonder if it could be easier/better to port Deepthy patches first and then add Javier fixes... Enrico -- 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: omap3-isp status
On Mon, Oct 10, 2011 at 12:35 AM, Enrico ebut...@users.berlios.de wrote: On Sat, Oct 8, 2011 at 6:11 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Yes, I'll cook a patch today on top on your omap3isp-yuv and send for review. I won't be able to test neither since I don't have proper hardware at home. But at least you will get an idea of the approach we are using to solve this and can point possible flaws. I made some tests and unfortunately there are some problems. Note: i made these tests picking some patches from omap3isp-yuv branch and applying to igep 3.1.0rc9 kernel (more or less like mainline + some bsp patches) so maybe i made some mistakes (the tvp5150 driver is patched too), but due to the nature of the problems i don't think this is the case. Javier patches v1: i can grab frames with yavta but i get only garbage. Javier patches v2: i cannot grab frames with yavta (it hangs). I see only 2 interrupts on the isp, then stops. I compared Javier-v2 registers setup with Deepthy's patches and there are some differences. Moreover i remember that in Deepthy patches vd1 interrupt was not used (and in fact i had the same yavta-hanging problem before, and Deepthy patches solved it). I think Javier-v1 patches didn't hang the isp because they changed vd0/vd1 logic too, so maybe there were only some wrong isp registers but the logic was correct. Now i wonder if it could be easier/better to port Deepthy patches first and then add Javier fixes... Enrico Hi Enrico, Yes, you are right in interlaced mode the VD1 interrupt handler doesn't have to be executed. In v1 there is a conditional execution and that is why the ISP doesn't hang up. Could you please try changing this on ispccdc.c with v2 patches? diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 9b40968..bfd3f46 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -1658,7 +1658,8 @@ int omap3isp_ccdc_isr(struct isp_ccdc_device *ccdc, u32 events) if (ccdc-state == ISP_PIPELINE_STREAM_STOPPED) return 0; - if (events IRQ0STATUS_CCDC_VD1_IRQ) + if ((events IRQ0STATUS_CCDC_VD1_IRQ) + !ccdc_input_is_fldmode(ccdc)) ccdc_vd1_isr(ccdc); ccdc_lsc_isr(ccdc, events); With this change the ISP shouldn't hang but I don't know if you will get the right data. Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- 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
