The USB device VID in Linux is difference with in Windows
hi, guys, I have a Hauppauge product, but it can't support on Linux, and I'd like have a try to compose a new driver for it. the product details info: - name: Hauppauge DMB-T MiniStick(it only use on HongKong and China) - VID: 2040 - PID: 5020 ... I got the above info from Win 7, but when I hot plug it into Linux, it can't enable but with these info: $ dmesg ... ... [406600.393164] usb 1-8: new high speed USB device using ehci_hcd and address 13 [406600.507446] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 64 [406600.507454] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x1 has invalid maxpacket 64 [406600.507459] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x2 has invalid maxpacket 64 [406600.507464] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 [406600.507687] usb 1-8: New USB device found, idVendor=3344, idProduct=5020 [406600.507692] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=3 [406600.507695] usb 1-8: SerialNumber: 䥈児 yes, the idVendor is 3344, not 2040, but I'm sure it's 2040 in Windows, and the Hauppauge's vendor id is 2040, and it can't read out the SerialNumber. so I'm doubt the firmware in the product has some special data. I'm a newer to usb, can anyone know why? or what's the trouble with it? any comments are welcome. thanks, best Regards. Zhouping -- 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: Question about USB interface index restriction in gspca
On Mon, 19 Sep 2011 22:13:12 +0200 Frank Schäfer fschaefer@googlemail.com wrote: So, if your webcam is in the 99.99% which use the interface 0, use gspca_dev_probe(), otherwise, YOU know the right interface, so, call gspca_dev_probe2(). Isn't it also possible that we don't know the right interface and it is not interface 0 ? ;-) I hope that the interface does not change each time you unplug/replug the webcam :), but if different webcams with a same device ID may use different interfaces, you should have to develop specific code in the subdriver... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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/3] v4l: Extend V4L2_CID_COLORFX control with AQUA effect
Hi Laurent, On 09/21/2011 12:23 AM, Laurent Pinchart wrote: On Monday 19 September 2011 13:26:39 Sylwester Nawrocki wrote: On 09/19/2011 08:08 AM, Subash Patel wrote: Hi Laurent, I am not representing Sylwester :), But with a similar sensor I use, Aqua means cool tone which is Cb/Cr manipulations. On 09/19/2011 04:38 AM, Laurent Pinchart wrote: On Friday 16 September 2011 19:05:28 Sylwester Nawrocki wrote: Add V4L2_COLORFX_AQUA image effect in the V4L2_CID_COLORFX menu. What's the aqua effect ? Aqua means cool tone, as Subash explained. It's somehow opposite to Sepia which is warm tone. I'll improve the commit description in the next patch version. I tried to make a table with short description of each color effect in the DocBook but it was taking me too long so I dropped it for a moment. I have attached an image presenting the color effects. Maybe it's worth to add something like this to the DocBook, or perhaps just the descriptions. Thanks for the information. I think it would indeed be useful to add descriptions to the documentation. Sure, I'll try to find some time to complete this. And I wonder, what BLUE_SKY effect is ? I suspect it's very much same as the Aqua effect which is present in our sensor ISP. Does anyone know exactly ? Perhaps I could just use it instead of adding new menu entry. 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
RE: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:30 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for
buf_size allocation
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
prevent
requesting a larger size buffer than what is allocated at kernel boot
during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct
as
vout-buffer_size is later set to the size requested in reqbuf. When the
video
device is opened the next time, this check will prevent us to allocate a
buffer
which is larger than what we requested the last time.
Don't use vout-buffer_size, always check with the parameters
video1_bufsize
or video2_bufsize.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 95daf98..e14c82b 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
u32 phy_addr = 0, virt_addr = 0;
struct omap_vout_device *vout = q-priv_data;
struct omapvideo_info *ovid = vout-vid_info;
+ int vid_max_buf_size;
if (!vout)
return -EINVAL;
+ vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
+
if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
return -EINVAL;
@@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
video1_numbuffers : video2_numbuffers;
/* Check the size of the buffer */
- if (*size vout-buffer_size) {
+ if (*size vid_max_buf_size) {
Good catch !!!
v4l2_err(vout-vid_dev-v4l2_dev,
buffer allocation mismatch [%u] [%u]\n,
*size, vout-buffer_size);
@@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
unsigned long size = (vma-vm_end - vma-vm_start);
struct omap_vout_device *vout = file-private_data;
struct videobuf_queue *q = vout-vbq;
+ int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev,
%s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__,
@@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
return -EINVAL;
}
/* Check the size of the buffer */
- if (size vout-buffer_size) {
+ if (size vid_max_buf_size) {
Don't you think in case of mmap we should still check for the
vout-buffer_size, since this is the size user has requested in req_buf.
Thanks,
Vaibhav
v4l2_err(vout-vid_dev-v4l2_dev,
insufficient memory [%lu] [%u]\n,
size, vout-buffer_size);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
frame grabber INT-1461 under Linux
Hi, dmesg has asked me to mail you. Here's the essential part of the message: [1.806495] Linux video capture interface: v2.00 [1.806607] bttv: driver version 0.9.18 loaded [1.806613] bttv: using 8 buffers with 2080k (520 pages) each for capture [1.806669] bttv: Bt8xx card found (0). [1.806692] bttv :01:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [1.806710] bttv0: Bt878 (rev 17) at :01:01.0, irq: 17, latency: 64, mmio: 0xfdfff000 [1.806753] bttv0: subsystem: 1766: (UNKNOWN) [1.806758] please mail id, board name and the correct card= insmod option to linux-media@vger.kernel.org [1.806766] bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] [1.806839] bttv0: gpio: en=, out= in=00e31fff [init] [1.807003] bttv0: tuner absent [1.807086] bttv0: registered device video0 [1.807179] bttv0: registered device vbi0 [1.807204] bttv0: PLL: 28636363 = 35468950 .. ok [1.847974] bt878: AUDIO driver version 0.0.0 loaded I use bttv.card=77 kernel parameter. With no parameter, the frame grabber works, but in a strange way. Info about my frame grabber: INT-1461 PC/104-Plus Frame Grabber w/ 4 CVBS Inputs 24 DIO The INT-1461 video frame grabber is a low-cost, high-performance solution for capturing analog broadcast signals across the PCI bus. Based around the Conexant FusionTM 878A video decoder, this compact PC/104-Plus form factor board supports NTSC, PAL, and SECAM video formats at capture resolutions of up to 768 x 576 pixels and 30 frames per second. It can also sub-sample, scale, crop, and clip images at various resolutions and frame rates. You can easily find more info on the net. Thank you for writing and supporting media drivers. Regards, -- .. Pavel Andris | tel: +421 2 5941 1167 Institute of Informatics | fax: +421 2 5477 3271 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: utrra...@savba.sk SK - 845 07 Bratislava | Slovak republic| .. One hundred thousand lemmings cannot be wrong. Graffiti .. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code
from omap_vout_isr
Currently, there is a lot of redundant code is between DPI and VENC panels,
this
can be made common by moving out field/interlace specific code to a
separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 172 -
-
1 files changed, 82 insertions(+), 90 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index e14c82b..c5f2ea0 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct
omap_vout_device *vout)
return 0;
}
+static int omapvid_handle_interlace_display(struct omap_vout_device *vout,
+ unsigned int irqstatus, struct timeval timevalue)
+{
+ u32 fid;
+
+ if (vout-first_int) {
+ vout-first_int = 0;
+ goto err;
+ }
+
+ if (irqstatus DISPC_IRQ_EVSYNC_ODD)
+ fid = 1;
+ else if (irqstatus DISPC_IRQ_EVSYNC_EVEN)
+ fid = 0;
+ else
+ goto err;
+
+ vout-field_id ^= 1;
+ if (fid != vout-field_id) {
+ /* reset field ID */
+ vout-field_id = 0;
[Hiremath, Vaibhav] You should check whether fid == 0 before resetting it.
+ } else if (0 == fid) {
[Hiremath, Vaibhav] This is not matching with the original code, probably I
have to be more careful here. I need to spend more time here...
+ if (vout-cur_frm == vout-next_frm)
+ goto err;
+
+ vout-cur_frm-ts = timevalue;
+ vout-cur_frm-state = VIDEOBUF_DONE;
+ wake_up_interruptible(vout-cur_frm-done);
+ vout-cur_frm = vout-next_frm;
+ } else {
+ if (list_empty(vout-dma_queue) ||
+ (vout-cur_frm != vout-next_frm))
+ goto err;
+ }
+
+ return vout-field_id;
+err:
+ return 0;
+}
+
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret;
- u32 addr, fid;
+ int ret, fid;
+ u32 addr;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
- if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
- switch (cur_display-type) {
- case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
- goto vout_isr_err;
- break;
- case OMAP_DISPLAY_TYPE_HDMI:
- if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
- goto vout_isr_err;
- break;
- default:
+ switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DPI:
+ if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
goto vout_isr_err;
- }
- if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
- vout-cur_frm-ts = timevalue;
- vout-cur_frm-state = VIDEOBUF_DONE;
- wake_up_interruptible(vout-cur_frm-done);
- vout-cur_frm = vout-next_frm;
- }
- vout-first_int = 0;
- if (list_empty(vout-dma_queue))
+ break;
+ case OMAP_DISPLAY_TYPE_VENC:
+ fid = omapvid_handle_interlace_display(vout, irqstatus,
+ timevalue);
+ if (!fid)
goto vout_isr_err;
[Hiremath, Vaibhav]
Have you tested TV out functionality?
+ break;
+ case OMAP_DISPLAY_TYPE_HDMI:
+ if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
+ goto vout_isr_err;
+ break;
+ default:
+ goto vout_isr_err;
+ }
- vout-next_frm = list_entry(vout-dma_queue.next,
- struct videobuf_buffer, queue);
- list_del(vout-next_frm-queue);
-
- vout-next_frm-state = VIDEOBUF_ACTIVE;
-
- addr = (unsigned long) vout-queued_buf_addr[vout-next_frm-
i]
- + vout-cropped_offset;
+ if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
+ vout-cur_frm-ts = timevalue;
+ vout-cur_frm-state = VIDEOBUF_DONE;
Re: [PATCH v1 3/3] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sakari,
On 09/21/2011 12:10 AM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 01:58:59PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects. horizontal/vertical image flip, frame interval.
Thanks for the patch, Sylwester!
[clip]
+v4l2_ctrl_new_std_menu(hdl, ops, V4L2_CID_POWER_LINE_FREQUENCY,
+ V4L2_CID_POWER_LINE_FREQUENCY_AUTO, 0,
+ V4L2_CID_POWER_LINE_FREQUENCY_50HZ);
+
+v4l2_ctrl_new_std_menu(hdl, ops, V4L2_CID_COLORFX,
+ V4L2_COLORFX_SKETCH, 0x3D0, V4L2_COLORFX_NONE);
New items may be added to standard menus so you should mask out also
undefined bits. Say, ~0x42f (hope I got that right).
Sure, that's an important detail. ~0x42 look like the right value. Thanks for
pointing this out.
Youd also don't need to check for invalid menu ids; the control framework
does this for you.
Right, good catch. I'll modify accordingly.
+v4l2_ctrl_new_std(hdl, ops, V4L2_CID_WHITE_BALANCE_TEMPERATURE,
+ 0, 256, 1, 0);
+
+v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SATURATION, -127, 127, 1, 0);
+v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SHARPNESS, -127, 127, 1, 0);
+v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -127, 127, 1, 0);
+v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -127, 127, 1, 0);
+
+s5k6aa-sd.ctrl_handler = hdl;
Shoudln't this assignment be done after checking for the error?
Indeed, seems much more appropriate.
+if (hdl-error) {
+ret = hdl-error;
+v4l2_ctrl_handler_free(hdl);
+}
+return ret;
--
Thanks!
Sylwester
--
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
Re: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
Hi,
On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code
from omap_vout_isr
Currently, there is a lot of redundant code is between DPI and VENC panels,
this
can be made common by moving out field/interlace specific code to a
separate
function called omapvid_handle_interlace_display(). There is no functional
change made.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 172 -
-
1 files changed, 82 insertions(+), 90 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index e14c82b..c5f2ea0 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct
omap_vout_device *vout)
return 0;
}
+static int omapvid_handle_interlace_display(struct omap_vout_device *vout,
+ unsigned int irqstatus, struct timeval timevalue)
+{
+ u32 fid;
+
+ if (vout-first_int) {
+ vout-first_int = 0;
+ goto err;
+ }
+
+ if (irqstatus DISPC_IRQ_EVSYNC_ODD)
+ fid = 1;
+ else if (irqstatus DISPC_IRQ_EVSYNC_EVEN)
+ fid = 0;
+ else
+ goto err;
+
+ vout-field_id ^= 1;
+ if (fid != vout-field_id) {
+ /* reset field ID */
+ vout-field_id = 0;
[Hiremath, Vaibhav] You should check whether fid == 0 before resetting it.
+ } else if (0 == fid) {
[Hiremath, Vaibhav] This is not matching with the original code, probably I
have to be more careful here. I need to spend more time here...
If you do a dry run of it you'll see that it does the same thing
functionally. If fid was 1, vout-field_id would have been 0 anyway.
So the check for fid == 0 looked a bit redundant to me. However, if you
think that doing this makes the code less clear, we can surely keep this
check.
+ if (vout-cur_frm == vout-next_frm)
+ goto err;
+
+ vout-cur_frm-ts = timevalue;
+ vout-cur_frm-state = VIDEOBUF_DONE;
+ wake_up_interruptible(vout-cur_frm-done);
+ vout-cur_frm = vout-next_frm;
+ } else {
+ if (list_empty(vout-dma_queue) ||
+ (vout-cur_frm != vout-next_frm))
+ goto err;
+ }
+
+ return vout-field_id;
+err:
+ return 0;
+}
+
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret;
- u32 addr, fid;
+ int ret, fid;
+ u32 addr;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
- if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
- switch (cur_display-type) {
- case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
- goto vout_isr_err;
- break;
- case OMAP_DISPLAY_TYPE_HDMI:
- if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
- goto vout_isr_err;
- break;
- default:
+ switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DPI:
+ if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
goto vout_isr_err;
- }
- if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
- vout-cur_frm-ts = timevalue;
- vout-cur_frm-state = VIDEOBUF_DONE;
- wake_up_interruptible(vout-cur_frm-done);
- vout-cur_frm = vout-next_frm;
- }
- vout-first_int = 0;
- if (list_empty(vout-dma_queue))
+ break;
+ case OMAP_DISPLAY_TYPE_VENC:
+ fid = omapvid_handle_interlace_display(vout, irqstatus,
+ timevalue);
+ if (!fid)
goto vout_isr_err;
[Hiremath, Vaibhav]
Have you tested TV out functionality?
I haven't checked it yet to be totally honest. Its hard to find a VENC
TV! I wanted to anyway get some kind of Ack from you before starting to
test this. Since you also feel that this clean up is needed, I'll start
testing this out :)
+ break;
+ case OMAP_DISPLAY_TYPE_HDMI:
+ if (!(irqstatus
Re: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation
Hi,
On Wednesday 21 September 2011 02:10 PM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:30 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for
buf_size allocation
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
prevent
requesting a larger size buffer than what is allocated at kernel boot
during
omap_vout_probe.
The requested size is compared with vout-buffer_size, this isn't correct
as
vout-buffer_size is later set to the size requested in reqbuf. When the
video
device is opened the next time, this check will prevent us to allocate a
buffer
which is larger than what we requested the last time.
Don't use vout-buffer_size, always check with the parameters
video1_bufsize
or video2_bufsize.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 95daf98..e14c82b 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
u32 phy_addr = 0, virt_addr = 0;
struct omap_vout_device *vout = q-priv_data;
struct omapvideo_info *ovid =vout-vid_info;
+ int vid_max_buf_size;
if (!vout)
return -EINVAL;
+ vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
+
if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
return -EINVAL;
@@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
video1_numbuffers : video2_numbuffers;
/* Check the size of the buffer */
- if (*size vout-buffer_size) {
+ if (*size vid_max_buf_size) {
Good catch !!!
v4l2_err(vout-vid_dev-v4l2_dev,
buffer allocation mismatch [%u] [%u]\n,
*size, vout-buffer_size);
@@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
unsigned long size = (vma-vm_end - vma-vm_start);
struct omap_vout_device *vout = file-private_data;
struct videobuf_queue *q =vout-vbq;
+ int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+ video2_bufsize;
v4l2_dbg(1, debug,vout-vid_dev-v4l2_dev,
%s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__,
@@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
return -EINVAL;
}
/* Check the size of the buffer */
- if (size vout-buffer_size) {
+ if (size vid_max_buf_size) {
Don't you think in case of mmap we should still check for the
vout-buffer_size, since this is the size user has requested in req_buf.
Ah, you are right, the check for the maximum size should only be in the
reqbuf path. vout-buffer_size would have been updated correctly at time
of mmap. I'll change this back to vout-buffer_size.
Thanks,
Archit
Thanks,
Vaibhav
v4l2_err(vout-vid_dev-v4l2_dev,
insufficient memory [%lu] [%u]\n,
size, vout-buffer_size);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cx231xx: DMA problem on ARM
Hello,
On an x86 platform, we have managed to use a Hauppauge USB Live 2
capture device with the cx231xx on a 3.0 kernel with the patch at [1].
Things work nicely.
However, using a similar 3.0 kernel with the exact same device on an
ARM platform (BeagleBoard-XM), starting a V4L application to capture
the video immediately triggers the following BUG_ON in
arch/arm/mm/dma-mapping.c:
429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size,
430 enum dma_data_direction dir)
431 {
432 unsigned long paddr;
433
434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size -
1));
This problem looks similar to the problem fixed on the gspca driver by:
commit 882787ff8fdeb0be790547ee9b22b281095e95da
Author: Jason Wang jason77.w...@gmail.com
Date: Fri Sep 3 06:57:19 2010 -0300
V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch
When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: Jason Wang jason77.w...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
Cc: sta...@kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
I guess the cx231xx driver is trying to DMA-map buffers whose location
is not appropriate for DMA-mapping, because they are already in an DMA
coherent region. Is the fix just to add the same
URB_NO_TRANSFER_DMA_MAP to the urb-transfer_flags ? Or is it something
completely different ?
Thanks!
Thomas
[1]
https://github.com/torvalds/linux/commit/992299e84a4891275ea5924e30b66ce39a701e5e#drivers/media/video/cx231xx
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx: DMA problem on ARM
On Wed, Sep 21, 2011 at 7:56 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Hello,
On an x86 platform, we have managed to use a Hauppauge USB Live 2
capture device with the cx231xx on a 3.0 kernel with the patch at [1].
Things work nicely.
However, using a similar 3.0 kernel with the exact same device on an
ARM platform (BeagleBoard-XM), starting a V4L application to capture
the video immediately triggers the following BUG_ON in
arch/arm/mm/dma-mapping.c:
429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size,
430 enum dma_data_direction dir)
431 {
432 unsigned long paddr;
433
434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size -
1));
This problem looks similar to the problem fixed on the gspca driver by:
commit 882787ff8fdeb0be790547ee9b22b281095e95da
Author: Jason Wang jason77.w...@gmail.com
Date: Fri Sep 3 06:57:19 2010 -0300
V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch
When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: Jason Wang jason77.w...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
Cc: sta...@kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
I guess the cx231xx driver is trying to DMA-map buffers whose location
is not appropriate for DMA-mapping, because they are already in an DMA
coherent region. Is the fix just to add the same
URB_NO_TRANSFER_DMA_MAP to the urb-transfer_flags ? Or is it something
completely different ?
Hi Thomas,
I ran into the same issue on em28xx in the past (which is what those
parts of cx231xx are based on). Yes, just adding
URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please
try that out, and assuming it works feel free to submit a patch which
can be included upstream.
Regards,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] v4l2: add vb2_get_unmapped_area in vb2 core
Hello,
On Friday, September 09, 2011 12:12 AM Scott Jiang wrote:
no mmu system needs get_unmapped_area file operations to do mmap
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
The patch looks fine, I will add it to my videobuf2 fixes branch. Thanks for
your
contribution!
---
drivers/media/video/videobuf2-core.c | 31 +++
include/media/videobuf2-core.h |7 +++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 3015e60..02a0ec6 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1344,6 +1344,37 @@ int vb2_mmap(struct vb2_queue *q, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL_GPL(vb2_mmap);
+#ifndef CONFIG_MMU
+unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
+ unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags)
+{
+ unsigned long off = pgoff PAGE_SHIFT;
+ struct vb2_buffer *vb;
+ unsigned int buffer, plane;
+ int ret;
+
+ if (q-memory != V4L2_MEMORY_MMAP) {
+ dprintk(1, Queue is not currently set up for mmap\n);
+ return -EINVAL;
+ }
+
+ /*
+ * Find the plane corresponding to the offset passed by userspace.
+ */
+ ret = __find_plane_by_offset(q, off, buffer, plane);
+ if (ret)
+ return ret;
+
+ vb = q-bufs[buffer];
+
+ return (unsigned long)vb2_plane_vaddr(vb, plane);
+}
+EXPORT_SYMBOL_GPL(vb2_get_unmapped_area);
+#endif
+
static int __vb2_init_fileio(struct vb2_queue *q, int read);
static int __vb2_cleanup_fileio(struct vb2_queue *q);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f87472a..5c7b5b4 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -302,6 +302,13 @@ int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type
type);
int vb2_streamoff(struct vb2_queue *q, enum v4l2_buf_type type);
int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma);
+#ifndef CONFIG_MMU
+unsigned long vb2_get_unmapped_area(struct vb2_queue *q,
+ unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags);
+#endif
unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table
*wait);
size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count,
loff_t *ppos, int nonblock);
--
1.7.0.4
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 v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
Hi Sakari,
On 09/21/2011 12:17 AM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote:
On 09/20/2011 10:57 PM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote:
V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple and thus. Currently in the menu we have entries for
50 and 60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h|1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 2420e4a..c6b3c46 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -232,8 +232,9 @@ control is deprecated. New drivers and applications
should use the
entryEnables a power line frequency filter to avoid
flicker. Possible values forconstantenum
v4l2_power_line_frequency/constant are:
constantV4L2_CID_POWER_LINE_FREQUENCY_DISABLED/constant (0),
-constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1) and
-constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2)./entry
+constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1),
+constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2) and
+constantV4L2_CID_POWER_LINE_FREQUENCY_AUTO/constant (3)./entry
A stupid question: wouldn't this be a case for a new control for automatic
power line frequency, in other words enabling or disabling it?
IMO this would complicate things in kernel and user land, without any
reasonable
positive effects. AUTO seems to fit well here, it's just another mode of
operation
of a power line noise filter. Why make things more complicated than they
need to be ?
The advantage would be to be able to get the power line frquency if that's
supported by the hardware. This implementation excludes that. Such
information might be interesting to add e.g. to the image's exif data.
AFAIU, the power line frequency filter just modifies frame exposure time to be
multiple of half of the mains frequency period. So it's the exposure time that
gets
finally affected. Maybe there is some hardware that supports retrieving of the
detected
frequency, however I'm not aware of it. And it doesn't seem useful unless you
want
to use camera as some non-standard measurement tool. It also takes some time
until
the detection algorithm locks, during this time an undefined frequency value
would
be read.
I believe the filter settings do not really apply to still capture as it
involves
periodic operation, like preview. Even if we had this as meta data tag, there
are
more direct raw image parameters than the PL noise filter frequency.
I feel uncomfortable with having 2 controls, where one can disable the filter
and
the other enable it with AUTO setting.
Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ,
60HZ, AUTO.
(there is already one sensor driver in mainline that support it - ov519).
How do we map this onto 2 controls ?
What do we return from the menu control that covers { OFF, 50HZ, 60HZ } when
AUTO
mode is enabled through the other control and H/W doesn't allow to read the
detected
frequency ?
I think, for the 2 controls we would need the DISABLED entry not to belong to
V4L2_CID_POWER_LINE_FREQUENCY at first place.
Not sure if that's important, though.
I would say no, but someone can prove me wrong. And who knows what kind of
strange
H/W future brings.
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
Re: [PATCH v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
Hi Sylwester,
On Wednesday 21 September 2011 14:28:25 Sylwester Nawrocki wrote:
On 09/21/2011 12:17 AM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote:
On 09/20/2011 10:57 PM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote:
V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple and thus. Currently in the menu we have entries for
50 and 60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h|1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml index 2420e4a..c6b3c46
100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -232,8 +232,9 @@ control is deprecated. New drivers and
applications should use the
entryEnables a power line frequency filter to avoid
flicker. Possible values forconstantenum
v4l2_power_line_frequency/constant are:
constantV4L2_CID_POWER_LINE_FREQUENCY_DISABLED/constant (0),
-constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1) and
-constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2)./entry
+constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1),
+constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2) and
+constantV4L2_CID_POWER_LINE_FREQUENCY_AUTO/constant (3)./entry
A stupid question: wouldn't this be a case for a new control for
automatic power line frequency, in other words enabling or disabling
it?
IMO this would complicate things in kernel and user land, without any
reasonable positive effects. AUTO seems to fit well here, it's just
another mode of operation of a power line noise filter. Why make things
more complicated than they need to be ?
The advantage would be to be able to get the power line frquency if
that's supported by the hardware. This implementation excludes that.
Such information might be interesting to add e.g. to the image's exif
data.
AFAIU, the power line frequency filter just modifies frame exposure time to
be multiple of half of the mains frequency period. So it's the exposure
time that gets finally affected. Maybe there is some hardware that
supports retrieving of the detected frequency, however I'm not aware of
it. And it doesn't seem useful unless you want to use camera as some
non-standard measurement tool. It also takes some time until the detection
algorithm locks, during this time an undefined frequency value would be
read.
I believe the filter settings do not really apply to still capture as it
involves periodic operation, like preview. Even if we had this as meta
data tag, there are more direct raw image parameters than the PL noise
filter frequency.
I feel uncomfortable with having 2 controls, where one can disable the
filter and the other enable it with AUTO setting.
Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ,
60HZ, AUTO. (there is already one sensor driver in mainline that support
it - ov519). How do we map this onto 2 controls ?
What do we return from the menu control that covers { OFF, 50HZ, 60HZ }
when AUTO mode is enabled through the other control and H/W doesn't allow
to read the detected frequency ?
I think, for the 2 controls we would need the DISABLED entry not to belong
to V4L2_CID_POWER_LINE_FREQUENCY at first place.
Not sure if that's important, though.
I would say no, but someone can prove me wrong. And who knows what kind of
strange H/W future brings.
I think it all boils down to whether V4L2_CID_POWER_LINE_FREQUENCY is the
power line frequency filter control or the power line frequency control. In
the first case it doesn't make sense to use two separate controls. In the
second case it could.
I don't think we need two controls for this, but that's just a personal
opinion of the I don't think we need to bother type :-)
--
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 2/8] mm: alloc_contig_freed_pages() added
On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen d...@linux.vnet.ibm.com
wrote:
On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned
long end,
+ gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ zone = page_zone(pfn_to_page(start));
This implies that start-end are entirely contained in a single zone.
What enforces that?
In case of CMA, the __cma_activate_area() function from 6/8 has the check:
151 VM_BUG_ON(!pfn_valid(pfn));
152 VM_BUG_ON(page_zone(pfn_to_page(pfn)) !=
zone);
This guarantees that CMA will never try to call alloc_contig_freed_pages()
on a region that spans multiple regions.
If some higher layer enforces that, I think we probably need at least
a VM_BUG_ON() in here and a comment about who enforces it.
Agreed.
+ spin_lock_irq(zone-lock);
+
+ page = pfn_to_page(pfn);
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ list_del(page-lru);
+ order = page_order(page);
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+ pfn += 1 order;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+ page += 1 order;
+ }
This 'struct page *'++ stuff is OK, but only for small, aligned areas.
For at least some of the sparsemem modes (non-VMEMMAP), you could walk
off of the end of the section_mem_map[] when you cross a MAX_ORDER
boundary. I'd feel a little bit more comfortable if pfn_to_page() was
being done each time, or only occasionally when you cross a section
boundary.
I'm fine with that. I've used pointer arithmetic for performance reasons
but if that may potentially lead to bugs then obviously pfn_to_page()
should
be used.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
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 for v3.2] [media] saa7164: Adding support for HVR2200 card id 0x8953
Em 17-09-2011 18:35, Steven Toth escreveu: Hi Mauro, Please pull 92aa36f8f9d19b7c47ad3daca15aa0932254246b from git://git.kernellabs.com/stoth/saa7164-dev.git I need to know from what branch I need to pull. As this is auto-generated when a git request-pull is used, I suspect that you're preparing the pull request by hand or by some script you wrote. The better way is to just run: git request-pull $ORIGIN $URL where $ORIGIN is the reference branch/object for the pull (for example, remotes/media/staging/v3.2) and $URL is the http/git/ssh URL for your tree. This time, I've verified it manually, but please use git request-pull next time, as it makes my life easier, and will allow patchwork to get your pull request. Another SAA7164 HVR220 card profile. http://git.kernellabs.com/?p=stoth/saa7164-dev.git;a=commit;h=92aa36f8f9d19b7c47ad3daca15aa0932254246b Applied, thanks! drivers/media/video/saa7164/saa7164-cards.c | 62 +++ drivers/media/video/saa7164/saa7164-dvb.c |1 + drivers/media/video/saa7164/saa7164.h |1 + Thanks, Thanks, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] v4l2: Add the polarity flags for parallel camera bus FIELD signal
Hi Laurent, On 09/21/2011 01:12 AM, Laurent Pinchart wrote: Hi Sylwester, Thanks for the patch. On Monday 19 September 2011 19:07:55 Sylwester Nawrocki wrote: FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 standard. Add corresponding flag for configuring the FIELD signal polarity. Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the hardware that uses [HV]REF signals. I like this approach better. ... +/* Field selection signal for interlaced scan mode */ +#define V4L2_MBUS_FIELD_ACTIVE_HIGH (1 10) +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 11) What does this mean ? The FIELD signal is used to select between odd and even fields. Does active high mean that the field is odd or even when the signal has a high level ? The comment should make it explicit, or we could even rename those two constants to FIELD_ODD_HIGH/FIELD_ODD_LOW (or FIELD_EVEN_HIGH/FIELD_EVEN_LOW). Yes, certainly I didn't think enough about this. I silently assumed that for V4L2_MBUS_FIELD_ACTIVE_HIGH FIELD = 0 selects Field1 (odd) and FIELD = 1 selects Field2 (even). I think it would be good to construct the macro so it is possibly self-explanatory, rather than requiring often to dig in the documentation. So I would go for V4L2_MBUS_FIELD_ODD_LOW/V4L2_MBUS_FIELD_ODD_HIGH. Unless someone proposes something different/better I'll send an amended version tomorrow. Thanks, -- 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
RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 3:31 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
omap_vout_isr
Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.
On OMAP4, because we have 2 LCD managers, the panel type itself is not
sufficient to tell if we have received the correct irq, i.e, we shouldn't
proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2
interrupt for LCD manager.
Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager
to VSYNC2 interrupt.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index c5f2ea0..20638c3 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -566,8 +566,8 @@ err:
static void omap_vout_isr(void *arg, unsigned int irqstatus)
{
- int ret, fid;
- u32 addr;
+ int ret, fid, mgr_id;
+ u32 addr, irq;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
if (!ovl-manager || !ovl-manager-device)
return;
+ mgr_id = ovl-manager-id;
cur_display = ovl-manager-device;
spin_lock(vout-vbq_lock);
@@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int
irqstatus)
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
- if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+ if (mgr_id == OMAP_DSS_CHANNEL_LCD)
+ irq = DISPC_IRQ_VSYNC;
+ else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
+ irq = DISPC_IRQ_VSYNC2;
+ else
+ goto vout_isr_err;
+
+ if (!(irqstatus irq))
goto vout_isr_err;
break;
I understand what this patch meant for, but I am more curious to know
What is value addition of this patch?
if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
Vs
if (mgr_id == OMAP_DSS_CHANNEL_LCD)
irq = DISPC_IRQ_VSYNC;
else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
irq = DISPC_IRQ_VSYNC2;
Isn't this same, because we are not doing anything separate and special
for VSYNC and VSYNC2?
Thanks,
Vaibhav
case OMAP_DISPLAY_TYPE_VENC:
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/8] ARM: integrate CMA with DMA-mapping subsystem
Hello, On Thursday, September 08, 2011 7:27 PM Mike Frysinger wrote: On Fri, Aug 19, 2011 at 10:27, Marek Szyprowski wrote: arch/arm/include/asm/device.h |3 + arch/arm/include/asm/dma-contiguous.h | 33 +++ seems like these would be good asm-generic/ additions rather than arm Only some of them can be really moved to asm-generic imho. The following lines are definitely architecture specific: void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size); Some other archs might define empty fixup function. Right now only ARM architecture is the real client of the CMA. IMHO if any other arch stats using CMA, some of the CMA definitions can be then moved to asm-generic. Right now I wanted to keep it as simple as possible. 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 v3 1/3] noon010pc30: Conversion to the media controller API
Hi Laurent,
thanks for the review.
On 09/21/2011 12:18 AM, Laurent Pinchart wrote:
Hi Sylwester,
Thanks for the patch.
On Friday 16 September 2011 17:59:54 Sylwester Nawrocki wrote:
Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations.
Add media entity initialization and set subdev flags so the host driver
creates a subdev device node for the driver.
A mutex was added for serializing the subdev operations. When setting
format is attempted during streaming an (EBUSY) error will be returned.
After the device is powered up it will now remain in power sleep
mode until s_stream(1) is called. The power sleep mode is used
to suspend/resume frame generation at the sensor's output through
s_stream op.
While at here simplify the colorspace parameter handling.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[snip]
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c index 35f722a..115d976 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
[snip]
@@ -599,6 +641,22 @@ static int noon010_log_status(struct v4l2_subdev *sd)
return 0;
}
+static int noon010_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+struct v4l2_mbus_framefmt *mf = v4l2_subdev_get_try_format(fh, 0);
+struct noon010_info *info = to_noon010(sd);
+
+mutex_lock(info-lock);
+noon010_get_current_fmt(to_noon010(sd), mf);
Should you initialize mf with a constant default format instead of retrieving
the current format from the sensor ? A non-constant default would probably
confuse userspace application.
Sure, I could change to it. But I don't quite see the problem, the applications
should call set_fmt(TRY) anyway, rather than relying on the format gotten right
after opening the device, shouldn't they ? Anyway I guess it's better to have
all drivers behaving consistently.
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
Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote: This 'struct page *'++ stuff is OK, but only for small, aligned areas. For at least some of the sparsemem modes (non-VMEMMAP), you could walk off of the end of the section_mem_map[] when you cross a MAX_ORDER boundary. I'd feel a little bit more comfortable if pfn_to_page() was being done each time, or only occasionally when you cross a section boundary. I'm fine with that. I've used pointer arithmetic for performance reasons but if that may potentially lead to bugs then obviously pfn_to_page() should be used pfn_to_page() on x86 these days is usually: #define __pfn_to_page(pfn) (vmemmap + (pfn)) Even for the non-vmemmap sparsemem it stays pretty quick because the section array is in cache as you run through the loop. There are ways to _minimize_ the number of pfn_to_page() calls by checking when you cross a section boundary, or even at a MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble. -- Dave -- 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 v4] noon010pc30: Conversion to the media controller API
Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations.
Add media entity initialization and set subdev flags so the host driver
creates a subdev device node for the driver.
A mutex was added for serializing the subdev operations. When setting
format is attempted during streaming an (EBUSY) error will be returned.
After the device is powered up it will now remain in power sleep
mode until s_stream(1) is called. The power sleep mode is used
to suspend/resume frame generation at the sensor's output through
s_stream op.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Addresing Laurent's comments, changes since v3:
- set constant default TRY format in subdev open() internal op
rather than the currently set format
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/noon010pc30.c | 221 +---
2 files changed, 154 insertions(+), 69 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6279663..75bb46f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -755,7 +755,7 @@ config VIDEO_VIA_CAMERA
config VIDEO_NOON010PC30
tristate NOON010PC30 CIF camera sensor support
- depends on I2C VIDEO_V4L2
+ depends on I2C VIDEO_V4L2 EXPERIMENTAL VIDEO_V4L2_SUBDEV_API
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 35f722a..1a874ec 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -1,7 +1,7 @@
/*
* Driver for SiliconFile NOON010PC30 CIF (1/11) Image Sensor with ISP
*
- * Copyright (C) 2010 Samsung Electronics
+ * Copyright (C) 2010 - 2011 Samsung Electronics Co., Ltd.
* Contact: Sylwester Nawrocki, s.nawro...@samsung.com
*
* Initial register configuration based on a driver authored by
@@ -10,7 +10,7 @@
* 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 vergsion.
+ * (at your option) any later version.
*/
#include linux/delay.h
@@ -131,17 +131,24 @@ static const char * const noon010_supply_name[] = {
struct noon010_info {
struct v4l2_subdev sd;
+ struct media_pad pad;
struct v4l2_ctrl_handler hdl;
const struct noon010pc30_platform_data *pdata;
+ struct regulator_bulk_data supply[NOON010_NUM_SUPPLIES];
+ u32 gpio_nreset;
+ u32 gpio_nstby;
+
+ /* Protects the struct members below */
+ struct mutex lock;
+
const struct noon010_format *curr_fmt;
const struct noon010_frmsize *curr_win;
+ unsigned int apply_new_cfg:1;
+ unsigned int streaming:1;
unsigned int hflip:1;
unsigned int vflip:1;
unsigned int power:1;
u8 i2c_reg_page;
- struct regulator_bulk_data supply[NOON010_NUM_SUPPLIES];
- u32 gpio_nreset;
- u32 gpio_nstby;
};
struct i2c_regval {
@@ -313,6 +320,7 @@ static int noon010_enable_autowhitebalance(struct
v4l2_subdev *sd, int on)
return ret;
}
+/* Called with struct noon010_info.lock mutex held */
static int noon010_set_flip(struct v4l2_subdev *sd, int hflip, int vflip)
{
struct noon010_info *info = to_noon010(sd);
@@ -340,21 +348,18 @@ static int noon010_set_flip(struct v4l2_subdev *sd, int
hflip, int vflip)
static int noon010_set_params(struct v4l2_subdev *sd)
{
struct noon010_info *info = to_noon010(sd);
- int ret;
- if (!info-curr_win)
- return -EINVAL;
-
- ret = cam_i2c_write(sd, VDO_CTL_REG(0), info-curr_win-vid_ctl1);
-
- if (!ret info-curr_fmt)
- ret = cam_i2c_write(sd, ISP_CTL_REG(0),
- info-curr_fmt-ispctl1_reg);
- return ret;
+ int ret = cam_i2c_write(sd, VDO_CTL_REG(0),
+ info-curr_win-vid_ctl1);
+ if (ret)
+ return ret;
+ return cam_i2c_write(sd, ISP_CTL_REG(0),
+info-curr_fmt-ispctl1_reg);
}
/* Find nearest matching image pixel size. */
-static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf)
+static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf,
+ const struct noon010_frmsize **size)
{
unsigned int min_err = ~0;
int i = ARRAY_SIZE(noon010_sizes);
@@ -374,11 +379,14 @@ static int noon010_try_frame_size(struct
v4l2_mbus_framefmt *mf)
if (match) {
mf-width = match-width;
mf-height = match-height;
+ if (size)
+ *size = match;
return 0;
}
return -EINVAL;
}
+/* Called with info.lock
Re: [PATCH v4] noon010pc30: Conversion to the media controller API
Hi Sylwester, Thanks for the patch. On Wednesday 21 September 2011 16:26:00 Sylwester Nawrocki wrote: Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations. Add media entity initialization and set subdev flags so the host driver creates a subdev device node for the driver. A mutex was added for serializing the subdev operations. When setting format is attempted during streaming an (EBUSY) error will be returned. After the device is powered up it will now remain in power sleep mode until s_stream(1) is called. The power sleep mode is used to suspend/resume frame generation at the sensor's output through s_stream op. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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: Oops in 2.6.37-rc{3,4,5}
Em 12-12-2010 09:15, Chris Clayton escreveu: On Sunday 12 December 2010, Dave Young wrote: On Fri, Dec 10, 2010 at 10:34:06PM +, Chris Clayton wrote: I'm not subscribed, so please cc me on any reply. With rc kernels from 2.6.37, X frequently (approx 3 boots out of every 4) fails to start. dmesg shows the oops below. I can bisect over the weekend - probably Sunday - if no answer comes up in the meantime. I get the same oops with rc3, rc and rc5. rc2 doesn't get as far as trying to start X. Happy to test patches or provide additional diagnostics, but I'll be off line soon until 20:00 or so UK time tomorrow. snip [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [c13229ef] __mutex_lock_slowpath+0x9f/0x170 *pdpt = 34676001 *pde = Oops: 0002 [#1] PREEMPT SMP last sysfs file: /sys/module/drm_kms_helper/initstate Modules linked in: i915 drm_kms_helper drm fb fbdev cfbcopyarea video backlight output cfbimgblt cfbfillrect xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 saa7134_alsa tda10048 saa7134_dvb videobuf_dvb dvb_core mt20xx tea5767 tda9887 msp3400 gspca_zc3xx gspca_main tda18271 tda8290 ir_lirc_codec tuner lirc_dev bttv i2c_algo_bit btcx_risc snd_bt87x ir_common uhci_hcd ir_core saa7134 v4l2_common videodev v4l1_compat ehci_hcd videobuf_dma_sg videobuf_core tveeprom evdev [last unloaded: floppy] Pid: 1725, comm: X Not tainted 2.6.37-rc5+ #476 EG41MF-US2H/EG41MF-US2H EIP: 0060:[c13229ef] EFLAGS: 00013246 CPU: 3 EIP is at __mutex_lock_slowpath+0x9f/0x170 EAX: EBX: f4403410 ECX: f4403420 EDX: f4641dd8 ESI: f4403414 EDI: EBP: f4403418 ESP: f4641dd4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process X (pid: 1725, ti=f464 task=f3c67390 task.ti=f464) Stack: f3c67390 f4403418 f46a3800 f4403410 f4fd14f0 f425f600 f4403400 c13228a6 f4fd1000 f4fd14f0 f8841b6c c10aabb2 0514 f4c34000 f4df72c0 c10aabf7 f4403410 0001 f425f600 ffed f425f604 f46bfe40 Call Trace: [c13228a6] ? mutex_lock+0x16/0x30 [f8841b6c] ? bttv_open+0xac/0x280 [bttv] [c10aabb2] ? cdev_get+0x52/0x90 [c10aabf7] ? exact_lock+0x7/0x10 [f87095a7] ? v4l2_open+0xb7/0xd0 [videodev] [c10ab2ea] ? chrdev_open+0xda/0x1b0 [c10a5f25] ? __dentry_open+0xd5/0x280 [c10a7068] ? nameidata_to_filp+0x68/0x70 [c10ab210] ? chrdev_open+0x0/0x1b0 [c10b351f] ? do_last.clone.32+0x34f/0x5a0 [c10b3af3] ? do_filp_open+0x383/0x550 [c10b1e58] ? getname+0x28/0xf0 [c10a70c8] ? do_sys_open+0x58/0x110 [c10a5d09] ? filp_close+0x49/0x70 [c10a71ac] ? sys_open+0x2c/0x40 [c1002d10] ? sysenter_do_call+0x12/0x26 [c132] ? timer_cpu_notify+0x1b4/0x233 Code: 83 78 18 63 7f b6 8d b6 00 00 00 00 8d 73 04 8d 6b 08 89 f0 e8 f3 10 00 00 8b 43 0c 8d 54 24 04 89 44 24 08 89 53 0c 89 6c 24 04 89 10 8b 04 24 ba ff ff ff ff 89 44 24 0c 89 d0 87 03 83 f8 01 EIP: [c13229ef] __mutex_lock_slowpath+0x9f/0x170 SS:ESP 0068:f4641dd4 CR2: ---[ end trace 5ac4e44ad0dc7959 ]--- snip Could you try following patch? --- linux-2.6.orig/drivers/media/video/bt8xx/bttv-driver.c 2010-11-27 11:21:30.0 +0800 +++ linux-2.6/drivers/media/video/bt8xx/bttv-driver.c2010-12-12 16:31:39.63338 +0800 @@ -3291,6 +3291,8 @@ static int bttv_open(struct file *file) fh = kmalloc(sizeof(*fh), GFP_KERNEL); if (unlikely(!fh)) return -ENOMEM; + +mutex_init(fh-cap.vb_lock); file-private_data = fh; /* Yes Dave, that's fixed it thanks. Six successful boots, which never happened without the patch. Tested-by: Chris Clayton chris2...@googlemail.com It seems we missed this patch. It looks right on my eyes, so I'm applying it. Thanks, 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: Oops in 2.6.37-rc{3,4,5}
Em 21-09-2011 11:45, Mauro Carvalho Chehab escreveu: Em 12-12-2010 09:15, Chris Clayton escreveu: On Sunday 12 December 2010, Dave Young wrote: On Fri, Dec 10, 2010 at 10:34:06PM +, Chris Clayton wrote: I'm not subscribed, so please cc me on any reply. With rc kernels from 2.6.37, X frequently (approx 3 boots out of every 4) fails to start. dmesg shows the oops below. I can bisect over the weekend - probably Sunday - if no answer comes up in the meantime. I get the same oops with rc3, rc and rc5. rc2 doesn't get as far as trying to start X. Happy to test patches or provide additional diagnostics, but I'll be off line soon until 20:00 or so UK time tomorrow. snip [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [c13229ef] __mutex_lock_slowpath+0x9f/0x170 *pdpt = 34676001 *pde = Oops: 0002 [#1] PREEMPT SMP last sysfs file: /sys/module/drm_kms_helper/initstate Modules linked in: i915 drm_kms_helper drm fb fbdev cfbcopyarea video backlight output cfbimgblt cfbfillrect xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 saa7134_alsa tda10048 saa7134_dvb videobuf_dvb dvb_core mt20xx tea5767 tda9887 msp3400 gspca_zc3xx gspca_main tda18271 tda8290 ir_lirc_codec tuner lirc_dev bttv i2c_algo_bit btcx_risc snd_bt87x ir_common uhci_hcd ir_core saa7134 v4l2_common videodev v4l1_compat ehci_hcd videobuf_dma_sg videobuf_core tveeprom evdev [last unloaded: floppy] Pid: 1725, comm: X Not tainted 2.6.37-rc5+ #476 EG41MF-US2H/EG41MF-US2H EIP: 0060:[c13229ef] EFLAGS: 00013246 CPU: 3 EIP is at __mutex_lock_slowpath+0x9f/0x170 EAX: EBX: f4403410 ECX: f4403420 EDX: f4641dd8 ESI: f4403414 EDI: EBP: f4403418 ESP: f4641dd4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process X (pid: 1725, ti=f464 task=f3c67390 task.ti=f464) Stack: f3c67390 f4403418 f46a3800 f4403410 f4fd14f0 f425f600 f4403400 c13228a6 f4fd1000 f4fd14f0 f8841b6c c10aabb2 0514 f4c34000 f4df72c0 c10aabf7 f4403410 0001 f425f600 ffed f425f604 f46bfe40 Call Trace: [c13228a6] ? mutex_lock+0x16/0x30 [f8841b6c] ? bttv_open+0xac/0x280 [bttv] [c10aabb2] ? cdev_get+0x52/0x90 [c10aabf7] ? exact_lock+0x7/0x10 [f87095a7] ? v4l2_open+0xb7/0xd0 [videodev] [c10ab2ea] ? chrdev_open+0xda/0x1b0 [c10a5f25] ? __dentry_open+0xd5/0x280 [c10a7068] ? nameidata_to_filp+0x68/0x70 [c10ab210] ? chrdev_open+0x0/0x1b0 [c10b351f] ? do_last.clone.32+0x34f/0x5a0 [c10b3af3] ? do_filp_open+0x383/0x550 [c10b1e58] ? getname+0x28/0xf0 [c10a70c8] ? do_sys_open+0x58/0x110 [c10a5d09] ? filp_close+0x49/0x70 [c10a71ac] ? sys_open+0x2c/0x40 [c1002d10] ? sysenter_do_call+0x12/0x26 [c132] ? timer_cpu_notify+0x1b4/0x233 Code: 83 78 18 63 7f b6 8d b6 00 00 00 00 8d 73 04 8d 6b 08 89 f0 e8 f3 10 00 00 8b 43 0c 8d 54 24 04 89 44 24 08 89 53 0c 89 6c 24 04 89 10 8b 04 24 ba ff ff ff ff 89 44 24 0c 89 d0 87 03 83 f8 01 EIP: [c13229ef] __mutex_lock_slowpath+0x9f/0x170 SS:ESP 0068:f4641dd4 CR2: ---[ end trace 5ac4e44ad0dc7959 ]--- snip Could you try following patch? --- linux-2.6.orig/drivers/media/video/bt8xx/bttv-driver.c 2010-11-27 11:21:30.0 +0800 +++ linux-2.6/drivers/media/video/bt8xx/bttv-driver.c 2010-12-12 16:31:39.63338 +0800 @@ -3291,6 +3291,8 @@ static int bttv_open(struct file *file) fh = kmalloc(sizeof(*fh), GFP_KERNEL); if (unlikely(!fh)) return -ENOMEM; + + mutex_init(fh-cap.vb_lock); file-private_data = fh; /* Yes Dave, that's fixed it thanks. Six successful boots, which never happened without the patch. Tested-by: Chris Clayton chris2...@googlemail.com It seems we missed this patch. It looks right on my eyes, so I'm applying it. My mistake. This patch were superseded by some changes at vb_lock. Thanks, 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 -- 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] v4l2: Add the polarity flags for parallel camera bus FIELD signal
On 09/21/2011 03:24 PM, Sylwester Nawrocki wrote: Hi Laurent, On 09/21/2011 01:12 AM, Laurent Pinchart wrote: Hi Sylwester, Thanks for the patch. On Monday 19 September 2011 19:07:55 Sylwester Nawrocki wrote: FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 standard. Add corresponding flag for configuring the FIELD signal polarity. Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the hardware that uses [HV]REF signals. I like this approach better. ... +/* Field selection signal for interlaced scan mode */ +#define V4L2_MBUS_FIELD_ACTIVE_HIGH(1 10) +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 11) What does this mean ? The FIELD signal is used to select between odd and even fields. Does active high mean that the field is odd or even when the signal has a high level ? The comment should make it explicit, or we could even rename those two constants to FIELD_ODD_HIGH/FIELD_ODD_LOW (or FIELD_EVEN_HIGH/FIELD_EVEN_LOW). Yes, certainly I didn't think enough about this. I silently assumed that for V4L2_MBUS_FIELD_ACTIVE_HIGH FIELD = 0 selects Field1 (odd) and FIELD = 1 selects Field2 (even). I think it would be good to construct the macro so it is possibly self-explanatory, rather than requiring often to dig in the documentation. So I would go for V4L2_MBUS_FIELD_ODD_LOW/V4L2_MBUS_FIELD_ODD_HIGH. Unless someone proposes something different/better I'll send an amended version tomorrow. Thinking some more of it, V4L2_MBUS_FIELD_EVEN_HIGH/V4L2_MBUS_FIELD_EVEN_LOW is perhaps more in line with other defines where *HIGH means standard, non-inverted case. So it seems better to me. -- 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: [RESEND] [PATCH for 2.6.37] cx23885, cx25840: Provide IR Rx timeout event reports
Em 19-12-2010 21:10, Andy Walls escreveu:
(Resending because Mauro reported losing some emails on IRC)
Provide CX2388[578] IR receive timeout (RTO) reports in the
final space raw event sent up the chain to the raw IR pulse
decoders. This should allow the lirc decoder to actually
measure the inter-transmission gap properly.
Hi Andy,
I've no idea what's happened with this patch[1], but it seems that it
were never applied. Is this patch still valid?
[1] http://patchwork.linuxtv.org/patch/5133/
Thanks,
Mauro
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/media/video/cx23885/cx23888-ir.c | 12
drivers/media/video/cx25840/cx25840-ir.c | 12
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23888-ir.c
b/drivers/media/video/cx23885/cx23888-ir.c
index e37be6f..bb1ce34 100644
--- a/drivers/media/video/cx23885/cx23888-ir.c
+++ b/drivers/media/video/cx23885/cx23888-ir.c
@@ -673,7 +673,7 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
unsigned int i, n;
union cx23888_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
n = count / sizeof(union cx23888_ir_fifo_rec)
* sizeof(union cx23888_ir_fifo_rec);
@@ -692,11 +692,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd,
u8 *buf, size_t count,
if ((p-hw_fifo_data FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_888_debug, sd, rx read: end of rx\n);
+ w = 1;
} else {
u = (p-hw_fifo_data FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -707,9 +708,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(p-ir_core_data);
p-ir_core_data.pulse = u;
p-ir_core_data.duration = v;
+ p-ir_core_data.timeout = w;
- v4l2_dbg(2, ir_888_debug, sd, rx read: %10u ns %s\n,
- v, u ? mark : space);
+ v4l2_dbg(2, ir_888_debug, sd, rx read: %10u ns %s %s\n,
+ v, u ? mark : space, w ? (timed out) : );
+ if (w)
+ v4l2_dbg(2, ir_888_debug, sd, rx read: end of rx\n);
}
return 0;
}
diff --git a/drivers/media/video/cx25840/cx25840-ir.c
b/drivers/media/video/cx25840/cx25840-ir.c
index 627926f..b210c29 100644
--- a/drivers/media/video/cx25840/cx25840-ir.c
+++ b/drivers/media/video/cx25840/cx25840-ir.c
@@ -668,7 +668,7 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
u16 divider;
unsigned int i, n;
union cx25840_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
if (ir_state == NULL)
return -ENODEV;
@@ -694,11 +694,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd,
u8 *buf, size_t count,
if ((p-hw_fifo_data FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_debug, sd, rx read: end of rx\n);
+ w = 1;
} else {
u = (p-hw_fifo_data FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -709,9 +710,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(p-ir_core_data);
p-ir_core_data.pulse = u;
p-ir_core_data.duration = v;
+ p-ir_core_data.timeout = w;
- v4l2_dbg(2, ir_debug, sd, rx read: %10u ns %s\n,
- v, u ? mark : space);
+ v4l2_dbg(2, ir_debug, sd, rx read: %10u ns %s %s\n,
+ v, u ? mark : space, w ? (timed out) : );
+ if (w)
+ v4l2_dbg(2, ir_debug, sd, rx read: end of rx\n);
}
return 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
--
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] drivers/media/video/stk-webcam.c: webcam LED bug fix [IMPROVED]
This is an improved version of the patch I sent a little ago.
The problem was:
On my DC-1125 webcam chip from Syntek, whenever the webcam turns
on, the LED light on it is turned on also and never turns off again
unless
system is shut downed or restarted.
The previous version seemed to break some other laptop webcam work. Thanks
to Andrea Anacleto for the bug report and solution.
Signed-off-by: Andrea Anacleto andreaanacl...@libero.it
Signed-off-by: Arvydas Sidorenko asi...@gmail.com
---
drivers/media/video/stk-webcam.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/stk-webcam.c b/drivers/media/video/stk-webcam.c
index d1a2cef..af57d80 100644
--- a/drivers/media/video/stk-webcam.c
+++ b/drivers/media/video/stk-webcam.c
@@ -55,6 +55,8 @@ MODULE_AUTHOR(Jaime Velasco Juan jsagarri...@gmail.com and
Nicolas VIVIEN);
MODULE_DESCRIPTION(Syntek DC1125 webcam driver);
+/* bool for webcam LED management */
+int first_init = 1;
/* Some cameras have audio interfaces, we aren't interested in those */
static struct usb_device_id stkwebcam_table[] = {
@@ -561,6 +563,12 @@ static int v4l_stk_open(struct file *fp)
if (dev == NULL || !is_present(dev)) {
return -ENXIO;
}
+
+ if (!first_init)
+ stk_camera_write_reg(dev, 0x0, 0x24);
+ else
+ first_init = 0;
+
fp-private_data = dev;
usb_autopm_get_interface(dev-interface);
@@ -574,6 +582,7 @@ static int v4l_stk_release(struct file *fp)
if (dev-owner == fp) {
stk_stop_stream(dev);
stk_free_buffers(dev);
+ stk_camera_write_reg(dev, 0x0, 0x49); /* turn off the LED */
dev-owner = NULL;
}
@@ -1350,6 +1359,7 @@ static int stk_camera_resume(struct usb_interface *intf)
return 0;
unset_initialised(dev);
stk_initialise(dev);
+ stk_camera_write_reg(dev, 0x0, 0x49);
stk_setup_format(dev);
if (is_streaming(dev))
stk_start_stream(dev);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] fixup! mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz min...@mina86.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |4 ++-
mm/page_alloc.c| 66 ++-
2 files changed, 60 insertions(+), 10 deletions(-)
On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned
long end,
+ gfp_t flag)
+{
+unsigned long pfn = start, count;
+struct page *page;
+struct zone *zone;
+int order;
+
+VM_BUG_ON(!pfn_valid(start));
+zone = page_zone(pfn_to_page(start));
On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen d...@linux.vnet.ibm.com wrote:
This implies that start-end are entirely contained in a single zone.
What enforces that? If some higher layer enforces that, I think we
probably need at least a VM_BUG_ON() in here and a comment about who
enforces it.
+spin_lock_irq(zone-lock);
+
+page = pfn_to_page(pfn);
+for (;;) {
+VM_BUG_ON(page_count(page) || !PageBuddy(page));
+list_del(page-lru);
+order = page_order(page);
+zone-free_area[order].nr_free--;
+rmv_page_order(page);
+__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+pfn += 1 order;
+if (pfn = end)
+break;
+VM_BUG_ON(!pfn_valid(pfn));
+page += 1 order;
+}
This 'struct page *'++ stuff is OK, but only for small, aligned areas.
For at least some of the sparsemem modes (non-VMEMMAP), you could walk
off of the end of the section_mem_map[] when you cross a MAX_ORDER
boundary. I'd feel a little bit more comfortable if pfn_to_page() was
being done each time, or only occasionally when you cross a section
boundary.
Do the attached changes seem to make sense?
I wanted to avoid calling pfn_to_page() each time as it seem fairly
expensive in sparsemem and disctontig modes. At the same time, the
macro trickery is so that users of sparsemem-vmemmap and flatmem won't
have to pay the price.
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index b2a81fd..003c52f 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -46,11 +46,13 @@ static inline void unset_migratetype_isolate(struct page
*page)
{
__unset_migratetype_isolate(page, MIGRATE_MOVABLE);
}
+
+/* The below functions must be run on a range from a single zone. */
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
gfp_t flags, unsigned migratetype);
-extern void free_contig_pages(struct page *page, int nr_pages);
+extern void free_contig_pages(unsigned long pfn, unsigned nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 46e78d4..32fda5d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5716,9 +5716,41 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+#if defined(CONFIG_FLATMEM) || defined(CONFIG_SPARSEMEM_VMEMMAP)
+
+/*
+ * In FLATMEM and CONFIG_SPARSEMEM_VMEMMAP we can safely increment the page
+ * pointer and get the same value as if we were to get by calling
+ * pfn_to_page() on incremented pfn counter.
+ */
+#define __contig_next_page(page, pageblock_left, pfn, increment) \
+ ((page) + (increment))
+
+#define __contig_first_page(pageblock_left, pfn) pfn_to_page(pfn)
+
+#else
+
+/*
+ * If we cross pageblock boundary, make sure we get a valid page pointer. If
+ * we are within pageblock, incrementing the pointer is good enough, and is
+ * a bit of an optimisation.
+ */
+#define __contig_next_page(page, pageblock_left, pfn, increment) \
+ (likely((pageblock_left) -= (increment)) ? (page) + (increment) \
+: (((pageblock_left) = pageblock_nr_pages), pfn_to_page(pfn)))
+
+#define __contig_first_page(pageblock_left, pfn) ( \
+ ((pageblock_left) = pageblock_nr_pages -\
+((pfn) (pageblock_nr_pages - 1))), \
+ pfn_to_page(pfn))
+
+
+#endif
+
unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
gfp_t flag)
{
+ unsigned long pageblock_left __unused;
unsigned long pfn = start, count;
struct page *page;
struct zone *zone;
@@ -5729,27 +5761,37 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
spin_lock_irq(zone-lock);
- page = pfn_to_page(pfn);
+ page = __contig_first_page(pageblock_left, pfn);
for (;;) {
- VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ VM_BUG_ON(!page_count(page) || !PageBuddy(page) ||
+
Re: [PATCH 1/3] sr030pc30: Remove empty s_stream op
Em 19-01-2011 23:44, Sylwester Nawrocki escreveu:
s_stream does nothing in current form so remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungin.p...@samsung.com
---
drivers/media/video/sr030pc30.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c
index c901721..e1eced1 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -714,11 +714,6 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd)
return ret;
}
-static int sr030pc30_s_stream(struct v4l2_subdev *sd, int enable)
-{
- return 0;
-}
-
static int sr030pc30_s_power(struct v4l2_subdev *sd, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -761,7 +756,6 @@ static const struct v4l2_subdev_core_ops
sr030pc30_core_ops = {
};
static const struct v4l2_subdev_video_ops sr030pc30_video_ops = {
- .s_stream = sr030pc30_s_stream,
.g_mbus_fmt = sr030pc30_g_fmt,
.s_mbus_fmt = sr030pc30_s_fmt,
.try_mbus_fmt = sr030pc30_try_fmt,
Hmm...
this patch[1] were never merged. It seems a cleanup, though.
Care to review it?
Thanks!
Mauro
[1] http://patchwork.linuxtv.org/patch/5631/
--
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
[GIT PATCHES FOR 3.2] noon010pc30 conversion to the pad (v2)
Hi Mauro, here is an updated pull request. Additionally I have appended a Kconfig cleanup patch to it. The following changes since commit de2fb698c6fb1e968a5ed9cc449024f119ad3853: [media] saa7164: Adding support for HVR2200 card id 0x8953 (2011-09-21 10:16:31 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l_noon010pc30 Sylwester Nawrocki (4): noon010pc30: Conversion to the media controller API noon010pc30: Improve s_power operation handling noon010pc30: Remove g_chip_ident operation handler v4l: Move SR030PC30, NOON010PC30, M5MOLS drivers to the right location drivers/media/video/Kconfig | 28 ++-- drivers/media/video/noon010pc30.c | 263 +++-- include/media/v4l2-chip-ident.h |3 - 3 files changed, 180 insertions(+), 114 deletions(-) Thank you, -- 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
Re: [PATCH 1/3] sr030pc30: Remove empty s_stream op
On 09/21/2011 05:22 PM, Mauro Carvalho Chehab wrote:
Em 19-01-2011 23:44, Sylwester Nawrocki escreveu:
s_stream does nothing in current form so remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungin.p...@samsung.com
---
drivers/media/video/sr030pc30.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sr030pc30.c
b/drivers/media/video/sr030pc30.c
index c901721..e1eced1 100644
--- a/drivers/media/video/sr030pc30.c
+++ b/drivers/media/video/sr030pc30.c
@@ -714,11 +714,6 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd)
return ret;
}
-static int sr030pc30_s_stream(struct v4l2_subdev *sd, int enable)
-{
-return 0;
-}
-
static int sr030pc30_s_power(struct v4l2_subdev *sd, int on)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -761,7 +756,6 @@ static const struct v4l2_subdev_core_ops
sr030pc30_core_ops = {
};
static const struct v4l2_subdev_video_ops sr030pc30_video_ops = {
-.s_stream = sr030pc30_s_stream,
.g_mbus_fmt = sr030pc30_g_fmt,
.s_mbus_fmt = sr030pc30_s_fmt,
.try_mbus_fmt = sr030pc30_try_fmt,
Hmm...
this patch[1] were never merged. It seems a cleanup, though.
Care to review it?
Indeed, it is still worth to apply. There was some ongoing work
at the control framework and other patches form this series need some
more modifications. But this one alone can be merged.
Thanks!
Mauro
[1] http://patchwork.linuxtv.org/patch/5631/
Thank you,
--
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 1/3] fixup! mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz min...@mina86.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
---
include/asm-generic/memory_model.h | 17 ++
include/linux/page-isolation.h |4 ++-
mm/page_alloc.c| 43 +++
3 files changed, 53 insertions(+), 11 deletions(-)
On Wed, 2011-09-21 at 17:19 +0200, Michal Nazarewicz wrote:
I wanted to avoid calling pfn_to_page() each time as it seem fairly
expensive in sparsemem and disctontig modes. At the same time, the
macro trickery is so that users of sparsemem-vmemmap and flatmem won't
have to pay the price.
On Wed, 21 Sep 2011 17:45:59 +0200, Dave Hansen d...@linux.vnet.ibm.com wrote:
Personally, I'd say the (incredibly minuscule) runtime cost is worth the
cost of making folks' eyes bleed when they see those macros. I think
there are some nicer ways to do it.
Yeah. I wasn't amazed by them either.
Is there a reason you can't logically do?
page = pfn_to_page(pfn);
for (;;) {
if (pfn_to_section_nr(pfn) == pfn_to_section_nr(pfn+1))
page++;
else
page = pfn_to_page(pfn+1);
}
Done. Thanks for the suggestions!
+#define __contig_next_page(page, pageblock_left, pfn, increment)\
+(likely((pageblock_left) -= (increment)) ? (page) + (increment) \
+ : (((pageblock_left) = pageblock_nr_pages), pfn_to_page(pfn)))
+
+#define __contig_first_page(pageblock_left, pfn) ( \
+((pageblock_left) = pageblock_nr_pages -\
+ ((pfn) (pageblock_nr_pages - 1))), \
+pfn_to_page(pfn))
+
+#endif
For the love of Pete, please make those in to functions if you're going
to keep them.
That was tricky because they modify pageblock_left. Not relevant now
anyways though.
diff --git a/include/asm-generic/memory_model.h
b/include/asm-generic/memory_model.h
index fb2d63f..900da88 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -69,6 +69,23 @@
})
#endif /* CONFIG_FLATMEM/DISCONTIGMEM/SPARSEMEM */
+#if defined(CONFIG_SPARSEMEM) !defined(CONFIG_SPARSEMEM_VMEMMAP)
+
+/*
+ * Both PFNs must be from the same zone! If this function returns
+ * true, pfn_to_page(pfn1) + (pfn2 - pfn1) == pfn_to_page(pfn2).
+ */
+static inline bool zone_pfn_same_memmap(unsigned long pfn1, unsigned long pfn2)
+{
+ return pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2);
+}
+
+#else
+
+#define zone_pfn_same_memmap(pfn1, pfn2) (true)
+
+#endif
+
#define page_to_pfn __page_to_pfn
#define pfn_to_page __pfn_to_page
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index b2a81fd..003c52f 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -46,11 +46,13 @@ static inline void unset_migratetype_isolate(struct page
*page)
{
__unset_migratetype_isolate(page, MIGRATE_MOVABLE);
}
+
+/* The below functions must be run on a range from a single zone. */
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
gfp_t flags, unsigned migratetype);
-extern void free_contig_pages(struct page *page, int nr_pages);
+extern void free_contig_pages(unsigned long pfn, unsigned nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 46e78d4..bc200a9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5725,31 +5725,46 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
int order;
VM_BUG_ON(!pfn_valid(start));
- zone = page_zone(pfn_to_page(start));
+ page = pfn_to_page(start);
+ zone = page_zone(page);
spin_lock_irq(zone-lock);
- page = pfn_to_page(pfn);
for (;;) {
- VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ VM_BUG_ON(!page_count(page) || !PageBuddy(page) ||
+ page_zone(page) != zone);
+
list_del(page-lru);
order = page_order(page);
+ count = 1UL order;
zone-free_area[order].nr_free--;
rmv_page_order(page);
- __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
- pfn += 1 order;
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(long)count);
+
+ pfn += count;
if (pfn = end)
break;
VM_BUG_ON(!pfn_valid(pfn));
- page += 1 order;
+
+ if (zone_pfn_same_memmap(pfn - count, pfn))
+ page += count;
+ else
+ page = pfn_to_page(pfn);
}
spin_unlock_irq(zone-lock);
/* After this,
Re: [PATCH 1/3] fixup! mm: alloc_contig_freed_pages() added
On Wed, 2011-09-21 at 18:26 +0200, Michal Nazarewicz wrote: - page += 1 order; + + if (zone_pfn_same_memmap(pfn - count, pfn)) + page += count; + else + page = pfn_to_page(pfn); } That all looks sane to me and should fix the bug I brought up. -- Dave -- 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 0/2] soc-camera: prepare sh_mobile_ceu_camera for MC
Hi all Of the following 2 patches the first one just adds a helper function to soc-camera core, and the second one removes the worst cases of coffee-ground reading from the driver. By this I mean optimisation attempts, trying to combine client (e.g., camera sensor driver) and host (CEU, bridge) cropping and scaling to achieve best results. Where best results meant as close to user-requesed configuration as possible with minimum bandwidth waste. Even though the results were pretty good, the implementation made the driver very complex, hard to maintain and loaded with calculations less trivial, than what we like to have in the kernel. With the move to the Media Controller these optimisations can and shall be carried out in the user-space with each driver being configured separately for its specific cropping and scaling tasks. Even though we want to preserve the ability to work with standard V4L2 applications even without the need for an initial set up, we can now remove all those optimisations and only keep a couple of simple cases for backwards compatibility. These simple cases include situations, where the CEU driver forwards an S_CROP or an S_FMT to the subdevice driver(s), then checks the result and if there is a _simple_ way to improve it, then it does that. Most importantly all cases of cropping (on CEU / bridge) on top of scaling (subdevice), which lead to the need to calculate subdevice scaling factors and use them to calculate host cropping and its projection on the sensor plane... I don't think we manage to get these patches in 3.2, especially, since they mostly make sense in conmbination with the soc-camera Media Controller patches, which also are not quite finished yet. So, these patches are an early preview. They should be applied on top of what will become the soc-camera 3.2 pull, an almost final version of which is available at git://linuxtv.org/gliakhovetski/v4l-dvb.git rc1-for-3.2 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
[PATCH 1/2] V4L: soc-camera: add a function to lookup xlate by mediabus code
In addition to a helper function, performing a format translation table
lookup by a fourcc value, a similar function is now needed to lookup
translation table entries by mediabus codes.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera.c | 14 +-
include/media/soc_camera.h |5 -
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index d1ced8f..b62f2fe 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -112,7 +112,7 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
}
const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
- struct soc_camera_device *icd, unsigned int fourcc)
+ const struct soc_camera_device *icd, unsigned int fourcc)
{
unsigned int i;
@@ -123,6 +123,18 @@ const struct soc_camera_format_xlate
*soc_camera_xlate_by_fourcc(
}
EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
+const struct soc_camera_format_xlate *soc_camera_xlate_by_mcode(
+ const struct soc_camera_device *icd, enum v4l2_mbus_pixelcode code)
+{
+ unsigned int i;
+
+ for (i = 0; i icd-num_user_formats; i++)
+ if (icd-user_formats[i].code == code)
+ return icd-user_formats + i;
+ return NULL;
+}
+EXPORT_SYMBOL(soc_camera_xlate_by_mcode);
+
/**
* soc_camera_apply_board_flags() - apply platform SOCAM_SENSOR_INVERT_* flags
* @icl: camera platform parameters
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index b1377b9..fe7e8ad 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -174,7 +174,10 @@ int soc_camera_host_register(struct soc_camera_host *ici);
void soc_camera_host_unregister(struct soc_camera_host *ici);
const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
- struct soc_camera_device *icd, unsigned int fourcc);
+ const struct soc_camera_device *icd, unsigned int fourcc);
+
+const struct soc_camera_format_xlate *soc_camera_xlate_by_mcode(
+ const struct soc_camera_device *icd, enum v4l2_mbus_pixelcode code);
/**
* struct soc_camera_format_xlate - match between host and sensor formats
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] V4L: sh_mobile_ceu_camera: simplify scaling and cropping algorithms
With the pad-level API scaling and cropping will be configured on each
entity separately. To prepare for the conversion remove all attempts
to optimise scaling and cropping on the host and clients, as has
previously been done by the sh_mobile_ceu_camera driver.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This removes ugliest optimisation attempts and makes the driver 170 lines
shorter.
drivers/media/video/sh_mobile_ceu_camera.c | 876 +++-
1 files changed, 352 insertions(+), 524 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 955947a..d54c72b 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -112,7 +112,6 @@ struct sh_mobile_ceu_dev {
u32 cflcr;
- enum v4l2_field field;
int sequence;
unsigned int image_mode:1;
@@ -121,20 +120,16 @@ struct sh_mobile_ceu_dev {
};
struct sh_mobile_ceu_cam {
- /* CEU offsets within the camera output, before the CEU scaler */
- unsigned int ceu_left;
- unsigned int ceu_top;
+ /* Client cropping rectangle */
+ struct v4l2_rect rect;
/* Client output, as seen by the CEU */
unsigned int width;
unsigned int height;
/*
-* User window from S_CROP / G_CROP, produced by client cropping and
-* scaling, CEU scaling and CEU cropping, mapped back onto the client
-* input window
+* CEU offsets and sizes within the camera output, before the CEU
+* scaling filter
*/
- struct v4l2_rect subrect;
- /* Camera cropping rectangle */
- struct v4l2_rect rect;
+ struct v4l2_rect ceu_rect;
const struct soc_mbus_pixelfmt *extra_fmt;
enum v4l2_mbus_pixelcode code;
};
@@ -303,7 +298,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
if (!pcdev-active)
return ret;
- if (V4L2_FIELD_INTERLACED_BT == pcdev-field) {
+ if (V4L2_FIELD_INTERLACED_BT == icd-field) {
top1= CDBYR;
top2= CDBCR;
bottom1 = CDAYR;
@@ -329,7 +324,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
}
ceu_write(pcdev, top1, phys_addr_top);
- if (V4L2_FIELD_NONE != pcdev-field) {
+ if (V4L2_FIELD_NONE != icd-field) {
if (planar)
phys_addr_bottom = phys_addr_top + icd-user_width;
else
@@ -343,7 +338,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
phys_addr_top += icd-user_width *
icd-user_height;
ceu_write(pcdev, top2, phys_addr_top);
- if (V4L2_FIELD_NONE != pcdev-field) {
+ if (V4L2_FIELD_NONE != icd-field) {
phys_addr_bottom = phys_addr_top + icd-user_width;
ceu_write(pcdev, bottom2, phys_addr_bottom);
}
@@ -517,7 +512,7 @@ static irqreturn_t sh_mobile_ceu_irq(int irq, void *data)
ret = sh_mobile_ceu_capture(pcdev);
do_gettimeofday(vb-v4l2_buf.timestamp);
if (!ret) {
- vb-v4l2_buf.field = pcdev-field;
+ vb-v4l2_buf.field = pcdev-icd-field;
vb-v4l2_buf.sequence = pcdev-sequence++;
}
vb2_buffer_done(vb, ret 0 ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
@@ -659,17 +654,18 @@ static void sh_mobile_ceu_set_rect(struct
soc_camera_device *icd)
u32 camor;
dev_geo(icd-parent, Crop %ux%u@%u:%u\n,
- icd-user_width, icd-user_height, cam-ceu_left, cam-ceu_top);
+ icd-user_width, icd-user_height, cam-ceu_rect.left,
cam-ceu_rect.top);
- left_offset = cam-ceu_left;
- top_offset = cam-ceu_top;
+ left_offset = cam-ceu_rect.left;
+ top_offset = cam-ceu_rect.top;
WARN_ON(icd-user_width 3 || icd-user_height 3);
width = icd-user_width;
+ in_width = min(2560U, cam-width);
+
if (pcdev-image_mode) {
- in_width = cam-width;
if (!pcdev-is_16bit) {
in_width *= 2;
left_offset *= 2;
@@ -688,7 +684,7 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device
*icd)
w_factor = 1;
}
- in_width = cam-width * w_factor;
+ in_width *= w_factor;
left_offset *= w_factor;
if (bytes_per_line 0)
@@ -698,8 +694,8 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device
*icd)
}
height = icd-user_height;
- in_height = cam-height;
- if (V4L2_FIELD_NONE != pcdev-field) {
+ in_height = min(1920U, cam-height);
+ if (V4L2_FIELD_NONE != icd-field) {
height = (height / 2) ~3;
Re: [PATCH v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
On Wed, Sep 21, 2011 at 02:47:29PM +0200, Laurent Pinchart wrote:
Hi Sylwester,
Hi Laurent and Sylwester,
On Wednesday 21 September 2011 14:28:25 Sylwester Nawrocki wrote:
On 09/21/2011 12:17 AM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote:
On 09/20/2011 10:57 PM, Sakari Ailus wrote:
On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote:
V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple and thus. Currently in the menu we have entries for
50 and 60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h|1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml index 2420e4a..c6b3c46
100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -232,8 +232,9 @@ control is deprecated. New drivers and
applications should use the
entryEnables a power line frequency filter to avoid
flicker. Possible values forconstantenum
v4l2_power_line_frequency/constant are:
constantV4L2_CID_POWER_LINE_FREQUENCY_DISABLED/constant (0),
-constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1) and
-constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2)./entry
+constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1),
+constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2) and
+constantV4L2_CID_POWER_LINE_FREQUENCY_AUTO/constant (3)./entry
A stupid question: wouldn't this be a case for a new control for
automatic power line frequency, in other words enabling or disabling
it?
IMO this would complicate things in kernel and user land, without any
reasonable positive effects. AUTO seems to fit well here, it's just
another mode of operation of a power line noise filter. Why make things
more complicated than they need to be ?
The advantage would be to be able to get the power line frquency if
that's supported by the hardware. This implementation excludes that.
Such information might be interesting to add e.g. to the image's exif
data.
AFAIU, the power line frequency filter just modifies frame exposure time to
be multiple of half of the mains frequency period. So it's the exposure
time that gets finally affected. Maybe there is some hardware that
supports retrieving of the detected frequency, however I'm not aware of
it. And it doesn't seem useful unless you want to use camera as some
non-standard measurement tool. It also takes some time until the detection
algorithm locks, during this time an undefined frequency value would be
read.
I believe the filter settings do not really apply to still capture as it
involves periodic operation, like preview. Even if we had this as meta
data tag, there are more direct raw image parameters than the PL noise
filter frequency.
I feel uncomfortable with having 2 controls, where one can disable the
filter and the other enable it with AUTO setting.
Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ,
60HZ, AUTO. (there is already one sensor driver in mainline that support
it - ov519). How do we map this onto 2 controls ?
What do we return from the menu control that covers { OFF, 50HZ, 60HZ }
when AUTO mode is enabled through the other control and H/W doesn't allow
to read the detected frequency ?
I think, for the 2 controls we would need the DISABLED entry not to belong
to V4L2_CID_POWER_LINE_FREQUENCY at first place.
Not sure if that's important, though.
I would say no, but someone can prove me wrong. And who knows what kind of
strange H/W future brings.
I think it all boils down to whether V4L2_CID_POWER_LINE_FREQUENCY is the
power line frequency filter control or the power line frequency control. In
the first case it doesn't make sense to use two separate controls. In the
second case it could.
I don't think we need two controls for this, but that's just a personal
opinion of the I don't think we need to bother type :-)
I'm fine with the auto option being part of the same control.
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail:
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Em 08-06-2011 07:29, Kassey Lee escreveu:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Hi Guennadi,
Would you mind reviewing this patch[1]?
[1] http://patchwork.linuxtv.org/patch/7210/
Thanks,
Mauro.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1071
+++
4 files changed, 1116 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC) += mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..ed2397f
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
uk-EmleyMoor update
The Emley Moor transmitter in the UK completed digital switchover today, making the existing transmitter file: http://linuxtv.org/hg/dvb-apps/file/tip/util/scan/dvb-t/uk-EmleyMoor obsolete. Attached is a patch which I've just successfully used with dvbscan to obtain a new channels.conf. Thanks, -- Andii :-) --- /usr/share/dvb/dvb-t/uk-EmleyMoor 2010-08-02 19:17:04.302416402 +0100 +++ /home/andrew/.tzap/uk-EmleyMoor 2011-09-21 18:11:02.936106090 +0100 @@ -1,10 +1,7 @@ # UK, Emley Moor -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 722167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 625833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 649833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 673833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 705833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 697833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE +T 68200 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB1/BBCA +T 65800 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB2/D34 +T 71400 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM4/SDN +T 72200 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM5/ARQA +T 69000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM6/ARQB
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Hi Mauro
On Wed, 21 Sep 2011, Mauro Carvalho Chehab wrote:
Em 08-06-2011 07:29, Kassey Lee escreveu:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Hi Guennadi,
Would you mind reviewing this patch[1]?
Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to
be usable for other implementations, using the same core, this driver has
to be converted to re-use the common code, and so far this has not been
done, or am I missing something?
Thanks
Guennadi
[1] http://patchwork.linuxtv.org/patch/7210/
Thanks,
Mauro.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1071
+++
4 files changed, 1116 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..ed2397f
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * 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.
+ *
+ */
+
+#include
Re: [PATCH 10/10] rc-core: move timeout and checks to lirc
Em 28-04-2011 12:14, David Härdeman escreveu:
The lirc TX functionality expects the process which writes (TX) data to
the lirc dev to sleep until the actual data has been transmitted by the
hardware.
Since the same timeout calculation is duplicated in more than one driver
(and would have to be duplicated in even more drivers as they gain TX
support), it makes sense to move this timeout calculation to the lirc
layer instead.
At the same time, centralize some of the sanity checks.
This patch[1] were never applied, nor I'm seeing any comments about it
at the ML.
Jarod,
would you care to review it?
Thanks,
Mauro
[1] http://patchwork.linuxtv.org/patch/6468/
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/ir-lirc-codec.c | 33 +
drivers/media/rc/mceusb.c| 18 --
drivers/media/rc/rc-loopback.c | 12
3 files changed, 29 insertions(+), 34 deletions(-)
diff --git a/drivers/media/rc/ir-lirc-codec.c
b/drivers/media/rc/ir-lirc-codec.c
index ac54139..a58c7fe 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -106,6 +106,12 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char *buf,
unsigned int *txbuf; /* buffer with values to transmit */
ssize_t ret = 0;
size_t count;
+ ktime_t start;
+ s64 towait;
+ unsigned int duration = 0; /* signal duration in us */
+ int i;
+
+ start = ktime_get();
lirc = lirc_get_pdata(file);
if (!lirc)
@@ -128,11 +134,30 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char *buf,
goto out;
}
- if (dev-tx_ir)
- ret = dev-tx_ir(dev, txbuf, count);
+ if (!dev-tx_ir) {
+ ret = -ENOSYS;
+ goto out;
+ }
+
+ ret = dev-tx_ir(dev, txbuf, (u32)n);
+ if (ret 0)
+ goto out;
+
+ for (i = 0; i ret; i++)
+ duration += txbuf[i];
- if (ret 0)
- ret *= sizeof(unsigned);
+ ret *= sizeof(unsigned int);
+
+ /*
+ * The lircd gap calculation expects the write function to
+ * wait for the actual IR signal to be transmitted before
+ * returning.
+ */
+ towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get());
+ if (towait 0) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(usecs_to_jiffies(towait));
+ }
out:
kfree(txbuf);
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index c1cd00d..7b08797 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -671,10 +671,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
int i, ret = 0;
int cmdcount = 0;
unsigned char *cmdbuf; /* MCE command buffer */
- long signal_duration = 0; /* Singnal length in us */
- struct timeval start_time, end_time;
-
- do_gettimeofday(start_time);
cmdbuf = kzalloc(sizeof(unsigned) * MCE_CMDBUF_SIZE, GFP_KERNEL);
if (!cmdbuf)
@@ -687,7 +683,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
/* Generate mce packet data */
for (i = 0; (i count) (cmdcount MCE_CMDBUF_SIZE); i++) {
- signal_duration += txbuf[i];
txbuf[i] = txbuf[i] / MCE_TIME_UNIT;
do { /* loop to support long pulses/spaces 127*50us=6.35ms */
@@ -730,19 +725,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
/* Transmit the command to the mce device */
mce_async_out(ir, cmdbuf, cmdcount);
- /*
- * The lircd gap calculation expects the write function to
- * wait the time it takes for the ircommand to be sent before
- * it returns.
- */
- do_gettimeofday(end_time);
- signal_duration -= (end_time.tv_usec - start_time.tv_usec) +
-(end_time.tv_sec - start_time.tv_sec) * 100;
-
- /* delay with the closest number of ticks */
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(usecs_to_jiffies(signal_duration));
-
out:
kfree(cmdbuf);
return ret ? ret : count;
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index fb8ca81..5cb7057 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -105,18 +105,9 @@ static int loop_tx_ir(struct rc_dev *dev, unsigned
*txbuf, unsigned count)
{
struct loopback_dev *lodev = dev-priv;
u32 rxmask;
- unsigned total_duration = 0;
unsigned i;
DEFINE_IR_RAW_EVENT(rawir);
- for (i = 0; i count; i++)
- total_duration += abs(txbuf[i]);
-
- if (total_duration == 0) {
- dprintk(invalid tx data, total duration zero\n);
- return
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Em 04-05-2011 08:27, Lutz Sammer escreveu: On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns Manu, We're still missing your review on this patch[1], or it were eventually missed. Please review it. Thanks, Mauro [1] http://patchwork.linuxtv.org/patch/6511/ -- 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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Wed, 21 Sep 2011 19:31:21 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to be usable for other implementations, using the same core, this driver has to be converted to re-use the common code, and so far this has not been done, or am I missing something? That is, indeed, how I think it should be done. I'm fully aware that I've not quite finished my part of that - in particular, I've not fixed the ov7670-only problem. That would move up on my tragically long priority list if I knew that there would be a need for it in the near future. Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Em 21-09-2011 14:31, Guennadi Liakhovetski escreveu:
Hi Mauro
On Wed, 21 Sep 2011, Mauro Carvalho Chehab wrote:
Em 08-06-2011 07:29, Kassey Lee escreveu:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Hi Guennadi,
Would you mind reviewing this patch[1]?
Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to
be usable for other implementations, using the same core, this driver has
to be converted to re-use the common code, and so far this has not been
done, or am I missing something?
Ah, yes. Ok, I've marked it as superseded at patchwork.
As you know, I've migrated all patches to Linuxtv patchwork,
and taking the opportunity to double-check if something got
missed by all those troubles at kernel.org.
It is hard to recover the history of some patches, like this one ;)
Thanks!
Mauro
Thanks
Guennadi
[1] http://patchwork.linuxtv.org/patch/7210/
Thanks,
Mauro.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1071
+++
4 files changed, 1116 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.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.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) +=
soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c
b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..ed2397f
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1071 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2
+ * framework, but part of the low level register function
+ * is base on cafe_ccic.c
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * This program is free software; you can
[PATCH v2 1/2] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct
a driver what is the power line frequency so an appropriate filter
can be used by the device to cancel flicker by compensating the light
intensity ripple. Currently in the menu we have entries for 50 Hz and
60 Hz and for entirely disabling the anti-flicker filter.
However some devices are capable of automatically detecting the
frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h|1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 23fdf79..3bc5ee8 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should
use the
entryEnables a power line frequency filter to avoid
flicker. Possible values for constantenum
v4l2_power_line_frequency/constant are:
constantV4L2_CID_POWER_LINE_FREQUENCY_DISABLED/constant (0),
-constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1) and
-constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2)./entry
+constantV4L2_CID_POWER_LINE_FREQUENCY_50HZ/constant (1),
+constantV4L2_CID_POWER_LINE_FREQUENCY_60HZ/constant (2) and
+constantV4L2_CID_POWER_LINE_FREQUENCY_AUTO/constant (3)./entry
/row
row
entryconstantV4L2_CID_HUE_AUTO/constant/entry
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 06b6014..20abe5d 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -210,6 +210,7 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Disabled,
50 Hz,
60 Hz,
+ Auto,
NULL
};
static const char * const camera_exposure_auto[] = {
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a5359c6..b433968 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1125,6 +1125,7 @@ enum v4l2_power_line_frequency {
V4L2_CID_POWER_LINE_FREQUENCY_DISABLED = 0,
V4L2_CID_POWER_LINE_FREQUENCY_50HZ = 1,
V4L2_CID_POWER_LINE_FREQUENCY_60HZ = 2,
+ V4L2_CID_POWER_LINE_FREQUENCY_AUTO = 3,
};
#define V4L2_CID_HUE_AUTO (V4L2_CID_BASE+25)
#define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26)
--
1.7.6.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 v2 0/3] Add v4l2 subdev driver for S5K6AAFX sensor
Hello The following change set adds subdev driver for S5K6AAFX sensor with embedded ISP SoC, and minor v4l2 control API enhancement. Changes since v1: - improved s5k6aa_initialize_ctrls() - fixed pixel resolution update issue which in some cases resulted in cropping where scaling was expected - used V4L2_COLORFX_SKY_BLUE instead of V4L2_COLORFX_AQUA - dropped patch adding V4L2_COLORFX_AQUA entry for V4L2_CID_COLORFX control - patch 2/2 - no changes Sylwester Nawrocki (2): v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control v4l: Add v4l2 subdev driver for S5K6AAFX sensor Documentation/DocBook/media/v4l/controls.xml |5 +- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h|1 + include/media/s5k6aa.h | 51 + 7 files changed, 1546 insertions(+), 2 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h Thanks, -- 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 v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
This driver exposes preview mode operation of the S5K6AAFX sensor with embedded SoC ISP. It uses one of the five user predefined configuration register sets. There is yet no support for capture (snapshot) operation. Following controls are supported: manual/auto exposure and gain, power line frequency (anti-flicker), saturation, sharpness, brightness, contrast, white balance temperature, color effects, horizontal/vertical image flip, frame interval. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1541 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9da6044..ccc8172 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -496,6 +496,13 @@ config VIDEO_TCM825X This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. +config VIDEO_S5K6AA + tristate Samsung S5K6AAFX sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M + camera sensor with an embedded SoC image signal processor. + comment Flash devices config VIDEO_ADP1653 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index f52a771..526cb32 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..43b7dac --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1482 @@ +/* + * Driver for Samsung S5K6AAFX SXGA 1/6 1.3M CMOS Image Sensor + * with embedded SoC ISP. + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki s.nawro...@samsung.com + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * Copyright (C) 2009, Dongsoo Nathaniel Kim dongsoo45@samsung.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. + * + * TODO: + * - add set/get_crop operations + * - add capture (snapshot) mode support + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/gpio.h +#include linux/i2c.h +#include linux/media.h +#include linux/regulator/consumer.h +#include linux/slab.h + +#include media/media-entity.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include media/v4l2-mediabus.h +#include media/s5k6aa.h + +static int debug; +module_param(debug, int, 0644); + +#define DRIVER_NAMES5K6AA + +/* The token to indicate array termination */ +#define S5K6AA_TERM0x +#define S5K6AA_OUT_WIDTH_DEF 640 +#define S5K6AA_OUT_HEIGHT_DEF 480 +#define S5K6AA_WIN_WIDTH_MAX 1280 +#define S5K6AA_WIN_HEIGHT_MAX 1024 +#define S5K6AA_WIN_WIDTH_MIN 8 +#define S5K6AA_WIN_HEIGHT_MIN 8 + +/* + * H/W register Interface (0xD000 - 0xDFFF) + */ +#define AHB_MSB_ADDR_PTR 0xfcfc +#define GEN_REG_OFFSH 0xd000 +#define REG_SW_RESET 0x0010 +#define REG_SW_LOAD_COMPLETE 0x0014 +#define REG_CMDWR_ADDRH0x0028 +#define REG_CMDWR_ADDRL0x002a +#define REG_CMDRD_ADDRH0x002c +#define REG_CMDRD_ADDRL0x002e + +#define REG_CMDBUF0_ADDR 0x0f12 +#define REG_CMDBUF1_ADDR 0x0f10 + +/* + * Host S/W Register interface (0x7000 - 0x70002000) + * The value of the two most significant address bytes is 0x7000, + * (HOST_SWIF_OFFS_H). The register addresses below specify 2 LSBs. + */ +#define HOST_SWIF_OFFSH0x7000 + +/* Initialization parameters */ +/* Master clock frequency in KHz */ +#define REG_I_INCLK_FREQ_L 0x01b8 +#define REG_I_INCLK_FREQ_H 0x01ba +#define REG_I_USE_NPVI_CLOCKS 0x01c6 +#define REG_I_USE_NMIPI_CLOCKS 0x01c8 + +/* Clock configurations, n = 0..3. REG_I_* frequency unit is 4 kHz. */ +#define
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Sep 21 19:00:16 CEST 2011 git hash:e553000a14ead0e265a8aa4d241c7b3221e233e3 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.3-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Mauro, On Wed, Sep 21, 2011 at 10:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 04-05-2011 08:27, Lutz Sammer escreveu: On 05/04/11 01:16, Mauro Carvalho Chehab wrote: Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: On Tue, 05 Apr 2011 13:00:14 +0200 Issa Gorissen flop.m@xxx wrote: Hi, Eutelsat made a recent migration from DVB-S to DVB-S2 (since 31/3/2011) on two transponders on HB13E - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 Msymb/s 0.2 Pilot off Polar H Before those changes, with my TT S2 3200, I was able to watch TV on those transponders. Now, I cannot even tune on those transponders. I have tried with scan-s2 and w_scan and the latest drivers from git. They both find the transponders but cannot tune onto it. Something noteworthy is that my other card, a DuoFlex S2 can tune fine on those transponders. My question is; can someone try this as well with a TT S2 3200 and post the results ? i read something about it lately here (german!): http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 It says in stb0899_drv.c function: static void stb0899_set_iterations(struct stb0899_state *state) This: reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); should be replaced with this: reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, STB0899_OFF0_MAX_ITER, reg); Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines affected. Kind Regards Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. Can someone confirm that such patch would fix the issue? If so, please forward it in a way that it could be applied (patch is currently line-wrapped), and submit with some comments/description and your SOB. As the patch is currently broken, I'm just marking it as rejected at patchwork. Manu, Please take a look on this trouble report. Sorry, the things are mixed here. My patch (resend and hopefully this time not broken) handles only DVB-S transponders. The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for me. But I have very weak receiption, Johns Manu, We're still missing your review on this patch[1], or it were eventually missed. Please review it. Thanks, Mauro [1] http://patchwork.linuxtv.org/patch/6511/ Patch is good and correct. Thanks. Reviewed-by: Manu Abraham m...@linuxtv.org -- 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: frame grabber INT-1461 under Linux
What's strange? card=77 is for GrandTec Multi Capture Card (Bt878), according to the http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/video4linux/CARD LIST.bttv. Sensoray has a Model 311 (http://www.sensoray.com/products/311.htm), with card=73. I knew that the INT-1461 is very similar to Sensoray's Model 311. So, you may try card=73. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Pavel Andris Sent: Wednesday, September 21, 2011 2:33 AM To: linux-media@vger.kernel.org Subject: frame grabber INT-1461 under Linux Hi, dmesg has asked me to mail you. Here's the essential part of the message: [1.806495] Linux video capture interface: v2.00 [1.806607] bttv: driver version 0.9.18 loaded [1.806613] bttv: using 8 buffers with 2080k (520 pages) each for capture [1.806669] bttv: Bt8xx card found (0). [1.806692] bttv :01:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [1.806710] bttv0: Bt878 (rev 17) at :01:01.0, irq: 17, latency: 64, mmio: 0xfdfff000 [1.806753] bttv0: subsystem: 1766: (UNKNOWN) [1.806758] please mail id, board name and the correct card= insmod option to linux-media@vger.kernel.org [1.806766] bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] [1.806839] bttv0: gpio: en=, out= in=00e31fff [init] [1.807003] bttv0: tuner absent [1.807086] bttv0: registered device video0 [1.807179] bttv0: registered device vbi0 [1.807204] bttv0: PLL: 28636363 = 35468950 .. ok [1.847974] bt878: AUDIO driver version 0.0.0 loaded I use bttv.card=77 kernel parameter. With no parameter, the frame grabber works, but in a strange way. Info about my frame grabber: INT-1461 PC/104-Plus Frame Grabber w/ 4 CVBS Inputs 24 DIO The INT-1461 video frame grabber is a low-cost, high-performance solution for capturing analog broadcast signals across the PCI bus. Based around the Conexant FusionTM 878A video decoder, this compact PC/104-Plus form factor board supports NTSC, PAL, and SECAM video formats at capture resolutions of up to 768 x 576 pixels and 30 frames per second. It can also sub-sample, scale, crop, and clip images at various resolutions and frame rates. You can easily find more info on the net. Thank you for writing and supporting media drivers. Regards, -- .. Pavel Andris | tel: +421 2 5941 1167 Institute of Informatics | fax: +421 2 5477 3271 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: utrra...@savba.sk SK - 845 07 Bratislava | Slovak republic| .. One hundred thousand lemmings cannot be wrong. Graffiti .. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx: DMA problem on ARM
Hello Devin, Thanks for your quick reply. Le Wed, 21 Sep 2011 08:04:52 -0400, Devin Heitmueller dheitmuel...@kernellabs.com a écrit : I ran into the same issue on em28xx in the past (which is what those parts of cx231xx are based on). Yes, just adding URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please try that out, and assuming it works feel free to submit a patch which can be included upstream. Ok, we'll try this out and report the results, and if those are positive, the corresponding patch. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.2] gspca for_v3.2
Em 12-08-2011 05:37, Jean-Francois Moine escreveu: The following changes since commit 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e: [media] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028 (2011-08-06 09:52:47 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.2 Jean-François, The last 3 patches didn't apply. Could you please re-base them over the current tree? Thanks! Mauro Jean-François Moine (15): gspca - ov519: Fix LED inversion of some ov519 webcams gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 gspca - jeilinj: Cleanup code gspca - sonixj: Adjust the contrast control gspca - sonixj: Increase the exposure for sensor soi768 gspca - sonixj: Cleanup source and remove useless instructions gspca - benq: Remove the useless function sd_isoc_init gspca - kinect: Remove the gspca_debug definition gspca - ov534_9: Use the new control mechanism gspca - ov534_9: New sensor ov9712 and new webcam 05a9:8065 gspca - main: Fix the isochronous transfer interval gspca - main: Better values for V4L2_FMT_FLAG_COMPRESSED gspca - main: Use a better altsetting for image transfer gspca - main: Handle the xHCI error on usb_set_interface() gspca - tp6800: New subdriver for Topro webcams Luiz Carlos Ramos (1): gspca - sonixj: Fix wrong register mask for sensor om6802 Documentation/video4linux/gspca.txt |3 + drivers/media/video/gspca/Kconfig |9 + drivers/media/video/gspca/Makefile |2 + drivers/media/video/gspca/benq.c| 15 - drivers/media/video/gspca/gspca.c | 234 ++- drivers/media/video/gspca/jeilinj.c | 10 +- drivers/media/video/gspca/kinect.c |5 - drivers/media/video/gspca/ov519.c | 22 +- drivers/media/video/gspca/ov534_9.c | 504 ++-- drivers/media/video/gspca/sonixj.c | 29 +- drivers/media/video/gspca/tp6800.c | 4989 +++ 11 files changed, 5430 insertions(+), 392 deletions(-) create mode 100644 drivers/media/video/gspca/tp6800.c -- 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
Patches at patchwork.linuxtv.org (127 patches)
As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. As we were without access to the old patchwork instance, I simply sent all emails I had locally stored on my local mahine to the new instance and reviewed all patches again. Basically, for old patches, I basically did some scripting that were marking old patches as superseded, if they didn't apply anymore. I also preserved the patches that were marked as under review from patchwork time, using some scripting and a local control file. So, we're basically close to what we had before kernel.org troubles (except for a series of patches that I've already applied today). My intention is to finish review all patches marked as new until the end of this week, and set a new tree for linux-next with our stuff (as the old one were at git.kernel.org). Please let me know if something is missed or if some patch from the list bellow is obsolete and can be marked with a different status. Thanks! Mauro == New patches == Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc http://patchwork.kernel.org/patch/255 Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface http://patchwork.kernel.org/patch/251 Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte http://patchwork.kernel.org/patch/253 Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote http://patchwork.kernel.org/patch/250 Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote http://patchwork.kernel.org/patch/252 Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [7/7] ati_remote: update Kconfig description http://patchwork.kernel.org/patch/254 Anssi Hannula anssi.hann...@iki.fi Aug,20 2011: [2/6] Fix memory leak on disconnect or error. http://patchwork.kernel.org/patch/270 Chris Rankin ranki...@yahoo.com Aug,20 2011: [1/2] EM28xx - fix race on disconnect http://patchwork.kernel.org/patch/275 Chris Rankin ranki...@yahoo.com Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/276 Chris Rankin ranki...@yahoo.com Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/278 Chris Rankin ranki...@yahoo.com Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/279 Chris Rankin ranki...@yahoo.com Aug,27 2011: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.kernel.org/patch/304 Archit Taneja arc...@ti.com Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.kernel.org/patch/353 Archit Taneja arc...@ti.com Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr http://patchwork.kernel.org/patch/354 Archit Taneja arc...@ti.com Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. http://patchwork.kernel.org/patch/7088Thierry Reding thierry.red...@avionic-design.de Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device http://patchwork.kernel.org/patch/7090jasondong jason.d...@ite.com.tw May,23 2011: Alternate setting 1 must be selected for interface 0 on the model that http://patchwork.kernel.org/patch/7179Hans Petter Selasky hsela...@c2i.net Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 http://patchwork.kernel.org/patch/7414Amber Jain am...@ti.com Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats http://patchwork.kernel.org/patch/7630Laurent Pinchart Laurent Pinchart laurent.pinch...@ideasonboard.com Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] http://patchwork.kernel.org/patch/7683Florian Mickler flor...@mickler.org Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure http://patchwork.kernel.org/patch/7687Hiremath, Vaibhav hvaib...@ti.com Aug,29 2011: tvp5150: add v4l2 subdev pad ops http://patchwork.kernel.org/patch/7700Enrico ebut...@users.berlios.de Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device unregister http://patchwork.kernel.org/patch/7701Maciej Szmigiero m...@o2.pl Aug,31 2011: TT CT-3650 CI support http://patchwork.kernel.org/patch/7732 Sep, 4 2011: Medion 95700 analog video support http://patchwork.kernel.org/patch/7767
Re: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. As we were without access to the old patchwork instance, I simply sent all emails I had locally stored on my local mahine to the new instance and reviewed all patches again. Basically, for old patches, I basically did some scripting that were marking old patches as superseded, if they didn't apply anymore. I also preserved the patches that were marked as under review from patchwork time, using some scripting and a local control file. So, we're basically close to what we had before kernel.org troubles (except for a series of patches that I've already applied today). My intention is to finish review all patches marked as new until the end of this week, and set a new tree for linux-next with our stuff (as the old one were at git.kernel.org). Please let me know if something is missed or if some patch from the list bellow is obsolete and can be marked with a different status. Thanks! Mauro == New patches == Gah! forgot to update the URL on my script. the patch list with the right URL is: == New patches == Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc http://patchwork.linuxtv.org/patch/255Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface http://patchwork.linuxtv.org/patch/251Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte http://patchwork.linuxtv.org/patch/253Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote http://patchwork.linuxtv.org/patch/250Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote http://patchwork.linuxtv.org/patch/252Anssi Hannula anssi.hann...@iki.fi Aug, 6 2011: [7/7] ati_remote: update Kconfig description http://patchwork.linuxtv.org/patch/254Anssi Hannula anssi.hann...@iki.fi Aug,20 2011: [2/6] Fix memory leak on disconnect or error. http://patchwork.linuxtv.org/patch/270Chris Rankin ranki...@yahoo.com Aug,20 2011: [1/2] EM28xx - fix race on disconnect http://patchwork.linuxtv.org/patch/275Chris Rankin ranki...@yahoo.com Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/276Chris Rankin ranki...@yahoo.com Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/278Chris Rankin ranki...@yahoo.com Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/279Chris Rankin ranki...@yahoo.com Aug,27 2011: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.linuxtv.org/patch/304Archit Taneja arc...@ti.com Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.linuxtv.org/patch/353Archit Taneja arc...@ti.com Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr http://patchwork.linuxtv.org/patch/354Archit Taneja arc...@ti.com Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. http://patchwork.linuxtv.org/patch/7088 Thierry Reding thierry.red...@avionic-design.de Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device http://patchwork.linuxtv.org/patch/7090 jasondong jason.d...@ite.com.tw May,23 2011: Alternate setting 1 must be selected for interface 0 on the model that http://patchwork.linuxtv.org/patch/7179 Hans Petter Selasky hsela...@c2i.net Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 http://patchwork.linuxtv.org/patch/7414 Amber Jain am...@ti.com Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats http://patchwork.linuxtv.org/patch/7630 Laurent Pinchart Laurent Pinchart laurent.pinch...@ideasonboard.com Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] http://patchwork.linuxtv.org/patch/7683 Florian Mickler flor...@mickler.org Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure http://patchwork.linuxtv.org/patch/7687 Hiremath, Vaibhav hvaib...@ti.com Aug,29 2011: tvp5150: add v4l2 subdev pad ops http://patchwork.linuxtv.org/patch/7700 Enrico ebut...@users.berlios.de Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device unregister http://patchwork.linuxtv.org/patch/7701 Maciej Szmigiero m...@o2.pl Aug,31 2011: TT CT-3650 CI support
Re: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro, On 09/21/2011 10:44 PM, Mauro Carvalho Chehab wrote: Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. As we were without access to the old patchwork instance, I simply sent all emails I had locally stored on my local mahine to the new instance and reviewed all patches again. Basically, for old patches, I basically did some scripting that were marking old patches as superseded, if they didn't apply anymore. I also preserved the patches that were marked as under review from patchwork time, using some scripting and a local control file. So, we're basically close to what we had before kernel.org troubles (except for a series of patches that I've already applied today). My intention is to finish review all patches marked as new until the end of this week, and set a new tree for linux-next with our stuff (as the old one were at git.kernel.org). Please let me know if something is missed or if some patch from the list bellow is obsolete and can be marked with a different status. Thanks! Mauro ... == New patches == Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc http://patchwork.linuxtv.org/patch/255Anssi Hannulaanssi.hann...@iki.fi Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface http://patchwork.linuxtv.org/patch/251Anssi Hannulaanssi.hann...@iki.fi Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte http://patchwork.linuxtv.org/patch/253Anssi Hannulaanssi.hann...@iki.fi Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote http://patchwork.linuxtv.org/patch/250Anssi Hannulaanssi.hann...@iki.fi Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote http://patchwork.linuxtv.org/patch/252Anssi Hannulaanssi.hann...@iki.fi Aug, 6 2011: [7/7] ati_remote: update Kconfig description http://patchwork.linuxtv.org/patch/254Anssi Hannulaanssi.hann...@iki.fi Aug,20 2011: [2/6] Fix memory leak on disconnect or error. http://patchwork.linuxtv.org/patch/270Chris Rankinranki...@yahoo.com Aug,20 2011: [1/2] EM28xx - fix race on disconnect http://patchwork.linuxtv.org/patch/275Chris Rankinranki...@yahoo.com Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/276Chris Rankinranki...@yahoo.com Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/278Chris Rankinranki...@yahoo.com Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/279Chris Rankinranki...@yahoo.com Aug,27 2011: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.linuxtv.org/patch/304Archit Tanejaarc...@ti.com Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation http://patchwork.linuxtv.org/patch/353Archit Tanejaarc...@ti.com Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr http://patchwork.linuxtv.org/patch/354Archit Tanejaarc...@ti.com Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. http://patchwork.linuxtv.org/patch/7088 Thierry Redingthierry.red...@avionic-design.de Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device http://patchwork.linuxtv.org/patch/7090 jasondongjason.d...@ite.com.tw May,23 2011: Alternate setting 1 must be selected for interface 0 on the model that http://patchwork.linuxtv.org/patch/7179 Hans Petter Selaskyhsela...@c2i.net Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 http://patchwork.linuxtv.org/patch/7414 Amber Jainam...@ti.com Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats http://patchwork.linuxtv.org/patch/7630 Laurent PinchartLaurent Pinchartlaurent.pinch...@ideasonboard.com Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] http://patchwork.linuxtv.org/patch/7683 Florian Micklerflor...@mickler.org Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure http://patchwork.linuxtv.org/patch/7687 Hiremath, Vaibhavhvaib...@ti.com Aug,29 2011: tvp5150: add v4l2 subdev pad ops http://patchwork.linuxtv.org/patch/7700 Enricoebut...@users.berlios.de Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device unregister http://patchwork.linuxtv.org/patch/7701 Maciej Szmigierom...@o2.pl Aug,31 2011: TT CT-3650 CI support
Re: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro,
On Wednesday 21 September 2011 22:44:20 Mauro Carvalho Chehab wrote:
Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu:
As announced on Sept, 18, we moved our patch queue to
patchwork.linuxtv.org.
Thank you for working on that.
[snip]
Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
http://patchwork.linuxtv.org/patch/7630
This one has been superseeded. Speaking of this, the next version of the patch
will be needed for an fbdev driver that should make it to v3.3. Should I push
NV24 support through your tree for v3.2 to make sure compilation won't break
during the v3.3 merge window ?
Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb
(v4l2_device_d
http://patchwork.linuxtv.org/patch/7779
Superseeded as well.
Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes
http://patchwork.linuxtv.org/patch/7835
Please pull that :-) It's for v3.1, there's not much time left.
== Patches waiting for Laurent Pinchart review ==
[snip]
Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev
http://patchwork.linuxtv.org/patch/7431
I don't think that one is for me.
Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel
codes in adv7
http://patchwork.linuxtv.org/patch/7425
I don't think this one is for me either.
--
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: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 18:09, Sylwester Nawrocki escreveu: Hi Mauro, Updated accordingly, thanks! Sep,19 2011: [GIT,PATCHES,FOR,3.2] noon010pc30 conversion to the pad level ops http://patchwork.linuxtv.org/patch/7877 Sylwester Nawrockis.nawro...@samsung.com not really a patch This patchwork version is capable of getting git pull requests, when generated with git request-pull. I'm planning to change my scripts to recognize those requests and use it. An unique queue helps me to apply patches at the arrival order. Thanks, 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: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 18:58, Laurent Pinchart escreveu:
Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
http://patchwork.linuxtv.org/patch/7630
This one has been superseeded. Speaking of this, the next version of the
patch
will be needed for an fbdev driver that should make it to v3.3. Should I push
NV24 support through your tree for v3.2 to make sure compilation won't break
during the v3.3 merge window ?
The better is to submit both patches to the same tree, getting the maintainer's
ack from the other side. I'm ok with either direction. If you opt to sent the
patches via fbdev tree, send me the latest version of it for me to review and
ack.
Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb
(v4l2_device_d
http://patchwork.linuxtv.org/patch/7779
Superseeded as well.
Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes
http://patchwork.linuxtv.org/patch/7835
Please pull that :-) It's for v3.1, there's not much time left.
I will.
== Patches waiting for Laurent Pinchart review ==
[snip]
Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev
http://patchwork.linuxtv.org/patch/7431
I don't think that one is for me.
Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel
codes in adv7
http://patchwork.linuxtv.org/patch/7425
I don't think this one is for me either.
Hmm.. not sure why I put those two for you. Will fix that on my control
files.
Thank you!
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: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro,
On Thursday 22 September 2011 00:20:09 Mauro Carvalho Chehab wrote:
Em 21-09-2011 18:58, Laurent Pinchart escreveu:
Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
http://patchwork.linuxtv.org/patch/7630
This one has been superseeded. Speaking of this, the next version of the
patch will be needed for an fbdev driver that should make it to v3.3.
Should I push NV24 support through your tree for v3.2 to make sure
compilation won't break during the v3.3 merge window ?
The better is to submit both patches to the same tree, getting the
maintainer's ack from the other side. I'm ok with either direction. If you
opt to sent the patches via fbdev tree, send me the latest version of it
for me to review and ack.
linux-media has already been CC'ed.
[PATCH v3 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
http://patchwork.linuxtv.org/patch/306/
Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb
(v4l2_device_d
http://patchwork.linuxtv.org/patch/7779
Superseeded as well.
Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes
http://patchwork.linuxtv.org/patch/7835
Please pull that :-) It's for v3.1, there's not much time left.
I will.
Thank you.
== Patches waiting for Laurent Pinchart review ==
[snip]
Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev
http://patchwork.linuxtv.org/patch/7431
I don't think that one is for me.
Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel
codes in adv7
http://patchwork.linuxtv.org/patch/7425
I don't think this one is for me either.
Hmm.. not sure why I put those two for you. Will fix that on my control
files.
Thank you!
You're welcome. Thank you for your work on this, and the speed at which you
got it running.
--
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
[GIT PULL FOR v3.2] uvcvideo patches
Hi Mauro, The following changes since commit e27412f5a5966629e3d4213c78a539068ca0ea26: [media] mmp_camera: add MODULE_ALIAS (2011-09-18 08:05:43 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Al Cooper (1): media: Fix a UVC performance problem on systems with non-coherent DMA. Arne Caspari (1): uvcvideo: Detect The Imaging Source CCD cameras by vendor and product ID Laurent Pinchart (2): uvcvideo: Remove deprecated UVCIOC ioctls USB: export video.h to the includes available for userspace Stephan Lachowsky (1): uvcvideo: Add a mapping for H.264 payloads Documentation/feature-removal-schedule.txt | 23 -- drivers/media/video/uvc/uvc_driver.c | 13 drivers/media/video/uvc/uvc_v4l2.c | 54 +-- drivers/media/video/uvc/uvc_video.c| 17 - drivers/media/video/uvc/uvcvideo.h | 104 ++- include/linux/usb/Kbuild |1 + 6 files changed, 40 insertions(+), 172 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [VER 1.06] it913x add remote control support.
Add remote support for KWORLD UB499-2T-T09
The remote supplied is the same as KWORLD_315U.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 6d2f281..f027a2c 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -306,6 +306,30 @@ static struct i2c_algorithm it913x_i2c_algo = {
};
/* Callbacks for DVB USB */
+#define IT913X_POLL 250
+static int it913x_rc_query(struct dvb_usb_device *d)
+{
+ u8 ibuf[4];
+ int ret;
+ u32 key;
+ /* Avoid conflict with frontends*/
+ if (mutex_lock_interruptible(d-i2c_mutex) 0)
+ return -EAGAIN;
+
+ ret = it913x_io(d-udev, READ_LONG, PRO_LINK, CMD_IR_GET,
+ 0, 0, ibuf[0], sizeof(ibuf));
+
+ if ((ibuf[2] + ibuf[3]) == 0xff) {
+ key = ibuf[2];
+ key += ibuf[0] 8;
+ deb_info(1, INT Key =%08x, key);
+ if (d-rc_dev != NULL)
+ rc_keydown(d-rc_dev, key, 0);
+ }
+ mutex_unlock(d-i2c_mutex);
+
+ return ret;
+}
static int it913x_identify_state(struct usb_device *udev,
struct dvb_usb_device_properties *props,
struct dvb_usb_device_description **desc,
@@ -575,6 +599,14 @@ static struct dvb_usb_device_properties it913x_properties
= {
}
},
.identify_state = it913x_identify_state,
+ .rc.core = {
+ .protocol = RC_TYPE_NEC,
+ .module_name= it913x,
+ .rc_query = it913x_rc_query,
+ .rc_interval= IT913X_POLL,
+ .allowed_protos = RC_TYPE_NEC,
+ .rc_codes = RC_MAP_KWORLD_315U,
+ },
.i2c_algo = it913x_i2c_algo,
.num_device_descs = 1,
.devices = {
@@ -615,5 +647,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.05);
+MODULE_VERSION(1.06);
MODULE_LICENSE(GPL);
--
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
[PATCH] [ver 1.06] it913x-fe - correct tuner settings. Resend
Correct tuner settings for more accuracy. This now makes the tuner
section more compatible with other versions of the IT913X
series.
TODOs
Version 2 chip
Patch sent last week appears to be mangled and marked superseded.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/it913x-fe-priv.h | 24 +
drivers/media/dvb/frontends/it913x-fe.c | 139 --
2 files changed, 113 insertions(+), 50 deletions(-)
diff --git a/drivers/media/dvb/frontends/it913x-fe-priv.h
b/drivers/media/dvb/frontends/it913x-fe-priv.h
index b80634ab..40e1d9b 100644
--- a/drivers/media/dvb/frontends/it913x-fe-priv.h
+++ b/drivers/media/dvb/frontends/it913x-fe-priv.h
@@ -316,27 +316,13 @@ static struct it913xset it9137_set[] = {
{0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */
};
-static struct it913xset it9137_tuner[] = {
- {PRO_DMOD, 0xec57, {0x00}, 0x01},
- {PRO_DMOD, 0xec58, {0x00}, 0x01},
- {PRO_DMOD, 0xec40, {0x00}, 0x01},
- {PRO_DMOD, 0xec02, {0x00, 0x0c, 0x00, 0x40, 0x00, 0x80, 0x80,
- 0x00, 0x00, 0x00, 0x00 }, 0x0b},
- {PRO_DMOD, 0xec0d, {0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00 }, 0x0b},
- {PRO_DMOD, 0xec19, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00}, 0x08},
- {PRO_DMOD, 0xec22, {0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00}, 0x0a},
- {PRO_DMOD, 0xec3f, {0x01}, 0x01},
- /* Clear any existing tune */
- {PRO_DMOD, 0xec4c, {0xa8, 0x00, 0x00, 0x00, 0x00}, 0x05},
- {0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */
-};
-
static struct it913xset set_it9137_template[] = {
{PRO_DMOD, 0xee06, {0x00}, 0x01},
{PRO_DMOD, 0xec56, {0x00}, 0x01},
- {PRO_DMOD, 0xec4c, {0x00, 0x00, 0x00, 0x00, 0x00}, 0x05},
+ {PRO_DMOD, 0xec4c, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4d, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4e, {0x00}, 0x01},
+ {PRO_DMOD, 0xec4f, {0x00}, 0x01},
+ {PRO_DMOD, 0xec50, {0x00}, 0x01},
{0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */
};
diff --git a/drivers/media/dvb/frontends/it913x-fe.c
b/drivers/media/dvb/frontends/it913x-fe.c
index c92b3ec..02839a8b7 100644
--- a/drivers/media/dvb/frontends/it913x-fe.c
+++ b/drivers/media/dvb/frontends/it913x-fe.c
@@ -58,6 +58,10 @@ struct it913x_fe_state {
u8 tuner_type;
struct adctable *table;
fe_status_t it913x_status;
+ u16 tun_xtal;
+ u8 tun_fdiv;
+ u8 tun_clk_mode;
+ u32 tun_fn_min;
};
static int it913x_read_reg(struct it913x_fe_state *state,
@@ -159,13 +163,74 @@ static int it913x_fe_script_loader(struct it913x_fe_state
*state,
return 0;
}
+static int it913x_init_tuner(struct it913x_fe_state *state)
+{
+ int ret, i, reg;
+ u8 val, nv_val;
+ u8 nv[] = {48, 32, 24, 16, 12, 8, 6, 4, 2};
+ u8 b[2];
+
+ reg = it913x_read_reg_u8(state, 0xec86);
+ switch (reg) {
+ case 0:
+ state-tun_clk_mode = reg;
+ state-tun_xtal = 2000;
+ state-tun_fdiv = 3;
+ val = 16;
+ break;
+ case -ENODEV:
+ return -ENODEV;
+ case 1:
+ default:
+ state-tun_clk_mode = reg;
+ state-tun_xtal = 640;
+ state-tun_fdiv = 1;
+ val = 6;
+ break;
+ }
+
+ reg = it913x_read_reg_u8(state, 0xed03);
+
+ if (reg 0)
+ return -ENODEV;
+ else if (reg sizeof(nv))
+ nv_val = nv[reg];
+ else
+ nv_val = 2;
+
+ for (i = 0; i 50; i++) {
+ ret = it913x_read_reg(state, 0xed23, b[0], sizeof(b));
+ reg = (b[1] 8) + b[0];
+ if (reg 0)
+ break;
+ if (ret 0)
+ return -ENODEV;
+ udelay(2000);
+ }
+ state-tun_fn_min = state-tun_xtal * reg;
+ state-tun_fn_min /= (state-tun_fdiv * nv_val);
+ deb_info(Tuner fn_min %d, state-tun_fn_min);
+
+ for (i = 0; i 50; i++) {
+ reg = it913x_read_reg_u8(state, 0xec82);
+ if (reg 0)
+ break;
+ if (reg 0)
+ return -ENODEV;
+ udelay(2000);
+ }
+
+ return it913x_write_reg(state, PRO_DMOD, 0xed81, val);
+}
+
static int it9137_set_tuner(struct it913x_fe_state *state,
enum fe_bandwidth bandwidth, u32 frequency_m)
{
struct it913xset *set_tuner = set_it9137_template;
- int ret;
+ int ret, reg;
u32 frequency = frequency_m / 1000;
- u32 freq;
+ u32 freq, temp_f, tmp;
+ u16 iqik_m_cal;
u16 n_div;
u8 n;
u8 l_band;
@@ -218,10 +283,11
RE: [PATCH v2] [media] at91: add code to initialize and manage the ISI_MCK for Atmel ISI driver.
Hi, Nicolas
On Friday, September 09, 2011 6:05 PM, Nicolas Ferre wrote:
Le 06/09/2011 08:54, Guennadi Liakhovetski :
On Tue, 6 Sep 2011, Josh Wu wrote:
This patch enable the configuration for ISI_MCK, which is provided by
programmable clock.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/video/atmel-isi.c | 60
++-
include/media/atmel-isi.h |4 ++
2 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c
b/drivers/media/video/atmel-isi.c
[..]
/*
-
--*/
+/* Initialize ISI_MCK clock, called by atmel_isi_probe() function */
+static int initialize_mck(struct platform_device *pdev,
+ struct atmel_isi *isi)
+{
+ struct device *dev = pdev-dev;
+ struct isi_platform_data *pdata = dev-platform_data;
+ struct clk *pck_parent;
+ int ret;
+
+ if (!strlen(pdata-pck_name) || !strlen(pdata-pck_parent_name))
+ return -EINVAL;
+
+ /* ISI_MCK is provided by PCK clock */
+ isi-mck = clk_get(dev, pdata-pck_name);
I think, it's still not what Russell meant. Look at
drivers/mmc/host/atmel-mci.c:
host-mck = clk_get(pdev-dev, mci_clk);
and in arch/arm/mach-at91/at91sam9g45.c they've got
CLKDEV_CON_DEV_ID(mci_clk, atmel_mci.0, mmc0_clk),
CLKDEV_CON_DEV_ID(mci_clk, atmel_mci.1, mmc1_clk),
where
#define CLKDEV_CON_DEV_ID(_con_id, _dev_id, _clk)\
{ \
.con_id = _con_id, \
.dev_id = _dev_id, \
.clk = _clk,\
}
I.e., in the device driver (mmc in this case) you only use the
(platform) device instance, whose dev_name(dev) is then matched
against one of clock lookups above, and a connection ID, which is used
in case your device is using more than one clock. In the ISI case,
your pck1 clock, that you seem to need here, doesn't have a clock
lookup object, so, you might have to add one, and then use its connection ID.
+ if (IS_ERR(isi-mck)) {
+ dev_err(dev, Failed to get PCK: %s\n, pdata-pck_name);
+ return PTR_ERR(isi-mck);
+ }
+
+ pck_parent = clk_get(dev, pdata-pck_parent_name);
+ if (IS_ERR(pck_parent)) {
+ ret = PTR_ERR(pck_parent);
+ dev_err(dev, Failed to get PCK parent: %s\n,
+ pdata-pck_parent_name);
+ goto err_init_mck;
+ }
+
+ ret = clk_set_parent(isi-mck, pck_parent);
I'm not entirely sure on this one, but as we had a similar situation
with clocks, we decided to extablish the clock hierarchy in the board
code, and only deal with the actual device clocks in the driver
itself. I.e., we moved all clk_set_parent() and setting up the parent clock
into the board.
And I do think, this makes more sense, than doing this in the driver,
not all users of this driver will need to manage the parent clock, right?
Exactly.
Josh, for the two comments by Guennadi above, you can take
sound/soc/atmel/sam9g20_wm8731.c as an example of using PCK and parent
clocks. You will also find how to use named clocks and how to set the
programmable clocks rate...
According to sam9g20_wm8731.c file, and combined Guennadi and J.C's advices,
I'd like to only add clk_set_rate() and enable/disble isi_mck code in ISI
driver.
Also I will define isi_mck clock in soc chip file(at91sam9g45.c).
Then I will move all setting up the parent clock code into the
at91sam9g45_devices.c, where there are code to add Atmel ISI device.
I will generate the new version patch for it soon.
+ clk_put(pck_parent);
+ if (ret)
+ goto err_init_mck;
+
+ ret = clk_set_rate(isi-mck, pdata-isi_mck_hz);
+ if (ret 0)
+ goto err_init_mck;
+
+ return 0;
+
+err_init_mck:
+ clk_put(isi-mck);
+ return ret;
+}
+
static int __devexit atmel_isi_remove(struct platform_device *pdev)
{
struct soc_camera_host *soc_host = to_soc_camera_host(pdev-dev);
@@ -897,6 +948,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);
[..]
Best regards,
--
Nicolas Ferre
Best Regards,
Josh Wu
--
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] Add code to enable/disable ISI_MCK clock.
This patch add code to enable/disable ISI_MCK clock when add/remove soc camera
device.it also set ISI_MCK frequence before using it.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/video/atmel-isi.c | 30 --
include/media/atmel-isi.h |2 ++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7b89f00..888234a 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, provided by Programmable clock */
+ struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -763,6 +766,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);
@@ -776,6 +785,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;
@@ -897,6 +907,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);
@@ -915,7 +926,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-isi_mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -944,6 +955,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, which is provided by Programmable 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_alloc_descriptors;
+ }
+
+ /* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ ret = clk_set_rate(isi-mck, pdata-isi_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,
@@ -951,7 +975,7 @@ static int __devinit atmel_isi_probe(struct platform_device
*pdev)
if (!isi-p_fb_descriptors) {
ret = -ENOMEM;
dev_err(pdev-dev, Can't allocate descriptors!\n);
- goto err_alloc_descriptors;
+ goto err_set_mck_rate;
}
for (i = 0; i MAX_BUFFER_NUM; i++) {
@@ -1013,6 +1037,8 @@ err_alloc_ctx:
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
+err_set_mck_rate:
+ clk_put(isi-mck);
err_alloc_descriptors:
kfree(isi);
err_alloc_isi:
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..a0229a6 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -114,6 +114,8 @@ struct isi_platform_data {
u32 data_width_flags;
/* Using for ISI_CFG1 */
u32 frate;
+ /* Using for ISI_MCK, provided by Programmable clock */
+ u32 isi_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] at91: add Atmel ISI and ov2640 support on sam9m10/sam9g45 board.
This patch
1. add ISI_MCK parent setting code when add ISI device.
2. add ov2640 support on board file.
3. define isi_mck clock in sam9g45 chip file.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/mach-at91/at91sam9g45.c |3 +
arch/arm/mach-at91/at91sam9g45_devices.c | 105 +-
arch/arm/mach-at91/board-sam9m10g45ek.c | 85 -
arch/arm/mach-at91/include/mach/board.h |3 +-
4 files changed, 193 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index e04c5fb..5e23d6d 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -201,6 +201,7 @@ static struct clk *periph_clocks[] __initdata = {
// irq0
};
+static struct clk pck1;
static struct clk_lookup periph_clocks_lookups[] = {
/* One additional fake clock for ohci */
CLKDEV_CON_ID(ohci_clk, uhphs_clk),
@@ -215,6 +216,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID(t0_clk, atmel_tcb.1, tcb0_clk),
CLKDEV_CON_DEV_ID(pclk, ssc.0, ssc0_clk),
CLKDEV_CON_DEV_ID(pclk, ssc.1, ssc1_clk),
+ /* ISI_MCK, which is provided by programmable clock(PCK1) */
+ CLKDEV_CON_DEV_ID(isi_mck, atmel_isi.0, pck1),
};
static struct clk_lookup usart_clocks_lookups[] = {
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c
b/arch/arm/mach-at91/at91sam9g45_devices.c
index 600bffb..82eeac8 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -16,7 +16,7 @@
#include linux/platform_device.h
#include linux/i2c-gpio.h
#include linux/atmel-mci.h
-
+#include linux/clk.h
#include linux/fb.h
#include video/atmel_lcdc.h
@@ -28,6 +28,8 @@
#include mach/at_hdmac.h
#include mach/atmel-mci.h
+#include media/atmel-isi.h
+
#include generic.h
@@ -863,6 +865,107 @@ void __init at91_add_device_ac97(struct
ac97c_platform_data *data)
void __init at91_add_device_ac97(struct ac97c_platform_data *data) {}
#endif
+/*
+ * Image Sensor Interface
+ * */
+#if defined(CONFIG_VIDEO_ATMEL_ISI) || defined(CONFIG_VIDEO_ATMEL_ISI_MODULE)
+static u64 isi_dmamask = DMA_BIT_MASK(32);
+static struct isi_platform_data isi_data;
+
+struct resource isi_resources[] = {
+ [0] = {
+ .start = AT91SAM9G45_BASE_ISI,
+ .end= AT91SAM9G45_BASE_ISI + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = AT91SAM9G45_ID_ISI,
+ .end= AT91SAM9G45_ID_ISI,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device at91sam9g45_isi_device = {
+ .name = atmel_isi,
+ .id = 0,
+ .dev= {
+ .dma_mask = isi_dmamask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = isi_data,
+ },
+ .resource = isi_resources,
+ .num_resources = ARRAY_SIZE(isi_resources),
+};
+
+static int __init isi_set_clk_parent(void)
+{
+ struct clk *pck1;
+ struct clk *plla;
+ int ret;
+
+ /* ISI_MCK is supplied by PCK1 - set parent for it. */
+ pck1 = clk_get(NULL, pck1);
+ if (IS_ERR(pck1)) {
+ printk(KERN_ERR Failed to get PCK1\n);
+ ret = PTR_ERR(pck1);
+ goto err;
+ }
+
+ plla = clk_get(NULL, plla);
+ if (IS_ERR(plla)) {
+ printk(KERN_ERR Failed to get PLLA\n);
+ ret = PTR_ERR(plla);
+ goto err_pck1;
+ }
+ ret = clk_set_parent(pck1, plla);
+ clk_put(plla);
+ if (ret != 0) {
+ printk(KERN_ERR Failed to set PCK1 parent\n);
+ goto err_pck1;
+ }
+ return ret;
+
+err_pck1:
+ clk_put(pck1);
+err:
+ return ret;
+}
+
+void __init at91_add_device_isi(struct isi_platform_data * data)
+{
+ if (!data)
+ return;
+ isi_data = *data;
+
+ at91_set_A_periph(AT91_PIN_PB20, 0);/* ISI_D0 */
+ at91_set_A_periph(AT91_PIN_PB21, 0);/* ISI_D1 */
+ at91_set_A_periph(AT91_PIN_PB22, 0);/* ISI_D2 */
+ at91_set_A_periph(AT91_PIN_PB23, 0);/* ISI_D3 */
+ at91_set_A_periph(AT91_PIN_PB24, 0);/* ISI_D4 */
+ at91_set_A_periph(AT91_PIN_PB25, 0);/* ISI_D5 */
+ at91_set_A_periph(AT91_PIN_PB26, 0);/* ISI_D6 */
+ at91_set_A_periph(AT91_PIN_PB27, 0);/* ISI_D7 */
+ at91_set_A_periph(AT91_PIN_PB28, 0);/* ISI_PCK */
+ at91_set_A_periph(AT91_PIN_PB30, 0);/* ISI_HSYNC */
+ at91_set_A_periph(AT91_PIN_PB29, 0);/* ISI_VSYNC */
+ at91_set_B_periph(AT91_PIN_PB31, 0);/* ISI_MCK (PCK1) */
+
