[PATCH] scatterlist: add sg_clone_table function
This patch adds another constructor for an sg table. An sg table is
created from an existing sg table. The new sg table is allocated and
initialized with same data from the original sg table. The user has to
call 'sg_clone_table' with the required sg table, the existing sg table
and the gfp allocation mask.
This function can be used in the dma-buf framework. If a buffer needs
to be shared across multiple devices using the dma_buf framework, an
sg table needs to be created and mapped to the target device's address
space. This is done in most drivers by creating the sg table from the
pages of the buffer (e.g. calling sg_alloc_table_from_pages function).
In case this needs to be done frequently (e.g. a framebuffer
is repeatedly shared with the GPU, video accelerator, CSC etc), it is
efficient to create an sg table once during buffer allocation and then
create temporary sg tables for dma mapping from the original sg table.
Signed-off-by: Prathyush K
---
include/linux/scatterlist.h |1 +
lib/scatterlist.c | 36
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 4bd6c06..fd12525 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -215,6 +215,7 @@ void sg_free_table(struct sg_table *);
int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int, gfp_t,
sg_alloc_fn *);
int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
+int sg_clone_table(struct sg_table *, struct sg_table *, gfp_t);
int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
unsigned long offset, unsigned long size,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 3675452..4f106b3 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -329,6 +329,42 @@ int sg_alloc_table(struct sg_table *table, unsigned int
nents, gfp_t gfp_mask)
}
EXPORT_SYMBOL(sg_alloc_table);
+/*
+ * sg_clone_table - Allocate and initialize an sg table from an existing
+ * sg table
+ * @sgt_in:The sg table to clone
+ * @sgt_out: The output sg table cloned from the original sg table.
+ * @gfp_mask: GFP allocation mask
+ *
+ * Description:
+ *Allocate and initialize an sg table from an existing sg table. A user
+ *would want to create a temporary sg table which is a clone of an
+ *existing table. This cloned sg table is released by sg_free_table.
+ *
+ * Returns:
+ *0 on success, negative error on failure
+ */
+int sg_clone_table(struct sg_table *sgt_in, struct sg_table *sgt_out,
+ gfp_t gfp_mask)
+{
+ struct scatterlist *s, *s_out;
+ unsigned int i;
+ int ret;
+
+ ret = sg_alloc_table(sgt_out, sgt_in->orig_nents, gfp_mask);
+ if (unlikely(ret))
+ return ret;
+
+ s_out = sgt_out->sgl;
+ for_each_sg(sgt_in->sgl, s, sgt_in->orig_nents, i) {
+ sg_set_page(s_out, sg_page(s), s->length, s->offset);
+ s_out = sg_next(s_out);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(sg_clone_table);
+
/**
* sg_alloc_table_from_pages - Allocate and initialize an sg table from
*an array of pages
--
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] rtl28xxu: 0ccd:00d7 TerraTec Cinergy T Stick+
On 11/07/2012 01:01 AM, Andrew Karpow wrote:
added usb-id as driver supports the stick
Signed-off-by: Andrew Karpow
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 0149cdd..093f1ac 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1348,6 +1348,8 @@ static const struct usb_device_id
rtl28xxu_id_table[] = {
&rtl2832u_props, "TerraTec Cinergy T Stick RC (Rev. 3)", NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1102,
&rtl2832u_props, "Dexatek DK mini DVB-T Dongle", NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00d7,
+ &rtl2832u_props, "TerraTec Cinergy T Stick+", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
Acked-by: Antti Palosaari
Thank you!
Could someone say if that simple USB ID addition could be added to the
Kernel 3.7 which is already in release candidate phase?
regards
Antti
--
http://palosaari.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
[PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers
Make gsc-m2m propagate the timestamp field from source to destination
buffers
Signed-off-by: John Sheu
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/exynos-gsc/gsc-m2m.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 047f0f0..1139276 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -99,22 +99,27 @@ static void gsc_m2m_job_abort(void *priv)
gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
}
-static int gsc_fill_addr(struct gsc_ctx *ctx)
+static int gsc_get_bufs(struct gsc_ctx *ctx)
{
struct gsc_frame *s_frame, *d_frame;
- struct vb2_buffer *vb = NULL;
+ struct vb2_buffer *src_vb, *dst_vb;
int ret;
s_frame = &ctx->s_frame;
d_frame = &ctx->d_frame;
- vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
- ret = gsc_prepare_addr(ctx, vb, s_frame, &s_frame->addr);
+ src_vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
+ ret = gsc_prepare_addr(ctx, src_vb, s_frame, &s_frame->addr);
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
+ ret |= gsc_prepare_addr(ctx, dst_vb, d_frame, &d_frame->addr);
if (ret)
return ret;
- vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
- return gsc_prepare_addr(ctx, vb, d_frame, &d_frame->addr);
+ memcpy(&dst_vb->v4l2_buf.timestamp, &src_vb->v4l2_buf.timestamp,
+ sizeof(dst_vb->v4l2_buf.timestamp));
+
+ return 0;
}
static void gsc_m2m_device_run(void *priv)
@@ -148,7 +153,7 @@ static void gsc_m2m_device_run(void *priv)
goto put_device;
}
- ret = gsc_fill_addr(ctx);
+ ret = gsc_get_bufs(ctx);
if (ret) {
pr_err("Wrong address");
goto put_device;
--
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] [media] exynos-gsc: Fix settings for input and output image RGB type
Macros used to set input and output RGB type aren't correct. Updating the macros as per register manual. Signed-off-by: Shaik Ameer Basha --- drivers/media/platform/exynos-gsc/gsc-regs.h | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.h b/drivers/media/platform/exynos-gsc/gsc-regs.h index 533e994..4678f9a 100644 --- a/drivers/media/platform/exynos-gsc/gsc-regs.h +++ b/drivers/media/platform/exynos-gsc/gsc-regs.h @@ -40,10 +40,10 @@ #define GSC_IN_ROT_YFLIP (2 << 16) #define GSC_IN_ROT_XFLIP (1 << 16) #define GSC_IN_RGB_TYPE_MASK (3 << 14) -#define GSC_IN_RGB_HD_WIDE (3 << 14) -#define GSC_IN_RGB_HD_NARROW (2 << 14) -#define GSC_IN_RGB_SD_WIDE (1 << 14) -#define GSC_IN_RGB_SD_NARROW (0 << 14) +#define GSC_IN_RGB_HD_NARROW (3 << 14) +#define GSC_IN_RGB_HD_WIDE (2 << 14) +#define GSC_IN_RGB_SD_NARROW (1 << 14) +#define GSC_IN_RGB_SD_WIDE (0 << 14) #define GSC_IN_YUV422_1P_ORDER_MASK(1 << 13) #define GSC_IN_YUV422_1P_ORDER_LSB_Y (0 << 13) #define GSC_IN_YUV422_1P_OEDER_LSB_C (1 << 13) @@ -85,10 +85,10 @@ #define GSC_OUT_GLOBAL_ALPHA_MASK (0xff << 24) #define GSC_OUT_GLOBAL_ALPHA(x)((x) << 24) #define GSC_OUT_RGB_TYPE_MASK (3 << 10) -#define GSC_OUT_RGB_HD_NARROW (3 << 10) -#define GSC_OUT_RGB_HD_WIDE(2 << 10) -#define GSC_OUT_RGB_SD_NARROW (1 << 10) -#define GSC_OUT_RGB_SD_WIDE(0 << 10) +#define GSC_OUT_RGB_HD_WIDE(3 << 10) +#define GSC_OUT_RGB_HD_NARROW (2 << 10) +#define GSC_OUT_RGB_SD_WIDE(1 << 10) +#define GSC_OUT_RGB_SD_NARROW (0 << 10) #define GSC_OUT_YUV422_1P_ORDER_MASK (1 << 9) #define GSC_OUT_YUV422_1P_ORDER_LSB_Y (0 << 9) #define GSC_OUT_YUV422_1P_OEDER_LSB_C (1 << 9) -- 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] [media] exynos-gsc: Adding tiled multi-planar format to G-Scaler
Adding V4L2_PIX_FMT_NV12MT_16X16 to G-Scaler supported formats.
If the output or input format is V4L2_PIX_FMT_NV12MT_16X16, configure
G-Scaler to use GSC_IN_TILE_MODE.
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/exynos-gsc/gsc-core.c |9 +
drivers/media/platform/exynos-gsc/gsc-core.h |5 +
drivers/media/platform/exynos-gsc/gsc-regs.c |6 ++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index cc7b218..00f1013 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -185,6 +185,15 @@ static const struct gsc_fmt gsc_formats[] = {
.corder = GSC_CRCB,
.num_planes = 3,
.num_comp = 3,
+ }, {
+ .name = "YUV 4:2:0 non-contig. 2p, Y/CbCr, tiled",
+ .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+ .depth = { 8, 4 },
+ .color = GSC_YUV420,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
}
};
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 5f157ef..cc19bba 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -427,6 +427,11 @@ static inline void gsc_ctx_state_lock_clear(u32 state,
struct gsc_ctx *ctx)
spin_unlock_irqrestore(&ctx->gsc_dev->slock, flags);
}
+static inline int is_tiled(const struct gsc_fmt *fmt)
+{
+ return fmt->pixelformat == V4L2_PIX_FMT_NV12MT_16X16;
+}
+
static inline void gsc_hw_enable_control(struct gsc_dev *dev, bool on)
{
u32 cfg = readl(dev->regs + GSC_ENABLE);
diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c
b/drivers/media/platform/exynos-gsc/gsc-regs.c
index 0146b35..6f5b5a4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-regs.c
+++ b/drivers/media/platform/exynos-gsc/gsc-regs.c
@@ -214,6 +214,9 @@ void gsc_hw_set_in_image_format(struct gsc_ctx *ctx)
break;
}
+ if (is_tiled(frame->fmt))
+ cfg |= GSC_IN_TILE_C_16x8 | GSC_IN_TILE_MODE;
+
writel(cfg, dev->regs + GSC_IN_CON);
}
@@ -334,6 +337,9 @@ void gsc_hw_set_out_image_format(struct gsc_ctx *ctx)
break;
}
+ if (is_tiled(frame->fmt))
+ cfg |= GSC_OUT_TILE_C_16x8 | GSC_OUT_TILE_MODE;
+
end_set:
writel(cfg, dev->regs + GSC_OUT_CON);
}
--
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] siano: fix Kconfig
Em Wed, 07 Nov 2012 01:10:18 +0100 David Härdeman escreveu: > make allmodconfig fails on the staging/for_v3.8 branch: > > LD init/built-in.o > drivers/built-in.o: In function `sms_ir_event': > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:48: undefined > reference to `ir_raw_event_store' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:50: undefined > reference to `ir_raw_event_handle' > drivers/built-in.o: In function `sms_ir_init': > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:56: undefined > reference to `smscore_get_board_id' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:60: undefined > reference to `rc_allocate_device' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:72: undefined > reference to `sms_get_board' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:92: undefined > reference to `sms_get_board' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:97: undefined > reference to `rc_register_device' > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:100: undefined > reference to `rc_free_device' > drivers/built-in.o: In function `sms_ir_exit': > /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:111: undefined > reference to `rc_unregister_device' > make: *** [vmlinux] Error 1 > > from drivers/media/common/siano/Kconfig: > config SMS_SIANO_RC > bool "Enable Remote Controller support for Siano devices" > > from drivers/media/common/siano/Makefile: > obj-$(CONFIG_SMS_SIANO_RC) += smsir.o > > Note the "bool" option in the Kconfig which results in these .config options: > CONFIG_SMS_SIANO_MDTV=m > CONFIG_SMS_SIANO_RC=y > CONFIG_RC_CORE=m > > So the smsir.ko module gets built in while rc-core is a standalone > module. Fix by making smsir a tristate as well. (I hope that's the > correct fix, I'm no Kconfig expert). I suspect that this won't cover all possibilities. It seems that this would still be a valid option: CONFIG_SMS_SIANO_MDTV=y CONFIG_SMS_SIANO_RC=m CONFIG_RC_CORE=m But I don't think it would work. > > Signed-off-by: David Härdeman > --- > drivers/media/common/siano/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/common/siano/Kconfig > b/drivers/media/common/siano/Kconfig > index 3cb7823..239b7ba 100644 > --- a/drivers/media/common/siano/Kconfig > +++ b/drivers/media/common/siano/Kconfig > @@ -9,7 +9,7 @@ config SMS_SIANO_MDTV > default y > > config SMS_SIANO_RC > - bool "Enable Remote Controller support for Siano devices" > + tristate "Enable Remote Controller support for Siano devices" > depends on SMS_SIANO_MDTV && RC_CORE > depends on SMS_USB_DRV || SMS_SDIO_DRV > depends on MEDIA_COMMON_OPTIONS > Cheers, Mauro -- 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] siano: fix Kconfig
make allmodconfig fails on the staging/for_v3.8 branch: LD init/built-in.o drivers/built-in.o: In function `sms_ir_event': /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:48: undefined reference to `ir_raw_event_store' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:50: undefined reference to `ir_raw_event_handle' drivers/built-in.o: In function `sms_ir_init': /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:56: undefined reference to `smscore_get_board_id' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:60: undefined reference to `rc_allocate_device' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:72: undefined reference to `sms_get_board' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:92: undefined reference to `sms_get_board' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:97: undefined reference to `rc_register_device' /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:100: undefined reference to `rc_free_device' drivers/built-in.o: In function `sms_ir_exit': /home/david/checkouts/linux/drivers/media/common/siano/smsir.c:111: undefined reference to `rc_unregister_device' make: *** [vmlinux] Error 1 from drivers/media/common/siano/Kconfig: config SMS_SIANO_RC bool "Enable Remote Controller support for Siano devices" from drivers/media/common/siano/Makefile: obj-$(CONFIG_SMS_SIANO_RC) += smsir.o Note the "bool" option in the Kconfig which results in these .config options: CONFIG_SMS_SIANO_MDTV=m CONFIG_SMS_SIANO_RC=y CONFIG_RC_CORE=m So the smsir.ko module gets built in while rc-core is a standalone module. Fix by making smsir a tristate as well. (I hope that's the correct fix, I'm no Kconfig expert). Signed-off-by: David Härdeman --- drivers/media/common/siano/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/common/siano/Kconfig b/drivers/media/common/siano/Kconfig index 3cb7823..239b7ba 100644 --- a/drivers/media/common/siano/Kconfig +++ b/drivers/media/common/siano/Kconfig @@ -9,7 +9,7 @@ config SMS_SIANO_MDTV default y config SMS_SIANO_RC - bool "Enable Remote Controller support for Siano devices" + tristate "Enable Remote Controller support for Siano devices" depends on SMS_SIANO_MDTV && RC_CORE depends on SMS_USB_DRV || SMS_SDIO_DRV depends on MEDIA_COMMON_OPTIONS -- 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] rtl28xxu: 0ccd:00d7 TerraTec Cinergy T Stick+
added usb-id as driver supports the stick
Signed-off-by: Andrew Karpow
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 0149cdd..093f1ac 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1348,6 +1348,8 @@ static const struct usb_device_id
rtl28xxu_id_table[] = {
&rtl2832u_props, "TerraTec Cinergy T Stick RC (Rev. 3)", NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1102,
&rtl2832u_props, "Dexatek DK mini DVB-T Dongle", NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00d7,
+ &rtl2832u_props, "TerraTec Cinergy T Stick+", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.8.6
--
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] rtl28xxu: 1d19:1102 Dexatek DK mini DVB-T Dongle
Short question,
is simple ID addition for device driver like that allowed to push during
RC phase (for Kernel 3.7 as now is RC4 released)?
I tried to look documentation but didn't found answer.
regards
Antti
On 11/06/2012 09:16 PM, Antti Palosaari wrote:
Add new USB ID as driver supports it.
Reported-by: Hubert Lin
Tested-by: Hubert Lin
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index adabba8..0149cdd 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1346,6 +1346,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "DigitalNow Quad DVB-T Receiver", NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00d3,
&rtl2832u_props, "TerraTec Cinergy T Stick RC (Rev. 3)", NULL)
},
+ { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1102,
+ &rtl2832u_props, "Dexatek DK mini DVB-T Dongle", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
http://palosaari.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
[RFC] Selections targets at V4L2 video mem-to-mem interface
Hi All,
I'd like to clarify the meaning of selection targets on a mem-to-mem video
device, in order to document it and to make sure new m2m drivers get it
right, and also that the existing ones, using originally the crop ioctls,
are converted to the selection ioctls properly.
Until the selections API was introduced we used the CROP ioctls to
configure
cropping on OUTPUT buffer queue and composition onto CAPTURE buffer.
Looking at Figure 1.2, [1] it seems obvious that there should be applied
following mapping of the CROP to SELECTION ioctls:
S_CROP(V4L2_BUF_TYPE_VIDEO_OUTPUT) ->
S_SELECTION(V4L2_BUF_TYPE_VIDEO_OUTPUT,
V4L2_SEL_TGT_CROP)
S_CROP(V4L2_BUF_TYPE_VIDEO_CAPTURE) ->
S_SELECTION(V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_SEL_TGT_COMPOSE)
And that's how selections are currently documented at video output and
capture interfaces:
*Configuration of video output*
For output devices targets and ioctls are used similarly to the video
capture
case. The composing rectangle refers to the insertion of an image into a
video
signal. The cropping rectangles refer to a memory buffer."
*Configuration of video capture*
... The top left corner, width and height of the source rectangle, that
is the
area actually sampled, is given by the V4L2_SEL_TGT_CROP target.
...
The composing targets refer to a memory buffer.
If we apply this mapping, then current VIDIOC_S/G_CROP ->
VIDIOC_S/G_SELECTION
ioctl fallback code wouldn't be valid, as we have there, e.g.
static int v4l_s_crop(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
struct v4l2_crop *p = arg;
struct v4l2_selection s = {
.type = p->type,
.r = p->c,
};
if (ops->vidioc_s_crop)
return ops->vidioc_s_crop(file, fh, p);
/* simulate capture crop using selection api */
/* crop means compose for output devices */
if (V4L2_TYPE_IS_OUTPUT(p->type))
s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
else
s.target = V4L2_SEL_TGT_CROP_ACTIVE;
return ops->vidioc_s_selection(file, fh, &s);
}
i.e. it does exactly opposite to what we would expect for M2M.
One possible solution would be to get hold of struct video_device and
do proper targets conversion after checking the vfl_dir field.
Does anyone have suggestions on this ?
BTW, we still have some V4L2_SEL_TGT*_ACTIVE symbols left, I'll write
a patch to clean this up.
[1] http://hverkuil.home.xs4all.nl/spec/media.html#idp9025504
[2] http://hverkuil.home.xs4all.nl/spec/media.html#idp9031840
--
Thanks,
Sylwester
--
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: VIDIOC_STREAMON and VIDIOC_QBUF calls fail
Hi Andreas, On Mon, Nov 05, 2012 at 04:47:43PM +0100, Andreas Nagel wrote: > Hello, > > in order to familiarize myself with Media Controller and V4L2 I am > creating a small example program for capturing some frames through > the OMAP3 ISP. > The hardware used is a TAO-3530 on a Tsunami daughterboard from > Technexion. My video source is a standard DVD player connected to > the daughterboards S-VIDEO port. That port itself is wired to a > TVP5146 decoder chip from TI. > A precompiled Android image with a demo app proofs, that the > hardware is working fine. > > My example program is mostly based on the following wiki page and > the capture example in the V4L2 documentation. > http://processors.wiki.ti.com/index.php/Writing_V4L2_Media_Controller_Applications_on_Dm36x_Video_Capture > > My code sets up the ISP pipeline, configures the format on all the > subdevices pads and the actual video device. Works fine so far. > Then I passed user pointers (aquired with malloc) to the device > driver for the capture buffers. Before issuing VIDIOC_STREAMON, I > enqueue my buffers with VIDIOC_QBUF, which fails with errno = EIO. I > don't know, why this is happening or where to got from here. One possibility could be that mapping the buffer to ISP MMU fails for a reason or another. Do you set the length field in the buffer? > When using memory-mapped buffers instead, mapping the addresses to > userspace works fine as well as VIDIOC_QBUF calls. But then > VIDIOC_STREAMON fails with EINVAL. According to V4L documentation, > EINVAL means > a) buffertype (V4L2_BUF_TYPE_VIDEO_CAPTURE in this case) not supported > b) no buffers have been allocated (memory mapping) > c) or enqueued yet > > Because I tested V4L2_CAP_VIDEO_CAPTURE capability, I guess option > a) does not apply. Buffers have been enqueud, so c) doesn't apply > either. > What about b) ? As I chose memory-mapped buffers here, the device > drivers manages the buffers. How can I make sure, that buffers were > actually allocated? > > And am I missing something else? The formats on the pads at different ends of the links in the pipeline must match. In most cases, they have to be exactly the same. Have you used the media-ctl test program here? http://git.ideasonboard.org/media-ctl.git> media-ctl -p gives you (and us) lots of information that helps figuring out what could go wrong here. > I attached my example code. If you need more information, I will provide it. > > Note: I have to use the Technexion 2.6.37 kernel, which is based on > the TI kernel. It's the only kernel that comes with the ISP driver > and Media Controller API onboard and I guess, TI or TN included this > stuff somehow. Normally, this shouldn't be available until 2.6.39. > Sadly, I cannot use another kernel, because Technexion doesn't push > board support anywhere. This might work but I think it'd be best if you could just use the mainline kernel. Others are mostly unsupported. Cc Laurent. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi. > Does the sensor still hang after 0x2f is written to REG_GRCOM instead ? Work! I'm looking at drivers/media/usb/gspca/m5602/m5602_ov9650.h It use significantly different init sequence. Some of settings described in Application note for ov9650, some look like magic. > Do you have CONFIG_PM_RUNTIME enabled ? Can you try and see it works > if you enable it, without additional changes to the clock handling ? Work. With CONFIG_PM_RUNTIME and without enabling CLK_GATE at probe. > I hope to eventually prepare the ov9650 sensor driver for mainline. Your > help in making it ready for VER=0x52 would be very much appreciated. :-) I'll try to helpful. >> Next step is to make ov2460 work. > For now I can only recommend you to make the ov2460 driver more similar > to the ov9650 one. Thanks, I'll try. P.S. I add support of image effects just for fun. And found in DS that s3c2450 also support effects. It's FIMC in-between of 2440 and 6400/6410. Does anyone have s3c2450 hardware to test it? -- 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: avermedia, new version of avertv volar green hd
Also lsusb -vvd 07ca:3835 could be nice to see.
Antti
On 11/06/2012 10:33 PM, Antti Palosaari wrote:
Any idea about chipset? Those listed didn't sound any familiar. What are
driver file names?
regards
Antti
On 11/05/2012 02:37 PM, Árvai Zoltán wrote:
Hi,
I asked the local guy from Avermedia about this tuner.
He said it is a new product called "AVerTV Volar HD M" (A835M). It has
probably the same hardware like the Volar Green, but it has extended
software bundle (e.g. Mac support).
http://www.avermedia.com/Product/ProductDetail.aspx?Id=517
Regards,
Zoltan
On 11/04/2012 07:43 PM, moebius wrote:
Bonjour,
It's a dvb-t usb dongle
It's the same name than a former device but with new id : 07ca:3835
instead of 07ca:a835 and probably new hardware ; and it doesn't work...
I've tried to enter a new device in the v4l-dvb web list but nothing
has happened ; the source, can be found at
http://www.linuxtv.org/wiki/index.php?title=DVB-T_USB_Devices_ListData/Helper&action=edit§ion=1
I've made a photo too but don't know how I can upload it.
Anyway, here is the source :
AVerMedia AVerTV Volar Green HD 07ca:3835
{{DeviceDisplayMedium|AVerMedia AVerTV Volar Green HD 07ca:3835}}
{renderwith}}}|src=USB_Device_Data|selatt1={{{selatt1|}}}|selval1={{{selval1|}}}|selatt2={{{selatt2|}}}|selval2={{{selval2|}}}|selatt3={{{selatt3|}}}|selval3={{{selval3|}}}|selatt4={{{selatt4|}}}|selval4={{{selval4|}}}
| did=AVerMedia AVerTV Volar Green HD 07ca:3835
| vendor=[[AVerMedia]]
| device=[[AVerMedia AVerTV Volar Green HD | AVerTV Volar Green HD]]
| standard=DVB-T
| supported={{no}}
| pic=
| pic=
| url=
| url=
| hostinterface=USB2.0
| usbid=07ca:3835
| hw=unknown (see pic)
| tuner=
| demodulator=
| usbbridge=
| fw=
| comment= New version with same name ; main chipset (square, 4x12
pins) named AV3007 SXB1102 ; a little chip with 8 pins named 402R6
K207, another one with 5 pins 215L1(or "I" instead of "1") AC1H ; last
small chip with metal on top T120 WtBF.
This device don't work on recent ubuntu kernel (3.2.0-23-lowlatency),
even with the last (04/11/2012) v4l drivers that I've downloaded and
install today.
}}
cordialement,
--
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
--
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
--
http://palosaari.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
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:Tue Nov 6 19:02:24 CET 2012 git hash:2cb654fd281e1929aa3b9f5f54f492135157a613 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: OK 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-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-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-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: avermedia, new version of avertv volar green hd
Any idea about chipset? Those listed didn't sound any familiar. What are
driver file names?
regards
Antti
On 11/05/2012 02:37 PM, Árvai Zoltán wrote:
Hi,
I asked the local guy from Avermedia about this tuner.
He said it is a new product called "AVerTV Volar HD M" (A835M). It has
probably the same hardware like the Volar Green, but it has extended
software bundle (e.g. Mac support).
http://www.avermedia.com/Product/ProductDetail.aspx?Id=517
Regards,
Zoltan
On 11/04/2012 07:43 PM, moebius wrote:
Bonjour,
It's a dvb-t usb dongle
It's the same name than a former device but with new id : 07ca:3835
instead of 07ca:a835 and probably new hardware ; and it doesn't work...
I've tried to enter a new device in the v4l-dvb web list but nothing
has happened ; the source, can be found at
http://www.linuxtv.org/wiki/index.php?title=DVB-T_USB_Devices_ListData/Helper&action=edit§ion=1
I've made a photo too but don't know how I can upload it.
Anyway, here is the source :
AVerMedia AVerTV Volar Green HD 07ca:3835
{{DeviceDisplayMedium|AVerMedia AVerTV Volar Green HD 07ca:3835}}
{renderwith}}}|src=USB_Device_Data|selatt1={{{selatt1|}}}|selval1={{{selval1|}}}|selatt2={{{selatt2|}}}|selval2={{{selval2|}}}|selatt3={{{selatt3|}}}|selval3={{{selval3|}}}|selatt4={{{selatt4|}}}|selval4={{{selval4|}}}
| did=AVerMedia AVerTV Volar Green HD 07ca:3835
| vendor=[[AVerMedia]]
| device=[[AVerMedia AVerTV Volar Green HD | AVerTV Volar Green HD]]
| standard=DVB-T
| supported={{no}}
| pic=
| pic=
| url=
| url=
| hostinterface=USB2.0
| usbid=07ca:3835
| hw=unknown (see pic)
| tuner=
| demodulator=
| usbbridge=
| fw=
| comment= New version with same name ; main chipset (square, 4x12
pins) named AV3007 SXB1102 ; a little chip with 8 pins named 402R6
K207, another one with 5 pins 215L1(or "I" instead of "1") AC1H ; last
small chip with metal on top T120 WtBF.
This device don't work on recent ubuntu kernel (3.2.0-23-lowlatency),
even with the last (04/11/2012) v4l drivers that I've downloaded and
install today.
}}
cordialement,
--
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
--
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
--
http://palosaari.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
[PATCH 2/2] Staging/media: Use dev_ printks in go7007/s2250-board.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/s2250-board.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/go7007/s2250-board.c
b/drivers/staging/media/go7007/s2250-board.c
index 6f94c17..d1cfefe 100644
--- a/drivers/staging/media/go7007/s2250-board.c
+++ b/drivers/staging/media/go7007/s2250-board.c
@@ -173,7 +173,7 @@ static int write_reg(struct i2c_client *client, u8 reg, u8
value)
usb = go->hpi_context;
if (mutex_lock_interruptible(&usb->i2c_lock) != 0) {
- printk(KERN_INFO "i2c lock failed\n");
+ dev_info(&client->dev, "i2c lock failed\n");
kfree(buf);
return -EINTR;
}
@@ -212,7 +212,7 @@ static int write_reg_fp(struct i2c_client *client, u16
addr, u16 val)
usb = go->hpi_context;
if (mutex_lock_interruptible(&usb->i2c_lock) != 0) {
- printk(KERN_INFO "i2c lock failed\n");
+ dev_info(&client->dev, "i2c lock failed\n");
kfree(buf);
return -EINTR;
}
@@ -230,13 +230,13 @@ static int write_reg_fp(struct i2c_client *client, u16
addr, u16 val)
val_read = (buf[2] << 8) + buf[3];
kfree(buf);
if (val_read != val) {
- printk(KERN_INFO "invalid fp write %x %x\n",
- val_read, val);
+ dev_info(&client->dev, "invalid fp write %x %x\n",
+val_read, val);
return -EFAULT;
}
if (subaddr != addr) {
- printk(KERN_INFO "invalid fp write addr %x %x\n",
- subaddr, addr);
+ dev_info(&client->dev, "invalid fp write addr %x %x\n",
+subaddr, addr);
return -EFAULT;
}
} else {
@@ -274,7 +274,7 @@ static int read_reg_fp(struct i2c_client *client, u16 addr,
u16 *val)
memset(buf, 0xcd, 6);
usb = go->hpi_context;
if (mutex_lock_interruptible(&usb->i2c_lock) != 0) {
- printk(KERN_INFO "i2c lock failed\n");
+ dev_info(&client->dev, "i2c lock failed\n");
kfree(buf);
return -EINTR;
}
@@ -298,7 +298,7 @@ static int write_regs(struct i2c_client *client, u8 *regs)
for (i = 0; !((regs[i] == 0x00) && (regs[i+1] == 0x00)); i += 2) {
if (write_reg(client, regs[i], regs[i+1]) < 0) {
- printk(KERN_INFO "s2250: failed\n");
+ dev_info(&client->dev, "failed\n");
return -1;
}
}
@@ -311,7 +311,7 @@ static int write_regs_fp(struct i2c_client *client, u16
*regs)
for (i = 0; !((regs[i] == 0x00) && (regs[i+1] == 0x00)); i += 2) {
if (write_reg_fp(client, regs[i], regs[i+1]) < 0) {
- printk(KERN_INFO "s2250: failed fp\n");
+ dev_info(&client->dev, "failed fp\n");
return -1;
}
}
@@ -605,23 +605,20 @@ static int s2250_probe(struct i2c_client *client,
/* initialize the audio */
if (write_regs(audio, aud_regs) < 0) {
- printk(KERN_ERR
- "s2250: error initializing audio\n");
+ dev_err(&client->dev, "error initializing audio\n");
i2c_unregister_device(audio);
kfree(state);
return 0;
}
if (write_regs(client, vid_regs) < 0) {
- printk(KERN_ERR
- "s2250: error initializing decoder\n");
+ dev_err(&client->dev, "error initializing decoder\n");
i2c_unregister_device(audio);
kfree(state);
return 0;
}
if (write_regs_fp(client, vid_regs_fp) < 0) {
- printk(KERN_ERR
- "s2250: error initializing decoder\n");
+ dev_err(&client->dev, "error initializing decoder\n");
i2c_unregister_device(audio);
kfree(state);
return 0;
--
1.7.9.5
--
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] Staging/media: Use dev_ printks in go7007/wis-tw2804.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-tw2804.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-tw2804.c
b/drivers/staging/media/go7007/wis-tw2804.c
index 9134f03..69b9063 100644
--- a/drivers/staging/media/go7007/wis-tw2804.c
+++ b/drivers/staging/media/go7007/wis-tw2804.c
@@ -128,30 +128,32 @@ static int wis_tw2804_command(struct i2c_client *client,
int *input = arg;
if (*input < 0 || *input > 3) {
- printk(KERN_ERR "wis-tw2804: channel %d is not "
- "between 0 and 3!\n", *input);
+ dev_err(&client->dev,
+ "channel %d is not between 0 and 3!\n", *input);
return 0;
}
dec->channel = *input;
- printk(KERN_DEBUG "wis-tw2804: initializing TW2804 "
- "channel %d\n", dec->channel);
+ dev_dbg(&client->dev, "initializing TW2804 channel %d\n",
+ dec->channel);
if (dec->channel == 0 &&
write_regs(client, global_registers, 0) < 0) {
- printk(KERN_ERR "wis-tw2804: error initializing "
- "TW2804 global registers\n");
+ dev_err(&client->dev,
+ "error initializing TW2804 global registers\n");
return 0;
}
if (write_regs(client, channel_registers, dec->channel) < 0) {
- printk(KERN_ERR "wis-tw2804: error initializing "
- "TW2804 channel %d\n", dec->channel);
+ dev_err(&client->dev,
+ "error initializing TW2804 channel %d\n",
+ dec->channel);
return 0;
}
return 0;
}
if (dec->channel < 0) {
- printk(KERN_DEBUG "wis-tw2804: ignoring command %08x until "
- "channel number is set\n", cmd);
+ dev_dbg(&client->dev,
+ "ignoring command %08x until channel number is set\n",
+ cmd);
return 0;
}
@@ -311,7 +313,7 @@ static int wis_tw2804_probe(struct i2c_client *client,
dec->hue = 128;
i2c_set_clientdata(client, dec);
- printk(KERN_DEBUG "wis-tw2804: creating TW2804 at address %d on %s\n",
+ dev_dbg(&client->dev, "creating TW2804 at address %d on %s\n",
client->addr, adapter->name);
return 0;
--
1.7.9.5
--
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 1/2] Staging/media: fixed spacing coding style in go7007/wis-uda1342.c
fixed below checkpatch error.
- ERROR: that open brace { should be on the previous line
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/s2250-board.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/s2250-board.c
b/drivers/staging/media/go7007/s2250-board.c
index 014d384..6f94c17 100644
--- a/drivers/staging/media/go7007/s2250-board.c
+++ b/drivers/staging/media/go7007/s2250-board.c
@@ -103,8 +103,7 @@ static u16 vid_regs_fp[] = {
};
/* PAL specific values */
-static u16 vid_regs_fp_pal[] =
-{
+static u16 vid_regs_fp_pal[] = {
0x120, 0x017,
0x121, 0xd22,
0x122, 0x122,
--
1.7.9.5
--
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] Staging/media: Use dev_ printks in go7007/wis-uda1342.c
fixed below checkpatch warning. - WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... Signed-off-by: YAMANE Toshiaki --- drivers/staging/media/go7007/wis-uda1342.c |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/go7007/wis-uda1342.c b/drivers/staging/media/go7007/wis-uda1342.c index 0127be2..48e1407 100644 --- a/drivers/staging/media/go7007/wis-uda1342.c +++ b/drivers/staging/media/go7007/wis-uda1342.c @@ -47,8 +47,8 @@ static int wis_uda1342_command(struct i2c_client *client, write_reg(client, 0x00, 0x1241); /* select input 1 */ break; default: - printk(KERN_ERR "wis-uda1342: input %d not supported\n", - *inp); + dev_err(&client->dev, "input %d not supported\n", + *inp); break; } break; @@ -67,8 +67,7 @@ static int wis_uda1342_probe(struct i2c_client *client, if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) return -ENODEV; - printk(KERN_DEBUG - "wis-uda1342: initializing UDA1342 at address %d on %s\n", + dev_dbg(&client->dev, "initializing UDA1342 at address %d on %s\n", client->addr, adapter->name); write_reg(client, 0x00, 0x8000); /* reset registers */ -- 1.7.9.5 -- 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] rtl28xxu: 1d19:1102 Dexatek DK mini DVB-T Dongle
Add new USB ID as driver supports it.
Reported-by: Hubert Lin
Tested-by: Hubert Lin
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index adabba8..0149cdd 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1346,6 +1346,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "DigitalNow Quad DVB-T Receiver", NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, 0x00d3,
&rtl2832u_props, "TerraTec Cinergy T Stick RC (Rev. 3)", NULL)
},
+ { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1102,
+ &rtl2832u_props, "Dexatek DK mini DVB-T Dongle", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.7
--
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
for_v3.8 build is broken
That build is broken currently. drivers/built-in.o: In function `sms_ir_event': /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:48: undefined reference to `ir_raw_event_store' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:50: undefined reference to `ir_raw_event_handle' drivers/built-in.o: In function `sms_ir_init': /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:56: undefined reference to `smscore_get_board_id' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:60: undefined reference to `rc_allocate_device' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:72: undefined reference to `sms_get_board' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:92: undefined reference to `sms_get_board' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:97: undefined reference to `rc_register_device' /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:100: undefined reference to `rc_free_device' drivers/built-in.o: In function `sms_ir_exit': /home/crope/linuxtv/code/linux/drivers/media/common/siano/smsir.c:111: undefined reference to `rc_unregister_device' make: *** [vmlinux] Error 1 Antti -- http://palosaari.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: [PATCH] cx23885: Added support for AVerTV Hybrid Express Slim HC81R (only analog)
Hi guys! So what is with my patch? It is will be accepted? -- 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] Add chipid to fc2580.c
On 11/06/2012 02:01 PM, Oliver Schinagl wrote:
On 05-11-12 23:58, Antti Palosaari wrote:
On 10/30/2012 11:24 AM, Oliver Schinagl wrote:
On 29-10-12 02:09, Antti Palosaari wrote:
su 28.10.2012 22:07 Mauro Carvalho Chehab kirjoitti:
Em Mon, 22 Oct 2012 10:17:26 +0200
Oliver Schinagl escreveu:
diff --git a/drivers/media/tuners/fc2580.c
b/drivers/media/tuners/fc2580.c
index aff39ae..102d942 100644
I found a fellow Asus U3100+ user (mentioned him before with the
firmware issue) that even when using the latest firmware, still see's
0xff as the chipID.
You missed to add a signed-off-by on your patch.
Maybe it would make sense, in this case, to print some warning
message,
as this could be due to a bug either at the hardware or at some place
at the driver, like the gpio config settings for this device.
Anyway, Antti, your call.
I am on holiday now and dont want to look much these things at the
moment.
Having 0x00 or 0xff as chip id is something very very stupid and not
exits
in real world. It is good indicator I2C operation was failing. Check
GPIOs, see windows sniffs, add sleep, test if other I2C reads are
working
later, etc. to find out more info and fix it properly. In worst case
it is
possible that I2C reads are not working at all...
This was a random report for someone who I assisted via e-mail to get
the latest git clone from antti's tree. Building, enabling debugging and
getting this information alone took a week. I don't think we have the
possibility to get a dump from anything. The stick has been working fine
from my understanding using the 0xff tunerID. How to handle support for
these 'bugged' tuners, I leave that up to you :)
Honestly I don't want to add hack like that with this little
information. It must be found out if all I2C readings are failing, or
just the first one, or some other condition. Currently there is only
two register reads on that driver. Guess what happens if someone
enhances that driver so that one bit from certain register is
changed... Set register bit 7, current register value is 0x00.
Register value will be 0x7ff as read returns always 0xff :-(
true, do you have some test code, that could test this? or a test module
that prints some debug information for this specific case? I could then
have the user in question try it out and report his findings?
Just add like 5 register reads one after another inside attach and print
out returned values. Or add debug print to register read to see what it
returns as read is used during tune too. Write different tuner id to
af9035 firmware to see if it is fw issue. There is million ways to make
tests and see what happens and make conclusions.
Antti
oliver
AFTER your well deserved holiday. Enjoy and have a great time!
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -497,6 +497,7 @@ struct dvb_frontend *fc2580_attach(struct
dvb_frontend *fe,
switch (chip_id) {
case 0x56:
case 0x5a:
+ case 0xff:
break;
default:
goto err;
--
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
--
Regards,
Mauro
--
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
regards
Antti
--
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
--
http://palosaari.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: Using OV5642 sensor driver for CM8206-A500SA-E
Hi Bastian, On Tue, 6 Nov 2012 10:38:40 +0100 Bastian Hecht wrote: > Hi Anatolij, > > if I remember correctly I had the same issue inverted. For me the > initialization sequence of the freescale driver didn't work. Generally it > was quite difficult to deduce anything from the docs to split the > initialization into sensible parts. Too many parts were undocumented or > didn't work as expected. Maybe there are different hardware revisions out > there that need a different register setup. > Unfortunately I can only give you some general notes here as I no longer > possess an OV5642. Okay, thanks for the info anyway! Anatolij -- 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: Debugging DVB
Michelle, you could try looking at the DVB-Apps, its probably the best starting place. http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps oliver On 06-11-12 10:23, Michelle wrote: Dear All, I need your advice and help. I am very new to Linux DVB system. I have installed a DVB-S card in my system. May I know how can I verify the received signal? Thank you. -- 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 -- 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] OV5642: fix VIDIOC_S_GROP ioctl
On Tue, 6 Nov 2012 12:45:51 +0100 (CET) Guennadi Liakhovetski wrote: > On Tue, 6 Nov 2012, Anatolij Gustschin wrote: > > > VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: > > > > soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop > > failed > > > > The issue is caused by checking for V4L2_BUF_TYPE_VIDEO_CAPTURE type > > in driver's g_crop callback. This check should be in s_crop instead, > > g_crop should just set the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE > > as other drivers do. Move the V4L2_BUF_TYPE_VIDEO_CAPTURE type check > > to s_crop callback. > > I'm not sure this is correct: > > http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-crop.html > > Or is the .g_crop() subdev operation using a different semantics? Where is > that documented? I do not know if it is documented somewhere. But it seems natural to me that a sensor driver sets the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE in its .g_crop(). A sensor is a capture device, not an output or overlay device. And this ioctl is a query operation. OTOH I'm fine with this type checking in .g_crop() and it can help to discover bugs in user space apps. The VIDIOC_G_CROP documentation states that the type field needs to be set to the respective buffer type when querying, so the check in .g_crop() is perfectly valid. But then I need following patch to fix the observed issue: --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -902,6 +902,8 @@ static int soc_camera_s_crop(struct file *file, void *fh, dev_dbg(icd->pdev, "S_CROP(%ux%u@%u:%u)\n", rect->width, rect->height, rect->left, rect->top); + current_crop.type = a->type; + /* If get_crop fails, we'll let host and / or client drivers decide */ ret = ici->ops->get_crop(icd, ¤t_crop); What do you think? And the type field should be checked in .s_crop() anyway, I think. Thanks, Anatolij -- 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 1/2] ARM: i.MX27: Add platform support for IRAM.
On Tue, Nov 06, 2012 at 12:37:35PM +0100, Guennadi Liakhovetski wrote: > Hi Javier > > On Mon, 5 Nov 2012, Javier Martin wrote: > > > Add support for IRAM to i.MX27 non-DT platforms using > > iram_init() function. > > I'm not sure this belongs in a camera driver. Can IRAM not be used for > anything else? I'll check the i.MX27 datasheet when I'm back home after > the conference, so far this seems a bit odd. This patch just adds the sram pool to the system in i.MX27 code, the patch is not camera specific. Sascha -- 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] Staging/media: Use dev_ printks in go7007/go7007-v4l2.c
fixed below checkpatch warning. - WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to printk(KERN_INFO ... Signed-off-by: YAMANE Toshiaki --- drivers/staging/media/go7007/go7007-v4l2.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/media/go7007/go7007-v4l2.c b/drivers/staging/media/go7007/go7007-v4l2.c index 980371b..d2d72d5 100644 --- a/drivers/staging/media/go7007/go7007-v4l2.c +++ b/drivers/staging/media/go7007/go7007-v4l2.c @@ -1811,8 +1811,8 @@ int go7007_v4l2_init(struct go7007 *go) } video_set_drvdata(go->video_dev, go); ++go->ref_count; - printk(KERN_INFO "%s: registered device %s [v4l2]\n", - go->video_dev->name, video_device_node_name(go->video_dev)); + dev_info(go->dev, "registered device %s [v4l2]\n", +video_device_node_name(go->video_dev)); return 0; } -- 1.7.9.5 -- 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 2/2] Staging/media: Use dev_ printks in go7007/wis-tw9903.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-tw9903.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-tw9903.c
b/drivers/staging/media/go7007/wis-tw9903.c
index 3821cd5..246ce17 100644
--- a/drivers/staging/media/go7007/wis-tw9903.c
+++ b/drivers/staging/media/go7007/wis-tw9903.c
@@ -127,8 +127,8 @@ static int wis_tw9903_command(struct i2c_client *client,
0x06, 0xc0, /* reset device */
0, 0,
};
- printk(KERN_DEBUG "vscale is %04x, hscale is %04x\n",
- vscale, hscale);
+ dev_dbg(&client->dev, "vscale is %04x, hscale is %04x\n",
+ vscale, hscale);
/*write_regs(client, regs);*/
break;
}
@@ -287,12 +287,11 @@ static int wis_tw9903_probe(struct i2c_client *client,
dec->hue = 0;
i2c_set_clientdata(client, dec);
- printk(KERN_DEBUG
- "wis-tw9903: initializing TW9903 at address %d on %s\n",
+ dev_dbg(&client->dev, "initializing TW9903 at address %d on %s\n",
client->addr, adapter->name);
if (write_regs(client, initial_registers) < 0) {
- printk(KERN_ERR "wis-tw9903: error initializing TW9903\n");
+ dev_err(&client->dev, "error initializing TW9903\n");
kfree(dec);
return -ENODEV;
}
--
1.7.9.5
--
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 1/2] Staging/media: fixed spacing coding style in go7007/wis-tw9903.c
fixed below checkpatch error.
- ERROR: that open brace { should be on the previous line
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/go7007/wis-tw9903.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/go7007/wis-tw9903.c
b/drivers/staging/media/go7007/wis-tw9903.c
index 9230f4a..3821cd5 100644
--- a/drivers/staging/media/go7007/wis-tw9903.c
+++ b/drivers/staging/media/go7007/wis-tw9903.c
@@ -31,8 +31,7 @@ struct wis_tw9903 {
int hue;
};
-static u8 initial_registers[] =
-{
+static u8 initial_registers[] = {
0x02, 0x44, /* input 1, composite */
0x03, 0x92, /* correct digital format */
0x04, 0x00,
--
1.7.9.5
--
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] Add chipid to fc2580.c
On 05-11-12 23:58, Antti Palosaari wrote:
On 10/30/2012 11:24 AM, Oliver Schinagl wrote:
On 29-10-12 02:09, Antti Palosaari wrote:
su 28.10.2012 22:07 Mauro Carvalho Chehab kirjoitti:
Em Mon, 22 Oct 2012 10:17:26 +0200
Oliver Schinagl escreveu:
diff --git a/drivers/media/tuners/fc2580.c
b/drivers/media/tuners/fc2580.c
index aff39ae..102d942 100644
I found a fellow Asus U3100+ user (mentioned him before with the
firmware issue) that even when using the latest firmware, still see's
0xff as the chipID.
You missed to add a signed-off-by on your patch.
Maybe it would make sense, in this case, to print some warning
message,
as this could be due to a bug either at the hardware or at some place
at the driver, like the gpio config settings for this device.
Anyway, Antti, your call.
I am on holiday now and dont want to look much these things at the
moment.
Having 0x00 or 0xff as chip id is something very very stupid and not
exits
in real world. It is good indicator I2C operation was failing. Check
GPIOs, see windows sniffs, add sleep, test if other I2C reads are
working
later, etc. to find out more info and fix it properly. In worst case
it is
possible that I2C reads are not working at all...
This was a random report for someone who I assisted via e-mail to get
the latest git clone from antti's tree. Building, enabling debugging and
getting this information alone took a week. I don't think we have the
possibility to get a dump from anything. The stick has been working fine
from my understanding using the 0xff tunerID. How to handle support for
these 'bugged' tuners, I leave that up to you :)
Honestly I don't want to add hack like that with this little
information. It must be found out if all I2C readings are failing, or
just the first one, or some other condition. Currently there is only
two register reads on that driver. Guess what happens if someone
enhances that driver so that one bit from certain register is
changed... Set register bit 7, current register value is 0x00.
Register value will be 0x7ff as read returns always 0xff :-(
true, do you have some test code, that could test this? or a test module
that prints some debug information for this specific case? I could then
have the user in question try it out and report his findings?
oliver
AFTER your well deserved holiday. Enjoy and have a great time!
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -497,6 +497,7 @@ struct dvb_frontend *fc2580_attach(struct
dvb_frontend *fe,
switch (chip_id) {
case 0x56:
case 0x5a:
+ case 0xff:
break;
default:
goto err;
--
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
--
Regards,
Mauro
--
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
regards
Antti
--
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] OV5642: fix VIDIOC_S_GROP ioctl
On Tue, 6 Nov 2012, Anatolij Gustschin wrote: > VIDIOC_S_GROP ioctl doesn't work, soc-camera driver reports: > > soc-camera-pdrv soc-camera-pdrv.0: S_CROP denied: getting current crop failed > > The issue is caused by checking for V4L2_BUF_TYPE_VIDEO_CAPTURE type > in driver's g_crop callback. This check should be in s_crop instead, > g_crop should just set the type field to V4L2_BUF_TYPE_VIDEO_CAPTURE > as other drivers do. Move the V4L2_BUF_TYPE_VIDEO_CAPTURE type check > to s_crop callback. I'm not sure this is correct: http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-crop.html Or is the .g_crop() subdev operation using a different semantics? Where is that documented? Thanks Guennadi > > Signed-off-by: Anatolij Gustschin > Cc: Guennadi Liakhovetski > --- > drivers/media/i2c/soc_camera/ov5642.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/i2c/soc_camera/ov5642.c > b/drivers/media/i2c/soc_camera/ov5642.c > index 8577e0c..19863e5 100644 > --- a/drivers/media/i2c/soc_camera/ov5642.c > +++ b/drivers/media/i2c/soc_camera/ov5642.c > @@ -872,6 +872,9 @@ static int ov5642_s_crop(struct v4l2_subdev *sd, const > struct v4l2_crop *a) > struct v4l2_rect rect = a->c; > int ret; > > + if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) > + return -EINVAL; > + > v4l_bound_align_image(&rect.width, 48, OV5642_MAX_WIDTH, 1, > &rect.height, 32, OV5642_MAX_HEIGHT, 1, 0); > > @@ -899,9 +902,7 @@ static int ov5642_g_crop(struct v4l2_subdev *sd, struct > v4l2_crop *a) > struct ov5642 *priv = to_ov5642(client); > struct v4l2_rect *rect = &a->c; > > - if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) > - return -EINVAL; > - > + a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; > *rect = priv->crop_rect; > > return 0; > -- > 1.7.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 > --- 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 1/2] ARM: i.MX27: Add platform support for IRAM.
Hi Javier
On Mon, 5 Nov 2012, Javier Martin wrote:
> Add support for IRAM to i.MX27 non-DT platforms using
> iram_init() function.
I'm not sure this belongs in a camera driver. Can IRAM not be used for
anything else? I'll check the i.MX27 datasheet when I'm back home after
the conference, so far this seems a bit odd.
Thanks
Guennadi
>
> Signed-off-by: Javier Martin
> ---
> arch/arm/mach-imx/mm-imx27.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
> index e7e24af..fd2416d 100644
> --- a/arch/arm/mach-imx/mm-imx27.c
> +++ b/arch/arm/mach-imx/mm-imx27.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> /* MX27 memory map definition */
> static struct map_desc imx27_io_desc[] __initdata = {
> @@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
> /* imx27 has the imx21 type audmux */
> platform_device_register_simple("imx21-audmux", 0, imx27_audmux_res,
> ARRAY_SIZE(imx27_audmux_res));
> + /* imx27 has an iram of 46080 bytes size */
> + iram_init(MX27_IRAM_BASE_ADDR, 46080);
> }
> --
> 1.7.9.5
>
> --
> 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
>
---
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 RFC 1/5] V4L: Add V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 media bus format
Hi Sakari and Sylwester, Sorry for the late answer. > -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@iki.fi] > Sent: Monday, October 15, 2012 8:36 PM > To: Sylwester Nawrocki > Cc: Vincent ABRIOU; linux-media@vger.kernel.org; a.ha...@samsung.com; > Laurent Pinchart; hverk...@xs4all.nl; kyungmin.p...@samsung.com; > sw0312@samsung.com; Nicolas THERY; Jean-Marc VOLLE; Pierre-yves > TALOUD; Willy POISSON > Subject: Re: [PATCH RFC 1/5] V4L: Add > V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 media bus format > > Hi Sylwester and Vincent, > > My apologies for the late reply on this topic. I've been quite busy lately. > > Sylwester Nawrocki wrote: > > On 10/09/2012 03:36 PM, Vincent ABRIOU wrote: > >> Hi Sylwester, > >> > >> I'm wondering why don't you simply define > V4L2_MBUS_FMT_UYVY_JPEG_1X8 > >> without any reference to your camera? > > > > Because it's not a plain UYVY/JPEG data. There is an additional > > meta-data that follows interleaved UYVY/JPEG. It's all on a single > > User Defined MIPI CSI-2 DT. In addition to that there is some more > > meta data transmitted on MIPI CSI-2 Embedded Data DT. If there was no > > meta-data present at the User Defined DT, then we could think about > > using generic > > V4L2_MBUS_FMT_UYVY_JPEG_1X8 pixel code and handling the meta-data > on > > separate DT with the frame_desc calls. > > > > Anyway this S5C media bus format is an experimental thing and if there > > are cameras generating plain JPEG/YUV we need to search for better, > > more generic solution. > > Vincent: what's the frame layout that your sensor produces? There are two > cases that could be easy (sort of, everything's relative) that I can see for > the > standard interfaces. The sensor I used interleaved Jpeg and YUV but I met 2 cases: 1/ sensor providing JPEG / YUV (using the same DT) 2/ sensor providing JPEG with a 1st DT, YUV with a 2nd DT and embedded data using a 3rd DT > > 1. Different parts of the image are transmitted over different CSI-2 contexts. > This way the receiver may separate them to separate memory regions, and > the end result is a single multi-plane buffer. > > 2. If the distance in octets of the intermittent image strides is constant, > then > we could do some tricks with multi-plane buffers. The two planes of the > buffer could be interleaved, with correct base addresses. > > I think Sylwester's case fits into neither of the above. A device-specific > format does not resolve configuring the two formats. > > Both require adding plane-specific pixel codes, agreement over how frame > descriptors are used for describing frames of multiple independent content > planes, and how the multiple formats are configured on the sensor. Use of > sub-subdevs come to mind for the last one as an alternative --- this issue > stems from the fact we're using the same interface to model the bus and the > image format on that bus. It no longer works out the way it used to when > there are two formats on the same bus. > My point of view is that the only user's concern is how to retrieve the data, on which pad and how are they sorted? The MBUS format to be use by the camera (and set by the user) should only define the overall structure of the CSI stream and could be generic (like V4L2_MBUS_FMT_UYVY_JPEG_1X8 or V4L2_MBUS_FMT_YUYV_JPEG_1X8 without any sensor model mentioned). In the MBUS format naming, we don't care about describing the eventual metadata and other stream specificities link to the camera because the CSI stream details could be described in the v4l2_subdev_frame_format as initially proposed by Sakari (More flag descriptor could be added to describe the data to be transmitted). It is then up to the CSI2 receiver to recover the CSI stream layout and to configure output pads and multi-plane buffer according to its capabilities. Multi-plan buffer attached to the pad need to have a plane-specific pixel code in order to warn user about the buffer content. Then user could query the output pads of the CSI 2 receiver to discover on which pad the different pixel formats are outputted and how: > Each of these probably require a separate RFC and someone to implement > the changes. > > Kind regards, > > -- > Sakari Ailus > sakari.ai...@iki.fi Best Regards, Vincent Abriou -- 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: Using OV5642 sensor driver for CM8206-A500SA-E
Hi Anatolij, if I remember correctly I had the same issue inverted. For me the initialization sequence of the freescale driver didn't work. Generally it was quite difficult to deduce anything from the docs to split the initialization into sensible parts. Too many parts were undocumented or didn't work as expected. Maybe there are different hardware revisions out there that need a different register setup. Unfortunately I can only give you some general notes here as I no longer possess an OV5642. Good luck, Bastian 2012/11/6 Anatolij Gustschin > > Hi, > > I'm trying to use mainline ov5642 driver for ov5642 based camera > module CM8206-A500SA-E from TRULY. The driver loads and initializes > the sensor, but the initialization seems to be incomplete, the sensor > doesn't generate pixel clock and sync signals. > > For a quick test I've replaced the default initialisation sequences > from ov5642_default_regs_init[] and ov5642_default_regs_finalise[] > with an init sequence in ov5642_setting_30fps_720P_1280_720[] taken > from Freescale ov5642 driver [1] and commented out ov5642_set_resolution() > in ov5642_s_power(). With these changes to the mainline driver the > sensor starts clocking out pixels and I receive 1280x720 image. > > Is anyone using the mainline ov5642 driver for mentioned TRULY camera > module? Just wanted to ask before digging further to find out what > changes to the mainline driver are really needed to make it working > with TRULY camera module. > > Thanks, > Anatolij > > [1] > http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/plain/drivers/media/video/mxc/capture/ov5642.c?h=imx_3.0.15 -- 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
Using OV5642 sensor driver for CM8206-A500SA-E
Hi, I'm trying to use mainline ov5642 driver for ov5642 based camera module CM8206-A500SA-E from TRULY. The driver loads and initializes the sensor, but the initialization seems to be incomplete, the sensor doesn't generate pixel clock and sync signals. For a quick test I've replaced the default initialisation sequences from ov5642_default_regs_init[] and ov5642_default_regs_finalise[] with an init sequence in ov5642_setting_30fps_720P_1280_720[] taken from Freescale ov5642 driver [1] and commented out ov5642_set_resolution() in ov5642_s_power(). With these changes to the mainline driver the sensor starts clocking out pixels and I receive 1280x720 image. Is anyone using the mainline ov5642 driver for mentioned TRULY camera module? Just wanted to ask before digging further to find out what changes to the mainline driver are really needed to make it working with TRULY camera module. Thanks, Anatolij [1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/plain/drivers/media/video/mxc/capture/ov5642.c?h=imx_3.0.15 -- 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
Debugging DVB
Dear All, I need your advice and help. I am very new to Linux DVB system. I have installed a DVB-S card in my system. May I know how can I verify the received signal? Thank you. -- 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
