Re: [PATCH RFC v2 1/2] max77693: added device tree support
Hi Samuel, A while ago I have send rebased patch adding device-tree support for max77693 as you asked: https://patchwork.kernel.org/patch/2414341/ The patch is still not applied. Is there a reason for that or just an omission? Regards Andrzej On 04/08/2013 05:21 PM, Samuel Ortiz wrote: Hi Andrzej, On Tue, Feb 19, 2013 at 04:36:16PM +0100, Andrzej Hajda wrote: max77693 mfd main device uses only wakeup field from max77693_platform_data. This field is mapped to wakeup-source property in device tree. Device tree bindings doc will be added in max77693-led patch. Signed-off-by: Andrzej Hajda a.ha...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mfd/max77693.c | 40 +--- 1 file changed, 33 insertions(+), 7 deletions(-) This patch looks good to me, but doesn't apply to mfd-next. Would you mind rebasing it ? Cheers, Samuel. -- 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] videobuf2-dma-sg: Minimize the number of dma segments
Hello,
On 7/15/2013 11:34 AM, Ricardo Ribalda Delgado wrote:
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread through
houndreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages_exact. In the worst case it will behave as before, but most
of the times it will reduce the number fo dma segments
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
I like the idea, but the code doesn't seem to be correct. buf-pages
array is
needed for vb2_dma_sg_mmap() function to map pages to userspace. However
in your
code I don't see any place where you fill it with the pages of order higher
than 0. AFAIR vm_insert_page() can handle compound pages, but
alloc_pages_exact()
splits such pages into a set of pages of order 0, so you need to change
your code
to correctly fill buf-pages array.
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 49 +---
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..67a94ab 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -42,10 +42,44 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ void *vaddr = NULL;
+ unsigned int req_pages;
+
+ while (last_page buf-sg_desc.num_pages) {
+ req_pages = buf-sg_desc.num_pages-last_page;
+ while (req_pages = 1) {
+ vaddr = alloc_pages_exact(req_pages*PAGE_SIZE,
+ GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN);
+ if (vaddr)
+ break;
+ req_pages = 1;
+ }
+ if (!vaddr) {
+ while (--last_page = 0)
+ __free_page(buf-pages[last_page]);
+ return -ENOMEM;
+ }
+ while (req_pages) {
+ buf-pages[last_page] = virt_to_page(vaddr);
+ sg_set_page(buf-sg_desc.sglist[last_page],
+ buf-pages[last_page], PAGE_SIZE, 0);
+ vaddr += PAGE_SIZE;
+ last_page++;
+ req_pages--;
+ }
+ }
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +103,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
if (!buf-pages)
goto fail_pages_array_alloc;
- for (i = 0; i buf-sg_desc.num_pages; ++i) {
- buf-pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf-pages[i])
- goto fail_pages_alloc;
- sg_set_page(buf-sg_desc.sglist[i],
- buf-pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf-handler.refcount = buf-refcount;
buf-handler.put = vb2_dma_sg_put;
@@ -89,8 +118,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i = 0)
- __free_page(buf-pages[i]);
kfree(buf-pages);
fail_pages_array_alloc:
Best regards
--
Marek Szyprowski
Samsung RD Institute Poland
--
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 v4] media: OF: add sync-on-green-active property
Hi Sylwester, Thanks for the review. On Wed, Jul 17, 2013 at 2:08 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi Prabhakar, [snip] diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..5186c7e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -101,6 +101,9 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +- sync-on-green-active: polarity field when video synchronization is + Sync-On-Green. When set the driver determines whether it's a normal operation + or inverted operation. Would you mind adding this entry after pclk-sample property description ? OK. And how about describing it a bit more precisely and similarly to VSYNC/HSYNC, e.g. - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. OK I'll paste the above one itself :-) -- Regards, Prabhakar Lad -- 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: MT9D131 context switching [was RE: width and height of JPEG compressed images]
Hi Sakari, On 17 July 2013 00:58 Sakari Ailus wrote: On Mon, Jul 15, 2013 at 09:30:33AM +, Thomas Vajzovic wrote: On 10 July 2013 20:44 Sylwester Nawrocki wrote: On 07/07/2013 10:18 AM, Thomas Vajzovic wrote: On 06 July 2013 20:58 Sylwester Nawrocki wrote: On 07/05/2013 10:22 AM, Thomas Vajzovic wrote: I am writing a driver for the sensor MT9D131. As a side note, looking at the MT9D131 sensor datasheet I can see it has preview (Mode A) and capture (Mode B) modes. Are you also planning adding proper support for switching between those modes ? I'm interested in supporting this in standard way in V4L2, as lot's of sensors I have been working with also support such modes. This camera has more like three modes: preview (context A) up to 800x600, up to 30fps, YUV/RGB capture video (context B) up to 1600x1200, up to 15fps, YUV/RGB/JPEG capture stills (context B) up to 1600x1200, sequence of 1 or more frames with no fixed timing, YUV/RGB/JPEG I have implemented switching between the first two of these, but the choice is forced by the framerate, resolution and format that the user requests, so I have not exposed any interface to change the context, the driver just chooses the one that can do what the user wants. As for the third mode, I do not currently plan to implement it, but if I was going to then I think the only API that would be required is V4L2_MODE_HIGHQUALITY in v4l2_captureparm.capturemode. Is there a practical difference in video and still capture in this case? I haven't read the docs fully because I don't use that mode, but AFAIK: If you select capture stills then it takes a few frames and then changes mode back to preview on its own. As it is changing modes then the auto- exposure and gain does clever things. I think it might discard or mask all but one of the frames to help you just get the single best one. This mode also supports triggering a synchronized flash light in hardware and I don't know what else. Regards, Tom Disclaimer: This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the original message and the sent message from your computer. Infrared Integrated Systems Limited Park Circle Tithe Barn Way Swan Valley Northampton NN4 9BG Registration Number: 3186364. -- 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] stk1160: Allow to change input while streaming
Remove the check as there's no reason to prevent the input from
being set when the device is streaming. This allows surveillance
applications (such as motion, zoneminder, etc.) to configure the
input while streaming.
Reported-by: Sergey 'Jin' Bostandzhyan j...@mediatomb.cc
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Cc: Sergey 'Jin' Bostandzhyan j...@mediatomb.cc
Cc: Hans Verkuil hans.verk...@cisco.com
drivers/media/usb/stk1160/stk1160-v4l.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/media/usb/stk1160/stk1160-v4l.c
b/drivers/media/usb/stk1160/stk1160-v4l.c
index 876fc26..ee46d82 100644
--- a/drivers/media/usb/stk1160/stk1160-v4l.c
+++ b/drivers/media/usb/stk1160/stk1160-v4l.c
@@ -440,9 +440,6 @@ static int vidioc_s_input(struct file *file, void *priv,
unsigned int i)
{
struct stk1160 *dev = video_drvdata(file);
- if (vb2_is_busy(dev-vb_vidq))
- return -EBUSY;
-
if (i STK1160_MAX_INPUT)
return -EINVAL;
--
1.8.1.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: Possible problem with stk1160 driver
Hi Sergey, On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote: It generally works fine, I can, for example, open the video device using VLC, select one of the inputs and get the picture. However, programs like motion or zoneminder fail, I am not quite sure if it is something that they might be doing or if it is a problem in the driver. Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails with EBUSY. I've just sent a patch to fix this issue. Could you try it and let me know if it solves your issue? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] [media] usbtv: remove unused including linux/version.h
On Wed, 2013-07-17 at 10:01 +0800, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove including linux/version.h that don't need it. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Lubomir Rintel lkund...@v3.sk -- 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] videobuf2-dma-sg: Minimize the number of dma segments
Hi Marek
alloc_pages_exact returns pages of order 0, every single page is
filled into buf-pages, that then is used by vb2_dma_sg_mmap(), that
also expects order 0 pages (its loops increments in PAGE_SIZE). The
code has been tested on real HW.
Your concern is that that alloc_pages_exact splits the higher order pages?
Do you want that videobuf2-dma-sg to have support for higher order pages?
Best regards
PS: sorry for the duplicated post, previous one contained html parts
and was rejected by the list
On Wed, Jul 17, 2013 at 10:27 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On 7/15/2013 11:34 AM, Ricardo Ribalda Delgado wrote:
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread through
houndreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages_exact. In the worst case it will behave as before, but most
of the times it will reduce the number fo dma segments
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
I like the idea, but the code doesn't seem to be correct. buf-pages array
is
needed for vb2_dma_sg_mmap() function to map pages to userspace. However in
your
code I don't see any place where you fill it with the pages of order higher
than 0. AFAIR vm_insert_page() can handle compound pages, but
alloc_pages_exact()
splits such pages into a set of pages of order 0, so you need to change your
code
to correctly fill buf-pages array.
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 49
+---
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..67a94ab 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -42,10 +42,44 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ void *vaddr = NULL;
+ unsigned int req_pages;
+
+ while (last_page buf-sg_desc.num_pages) {
+ req_pages = buf-sg_desc.num_pages-last_page;
+ while (req_pages = 1) {
+ vaddr = alloc_pages_exact(req_pages*PAGE_SIZE,
+ GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN);
+ if (vaddr)
+ break;
+ req_pages = 1;
+ }
+ if (!vaddr) {
+ while (--last_page = 0)
+ __free_page(buf-pages[last_page]);
+ return -ENOMEM;
+ }
+ while (req_pages) {
+ buf-pages[last_page] = virt_to_page(vaddr);
+ sg_set_page(buf-sg_desc.sglist[last_page],
+ buf-pages[last_page], PAGE_SIZE,
0);
+ vaddr += PAGE_SIZE;
+ last_page++;
+ req_pages--;
+ }
+ }
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +103,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx,
unsigned long size, gfp_t gfp_fla
if (!buf-pages)
goto fail_pages_array_alloc;
- for (i = 0; i buf-sg_desc.num_pages; ++i) {
- buf-pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf-pages[i])
- goto fail_pages_alloc;
- sg_set_page(buf-sg_desc.sglist[i],
- buf-pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf-handler.refcount = buf-refcount;
buf-handler.put = vb2_dma_sg_put;
@@ -89,8 +118,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i = 0)
- __free_page(buf-pages[i]);
kfree(buf-pages);
fail_pages_array_alloc:
Best regards
--
Marek Szyprowski
Samsung RD Institute Poland
--
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
[PATCH 1/2] Fixed for compatible with kernel 3.10.0-rc6
--- drivers/video/Kconfig |2 ++ drivers/video/fbmon.c | 12 +--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 2e14e0b..b0a0947 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -324,6 +324,7 @@ config FB_ARMCLCD select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select FB_MODE_HELPERS if OF + select VIDEOMODE_HELPERS help This framebuffer device driver is for the ARM PrimeCell PL110 Colour LCD controller. ARM PrimeCells provide the building @@ -340,6 +341,7 @@ config FB_ARMHDLCD select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT + select VIDEOMODE_HELPERS help This framebuffer device driver is for the ARM High Definition Colour LCD controller. diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c index 304cf37..aaa5be7 100644 --- a/drivers/video/fbmon.c +++ b/drivers/video/fbmon.c @@ -1440,17 +1440,15 @@ void videomode_from_fb_var_screeninfo(const struct fb_var_screeninfo *var, vm-vback_porch = var-upper_margin; vm-vsync_len = var-vsync_len; - vm-dmt_flags = 0; + vm-flags = 0; if (var-sync FB_SYNC_HOR_HIGH_ACT) - vm-dmt_flags |= VESA_DMT_HSYNC_HIGH; + vm-flags |= DISPLAY_FLAGS_HSYNC_HIGH; if (var-sync FB_SYNC_VERT_HIGH_ACT) - vm-dmt_flags |= VESA_DMT_VSYNC_HIGH; - - vm-data_flags = 0; + vm-flags |= DISPLAY_FLAGS_VSYNC_HIGH; if (var-vmode FB_VMODE_INTERLACED) - vm-data_flags |= DISPLAY_FLAGS_INTERLACED; + vm-flags |= DISPLAY_FLAGS_INTERLACED; if (var-vmode FB_VMODE_DOUBLE) - vm-data_flags |= DISPLAY_FLAGS_DOUBLESCAN; + vm-flags |= DISPLAY_FLAGS_DOUBLESCAN; } EXPORT_SYMBOL_GPL(videomode_from_fb_var_screeninfo); -- 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] CDFv2 for VExpress HDLCD DVI output support
---
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts |6 +-
drivers/video/arm-hdlcd.c | 116 +---
drivers/video/vexpress-dvimode.c | 11 +++
drivers/video/vexpress-muxfpga.c |8 +-
include/linux/arm-hdlcd.h |6 ++
5 files changed, 135 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index f1dc620..aeef32d 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -145,10 +145,14 @@
compatible = arm,hdlcd;
reg = 0 0x2b00 0 0x1000;
interrupts = 0 85 4;
- mode = 1024x768-16@60;
framebuffer = 0 0xff00 0 0x0100;
clocks = oscclk5;
clock-names = pxlclk;
+ label = V2P-CA15_A7 HDLCD;
+ display = v2m_muxfpga 0xf;
+max-hactive = 1280;
+max-vactive = 1024;
+max-bpp = 16;
};
memory-controller@2b0a {
diff --git a/drivers/video/arm-hdlcd.c b/drivers/video/arm-hdlcd.c
index cfd631e..528239f 100644
--- a/drivers/video/arm-hdlcd.c
+++ b/drivers/video/arm-hdlcd.c
@@ -31,7 +31,8 @@
#include linux/proc_fs.h
#include linux/seq_file.h
#endif
-
+#include video/display.h
+#include video/videomode.h
#include edid.h
#ifdef CONFIG_SERIAL_AMBA_PCU_UART
@@ -41,6 +42,8 @@ int get_edid(u8 *msgbuf);
#define to_hdlcd_device(info) container_of(info, struct hdlcd_device, fb)
+#define MAX_FB_MODE_NAME 128
+
static struct of_device_id hdlcd_of_matches[] = {
{ .compatible = arm,hdlcd },
{},
@@ -129,12 +132,20 @@ static inline void hdlcd_enable(struct hdlcd_device
*hdlcd)
{
dev_dbg(hdlcd-dev, HDLCD: output enabled\n);
writel(1, hdlcd-base + HDLCD_REG_COMMAND);
+
+ if (hdlcd-display)
+display_entity_set_state( hdlcd-display,
+ DISPLAY_ENTITY_STATE_ON);
}
static inline void hdlcd_disable(struct hdlcd_device *hdlcd)
{
dev_dbg(hdlcd-dev, HDLCD: output disabled\n);
writel(0, hdlcd-base + HDLCD_REG_COMMAND);
+
+ if (hdlcd-display)
+display_entity_set_state(hdlcd-display,
+ DISPLAY_ENTITY_STATE_OFF);
}
static int hdlcd_set_bitfields(struct hdlcd_device *hdlcd,
@@ -267,6 +278,13 @@ static int hdlcd_set_par(struct fb_info *info)
hdlcd_disable(hdlcd);
+ if(hdlcd-display) {
+struct videomode mode;
+
+videomode_from_fb_var_screeninfo(hdlcd-fb.var, mode);
+display_entity_update(hdlcd-display, mode);
+}
+
WRITE_HDLCD_REG(HDLCD_REG_FB_LINE_LENGTH, hdlcd-fb.var.xres *
bytes_per_pixel);
WRITE_HDLCD_REG(HDLCD_REG_FB_LINE_PITCH, hdlcd-fb.var.xres *
bytes_per_pixel);
WRITE_HDLCD_REG(HDLCD_REG_FB_LINE_COUNT, hdlcd-fb.var.yres - 1);
@@ -520,8 +538,8 @@ static int hdlcd_setup(struct hdlcd_device *hdlcd)
hdlcd-fb.var.nonstd= 0;
hdlcd-fb.var.activate = FB_ACTIVATE_NOW;
- hdlcd-fb.var.height= -1;
- hdlcd-fb.var.width = -1;
+ hdlcd-fb.var.height= hdlcd-height;
+ hdlcd-fb.var.width = hdlcd-width;
hdlcd-fb.var.accel_flags = 0;
init_completion(hdlcd-vsync_completion);
@@ -542,7 +560,7 @@ static int hdlcd_setup(struct hdlcd_device *hdlcd)
hdlcd-fb.monspecs.vfmin= 0;
hdlcd-fb.monspecs.vfmax= 400;
hdlcd-fb.monspecs.dclkmin = 100;
- hdlcd-fb.monspecs.dclkmax = 1;
+ hdlcd-fb.monspecs.dclkmax = 14000;
fb_find_mode(hdlcd-fb.var, hdlcd-fb, fb_mode, NULL, 0,
hdlcd_default_mode, 32);
}
@@ -633,6 +651,75 @@ static int parse_edid_data(struct hdlcd_device *hdlcd,
const u8 *edid_data, int
return 0;
}
+#ifdef CONFIG_OF
+static int hdlcd_of_init_display(struct hdlcd_device *hdlcd, struct
device_node *of_node)
+{
+int err, i;
+int modes_num, best_mode = -1;
+char*mode_name;
+const struct videomode *modes;
+
+u32 max_bpp = 32;
+u32 max_hactive = (u32)~0UL;
+u32 max_vactive = (u32)~0UL;
+unsigned int width, height;
+
+/* get the display entity */
+hdlcd-display = of_display_entity_get(of_node, 0);
+if (hdlcd-display == NULL) {
+ dev_err( hdlcd-dev, HDLCD: cannot get display entity\n);
+return -EPROBE_DEFER;
+}
+
+/* get videomodes from display entity */
+modes_num = display_entity_get_modes(hdlcd-display, modes);
+if (modes_num 0) {
+dev_err( hdlcd-dev, HDLCD: cannot get videomode from display
entity\n);
+return modes_num;
+}
+
+ /* Pick the best (the widest, then the highest) mode from the list */
+of_property_read_u32(of_node, max-hactive, max_hactive);
+
[PATCH 0/2][RFC] CDFv2 for VExpress HDLCD DVI output support
Hi All, This series patches extend Pawel's patches to Versatile Express HDLCD DVI output support. Before apply this patches, please apply Pawel's patches first. This series patches implements base on Linaro release 13.06 branch ll_20130621.0. here is Pawel's patches [1] http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html Show Liu (2): Fixed for compatible with kernel 3.10.0-rc6 CDFv2 for VExpress HDLCD DVI output support arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts |6 +- drivers/video/Kconfig |2 + drivers/video/arm-hdlcd.c | 116 +--- drivers/video/fbmon.c | 12 ++- drivers/video/vexpress-dvimode.c | 11 +++ drivers/video/vexpress-muxfpga.c |8 +- include/linux/arm-hdlcd.h |6 ++ 7 files changed, 142 insertions(+), 19 deletions(-) -- 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] cx24117[v2]: Add new dvb-frontend driver (tested cards: TBS6980 and TBS6981 Dual tuner DVB-S/S2)
[v2] Fixed/changed according to first review. Regards, Luis Signed-off-by: Luis Alves lja...@gmail.com --- drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24117.c | 1645 + drivers/media/dvb-frontends/cx24117.h | 47 + drivers/media/pci/cx23885/Kconfig |1 + drivers/media/pci/cx23885/cx23885-cards.c | 65 ++ drivers/media/pci/cx23885/cx23885-dvb.c | 31 + drivers/media/pci/cx23885/cx23885-input.c | 12 + drivers/media/pci/cx23885/cx23885.h |2 + 9 files changed, 1811 insertions(+) create mode 100644 drivers/media/dvb-frontends/cx24117.c create mode 100644 drivers/media/dvb-frontends/cx24117.h diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 0e2ec6f..bddbab4 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -200,6 +200,13 @@ config DVB_CX24116 help A DVB-S/S2 tuner module. Say Y when you want to support this frontend. +config DVB_CX24117 + tristate Conexant CX24117 based + depends on DVB_CORE I2C + default m if !MEDIA_SUBDRV_AUTOSELECT + help + A Dual DVB-S/S2 tuner module. Say Y when you want to support this frontend. + config DVB_SI21XX tristate Silicon Labs SI21XX based depends on DVB_CORE I2C diff --git a/drivers/media/dvb-frontends/Makefile b/drivers/media/dvb-frontends/Makefile index cebc0fa..f9cb43d 100644 --- a/drivers/media/dvb-frontends/Makefile +++ b/drivers/media/dvb-frontends/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_DVB_ATBM8830) += atbm8830.o obj-$(CONFIG_DVB_DUMMY_FE) += dvb_dummy_fe.o obj-$(CONFIG_DVB_AF9013) += af9013.o obj-$(CONFIG_DVB_CX24116) += cx24116.o +obj-$(CONFIG_DVB_CX24117) += cx24117.o obj-$(CONFIG_DVB_SI21XX) += si21xx.o obj-$(CONFIG_DVB_STV0288) += stv0288.o obj-$(CONFIG_DVB_STB6000) += stb6000.o diff --git a/drivers/media/dvb-frontends/cx24117.c b/drivers/media/dvb-frontends/cx24117.c new file mode 100644 index 000..f55f8a2 --- /dev/null +++ b/drivers/media/dvb-frontends/cx24117.c @@ -0,0 +1,1645 @@ +/* +Conexant cx24117/cx24132 - Dual DVBS/S2 Satellite demod/tuner driver + +Copyright (C) 2013 Luis Alves lja...@gmail.com + July, 6th 2013 + First release based on cx24116 driver by: + Steven Toth and Georg Acher, Darron Broad, Igor Liplianin +Cards currently supported: + TBS6980 - Dual DVBS/S2 PCIe card + TBS6981 - Dual DVBS/S2 PCIe card + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/slab.h +#include linux/kernel.h +#include linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/firmware.h + +#include dvb_frontend.h +#include cx24117.h + + +#define CX24117_DEFAULT_FIRMWARE dvb-fe-cx24117.fw +#define CX24117_SEARCH_RANGE_KHZ 5000 + +/* known registers */ +#define CX24117_REG_COMMAND (0x00) /* command buffer */ +#define CX24117_REG_EXECUTE (0x1f) /* execute command */ + +#define CX24117_REG_FREQ3_0 (0x34) /* frequency */ +#define CX24117_REG_FREQ2_0 (0x35) +#define CX24117_REG_FREQ1_0 (0x36) +#define CX24117_REG_STATE0 (0x39) +#define CX24117_REG_SSTATUS0 (0x3a) /* demod0 signal high / status */ +#define CX24117_REG_SIGNAL0 (0x3b) +#define CX24117_REG_FREQ5_0 (0x3c) /* +-freq */ +#define CX24117_REG_FREQ6_0 (0x3d) +#define CX24117_REG_SRATE2_0 (0x3e) /* +- 1000 * srate */ +#define CX24117_REG_SRATE1_0 (0x3f) +#define CX24117_REG_QUALITY2_0 (0x40) +#define CX24117_REG_QUALITY1_0 (0x41) + +#define CX24117_REG_BER4_0 (0x47) +#define CX24117_REG_BER3_0 (0x48) +#define CX24117_REG_BER2_0 (0x49) +#define CX24117_REG_BER1_0 (0x4a) +#define CX24117_REG_DVBS_UCB2_0 (0x4b) +#define CX24117_REG_DVBS_UCB1_0 (0x4c) +#define CX24117_REG_DVBS2_UCB2_0 (0x50) +#define CX24117_REG_DVBS2_UCB1_0 (0x51) +#define CX24117_REG_QSTATUS0 (0x93) +#define CX24117_REG_CLKDIV0 (0xe6) +#define CX24117_REG_RATEDIV0 (0xf0) + + +#define CX24117_REG_FREQ3_1 (0x55) /* frequency */ +#define CX24117_REG_FREQ2_1 (0x56) +#define CX24117_REG_FREQ1_1 (0x57)
Re: [PATCH v3] ov10635: Add OmniVision ov10635 SoC camera driver
Hi Phil,
On Tuesday 16 July 2013 14:54:41 phil.edwor...@renesas.com wrote:
On 16/07/2013 13:05 Laurent Pinchart wrote:
On Wednesday 05 June 2013 10:11:35 Phil Edworthy wrote:
Signed-off-by: Phil Edworthy phil.edwor...@renesas.com
---
v3:
- Removed dupplicated writes to reg 0x3042
- Program all the standard registers after checking the ID
v2:
- Simplified flow in ov10635_s_ctrl.
- Removed chip ident code - build tested only
drivers/media/i2c/soc_camera/Kconfig |6 +
drivers/media/i2c/soc_camera/Makefile |1 +
drivers/media/i2c/soc_camera/ov10635.c | 1134 +
3 files changed, 1141 insertions(+)
create mode 100644 drivers/media/i2c/soc_camera/ov10635.c
[snip]
diff --git a/drivers/media/i2c/soc_camera/ov10635.c
b/drivers/media/i2c/soc_camera/ov10635.c new file mode 100644
index 000..064cc7b
--- /dev/null
+++ b/drivers/media/i2c/soc_camera/ov10635.c
@@ -0,0 +1,1134 @@
+/*
+ * OmniVision OV10635 Camera Driver
+ *
+ * Copyright (C) 2013 Phil Edworthy
+ * Copyright (C) 2013 Renesas Electronics
+ *
+ * This driver has been tested at QVGA, VGA and 720p, and 1280x800 at
+ * up to 30fps and it should work at any resolution in between and any
+ * frame rate up to 30fps.
+ *
+ * FIXME:
+ * Horizontal flip (mirroring) does not work correctly. The image is
+ * flipped, but the colors are wrong.
Have you checked whether this could be fixed by shifting the crop rectangle by
one pixel ? Color issues with flipping are usually due to the fact that
flipping modifies the Bayer pattern.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/v4l2-mediabus.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+
+/* Register definitions */
+#define OV10635_VFLIP 0x381c
+#defineOV10635_VFLIP_ON (0x3 6)
+#defineOV10635_VFLIP_SUBSAMPLE 0x1
+#define OV10635_HMIRROR 0x381d
+#defineOV10635_HMIRROR_ON 0x3
+#define OV10635_PID 0x300a
+#define OV10635_VER 0x300b
+
+/* IDs */
+#define OV10635_VERSION_REG 0xa635
+#define OV10635_VERSION(pid, ver) (((pid) 8) | ((ver) 0xff))
+
+#define OV10635_SENSOR_WIDTH 1312
+#define OV10635_SENSOR_HEIGHT 814
+
+#define OV10635_MAX_WIDTH 1280
+#define OV10635_MAX_HEIGHT 800
[snip]
+static const struct ov10635_reg ov10635_regs_enable[] = {
+ { 0x3042, 0xf0 }, { 0x301b, 0xf0 }, { 0x301c, 0xf0 },
+ { 0x301a, 0xf0 },
+};
Could you please define macros for register addresses and values ? I
know it's quite a bit of boring work, but without that maintening the
driver would be pretty difficult.
I will ask OmniVision if I can provide the register names.
A quick search unfortunately revealed no leak datasheets, so permission will
indeed be required.
However, I
assume you don't mean I should define macros for all of the registers in
the ov10635_regs_default array?
Ideally that would be great, but I won't nak the patch because of that.
http://git.linuxtv.org/pinchartl/media.git/blob/refs/heads/sensors/ov3640:/drivers/media/i2c/ov3640_regs.h
:-)
--
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
Re: [PATCH 0/2][RFC] CDFv2 for VExpress HDLCD DVI output support
On Wed, 2013-07-17 at 11:08 +0100, Show Liu wrote: This series patches extend Pawel's patches to Versatile Express HDLCD DVI output support. Before apply this patches, please apply Pawel's patches first. This series patches implements base on Linaro release 13.06 branch ll_20130621.0. here is Pawel's patches [1] http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html Glad to see someone thinking the same way ;-) Thanks for trying it and particularly for the fixes in vexpress-* code. I'll keep them in mind when the time comes :-) Of course neither the CDF patch nor the HDLCD driver are upstream yet. Laurent promised to post next (hopefully final ;-) version of his patches soon, but the API has apparently changed so we'll have to adapt to it. As to the HDLCD driver - there is some work going on converting it to DRM/KMS and upstreaming as such, using CDF if it's available by that time as well. Paweł -- 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][RFC] CDFv2 for VExpress HDLCD DVI output support
On Wednesday 17 July 2013 11:49:49 Pawel Moll wrote: On Wed, 2013-07-17 at 11:08 +0100, Show Liu wrote: This series patches extend Pawel's patches to Versatile Express HDLCD DVI output support. Before apply this patches, please apply Pawel's patches first. This series patches implements base on Linaro release 13.06 branch ll_20130621.0. here is Pawel's patches [1] http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html Glad to see someone thinking the same way ;-) Thanks for trying it and particularly for the fixes in vexpress-* code. I'll keep them in mind when the time comes :-) Of course neither the CDF patch nor the HDLCD driver are upstream yet. Laurent promised to post next (hopefully final ;-) I don't think it will be the final version, but there should be no major change to the API after that. I still expect a couple of versions before the code reaches a mergeable stable, but it shouldn't take too long this time. Further enhancements then will likely go in as follow-up patchs. version of his patches soon, Hopefully by the end of the week (which ends on Sunday, not Friday ;-)), give or take a couple of days. but the API has apparently changed so we'll have to adapt to it. As to the HDLCD driver - there is some work going on converting it to DRM/KMS and upstreaming as such, using CDF if it's available by that time as well. -- 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
Re: implement ov3640 driver using subdev-api with omap3-isp
Hi Tom,
On Tuesday 16 July 2013 14:24:59 Tom wrote:
Laurent Pinchart laurent.pinchart at ideasonboard.com writes:
On Monday 15 July 2013 09:23:19 Tom wrote:
Hello,
I am working with a gumstix overo board connected with a e-con-systems
camera module using a ov3640 camera sensor.
Along with the board I got a camera driver
(https://github.com/scottellis/econ-cam-driver)
which can be used with linux kernel 2.6.34, but I want to use the camera
along with the linux kernel 3.5.
So I tried to implement the driver into the kernel sources by referring
to a existing drivers like /driver/media/video/ov9640.c and
/driver/media/video/mt9v032.c.
The old driver has an isp implementation integrated and it registers
itself once as a video device. So the application which is going to use
the camera sensor just needs to open the right video device and by
calling ioctl the corresponding functions will be called.
By going through the linux 3.5 kernel sources I found out that the
omap3-isp registers itself as an video-device and should support
sensors using the v4l2-subdev interface.
So am I right when I think that I just need to add the ov3640 subdev to
the isp_v4l2_subdevs_group in the board-overo.c file and then just open
thevideo device of the isp to use it via application (ioctl)?
I read an article which told me that I need to use the
v4l2_subdev_pad_ops to interact from isp with the ov3640 subdev, but it
does not work. I don't know what I am doing wrong.
Is there already an implemenation of the ov3640 using subdev-api which I
couldn't find or can someone give me a hint what I need to do to get the
sensor with the isp working?
As a matter of fact there's one. You can't be blamed for not finding it,
as it was stored on my computer.
I've rebased the patches on top of the latest linuxtv master branch and
pushed the patches to
git://linuxtv.org/pinchartl/media.git sensors/ov3640
Two caveats:
- The rebased patches have been compile-tested only, I haven't had time to
test them on the hardware. One particular point that might break is the
use of the clock API as a replacement for the OMAP3 ISP .set_xclk()
callback. Any problem that may arise from this shouldn't be too difficult
to fix.
- The driver doesn't work in all resolutions and formats. This is really
work in progress that I haven't had time to finish. The code should be
relatively clean, but the lack of support from Omnivision killed the
schedule (which I've planned too optimistically I have to confess).
Fixes would be very welcome. I'd like to push this driver to mainline at
some point, I'd hate to waste the time I've spent on this.
Hello Laurent,
many thanks for the quick reply.
I'm still a beginner, so please excuse that I have to ask you once again
just to understand the subdev-api and the isp exactly.
No worries. As long as people do a bit of research and read documentation by
themselves beforehand, I'm happy to answer questions and share knowledge.
Is the implementation within the board-overo.c file correct to use the isp
along with your camera driver?
And would it be enough to just open the isp video device within my
application or do I need to open the subdev-device, too when calling ioctl?
You will need to access the subdevs directly to configure the OMAP3 ISP
pipeline before starting the video stream. This task can be performed directly
in a custom application using the media controller and V4L2 subdevs userspace
APIs, or using the media-ctl command line tool
(http://git.ideasonboard.org/media-ctl.git). The topic has been discussed
extensively before and information is available online, both in web pages or
in the linux-media mailing list archives. I don't have exact URLs, so it would
be nice if you could post a couple of pointers in reply to this thread after
searching for information, to help future newcomers.
Once the pipeline is configured you can then capture video frames from the
OMAP3 ISP output using the V4L2 API on the appropriate video node.
Best Regards, Tom
My Code Snippet board-overo.c:
#define LM3553_SLAVE_ADDRESS 0x53
#define OV3640_I2C_ADDR (0x78 1)
int omap3evm_ov3640_platform_data;
int lm3553_platform_data;
static struct i2c_board_info omap3_i2c_boardinfo_ov3640 = {
I2C_BOARD_INFO(ov3640, OV3640_I2C_ADDR),
.platform_data = omap3evm_ov3640_platform_data,
};
static struct i2c_board_info omap3_i2c_boardinfo_lm3553 = {
I2C_BOARD_INFO(lm3553,LM3553_SLAVE_ADDRESS),
.platform_data = lm3553_platform_data,
};
static struct i2c_board_info mt9v032_i2c_device = {
I2C_BOARD_INFO(mt9v032, MT9V032_I2C_ADDR),
.platform_data = mt9v032_platform_data,
};
/*static struct isp_subdev_i2c_board_info mt9v032_subdevs[] = {
{
Re: [PATCH 4/4] qv4l2: add OpenGL video render
On Wednesday, July 17, 2013 01:03:44 PM you wrote:
Hi Bård,
On Tuesday 16 July 2013 14:59:04 Bard Eirik Winther wrote:
On Tuesday, July 16, 2013 02:01:45 PM you wrote:
Hi Bård,
Thank you for the patches.
On Tuesday 16 July 2013 13:24:08 Bård Eirik Winther wrote:
The qv4l2 test utility now supports OpenGL-accelerated display of video.
This allows for using the graphics card to render the video content to
screen and to performing color space conversion.
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
configure.ac| 8 +-
utils/qv4l2/Makefile.am | 9 +-
utils/qv4l2/capture-win.cpp | 559 +++--
utils/qv4l2/capture-win.h | 81 ++-
utils/qv4l2/qv4l2.cpp | 173 +++---
utils/qv4l2/qv4l2.h | 8 +
6 files changed, 782 insertions(+), 56 deletions(-)
Is there a chance you could split the OpenGL code to separate classes, in
a
separate source file ? This would allow implementing other renderers, such
as KMS planes on embedded devices.
Hi.
Do you mean to separate the GL class only or all the different
shaders/renderes as well?
Basically, what would be nice to get is an easy way to extend qv4l2 with
different renderers. OpenGL is fine on the desktop, but for embedded devices
a
KMS planes backend would work best given the mess that the embedded GPU
situation is. Instead of adding #ifdef ENABLE_OGL and if (use_ogl) through
the
code, abstracting the rendering code in a separate base class that renderers
could inherit from would make the code simpler to read, maintain and extend.
I haven't looked at the details so I'm not sure how much work that would be,
but if the effort is reasonable I think it would be a nice improvement.
I belive I have found a workable solution that should not take that much of
time to implement.
The current interface for adding more render/display options is simply to
extend this class:
class CaptureCanvas {
public:
CaptureCanvas(){}
virtual ~CaptureCanvas();
virtual void setFrame(int width, int height, unsigned char *data, __u32
format);
virtual void start();
virtual void stop();
virtual void hasNativeFormat(__u32 format);
virtual static bool isSupportedRender();
};
It should cover any needs for display afaik, but then again I do not know every
system that exists which might require more interaction.
--
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/5] Davinci VPBE use devres and some cleanup
Hi Prabhakar, On Saturday 13 July 2013 14:20:26 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series replaces existing resource handling in the driver with managed device resource. Thank you for the patches. They greatly simplify the probe/remove functions, I like that. For patches 1 to 4, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I have the same concern as Joe Perches for patch 5. Lad, Prabhakar (5): media: davinci: vpbe_venc: convert to devm_* api media: davinci: vpbe_osd: convert to devm_* api media: davinci: vpbe_display: convert to devm* api media: davinci: vpss: convert to devm* api media: davinci: vpbe: Replace printk with dev_* drivers/media/platform/davinci/vpbe.c |6 +- drivers/media/platform/davinci/vpbe_display.c | 23 ++ drivers/media/platform/davinci/vpbe_osd.c | 45 +++- drivers/media/platform/davinci/vpbe_venc.c| 97 - drivers/media/platform/davinci/vpss.c | 62 5 files changed, 52 insertions(+), 181 deletions(-) -- 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
Re: [omap3isp] xclk deadlock
Hi Jakub, (CC'ing Tomi Valkeinen) On Friday 12 July 2013 16:44:44 Jakub Piotr Cłapa wrote: Hi Laurent, On 05.07.13 12:48, Laurent Pinchart wrote: Thanks for the explanation. It would be great if you could update your board/beagle/mt9p031 branch and include the discussed changes. Done. Could you please test it ? Thanks for you help. There are no errors about the clocks or regulators now but the rest does not work so well (everything mentioned below works fine on my old 3.2.24 kernel): 1. The images streamed to omapdss using omap3-isp-live look like they lost synchronization with a black bar horizontal bar jumping on the screen and other such artifacts (it looks as if both width and height were invalid). The framerate is about a half of what it should be. Adjusting the camera iris changes the lightness of the image so the whole pipeline is working to some extent (so these artifacts are not just some random memory patterns). The Register dumps are a little different between 3.2.24 and 3.10 [4]. 2. When exiting from live the kernel hangs more often then not (sometimes it is accompanied by Unhandled fault: external abort on non-linefetch in dispc_write_irqenable in omapdss). I'll pass this one to Tomi :-) 3. After setting up a simple pipeline using media-ctl[2] I get CCDC won't become idle errors. If I do this after running live I also get (unless it hangs) the CCDC Register dump [1]. Otherwise I only get the stream of kernel log messages without anything else from omap3isp. 4. I recreated the live pipeline (judging by the lack of differences in media-ctl -p output [3]) and used yavta. I get the same hangs but when I don't I can check the UYVY frames one by one. They look bad at any stride (I dropped the UV components and tried to get some meaningful output in the GIMP raw image data import dialog by adjustung the width). Would you be able to bisect the problems ? Please also see below for more comments. As a side note, you can use raw2rgbpnm (https://gitorious.org/raw2rgbpnm) to convert raw binary images to a more usable format. [1]: [ 153.774017] omap3isp omap3isp: -CCDC Register dump- [ 153.781494] omap3isp omap3isp: ###CCDC PCR=0x [ 153.786773] omap3isp omap3isp: ###CCDC SYN_MODE=0x00030400 [ 153.792572] omap3isp omap3isp: ###CCDC HD_VD_WID=0x [ 153.798431] omap3isp omap3isp: ###CCDC PIX_LINES=0x [ 153.804290] omap3isp omap3isp: ###CCDC HORZ_INFO=0x031f [ 153.810180] omap3isp omap3isp: ###CCDC VERT_START=0x [ 153.816101] omap3isp omap3isp: ###CCDC VERT_LINES=0x0257 [ 153.822052] omap3isp omap3isp: ###CCDC CULLING=0x00ff [ 153.827728] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x0640 [ 153.833648] omap3isp omap3isp: ###CCDC SDOFST=0x [ 153.839263] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000 [ 153.845001] omap3isp omap3isp: ###CCDC CLAMP=0x0010 [ 153.850524] omap3isp omap3isp: ###CCDC DCSUB=0x [ 153.855987] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11 [ 153.861602] omap3isp omap3isp: ###CCDC BLKCMP=0x [ 153.867156] omap3isp omap3isp: ###CCDC FPC=0x [ 153.872497] omap3isp omap3isp: ###CCDC FPC_ADDR=0x [ 153.878265] omap3isp omap3isp: ###CCDC VDINT=0x02560190 [ 153.883789] omap3isp omap3isp: ###CCDC ALAW=0x0004 [ 153.889221] omap3isp omap3isp: ###CCDC REC656IF=0x [ 153.894958] omap3isp omap3isp: ###CCDC CFG=0x8000 [ 153.900299] omap3isp omap3isp: ###CCDC FMTCFG=0xc000 [ 153.905853] omap3isp omap3isp: ###CCDC FMT_HORZ=0x0320 [ 153.911651] omap3isp omap3isp: ###CCDC FMT_VERT=0x0258 [ 153.917388] omap3isp omap3isp: ###CCDC PRGEVEN0=0x [ 153.923187] omap3isp omap3isp: ###CCDC PRGEVEN1=0x [ 153.928955] omap3isp omap3isp: ###CCDC PRGODD0=0x [ 153.934661] omap3isp omap3isp: ###CCDC PRGODD1=0x [ 153.940338] omap3isp omap3isp: ###CCDC VP_OUT=0x04ae3200 [ 153.945922] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600 [ 153.951873] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x [ 153.957916] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x [ 153.964233] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x [ 153.970733] omap3isp omap3isp: [ 154.174468] omap3isp omap3isp: CCDC won't become idle! [ 154.315917] omap3isp omap3isp: CCDC won't become idle! [ 154.340118] omap3isp omap3isp: CCDC won't become idle! [ 154.364349] omap3isp omap3isp: CCDC won't become idle! [ 154.388549] omap3isp omap3isp: CCDC won't become idle! [ 154.412750] omap3isp omap3isp: CCDC won't become idle! [ 154.436950] omap3isp omap3isp: CCDC won't become idle! [ 154.461151] omap3isp omap3isp: CCDC won't become idle! [ 154.485382] omap3isp omap3isp: CCDC won't become idle! [2]: media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Re: [PATCH] videobuf2-dma-sg: Minimize the number of dma segments
Hello, On 7/17/2013 11:43 AM, Ricardo Ribalda Delgado wrote: Hi Marek alloc_pages_exact returns pages of order 0, every single page is filled into buf-pages, that then is used by vb2_dma_sg_mmap(), that also expects order 0 pages (its loops increments in PAGE_SIZE). The code has been tested on real HW. Your concern is that that alloc_pages_exact splits the higher order pages? Do you want that videobuf2-dma-sg to have support for higher order pages? Ah... My fault. I didn't notice that you recalculate req_pages at the begginning of each loop iteration, so the code is correct, buf-pages is filled correctly with order 0 pages. So now the only issue I see is the oversized sglist allocation (the size of sg list is computed for worst case, 0 order pages) and lack of the max segment size support. Sadly there are devices which can handle single sg chunk up to some predefined size (see dma_get_max_seg_size() function). For some reference code, please check __iommu_map_sg() and maybe __iommu_alloc_buffer() functions in arch/arm/mm/dma-mapping.c Best regards -- Marek Szyprowski Samsung RD Institute Poland -- 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: mb86a20s and cx23885
Hi all El 15/07/13 17:30, Mauro Carvalho Chehab escribió: Em Mon, 15 Jul 2013 16:30:18 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all After some time trying to see what the problem is, I have found it is not come the RF signal. I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-) When I try to apply these changes to a 3.4 or later kernel does not tune plate. Between 3.2 and 3.4 kernel there are several changes to the drivers: CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune. If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it. Mauro Thanks for the suggestion. This weekend I have some time and I'll study how to implement it. I guess it's do something similar to: ~ $ git clone git://linuxtv.org/media_build.git ~ $ cd media_build ~/media_build $./build --main-git ~/media_build $ cd media ~/media $ gedit drivers/media/video/foo.c ~/media $ make -C ../v4l ~/media $ make -C ../ install ~/media $ make -C .. rmmod ~/media $ modprobe foo You can do (using Linus git tree): git checkout v3.4 git bisect bad git checkout good v3.2 Where is the git tree of Linus in git://git.kernel.org/ or git://linuxtv.org/? Thanks again, Alfredo git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as bad or good, until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions. For more reference, you can take a look, for example, at: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git Regards, Mauro PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect. The changes I have applied to kernel 3.2 are: -- 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] videobuf2-dma-sg: Minimize the number of dma segments
Hello again
I have made some experiments and have replaced alloc_pages_exact with
alloc_pages of order N. Unfortunatelly vm_insert_page and vm_map_ram
does not work as expected.
vm_insert_page, only insert the PAGE_SIZE bytes of the higher order
page, if I try to add the other pages manually, the function returns
-22 due to count=0.
vm_map_ram is designed to work with exactly order 0 pages.
it works fine if I manually split the page, but the header file
suggest that function should not be called by the drivers... (although
this is not a device driver).
Here you can see my experiment in case you want to replicate it.
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 89 ++--
1 file changed, 72 insertions(+), 17 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..bbb3680 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -24,6 +24,8 @@
static int debug;
module_param(debug, int, 0644);
+#define PAGE_SPLIT
+
#define dprintk(level, fmt, arg...) \
do { \
if (debug = level) \
@@ -42,10 +44,69 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ int size = buf-sg_desc.size;
+
+ while (size 0) {
+ struct page *pages;
+ int order;
+#ifdef PAGE_SPLIT
+ int i;
+#endif
+
+ order = get_order(size);
+ /* Dont over allocate*/
+ if ((PAGE_SIZE order) size)
+ order--;
+
+ pages = NULL;
+ while (!pages) {
+ pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
+ __GFP_NOWARN | gfp_flags, order);
+ if (pages)
+ break;
+
+
+ if (order == 0)
+ while (--last_page = 0) {
+ __free_pages(
+ buf-pages[last_page],
+ get_order(sg_dma_len
+ (buf-sg_desc.sglist[last_page])));
+ return -ENOMEM;
+ }
+ order--;
+ }
+
+#ifdef PAGE_SPLIT
+ split_page(pages, order);
+ for (i = 0; i (1order); i++) {
+ buf-pages[last_page] = pages + i;
+ sg_set_page(buf-sg_desc.sglist[last_page],
+ buf-pages[last_page], PAGE_SIZE, 0);
+ last_page++;
+ }
+#else
+ buf-pages[last_page] = pages;
+ sg_set_page(buf-sg_desc.sglist[last_page],
+ buf-pages[last_page], PAGE_SIZE order, 0);
+ last_page++;
+#endif
+ size -= PAGE_SIZE order;
+ }
+
+ buf-sg_desc.num_pages = last_page;
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size,
gfp_t gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +130,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx,
unsigned long size, gfp_t gfp_fla
if (!buf-pages)
goto fail_pages_array_alloc;
- for (i = 0; i buf-sg_desc.num_pages; ++i) {
- buf-pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf-pages[i])
- goto fail_pages_alloc;
- sg_set_page(buf-sg_desc.sglist[i],
-buf-pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf-handler.refcount = buf-refcount;
buf-handler.put = vb2_dma_sg_put;
@@ -89,8 +145,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx,
unsigned long size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i = 0)
- __free_page(buf-pages[i]);
kfree(buf-pages);
fail_pages_array_alloc:
@@ -111,9 +165,10 @@ static void vb2_dma_sg_put(void *buf_priv)
buf-sg_desc.num_pages);
if (buf-vaddr)
vm_unmap_ram(buf-vaddr, buf-sg_desc.num_pages);
- vfree(buf-sg_desc.sglist);
while (--i = 0)
- __free_page(buf-pages[i]);
+ __free_pages(buf-pages[i], get_order(
+ sg_dma_len(buf-sg_desc.sglist[i])));
+ vfree(buf-sg_desc.sglist);
kfree(buf-pages);
kfree(buf);
}
@@ -248,14 +303,14 @@ static int vb2_dma_sg_mmap(void *buf_priv,
struct vm_area_struct *vma)
do {
int ret;
- ret = vm_insert_page(vma, uaddr, buf-pages[i++]);
+ ret = vm_insert_page(vma, uaddr, buf-pages[i]);
if (ret) {
printk(KERN_ERR Remapping memory, error: %d\n, ret);
return ret;
}
-
- uaddr += PAGE_SIZE;
- usize -= PAGE_SIZE;
+ uaddr += sg_dma_len(buf-sg_desc.sglist[i]);
+ usize -= sg_dma_len(buf-sg_desc.sglist[i]);
+ i++;
} while (usize 0);
--
1.7.10.4
On Wed, Jul 17, 2013 at 11:43 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hi Marek
alloc_pages_exact returns pages of order 0, every single page is
filled into buf-pages, that then is used by vb2_dma_sg_mmap(), that
also expects order 0 pages (its loops increments in PAGE_SIZE). The
code has been tested on real HW.
Your concern is that that alloc_pages_exact splits the higher order pages?
Do you want that videobuf2-dma-sg to have support for higher order pages?
Best regards
PS: sorry for the duplicated post, previous one contained html parts
and was rejected by the list
On Wed, Jul 17, 2013 at 10:27 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On 7/15/2013 11:34 AM, Ricardo Ribalda Delgado
Re: [PATCH] videobuf2-dma-sg: Minimize the number of dma segments
Hello again Marek In my system I am doing the scatter gather compaction on device driver... But I agree that it would be better done on the vb2 layer. For the oversize sglist we could do one of this two things. If we want to have a simple pass processing we have to allocate an structure A for the worts case, work on that structure. then allocate a structure B for the exact size that we need, memcpy A to B, and free(A). Otherwise we need two passes. One to allocate the pages, and another one to allocate the pages and find out the amount of sg, and another to greate the sg structure. What do you prefer? Regards! On Wed, Jul 17, 2013 at 3:42 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On 7/17/2013 11:43 AM, Ricardo Ribalda Delgado wrote: Hi Marek alloc_pages_exact returns pages of order 0, every single page is filled into buf-pages, that then is used by vb2_dma_sg_mmap(), that also expects order 0 pages (its loops increments in PAGE_SIZE). The code has been tested on real HW. Your concern is that that alloc_pages_exact splits the higher order pages? Do you want that videobuf2-dma-sg to have support for higher order pages? Ah... My fault. I didn't notice that you recalculate req_pages at the begginning of each loop iteration, so the code is correct, buf-pages is filled correctly with order 0 pages. So now the only issue I see is the oversized sglist allocation (the size of sg list is computed for worst case, 0 order pages) and lack of the max segment size support. Sadly there are devices which can handle single sg chunk up to some predefined size (see dma_get_max_seg_size() function). For some reference code, please check __iommu_map_sg() and maybe __iommu_alloc_buffer() functions in arch/arm/mm/dma-mapping.c Best regards -- Marek Szyprowski Samsung RD Institute Poland -- Ricardo Ribalda -- 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: [RFC v2 05/10] exynos5-fimc-is: Adds the sensor subdev
On 07/17/2013 06:55 AM, Arun Kumar K wrote: On Wed, Jul 17, 2013 at 3:33 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 07/09/2013 02:04 PM, Arun Kumar K wrote: On Wed, Jun 26, 2013 at 12:57 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Fri May 31 2013 15:03:23 Arun Kumar K wrote: FIMC-IS uses certain sensors which are exclusively controlled from the IS firmware. This patch adds the sensor subdev for the fimc-is sensors. Signed-off-by: Arun Kumar Karun...@samsung.com Signed-off-by: Kilyeon Imkilyeon...@samsung.com Not surprisingly I really hate the idea of sensor drivers that are tied to a specific SoC, since it completely destroys the reusability of such drivers. Yes agree to it. I understand that you have little choice to do something special here, but I was wondering whether there is a way of keeping things as generic as possible. I'm just brainstorming here, but as far as I can see this driver is basically a partial sensor driver: it handles the clock, the format negotiation and power management. Any sensor driver needs that. What would be nice is if the fmic specific parts are replaced by callbacks into the bridge driver using v4l2_subdev_notify(). The platform data (or DT) can also state if this sensor is firmware controlled or not. If not, then the missing bits can be implemented in the future by someone who needs that. That way the driver itself remains independent from fimc. And existing sensor drivers can be adapted to be usable with fimc as well by adding support for the notify callback. Would a scheme along those lines work? Yes this should make the implementation very generic. Will check the feasibility of this approach. Is I suggested earlier, you likely could do without this call back to the FIMC-IS from within the sensor subdev. Look at your call chain right now: /dev/video? media-dev-driversensor-subdev FIMC-IS | | | | | VIDIOC_STREAMON | | | |# s_stream()| | | #--# pipeline_open() | | | # | | | # pipeline_start() | | | # | | | | | Couldn't you move pipeline_open(), pipeline_start() to s_stream handler of the ISP subdev ? It is currently empty. The media device driver could call s_stream on the ISP subdev each time it sees s_stream request on the sensor subdev. And you wouldn't need any hacks to get the pipeline pointer in the sensor subdev. Then it would be something like: /dev/video? media-dev-driversensor-subdev FIMC-IS-ISP-subdev | | | | | VIDIOC_STREAMON | | | |# s_stream()| | | #--| | | # s_stream()| | | #---+# pipeline_open() | | | # pipeline_start() | | | # I suppose pipeline_open() is better candidate for the s_power callback. It just needs to be ensured at the media device level the subdev operations sequences are correct. It can be done this way. But my intention of putting these calls in the sensor subdev was to use the sensor subdev independent of isp subdev. This is for the usecase where the pipeline will only contain is-sensor -- mipi-csis -- fimc-lite --- memory This way you can capture the bayer rgb data from sensor without using any isp components at all. The second pipeline which is isp -- scc -- scp can be used for processing the sensor data and can be created and used if needed. In the method you mentioned, the isp subdev has to be used even when it is not part of the pipeline. Is that allowed? If its allowed as per media pipeline guidelines, then this definitely is a better approach. Please suggest on this. Sure, I'm aware of those two relatively separate pipelines. s_power, s_stream callbacks belong to the kernel so I don't think it would be an issue to do it as I described. Please note s_power, s_stream are normally reference counted. Alternatively you could create a separate subdev for the FIMC-IS firmware interface. Such subdev wouldn't be exposing device node and would be used by the media pipeline controller driver to ensure proper hardware configuration sequences. I don't know the Exynos5 FIMC-IS firmware architecture very well so I'm not sure if it is worth to create such a separate subdev as the firmware interface obstruction layer ;) I guess we could do only with subdevs that are
[PATCH v2 0/5] Renesas VSP1 driver
Hello, Here's the second version of the VSP1 engine (a Video Signal Processor found in several Renesas R-Car SoCs) driver. Many thanks to Hans Verkuil for his very quick review of v1. The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, a documentation fix and new pixel format and media bus code definitions. The last patch finally adds the VSP1 driver. Changes since v1: - Updated to the v3.11 media controller API changes - Only add the LIF entity to the entities list when the LIF is present - Added a MODULE_ALIAS() - Fixed file descriptions in comment blocks - Removed function prototypes for the unimplemented destroy functions - Fixed a typo in the HST register name - Fixed format propagation for the UDS entities - Added v4l2_capability::device_caps support - Prefix the device name with platform: in bus_info - Zero the v4l2_pix_format priv field in the internal try format handler - Use vb2_is_busy() instead of vb2_is_streaming() when setting the format - Use the vb2_ioctl_* handlers where possible Laurent Pinchart (5): media: Fix circular graph traversal v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB and AYUV on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 +-- Documentation/DocBook/media_api.tmpl |6 + drivers/media/media-entity.c | 17 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|2 + drivers/media/platform/vsp1/Makefile |5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 487 + drivers/media/platform/vsp1/vsp1_entity.c | 186 drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 237 drivers/media/platform/vsp1/vsp1_lif.h | 37 + drivers/media/platform/vsp1/vsp1_regs.h| 581 ++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 drivers/media/platform/vsp1/vsp1_rwpf.c| 124 +++ drivers/media/platform/vsp1/vsp1_rwpf.h| 53 + drivers/media/platform/vsp1/vsp1_uds.c | 345 ++ drivers/media/platform/vsp1/vsp1_uds.h | 40 + drivers/media/platform/vsp1/vsp1_video.c | 1129 drivers/media/platform/vsp1/vsp1_video.h | 144 +++ drivers/media/platform/vsp1/vsp1_wpf.c | 233 include/linux/platform_data/vsp1.h | 25 + include/uapi/linux/v4l2-mediabus.h |6 +- include/uapi/linux/videodev2.h |2 + 26 files changed, 4428 insertions(+), 373 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml create mode 100644 drivers/media/platform/vsp1/Makefile create mode 100644 drivers/media/platform/vsp1/vsp1.h create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h create mode 100644 drivers/media/platform/vsp1/vsp1_video.c create mode 100644 drivers/media/platform/vsp1/vsp1_video.h create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c create mode 100644 include/linux/platform_data/vsp1.h -- 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
[PATCH v2 4/5] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a
luma plane followed by an interleaved chroma plane. The planes are not
required to be contiguous in memory, and the formats can only be used
with the multi-planar formats API.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 170 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/uapi/linux/videodev2.h | 2 +
3 files changed, 173 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..84a8bb3
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,170 @@
+refentry
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M
('NM61')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname
id=V4L2-PIX-FMT-NV16MconstantV4L2_PIX_FMT_NV16M/constant/refname
+ refname
id=V4L2-PIX-FMT-NV61MconstantV4L2_PIX_FMT_NV61M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant and
constantV4L2_PIX_FMT_NV61/constant with planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:0 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane is the same width and height, in bytes, as the Y plane.
+Each CbCr pair belongs to four pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Y'subscript00/subscript, Y'subscript01/subscript,
+Y'subscript10/subscript, Y'subscript11/subscript.
+constantV4L2_PIX_FMT_NV61M/constant is the same as
constantV4L2_PIX_FMT_NV16M/constant
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte./para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript02/subscript/entry
+ entryCrsubscript02/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript12/subscript/entry
+
[PATCH v2 3/5] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 + Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..9100674 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ colspec colname=id align=left / colspec colname=code align=center/ colspec colname=bit / - colspec colnum=4 colname=b23 align=center / - colspec colnum=5 colname=b22 align=center / - colspec colnum=6 colname=b21 align=center / - colspec colnum=7 colname=b20 align=center / - colspec colnum=8 colname=b19 align=center / - colspec colnum=9 colname=b18 align=center / - colspec colnum=10 colname=b17 align=center / - colspec colnum=11 colname=b16 align=center / - colspec colnum=12 colname=b15 align=center / - colspec colnum=13 colname=b14 align=center / - colspec colnum=14 colname=b13 align=center / - colspec colnum=15 colname=b12 align=center / - colspec colnum=16 colname=b11 align=center / - colspec colnum=17 colname=b10 align=center / - colspec colnum=18 colname=b09 align=center / - colspec colnum=19 colname=b08 align=center / - colspec colnum=20 colname=b07 align=center / - colspec colnum=21 colname=b06 align=center / - colspec colnum=22 colname=b05 align=center / - colspec colnum=23 colname=b04 align=center / - colspec colnum=24 colname=b03 align=center / - colspec colnum=25 colname=b02 align=center / - colspec colnum=26 colname=b01 align=center / - colspec colnum=27 colname=b00 align=center / - spanspec namest=b23 nameend=b00 spanname=b0 / + colspec colnum=4 colname=b31 align=center / + colspec colnum=5 colname=b20 align=center / + colspec colnum=6 colname=b29 align=center / + colspec colnum=7 colname=b28 align=center / + colspec colnum=8 colname=b27 align=center / + colspec colnum=9 colname=b26 align=center / + colspec colnum=10 colname=b25 align=center / + colspec colnum=11 colname=b24 align=center / + colspec colnum=12 colname=b23 align=center / + colspec colnum=13 colname=b22 align=center / + colspec colnum=14 colname=b21 align=center / + colspec colnum=15 colname=b20 align=center / + colspec colnum=16 colname=b19 align=center / + colspec colnum=17 colname=b18 align=center / + colspec colnum=18 colname=b17 align=center / + colspec colnum=19 colname=b16 align=center / + colspec colnum=20 colname=b15 align=center / + colspec colnum=21 colname=b14 align=center / + colspec colnum=22 colname=b13 align=center / + colspec colnum=23 colname=b12 align=center / + colspec colnum=24 colname=b11 align=center / + colspec colnum=25 colname=b10 align=center / + colspec colnum=26 colname=b09 align=center / + colspec colnum=27 colname=b08 align=center / + colspec colnum=28 colname=b07 align=center / + colspec colnum=29 colname=b06 align=center / + colspec colnum=30 colname=b05 align=center / + colspec colnum=31 colname=b04 align=center / + colspec colnum=32 colname=b03 align=center / + colspec colnum=33 colname=b02 align=center / + colspec colnum=34 colname=b01 align=center / + colspec colnum=35 colname=b00 align=center / + spanspec namest=b31 nameend=b00 spanname=b0 / thead row entryIdentifier/entry @@ -133,6 +141,14 @@ entry/entry entry/entry entryBit/entry + entry31/entry + entry30/entry + entry29/entry + entry28/entry + entry27/entry + entry26/entry + entry25/entry + entry24/entry entry23/entry entry22/entry entry21/entry @@ -164,7 +180,7 @@ entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_BE/entry entry0x1001/entry entry/entry - dash-ent-16; + dash-ent-24; entry0/entry entry0/entry entry0/entry @@ -178,7 +194,7 @@ entry/entry entry/entry entry/entry - dash-ent-16; + dash-ent-24; entrygsubscript3/subscript/entry entrygsubscript2/subscript/entry entrygsubscript1/subscript/entry @@ -192,7 +208,7 @@
[PATCH v2 1/5] media: Fix circular graph traversal
The graph traversal API (media_entity_graph_walk_*) will fail to
correctly walk the graph when circular links exist. Fix it by checking
whether an entity is already present in the stack before pushing it.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/media-entity.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index cb30ffb..c8aba5e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -121,9 +121,9 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
-#define link_top(en) ((en)-stack[(en)-top].link)
-#define stack_top(en) ((en)-stack[(en)-top].entity)
+#define stack_peek(en, i) ((en)-stack[i].entity)
+#define link_top(en) ((en)-stack[(en)-top].link)
+#define stack_top(en) ((en)-stack[(en)-top].entity)
/**
* media_entity_graph_walk_start - Start walking the media graph at a given
entity
@@ -159,6 +159,8 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
struct media_entity *
media_entity_graph_walk_next(struct media_entity_graph *graph)
{
+ unsigned int i;
+
if (stack_top(graph) == NULL)
return NULL;
@@ -181,8 +183,13 @@ media_entity_graph_walk_next(struct media_entity_graph
*graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Is the entity already in the path? */
+ for (i = 1; i graph-top; ++i) {
+ if (next == stack_peek(graph, i))
+ break;
+ }
+
+ if (i graph-top) {
link_top(graph)++;
continue;
}
--
1.8.1.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 v2 2/5] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value
The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ /row row id=V4L2-MBUS-FMT-YUV10-1X30 entryV4L2_MBUS_FMT_YUV10_1X30/entry - entry0x2014/entry + entry0x2016/entry entry/entry entryysubscript9/subscript/entry entryysubscript8/subscript/entry -- 1.8.1.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
CFP for Graphics and Display uConf at LPC 2013
Hi all, It's time to start nailing down the agenda for the Graphics and Display microconference at the Linux Plumbers Conference 2013. For conference approval and preliminary planning purposes, we have compiled a list of possible topics for discussion. The overview and general list of topic ideas is available here: http://wiki.linuxplumbersconf.org/2013:graphics_and_display The final topics for the microconference need to be formally proposed and accepted. We would like to focus on topics which would benefit from discussion to determine project/feature direction, rather than those which are well defined and looking for a likely person to do an implementation. Instructions for how to formally submit a presentation are available here: http://www.linuxplumbersconf.org/2013/submitting-microconference-discussion-topics/ Please feel free to update the wiki if there are topic ideas you think we have overlooked, and feel free to start a thread in response to this message if you want a more public forum for validating your topic idea; of course, you should also be submitting your ideas formally :-). We are also thinking that there may be some topics that could cross over with the Android microconference (leads on cc). For key attendees who think they will need travel assistance to attend, the deadline is July 18th, the budget is very limited, and the requests need to go through the conference committee. If you have any questions or concerns about the microconference, please feel free to contact us. Looking forward to seeing everyone in New Orleans. -- Thanks in advance, Jesse Barker (jesse 'dot' barker 'at' arm 'dot' com) Laurent Pinchart (laurent 'dot' pinchart 'at' ideasonboard 'dot' com) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC FINAL v5] media: OF: add sync-on-green-active property
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- Changes for v5: 1: Changed description for sync-on-green-active property in documentation file as suggested by Sylwester. Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |2 ++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..ce719f8 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -88,6 +88,8 @@ Optional endpoint properties - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for + LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift, v)) bus-data_shift = v; + if (!of_property_read_u32(node, sync-on-green-active, v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH (1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- 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 RFC FINAL v5] media: OF: add sync-on-green-active property
On 07/17/2013 05:47 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Thanks Prabhakar, it looks good to me. Just a side note, the 'From' tag above isn't needed. It wasn't added automatically, was it ? Unless there are comments from others I think this patch should be merged together with the users of this new property. Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Regards, Sylwester --- Changes for v5: 1: Changed description for sync-on-green-active property in documentation file as suggested by Sylwester. Changes for v4: 1: Fixed review comments pointed by Sylwester. Changes for v3: 1: Fixed review comments pointed by Laurent and Sylwester. RFC v2 https://patchwork.kernel.org/patch/2578091/ RFC V1 https://patchwork.kernel.org/patch/2572341/ .../devicetree/bindings/media/video-interfaces.txt |2 ++ drivers/media/v4l2-core/v4l2-of.c |4 include/media/v4l2-mediabus.h |2 ++ 3 files changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index e022d2d..ce719f8 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -88,6 +88,8 @@ Optional endpoint properties - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for + LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry determines the logical lane number, while the value of an entry indicates physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index aa59639..5c4c9f0 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -100,6 +100,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, if (!of_property_read_u32(node, data-shift, v)) bus-data_shift = v; + if (!of_property_read_u32(node, sync-on-green-active, v)) + flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH : + V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW; + bus-flags = flags; } diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 83ae07e..d47eb81 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -40,6 +40,8 @@ #define V4L2_MBUS_FIELD_EVEN_HIGH(1 10) /* FIELD = 1/0 - Field1 (odd)/Field2 (even) */ #define V4L2_MBUS_FIELD_EVEN_LOW (1 11) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH (1 12) +#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 13) /* Serial flags */ /* How many lanes the client can use */ -- Sylwester Nawrocki Samsung RD Institute Poland -- 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 v3] media: i2c: tvp7002: add OF support
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the tvp7002 driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch depends on https://patchwork.kernel.org/patch/2828800/
Changes for v3:
1: Fixed review comments pointed by Sylwester.
.../devicetree/bindings/media/i2c/tvp7002.txt | 43 +
drivers/media/i2c/tvp7002.c| 67 ++--
2 files changed, 103 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
new file mode 100644
index 000..744125f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
@@ -0,0 +1,43 @@
+* Texas Instruments TV7002 video decoder
+
+The TVP7002 device supports digitizing of video and graphics signal in RGB and
+YPbPr color space.
+
+Required Properties :
+- compatible : Must be ti,tvp7002
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+- sync-on-green-active: Active state of Sync-on-green signal property of the
+ endpoint, 0/1 for normal/inverted operation respectively.
+
+- field-even-active: Active-high Field ID polarity of the endpoint.
+
+For further reading of port node refer Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp7002@5c {
+ compatible = ti,tvp7002;
+ reg = 0x5c;
+
+ port {
+ tvp7002_1: endpoint {
+ hsync-active = 1;
+ vsync-active = 1;
+ pclk-sample = 0;
+ sync-on-green-active = 1;
+ field-even-active = 0;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index f6b1f3f..24a08fa 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -35,6 +35,8 @@
#include media/v4l2-device.h
#include media/v4l2-common.h
#include media/v4l2-ctrls.h
+#include media/v4l2-of.h
+
#include tvp7002_reg.h
MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
@@ -943,6 +945,48 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
.pad = tvp7002_pad_ops,
};
+static struct tvp7002_config *
+tvp7002_get_pdata(struct i2c_client *client)
+{
+ struct v4l2_of_endpoint bus_cfg;
+ struct tvp7002_config *pdata;
+ struct device_node *endpoint;
+ unsigned int flags;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ endpoint = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ if (!endpoint)
+ return NULL;
+
+ pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ v4l2_of_parse_endpoint(endpoint, bus_cfg);
+ flags = bus_cfg.bus.parallel.flags;
+
+ if (flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pdata-hs_polarity = 1;
+
+ if (flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pdata-vs_polarity = 1;
+
+ if (flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pdata-clk_polarity = 1;
+
+ if (flags V4L2_MBUS_FIELD_EVEN_HIGH)
+ pdata-fid_polarity = 1;
+
+ if (flags V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH)
+ pdata-sog_polarity = 1;
+
+done:
+ of_node_put(endpoint);
+ return pdata;
+}
+
/*
* tvp7002_probe - Probe a TVP7002 device
* @c: ptr to i2c_client struct
@@ -954,32 +998,32 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
*/
static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
{
+ struct tvp7002_config *pdata = tvp7002_get_pdata(c);
struct v4l2_subdev *sd;
struct tvp7002 *device;
struct v4l2_dv_timings timings;
int polarity_a;
int polarity_b;
u8 revision;
-
int error;
+ if (pdata == NULL) {
+ dev_err(c-dev, No platform data\n);
+ return -EINVAL;
+ }
+
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c-adapter,
I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
return -EIO;
- if (!c-dev.platform_data) {
- v4l_err(c, No platform data!!\n);
- return -ENODEV;
- }
-
device = devm_kzalloc(c-dev, sizeof(struct tvp7002), GFP_KERNEL);
if (!device)
Re: [PATCH RFC FINAL v5] media: OF: add sync-on-green-active property
Hi Sylwester, On Wed, Jul 17, 2013 at 9:50 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 07/17/2013 05:47 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch adds 'sync-on-green-active' property as part of endpoint property. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Thanks Prabhakar, it looks good to me. Just a side note, the 'From' tag above isn't needed. It wasn't added automatically, was it ? Yes this was added automatically. Unless there are comments from others I think this patch should be merged together with the users of this new property. Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Thanks for the Ack. -- Regards, Prabhakar Lad -- 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/5] Davinci VPBE use devres and some cleanup
Hi Laurent, On Wed, Jul 17, 2013 at 5:51 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, On Saturday 13 July 2013 14:20:26 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series replaces existing resource handling in the driver with managed device resource. Thank you for the patches. They greatly simplify the probe/remove functions, I like that. For patches 1 to 4, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks for the ACK. I have the same concern as Joe Perches for patch 5. Ok I'll fix it and repost the alone patch 5/5. -- Regards, Prabhakar Lad -- 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
Vážení E-mail užívateľa;
Vážení E-mail užívateľa; Prekročili ste 23432 boxy nastaviť svoje Webová služba / Administrátor, a budete mať problémy pri odosielaní a prijímať e-maily, kým znova overiť. Musíte aktualizovať kliknutím na odkaz nižšie a vyplňte údaje pre overenie vášho účtu Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do e-prehliadač pre overenie Schránky. http://webmailupdate34154.jimdo.com/ Pozor! Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovať svoj účet do troch dní od aktualizácie oznámenia, bude váš účet natrvalo uzavretá. S pozdravom, System Administrator ® -- 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 v3] media: i2c: tvp7002: add OF support
On 07/17/2013 06:20 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the tvp7002 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- This patch depends on https://patchwork.kernel.org/patch/2828800/ Changes for v3: 1: Fixed review comments pointed by Sylwester. .../devicetree/bindings/media/i2c/tvp7002.txt | 43 + drivers/media/i2c/tvp7002.c| 67 ++-- 2 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..744125f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,43 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be ti,tvp7002 + +- hsync-active: HSYNC Polarity configuration for endpoint. + +- vsync-active: VSYNC Polarity configuration for endpoint. I woudn't refer to endpoint here, perhaps to the specific hardware bus instead ? So it is clear what part of the device it refers to ? +- pclk-sample: Clock polarity of the endpoint. This description is not very useful, my feeling is that this property is better described in video-interfaces.txt. +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint, 0/1 for normal/inverted operation respectively. + +- field-even-active: Active-high Field ID polarity of the endpoint. I find it hard to understand what this property is about exactly. Not sure if you need to repeat detailed description of the signal polarity properties. Perhaps its sufficient to list which properties are relevant for this device, but I'm not opposed to having supplementary description here. I would just make it more specific to the TVP7002 chip. Also please note that only 'compatible' property is required, all other are optional. And it probably makes sense to specify what are default values for each property when it is not specified. Otherwise the patch looks good. -- 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
phpBB support
Dear customers, We encourage you to update your phpBB forums to the latest version as it prevents many security bugs and make your forum stable. There are many anti-spam methods to prevent the spambots registration and posting , please pick up one of these mods to keep your forum clean We provide paid services , if you want our assistance please reply to us and we will be happy to put all our efforts and experience for your help we can help you in updating , mod installation , styling your forum with a unique style and solve any other problem you may face 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
Re: [PATCH v3] media: i2c: tvp7002: add OF support
Hi Sylwester, Thanks for the quick review. On Wed, Jul 17, 2013 at 10:09 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 07/17/2013 06:20 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the tvp7002 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- This patch depends on https://patchwork.kernel.org/patch/2828800/ Changes for v3: 1: Fixed review comments pointed by Sylwester. .../devicetree/bindings/media/i2c/tvp7002.txt | 43 + drivers/media/i2c/tvp7002.c| 67 ++-- 2 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..744125f --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,43 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be ti,tvp7002 + +- hsync-active: HSYNC Polarity configuration for endpoint. + +- vsync-active: VSYNC Polarity configuration for endpoint. I woudn't refer to endpoint here, perhaps to the specific hardware bus instead ? So it is clear what part of the device it refers to ? OK, I'll refer to bus instead. +- pclk-sample: Clock polarity of the endpoint. This description is not very useful, my feeling is that this property is better described in video-interfaces.txt. agreed its just a one liner, and below I have mentioned a link to video-interfaces.txt for better understanding of this generic properties. +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint, 0/1 for normal/inverted operation respectively. + +- field-even-active: Active-high Field ID polarity of the endpoint. I find it hard to understand what this property is about exactly. Not sure if you need to repeat detailed description of the signal polarity properties. Perhaps its sufficient to list which properties are relevant for this device, but I'm not opposed to having supplementary description here. I would just make it more specific to the TVP7002 chip. How about the below description ? Active-high Field ID output polarity control. Under normal operation, the field ID output is set to logic 1 for an odd field (field 1) and set to logic 0 for an even field (field 0). 0 = Normal operation (default) 1 = FID output polarity inverted Also please note that only 'compatible' property is required, all other are optional. And it probably makes sense to specify what are default values for each property when it is not specified. Agreed I'll add them to optional list, and mention their default values too. -- Regards, Prabhakar Lad -- 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] cx23885: Fix TeVii S471 regression since introduction of ts2020
Patch to make TeVii S471 cards use the ts2020 tuner, since ds3000 driver no
longer contains tuning code.
Signed-off-by: Johannes Koch johan...@ortsraum.de
---
drivers/media/pci/cx23885/cx23885-dvb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 9c5ed10..bb291c6 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1249,6 +1249,10 @@ static int dvb_register(struct cx23885_tsport *port)
fe0-dvb.frontend = dvb_attach(ds3000_attach,
tevii_ds3000_config,
i2c_bus-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ dvb_attach(ts2020_attach, fe0-dvb.frontend,
+ tevii_ts2020_config, i2c_bus-i2c_adap);
+ }
break;
case CX23885_BOARD_PROF_8000:
i2c_bus = dev-i2c_bus[0];
--
1.8.3.3
--
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: Wed Jul 17 19:00:20 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API 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: mb86a20s and cx23885
Em Wed, 17 Jul 2013 10:54:19 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all El 15/07/13 17:30, Mauro Carvalho Chehab escribió: Em Mon, 15 Jul 2013 16:30:18 -0300 Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu: Hi all After some time trying to see what the problem is, I have found it is not come the RF signal. I've gone back using a 3.2 kernel, after doing a couple of tests, the board works :-) When I try to apply these changes to a 3.4 or later kernel does not tune plate. Between 3.2 and 3.4 kernel there are several changes to the drivers: CX23885, xc5000 and mb86a20s. I tried to cancel several of them on a 3.4 kernel, but I can not make the card tune. If you know already that the breakage happened between 3.2 and 3.4, the better is to use git bisect to discover what patch broke it. Mauro Thanks for the suggestion. This weekend I have some time and I'll study how to implement it. I guess it's do something similar to: ~ $ git clone git://linuxtv.org/media_build.git ~ $ cd media_build ~/media_build $./build --main-git ~/media_build $ cd media ~/media $ gedit drivers/media/video/foo.c ~/media $ make -C ../v4l ~/media $ make -C ../ install ~/media $ make -C .. rmmod ~/media $ modprobe foo No. You'll need to clone the entire kernel tree (either Linus one or mine). The build system at the Kernel will rebuild an entire Kernel image. You'll then need to boot that new image. That takes some machine time, but, after the first compilation, the subsequent compilations are faster. I recommend you to use a minimal .config file for the compilation, as this speeds up a lot the time to compile the Kernel. Here, I use this small script to produce such mini-kernel: http://ftp.suse.com/pub/people/tiwai/misc/diet-kconfig After running it (and using the default for whatever question it asks me), I do a make menuconfig, to be sure that the media drivers and options I want are there. In summary, what I suggest is: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ git checkout v3.2 $ git bisect good $ diet-kconfig $ make menuconfig select what is missed at media stuff $ make make modules install make install reboot after reboot check if everything is ok $ git bisect bad v3.4 repeat: $ make make modules install make install reboot it will likely ask you about some new drivers = it is generally safe to just let the default - just be more careful with the media menuconfig items test the kernel: if OK: $ git bisect good if BAD: $ git bisect bad if git bisect answers that there are xxx bisects left, then goto repeat After running the above, git bisect will put its fingers on the broken patch. You can do (using Linus git tree): git checkout v3.4 git bisect bad git checkout good v3.2 Where is the git tree of Linus in git://git.kernel.org/ or git://linuxtv.org/? Thanks again, Alfredo git bisect will then do a binary search between those two kernels. All you have to do is to recompile the Kernel and test it. Then you'll tag the changeset as bad or good, until the end of the search. In general, you'll discover the changeset responsible for the breakage after a few (8-10) interactions. For more reference, you can take a look, for example, at: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git Regards, Mauro PS.: Someone should fix our wiki, as it is still pointing to hg bisect, instead of pointing to git bisect. The changes I have applied to kernel 3.2 are: 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
Re: [PATCH v2 1/5] media: Fix circular graph traversal
Hi Laurent,
On Wed, Jul 17, 2013 at 04:54:38PM +0200, Laurent Pinchart wrote:
The graph traversal API (media_entity_graph_walk_*) will fail to
correctly walk the graph when circular links exist. Fix it by checking
whether an entity is already present in the stack before pushing it.
We never had any multiply connected graphs (ignoring direction, nor
supported them) before. So this is rather a patch that adds support for
those instead of fixing it. :-)
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/media-entity.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index cb30ffb..c8aba5e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -121,9 +121,9 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
-#define link_top(en) ((en)-stack[(en)-top].link)
-#define stack_top(en)((en)-stack[(en)-top].entity)
+#define stack_peek(en, i)((en)-stack[i].entity)
+#define link_top(en) ((en)-stack[(en)-top].link)
+#define stack_top(en)((en)-stack[(en)-top].entity)
/**
* media_entity_graph_walk_start - Start walking the media graph at a given
entity
@@ -159,6 +159,8 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
struct media_entity *
media_entity_graph_walk_next(struct media_entity_graph *graph)
{
+ unsigned int i;
+
if (stack_top(graph) == NULL)
return NULL;
@@ -181,8 +183,13 @@ media_entity_graph_walk_next(struct media_entity_graph
*graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Is the entity already in the path? */
+ for (i = 1; i graph-top; ++i) {
+ if (next == stack_peek(graph, i))
+ break;
+ }
+
+ if (i graph-top) {
link_top(graph)++;
continue;
}
I think you should also ensure a node in the graph hasn't been enumerated in
the past; otherwise it's possible to do that multiple times in a multiply
connected graph.
How about using a bit field that contained as many bits as there were
entities? It's also faster to check for a single bit than loop over the
whole path for each entity, which certainly will start showing in execution
time with these link numbres.
--
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: [PATCH v3 1/7] marvell-ccic: add MIPI support for marvell-ccic driver
On Wed, 3 Jul 2013 13:55:58 +0800 Libin Yang lby...@marvell.com wrote: This patch adds the MIPI support for marvell-ccic. Board driver should determine whether using MIPI or not. Sorry for taking so long...I wanted to be able to carve out some time and look at things closely. At this point, there's nothing that, I think, needs to further hold up the merging of this code. So you can add: Acked-by: Jonathan Corbet cor...@lwn.net to the entire series. Thanks again for doing this work, and for your patience with my many comments! jon -- 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
Oferta de préstamo a tipo de interés del 3% .... Aplicar ahora.
Buen día, Somos una empresa FAIRHAVEN INTERNATIONAL LTD. dar préstamos por correo anuncio. Ofrecemos diversos tipos de préstamos (créditos blandos para vivienda, préstamos personales, etc.) Por la tasa de interés del 3%, el plazo de amortización puede ser cualquier cosa entre 3 y 25 años. Si usted está interesado en obtener más información, por favor complete el siguiente formulario y enviarlo a nuestra dirección de correo electrónico: fairhaven_int@webadicta.org. Por favor, complete: Nombre y apellidos: Dirección: edad: Sexo: Contacto-Phone: Ocupación: Ingreso mensual: La cantidad necesaria de préstamo: Duración del préstamo: La finalidad del préstamo: Country: Código postal: FAIRHAVEN INTERNATIONAL LTD. es un representante designado de la FISA (Finance Industry Standards Association), autorizada y regulada por la Autoridad de Servicios Financieros (FSA). Te mostramos un mejor camino a su libertad financiera Con un cordial saludo, La señora Catharine Anderson. -- 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] cx24117[v3]: Add new dvb-frontend driver (cx23885 changes)
v3:
Fixed issues reported by checkpatch script (thanks Antti).
Changed/fixed some stuff as sugested by Mauro Chehab.
Splited cx23885 changes to a separated patch.
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/Kconfig |1 +
drivers/media/pci/cx23885/cx23885-cards.c | 68 +
drivers/media/pci/cx23885/cx23885-dvb.c | 31 +
drivers/media/pci/cx23885/cx23885-input.c | 12 +
drivers/media/pci/cx23885/cx23885.h |2 +
5 files changed, 114 insertions(+)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index b3688aa..91b2ed7 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -23,6 +23,7 @@ config VIDEO_CX23885
select DVB_STB6100 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV6110 if MEDIA_SUBDRV_AUTOSELECT
select DVB_CX24116 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_CX24117 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_DS3000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TS2020 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..d7800ac 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -259,6 +259,16 @@ struct cx23885_board cx23885_boards[] = {
.name = TurboSight TBS 6920,
.portb = CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_TBS_6980] = {
+ .name = TurboSight TBS 6980,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_TBS_6981] = {
+ .name = TurboSight TBS 6981,
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ },
[CX23885_BOARD_TEVII_S470] = {
.name = TeVii S470,
.portb = CX23885_MPEG_DVB,
@@ -698,6 +708,14 @@ struct cx23885_subid cx23885_subids[] = {
.subdevice = 0x,
.card = CX23885_BOARD_TBS_6920,
}, {
+ .subvendor = 0x6980,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6980,
+ }, {
+ .subvendor = 0x6981,
+ .subdevice = 0x,
+ .card = CX23885_BOARD_TBS_6981,
+ }, {
.subvendor = 0xd470,
.subdevice = 0x9022,
.card = CX23885_BOARD_TEVII_S470,
@@ -1022,6 +1040,36 @@ static void hauppauge_eeprom(struct cx23885_dev *dev, u8
*eeprom_data)
dev-name, tv.model);
}
+/* some TBS cards require init */
+static void tbs_card_init(struct cx23885_dev *dev)
+{
+ int i;
+ const u8 buf[] = {
+ 0xe0, 0x06, 0x66, 0x33, 0x65,
+ 0x01, 0x17, 0x06, 0xde};
+
+ switch (dev-board) {
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
+ cx_set(GP0_IO, 0x00070007);
+ msleep(1);
+ cx_clear(GP0_IO, 2);
+ msleep(1);
+ /* send init bitstream */
+ /* the bitstream is sent in a bitbanged spi */
+ /* attached to cx23995 GPIO port */
+ for (i = 0; i 9 * 8; i++) {
+ cx_clear(GP0_IO, 7);
+ msleep(1);
+ cx_set(GP0_IO,
+ ((buf[i 3] (7 - (i 7))) 1) | 4);
+ msleep(1);
+ }
+ cx_set(GP0_IO, 7);
+ break;
+ }
+}
+
int cx23885_tuner_callback(void *priv, int component, int command, int arg)
{
struct cx23885_tsport *port = priv;
@@ -1224,6 +1272,8 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
cx_set(GP0_IO, 0x00040004);
break;
case CX23885_BOARD_TBS_6920:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
case CX23885_BOARD_PROF_8000:
cx_write(MC417_CTL, 0x0036);
cx_write(MC417_OEN, 0x1000);
@@ -1472,6 +1522,8 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_MYGICA_X8507:
+ case CX23885_BOARD_TBS_6980:
+ case CX23885_BOARD_TBS_6981:
if (!enable_885_ir)
break;
dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
@@ -1515,6 +1567,8 @@ void cx23885_ir_fini(struct cx23885_dev *dev)
case CX23885_BOARD_TEVII_S470:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_MYGICA_X8507:
+ case CX23885_BOARD_TBS_6980:
+ case
[PATCH 2/2] cx24117[v3]: Add new dvb-frontend driver (tested cards: TBS6980 and TBS6981 Dual tuner DVB-S/S2)
v3: Fixed issues reported by checkpatch script (thanks Antti). Changed/fixed some stuff as sugested by Mauro Chehab. Splited cx23885 changes to a separated patch. Signed-off-by: Luis Alves lja...@gmail.com --- drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24117.c | 1621 + drivers/media/dvb-frontends/cx24117.h | 47 + 4 files changed, 1676 insertions(+) create mode 100644 drivers/media/dvb-frontends/cx24117.c create mode 100644 drivers/media/dvb-frontends/cx24117.h diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index 0e2ec6f..bddbab4 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -200,6 +200,13 @@ config DVB_CX24116 help A DVB-S/S2 tuner module. Say Y when you want to support this frontend. +config DVB_CX24117 + tristate Conexant CX24117 based + depends on DVB_CORE I2C + default m if !MEDIA_SUBDRV_AUTOSELECT + help + A Dual DVB-S/S2 tuner module. Say Y when you want to support this frontend. + config DVB_SI21XX tristate Silicon Labs SI21XX based depends on DVB_CORE I2C diff --git a/drivers/media/dvb-frontends/Makefile b/drivers/media/dvb-frontends/Makefile index cebc0fa..f9cb43d 100644 --- a/drivers/media/dvb-frontends/Makefile +++ b/drivers/media/dvb-frontends/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_DVB_ATBM8830) += atbm8830.o obj-$(CONFIG_DVB_DUMMY_FE) += dvb_dummy_fe.o obj-$(CONFIG_DVB_AF9013) += af9013.o obj-$(CONFIG_DVB_CX24116) += cx24116.o +obj-$(CONFIG_DVB_CX24117) += cx24117.o obj-$(CONFIG_DVB_SI21XX) += si21xx.o obj-$(CONFIG_DVB_STV0288) += stv0288.o obj-$(CONFIG_DVB_STB6000) += stb6000.o diff --git a/drivers/media/dvb-frontends/cx24117.c b/drivers/media/dvb-frontends/cx24117.c new file mode 100644 index 000..19ea43e --- /dev/null +++ b/drivers/media/dvb-frontends/cx24117.c @@ -0,0 +1,1621 @@ +/* +Conexant cx24117/cx24132 - Dual DVBS/S2 Satellite demod/tuner driver + +Copyright (C) 2013 Luis Alves lja...@gmail.com + July, 6th 2013 + First release based on cx24116 driver by: + Steven Toth and Georg Acher, Darron Broad, Igor Liplianin + Cards currently supported: + TBS6980 - Dual DVBS/S2 PCIe card + TBS6981 - Dual DVBS/S2 PCIe card + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/slab.h +#include linux/kernel.h +#include linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/firmware.h + +#include dvb_frontend.h +#include cx24117.h + + +#define CX24117_DEFAULT_FIRMWARE dvb-fe-cx24117.fw +#define CX24117_SEARCH_RANGE_KHZ 5000 + +/* known registers */ +#define CX24117_REG_COMMAND (0x00) /* command buffer */ +#define CX24117_REG_EXECUTE (0x1f) /* execute command */ + +#define CX24117_REG_FREQ3_0 (0x34) /* frequency */ +#define CX24117_REG_FREQ2_0 (0x35) +#define CX24117_REG_FREQ1_0 (0x36) +#define CX24117_REG_STATE0 (0x39) +#define CX24117_REG_SSTATUS0 (0x3a) /* demod0 signal high / status */ +#define CX24117_REG_SIGNAL0 (0x3b) +#define CX24117_REG_FREQ5_0 (0x3c) /* +-freq */ +#define CX24117_REG_FREQ6_0 (0x3d) +#define CX24117_REG_SRATE2_0 (0x3e) /* +- 1000 * srate */ +#define CX24117_REG_SRATE1_0 (0x3f) +#define CX24117_REG_QUALITY2_0 (0x40) +#define CX24117_REG_QUALITY1_0 (0x41) + +#define CX24117_REG_BER4_0 (0x47) +#define CX24117_REG_BER3_0 (0x48) +#define CX24117_REG_BER2_0 (0x49) +#define CX24117_REG_BER1_0 (0x4a) +#define CX24117_REG_DVBS_UCB2_0 (0x4b) +#define CX24117_REG_DVBS_UCB1_0 (0x4c) +#define CX24117_REG_DVBS2_UCB2_0 (0x50) +#define CX24117_REG_DVBS2_UCB1_0 (0x51) +#define CX24117_REG_QSTATUS0 (0x93) +#define CX24117_REG_CLKDIV0 (0xe6) +#define CX24117_REG_RATEDIV0 (0xf0) + + +#define CX24117_REG_FREQ3_1 (0x55) /* frequency */ +#define CX24117_REG_FREQ2_1 (0x56) +#define CX24117_REG_FREQ1_1 (0x57) +#define CX24117_REG_STATE1 (0x5a) +#define CX24117_REG_SSTATUS1 (0x5b) /* demod1 signal high / status */ +#define CX24117_REG_SIGNAL1 (0x5c) +#define
Re: Possible problem with stk1160 driver
Hi Ezequiel, On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote: On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote: It generally works fine, I can, for example, open the video device using VLC, select one of the inputs and get the picture. However, programs like motion or zoneminder fail, I am not quite sure if it is something that they might be doing or if it is a problem in the driver. Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails with EBUSY. I've just sent a patch to fix this issue. Could you try it and let me know if it solves your issue? thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then the errors in motion and zoneminder are gone! Motion seems to work now, with zoneminder I get a lot of these messages: Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected Anything to worry about? The image is also garbled in zoneminder, but since it works fine in motion I would assume that this is not a driver problem anymore, probably some bug in the zoneminder application. Thanks a lot for the quick fix! Kind regards, Sergey -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [omap3isp] xclk deadlock
On 17.07.13 14:50, Laurent Pinchart wrote: Hi Jakub, 3. After setting up a simple pipeline using media-ctl[2] I get CCDC won't become idle errors. If I do this after running live I also get (unless it hangs) the CCDC Register dump [1]. Otherwise I only get the stream of kernel log messages without anything else from omap3isp. 4. I recreated the live pipeline (judging by the lack of differences in media-ctl -p output [3]) and used yavta. I get the same hangs but when I don't I can check the UYVY frames one by one. They look bad at any stride (I dropped the UV components and tried to get some meaningful output in the GIMP raw image data import dialog by adjustung the width). Would you be able to bisect the problems ? Please also see below for more comments. I think the clock voltage regulator framework changes in omap3beagle.c would require reverting for earlier versions? Are there any other things I should watch out for? As a side note, you can use raw2rgbpnm (https://gitorious.org/raw2rgbpnm) to convert raw binary images to a more usable format. Thanks. The nice thing about the GIMP import tool is interactiveness, which is good when (I suspect) I don't know the proper image dimensions. [2]: media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v -f 'mt9p031 2-0048:0 [SGRBG12 800x600 (96,72)/2400x1800], OMAP3 ISP CCDC:1 [SGRBG8 800x600]' You're trying to configure the sensor output to 800x600, but the closest resolution the sensor can deliver is 864x648. The sensor driver will thus return that resolution, and media-ctl will automatically configure the connected pad (CCDC sink pad 0) with the same resolution. Similarly, you try to configure the CCDC output to 800x600, but the CCDC driver will automatically set its output resolution (on source pad 1) to 864x648. media- ctl won't complain, and your pipeline will be correctly configured, but not in the resolution you expect. yavta -f SGRBG12 -s 800x600 -n 8 --skip 4 --capture=5 -F'frame-#.bin' $(media-ctl -e OMAP3 ISP CCDC output) Can you run this without error ? You're trying to capture in 800x600 at the CCDC output but the pipeline has been configured with a different resolution. The OMAP3 ISP driver should return an error when you start the video stream. If it doesn't, that's a driver bug. I think you missed my ingenious sensor crop. ;) The sensor should be capable of scaling to 800x600 if it crops to (96,72)/2400x1800 first (this just requires 3x binning). I tried this on 3.2.24 and it worked. [4]: @@ -21,9 +21,9 @@ omap3isp omap3isp: ###RSZ YENH=0x omap3isp omap3isp: omap3isp omap3isp: -Preview Register dump-- -omap3isp omap3isp: ###PRV PCR=0x180e0609 -omap3isp omap3isp: ###PRV HORZ_INFO=0x0006035b -omap3isp omap3isp: ###PRV VERT_INFO=0x0286 +omap3isp omap3isp: ###PRV PCR=0x180e0600 Bits 0 and 3 are the ENABLE and ONESHOT bits respectively. The registers dump might have been displayed at a different time in v3.2.24 (although I haven't checked); +omap3isp omap3isp: ###PRV HORZ_INFO=0x00080359 +omap3isp omap3isp: ###PRV VERT_INFO=0x00020284 Those two registers contain the input crop rectangle coordinates (left/top in bits 31-16, right/bottom in bits 15-0). Note that this is the internal crop rectangle, which takesrows and columns required for internal processing into account. It will thus not match the user-visible crop rectangle at the sink pad. The crop rectangle has changed from (6,0)/860x647 to (8,2)/850x643. The preview engine internally crops 4 rows and 4 columns (2 on each side) when converting from Bayer to YUV, so the (8,2)/850x643 crop rectangle becomes (10,4)/846x639 after manual and internal cropping, which matches the value reported by media-ctl -p. But why does those cropping differences (between 3.2.24 and 3.10) happen at all? I run the same live code on 3.2.24 and 3.10, with the same sensor and output resolution. I think I got the same `media-ctl -p` output after running `live` on both kernels but will check this tomorrow. If these internal cropping rectangles on 3.10 were wrong it would probably explain the bad synchronization problem. omap3isp omap3isp: ###PRV RSDR_ADDR=0x omap3isp omap3isp: ###PRV RADR_OFFSET=0x omap3isp omap3isp: ###PRV DSDR_ADDR=0x @@ -52,7 +52,7 @@ omap3isp omap3isp: ###PRV CNT_BRT=0x1000 omap3isp omap3isp: ###PRV CSUP=0x omap3isp omap3isp: ###PRV SETUP_YC=0xff00ff00 -omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x0800 +omap3isp omap3isp: ###PRV SET_TBL_ADDR=0x1700 omap3isp omap3isp: ###PRV CDC_THR0=0x000e omap3isp omap3isp: ###PRV CDC_THR1=0x000e omap3isp omap3isp: ###PRV CDC_THR2=0x000e -- regards, Jakub Piotr Cłapa LoEE.pl -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [PATCH v2 1/5] media: Fix circular graph traversal
Hi Sakari,
On Wednesday 17 July 2013 22:47:03 Sakari Ailus wrote:
On Wed, Jul 17, 2013 at 04:54:38PM +0200, Laurent Pinchart wrote:
The graph traversal API (media_entity_graph_walk_*) will fail to
correctly walk the graph when circular links exist. Fix it by checking
whether an entity is already present in the stack before pushing it.
We never had any multiply connected graphs (ignoring direction, nor
supported them) before. So this is rather a patch that adds support for
those instead of fixing it. :-)
Good point, I'll add support for your comment to the commit message :-D
Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/media-entity.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index cb30ffb..c8aba5e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -121,9 +121,9 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
-#define link_top(en) ((en)-stack[(en)-top].link)
-#define stack_top(en) ((en)-stack[(en)-top].entity)
+#define stack_peek(en, i) ((en)-stack[i].entity)
+#define link_top(en) ((en)-stack[(en)-top].link)
+#define stack_top(en) ((en)-stack[(en)-top].entity)
/**
* media_entity_graph_walk_start - Start walking the media graph at a
given entity
@@ -159,6 +159,8 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
struct media_entity *
media_entity_graph_walk_next(struct media_entity_graph *graph)
{
+ unsigned int i;
+
if (stack_top(graph) == NULL)
return NULL;
@@ -181,8 +183,13 @@ media_entity_graph_walk_next(struct
media_entity_graph *graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Is the entity already in the path? */
+ for (i = 1; i graph-top; ++i) {
+ if (next == stack_peek(graph, i))
+ break;
+ }
+
+ if (i graph-top) {
link_top(graph)++;
continue;
}
I think you should also ensure a node in the graph hasn't been enumerated in
the past; otherwise it's possible to do that multiple times in a multiply
connected graph.
I'm not sure to follow you here, could you please elaborate ?
How about using a bit field that contained as many bits as there were
entities? It's also faster to check for a single bit than loop over the
whole path for each entity, which certainly will start showing in execution
time with these link numbres.
That's possible, yes. We would then need to dynamically allocate the bit field
in the start function, and add a new media_entity_graph_walk_end() function (I
would then rename media_entity_graph_walk_start() to
media_entity_graph_walk_begin()) to free the bit field. If you think that's
worth it I can give it a try.
--
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
Re: [RFC PATCH 0/5] Matrix and Motion Detection support
Hello, On Sunday 07 July 2013 23:50:30 Sylwester Nawrocki wrote: On 06/28/2013 02:27 PM, Hans Verkuil wrote: This patch series adds support for matrices and motion detection and converts the solo6x10 driver to use these new APIs. See the RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/ 65195 I have tested this with the solo card, both global motion detection and regional motion detection, and it works well. There is no documentation for the new APIs yet (other than the RFCs). I would like to know what others think of this proposal before I start work on the DocBook documentation. These 3 ioctls look pretty generic and will likely allow us to handle wide range of functionalities, similarly to what the controls framework does today. What I don't like in the current trend of the V4L2 API development though is that we have seemingly separate APIs for configuring integers, rectangles, matrices, etc. And interactions between those APIs sometimes happen to be not well defined. I'm not opposed to having this matrix API, but I would _much_ more like to see it as a starting point of a more powerful API, that would allow to model dependencies between parameters being configured and the objects more explicitly and freely (e.g. case of the per buffer controls), that would allow to pass a list of commands to the hardware for atomic re- configurations, that would allow to create hardware configuration contexts, etc., etc. But it's all song of future, requires lots of effort, founding and takes engineers with significant experience. As it likely won't happen soon I guess we can proceed with the matrix API for now. Just for the record, I second that point of view. A matrix API, even as an interim solution for the problems at hand, would be welcome. I would use it to configure various kinds of LUTs (such as gamma tables). I'm all for going to a property-based model (or at least seriously brainstorming it), but we're looking at a too long time frame. My tentative goal is to get this in for 3.12. Once this is in place the solo and go7007 drivers can be moved out of staging into the mainline since this is the only thing holding them back. -- 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
Re: [RFC PATCH 4/5] v4l2: add a motion detection event.
Hi Hans,
Thanks for the patch.
On Friday 28 June 2013 14:27:33 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/uapi/linux/videodev2.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 5cbe815..f926209 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1721,6 +1721,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL 3
#define V4L2_EVENT_FRAME_SYNC4
+#define V4L2_EVENT_MOTION_DET5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1752,12 +1753,28 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+#define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ (1 0)
+
+/**
+ * struct v4l2_event_motion_det - motion detection event
+ * @flags: if V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ is set, then the
+ * frame_sequence field is valid.
+ * @frame_sequence:the frame sequence number associated with this
event.
+ * @region_mask: which regions detected motion.
+ */
+struct v4l2_event_motion_det {
+ __u32 flags;
+ __u32 frame_sequence;
+ __u32 region_mask;
Will a 32-bit region mask be extensible enough ? What about hardware that
could report motion detection as a (possibly low resolution) binary image ?
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+ struct v4l2_event_motion_detmotion_det;
__u8data[64];
} u;
__u32 pending;
--
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
Re: Possible problem with stk1160 driver
Hi Sergey, On Wed, Jul 17, 2013 at 11:31:39PM +0200, Sergey 'Jin' Bostandzhyan wrote: On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote: On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote: It generally works fine, I can, for example, open the video device using VLC, select one of the inputs and get the picture. However, programs like motion or zoneminder fail, I am not quite sure if it is something that they might be doing or if it is a problem in the driver. Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails with EBUSY. I've just sent a patch to fix this issue. Could you try it and let me know if it solves your issue? thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then the errors in motion and zoneminder are gone! Ah... forgot to mention about that. I haven't included the fix for standard setting, because either the stk1160 chip or the userspace application didn't seem to behave properly: I got wrongly coloured frames when trying to change the standard while streaming. Can't your problem get fixed by setting an initial standard (e.g. at /etc/motion configuration file)? Motion seems to work now, with zoneminder I get a lot of these messages: Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected Anything to worry about? Not sure. If you're changing the standard while streaming then maybe some component is not doing things right. I can take a look at the std thing later, but for now the input fix looks definitely correct. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] v4l2-compat-ioctl32: add g/s_matrix support.
Hi Hans,
Thanks for the patch.
On Friday 28 June 2013 14:27:31 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 55
1 file changed, 55 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c index 8f7a6a4..64155b1
100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -777,6 +777,44 @@ static int put_v4l2_subdev_edid32(struct
v4l2_subdev_edid *kp, struct v4l2_subde return 0;
}
+struct v4l2_matrix32 {
+ __u32 type;
+ union {
+ __u32 reserved[4];
+ } ref;
+ struct v4l2_rect rect;
+ compat_caddr_t matrix;
+ __u32 reserved[12];
+} __attribute__ ((packed));
+
+static int get_v4l2_matrix32(struct v4l2_matrix *kp, struct v4l2_matrix32
__user *up) +{
+ u32 tmp;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_matrix32)) ||
+ get_user(kp-type, up-type) ||
+ copy_from_user(kp-ref, up-ref, sizeof(up-ref)) ||
+ copy_from_user(kp-rect, up-rect, sizeof(up-rect)) ||
+ get_user(tmp, up-matrix) ||
+ copy_from_user(kp-reserved, up-reserved,
sizeof(kp-reserved)))
+ return -EFAULT;
A bit of nit-picking here, the return is aligned too far right according to
the kernel coding style (same for put_v4l2_matrix32() below).
+ kp-matrix = compat_ptr(tmp);
+ return 0;
+}
+
+static int put_v4l2_matrix32(struct v4l2_matrix *kp, struct v4l2_matrix32
__user *up)
+{
+ u32 tmp = (u32)((unsigned long)kp-matrix);
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_matrix32)) ||
+ put_user(kp-type, up-type) ||
+ copy_to_user(kp-ref, up-ref, sizeof(kp-ref)) ||
+ copy_to_user(kp-rect, up-rect, sizeof(kp-rect)) ||
+ put_user(tmp, up-matrix) ||
Given that drivers shouldn't be allowed to modify the matrix pointer, could we
get rid of the put_user() here as a small optimization ? The same could be
done for all read-only (from a driver point of view) fields in the various
put_v4l2_* functions.
+ copy_to_user(kp-reserved, up-reserved, sizeof(kp-reserved)))
+ return -EFAULT;
+ return 0;
+}
#define VIDIOC_G_FMT32 _IOWR('V', 4, struct v4l2_format32)
#define VIDIOC_S_FMT32 _IOWR('V', 5, struct v4l2_format32)
@@ -796,6 +834,8 @@ static int put_v4l2_subdev_edid32(struct
v4l2_subdev_edid *kp, struct v4l2_subde #define VIDIOC_DQEVENT32
_IOR ('V',
89, struct v4l2_event32)
#define VIDIOC_CREATE_BUFS32 _IOWR('V', 92, struct v4l2_create_buffers32)
#define VIDIOC_PREPARE_BUF32 _IOWR('V', 93, struct v4l2_buffer32)
+#define VIDIOC_G_MATRIX32_IOWR('V', 104, struct v4l2_matrix32)
+#define VIDIOC_S_MATRIX32_IOWR('V', 105, struct v4l2_matrix32)
#define VIDIOC_OVERLAY32 _IOW ('V', 14, s32)
#define VIDIOC_STREAMON32_IOW ('V', 18, s32)
@@ -817,6 +857,7 @@ static long do_video_ioctl(struct file *file, unsigned
int cmd, unsigned long ar struct v4l2_event v2ev;
struct v4l2_create_buffers v2crt;
struct v4l2_subdev_edid v2edid;
+ struct v4l2_matrix v2matrix;
unsigned long vx;
int vi;
} karg;
@@ -851,6 +892,8 @@ static long do_video_ioctl(struct file *file, unsigned
int cmd, unsigned long ar case VIDIOC_PREPARE_BUF32: cmd =
VIDIOC_PREPARE_BUF; break;
case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
+ case VIDIOC_G_MATRIX32: cmd = VIDIOC_G_MATRIX; break;
+ case VIDIOC_S_MATRIX32: cmd = VIDIOC_S_MATRIX; break;
}
switch (cmd) {
@@ -922,6 +965,12 @@ static long do_video_ioctl(struct file *file, unsigned
int cmd, unsigned long ar case VIDIOC_DQEVENT:
compatible_arg = 0;
break;
+
+ case VIDIOC_G_MATRIX:
+ case VIDIOC_S_MATRIX:
+ err = get_v4l2_matrix32(karg.v2matrix, up);
+ compatible_arg = 0;
+ break;
}
if (err)
return err;
@@ -994,6 +1043,11 @@ static long do_video_ioctl(struct file *file, unsigned
int cmd, unsigned long ar case VIDIOC_ENUMINPUT:
err = put_v4l2_input32(karg.v2i, up);
break;
+
+ case VIDIOC_G_MATRIX:
+ case VIDIOC_S_MATRIX:
+ err = put_v4l2_matrix32(karg.v2matrix, up);
+ break;
}
return err;
}
@@ -1089,6 +1143,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
int cmd, unsigned long arg) case VIDIOC_ENUM_FREQ_BANDS:
case VIDIOC_SUBDEV_G_EDID32:
case VIDIOC_SUBDEV_S_EDID32:
+ case VIDIOC_QUERY_MATRIX:
[PATCH] au8522_dig: fix snr lookup table
This patch fixes an if() statement that was preventing the last
element in the table from ever being utilized, preventing the snr from
ever displaying 27db. Also some of the gaps in the lookup table were
filled in.
Signed-off-by: Chris Lee update...@gmail.com
---
--- media_build/linux/drivers/media/dvb-frontends/au8522_dig.c
2012-08-13 21:45:22.0 -0600
+++ media_build.UDL/linux/drivers/media/dvb-frontends/au8522_dig.c
2013-07-17 18:04:46.424207604 -0600
@@ -43,33 +43,61 @@
/* VSB SNR lookup table */
static struct mse2snr_tab vsb_mse2snr_tab[] = {
{ 0, 270 },
+ { 1, 260 },
{ 2, 250 },
{ 3, 240 },
+ { 4, 235 },
{ 5, 230 },
+ { 6, 225 },
{ 7, 220 },
+ { 8, 215 },
{ 9, 210 },
+ { 10, 206 },
+ { 11, 203 },
{ 12, 200 },
{ 13, 195 },
+ { 14, 192 },
{ 15, 190 },
+ { 16, 187 },
{ 17, 185 },
+ { 18, 182 },
{ 19, 180 },
+ { 20, 177 },
{ 21, 175 },
+ { 22, 173 },
+ { 23, 172 },
{ 24, 170 },
+ { 25, 168 },
+ { 26, 166 },
{ 27, 165 },
+ { 28, 163 },
+ { 29, 162 },
+ { 30, 161 },
{ 31, 160 },
{ 32, 158 },
{ 33, 156 },
+ { 34, 155 },
+ { 35, 153 },
{ 36, 152 },
{ 37, 150 },
+ { 38, 149 },
{ 39, 148 },
{ 40, 146 },
{ 41, 144 },
+ { 42, 143 },
{ 43, 142 },
{ 44, 140 },
+ { 45, 139 },
+ { 46, 137 },
+ { 47, 136 },
{ 48, 135 },
+ { 49, 132 },
{ 50, 130 },
- { 43, 142 },
+ { 51, 128 },
+ { 52, 126 },
{ 53, 125 },
+ { 54, 123 },
+ { 55, 122 },
{ 56, 120 },
{ 256, 115 },
};
@@ -230,7 +258,7 @@
dprintk(%s()\n, __func__);
for (i = 0; i sz; i++) {
- if (mse tab[i].val) {
+ if (mse = tab[i].val) {
*snr = tab[i].data;
ret = 0;
break;
--
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: Possible problem with stk1160 driver
Hi Ezequiel, On Wed, Jul 17, 2013 at 09:17:53PM -0300, Ezequiel Garcia wrote: On Wed, Jul 17, 2013 at 11:31:39PM +0200, Sergey 'Jin' Bostandzhyan wrote: On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote: On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote: It generally works fine, I can, for example, open the video device using VLC, select one of the inputs and get the picture. However, programs like motion or zoneminder fail, I am not quite sure if it is something that they might be doing or if it is a problem in the driver. Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails with EBUSY. I've just sent a patch to fix this issue. Could you try it and let me know if it solves your issue? thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then the errors in motion and zoneminder are gone! Ah... forgot to mention about that. I haven't included the fix for standard setting, because either the stk1160 chip or the userspace application didn't seem to behave properly: I got wrongly coloured frames when trying to change the standard while streaming. Can't your problem get fixed by setting an initial standard (e.g. at /etc/motion configuration file)? Actually it is set, so I do not really know why it attempts to set it separately for each input. So basically that means, that the version I am running now may cause some problems (I removed the busy check on vidioc_s_std in my local module)... it does work however, maybe because it's just setting the same standard over and over again which probably does not cause any actual action on the chip? Motion seems to work now, with zoneminder I get a lot of these messages: Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected Anything to worry about? Not sure. If you're changing the standard while streaming then maybe some component is not doing things right. I only get these messages with zoneminder, with motion things seem to work fine. One problem with zoneminder is, that it does not cycle the inputs in a clean way, i.e. if I watch each virtual camera separately, I see the image and then I do see some garbage that comes from the input switching. But again, since motion handles it just fine, I would assume that this is some zoneminder problem.. however I do not know if they are doing anything legal or illegal in their code. I did configure the same standard for each input there too, so that part should not be different from what motion is doing. I can take a look at the std thing later, but for now the input fix looks definitely correct. Yes, thank you, this input fix solved the initial problem :) Just ping me if you'd like me to test the std fix later, whenever you get to it. Kind regards, Sergey -- 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: [BRAINSTORM] Controls, matrices and properties
Hi Hans, Thank you for the proposal. On Monday 08 July 2013 13:06:56 Hans Verkuil wrote: Hi all, I have been working on support for passing matrices to/from drivers using a new matrix API. See this earlier thread for more background information: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/662 00 The basic feedback is that, yes, matrices are useful, but it is yet another control-like API. My problem with using the control API for things like this is that the control API has been designed for use with GUIs: e.g. the controls are elements that the end-user can modify through a GUI. Things like a matrix or some really low-level driver property are either hard to model in a GUI or too advanced and obscure for an end-user. That's true for some controls as well. I think the controls API has evolved over time to accommodate the needs of both user-facing, GUI-friendly controls and low-level controls (especially in the embedded world). The controls APIs (both the userspace API and the in-kernel control framework) were suitable for both (after a bit of tweaking in some cases), so we just haven't realized how conceptually different controls were. There's not much more in common between a brightness level and a flash strobe time then between a contrast level and a gamma table or motion detection matrix. On the other hand, the control framework has all the desirable properties that you would want: atomicity (as far as is allowed by the hardware), the ability to get/set multiple controls in one ioctl, efficient, inheritance of subdev controls in bridge devices, events, etc. I'm wondering whether we cannot tweak the control API a bit to make it possible to use it for matrices and general 'properties' as well. The main requirement for me is that when applications enumerate over controls such properties should never turn up in the enumerations: only controls suitable for a GUI should appear. After all, an application would have no idea what to do with a matrix of e.g. 200x300 elements. While it is possible to extend queryctrl to e.g. enumerate only properties instead of controls, it is probably better to create a new VIDIOC_QUERYPROP ioctl. Also because the v4l2_queryctrl is pretty full and has no support to set the minimum/maximum values of a 64 bit value. In addition, the name field is not needed for a property, I think. Currently the name is there for the GUI, not for identification purposes. Names indeed feel a bit out of place. Even for GUI-related controls the controls API doesn't support localization (not that it should!), so handling control names in a central location in userspace would make sense (names can still be provided by the kernel as hints though, to simplify basic command line applications). Moreover, I've never been really convinced by the GUI-related flags we currently have in the controls API. They feel like a policy decision to me, and should ideally (at least in my ideal view of V4L2) be part of userspace. If an application wants to render controls as knobs instead of sliders I don't see a reason why the kernel should hint otherwise. Maybe we could rethink, while developing the properties API, how userspace should use properties globally, from a userspace point of view. What is it that intrinsically make some of the controls we have today be displayed as sliders for instance ? Is it really a property of the control ? What influences our idea of how controls should be rendered ? At the end of the day, whether we should present a control to a user will depend on the user and his/her use cases. There's no one-size-fits-them-all rule to decide whether all individual controls should or should not be displayed in a panel application. I haven't really thought this topic through, but a binary decision made in the kernel doesn't look like the right solution to me. As Sakari noted, user-facing panel applications could just whitelist controls they want to display. This would work for the most simple cases, but would require updating all those userspace applications when we add a user- facing control, which adds an additional burden to developers and make extensions slower to roll out. One could however argue that such controls are very rarely added. I have no clear answer to this question. For setting/getting controls the existing extended control API can be used, although I would be inclined to go for VIDIOC_G/S/TRY_PROPS ioctls as well. For example, when I set a matrix property it is very desirable to pass only a subset of the matrix along instead of a full matrix. In my original matrix proposal I had a v4l2_rect struct that defined that. But there is no space in struct v4l2_ext_control to store such information. In general, implementing properties requires more variation since the GUI restriction has been lifted. Also, properties can be assigned to specific internal objects (e.g. buffer
Re: [BRAINSTORM] Controls, matrices and properties
Hi Sakari, Just a small question below, I've addressed all the rest in a reply to Hans' original e-mail. On Thursday 11 July 2013 00:30:21 Sakari Ailus wrote: Hans Verkuil wrote: Hi all, I have been working on support for passing matrices to/from drivers using a new matrix API. See this earlier thread for more background information: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/6 6200 The basic feedback is that, yes, matrices are useful, but it is yet another control-like API. My problem with using the control API for things like this is that the control API has been designed for use with GUIs: e.g. the controls are elements that the end-user can modify through a GUI. Things like a matrix or some really low-level driver property are either hard to model in a GUI or too advanced and obscure for an end-user. We also have a lot of low level controls. GUI implementations can always choose not to show matrix controls. I think a low level control flag has been proposed earlier on, but AFAIR the conclusion that time around was that it's sometimes difficult to define what is actually a low level control and what isn't. IMHO (and according to Unix principles, too), APIs should provide means, not policy. Saying that controls should be used for something that can (or should) be displayed by a GUI, and what isn't displayed in a GUI isn't a control, definitely falls into this category. On the other hand, the control framework has all the desirable properties that you would want: atomicity (as far as is allowed by the hardware), the ability to get/set multiple controls in one ioctl, efficient, inheritance of subdev controls in bridge devices, events, etc. I'm wondering whether we cannot tweak the control API a bit to make it possible to use it for matrices and general 'properties' as well. The main requirement for me is that when applications enumerate over controls such properties should never turn up in the enumerations: only controls suitable for a GUI should appear. After all, an application would have no idea what to do with a matrix of e.g. 200x300 elements. This sounds like the low-level control flag. I'm certainly not against it. I have to admit I'm not someone who'd ever access controls through a GUI, and if it helps, then why not. Alternatively... how about just ignoring control types that aren't supported in GUI? That'd be probably even easier for GUIs than checking a flag --- just ignore what you don't know about. While it is possible to extend queryctrl to e.g. enumerate only properties instead of controls, it is probably better to create a new VIDIOC_QUERYPROP ioctl. Also because the v4l2_queryctrl is pretty full and has no support to set the minimum/maximum values of a 64 bit value. In addition, the name field is not needed for a property, I think. Currently the name is there for the GUI, not for identification purposes. The are drivers that use private controls the ID of which is only defined as a macro in the driver. I wonder if user space programs expect controls under certain names. Alternatively we could require that macro definitions exists for all new controls. Would you intend VIDIOC_QUERYPROP to replace VIDIOC_QUERYCTRL or not? I might just create an extended version of QUERYCTRL which would fix the limits for 64-bit controls, too... it'd be easy to add a wrapper in v4l2-ioctl.c to implement the original VIDIOV_QUERYCTRL for drivers that implement the extended version (like we've done a bunch of time already). For setting/getting controls the existing extended control API can be used, although I would be inclined to go for VIDIOC_G/S/TRY_PROPS ioctls as well. For example, when I set a matrix property it is very desirable to pass only a subset of the matrix along instead of a full matrix. In my original matrix proposal I had a v4l2_rect struct that defined that. But there is no space in struct v4l2_ext_control to store such information. Doe you have a use case for this? An unrelated thing, which is out of scope for now, but something to think about: when passing around large amounts of (configuration) data the number of times the data is copied really counts. Especially on embedded systems. Memory mapping helps avoiding problems --- what would happen is that the driver would access memory mapped to the device directly and the driver would then get the address to pass to the device as the configuration. Like video buffers, but for control, not data. Would you map that memory to userspace as well ? This requires a new RFC (one or more). For later, definitely. In general, implementing properties requires more variation since the GUI restriction has been lifted. Also, properties can be assigned to specific internal objects (e.g. buffer specific properties), so you need fields to tell the kernel with which object
[PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
Hi,
This i2c init should stop the interrupt storm that happens in some cards when
the IR receiver in enabled.
It works perfectly in my TBS6981.
It would be good to test in other problematic cards.
In this patch I've added the IR init to the TeVii S470/S471 (and some others
that fall in the same case statment).
Other cards but these that suffer the same issue should also be tested.
Give feedback!
Regards,
Luis
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/pci/cx23885/cx23885-cards.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 7e923f8..89ce132 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -1081,6 +1081,27 @@ int cx23885_tuner_callback(void *priv, int component,
int command, int arg)
return 0;
}
+void cx23885_ir_setup(struct cx23885_dev *dev)
+{
+ struct i2c_msg msg;
+ char buffer[2];
+
+ /* this should stop the IR interrupt
+ storm that happens in some cards */
+ msg.addr = 0x4c;
+ msg.flags = 0;
+ msg.len = 2;
+ msg.buf = buffer;
+
+ buffer[0] = 0x1f;
+ buffer[1] = 0x80;
+ i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+
+ buffer[0] = 0x23;
+ buffer[1] = 0x80;
+ i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+}
+
void cx23885_gpio_setup(struct cx23885_dev *dev)
{
switch (dev-board) {
@@ -1664,6 +1685,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts1-gen_ctrl_val = 0x5; /* Parallel */
ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ cx23885_ir_setup(dev);
break;
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
case CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF:
--
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] au8522_dig: fix snr lookup table
On Wed, Jul 17, 2013 at 8:30 PM, Chris Lee update...@gmail.com wrote: This patch fixes an if() statement that was preventing the last element in the table from ever being utilized, preventing the snr from ever displaying 27db. Also some of the gaps in the lookup table were filled in. Signed-off-by: Chris Lee update...@gmail.com I don't have any specific objection to this patch, other than that I have no idea if the values he's adding are actually correct. I'd have to pull out the datasheet and see what the formula looks like to actually calculate the correct values. This is of course assuming Chris didn't have the formula and just picked numbers that were roughly in between the adjacent values. The off-by-one is legit (syntactically at least - there is indeed no value that would result in 0 being selected), although frankly I don't know whether value 0 is supposed to be 26.0 or 27.0. It's entirely possible that 0=26.0 and the whole table is off by one value (this was actually the case with the QAM256 table, except in that case it was much worse because it was oscillating between 40.0 and 0.00). Anyway, hard to argue this isn't an improvement and thus shouldn't be accepted -- except for the real possibility that the patch introduces wrong values into the table. Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On Wed, Jul 17, 2013 at 9:33 PM, Luis Alves lja...@gmail.com wrote: Hi, This i2c init should stop the interrupt storm that happens in some cards when the IR receiver in enabled. It works perfectly in my TBS6981. What is at I2C address 0x4c? Might be useful to have a comment in there explaining what this patch actually does. This assumes you know/understand what it does - if you don't then a comment saying I don't know why this is needed but my board doesn't work right without it is just as valuable. It would be good to test in other problematic cards. In this patch I've added the IR init to the TeVii S470/S471 (and some others that fall in the same case statment). Other cards but these that suffer the same issue should also be tested. Without fully understanding the nature of this patch and what cards that it actually effects, it may make sense to move your board into a separate case statement. Generally it's bad form to make changes like against other cards without any testing against those cards (otherwise you can introduce regressions). Stick it in its own case statement, and users of the other boards can move their cards into that case statement *after* it's actually validated. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] [media] em28xx: Fix vidioc fmt vid cap v4l2 compliance
On Tue, Jul 16, 2013 at 7:06 PM, Alban Browaeys alban.browa...@gmail.com wrote: Set fmt.pix.priv to zero in vidioc_g_fmt_vid_cap and vidioc_try_fmt_vid_cap. Any reason not to have the v4l2 core do this before dispatching to the driver? Set it to zero before the core calls g_fmt. This avoids all the drivers (most of which don't use the field) from having to set the value themselves. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] au8522_dig: fix snr lookup table
It could be an off by one, I dont have a datasheet for the au8522 to know for sure. I filled in the blanks, ie 0 270 2 250 so I guessed that 1 is 260 Chris update...@gmail.com On Wed, Jul 17, 2013 at 7:41 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Wed, Jul 17, 2013 at 8:30 PM, Chris Lee update...@gmail.com wrote: This patch fixes an if() statement that was preventing the last element in the table from ever being utilized, preventing the snr from ever displaying 27db. Also some of the gaps in the lookup table were filled in. Signed-off-by: Chris Lee update...@gmail.com I don't have any specific objection to this patch, other than that I have no idea if the values he's adding are actually correct. I'd have to pull out the datasheet and see what the formula looks like to actually calculate the correct values. This is of course assuming Chris didn't have the formula and just picked numbers that were roughly in between the adjacent values. The off-by-one is legit (syntactically at least - there is indeed no value that would result in 0 being selected), although frankly I don't know whether value 0 is supposed to be 26.0 or 27.0. It's entirely possible that 0=26.0 and the whole table is off by one value (this was actually the case with the QAM256 table, except in that case it was much worse because it was oscillating between 40.0 and 0.00). Anyway, hard to argue this isn't an improvement and thus shouldn't be accepted -- except for the real possibility that the patch introduces wrong values into the table. Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On 07/18/2013 04:58 AM, Devin Heitmueller wrote: On Wed, Jul 17, 2013 at 9:33 PM, Luis Alves lja...@gmail.com wrote: Hi, This i2c init should stop the interrupt storm that happens in some cards when the IR receiver in enabled. It works perfectly in my TBS6981. What is at I2C address 0x4c? Might be useful to have a comment in there explaining what this patch actually does. This assumes you know/understand what it does - if you don't then a comment saying I don't know why this is needed but my board doesn't work right without it is just as valuable. It would be good to test in other problematic cards. In this patch I've added the IR init to the TeVii S470/S471 (and some others that fall in the same case statment). Other cards but these that suffer the same issue should also be tested. Without fully understanding the nature of this patch and what cards that it actually effects, it may make sense to move your board into a separate case statement. Generally it's bad form to make changes like against other cards without any testing against those cards (otherwise you can introduce regressions). Stick it in its own case statement, and users of the other boards can move their cards into that case statement *after* it's actually validated. Devin hmm, I looked again the cx23885 driver. 0x4c == [0x98 1] = flatiron == some internal block of the chip There is routine which dumps registers out, 0x00 - 0x23 cx23885_flatiron_dump() There is also existing routine to write those Flatiron registers. So, that direct I2C access could be shorten to: cx23885_flatiron_write(dev, 0x1f, 0x80); cx23885_flatiron_write(dev, 0x23, 0x80); Unfortunately these two register names are not defined. Something clock or interrupt related likely. 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
Re: [PATCH] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.
On Wed, Jul 17, 2013 at 10:15 PM, Antti Palosaari cr...@iki.fi wrote: hmm, I looked again the cx23885 driver. 0x4c == [0x98 1] = flatiron == some internal block of the chip Yeah, ok. Pretty sure Flatiron is the codename for the ADC for the SIF. There is routine which dumps registers out, 0x00 - 0x23 cx23885_flatiron_dump() There is also existing routine to write those Flatiron registers. So, that direct I2C access could be shorten to: cx23885_flatiron_write(dev, 0x1f, 0x80); cx23885_flatiron_write(dev, 0x23, 0x80); Yeah, the internal register routines should be used to avoid confusion. Unfortunately these two register names are not defined. Something clock or interrupt related likely. Strange. The ADC output is usually tied directly to the Merlin. I wonder why it would ever generate interrupts. No easy answers here. WIll probably have to take a closer look at the datasheet, or just ask Andy. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 05/10] exynos5-fimc-is: Adds the sensor subdev
Hi Sylwester, On Wed, Jul 17, 2013 at 7:44 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 07/17/2013 06:55 AM, Arun Kumar K wrote: On Wed, Jul 17, 2013 at 3:33 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 07/09/2013 02:04 PM, Arun Kumar K wrote: On Wed, Jun 26, 2013 at 12:57 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Fri May 31 2013 15:03:23 Arun Kumar K wrote: FIMC-IS uses certain sensors which are exclusively controlled from the IS firmware. This patch adds the sensor subdev for the fimc-is sensors. Signed-off-by: Arun Kumar Karun...@samsung.com Signed-off-by: Kilyeon Imkilyeon...@samsung.com Not surprisingly I really hate the idea of sensor drivers that are tied to a specific SoC, since it completely destroys the reusability of such drivers. Yes agree to it. I understand that you have little choice to do something special here, but I was wondering whether there is a way of keeping things as generic as possible. I'm just brainstorming here, but as far as I can see this driver is basically a partial sensor driver: it handles the clock, the format negotiation and power management. Any sensor driver needs that. What would be nice is if the fmic specific parts are replaced by callbacks into the bridge driver using v4l2_subdev_notify(). The platform data (or DT) can also state if this sensor is firmware controlled or not. If not, then the missing bits can be implemented in the future by someone who needs that. That way the driver itself remains independent from fimc. And existing sensor drivers can be adapted to be usable with fimc as well by adding support for the notify callback. Would a scheme along those lines work? Yes this should make the implementation very generic. Will check the feasibility of this approach. Is I suggested earlier, you likely could do without this call back to the FIMC-IS from within the sensor subdev. Look at your call chain right now: /dev/video? media-dev-driversensor-subdev FIMC-IS | | | | | VIDIOC_STREAMON | | | |# s_stream()| | | #--# pipeline_open() | | | # | | | # pipeline_start() | | | # | | | | | Couldn't you move pipeline_open(), pipeline_start() to s_stream handler of the ISP subdev ? It is currently empty. The media device driver could call s_stream on the ISP subdev each time it sees s_stream request on the sensor subdev. And you wouldn't need any hacks to get the pipeline pointer in the sensor subdev. Then it would be something like: /dev/video? media-dev-driversensor-subdev FIMC-IS-ISP-subdev | | | | | VIDIOC_STREAMON | | | |# s_stream()| | | #--| | | # s_stream()| | | #---+# pipeline_open() | | | # pipeline_start() | | | # I suppose pipeline_open() is better candidate for the s_power callback. It just needs to be ensured at the media device level the subdev operations sequences are correct. It can be done this way. But my intention of putting these calls in the sensor subdev was to use the sensor subdev independent of isp subdev. This is for the usecase where the pipeline will only contain is-sensor -- mipi-csis -- fimc-lite --- memory This way you can capture the bayer rgb data from sensor without using any isp components at all. The second pipeline which is isp -- scc -- scp can be used for processing the sensor data and can be created and used if needed. In the method you mentioned, the isp subdev has to be used even when it is not part of the pipeline. Is that allowed? If its allowed as per media pipeline guidelines, then this definitely is a better approach. Please suggest on this. Sure, I'm aware of those two relatively separate pipelines. s_power, s_stream callbacks belong to the kernel so I don't think it would be an issue to do it as I described. Please note s_power, s_stream are normally reference counted. Alternatively you could create a separate subdev for the FIMC-IS firmware interface. Such subdev wouldn't be exposing device node and would be used by the media pipeline controller driver to ensure proper hardware configuration sequences. I don't know the Exynos5 FIMC-IS firmware architecture very well so I'm not sure if it is worth to create such a separate
