RE: [PATCH 1/2] media: vb2: support userptr for PFN mappings.
Hello,
On Tuesday, January 03, 2012 8:48 AM javier Martin wrote:
On 2 January 2012 20:00, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Thanks for the patch.
On Monday 02 January 2012 15:12:22 Javier Martin wrote:
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
What's your main use case ? Capturing to the frame buffer ?
My main use case is capturing to my mx2_emmaprp mem2mem driver which
converts from YUV422 to YUV420 format in HW.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 66
+++--- 1 files changed, 42 insertions(+), 24
deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c index 03aa62f..5bc7cec 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -15,6 +15,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
+#include linux/io.h
Please keep headers sorted alphabetically.
OK. I didn't know that was the rule.
#include media/videobuf2-core.h
#include media/videobuf2-memops.h
@@ -71,6 +72,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ unsigned long int physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +83,34 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
-
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff)) {
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (vaddr -
vma-vm_start);
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
What if the region spans multiple VMAs ? Shouldn't you at least verify that
the region is physically contiguous, and that all VMAs share the same flags
?
That's what the OMAP3 ISP driver does (in ispqueue.c). Maybe it's overkill
though.
If you do that, the could might be cleaner if you split this function in
two,
as in the OMAP3 ISP driver.
Yes, I suspected this could probably be troublesome. I'll take a look
at OMAP3 ISP and see what I can do.
You can grab most of the required code for proper vma locking and contiguous pfn
extraction from videobuf2-dma_contig.c (vb2_dma_contig_get_userptr) and
videobuf2-memops.c (vb2_get_contig_userptr function), although the latter still
has some incomplete assumptions (it works correctly only with platforms where
dma address equals physical address in system memory - we will fix this soon).
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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] libv4l: add hflip quirk for dealextreme cam sku #44507
Hi,
Thanks for the patch.
I'm sorry, but a quick google shows that your cam has a usb id used by various
generic
cameras, including some microscopes, see:
http://blog.littleimpact.de/index.php/2011/10/16/using-biolux-nv-on-ubuntu-linux/
Enabling flipping on all these models because one has the sensor mounted upside
down
is the wrong thing to do.
Instead you could add the following to your /etc/profile
export LIBV4LCONTROL_FLAGS=3
Note this will flip the image from all cameras you plug into your computer, or
you
can keep a patched libv4l around for yourself.
Regards,
Hans
On 01/02/2012 09:25 PM, Vasily Khoruzhick wrote:
Signed-off-by: Vasily Khoruzhickanars...@gmail.com
---
lib/libv4lconvert/control/libv4lcontrol.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libv4lconvert/control/libv4lcontrol.c
b/lib/libv4lconvert/control/libv4lcontrol.c
index 12fa874..a9908ac 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -51,6 +51,8 @@ static const struct v4lcontrol_flags_info v4lcontrol_flags[]
= {
/* Genius E-M 112 (also want whitebalance by default) */
{ 0x093a, 0x2476, 0, NULL, NULL,
V4LCONTROL_HFLIPPED|V4LCONTROL_VFLIPPED | V4LCONTROL_WANTS_WB,
1500 },
+ /* uvc-compatible cam from dealextreme (sku #44507) */
+ { 0x18ec, 0x3366, 0, NULL, NULL, V4LCONTROL_HFLIPPED },
/* Laptops (and all in one PC's) */
{ 0x0402, 0x5606, 0,
--
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 v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
Added Mauro to CC. On 3 January 2012 08:43, javier Martin javier.mar...@vista-silicon.com wrote: On 2 January 2012 22:12, Sylwester Nawrocki snj...@gmail.com wrote: Hi Javier, On 01/02/2012 10:31 AM, javier Martin wrote: Hi, do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else? If you think your driver is good enough for merging, if you didn't do so already, you should normally send Mauro a git pull request. Please see: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request And here you can find some examples: http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=PULLarchive=both Do you mean I have to set up a public GIT repository? Is this mandatory? I am not a subsystem maintainer, just casual developer. What about this? http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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] s5p-mfc: Fix volatile controls setup
Hi Laurent,
Thanks for pointing this out, my comment is below.
Hans, I would be grateful if you could also read this and comment :)
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: 03 January 2012 02:14
Hi Kamil,
On Tuesday 27 December 2011 15:07:24 Kamil Debski wrote:
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c index 844a4d7..c25ec02 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
@@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
.maximum = 32,
.step = 1,
.default_value = 1,
- .flags = V4L2_CTRL_FLAG_VOLATILE,
+ .is_volatile = 1,
},
};
Why so ? is_volatile got removed in commit
88365105d683187e02a4f75220eaf51fd0c0b6e0.
Yep, this commit broke MFC, as after it has been applied volatile flag was not
set for any of the controls.
From 88365105d683187e02a4f75220eaf51fd0c0b6e0.
-- drivers/media/video/s5p-mfc/s5p_mfc_dec.c --
index 32f8989..bfbe084 100644
@@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
.maximum = 32,
.step = 1,
.default_value = 1,
- .is_volatile = 1,
+ .flags = V4L2_CTRL_FLAG_VOLATILE,
},
};
@@ -1020,7 +1020,7 @@ int s5p_mfc_dec_ctrls_setup(struct s5p_mfc_ctx *ctx)
return ctx-ctrl_handler.error;
}
if (controls[i].is_volatile ctx-ctrls[i])
- ctx-ctrls[i]-is_volatile = 1;
+ ctx-ctrls[i]-flags |= V4L2_CTRL_FLAG_VOLATILE;
}
return 0;
}
See? In the controls array the is_volatile field was no longer set, but it was
used
in the s5p_mfc_dec_ctrls_setup. Thus is was always 0.
The v4l2_ctrl_new_custom/v4l2_ctrl_new_std functions set the flags field
(which is done in v4l2_ctrl_fill).
It is also possible to |= the flag with the current contents of the field.
- if (controls[i].is_volatile ctx-ctrls[i])
+ if (ctx-ctrls[i])
- ctx-ctrls[i]-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ ctx-ctrls[i]-flags |= controls[i].flags;
This is possible, as it would set all the flags set in controls[] array.
Also checking for V4L2_CTRL_FLAG_VOLATILE in controls[x].flags and then setting
ctx-ctrls[i]-flags |= V4L2_CTRL_FLAG_VOLATILE is possible, but I think it is
not
necessary. The above solution should work fine as well.
The thing is that I did not notice Hans's commit and thought that it was my
mistake in MFC.
Thus I have fixed it in the simplest way. (It would be nice if I had been added
to CC of that patch)
Hans, if you could comment on which from the aforementioned solutions do you
find
the best?
The one from my commit, or the proposed above?
Also - maybe VOLATILE flag for V4L2_CID_MIN_BUFFERS_FOR_CAPTURE should be set in
v4l2_ctrl_fill?
Though I am not sure it would be the case for all devices.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Using OMAP3 ISP live display and snapshot sample applications
Hi Laurent, Happy New Year!! I saw that there is a simple viewfinder in your repo for OMAP3 and wish to know more about it. http://git.ideasonboard.org/?p=omap3-isp-live.git;a=summary I intend to test it with my 12-bit (Y12) monochrome camera sensor driver, running on top of Gumstix's (Steve v3.0) kernel. Is it workable at the moment? -- Regards, James -- 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 v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
On 01/03/2012 08:43 AM, javier Martin wrote: Do you mean I have to set up a public GIT repository? Is this mandatory? I am not a subsystem maintainer, just casual developer. It's not mandatory. But it helps Mauro to distinguish between RFC and patches for merging AFAIK. I think you can ask him to pickup patches from the mailing list directly. What about this? http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- 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] it913x ver 1.22 corrections to Tuner IDs
Correction to tuner ID 0x51.
Don't force tuner ID 0x60 unless eprom data zero.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c |5 +++--
drivers/media/dvb/frontends/it913x-fe.h |2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 4db9124..9addf6c 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -397,7 +397,8 @@ static int ite_firmware_select(struct usb_device *udev,
else if (le16_to_cpu(udev-descriptor.idProduct) ==
USB_PID_ITETECH_IT9135_9006) {
sw = IT9135_V2_FW;
- it913x_config.tuner_id_0 = 0x60;
+ if (it913x_config.tuner_id_0 == 0)
+ it913x_config.tuner_id_0 = IT9135_60;
} else
sw = IT9137_FW;
@@ -841,5 +842,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.21);
+MODULE_VERSION(1.22);
MODULE_LICENSE(GPL);
diff --git a/drivers/media/dvb/frontends/it913x-fe.h
b/drivers/media/dvb/frontends/it913x-fe.h
index 4143ef9..5ee3e2f 100644
--- a/drivers/media/dvb/frontends/it913x-fe.h
+++ b/drivers/media/dvb/frontends/it913x-fe.h
@@ -161,7 +161,7 @@ static inline struct dvb_frontend *it913x_fe_attach(
/* Build in tuner types */
#define IT9137 0x38
#define IT9135_38 0x38
-#define IT9135_51 0x50
+#define IT9135_51 0x51
#define IT9135_52 0x52
#define IT9135_60 0x60
#define IT9135_61 0x61
--
1.7.7.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] it913x-fe ver 1.13 add BER and UNC monitoring
Add BER monitoring with Pre-Viterbi error rate.
Add UCBLOCKS based on Aborted packets.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/it913x-fe.c | 21 +
drivers/media/dvb/frontends/it913x-fe.h | 10 ++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/it913x-fe.c
b/drivers/media/dvb/frontends/it913x-fe.c
index 8088e62..70131b9 100644
--- a/drivers/media/dvb/frontends/it913x-fe.c
+++ b/drivers/media/dvb/frontends/it913x-fe.c
@@ -66,6 +66,7 @@ struct it913x_fe_state {
u8 tun_fdiv;
u8 tun_clk_mode;
u32 tun_fn_min;
+ u32 ucblocks;
};
static int it913x_read_reg(struct it913x_fe_state *state,
@@ -553,14 +554,26 @@ static int it913x_fe_read_snr(struct dvb_frontend *fe,
u16 *snr)
static int it913x_fe_read_ber(struct dvb_frontend *fe, u32 *ber)
{
- *ber = 0;
+ struct it913x_fe_state *state = fe-demodulator_priv;
+ int ret;
+ u8 reg[5];
+ /* Read Aborted Packets and Pre-Viterbi error rate 5 bytes */
+ ret = it913x_read_reg(state, RSD_ABORT_PKT_LSB, reg, sizeof(reg));
+ state-ucblocks += (u32)(reg[1] 8) | reg[0];
+ *ber = (u32)(reg[4] 16) | (reg[3] 8) | reg[2];
return 0;
}
static int it913x_fe_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
{
- *ucblocks = 0;
- return 0;
+ struct it913x_fe_state *state = fe-demodulator_priv;
+ int ret;
+ u8 reg[2];
+ /* Aborted Packets */
+ ret = it913x_read_reg(state, RSD_ABORT_PKT_LSB, reg, sizeof(reg));
+ state-ucblocks += (u32)(reg[1] 8) | reg[0];
+ *ucblocks = state-ucblocks;
+ return ret;
}
static int it913x_fe_get_frontend(struct dvb_frontend *fe,
@@ -951,5 +964,5 @@ static struct dvb_frontend_ops it913x_fe_ofdm_ops = {
MODULE_DESCRIPTION(it913x Frontend and it9137 tuner);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
-MODULE_VERSION(1.12);
+MODULE_VERSION(1.13);
MODULE_LICENSE(GPL);
diff --git a/drivers/media/dvb/frontends/it913x-fe.h
b/drivers/media/dvb/frontends/it913x-fe.h
index 5ee3e2f..c4a908e 100644
--- a/drivers/media/dvb/frontends/it913x-fe.h
+++ b/drivers/media/dvb/frontends/it913x-fe.h
@@ -148,6 +148,16 @@ static inline struct dvb_frontend *it913x_fe_attach(
#define COEFF_1_2048 0x0001
#define XTAL_CLK 0x0025
#define BFS_FCW0x0029
+
+/* Error Regs */
+#define RSD_ABORT_PKT_LSB 0x0032
+#define RSD_ABORT_PKT_MSB 0x0033
+#define RSD_BIT_ERR_0_70x0034
+#define RSD_BIT_ERR_8_15 0x0035
+#define RSD_BIT_ERR_23_16 0x0036
+#define RSD_BIT_COUNT_LSB 0x0037
+#define RSD_BIT_COUNT_MSB 0x0038
+
#define TPSD_LOCK 0x003c
#define TRAINING_MODE 0x0040
#define ADC_X_20x0045
--
1.7.7.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: [GIT PULL] at91: devices and boards files update for 3.3
(added Mauro and linux-media to CC) On Tue, 3 Jan 2012, Nicolas Ferre wrote: On 12/20/2011 05:32 AM, Olof Johansson : On Sat, Dec 17, 2011 at 4:08 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: We can keep one late-merge branch in arm-soc that contain patches with external and possibly late dependencies and submit that branch last, but it would be good if we had a bit of margin to get it in. :) Ok, let's try this. Sounds good. Let us know when the stable branch is available. Nicolas, please prepare your branch as soon as possible once you have that info and send a pull request -- we still want the code into arm-soc branches very soon. Olof, Guennadi, I rebase today this branch on top of: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.3 I send another pull request real-soon-now... Will it be still possible to make it for 3.3 merge window? Looks like Mauro still hasn't pulled my branch in. I did ask him on IRC to do this and to push to Linus asap, but maybe he has missed that, I really should have mentioned that in the pull request. Mauro, could you, please, pull and include my branch in your first pull request for Linus for 3.3? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using OMAP3 ISP live display and snapshot sample applications
Hi James, On Tuesday 03 January 2012 10:40:10 James wrote: Hi Laurent, Happy New Year!! Thank you. Happy New Year to you as well. May 2012 bring you a workable OMAP3 ISP solution ;-) I saw that there is a simple viewfinder in your repo for OMAP3 and wish to know more about it. http://git.ideasonboard.org/?p=omap3-isp-live.git;a=summary I intend to test it with my 12-bit (Y12) monochrome camera sensor driver, running on top of Gumstix's (Steve v3.0) kernel. Is it workable at the moment? The application is usable but supports raw Bayer sensors only at the moment. It requires a frame buffer and an omap_vout device (both should be located automatically) and configures the OMAP3 ISP pipeline automatically to produce the display resolution. -- 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 1/2 v2] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v1:
- Use vb2_get_contig_userptr() which provides page
locking and contiguous memory check.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 74 +--
1 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..8248e56 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/io.h
#include linux/module.h
#include linux/mm.h
#include linux/sched.h
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,40 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ up_read(current-mm-mmap_sem);
+ if (vb2_get_contig_userptr(vaddr, size, res_vma, physp))
+ goto fail_pages_array_alloc;
+ buf-vma = res_vma;
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ up_read(current-mm-mmap_sem);
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+vaddr PAGE_MASK, buf-n_pages,
+write, 1, /* force */
+buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +142,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
+ iounmap(buf-vaddr);
}
-
RE: [PATCH 1/2 v2] media: vb2: support userptr for PFN mappings.
Hello,
On Tuesday, January 03, 2012 12:19 PM Javier Martin wrote:
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v1:
- Use vb2_get_contig_userptr() which provides page
locking and contiguous memory check.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 74
+--
1 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..8248e56 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/io.h
#include linux/module.h
#include linux/mm.h
#include linux/sched.h
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,40 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ down_read(current-mm-mmap_sem);
mm-mmap_sem is already grabbed by the videobuf2-core to avoid deadlocks. You
must not take it again here.
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ up_read(current-mm-mmap_sem);
+ if (vb2_get_contig_userptr(vaddr, size, res_vma, physp))
+ goto fail_pages_array_alloc;
+ buf-vma = res_vma;
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ up_read(current-mm-mmap_sem);
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+ GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+ vaddr PAGE_MASK, buf-n_pages,
+ write, 1, /* force */
+ buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +142,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+
Re: [PATCH] libv4l: add hflip quirk for dealextreme cam sku #44507
2012/1/3 Hans de Goede hdego...@redhat.com: Hi, Thanks for the patch. I'm sorry, but a quick google shows that your cam has a usb id used by various generic cameras, including some microscopes, see: http://blog.littleimpact.de/index.php/2011/10/16/using-biolux-nv-on-ubuntu-linux/ Enabling flipping on all these models because one has the sensor mounted upside down is the wrong thing to do. Instead you could add the following to your /etc/profile export LIBV4LCONTROL_FLAGS=3 Note this will flip the image from all cameras you plug into your computer, or you can keep a patched libv4l around for yourself. Thanks, I'm OK with it :) Regards, Hans -- 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 12/15] module_param: make bool parameters really bool (drivers misc)
diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c --- a/drivers/video/intelfb/intelfbdrv.c +++ b/drivers/video/intelfb/intelfbdrv.c @@ -230,16 +230,16 @@ MODULE_DESCRIPTION(Framebuffer driver f MODULE_LICENSE(Dual BSD/GPL); MODULE_DEVICE_TABLE(pci, intelfb_pci_table); -static int accel= 1; +static bool accel = 1; static int vram = 4; -static int hwcursor = 0; -static int mtrr = 1; -static int fixed= 0; -static int noinit = 0; -static int noregister = 0; -static int probeonly= 0; -static int idonly = 0; -static int bailearly= 0; +static bool hwcursor= 0; +static bool mtrr= 1; +static bool fixed = 0; +static bool noinit = 0; +static bool noregister = 0; +static bool probeonly = 0; +static bool idonly = 0; +static bool bailearly = 0; bailearly should be an int here. It's part of some ugly debug code where a value of 3 means bailout at point 3. Maybe we should just remove it instead... regards, dan carpenter signature.asc Description: Digital signature
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sylwester, On Monday 02 January 2012 21:55:31 Sylwester Nawrocki wrote: On 01/02/2012 12:16 PM, Laurent Pinchart wrote: * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be consistent with the other proposed controls ? Yes, you're right, I'll change them to make consistent with others. I've noticed that too, but a little bit too late:) * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY ... * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API Soudns good to me. parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. For the OMAP3 ISP we need multiple statistics windows. AEWB can use more than 32 windows. Having separate controls for that wouldn't be practical. OK, so the control API in current form doesn't seem capable of setting up the statistics windows. There is also little space in struct v4l2_ext_control for any major extensions. We might need to define dedicated set of selection targets in the selection API for handling multiple windows. Yet, to avoid forcing applications to use the selection API where rectangles aren't needed - only single spot coordinates, how about defining following two controls ? * AF spot coordinates when focus mode is set to V4L2_AUTO_FOCUS_MODE_SPOT - V4L2_CID_AUTO_FOCUS_POSITION_X - horizontal position in pixels relative to the left of frame - V4L2_CID_AUTO_FOCUS_POSITION_Y - vertical position in pixels relative to the top of frame What about a point control type instead ? :-) X and Y coordinates could be stored on 32 bits each. -- 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: MEM2MEM devices: how to handle sequence number?
Hi Javier, On Monday 02 January 2012 12:44:08 javier Martin wrote: Just one more question about this. The v4l2 encoder, which is the last element in my processing chain, is an H.264 encoder that has to know about previous frames to encode. For these kind of devices it is very useful to know whether a frame has been lost to introduce a skip frame and improve the encoding process. But, with the current approach we don't have any way to communicate this to the device. One option would be that the user specified a sequence number when issuing VIDIOC_QBUF at the output queue so that the device could detect any discontinuity and introduce a skip frame. But this would break your rule that sequence number introduced at the output queue has to be ignored by the driver. That's a use case I haven't thought about. Using sequence numbers could indeed help in that case. My concern is that most (if not all) applications don't set the sequence number before queuing a buffer, so requiring them to do so could introduce breakages. This could be limited to H.264 encoders (or more generally codecs) though. Another option would be to queue a 0-bytes frame. That might be a bit hackish though. -- 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] V4L: soc-camera: provide support for S_INPUT.
Guennadi,
probably you could answer me some question:
as we agreed I'm trying to implement ENUM_INPUT support to soc-camera
through pads. This means I must be able to pass the tvp5150 decoder
some platform_data in order to configure what inputs are really routed
in my board.
For that purpose I do the following in my board specific code:
static struct tvp5150_platform_data visstrim_tvp5150_data = {
.inputs = 55,
};
static struct i2c_board_info visstrim_i2c_camera = {
.type = tvp5150,
.addr = 0x5d,
.platform_data = visstrim_tvp5150_data,
};
static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0,/* Must match with the camera ID */
.board_info = visstrim_i2c_camera,
.i2c_adapter_id = 0,
.power = visstrim_camera_power,
.reset = visstrim_camera_reset,
};
static struct platform_device visstrim_tvp5150_soc = {
.name = soc-camera-pdrv,
.id = 0,
.dev= {
.platform_data = iclink_tvp5150,
},
};
However, it seems soc-camera ignores board_info.platform_data field
and assigns a value of its own:
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/soc_camera.c#L1006
How am I suppose to pass that information to the tvp5150 then?
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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] V4L: soc-camera: provide support for S_INPUT.
Hi Javier
On Tue, 3 Jan 2012, javier Martin wrote:
Guennadi,
probably you could answer me some question:
as we agreed I'm trying to implement ENUM_INPUT support to soc-camera
through pads.
No, you probably mean in the subdev driver, not in soc-camera core.
This means I must be able to pass the tvp5150 decoder
some platform_data in order to configure what inputs are really routed
in my board.
For that purpose I do the following in my board specific code:
static struct tvp5150_platform_data visstrim_tvp5150_data = {
.inputs = 55,
};
static struct i2c_board_info visstrim_i2c_camera = {
.type = tvp5150,
.addr = 0x5d,
.platform_data = visstrim_tvp5150_data,
};
static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0,/* Must match with the camera ID */
.board_info = visstrim_i2c_camera,
.i2c_adapter_id = 0,
.power = visstrim_camera_power,
.reset = visstrim_camera_reset,
};
static struct platform_device visstrim_tvp5150_soc = {
.name = soc-camera-pdrv,
.id = 0,
.dev= {
.platform_data = iclink_tvp5150,
},
};
However, it seems soc-camera ignores board_info.platform_data field
and assigns a value of its own:
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/soc_camera.c#L1006
How am I suppose to pass that information to the tvp5150 then?
Have a look at some examples, e.g., arch/sh/boards/mach-migor/setup.c:
static struct soc_camera_link ov7725_link = {
.power = ov7725_power,
.board_info = migor_i2c_camera[0],
.i2c_adapter_id = 0,
.priv = ov7725_info,
};
I.e., soc-camera expects you to use the struct soc_camera_link::priv field
for subdevice private platform data.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More adapters on v4l
Hello, I am trying to compile the v4l drivers, I make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb git clone git://linuxtv.org/media_build.git cd media_build ./build I got this message on the end: ** * Compilation finished. Use 'make install' to install them ** But before the make I want to add more adapters changing the v4l/scripts/make_kconfig.pl file to this: .config:CONFIG_DVB_MAX_ADAPTERS=16 When I execute the ./build it compile and I can not change the source. On the s2-liplianin branch I had no problem because I change it before the make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip s2-liplianin-0b7d3cc65161.zip cd s2-liplianin-0b7d3cc65161 ##change the adapter number### make make install Is possible to do the same with the v4l source? Thanks and best regards. -- Josu Lazkano -- 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: More adapters on v4l
Il 03/01/2012 17:09, Josu Lazkano ha scritto: Hello, I am trying to compile the v4l drivers, I make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb git clone git://linuxtv.org/media_build.git cd media_build ./build I got this message on the end: ** * Compilation finished. Use 'make install' to install them ** But before the make I want to add more adapters changing the v4l/scripts/make_kconfig.pl file to this: .config:CONFIG_DVB_MAX_ADAPTERS=16 When I execute the ./build it compile and I can not change the source. On the s2-liplianin branch I had no problem because I change it before the make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip s2-liplianin-0b7d3cc65161.zip cd s2-liplianin-0b7d3cc65161 ##change the adapter number### make make install Is possible to do the same with the v4l source? Thanks and best regards. Hi Josu, you can do this way: git clone git://linuxtv.org/media_build.git cd media_build ./build ## you can ctrl-C as soon as it starts compiling the drivers, or wait until the end ## make menuconfig ## change all the options you like and save ## cd linux make cd .. make install 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: multicast to analog EIA channel
Hello, I am new to the mailing list and wanted to pick some of your guys brains about something. I work for a small cable service provider. What I am trying to do is receive a multicast stream, modulate it and send it out as an EIA analog channel. I have everything in place but the hardware to do it. I know there is equipment built for this specific reason(RGP SEP, APEX1000, etc) but this is just going to be a temporary fix as we are doing a total video overhaul and moving to all MPEG4 capable equipment. I am a fairly experienced linux user and I figured there is a way to accomplish this with linux but all of my reasearch hasn't really helped so I'm reaching out to you. Has anyone ever done this? or know of any good reference sites for this? Any info would be greatly appreciated. Thanks again, Matt Bernardi -- 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] af9013: Fix typo in get_frontend() function
This patch fixes an obvious typo in the get_frontend() function
of the af9013 driver, recently rewritten by Antti Palosaari.
Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
drivers/media/dvb/frontends/af9013.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index e6ba3e0..2aedc0b 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -880,16 +880,16 @@ static int af9013_get_frontend(struct dvb_frontend
*fe)
switch ((buf[0] 2) 3) {
case 0:
- c-transmission_mode = GUARD_INTERVAL_1_32;
+ c-guard_interval = GUARD_INTERVAL_1_32;
break;
case 1:
- c-transmission_mode = GUARD_INTERVAL_1_16;
+ c-guard_interval = GUARD_INTERVAL_1_16;
break;
case 2:
- c-transmission_mode = GUARD_INTERVAL_1_8;
+ c-guard_interval = GUARD_INTERVAL_1_8;
break;
case 3:
- c-transmission_mode = GUARD_INTERVAL_1_4;
+ c-guard_interval = GUARD_INTERVAL_1_4;
break;
}
--
1.7.5.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: em28xx: new board id [eb1a:5051]
On Mon, 2012-01-02 at 21:32 -0800, Reuben Stokes wrote: On Monday 02 January 2012 13:04:01 Gareth Williams wrote: On Sun, 2012-01-01 at 20:40 -0800, okonomiyaki...@my180.net wrote: On Sat, 2011-12-31 at 17:01 -0800, Reuben Stokes wrote: On Saturday 31 December 2011 01:51:45 Gareth Williams wrote: On Fri, 2011-12-30 at 15:16 -0800, Reuben Stokes wrote: On Friday 30 December 2011 14:27:57 Gareth Williams wrote: On Fri, 2011-12-30 at 05:04 -0800, Reuben Stokes wrote: On Friday 30 December 2011 02:01:35 you wrote: On Thu, 2011-12-29 at 15:13 -0800, Reuben Stokes wrote: Hi, Not nearly as linux-savvy as most of the users here, but I attempted to operate a Raygo USB Video Recorder (audio/video capture device). Don't know if my efforts qualify as a test. Model Number: R12-41373 Display name: USB 2861 Device lsusb: Bus 001 Device 002: ID eb1a:5051 eMPIA Technology, Inc. dmesg: [ 7182.076058] usb 1-1: new high speed USB device using ehci_hcd and address 3 [ 7182.212702] usb 1-1: New USB device found, idVendor=eb1a, idProduct=5051 [ 7182.212714] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 7182.212723] usb 1-1: Product: USB 2861 Device [ 7182.212729] usb 1-1: SerialNumber: 0 System: HP Pavilion dv6910 laptop AMD Turion X2 CPU (64 bit) Mepis 11; 64 bit( based on Debian Squeeze) Tried --- * Installed em28xx drivers using instructions found at linuxtv.org. I note however that this particular vendor/product ID is not validated in the em28xx devices list. * As new drivers do not automatically load, I use command: modprobe em28xx After this modprobe -l | grep em28xx yields kernel/drivers/media/video/em28xx/em28xx-alsa.ko kernel/drivers/media/video/em28xx/em28xx.ko kernel/drivers/media/video/em28xx/em28xx-dvb.ko * Device comes with a driver CD for Windows which does work in Windows. End result is the device is not recognized as a capture device option in any software tried including vlc, cheese, guvcview, kdenlive. Any help getting this to work in Linux would be appreciated as it completely sucks in my bloated, memory-hogging, 32-bit Windows Vista. Reuben okonomiyaki...@gohighspeed.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 Reuben, If you're willing, then open up the device and see what the chips within are. You believe it's em28xx based, but there may well be additional devices in there for audio and video. Once you've found out what's inside it will be easier to get it working. It may be as simple as getting the driver to recognise the USB Vendor ID or it may require much more work. Regards, Gareth -- 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 Thank you very much for the response. Okay, opening it was easier than first suspected. The main (biggest) chip reads with nice big letters and a logo: eMPIA EM2860 P86J3-011 201047-01AG Less useful information inlcudes: A smaller chip on the flip side of the circuit board, in letters visible only through a magnifying glass, reads: eMPIA TECHNOLOGY EMP202 T10164 1052 The circuit board itself is stamped: PM22860-2GOB Again, thank you. Reuben Reuben, Was there another chip on there? The EMP202 is an audio chip that can covert analogue audio to digital PCM (and vice versa). The EM2860 sends this digital audio along with digital video over USB. For this to work though, the device will need to convert analogue video to digital and will need another chip to do this. An example would be a SAA7113 from Philips. Have another look and post back here. The two chips you've identified are commonly used in for this
Re: Working on Avermedia Duet A188 (saa716x and lgdt3304)
I'd like to try this again, as my last working tuner died this week. I've had this card sitting around for over a year hoping for support, but it doesn't look like anyone else is working on it. What kind of information is needed to make the card work? Will I need to find firmware somewhere? It looks like the basics are there with Manu's work on the SAA716x and Jared and Michael's work on the LGDT3304, but how do I customize these to work with the A188? Any help would be appreciated, thanks! Oblib I have been playing with this aswell.. I haven't done C since college. I hope someone could help us with this.. I have done some leg work here.. 1) I have contacted Avermedia to see if they will release the source to the windows drivers.. Can't hurt to ask.. waiting their response.. it had to be referred to RD department. So it Wasnt No.. 2) The actual components on the board are 2x TDA18271hdc2 in what appears to be a master slave setup(maybe.. Only one coax input) 2x LGDT3304 1x 60E 3) I have pulled this repository and worked from there.. http://linuxtv.org/hg/~endriss/mirror-saa716x/ I have edited the SAA71x budget Driver so that it recognizes the card and the cards rom tells us this.. [7.154089] SAA7160 ROM: Data=157 bytes [7.154090] SAA7160 ROM: Version=1 [7.154091] SAA7160 ROM: Devices=5 [7.154092] SAA7160 ROM: Compressed=0 [7.154092] [7.154388] SAA7160 ROM: = Device 0 = [7.154390]- [7.154400] 10 00 ff ff 02 00 01 00 60 71 00 ff 01 00 1a 00 [7.154406] ff 04 20 00 0c ff ff ff ff 00 00 00 00 00 00 00 [7.154412] 00 02 08 24 0f 00 00 82 00 00 00 [7.154416]- [7.154427] SAA7160 ROM: Device @ 0x7f [7.154428] SAA7160 ROM: Size=16 bytes [7.154429] SAA7160 ROM: Device ID=0x00 [7.154430] SAA7160 ROM: Master ID=0xff [7.154431] SAA7160 ROM: Bus ID=0xff [7.154432] SAA7160 ROM: Device type=0x10002 [7.154433] SAA7160 ROM: Implementation ID=0x7160 [7.154434] SAA7160 ROM: Path ID=0x00 [7.154435] SAA7160 ROM: GPIO ID=0xff [7.154436] SAA7160 ROM: Address=1 bytes [7.154437] SAA7160 ROM: Extended data=26 bytes [7.154438] [7.154439] SAA7160 ROM: Found GPIO device [7.154440]- [7.154449] 04 20 00 0c ff ff ff ff 00 00 00 00 00 00 00 00 [7.154455]- [7.154465] SAA7160 ROM: Size=4 bytes [7.154467] SAA7160 ROM: Pins=32 [7.154468] SAA7160 ROM: Ext data=12 [7.154468] [7.154470] SAA7160 ROM: Found streaming device [7.154471]- [7.154480] 02 08 24 0f 00 00 82 00 00 00 [7.154484]- [7.154494] SAA7160 ROM: Size=2 bytes [7.154495] SAA7160 ROM: Ext data=8 bytes [7.154496] [7.154497] SAA7160 ROM: = Device 1 = [7.154498]- [7.154508] 10 02 00 00 40 00 00 00 87 00 00 00 01 00 14 00 [7.154514] c0 02 12 01 ff 05 ff ff ff 05 ff ff ff ff ff ff [7.154519] ff 8e 06 ff ff [7.154522]- [7.154532] SAA7160 ROM: Device @ 0x60 [7.154533] SAA7160 ROM: Size=16 bytes [7.154534] SAA7160 ROM: Device ID=0x02 [7.154535] SAA7160 ROM: Master ID=0x00 [7.154536] SAA7160 ROM: Bus ID=0x00 [7.154537] SAA7160 ROM: Device type=0x40 [7.154538] SAA7160 ROM: Implementation ID=0x87 [7.154539] SAA7160 ROM: Path ID=0x00 [7.154540] SAA7160 ROM: GPIO ID=0x00 [7.154541] SAA7160 ROM: Address=1 bytes [7.154542] SAA7160 ROM: Extended data=20 bytes [7.154543] [7.154544] SAA7160 ROM: Found Tuner device [7.154545]- [7.154554] 02 12 01 ff 05 ff ff ff 05 ff ff ff ff ff ff ff [7.154560] 8e 06 ff ff [7.154562]- [7.154572] SAA7160 ROM: Size=2 bytes [7.154573] SAA7160 ROM: Ext data=18 bytes [7.154574] [7.154575] [7.154576] SAA7160 ROM: = Device 2 = [7.154577]- [7.154587] 10 03 00 00 00 01 00 00 87 00 00 00 01 00 03 00 [7.154592] 1c 03 08 00 [7.154594]- [7.154605] SAA7160 ROM: Device @ 0x0e [7.154606] SAA7160 ROM: Size=16 bytes [7.154607] SAA7160 ROM: Device ID=0x03 [7.154608]
[PATCH v2] 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 fixes 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, now the center frequency is the same for all firmwares (DTV7, DTV8, DTV78) and doesn't depend on channel 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; Signed-off-by: Gianluca Gennari gennar...@gmail.com --- drivers/media/common/tuners/tuner-xc2028.c | 26 -- 1 files changed, 16 insertions(+), 10 deletions(-) diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index bdcbfd7..2755599 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -962,14 +962,24 @@ 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 firmware DTV78 used to work fine in UHF band (8 MHz +* bandwidth) but not at all in VHF band (7 MHz bandwidth). +* The real problem was connected to the formula used to +* calculate the center frequency offset in VHF band. +* In fact, removing the 500KHz adjustment fixed the problem. +* This is coherent to what was implemented for the DTV7 +* firmware. +* In the end, now the center frequency is the same for all 3 +* firmwares (DTV7, DTV8, DTV78) and doesn't depend on channel +* bandwidth. +*/ + 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 +989,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.5.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: Working on Avermedia Duet A188 (saa716x and lgdt3304)
On Tue, Jan 3, 2012 at 1:05 PM, Tim richard...@hotmail.com wrote: Currently I I am trying to attach the lgdt3304 at i2c address 0x0e on bus A then try to attach the tda1827hdc2.. but the lgdt3304 never attaches Just a suggestion: These sorts of problems are usually either you're trying to talk to the device on the wrong i2c bus, or the chip is being held in reset by a GPIO. Also possible that it's bound to a different i2c address (most demods let you pick between a couple of addresses based on a pullup resistor on a particular pin. 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
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:Tue Jan 3 19:00:19 CET 2012 git hash:1e73fa5d56333230854ae9460579eb2fcee8af02 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: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS 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: ERRORS 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
sveon stv40 usb stick
Hello everybody! I recently bougth a Sveon STV40 usb stick to capture analogic video (http://www.sveon.com/fichaSTV40.html) I can use it in windows but my linux box (Fedora 16 - 3.1.6-1.fc16.x86_64 - gcc 4.6.2) can't recognize it. Is there any way I can fix this? These are the results of my investigation so far: 1) It is identified by lsusb as an Afatech board (1b80:e309) with an Empia 2861 chip (from dmesg and windows driver inf file) 2) I experimented with em28xx because the chipset was empia and with af9015 because I found that the stv22 was supported (http://linuxtv.org/wiki/index.php/Afatech_AF9015). In both cases after I manually added the vendor:id to /sys/bus/usb/drivers/ driver started but in the end I was not able to succeed. With em28xx I could go as far as having a /dev/video0 device but with no signal and the dmesg log said to ask here for help :) . With the af9015 I had an early stop. 3) Both the logs are attached. 4) I used the driver shipped with the fedora stock kernel because I can't compile the ones that I get from git://linuxtv.org/media_build.git. I have an error at: CC [M] media_build/v4l/as3645a.o media_build/v4l/as3645a.c: In function 'as3645a_probe': media_build/v4l/as3645a.c:815:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/as3645a.c:815:8: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors Thank you in advance for any help you might provide on this issue! ,Best regards Mario [12882.483471] Linux media interface: v0.10 [12882.484980] Linux video capture interface: v2.00 [12882.486187] usbcore: registered new interface driver em28xx [12882.486189] em28xx driver loaded [13002.169451] usb 1-5.3: new high speed USB device number 11 using ehci_hcd [13002.259795] usb 1-5.3: New USB device found, idVendor=1b80, idProduct=e309 [13002.259799] usb 1-5.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [13002.259803] usb 1-5.3: Product: USB 2861 Device (SVEON STV40) [13002.260702] em28xx: New device USB 2861 Device (SVEON STV40) @ 480 Mbps (1b80:e309, interface 0, class 0) [13002.260787] em28xx #0: chip ID is em2860 [13002.359275] em28xx #0: board has no eeprom [13002.431281] em28xx #0: preparing read at i2c address 0x60 failed (error=-19) [13007.073682] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [13007.073686] em28xx #0: You may try to use card=n insmod option to workaround that. [13007.073687] em28xx #0: Please send an email with this log to: [13007.073688] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [13007.073690] em28xx #0: Board eeprom hash is 0x [13007.073691] em28xx #0: Board i2c devicelist hash is 0x1b800080 [13007.073692] em28xx #0: Here is a list of valid choices for the card=n insmod option: [13007.073694] em28xx #0: card=0 - Unknown EM2800 video grabber [13007.073696] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [13007.073697] em28xx #0: card=2 - Terratec Cinergy 250 USB [13007.073699] em28xx #0: card=3 - Pinnacle PCTV USB 2 [13007.073700] em28xx #0: card=4 - Hauppauge WinTV USB 2 [13007.073701] em28xx #0: card=5 - MSI VOX USB 2.0 [13007.073702] em28xx #0: card=6 - Terratec Cinergy 200 USB [13007.073703] em28xx #0: card=7 - Leadtek Winfast USB II [13007.073705] em28xx #0: card=8 - Kworld USB2800 [13007.073706] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 [13007.073708] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [13007.073709] em28xx #0: card=11 - Terratec Hybrid XS [13007.073710] em28xx #0: card=12 - Kworld PVR TV 2800 RF [13007.073712] em28xx #0: card=13 - Terratec Prodigy XS [13007.073713] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [13007.073714] em28xx #0: card=15 - V-Gear PocketTV [13007.073716] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [13007.073717] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [13007.073718] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [13007.073720] em28xx #0: card=19 - EM2860/SAA711X Reference Design [13007.073721] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [13007.073722] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [13007.073724] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [13007.073725] em28xx #0: card=23 - Huaqi DLCW-130 [13007.073726] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner [13007.073727] em28xx #0: card=25 - Gadmei UTV310 [13007.073729] em28xx #0: card=26 - Hercules Smart TV USB 2.0 [13007.073730] em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) [13007.073731] em28xx #0: card=28 - Leadtek Winfast USB II Deluxe [13007.073733] em28xx #0: card=29 - EM2860/TVP5150 Reference Design [13007.073734] em28xx #0: card=30 - Videology 20K14XUSB
Re: [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
On Thu, Dec 15, 2011 at 07:50:30AM -0200, Mauro Carvalho Chehab wrote: On 15-12-2011 07:33, Hans Verkuil wrote: On Thursday, December 15, 2011 10:21:41 Mauro Carvalho Chehab wrote: On 15-12-2011 04:34, Dan Carpenter wrote: On a 32bit system the multiplication here could overflow. p-count is used in some of the V4L drivers. ULONG_MAX / sizeof(v4l2_ext_control) is too much. This ioctl is used on things like setting MPEG paramenters, where several parameters need adjustments at the same time. I risk to say that 64 is probably a reasonably safe upper limit. Let's make it 1024. That gives more than enough room for expansion without taking too much memory. Especially for video encoders a lot of controls are needed, and sensor drivers are also getting more complex, so 64 is a bit too low for my taste. I agree that limiting this to some sensible value is a good idea. I'm fine with 1024. Yet, this could easily be changed to whatever upper value needed, and still be backward compatible. Ok, can someone please send me the accepted version of this patch for inclusion in the 2.6.32-stable tree? thanks, greg k-h -- 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 v3 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:
Hi Konrad,
On Tue, Dec 20, 2011 at 10:06 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- different devices to 'attach' themselves to this buffer, to facilitate
backing storage negotiation, using dma_buf_attach() API.
Any thoughts of adding facility to track them? So you can see who is using
what?
Not for version 1, but it would be a useful addition once we start
using this mechanism.
OK. Looking forward to V2.
- association of a file pointer with each user-buffer and associated
allocator-defined operations on that buffer. This operation is called
the
'export' operation.
'create'? or 'alloc' ?
export implies an import somwhere and I don't think that is the case here.
I will rephrase it as suggested by Rob as well.
- this exported buffer-object to be shared with the other entity by asking
for
its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed
using
the associated exporter-defined operations.
- the exporter and user to share the scatterlist using map_dma_buf and
unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
for the whole memory region or just for the device itself?
Rob has very eloquently and kindly explained it in his reply.
Can you include his words of wisdom in the git description?
snip
+/*
+ * is_dma_buf_file - Check if struct file* is associated with dma_buf
+ */
+static inline int is_dma_buf_file(struct file *file)
+{
+ return file-f_op == dma_buf_fops;
+}
+
+/**
Wrong kerneldoc.
I looked into scripts/kernel-doc, and
Documentation/kernel-doc-na-HOWTO.txt = both these places mention
that the kernel-doc comments have to start with /**, and I couldn't
spot an error in what's wrong with my usage - would you please
elaborate on what you think is not right?
The issue I had was with '/**' but let me double-check where I learned
that /** was a bad. Either way, it is a style-guide thing and the
Documentation/* trumps what I recall.
snip
+/**
+ * struct dma_buf_attachment - holds device-buffer attachment data
OK, but what is the purpose of it?
I will add that in the comments.
+ * @dmabuf: buffer for this attachment.
+ * @dev: device attached to the buffer.
^^^ this
+ * @node: list_head to allow manipulation of list of dma_buf_attachment.
Just say: list of dma_buf_attachment'
ok.
+ * @priv: exporter-specific attachment data.
That exporter-specific.. brings to my mind custom decleration forms. But
maybe that is me.
:) well, in context of dma-buf 'exporter', it makes sense.
Or just private contents of the backend driver. But the naming is not that
important
to inhibit this patch from being merged.
+ */
+struct dma_buf_attachment {
+ struct dma_buf *dmabuf;
+ struct device *dev;
+ struct list_head node;
+ void *priv;
+};
Why don't you move the decleration of this below 'struct dma_buf'?
It would easier than to read this structure..
I could do that, but then anyways I will have to do a
forward-declaration of dma_buf_attachment, since I have to use it in
dma_buf_ops. If it improves readability, I am happy to move it below
struct dma_buf
It is more of just making the readability easier. As in reading from top bottom
one. But if it is too ugly, don't bother.
+
+/**
+ * struct dma_buf_ops - operations possible on struct dma_buf
+ * @attach: allows different devices to 'attach' themselves to the given
register?
+ * buffer. It might return -EBUSY to signal that backing storage
+ * is already allocated and incompatible with the requirements
Wait.. allocated or attached?
This and above comment on 'register' are already answered by Rob in
his explanation of the sequence in earlier reply. [the Documentation
patch [2/2] also tries to explain it]
OK. Might want to mention the user to look in the Documentation, in case you
don't
already have it.
+ * of requesting device. [optional]
What is optional? The return value? Or the 'attach' call? If the later , say
that in the first paragraph.
ok, sure. it is meant for the attach op.
+ * @detach: detach a given device from this buffer. [optional]
+ * @map_dma_buf: returns list of scatter pages allocated, increases
usecount
+ * of the buffer. Requires atleast one attach to be called
+ * before. Returned sg list should already be mapped into
+
Re: v4l: how to get blanking clock count?
I the case of your bridge, that may not be possible, but that's the only one I've heard of so I think it's definitely a special case. In that case the sensor driver can't be allowed to change the blanking periods while streaming is ongoing. I agree, it's just a matter of adding proper logic at the sensor driver. However it might be a bit tricky, the bridge would have to validate blanking values before actually enabling streaming. Yes, this value doesn't affect the result image. The hardware only raises a error interrupt to signify that a horizontal tracking overflow has occurred, that means the programmed number of samples did not match up with the actual number of samples counted between assertions of HSYNC(I can only set active samples now). -- 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: [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
Hello Mauro Carvalho Chehab, This is a semi-automatic email about new static checker warnings. The patch a7d44baaed0a: [media] cx23885-dvb: Remove a dirty hack that would require DVBv3 from Dec 26, 2011, leads to the following Smatch complaint: drivers/media/video/cx23885/cx23885-dvb.c +135 cx23885_dvb_gate_ctrl() error: we previously assumed 'fe' could be null (see line 128) drivers/media/video/cx23885/cx23885-dvb.c 127 128 if (fe fe-dvb.frontend fe-dvb.frontend-ops.i2c_gate_ctrl) ^^ Old condition. 129 fe-dvb.frontend-ops.i2c_gate_ctrl(fe-dvb.frontend, open); 130 131 /* 132 * FIXME: Improve this path to avoid calling the 133 * cx23885_dvb_set_frontend() every time it passes here. 134 */ 135 cx23885_dvb_set_frontend(fe-dvb.frontend); New dereference. 136 } 137 regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using OMAP3 ISP live display and snapshot sample applications
Hi Laurent, On Tue, Jan 3, 2012 at 7:17 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi James, On Tuesday 03 January 2012 10:40:10 James wrote: Hi Laurent, Happy New Year!! Thank you. Happy New Year to you as well. May 2012 bring you a workable OMAP3 ISP solution ;-) Yeah! that's on #1 of my 2012 wishlist!! (^^) But, it start off with a disappointment on the quest to get gst-launch v4l2src to work.. http://patches.openembedded.org/patch/8895/ Saw reported success in get v4l2src to work with MT9V032 by applying the hack but no luck with my Y12 monochrome sensor. (-.-) I saw that there is a simple viewfinder in your repo for OMAP3 and wish to know more about it. http://git.ideasonboard.org/?p=omap3-isp-live.git;a=summary I intend to test it with my 12-bit (Y12) monochrome camera sensor driver, running on top of Gumstix's (Steve v3.0) kernel. Is it workable at the moment? The application is usable but supports raw Bayer sensors only at the moment. It requires a frame buffer and an omap_vout device (both should be located automatically) and configures the OMAP3 ISP pipeline automatically to produce the display resolution. Will there be a need to patch for Y12 support or workable out-of-the-box? Likely your previous notes, I know that 12-bit Y12 to the screen is an overkill but will it be able to capture Y12 from CCDC output and then output to the screen? Y12 sensor- CCDC - CCDC output - screen I've one board connected to a LCD monitor via a DVI chip using GS's Tobi board as reference and another via 4.3 LG LCD Touchscreen using GS's Chestnut board as reference. Many thanks in adv -- Regards, James -- 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 v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver
remove unnecessary inclusion of machine specific header files mach/dm646x.h,
mach/hardware.h from vpif.h and aslo mach/dm646x.h from vpif_display.c
driver which comes in the way of platform code consolidation.
Add linux/i2c.h header file in vpif_types.h which is required for
building.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: LMML linux-media@vger.kernel.org
---
drivers/media/video/davinci/vpif.h |2 --
drivers/media/video/davinci/vpif_display.c |2 --
include/media/davinci/vpif_types.h |2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index 25036cb..8bcac65 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -18,8 +18,6 @@
#include linux/io.h
#include linux/videodev2.h
-#include mach/hardware.h
-#include mach/dm646x.h
#include media/davinci/vpif_types.h
/* Maximum channel allowed */
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 286f029..7fa34b4 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -39,8 +39,6 @@
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
-#include mach/dm646x.h
-
#include vpif_display.h
#include vpif.h
diff --git a/include/media/davinci/vpif_types.h
b/include/media/davinci/vpif_types.h
index 9929b05..bd8217c 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -17,6 +17,8 @@
#ifndef _VPIF_TYPES_H
#define _VPIF_TYPES_H
+#include linux/i2c.h
+
#define VPIF_CAPTURE_MAX_CHANNELS 2
enum vpif_if_type {
--
1.6.2.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
