Re: Question about USB interface index restriction in gspca
On Thu, 15 Sep 2011 23:46:57 +0200 Frank Schäfer fschaefer@googlemail.com wrote: For webcam devices, the interface class is meaningful only when set to USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values. Does that mean that there are devices out in the wild that report for example USB_CLASS_WIRELESS_CONTROLLER for the video interface ??? For video on a particular interface, the subdriver must call the function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit. Hmm, sure, that would work... But wouldn't it be better to improve the interface check and merge the two probing functions ? The subdrivers can decide which interfaces are (not) probed and the gspca core does plausability checks (e.g. bulk/isoc endpoint ? usb class ?). Generally, the first interface is the video device, and the function gspca_dev_probe() works well enough. The function gspca_dev_probe2() is used by only 2 subdrivers and the way to find the correct interface is not easy. For example, the webcam 047d:5003 (subdriver spca1528) has 3 interfaces (class vendor specific). The 1st one has only one altsetting with only one interrupt endpoint, the 2nd one has 8 altsettings, each with only one isochronous endpoint, and the last one has one altsetting with 3 endpoints (bulk in, bulk out and interrupt). At the first glance, it is easy to know the right interface, but writing generic code to handle such webcams seems rather complicated. 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(). Regards. -- 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 4/4] v4l2: add blackfin capture bridge driver
On Fri, 16 Sep 2011, Scott Jiang wrote: 2011/9/16 Sylwester Nawrocki snj...@gmail.com: On 09/15/2011 04:40 AM, Scott Jiang wrote: 2011/9/14 Sylwester Nawrockis.nawro...@samsung.com: On 09/14/2011 09:10 AM, Scott Jiang wrote: + fmt =bcap_formats[i]; + if (mbus_code) + *mbus_code = fmt-mbus_code; + if (bpp) + *bpp = fmt-bpp; + v4l2_fill_mbus_format(mbus_fmt, pixfmt, + fmt-mbus_code); + ret = v4l2_subdev_call(bcap-sd, video, + try_mbus_fmt,mbus_fmt); + if (ret 0) + return ret; + v4l2_fill_pix_format(pixfmt,mbus_fmt); + pixfmt-bytesperline = pixfmt-width * fmt-bpp; + pixfmt-sizeimage = pixfmt-bytesperline + * pixfmt-height; No need to clamp mbus_fmt.width and mbus_fmt.height to some maximum values to prevent allocating huge memory buffers ? Still pixfmt-pixelformat isn't filled. no here pixfmt-pixelformat is passed in + return 0; + } + } + return -EINVAL; I think you should return some default format, rather than giving up when the fourcc doesn't match. However I'm not 100% sure this is the specification requirement. no, there is no default format for bridge driver because it knows nothing about this. all the format info bridge needs ask subdevice. It's the bridge driver that exports a device node and is responsible for setting the default format. It should be possible to start streaming right after opening the device, without VIDIOC_S_FMT, with some reasonable defaults. If, as you say, the bridge knows nothing about formats what the bcap_formats[] array is here for ? accually this array is to convert mbus to pixformat. ppi supports any formats. Ideally it should contain all formats in v4l2, but it is enough at present for our platform. If I find someone needs more, I will add it. So return -EINVAL means this format is out of range, it can't be supported now. Ok, fair enough. I guess you rely on subdev driver to return some supported value through mbus_try_fmt and then the bridge driver must be able to handle this. However it might make sense to validate the resolution in some places to prevent allocating insanely huge buffers, when the sensor subdev misbehaves. all the format info is got from sensor, so it isn't out of control about default format, I think I can only call bcap_g_fmt_vid_cap in probe to get this info. Dose anybody have a better solution? How about doing that when device is opened for the first time ? no, different input and std has different default format, so I think there is no default format is a good choice. app should negotiate format before use. I'm not sure all the v4l2 app will do this step. v4l2 spec only says driver must implement xx ioctl, but it doesn't say app must call xx ioctl. Anyone can tell me how many steps app must call? IIRC, the user shall be able to open a v4l2 device, queue buffers and start streaming - without setting any format. However it could make more sense to try to set format at the subdev and then check how it was adjusted. Not all subdevs might implement g_mbus_fmt op or some might not deliver sane default values. in try_format and s_fmt I have implemented this in bridge driver and all my sensor drivers have implemented relative callback. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Support for H.264/MPEG4 encoder (VPU) in i.MX27.
OK, thank you for your interest, it seems quite clear to me now. However, I'll wait to see what Sascha has to say about this to avoid duplication of work. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] v4l2: add blackfin capture bridge driver
2011/9/13 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Tue, 13 Sep 2011, Scott Jiang wrote:
+
+struct bcap_format {
+ u8 *desc;
+ u32 pixelformat;
+ enum v4l2_mbus_pixelcode mbus_code;
+ int bpp; /* bytes per pixel */
Don't you think you might have to process 12 bpp formats at some point,
like YUV 4:2:0, or NV12? Maybe better calculate in bits from the beginning?
ppi only stores raw format into memory. I wonder if there is sensor
transmit data in planar format?
If planar format only exists in memory, I think I don't need to modify this.
--
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
media_build script fails for kernel 2.6.35 fc14
In tda18271-common.c Error 'vaf' storage size unknown. I do not get this error when building against 2.6.36 mdv2010.2 Please can anyone suggest a work-around? Stu-e -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] v4l2: add blackfin capture bridge driver
On Fri, 16 Sep 2011, Scott Jiang wrote:
2011/9/13 Guennadi Liakhovetski g.liakhovet...@gmx.de:
On Tue, 13 Sep 2011, Scott Jiang wrote:
+
+struct bcap_format {
+ u8 *desc;
+ u32 pixelformat;
+ enum v4l2_mbus_pixelcode mbus_code;
+ int bpp; /* bytes per pixel */
Don't you think you might have to process 12 bpp formats at some point,
like YUV 4:2:0, or NV12? Maybe better calculate in bits from the
beginning?
ppi only stores raw format into memory. I wonder if there is sensor
transmit data in planar format?
If planar format only exists in memory, I think I don't need to modify this.
There are also packed 12-bit formats, like yuv 4:1:1 (V4L2_PIX_FMT_Y41P).
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] preserve video-device parent, set by the driver
On Thursday, September 15, 2011 21:25:17 Guennadi Liakhovetski wrote:
There doesn't seem to be any real requirement to override video-device
parent, set by the driver, even if a v4l2-device is linked to the
video-device, being registered. Let the driver control the parent pointer,
if it needs to.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Marked as RFC, because I'm not sure, that there's no some hidden meaning
in this parent pointer manipulation. However, I haven't been able to find
any.
The idea is that the vdev-parent pointer will disappear once all drivers are
converted to struct v4l2_device. So any driver that already uses v4l2_device
shouldn't touch vdev-parent.
So this patch isn't correct. Adding a comment explaining this probably
wouldn't hurt, though :-)
Regards,
Hans
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 06f1400..728ebaf 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -576,7 +576,7 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
vdev-vfl_type = type;
vdev-cdev = NULL;
if (vdev-v4l2_dev) {
- if (vdev-v4l2_dev-dev)
+ if (vdev-v4l2_dev-dev !vdev-parent)
vdev-parent = vdev-v4l2_dev-dev;
if (vdev-ctrl_handler == NULL)
vdev-ctrl_handler = vdev-v4l2_dev-ctrl_handler;
--
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/5] [media]: OMAP_VOUT: Misc fixes and cleanup patches for 3.2
This set includes patches which do the following: - Fix crash if a we call dssdev-driver-update for a disabled panel. - Fix the issue of not being able to request for a buffer which is larger than what we did the last time. - Fix a small bug in omap_vout_isr() - Remove some redundant code in omap_vout_isr() - Add basic support for DSI panels Note: The patch OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation had been posted in the past, but wasn't commented on. So copied it here again. These patches are based on Tomi's master branch(which is based on 3.1-rc6), and a patches which affects omap_vout and has been posted recently on linux-media (see OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting). This tree can be used as reference: g...@gitorious.org:~boddob/linux-omap-dss2/archit-dss2-clone.git 'for_omap_vout' Archit Taneja (5): OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr OMAP_VOUT: Add support for DSI panels OMAP_VOUT: Don't trigger updates in omap_vout_probe drivers/media/video/omap/omap_vout.c | 199 +- 1 files changed, 99 insertions(+), 100 deletions(-) -- 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/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) {
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) {
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
[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;
+ } else if (0 == fid) {
+ 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;
+ 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;
+ wake_up_interruptible(vout-cur_frm-done);
+ vout-cur_frm = vout-next_frm;
+ }
- /* First save the configuration in ovelray structure */
- ret = omapvid_init(vout, addr);
- if (ret)
- printk(KERN_ERR VOUT_NAME
- failed to set overlay info\n);
- /* Enable the pipeline and set the Go bit */
- ret = omapvid_apply_changes(vout);
- if (ret)
- printk(KERN_ERR
[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;
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
[PATCH 4/5] [media] OMAP_VOUT: Add support for DSI panels
Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update mode.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 20638c3..51cf6c2 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -590,6 +590,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
do_gettimeofday(timevalue);
switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DSI:
case OMAP_DISPLAY_TYPE_DPI:
if (mgr_id == OMAP_DSS_CHANNEL_LCD)
irq = DISPC_IRQ_VSYNC;
--
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
[PATCH 5/5] [media]: OMAP_VOUT: Don't trigger updates in omap_vout_probe
Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:
- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by DSS2. This
leads to a crash at probe.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 51cf6c2..a9fcb1a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2220,14 +2220,6 @@ static int __init omap_vout_probe(struct platform_device
*pdev)
if (ret)
goto probe_err2;
- for (i = 0; i vid_dev-num_displays; i++) {
- struct omap_dss_device *display = vid_dev-displays[i];
-
- if (display-driver-update)
- display-driver-update(display, 0, 0,
- display-panel.timings.x_res,
- display-panel.timings.y_res);
- }
return 0;
probe_err2:
--
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
[linux-media]Re: media_build script fails for kernel 2.6.35 fc14
--- On Fri, 16/9/11, Stuart Morris stuart_mor...@talk21.com wrote: From: Stuart Morris stuart_mor...@talk21.com Subject: media_build script fails for kernel 2.6.35 fc14 To: linux-media@vger.kernel.org Date: Friday, 16 September, 2011, 9:24 In tda18271-common.c Error 'vaf' storage size unknown. I do not get this error when building against 2.6.36 mdv2010.2 Please can anyone suggest a work-around? Stu-e This commit appears to be the culprit: http://git.linuxtv.org/media_tree.git/commitdiff/be85fefecb20b533a2c3f668a345f03f492aeea3 [media] tda18271: Use printk extension %pV -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi,
Sorry for the delayed response.
From: Laurent Pinchart [laurent.pinch...@ideasonboard.com]
Sent: Thursday, September 08, 2011 10:51 PM
To: Ravi, Deepthy
Cc: linux-media@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de;
Hiremath, Vaibhav
Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi,
Thanks for the patch.
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
In order to support TVP5146 (for that matter any video decoder),
it is important to support G/S/ENUM_STD ioctl on /dev/videoX
device node.
Why so ? Shouldn't it be queried on the subdev output pad directly ?
[Deepthy Ravi] Because standard v4l2 application for analog devices will call
these std ioctls on the streaming device node. So it's done on /dev/video to
make the existing apllication work.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/omap3isp/ispvideo.c | 98
++- drivers/media/video/omap3isp/ispvideo.h |
1 +
2 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d5b8236..ff0ffed 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -37,6 +37,7 @@
#include plat/iovmm.h
#include plat/omap-pm.h
+#include media/tvp514x.h
#include ispvideo.h
#include isp.h
@@ -1136,7 +1137,97 @@ isp_video_g_input(struct file *file, void *fh,
unsigned int *input) static int
isp_video_s_input(struct file *file, void *fh, unsigned int input)
{
- return input == 0 ? 0 : -EINVAL;
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ struct v4l2_routing route;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+ subdev = media_entity_to_v4l2_subdev(entity);
+ if (subdev != NULL) {
+ if (input == 0)
+ route.input = INPUT_CVBS_VI4A;
+ else
+ route.input = INPUT_SVIDEO_VI2C_VI1C;
+ route.output = 0;
+ ret = v4l2_subdev_call(subdev, video,
s_routing,
+ route.input, route.output, 0);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int isp_video_querystd(struct file *file, void *fh, v4l2_std_id *a)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+ subdev = media_entity_to_v4l2_subdev(entity);
+ if (subdev != NULL) {
+ ret = v4l2_subdev_call(subdev, video, querystd,
+ a);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+ }
+ }
+
+ vfh-standard.id = *a;
+ return 0;
+}
+
+static int isp_video_g_std(struct file *file, void *fh, v4l2_std_id *norm)
+{
+ struct isp_video_fh *vfh = to_isp_video_fh(fh);
+ struct isp_video *video = video_drvdata(file);
+
+ mutex_lock(video-mutex);
+ *norm = vfh-standard.id;
+ mutex_unlock(video-mutex);
+
+ return 0;
+}
+
+static int isp_video_s_std(struct file *file, void *fh, v4l2_std_id *norm)
+{
+ struct isp_video *video = video_drvdata(file);
+ struct media_entity *entity = video-video.entity;
+ struct media_entity_graph graph;
+ struct v4l2_subdev *subdev;
+ int ret = 0;
+
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph))) {
+ if (media_entity_type(entity) ==
+ MEDIA_ENT_T_V4L2_SUBDEV) {
+
Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
Hi Deepthy, On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com In order to support TVP5146 (for that matter any video decoder), it is important to support G/S/ENUM_STD ioctl on /dev/videoX device node. Why so ? Shouldn't it be queried on the subdev output pad directly ? Because standard v4l2 application for analog devices will call these std ioctls on the streaming device node. So it's done on /dev/video to make the existing apllication work. Existing applications can't work with the OMAP3 ISP (and similar complex embedded devices) without userspace support anyway, either in the form of a GStreamer element or a libv4l plugin. I still believe that analog video standard operations should be added to the subdev pad operations and exposed through subdev device nodes, exactly as done with formats. -- 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 v3 0/3] Conversion of the NOON010PC30 sensor driver to media controller API
Hello, The following patch set converts noon010pc30 camera sensor driver to the subdev pad level operations and user-space V4L2 subdev API. In addition it implements s_stream operation, removes the now unneeded g_chip_ident op and tags the driver as experimental. Changes since v1: - fixed subdev's flags initialization - corrected s_stream handler so the sensor's sleep mode is used for suspending/resuming the output signal - removed g_chip_indent operation handler Changes since v2: - added subdev internal open() operation - moved registers access to s_power or s_stream so the user space calls are supported before/without enabling sensor's power Sylwester Nawrocki (3): noon010pc30: Conversion to the media controller API noon010pc30: Improve s_power operation handling noon010pc30: Remove g_chip_ident operation handler drivers/media/video/Kconfig |2 +- drivers/media/video/noon010pc30.c | 295 ++--- include/media/v4l2-chip-ident.h |3 - 3 files changed, 177 insertions(+), 123 deletions(-) Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] noon010pc30: Improve s_power operation handling
Remove the now unneeded check for the platform data in s_power
handler and the platform data pointer in struct noon010_info.
Also do not reset the configured output resolution and pixel
format when cycling sensor's power.
Add small delay for proper reset signal shape.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/noon010pc30.c | 40 +++-
1 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 115d976..436b1ee 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -132,7 +132,6 @@ 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;
@@ -282,8 +281,10 @@ static int noon010_power_ctrl(struct v4l2_subdev *sd, bool
reset, bool sleep)
u8 reg = sleep ? 0xF1 : 0xF0;
int ret = 0;
- if (reset)
+ if (reset) {
ret = cam_i2c_write(sd, POWER_CTRL_REG, reg | 0x02);
+ udelay(20);
+ }
if (!ret) {
ret = cam_i2c_write(sd, POWER_CTRL_REG, reg);
if (reset !ret)
@@ -561,45 +562,37 @@ static int noon010_set_fmt(struct v4l2_subdev *sd, struct
v4l2_subdev_fh *fh,
return ret;
}
+/* Called with struct noon010_info.lock mutex held */
static int noon010_base_config(struct v4l2_subdev *sd)
{
- struct noon010_info *info = to_noon010(sd);
- int ret;
-
- ret = noon010_bulk_write_reg(sd, noon010_base_regs);
- if (!ret) {
- info-curr_fmt = noon010_formats[0];
- info-curr_win = noon010_sizes[0];
+ int ret = noon010_bulk_write_reg(sd, noon010_base_regs);
+ if (!ret)
ret = noon010_set_params(sd);
- }
if (!ret)
ret = noon010_set_flip(sd, 1, 0);
- /* sync the handler and the registers state */
- v4l2_ctrl_handler_setup(to_noon010(sd)-hdl);
return ret;
}
static int noon010_s_power(struct v4l2_subdev *sd, int on)
{
struct noon010_info *info = to_noon010(sd);
- const struct noon010pc30_platform_data *pdata = info-pdata;
- int ret = 0;
-
- if (WARN(pdata == NULL, No platform data!\n))
- return -ENOMEM;
+ int ret;
+ mutex_lock(info-lock);
if (on) {
ret = power_enable(info);
- if (ret)
- return ret;
- ret = noon010_base_config(sd);
+ if (!ret)
+ ret = noon010_base_config(sd);
} else {
noon010_power_ctrl(sd, false, true);
ret = power_disable(info);
- info-curr_win = NULL;
- info-curr_fmt = NULL;
}
+ mutex_unlock(info-lock);
+
+ /* Restore the controls state */
+ if (!ret on)
+ ret = v4l2_ctrl_handler_setup(info-hdl);
return ret;
}
@@ -750,10 +743,11 @@ static int noon010_probe(struct i2c_client *client,
if (ret)
goto np_err;
- info-pdata = client-dev.platform_data;
info-i2c_reg_page = -1;
info-gpio_nreset = -EINVAL;
info-gpio_nstby= -EINVAL;
+ info-curr_fmt = noon010_formats[0];
+ info-curr_win = noon010_sizes[0];
if (gpio_is_valid(pdata-gpio_nreset)) {
ret = gpio_request(pdata-gpio_nreset, NOON010PC30 NRST);
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] 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.
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
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/noon010pc30.c | 253 -
2 files changed, 164 insertions(+), 91 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..115d976 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
@@ -113,7 +113,6 @@ MODULE_PARM_DESC(debug, Enable module debug trace. Set to
1 to enable.);
struct noon010_format {
enum v4l2_mbus_pixelcode code;
- enum v4l2_colorspace colorspace;
u16 ispctl1_reg;
};
@@ -131,17 +130,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 {
@@ -168,27 +174,11 @@ static const struct noon010_frmsize noon010_sizes[] = {
/* Supported pixel formats. */
static const struct noon010_format noon010_formats[] = {
- {
- .code = V4L2_MBUS_FMT_YUYV8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
- .ispctl1_reg= 0x03,
- }, {
- .code = V4L2_MBUS_FMT_YVYU8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
- .ispctl1_reg= 0x02,
- }, {
- .code = V4L2_MBUS_FMT_VYUY8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
- .ispctl1_reg= 0,
- }, {
- .code = V4L2_MBUS_FMT_UYVY8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
- .ispctl1_reg= 0x01,
- }, {
- .code = V4L2_MBUS_FMT_RGB565_2X8_BE,
- .colorspace = V4L2_COLORSPACE_JPEG,
- .ispctl1_reg= 0x40,
- },
+ { V4L2_MBUS_FMT_YUYV8_2X8, 0x03 },
+ { V4L2_MBUS_FMT_YVYU8_2X8, 0x02 },
+ { V4L2_MBUS_FMT_VYUY8_2X8, 0 },
+ { V4L2_MBUS_FMT_UYVY8_2X8, 0x01 },
+ { V4L2_MBUS_FMT_RGB565_2X8_BE, 0x40},
};
static const struct i2c_regval noon010_base_regs[] = {
@@ -313,6 +303,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 +331,18 @@ static int
[PATCH 3/3 (resend)] noon010pc30: Remove g_chip_ident operation handler
It is now not needed as the sensor identification is done
through the media controller API.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/noon010pc30.c | 10 --
include/media/v4l2-chip-ident.h |3 ---
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 436b1ee..d38b4d4 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -617,15 +617,6 @@ static int noon010_s_stream(struct v4l2_subdev *sd, int on)
return ret;
}
-static int noon010_g_chip_ident(struct v4l2_subdev *sd,
- struct v4l2_dbg_chip_ident *chip)
-{
- struct i2c_client *client = v4l2_get_subdevdata(sd);
-
- return v4l2_chip_ident_i2c_client(client, chip,
- V4L2_IDENT_NOON010PC30, 0);
-}
-
static int noon010_log_status(struct v4l2_subdev *sd)
{
struct noon010_info *info = to_noon010(sd);
@@ -655,7 +646,6 @@ static const struct v4l2_ctrl_ops noon010_ctrl_ops = {
};
static const struct v4l2_subdev_core_ops noon010_core_ops = {
- .g_chip_ident = noon010_g_chip_ident,
.s_power= noon010_s_power,
.g_ctrl = v4l2_subdev_g_ctrl,
.s_ctrl = v4l2_subdev_s_ctrl,
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index 63fd9d3..810a209 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -212,9 +212,6 @@ enum {
/* module sn9c20x: just ident 1 */
V4L2_IDENT_SN9C20X = 1,
- /* Siliconfile sensors: reserved range 10100 - 10199 */
- V4L2_IDENT_NOON010PC30 = 10100,
-
/* module cx231xx and cx25840 */
V4L2_IDENT_CX2310X_AV = 23099, /* Integrated A/V decoder; not in '100 */
V4L2_IDENT_CX23100= 23100,
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] 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
---
This is just a resend as I just previously sent wrong version.
Sorry about the mistake.
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/noon010pc30.c | 224 ++---
2 files changed, 158 insertions(+), 68 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..f91ae14 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 mutex held */
static int power_enable(struct noon010_info
[PATCH 0/3] Add v4l2 subdev driver for S5K6AAFX sensor with embedded ISP
Hello, The following 3 patches add the S5K6AAFX sensor with embedded ISP driver and minor enhancement of v4l2 control API. This is not a complete work and I thought I'd publish this to get some feedback as early as possible. In particular this driver depends on planned R/G/B component gain controls. Sylwester Nawrocki (3): v4l: Extend V4L2_CID_COLORFX control with AQUA effect v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control v4l: Add S5K6AA(FX) sensor driver Documentation/DocBook/media/v4l/controls.xml | 10 +- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1578 ++ drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h|2 + include/media/s5k6aa.h | 51 + 7 files changed, 1645 insertions(+), 4 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h Regards, -- Sylwester Nawrocki Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] 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 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
---
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 f3c6457..aff7989 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 5032226..ec858e7 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
--
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 3/3] v4l: Add v4l2 sub-device driver for S5K6AAFX sensor
This driver support only preview mode and currently uses one predefined user register configuration set, out of 5 preview and 5 capture profiles. V4L2_CID_RED/BLUE_BALANCE ids are used instead of new V4L2_CID_*_GAIN IDs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1578 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1636 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 75bb46f..a512aaf 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -761,6 +761,12 @@ config VIDEO_NOON010PC30 source drivers/media/video/m5mols/Kconfig +config VIDEO_S5K6AA + tristate S5K6AA(FX) 1.3M camera sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + Driver for Samsung S5K6AA(FX) 1.3M camera + config VIDEO_OMAP3 tristate OMAP 3 Camera support (EXPERIMENTAL) select OMAP_IOMMU diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 2723900..b84b10b 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..fbba1b7 --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1578 @@ +/* + * V4L2 driver for Samsung S5K6AAFX SXGA 1/6 1.3M CMOS Image Sensor + * SoC with an Embedded Image Processor + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki s.nawro...@samsung.com + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * + * 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: + * - replace V4L2_CID_*_BALANCE controls with new R/G/B gain controls + * - set/get_crop operations + * - proper colorspace handling + * - more controls + * Possible improvements: + * - add snapshot (device capture) mode support + * - use REG_USER_* registers instead of some REG_P_* + * - eliminate set_power callback from the platform_data struct + */ + +#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 REG_I_OPCLK_4KHZ(n)((n) * 6 + 0x01cc) +#define REG_I_MIN_OUTRATE_4KHZ(n) ((n) * 6 +
[PATCH 1/3] v4l: Extend V4L2_CID_COLORFX control with AQUA effect
Add V4L2_COLORFX_AQUA image effect in the V4L2_CID_COLORFX menu.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +++--
include/linux/videodev2.h|1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 8516401..f3c6457 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -294,8 +294,9 @@ minimum value disables backlight compensation./entry
constantV4L2_COLORFX_SKETCH/constant (5),
constantV4L2_COLORFX_SKY_BLUE/constant (6),
constantV4L2_COLORFX_GRASS_GREEN/constant (7),
-constantV4L2_COLORFX_SKIN_WHITEN/constant (8) and
-constantV4L2_COLORFX_VIVID/constant (9)./entry
+constantV4L2_COLORFX_SKIN_WHITEN/constant (8),
+constantV4L2_COLORFX_VIVID/constant (9) and
+constantV4L2_COLORFX_AQUA/constant (10)./entry
/row
row
entryconstantV4L2_CID_ROTATE/constant/entry
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..5032226 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1144,6 +1144,7 @@ enum v4l2_colorfx {
V4L2_COLORFX_GRASS_GREEN = 7,
V4L2_COLORFX_SKIN_WHITEN = 8,
V4L2_COLORFX_VIVID = 9,
+ V4L2_COLORFX_AQUA = 10,
};
#define V4L2_CID_AUTOBRIGHTNESS(V4L2_CID_BASE+32)
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Trident TV Master (TM5600/TM6000) information
Hi, I have a couple of USB video capture devices based on the Trident TV Master (TM5600/TM6000) chip: an ADS Technologies VideoXpress model USBAV-191, and a Compro Technology VideoMate C200. In the course of (unsuccessfuly) trying to get them to work in Linux, I came across some info which might be of help if anyone else is working on the TM6000 driver. In case this isn't widely-known I'm posting about it here. If you google for tv master technical reference (with quotes), the first result is a PDF with fairly detailed info on the TV Master chips including register names. There is also Linux driver source downloadable from http://linux.terratec.de/video_en.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 0/2] v4l: Add media bus polarity flags for HREF signal
Hello, The following patche adds support for HREF signal polarity configuration through the parallel media bus flags. The second one just converts s5p-fimc driver to use generic flags. Sylwester Nawrocki (2): v4l2: Add the parallel bus HREF signal polarity flags s5p-fimc: Convert to use generic bus polarity flags drivers/media/video/s5p-fimc/fimc-reg.c |8 include/media/s5p_fimc.h|7 +-- include/media/v4l2-mediabus.h | 14 -- 3 files changed, 13 insertions(+), 16 deletions(-) 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/RFC 1/2] v4l2: Add the parallel bus HREF signal polarity flags
HREF is a signal indicating valid data during single line transmission. Add corresponding flags for this signal to the set of mediabus signal polarity flags. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- include/media/v4l2-mediabus.h | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 6114007..41d8771 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -26,12 +26,14 @@ /* Note: in BT.656 mode HSYNC and VSYNC are unused */ #define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 2) #define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 3) -#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 4) -#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 5) -#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 6) -#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 7) -#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 8) -#define V4L2_MBUS_DATA_ACTIVE_LOW (1 9) +#define V4L2_MBUS_HREF_ACTIVE_HIGH (1 4) +#define V4L2_MBUS_HREF_ACTIVE_LOW (1 5) +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 6) +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 7) +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 8) +#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 9) +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 10) +#define V4L2_MBUS_DATA_ACTIVE_LOW (1 11) /* Serial flags */ /* How many lanes the client can use */ -- 1.7.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] s5p-fimc: Convert to use generic bus polarity flags
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park s.nawro...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-reg.c |8
include/media/s5p_fimc.h|7 +--
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c
b/drivers/media/video/s5p-fimc/fimc-reg.c
index 2a1ae51..5543b1b 100644
--- a/drivers/media/video/s5p-fimc/fimc-reg.c
+++ b/drivers/media/video/s5p-fimc/fimc-reg.c
@@ -535,16 +535,16 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc,
cfg = ~(S5P_CIGCTRL_INVPOLPCLK | S5P_CIGCTRL_INVPOLVSYNC |
S5P_CIGCTRL_INVPOLHREF | S5P_CIGCTRL_INVPOLHSYNC);
- if (cam-flags FIMC_CLK_INV_PCLK)
+ if (cam-flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= S5P_CIGCTRL_INVPOLPCLK;
- if (cam-flags FIMC_CLK_INV_VSYNC)
+ if (cam-flags V4L2_MBUS_VSYNC_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLVSYNC;
- if (cam-flags FIMC_CLK_INV_HREF)
+ if (cam-flags V4L2_MBUS_HREF_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLHREF;
- if (cam-flags FIMC_CLK_INV_HSYNC)
+ if (cam-flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
cfg |= S5P_CIGCTRL_INVPOLHSYNC;
writel(cfg, fimc-regs + S5P_CIGCTRL);
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index 2b58904..688fb3f 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -19,11 +19,6 @@ enum cam_bus_type {
FIMC_LCD_WB, /* FIFO link from LCD mixer */
};
-#define FIMC_CLK_INV_PCLK (1 0)
-#define FIMC_CLK_INV_VSYNC (1 1)
-#define FIMC_CLK_INV_HREF (1 2)
-#define FIMC_CLK_INV_HSYNC (1 3)
-
struct i2c_board_info;
/**
@@ -37,7 +32,7 @@ struct i2c_board_info;
* @i2c_bus_num: i2c control bus id the sensor is attached to
* @mux_id: FIMC camera interface multiplexer index (separate for MIPI and ITU)
* @clk_id: index of the SoC peripheral clock for sensors
- * @flags: flags defining bus signals polarity inversion (High by default)
+ * @flags: the parallel bus flags defining signals polarity (V4L2_MBUS_*)
*/
struct s5p_fimc_isp_info {
struct i2c_board_info *board_info;
--
1.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Sep 16 19:00:12 CEST 2011 git hash:2d04c13a507f5a01daa7422cd52250809573cfdb 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: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS 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: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: Asking advice for Camera/ISP driver framework design
On Fri, Sep 16, 2011 at 10:44:00AM +0800, Cliff Cai wrote: On Fri, Sep 16, 2011 at 1:14 AM, Sakari Ailus sakari.ai...@iki.fi wrote: Cliff Cai wrote: Dear guys, Hi Cliff, I'm currently working on a camera/ISP Linux driver project.Of course,I want it to be a V4L2 driver,but I got a problem about how to design the driver framework. let me introduce the background of this ISP(Image signal processor) a little bit. 1.The ISP has two output paths,first one called main path which is used to transfer image data for taking picture and recording,the other one called preview path which is used to transfer image data for previewing. 2.the two paths have the same image data input from sensor,but their outputs are different,the output of main path is high quality and larger image,while the output of preview path is smaller image. Is the ISP able to process images which already are in memory, or is this only from the sensor? yes,it has another DMA to achieve this. If you wish to support this, there would need to be an additional video node. What about the image processing performed by this ISP? Does it e.g. do scaling or cropping? They also should be configured using the V4L2 subdev interface. The OMAP 3 ISP is a good example of this; the technical reference manual is publicly available and the driver is exemplary. Your original message hints such functionality is available. It would be very helpful to know what kind of processing (scaling, pixel format conversion, crop, etc.) is supported by the ISP and what are the exact data paths through it. That defines what the media device graph implemented by the ISP driver should be. If you could show a graphical representation of this, all the better. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
On Thu, Sep 15, 2011 at 12:32:33AM +0530, Hadli, Manjunath wrote: Hello Sakari, I have attached two .ps files with the entity graph details in them, one with RAW input and the other with YCbCr. Hope this is what you were looking for? Hi Manju, This was exactly what I was looking for. Thanks! -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trident TV Master (TM5600/TM6000) information
If you google for tv master technical reference (with quotes), the first result is a PDF with fairly detailed info on the TV Master chips including register names. Thank you Mark, its appreciated. - Steve -- Steven Toth - 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
[Q] video configuration order
Hi all I've been re-thinking (yes, again...) our classical 2-step geometry configuration (let's leave COMPOSE and friends aside for now) per S_FMT and S_CROP, and came to the conclusion, that passing the pixel format with the scaling configuration (S_FMT) is a bad idea. Let's take CAPTURE as an example, and let's use the sensor terminology, even though the same basically applies to other video data sources. Considering just the two geometries - a cropped window on the sensor and an output frame, it is logical to first configure the input, and then the output, because at least on the hardware, where you have to write scaling factors into registers, and not just output sizes, you would have to recalculate those factors, if cropping were to be applied after scaling. In other words, output depends on the input, but not the other way round:-) But S_FMT also passes the pixel format with it, and if you change the pixel format, your cropping capabilities might change too. This might not be very obvious for raw sensors, but it is quite possible for various video data processing devices, like resizers, etc. Therefore, I think, the best order would be: (1) set pixel format (fourcc / mediabus code) (2) set crop (3) set scale I know we cannot change this in V4L2 anymore, so, this might be something for V4L3;-) But what we could do is at least redesign our subdevice APIs to separate the .s_fmt() method into two operations. Below is the specific example, that brought me to this, it might be helpful for those, wishing to even better understand the sources of this problem, others can skip the rest:-) The problem occurred to me, when I was working on the sh_mobile_ceu_camera.c driver. The CEU can scale some pixel formats (several YUV / NV1x formats), and cannot scale others (this actually holds for all bridges), but it can crop anything. As I'm extending soc-camera to work in both V4L2 and MC modes, I want to still be able to configure the sensor behind the CEU from just the classical S_FMT / S_CROP ioctl()s. In this mode I have to decide, where to do the cropping and scaling - on the sensor or on the CEU. One thing I want to avoid, is applying CEU cropping on top of sensor scaling - this gets messy very quickly. So, I only consider CEU cropping, when the sensor is not scaling. Given this, if the user has requested one of pixel codes, that the CEU cannot scale (e.g., a Bayer format), and I have configured sensor 1:1 scaling and crop on the CEU, and then the user issues an S_FMT, I now also lose the ability to ask the sensor to scale, because for that I would have to drop the CEU cropping and the resulting cropping rectangle can change _a lot_ as a result of an S_FMT ioctl(), which, as we know, is not something, that the user expects;-) This leads me to the conclusion, that I also should not do CEU cropping for those, not natively supported by the CEU, formats. This is where we come to cropping behaviour depending on the pixel format and the need to set that format before cropping and before scaling. 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] [media] hdpvr: fix null pointer dereference on error path in hdpvr_probe()
dev-free_buff_list and dev-rec_buff_list are zero initialized after kzalloc of dev. If something goes wrong before INIT_LIST_HEAD for them, goto error leads to call hdpvr_delete() and then to hdpvr_free_buffers(), where the lists are dereferenced. The patch moves INIT_LIST_HEAD before the first possible fail. Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru --- drivers/media/video/hdpvr/hdpvr-core.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/hdpvr/hdpvr-core.c b/drivers/media/video/hdpvr/hdpvr-core.c index 441dacf..fe0a088 100644 --- a/drivers/media/video/hdpvr/hdpvr-core.c +++ b/drivers/media/video/hdpvr/hdpvr-core.c @@ -295,6 +295,10 @@ static int hdpvr_probe(struct usb_interface *interface, goto error; } + /* init video transfer queues */ + INIT_LIST_HEAD(dev-free_buff_list); + INIT_LIST_HEAD(dev-rec_buff_list); + dev-workqueue = 0; /* register v4l2_device early so it can be used for printks */ @@ -319,10 +323,6 @@ static int hdpvr_probe(struct usb_interface *interface, if (!dev-workqueue) goto error; - /* init video transfer queues */ - INIT_LIST_HEAD(dev-free_buff_list); - INIT_LIST_HEAD(dev-rec_buff_list); - dev-options = hdpvr_default_options; if (default_video_input HDPVR_VIDEO_INPUTS) -- 1.7.4.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
