Re: [PATCH v2 1/2] v4l: Add new alpha component control
On 11/29/2011 07:58 PM, Laurent Pinchart wrote: On Tuesday 29 November 2011 19:30:25 Hans Verkuil wrote: On Tuesday, November 29, 2011 19:10:39 Laurent Pinchart wrote: On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: On 11/29/2011 12:08 PM, Hans Verkuil wrote: On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: On 11/28/2011 01:39 PM, Hans Verkuil wrote: On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: On 11/28/2011 12:38 PM, Hans Verkuil wrote: On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: Here is a patch that updates the range. It also sends a control event telling any listener that the range has changed. Tested with vivi and a modified v4l2-ctl. The only thing missing is a DocBook entry for that new event flag and perhaps some more documentation in places. Let me know how this works for you, and if it is really needed, then I can add it to the control framework. Thanks for your work, it's very appreciated. I've tested the patch with s5p-fimc and it works well. I just didn't check the event part yet. I spoke to Kamil as in the past he considered the control range updating at the codec driver. But since separate controls are used for different encoding standards, this is not needed it any more. Nevertheless I have at least two use cases, for the alpha control and for the image sensor driver. In case of the camera sensor, different device revisions may have different step and maximum value for some controls, depending on firmware. By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor start-up procedure just to find out properties of some controls. Wouldn't it be confusing for applications to start with a range and have it updated at runtime ? Good question. It was a nice exercise creating the range_update() function and it works well, but it this something we want to do? I think that being able to modify the range is a very useful functionality. It's just that in this case the sensor would start with a default range and switch to another based on the model. It would be better if we could start with the right range from the start. If we do, then we should mark such controls with a flag (_VOLATILE_RANGE or something like that) so apps know that the range isn't fixed. I think that when it comes to apps writing or reading such a control directly it isn't a problem. But for applications that automatically generate control panels (xawtv et al) it is rather complex to support such things. Hans, are you going to carry on with the control range update patches ? I'd like to push the alpha colour control for v3.3 but it depends on the controls framework updates now. Another use case for control range update would be with an auto-exposure metering spot location controls. An available range for x and y coordinates would depend on selected pixel resolution. If we would have created two controls for (x, y) their range would depend on pixel (width, height) respectively. So when a new format is set such controls would need to get their range updated. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Hi Christoph, On 07-12-2011 19:54, Christoph Pfister wrote: 2011/12/7 Mauro Carvalho Chehabmche...@redhat.com: snip Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz). Well, auto-Italy is a superset of the it-* files. For example T 17750 7MHz exists in some files (Modena, Montevergina) and T 17750 8MHz in others (Sassari), so both possibilities have to appear in auto-Italy (similar for other VHF frequencies, it simply doesn't seem to be regulated). There's nothing to fix there, auto-Italy exists exactly because of these irregularities. I see. From Gianluca's email and from w_scan code, I understood that 8 MHz on VHF in Italy is not used there anymore. If there are places there using 8 MHz, then w_scan requires a fix. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-930C DVB-T mode report
On 08-12-2011 07:10, Eddi De Pieri wrote: I test again HVR930C without the patch for XC5000 that added regression to other tuners. Attached the results using scan (ubuntu) Actually HVR-930C seems one of the usb dvb-t tuner I own with best sensitivity. using w_scan: root@depieri1lnx:~# w_scan -f t -c IT root@depieri1lnx:~# w_scan -f t -c IT w_scan version 20110616 (compiled for DVB API 5.3) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -Ccharset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend1) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-T' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (47.12MHz ... 865.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) [...] 834000: (time: 02:46) (time: 02:48) 842000: (time: 02:50) 85: (time: 02:52) (time: 02:55) 858000: (time: 02:56) (time: 02:58) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! With regards to Italy, w_scan does something different than scan. The auto-italy table used by scan tries several channels with both 8MHz and 7MHz, while w_scan only tries 7MHz for VHF. This might explain the issue, if you're still able to scan/tune with scan and if you have a good antenna. Regards Eddi -- 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 1/2] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu josh...@atmel.com
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
v3: using IS_ERR() to check return value of clk_get() instead of using
IS_ERR_OR_NULL()
drivers/media/video/atmel-isi.c | 31 +--
include/media/atmel-isi.h |4 +++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index fbc904f..44789f0 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -90,7 +90,10 @@ struct atmel_isi {
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
struct completion complete;
+ /* ISI peripherial clock */
struct clk *pclk;
+ /* ISI_MCK, feed to camera sensor to generate pixel clock */
+ struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -766,6 +769,12 @@ static int isi_camera_add_device(struct soc_camera_device
*icd)
if (ret)
return ret;
+ ret = clk_enable(isi-mck);
+ if (ret) {
+ clk_disable(isi-pclk);
+ return ret;
+ }
+
isi-icd = icd;
dev_dbg(icd-parent, Atmel ISI Camera driver attached to camera %d\n,
icd-devnum);
@@ -779,6 +788,7 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd)
BUG_ON(icd != isi-icd);
+ clk_disable(isi-mck);
clk_disable(isi-pclk);
isi-icd = NULL;
@@ -874,7 +884,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd, u32 pixfmt)
if (isi-pdata-has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-isi_full_mode)
+ if (isi-pdata-full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -912,6 +922,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_put(isi-mck);
clk_put(isi-pclk);
kfree(isi);
@@ -930,7 +941,7 @@ static int __devinit atmel_isi_probe(struct platform_device
*pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if (!pdata || !pdata-data_width_flags || !pdata-mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -959,6 +970,19 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
+ /* Get ISI_MCK, provided by programmable clock or external clock */
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR(isi-mck)) {
+ dev_err(dev, Failed to get isi_mck\n);
+ ret = PTR_ERR(isi-mck);
+ goto err_clk_get;
+ }
+
+ /* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ if (ret 0)
+ goto err_set_mck_rate;
+
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
@@ -1034,6 +1058,9 @@ err_alloc_ctx:
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
err_alloc_descriptors:
+err_set_mck_rate:
+ clk_put(isi-mck);
+err_clk_get:
kfree(isi);
err_alloc_isi:
clk_put(pclk);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..6568230 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -110,10 +110,12 @@ struct isi_platform_data {
u8 hsync_act_low;
u8 vsync_act_low;
u8 pclk_act_falling;
- u8 isi_full_mode;
+ u8 full_mode;
u32 data_width_flags;
/* Using for ISI_CFG1 */
u32 frate;
+ /* Using for ISI_MCK */
+ u32 mck_hz;
};
#endif /* __ATMEL_ISI_H__ */
--
1.6.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
[PATCH v3 2/2] [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions
Signed-off-by: Josh Wu josh...@atmel.com
---
in v2 version, made the label name to be consistent
drivers/media/video/atmel-isi.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index ea4eef4..91ebcfb 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -922,7 +922,9 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_unprepare(isi-mck);
clk_put(isi-mck);
+ clk_unprepare(isi-pclk);
clk_put(isi-pclk);
kfree(isi);
@@ -955,6 +957,12 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
if (IS_ERR(pclk))
return PTR_ERR(pclk);
+ ret = clk_prepare(pclk);
+ if (ret) {
+ clk_put(pclk);
+ return ret;
+ }
+
isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
if (!isi) {
ret = -ENOMEM;
@@ -978,6 +986,10 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_clk_get;
}
+ ret = clk_prepare(isi-mck);
+ if (ret)
+ goto err_clk_prepare_mck;
+
/* Set ISI_MCK's frequency, it should be faster than pixel clock */
ret = clk_set_rate(isi-mck, pdata-mck_hz);
if (ret 0)
@@ -1059,10 +1071,13 @@ err_alloc_ctx:
isi-fb_descriptors_phys);
err_alloc_descriptors:
err_set_mck_rate:
+ clk_unprepare(isi-mck);
+err_clk_prepare_mck:
clk_put(isi-mck);
err_clk_get:
kfree(isi);
err_alloc_isi:
+ clk_unprepare(pclk);
clk_put(pclk);
return ret;
--
1.6.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
Re: [PATCH v2] media: vb2: vmalloc-based allocator user pointer handling
Hi Marek and Andrzej,
Thanks for the patch.
On Wednesday 07 December 2011 17:29:06 Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds support for user pointer memory buffers to vmalloc
videobuf2 allocator.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/video/videobuf2-vmalloc.c | 97
--- 1 files changed, 89 insertions(+), 8
deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c index a3a8842..8843ad0 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -12,6 +12,7 @@
#include linux/module.h
#include linux/mm.h
+#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
@@ -20,7 +21,10 @@
struct vb2_vmalloc_buf {
void*vaddr;
+ struct page **pages;
+ int write;
unsigned long size;
+ unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -42,14 +46,14 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx,
unsigned long size) buf-handler.arg = buf;
if (!buf-vaddr) {
- printk(KERN_ERR vmalloc of size %ld failed\n, buf-size);
+ pr_err(vmalloc of size %ld failed\n, buf-size);
kfree(buf);
return NULL;
}
atomic_inc(buf-refcount);
- printk(KERN_DEBUG Allocated vmalloc buffer of size %ld at vaddr=%p\n,
- buf-size, buf-vaddr);
+ pr_err(Allocated vmalloc buffer of size %ld at vaddr=%p\n, buf-size,
+buf-vaddr);
Turning KERN_DEBUG into pr_err() is a bit harsh :-) In my opinion even
KERN_DEBUG is too much here, I don't want to get messages printed to the
kernel log every time I allocate buffers.
return buf;
}
@@ -59,13 +63,87 @@ static void vb2_vmalloc_put(void *buf_priv)
struct vb2_vmalloc_buf *buf = buf_priv;
if (atomic_dec_and_test(buf-refcount)) {
- printk(KERN_DEBUG %s: Freeing vmalloc mem at vaddr=%p\n,
- __func__, buf-vaddr);
+ pr_debug(%s: Freeing vmalloc mem at vaddr=%p\n, __func__,
+ buf-vaddr);
Same here. Should we get rid of those two messages, or at least conditionally-
compile them out of the kernel by default ?
vfree(buf-vaddr);
kfree(buf);
}
}
+static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr,
+ unsigned long size, int write)
+{
+ struct vb2_vmalloc_buf *buf;
+
No need for a blank line.
+ unsigned long first, last;
+ int n_pages_from_user, offset;
You seem to like long names :-) I'd use n_pages, and I would also shorten the
labels below, but that's just me.
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
The kernel coding style encourages parenthesis after the sizeof operator:
sizeof(*buf).
+ if (!buf)
+ return NULL;
+
+ buf-write = write;
+ offset = vaddr ~PAGE_MASK;
+ buf-size = size;
+
+ first = (vaddr PAGE_MASK) PAGE_SHIFT;
+ last = ((vaddr + size - 1) PAGE_MASK) PAGE_SHIFT;
If you shift right anyway is there a need to PAGE_MASK first ?
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
It's a common practice in the kernel to use variables instead of types when
possible with the sizeof operator: sizeof(buf-pages). That's up to you.
+ if (!buf-pages)
+ goto userptr_fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf core */
+ n_pages_from_user = get_user_pages(current, current-mm,
+ vaddr PAGE_MASK,
+ buf-n_pages,
+ write,
+ 1, /* force */
+ buf-pages,
+ NULL);
+ if (n_pages_from_user != buf-n_pages)
+ goto userptr_fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
+
No need for a blank line.
+ if (!buf-vaddr)
+ goto userptr_fail_get_user_pages;
+
+ buf-vaddr += offset;
+ return buf;
+
+userptr_fail_get_user_pages:
+ pr_debug(get_user_pages requested/got: %d/%d]\n, n_pages_from_user,
+ buf-n_pages);
+ while (--n_pages_from_user = 0)
+ put_page(buf-pages[n_pages_from_user]);
+ kfree(buf-pages);
+
+userptr_fail_pages_array_alloc:
+
[PATCH v2] as3645a: Handle power on errors when registering the device
Return an error in the registered handler if the device can't be powered
on.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/as3645a.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
Hi everybody,
This second version of the as3645a power on patch fixes a problem with the power
on operation that would leave the chip powered when it can't be initialized. It
still applies on top of the as3645a driver that I'm going to submit for
v3.3.
diff --git a/drivers/media/video/as3645a.c b/drivers/media/video/as3645a.c
index d583a9c..0ed52ee 100644
--- a/drivers/media/video/as3645a.c
+++ b/drivers/media/video/as3645a.c
@@ -523,7 +523,16 @@ static int __as3645a_set_power(struct as3645a *flash, int
on)
return ret;
}
- return on ? as3645a_setup(flash) : 0;
+ if (!on)
+ return 0;
+
+ ret = as3645a_setup(flash);
+ if (ret 0) {
+ if (flash-pdata-set_power)
+ flash-pdata-set_power(flash-subdev, 0);
+ }
+
+ return ret;
}
static int as3645a_set_power(struct v4l2_subdev *sd, int on)
@@ -557,7 +566,9 @@ static int as3645a_registered(struct v4l2_subdev *sd)
/* Power up the flash driver and read manufacturer ID, model ID, RFU
* and version.
*/
- as3645a_set_power(flash-subdev, 1);
+ rval = as3645a_set_power(flash-subdev, 1);
+ if (rval 0)
+ return rval;
rval = as3645a_read(flash, AS_DESIGN_INFO_REG);
if (rval 0)
--
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 v2 1/2] v4l: Add new alpha component control
Hi Laurent, On 12/08/2011 11:30 AM, Laurent Pinchart wrote: Another use case for control range update would be with an auto-exposure metering spot location controls. An available range for x and y coordinates would depend on selected pixel resolution. If we would have created two controls for (x, y) their range would depend on pixel (width, height) respectively. So when a new format is set such controls would need to get their range updated. To be honest I'm not sure whether points, and especially rectangles, should be handled as controls. We have no structure-like control type at the moment, adding points might be possible, but rectangles would require either 2 point- liek controls or 4 controls (left, top, width, height). I don't really like that. A new API (possibly based on the selection API ?) might be better. Indeed, I don't like having 4 controls for specifying a rectangle as well, it doesn't just sound right. I was concerned about specifying a point using the selection API. But it could be just (left=x, top=y, width=1, height=1). -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] MEM2MEM: Add support for eMMa-PrP mem2mem operations.
On 23-11-2011 13:13, Javier Martin wrote: Changes since v2: - Use devres to simplify error handling. - Remove unused structures. - Fix clock handling. - Other minor problems. This is a bad description. It makes no sense to add a changes since v2 at the merge. Please add a proper description here instead. If you want to put comments like the above for the reviewers, fine, but please put it after a line with ---, in order to allow Patchwork (and other maintainers tools) to discard it when merging. Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Javier Martinjavier.mar...@vista-silicon.com --- drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile |2 + drivers/media/video/mx2_emmaprp.c | 1008 + 3 files changed, 1020 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mx2_emmaprp.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index b303a3f..e8ce0c2 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1107,4 +1107,14 @@ config VIDEO_SAMSUNG_S5P_MFC help MFC 5.1 driver for V4L2. +config VIDEO_MX2_EMMAPRP + tristate MX2 eMMa-PrP support + depends on VIDEO_DEV VIDEO_V4L2 SOC_IMX27 + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + MX2X chips have a PrP that can be used to process buffers from + memory to memory. Operations include resizing and format + conversion. + endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 117f9c4..7ae711e 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -176,6 +176,8 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o +obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o + obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) += s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/ diff --git a/drivers/media/video/mx2_emmaprp.c b/drivers/media/video/mx2_emmaprp.c new file mode 100644 index 000..fef996e --- /dev/null +++ b/drivers/media/video/mx2_emmaprp.c @@ -0,0 +1,1008 @@ +/* + * Support eMMa-PrP through mem2mem framework. + * + * eMMa-PrP is a piece of HW that allows fetching buffers + * from one memory location and do several operations on + * them such as scaling or format conversion giving, as a result + * a new processed buffer in another memory location. + * + * Based on mem2mem_testdev.c by Pawel Osciak. + * + * Copyright (c) 2011 Vista Silicon S.L. + * Javier Martinjavier.mar...@vista-silicon.com + * + * 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 + */ +#includelinux/module.h +#includelinux/clk.h +#includelinux/slab.h +#includelinux/interrupt.h +#includelinux/io.h + +#includelinux/platform_device.h +#includemedia/v4l2-mem2mem.h +#includemedia/v4l2-device.h +#includemedia/v4l2-ioctl.h +#includemedia/videobuf2-dma-contig.h +#includeasm/sizes.h + +#define EMMAPRP_MODULE_NAME mem2mem-emmaprp + +MODULE_DESCRIPTION(Mem-to-mem device which supports eMMa-PrP present in mx2 SoCs); +MODULE_AUTHOR(Javier Martinjavier.mar...@vista-silicon.com); +MODULE_LICENSE(GPL); +MODULE_VERSION(0.0.1); + +static bool debug; +module_param(debug, bool, 0644); + +#define MIN_W 32 +#define MIN_H 32 +#define MAX_W 2040 +#define MAX_H 2046 + +#define W_ALIGN_MASK_YUV4200x07 /* multiple of 8 */ +#define W_ALIGN_MASK_OTHERS0x03 /* multiple of 4 */ +#define H_ALIGN_MASK 0x01 /* multiple of 2 */ + +/* Flags that indicate a format can be used for capture/output */ +#define MEM2MEM_CAPTURE(1 0) +#define MEM2MEM_OUTPUT (1 1) + +#define MEM2MEM_NAME m2m-emmaprp + +/* In bytes, per queue */ +#define MEM2MEM_VID_MEM_LIMIT SZ_16M + +#define dprintk(dev, fmt, arg...) \ + v4l2_dbg(1, debug,dev-v4l2_dev, %s: fmt, __func__, ## arg) + +/* EMMA PrP */ +#define PRP_CNTL0x00 +#define PRP_INTR_CNTL 0x04 +#define PRP_INTRSTATUS 0x08 +#define PRP_SOURCE_Y_PTR0x0c +#define PRP_SOURCE_CB_PTR 0x10 +#define PRP_SOURCE_CR_PTR 0x14 +#define PRP_DEST_RGB1_PTR 0x18 +#define PRP_DEST_RGB2_PTR 0x1c +#define PRP_DEST_Y_PTR 0x20 +#define PRP_DEST_CB_PTR 0x24 +#define PRP_DEST_CR_PTR 0x28 +#define PRP_SRC_FRAME_SIZE 0x2c +#define PRP_DEST_CH1_LINE_STRIDE0x30 +#define PRP_SRC_PIXEL_FORMAT_CNTL 0x34 +#define PRP_CH1_PIXEL_FORMAT_CNTL 0x38 +#define
[PATCH 0/1] xc3028: fix center frequency calculation for DTV78 firmware
Hi all, this patch replaces the previous one proposed in the thread xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator. The problem is that the firmware DTV78 works fine in UHF band (8 MHz bandwidth) but is not working at all in VHF band (7 MHz bandwidth). Reading the comments inside the code, I figured out that the real problem could be connected to the formula used to calculate the center frequency offset in VHF band. In fact, removing this adjustment fixed the problem: if ((priv-cur_fw.type DTV78) freq 47000) offset -= 50; This is coherent to what was implemented for the DTV7 firmware by an Australian user: if (priv-cur_fw.type DTV7) offset += 50; In the end, the center frequency is the same for all firmwares (DTV7, DTV8, DTV78) and for both 7 and 8 MHz bandwidth. Probably, a further offset is hardcoded directly into the firmwares, to compensate the difference between 7 and 8 MHz bandwidth. The final code looks clean and simple, and there is no need for any magic adjustment: if (priv-cur_fw.type DTV6) offset = 175; else/* DTV7 or DTV8 or DTV78 */ offset = 275; Best regards, Gianluca Gennari -- 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/2] MX2: Add platform definitions for eMMa-PrP device.
On 23-11-2011 13:13, Javier Martin wrote:
eMMa-PrP device included in Freescale i.MX2 chips can also
be used separately to process memory buffers.
This patch is just the arch glue to the driver, so it should be applied via the
media tree, and likely as patch 2, in order to avoid breaking git bisect.
Yet, I'd like to have the mach-imx maintainer's ack on this.
Regards,
Mauro.
Changes since v2:
- Define imx_add_mx2_emmaprp function which also registers device,
not only alloc.
- Change definition of emma_clk.
- Minor fixes.
Signed-off-by: Javier Martinjavier.mar...@vista-silicon.com
---
arch/arm/mach-imx/clock-imx27.c |2 +-
arch/arm/mach-imx/devices-imx27.h |2 ++
arch/arm/plat-mxc/devices/platform-mx2-camera.c | 18 ++
arch/arm/plat-mxc/include/mach/devices-common.h |2 ++
4 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-imx/clock-imx27.c b/arch/arm/mach-imx/clock-imx27.c
index 88fe00a..dc2d7a5 100644
--- a/arch/arm/mach-imx/clock-imx27.c
+++ b/arch/arm/mach-imx/clock-imx27.c
@@ -661,7 +661,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK(NULL, dma, dma_clk)
_REGISTER_CLOCK(NULL, rtic, rtic_clk)
_REGISTER_CLOCK(NULL, brom, brom_clk)
- _REGISTER_CLOCK(NULL, emma, emma_clk)
+ _REGISTER_CLOCK(m2m-emmaprp.0, NULL, emma_clk)
_REGISTER_CLOCK(NULL, slcdc, slcdc_clk)
_REGISTER_CLOCK(imx27-fec.0, NULL, fec_clk)
_REGISTER_CLOCK(NULL, emi, emi_clk)
diff --git a/arch/arm/mach-imx/devices-imx27.h
b/arch/arm/mach-imx/devices-imx27.h
index 2f727d7..28537a5 100644
--- a/arch/arm/mach-imx/devices-imx27.h
+++ b/arch/arm/mach-imx/devices-imx27.h
@@ -50,6 +50,8 @@ extern const struct imx_imx_uart_1irq_data
imx27_imx_uart_data[];
extern const struct imx_mx2_camera_data imx27_mx2_camera_data;
#define imx27_add_mx2_camera(pdata) \
imx_add_mx2_camera(imx27_mx2_camera_data, pdata)
+#define imx27_add_mx2_emmaprp(pdata) \
+ imx_add_mx2_emmaprp(imx27_mx2_camera_data)
extern const struct imx_mxc_ehci_data imx27_mxc_ehci_otg_data;
#define imx27_add_mxc_ehci_otg(pdata) \
diff --git a/arch/arm/plat-mxc/devices/platform-mx2-camera.c
b/arch/arm/plat-mxc/devices/platform-mx2-camera.c
index b3f4828..11eace9 100644
--- a/arch/arm/plat-mxc/devices/platform-mx2-camera.c
+++ b/arch/arm/plat-mxc/devices/platform-mx2-camera.c
@@ -62,3 +62,21 @@ struct platform_device *__init imx_add_mx2_camera(
res, data-iobaseemmaprp ? 4 : 2,
pdata, sizeof(*pdata), DMA_BIT_MASK(32));
}
+
+struct platform_device *__init imx_add_mx2_emmaprp(
+ const struct imx_mx2_camera_data *data)
+{
+ struct resource res[] = {
+ {
+ .start = data-iobaseemmaprp,
+ .end = data-iobaseemmaprp + data-iosizeemmaprp - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = data-irqemmaprp,
+ .end = data-irqemmaprp,
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+ return imx_add_platform_device_dmamask(m2m-emmaprp, 0,
+ res, 2, NULL, 0, DMA_BIT_MASK(32));
+}
diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h
b/arch/arm/plat-mxc/include/mach/devices-common.h
index def9ba5..1b2258d 100644
--- a/arch/arm/plat-mxc/include/mach/devices-common.h
+++ b/arch/arm/plat-mxc/include/mach/devices-common.h
@@ -223,6 +223,8 @@ struct imx_mx2_camera_data {
struct platform_device *__init imx_add_mx2_camera(
const struct imx_mx2_camera_data *data,
const struct mx2_camera_platform_data *pdata);
+struct platform_device *__init imx_add_mx2_emmaprp(
+ const struct imx_mx2_camera_data *data);
#includemach/mxc_ehci.h
struct imx_mxc_ehci_data {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] xc3028: fix center frequency calculation for DTV78 firmware
Updated center frequency calculation to fix VHF band reception with firmware DTV78. The adjustment for DTV78 is not needed anymore with new firmwares, since the offset is not depending anymore on the bandwidth or the firmware version (at least for DTV7, DTV8, DTV78). Signed-off-by: Gianluca Gennari gennar...@gmail.com --- drivers/media/common/tuners/tuner-xc2028.c | 22 -- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index e531267..7653aca 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -962,14 +962,20 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, * For DTV 7/8, the firmware uses BW = 8000, so it needs a * further adjustment to get the frequency center on VHF */ + + /* +* The center frequency formula above seems no more correct. +* The adjustment for DTV78 is not needed anymore with new +* firmwares, since the offset is not depending anymore on the +* bandwidth or the firmware version (at least for DTV78). +* This is probably a consequence of the SCODE table adjustments +* mentioned in the comment below. +*/ + if (priv-cur_fw.type DTV6) offset = 175; - else if (priv-cur_fw.type DTV7) - offset = 225; - else/* DTV8 or DTV78 */ + else/* DTV7 or DTV8 or DTV78 */ offset = 275; - if ((priv-cur_fw.type DTV78) freq 47000) - offset -= 50; /* * xc3028 additional magic @@ -979,17 +985,13 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, * newer firmwares */ -#if 1 /* * The proper adjustment would be to do it at s-code table. * However, this didn't work, as reported by * Robert Lowery rglow...@exemail.com.au */ - if (priv-cur_fw.type DTV7) - offset += 50; - -#else +#if 0 /* * Still need tests for XC3028L (firmware 3.2 or upper) * So, for now, let's just comment the per-firmware -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-930C DVB-T mode report
On 12/08/11 11:12, Mauro Carvalho Chehab wrote: -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) [...] 834000: (time: 02:46) (time: 02:48) 842000: (time: 02:50) 85: (time: 02:52) (time: 02:55) 858000: (time: 02:56) (time: 02:58) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! With regards to Italy, w_scan does something different than scan. The auto-italy table used by scan tries several channels with both 8MHz and 7MHz, while w_scan only tries 7MHz for VHF. This might explain the issue, if you're still able to scan/tune with scan and if you have a good antenna. Regards Eddi -- 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 Are there similar problems while scanning DVB-C nets with w_scan? And, is there a scan everything table for dvbscan? Regards, Fredrik -- 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] as3645a: Handle power on errors when registering the device
Hi, Laurent! On Thu, Dec 08, 2011 at 12:00:52PM +0100, Laurent Pinchart wrote: Return an error in the registered handler if the device can't be powered on. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Looks good to me. Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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: Hauppauge HVR-930C problems
On 08-12-2011 06:31, Fredrik Lingvall wrote:
On 12/07/11 15:54, Mauro Carvalho Chehab wrote:
lin-tv ~ # lsusb | grep Bus 002
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 008: ID 2040:1605 Hauppauge
There's nothing at the DVB core returning -ENOSPC.
Try to add just one line to a channels file, like this one:
C 60200 690 NONE QAM256
(this is the transponder that failed with w_scan. You could also use one
of the transponders where you got a pid timeout with scan)
Then call scan with this file, using strace:
$ strace -e ioctl dvbscan channelfile
This would allow to see what ioctl returned -ENOSPC (error -28).
Regards,
Mauro
Mauro,
I made a small script to check if the w_scan results are consistent:
#!/bin/bash
for i in `seq 1 20`;
do
w_scan -fc -c NO 1 scan$i.log 2 scan$i.log
done
And I get outputs like this (the timing numbers differs of course somewhat
between different runs):
snip
586000: sr6900 (time: 10:21) sr6875 (time: 10:23)
594000: sr6900 (time: 10:26) sr6875 (time: 10:28)
602000: sr6900 (time: 10:31) (time: 10:32) signal ok:
QAM_256 f = 602000 kHz S6900C999
Info: NIT(actual) filter timeout
61: sr6900 (time: 10:44) sr6875 (time: 10:47)
618000: sr6900 (time: 10:49) sr6875 (time: 10:52)
626000: sr6900 (time: 10:54) sr6875 (time: 10:57)
snip
Then I did the test that you suggested:
lin-tv ~ # strace -e ioctl dvbscan -fc test_channel_file
scanning test_channel_file
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ioctl(3, FE_GET_INFO, 0x60b180) = 0
initial transponder 60200 690 0 5
tune to: 60200:INVERSION_AUTO:690:FEC_NONE:QAM_256
ioctl(3, FE_SET_FRONTEND, 0x7fff0581fb20) = 0
ioctl(3, FE_READ_STATUS, 0x7fff0581fb4c) = 0
ioctl(3, FE_READ_STATUS, 0x7fff0581fb4c) = 0
ioctl(4, DMX_SET_FILTER, 0x7fff0581e930) = 0
ioctl(5, DMX_SET_FILTER, 0x7fff0581e930) = 0
ioctl(6, DMX_SET_FILTER, 0x7fff0581e930) = 0
WARNING: filter timeout pid 0x0011
ioctl(5, DMX_STOP, 0x23) = 0
WARNING: filter timeout pid 0x
ioctl(4, DMX_STOP, 0x23) = 0
WARNING: filter timeout pid 0x0010
ioctl(6, DMX_STOP, 0x23) = 0
dumping lists (0 services)
Done.
I did not get the:
602000: sr6900 (time: 10:32) (time: 10:33) signal ok:
QAM_256 f = 602000 kHz S6900C999
start_filter:1415: ERROR: ioctl DMX_SET_FILTER failed: 28 No space left on
device
Info: NIT(actual) filter timeout
that I got before. The changes I made from before was 1) I unmounted the USB
disk and 2) I rebuild the xc5000 module where I removed the
mutex_lock(xc5000_list_mutex);
and
mutex_unlock(xc5000_list_mutex);
lines according to the discussion in the ... em28xx: initial support for HAUPPAUGE
HVR-930C again thread.
Ok, let's go by parts.
1) error 28 at DMX_SET_FILTER is really due to lack of space at the USB bus.
I've
double-checked at the code. The only place there where it could occur is when
dvb_dmxdev_feed_start() calls feed-ts-start_filtering(feed-ts), with should
be
pointing to em28xx_start_feed(), with tries to start the transfer URB's at
em28xx_init_isoc() by calling usb_submit_urb(). This is the only routine that
returns
ENOSPC on this chain.
It is very likely that what fixed it were the removal of the USB disk.
2) There is an error at the bandwidth calculus on xc5000. It is likely that it
is
using a 6MHz bandwidth filter, instead of a 8MHz one.
Please try the enclosed patch.
[media] xc5000,tda18271c2dd: Fix bandwidth calculus
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index ecd1f95..8279c45 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -708,9 +708,9 @@ static int xc5000_set_params(struct dvb_frontend *fe,
* is equal to 0.15 for Annex A, and 0.13 for annex C
*/
if (fe-dtv_property_cache.rolloff == ROLLOFF_13)
- bw = (params-u.qam.symbol_rate * 13) / 10;
+ bw = (params-u.qam.symbol_rate * 113) / 100;
else
- bw = (params-u.qam.symbol_rate * 15) / 10;
+ bw = (params-u.qam.symbol_rate * 115) / 100;
if (bw = 600) {
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c
b/drivers/media/dvb/frontends/tda18271c2dd.c
index de544f6..b66ca29 100644
--- a/drivers/media/dvb/frontends/tda18271c2dd.c
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -1158,9 +1158,9 @@ static int set_params(struct dvb_frontend *fe,
* is equal to 0.15 for Annex A, and 0.13 for annex C
*/
if (fe-dtv_property_cache.rolloff == ROLLOFF_13)
- bw = (params-u.qam.symbol_rate * 13) /
Re: HVR-930C DVB-T mode report
On 08-12-2011 12:00, Fredrik Lingvall wrote: On 12/08/11 11:12, Mauro Carvalho Chehab wrote: -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) [...] 834000: (time: 02:46) (time: 02:48) 842000: (time: 02:50) 85: (time: 02:52) (time: 02:55) 858000: (time: 02:56) (time: 02:58) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! With regards to Italy, w_scan does something different than scan. The auto-italy table used by scan tries several channels with both 8MHz and 7MHz, while w_scan only tries 7MHz for VHF. This might explain the issue, if you're still able to scan/tune with scan and if you have a good antenna. Regards Eddi -- 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 Are there similar problems while scanning DVB-C nets with w_scan? And, is there a scan everything table for dvbscan? No. Both w_scan/dvbscan get the same channels, and they match the channels available at the STB and with other boards. Btw, drivers/media/common/tuners/xc5000.c doesn't support 7MHz for DVB-T: case BANDWIDTH_7_MHZ: printk(KERN_ERR xc5000 bandwidth 7MHz not supported\n); return -EINVAL; This may explain why you're getting so few channels on it. Only channels marked as 8MHz will be tuned. I _suspect_ that: case BANDWIDTH_7_MHZ: case BANDWIDTH_8_MHZ: priv-bandwidth = BANDWIDTH_8_MHZ; priv-video_standard = DTV8; priv-freq_hz = params-frequency - 275; break; would be the right thing to do. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-fimc: Fix camera input configuration in subdev operations
When using only subdev user-space operations the camera interface input was not configured properly. Fix this by updating the corresponding data structure in set_fmt operation. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/s5p-fimc/fimc-capture.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c b/drivers/media/video/s5p-fimc/fimc-capture.c index 48b2592..bd9c034 100644 --- a/drivers/media/video/s5p-fimc/fimc-capture.c +++ b/drivers/media/video/s5p-fimc/fimc-capture.c @@ -1303,6 +1303,7 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd, mutex_lock(fimc-lock); set_frame_bounds(ff, mf-width, mf-height); + fimc-vid_cap.mf = *mf; ff-fmt = ffmt; /* Reset the crop rectangle if required. */ -- 1.7.8 -- 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: ERRORS
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:Thu Dec 8 19:00:19 CET 2011 git hash:2bf936290baff2507763a2540cd9029e70ae39e2 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On Wed, Dec 07, 2011 at 08:02:42AM +, Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] - OMAP3 ISP CCP2 input:0 [] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CCDC:0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source - OMAP3 ISP CCP2:0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CSI2a output:0 [] - OMAP3 ISP CCDC:0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - OMAP3 ISP CSI2a:1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 3-005d:0 [ENABLED] pad1: Source [UYVY2X8 720x625] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [UYVY2X8 720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] - OMAP3 ISP CCDC:2 [] - OMAP3 ISP preview input:0 [] pad1: Source [YUYV 4082x4088] - OMAP3 ISP preview output:0 [] - OMAP3 ISP resizer:0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source - OMAP3 ISP preview:0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink - OMAP3 ISP preview:1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082] - OMAP3 ISP CCDC:1 [] - OMAP3 ISP preview:1 [] - OMAP3 ISP resizer input:0 [] pad1: Source [YUYV 3312x4095] - OMAP3 ISP resizer output:0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source - OMAP3 ISP resizer:0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink - OMAP3 ISP resizer:1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann a...@arndb.de wrote: On Wednesday 07 December 2011, Semwal, Sumit wrote: Thanks for the excellent discussion - it indeed is very good learning for the relatively-inexperienced me :) So, for the purpose of dma-buf framework, could I summarize the following and rework accordingly?: 1. remove mmap() dma_buf_op [and mmap fop], and introduce cpu_start(), cpu_finish() ops to bracket cpu accesses to the buffer. Also add DMABUF_CPU_START / DMABUF_CPU_FINI IOCTLs? I think we'd be better off for now without the extra ioctls and just document that a shared buffer must not be exported to user space using mmap at all, to avoid those problems. Serialization between GPU and CPU is on a higher level than the dma_buf framework IMHO. Agreed. 2. remove sg_sync* ops for now (and we'll see if we need to add them later if needed) Just removing the sg_sync_* operations is not enough. We have to make the decision whether we want to allow a) only coherent mappings of the buffer into kernel memory (requiring an extension to the dma_map_ops on ARM to not flush caches at map/unmap time) b) not allowing any in-kernel mappings (same requirement on ARM, also limits the usefulness of the dma_buf if we cannot access it from the kernel or from user space) c) only allowing streaming mappings, even if those are non-coherent (requiring strict serialization between CPU (in-kernel) and dma users of the buffer) I think only allowing streaming access makes the most sense: - I don't see much (if any need) for the kernel to access a dma_buf - in all current usecases it just contains pixel data and no hw-specific things (like sg tables, command buffers, ..). At most I see the need for the kernel to access the buffer for dma bounce buffers, but that is internal to the dma subsystem (and hence does not need to be exposed). - Userspace can still access the contents through the exporting subsystem (e.g. use some gem mmap support). For efficiency reason gpu drivers are already messing around with cache coherency in a platform specific way (and hence violated the dma api a bit), so we could stuff the mmap coherency in there, too. When we later on extend dma_buf support so that other drivers than the gpu can export dma_bufs, we can then extend the official dma api with already a few drivers with use-patterns around. But I still think that the kernel must not be required to enforce correct access ordering for the reasons outlined in my other mail. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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
Initial tuning file update for fi-sonera
Update for fi-sonera Mikko -- diff -r bec11f78be51 util/scan/dvb-c/fi-sonera --- a/util/scan/dvb-c/fi-sonera Wed Dec 07 15:26:50 2011 +0100 +++ b/util/scan/dvb-c/fi-sonera Thu Dec 08 23:51:13 2011 +0200 @@ -5,8 +5,19 @@ C 15400 690 NONE QAM128 C 16200 690 NONE QAM128 C 17000 690 NONE QAM128 +C 23400 690 NONE QAM256 +C 24200 690 NONE QAM256 +C 25000 690 NONE QAM256 +C 25800 690 NONE QAM256 +C 26600 690 NONE QAM256 C 31400 690 NONE QAM128 C 32200 690 NONE QAM128 C 33800 690 NONE QAM128 C 34600 690 NONE QAM128 C 35400 690 NONE QAM128 +C 36200 690 NONE QAM128 +C 37000 690 NONE QAM128 +C 37800 690 NONE QAM128 +C 38600 690 NONE QAM128 +C 39400 690 NONE QAM128 +C 40200 690 NONE QAM128 -- 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 v1 5/7] media: v4l2: introduce two IOCTLs for face detection
On 12/08/2011 04:42 AM, Ming Lei wrote:
+/**
+ * struct v4l2_obj_detection
+ * @buf_index: entry, index of v4l2_buffer for face detection
I would prefer having the frame sequence number here. It will be more
future proof IMHO. If for instance we decide to use such an ioctl on
a v4l2 sub-device, without dequeuing buffers, there will be no problem
with that. And still in your specific use case it's not big deal to
look up the buffer index given it's sequence number in the application.
+ * @centerx: return, position in x direction of detected object
+ * @centery: return, position in y direction of detected object
+ * @angle: return, angle of detected object
+ * 0 deg ~ 359 deg, vertical is 0 deg, clockwise
+ * @sizex: return, size in x direction of detected object
+ * @sizey: return, size in y direction of detected object
+ * @confidence: return, confidence level of detection result
+ * 0: the heighest level, 9: the lowest level
Hmm, not a good idea to align a public interface to the capabilities
of a single hardware implementation.
I think that the current omap interface is general enough, so why can't
we use it as public interface?
I meant exactly the line implying the range. What if for some hardware
it's 0..11 ?
min/max confidence could be queried with
relevant controls and here we could remove the line implying range.
No, the confidence is used to describe the probability about
the correctness of the current detection result. Anyway, no FD can
make sure that it is 100% correct. Other HW can normalize its
confidence level to 0~9 so that application can handle it easily, IMO.
1..100 might be better, to minimize rounding errors. Nevertheless IMO if we
can export an exact range supported by FD device we should do it, and let
upper layers do the normalization. And the bigger numbers should mean higher
confidence, consistently for all devices.
Do you think we could assume that the FD threshold range (FD_LHIT register
in case of OMAP4) is always same as the result confidence level ?
If so then the confidence level range could possibly be queried with the
detection threshold control. We could name it V4L2_CID_FD_CONFIDENCE_THRESHOLD
for example.
I could take care of preparing the control class draft and the documentation
for it.
+ * @reserved:future extensions
+ */
+struct v4l2_obj_detection {
How about changing name of this structure to v4l2_fd_primitive or v4l2_fd_shape
?
+ __u16 centerx;
+ __u16 centery;
+ __u16 angle;
+ __u16 sizex;
+ __u16 sizey;
How about using struct v4l2_rect in place of centerx/centery, sizex/sizey ?
After all it describes a rectangle. We could also use struct
v4l2_frmsize_discrete
for size but there seems to be missing en equivalent for position, e.g.
Maybe user space would like to plot a circle or ellipse over the detected
objection, and I am sure that I have seen this kind of plot over detected
face before.
OK, in any way I suggest to replace all __u16 with __u32, to minimize
performance
issues and be consistent with the data type specifying pixel values elsewhere in
V4L.
It makes sense to make 'confidence' __u32 as well and add a flags attribute to
indicate the shape.
+ __u16 confidence;
+ __u32 reserved[4];
And then
__u32 reserved[10];
or
__u32 reserved[2];
+};
+
+#define V4L2_FD_HAS_LEFT_EYE 0x1
+#define V4L2_FD_HAS_RIGHT_EYE0x2
+#define V4L2_FD_HAS_MOUTH0x4
+#define V4L2_FD_HAS_FACE 0x8
Do you think we could change it to:
#define V4L2_FD_FL_LEFT_EYE (1 0)
#define V4L2_FD_FL_RIGHT_EYE(1 1)
#define V4L2_FD_FL_MOUTH(1 2)
#define V4L2_FD_FL_FACE (1 3)
and add:
#define V4L2_FD_FL_SMILE(1 4)
#define V4L2_FD_FL_BLINK(1 5)
?
+
+/**
+ * struct v4l2_fd_detection - VIDIOC_G_FD_RESULT argument
+ * @flag:return, describe which objects are detected
+ * @left_eye:return, left_eye position if detected
+ * @right_eye: return, right_eye position if detected
+ * @mouth_eye: return, mouth_eye position if detected
mouth_eye ? ;)
Sorry, it should be mouth, :-)
:) also the word return could be omitted.
+ * @face:return, face position if detected
+ */
+struct v4l2_fd_detection {
How about changing the name to v4l2_fd_object ?
+ __u32 flag;
+ struct v4l2_obj_detection left_eye;
+ struct v4l2_obj_detection right_eye;
+ struct v4l2_obj_detection mouth;
+ struct v4l2_obj_detection face;
I would do this differently, i.e. put flag inside struct v4l2_obj_detection
and then struct v4l2_fd_detection would be simply an array of
struct v4l2_obj_detection, i.e.
struct v4l2_fd_detection {
unsigned int count;
struct v4l2_obj_detection [V4L2_MAX_FD_OBJECT_NUM];
};
This
Re: [RFC PATCH v1 6/7] media: video: introduce face detection driver module
On 12/07/2011 02:40 PM, Ming Lei wrote: I understand the API you mentioned here should belong to kernel internal API, correct me if it is wrong. Yes, I meant the in kernel design, i.e. generic face detection kernel module and an OMAP4 FDIF driver. It makes lots of sense to separate common code in this way, maybe even when there would be only OMAP devices using it. Yes, that is the motivation of the generic FD module. I think we can focus on two use cases for the generic FD now: - one is to detect faces from user space image data - another one is to detect faces in image data generated from HW(SoC internal bus, resize hardware) For OMAP4 hardware, input data is always from physically continuous memory directly, so it is very easy to support the two cases. For the use case 2, if buffer copy is to be avoided, we can use the coming shared dma-buf[1] to pass the image buffer produced by other HW to FD hw directly. Some H/W uses direct data buses to exchange data between processing blocks, and there is no need for additional memory. We only need to manage the data links, for which MC has been designed. For other FD hardware, if it supports to detect faces in image data from physically continuous memory, I think the patch is OK to support it. If the FD hw doesn't support to detect faces from physically continuous memory, I have some questions: how does user space app to parse the FD result if application can't get the input image data? If user space can Do we need the map of detected objects on a input image in all cases ? If an application needs only coordinates of detected object on a video signal to for example, focus on it, trigger some action, or just count detected faces, etc. Perhaps there are more practical similar use cases. get image data, how does it connect the image data with FD result? and If hardware provides frame sequence numbers the FD result can be associated with a frame, whether it's passing through H/W interconnect or is located in memory. what standard v4l2 ways(v4l2_buffer?) can the app use to describe the image data? We have USERPTR and MMAP memeory buffer for streaming IO, those use v4l2_buffer 1). read()/write() is also used 2), mostly for compressed formats. Except that there are works on shared buffers. I'm sure now the Samsung devices won't fit in video output node based driver design. They read image data in different ways and also the FD result format is totally different. I think user space will need the FD result, so it is very important to define API to describe the FD result format to user space. And the input about your FD HW result format is certainly helpful to define the API. I'll post exact attributes generated by our FD detection H/W soon. AFAICS OMAP4 FDIF processes only data stored in memory, thus it seems reasonable to use the videodev interface for passing data to the kernel from user space. But there might be face detection devices that accept data from other H/W modules, e.g. transferred through SoC internal data buses between image processing pipeline blocks. Thus any new interfaces need to be designed with such devices in mind. Also the face detection hardware block might now have an input DMA engine in it, the data could be fed from memory through some other subsystem (e.g. resize/colour converter). Then the driver for that subsystem would implement a video node. I think the direct input image or frame data to FD should be from memory no matter the actual data is from external H/W modules or input DMA because FD will take lot of time to detect faces in one image or frame and FD can't have so much memory to cache several images or frames data. Sorry, I cannot provide much details at the moment, but there exists hardware that reads data from internal SoC buses and even if it uses some sort of cache memory it doesn't necessarily have to be available for the user. Without some hardware background, it is not easy to give a generic FD module design. Yes, please give me some time so I can prepare the list of requirements. Still the FD result is associated with an image frame for such H/W, but not necessarily with a memory buffer queued by a user application. For user space application, it doesn't make sense to handle FD results only without image data. Even though there are other ways of input image data to FD, user space still need to know the image data, so it makes sense to associate FD result with a memory buffer. How long it approximately takes to process single image for OMAP4 FDIF ? See the link[2], and my test result is basically consistent with the data. Thanks. The processing time is rather low, looks like we could easily detect objects in each frame with 30..50 fps. If you have seen this kind of FD hardware design, please let me know. I'm for leaving the buffer handling details for individual drivers and focusing on a standard interface for
Re: HVR-930C DVB-T mode report
Hi Mauro... I applied your patch... the patch seems good using scan, but still some issue with w_scan: tune to: 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0d49: pmt_pid 0x0102 RAI -- Rai 1 (running) 0x 0x0d4a: pmt_pid 0x0101 RAI -- Rai 2 (running) 0x 0x0d4b: pmt_pid 0x0100 RAI -- Rai 3 TGR Veneto (running) 0x 0x0d53: pmt_pid 0x0118 RAI -- Rai News (running) 0x 0x0d54: pmt_pid 0x0119 Rai -- Rai 3 TGR Emilia Romagna (running) 0x 0x0d4c: pmt_pid 0x0103 Rai -- Rai Radio1 (running) 0x 0x0d4d: pmt_pid 0x0104 Rai -- Rai Radio2 (running) 0x 0x0d4e: pmt_pid 0x0105 Rai -- Rai Radio3 (running) Network Name 'Rai' tune to: 21250:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 0x 0x0001: pmt_pid 0x0023 TV7 -- TV7 MOVIE (running) 0x 0x0002: pmt_pid 0x002f TV7 -- TV7 DOC (running) 0x 0x0003: pmt_pid 0x002d TV7 -- TV7 SANITA (running) 0x 0x0004: pmt_pid 0x0026 TV7 -- TV7 ITALIA (running) 0x 0x0005: pmt_pid 0x0032 TV7 -- TV7 ATENEO (running) 0x 0x0006: pmt_pid 0x0022 TV7 -- TV7 SPORT (running) 0x 0x000b: pmt_pid 0x002b TV7 -- TV7 AZZURRA (running) Network Name 'Triveneta TV' using w_scan still persist issues. Here is the results: root@depieri1lnx:~# w_scan -f t -c IT w_scan version 20110616 (compiled for DVB API 5.3) using settings for ITALY DVB aerial DVB-T Europe frontend_type DVB-T, channellist 4 output format vdr-1.6 output charset 'UTF-8', use -C charset to override Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-C DRXK DVB-C: specified was DVB-T - SEARCH NEXT ONE. /dev/dvb/adapter0/frontend1 - DVB-T DRXK DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend1) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 5.4 frontend 'DRXK DVB-T' supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO FREQ (47.12MHz ... 865.00MHz) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Scanning 7MHz frequencies... 177500: (time: 00:00) 184500: (time: 00:03) 191500: (time: 00:06) 198500: (time: 00:09) 205500: (time: 00:12) 212500: (time: 00:15) 219500: (time: 00:17) 226500: (time: 00:20) Scanning 8MHz frequencies... 474000: (time: 00:23) [...] 85: (time: 02:38) 858000: (time: 02:40) ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!! dmesg says: [ 794.964818] drxk: Error -22 on QAMSetSymbolrate [ 794.964827] drxk: Error -22 on SetQAM [ 794.964832] drxk: Error -22 on Start [ 795.164518] drxk: Error -22 on QAMSetSymbolrate [ 795.164528] drxk: Error -22 on SetQAM [ 795.164534] drxk: Error -22 on Start -- 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 v1 5/7] media: v4l2: introduce two IOCTLs for face detection
Hi,
On Fri, Dec 9, 2011 at 6:27 AM, Sylwester Nawrocki snj...@gmail.com wrote:
On 12/08/2011 04:42 AM, Ming Lei wrote:
+/**
+ * struct v4l2_obj_detection
+ * @buf_index: entry, index of v4l2_buffer for face detection
I would prefer having the frame sequence number here. It will be more
future proof IMHO. If for instance we decide to use such an ioctl on
a v4l2 sub-device, without dequeuing buffers, there will be no problem
with that. And still in your specific use case it's not big deal to
look up the buffer index given it's sequence number in the application.
OK, take your suggestion to use frame index, but I still have question
about it, see my question in another thread.
+ * @centerx: return, position in x direction of detected object
+ * @centery: return, position in y direction of detected object
+ * @angle: return, angle of detected object
+ * 0 deg ~ 359 deg, vertical is 0 deg, clockwise
+ * @sizex: return, size in x direction of detected object
+ * @sizey: return, size in y direction of detected object
+ * @confidence: return, confidence level of detection result
+ * 0: the heighest level, 9: the lowest level
Hmm, not a good idea to align a public interface to the capabilities
of a single hardware implementation.
I think that the current omap interface is general enough, so why can't
we use it as public interface?
I meant exactly the line implying the range. What if for some hardware
it's 0..11 ?
We can let driver to normalize it to user which doesn't care if the range
is 0~11 or 10~21, a uniform range should always make user happy,
shouldn't it?
min/max confidence could be queried with
relevant controls and here we could remove the line implying range.
No, the confidence is used to describe the probability about
the correctness of the current detection result. Anyway, no FD can
make sure that it is 100% correct. Other HW can normalize its
confidence level to 0~9 so that application can handle it easily, IMO.
1..100 might be better, to minimize rounding errors. Nevertheless IMO if we
can export an exact range supported by FD device we should do it, and let
upper layers do the normalization. And the bigger numbers should mean higher
confidence, consistently for all devices.
Looks 1..100 is better, and I will change it to 1..100.
Do you think we could assume that the FD threshold range (FD_LHIT register
in case of OMAP4) is always same as the result confidence level ?
No, they are different. FD_LHIT is used to guild FD HW to detect more
faces but more false positives __or__ less faces but less false positives.
A control class is needed to be introduced for adjusting this value of FD
HW, and I think a normalized range is better too.
If so then the confidence level range could possibly be queried with the
detection threshold control. We could name it V4L2_CID_FD_CONFIDENCE_THRESHOLD
As I said above, there is no advantage to export the range to user, and a
uniform range will make user happy.
for example.
I could take care of preparing the control class draft and the documentation
for it.
It is great to hear it, :-)
+ * @reserved: future extensions
+ */
+struct v4l2_obj_detection {
How about changing name of this structure to v4l2_fd_primitive or
v4l2_fd_shape ?
I think v4l2_obj_detection is better because it can be reused to describe
some other kind of object detection from video in the future.
+ __u16 centerx;
+ __u16 centery;
+ __u16 angle;
+ __u16 sizex;
+ __u16 sizey;
How about using struct v4l2_rect in place of centerx/centery, sizex/sizey ?
After all it describes a rectangle. We could also use struct
v4l2_frmsize_discrete
for size but there seems to be missing en equivalent for position, e.g.
Maybe user space would like to plot a circle or ellipse over the detected
objection, and I am sure that I have seen this kind of plot over detected
face before.
OK, in any way I suggest to replace all __u16 with __u32, to minimize
performance
issues and be consistent with the data type specifying pixel values elsewhere
in
V4L.
OK, but may introduce more memory footprint for the fd result.
It makes sense to make 'confidence' __u32 as well and add a flags attribute to
indicate the shape.
Sounds good.
+ __u16 confidence;
+ __u32 reserved[4];
And then
__u32 reserved[10];
or
__u32 reserved[2];
+};
+
+#define V4L2_FD_HAS_LEFT_EYE 0x1
+#define V4L2_FD_HAS_RIGHT_EYE 0x2
+#define V4L2_FD_HAS_MOUTH 0x4
+#define V4L2_FD_HAS_FACE 0x8
Do you think we could change it to:
#define V4L2_FD_FL_LEFT_EYE (1 0)
#define V4L2_FD_FL_RIGHT_EYE (1 1)
#define V4L2_FD_FL_MOUTH (1 2)
#define V4L2_FD_FL_FACE (1 3)
OK
and add:
#define V4L2_FD_FL_SMILE (1 4)
#define
