Re: [PATCHv11 0/8] Contiguous Memory Allocator
On Thursday 07 July 2011 00:11:12 Andrew Morton wrote: I could review it and put it in there on a preliminary basis for some runtime testing. But the question in my mind is how different will the code be after the problems which rmk has identified have been fixed? If not very different then that effort and testing will have been worthwhile. If very different or unworkable then it was all for naught. So. Do we have a feeling for the magnitude of the changes which will be needed to fix these things up? As far as I can tell, the changes that we still need are mostly in the ARM specific portion of the series. All architectures that have cache coherent DMA by default (most of the other interesting ones) can just call dma_alloc_from_contiguous() from their dma_alloc_coherent() function without having to do extra work. It's possible that there will be small changes to simplify to the first six patches in order to simplify the ARM port, but I expect them to stay basically as they are, unless someone complains about them. Arnd -- 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
No stream from uvc camera after resume from system sleep
Hi Laurent, I found one problem about the uvc camera in my laptop on 3.0-rc6 and previous kernel: - no stream data received from camera after resume from system sleep - will be ok again if reloading uvcvideo after resume - no odd things are found from usb suspend and pm debug messages Could you give any suggestions about how to debug the issue? thanks, -- Ming Lei -- 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 v8 1/2] Add driver for Aptina Micron mt9p031 sensor.
On 7 July 2011 01:22, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Monday 04 July 2011 13:25:10 javier Martin wrote: Hi, Laurent. How is it going? Is there any chance these changes to be included for next release? We are afraid that changes in the framework may turn the patches useless. I've applied the patch to my tree and I'm working on a couple of fixes. I'll try to finish that ASAP, but I'm quite busy at the moment :-S Ok, thank you Laurent. I feel more comfortable now you have it applied to your tree. Regards. -- 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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
I failed to see what information is provided by the presets name.
If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use index as the preset selection key.
Anyway,
it is too late
for such change. We need to live with that.
Adding the fps solves nothing. Because that still does not give you
specific timings.
You can have 1920x1080P60 that has quite different timings from the
CEA-861 standard
and that may not be supported by a TV.
If you are working with HDMI, then you may want to filter all
supported
presets to
those of the CEA standard.
That's one thing that is missing at the moment: that presets belonging
to a certain
standard get their own range. Since we only do CEA861 right now it
hasn't been an
issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 131
#define DV_PRESET_SPEC(flag) (flag 0xff)
#define DV_PRESET_IS_CEA861 1
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz-7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time.
Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
check what line it wants,
It's not so easy as you think to find the right timings: you have to check
many parameters to be certain you have the right one and not some subtle
variation.
and do a S_DV_PRESET2, just like any other place
where V4L2 defines an ENUM function.
The enum won't change during application runtime, so, they can be stored
if the application would need to switch to other formats latter.
[PATCH v2 0/3] V4L2: OMAP: VOUT: Extend V4L2 support for OMAP4
This patch set addresses following: - Extend omap vout isr for secondary LCD over DPI panel. - Extend omap vout isr for HDMI interface. - DMA map and unmap the V4L2 buffers in qbuf and dqbuf so that they are properly flushed into memory before DMA starts. If this not done we were seeing artifacts on OMAP4. - Minor cleanup to remove unnecessary code. Changes from v1: - Split the patch-set into two so as to separate out NV12 color-format support for OMAP4. - Fixed review comments. Amber Jain (3): V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code. drivers/media/video/omap/omap_vout.c | 61 + 1 files changed, 46 insertions(+), 15 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 v2 1/3] V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface
Extending the omap vout isr handling for:
- secondary lcd over DPI interface,
- HDMI interface.
These are the new interfaces added to OMAP4 DSS.
Signed-off-by: Amber Jain am...@ti.com
---
Changes from v1:
- updated commit message to mention that these changes are specifically
for OMAP4.
drivers/media/video/omap/omap_vout.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 343b50c..6cd3622 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -546,10 +546,20 @@ 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_DPI) {
- if (!(irqstatus DISPC_IRQ_VSYNC))
- goto vout_isr_err;
+ 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:
+ 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;
@@ -573,7 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
ret = omapvid_init(vout, addr);
if (ret)
printk(KERN_ERR VOUT_NAME
- failed to set overlay info\n);
+ failed to set overlay info\n);
/* Enable the pipeline and set the Go bit */
ret = omapvid_apply_changes(vout);
if (ret)
@@ -943,7 +953,7 @@ static int omap_vout_release(struct file *file)
u32 mask = 0;
mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
- DISPC_IRQ_EVSYNC_ODD;
+ DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
vout-streaming = 0;
@@ -1614,7 +1624,8 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
addr = (unsigned long) vout-queued_buf_addr[vout-cur_frm-i]
+ vout-cropped_offset;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_register_isr(omap_vout_isr, vout, mask);
@@ -1664,7 +1675,8 @@ static int vidioc_streamoff(struct file *file, void *fh,
enum v4l2_buf_type i)
return -EINVAL;
vout-streaming = 0;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN | DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
--
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 v2 2/3] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf
Add support to map the buffer using dma_map_single during qbuf which inturn
calls cache flush and unmap the same during dqbuf. This is done to prevent
the artifacts seen because of cache-coherency issues on OMAP4
Signed-off-by: Amber Jain am...@ti.com
---
Changes from v1:
- Changed the definition of address variables to be u32 instead of int.
- Removed extra typedef for size variable.
drivers/media/video/omap/omap_vout.c | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 6cd3622..7d3410a 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/irq.h
#include linux/videodev2.h
+#include linux/dma-mapping.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
@@ -778,6 +779,17 @@ static int omap_vout_buffer_prepare(struct videobuf_queue
*q,
vout-queued_buf_addr[vb-i] = (u8 *)
omap_vout_uservirt_to_phys(vb-baddr);
} else {
+ u32 addr, dma_addr;
+ unsigned long size;
+
+ addr = (unsigned long) vout-buf_virt_addr[vb-i];
+ size = (unsigned long) vb-size;
+
+ dma_addr = dma_map_single(vout-vid_dev-v4l2_dev.dev, (void *)
addr,
+ size, DMA_TO_DEVICE);
+ if (dma_mapping_error(vout-vid_dev-v4l2_dev.dev, dma_addr))
+ v4l2_err(vout-vid_dev-v4l2_dev, dma_map_single
failed\n);
+
vout-queued_buf_addr[vb-i] = (u8 *)vout-buf_phy_addr[vb-i];
}
@@ -1567,15 +1579,28 @@ static int vidioc_dqbuf(struct file *file, void *fh,
struct v4l2_buffer *b)
struct omap_vout_device *vout = fh;
struct videobuf_queue *q = vout-vbq;
+ int ret;
+ u32 addr;
+ unsigned long size;
+ struct videobuf_buffer *vb;
+
+ vb = q-bufs[b-index];
+
if (!vout-streaming)
return -EINVAL;
if (file-f_flags O_NONBLOCK)
/* Call videobuf_dqbuf for non blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
else
/* Call videobuf_dqbuf for blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+
+ addr = (unsigned long) vout-buf_phy_addr[vb-i];
+ size = (unsigned long) vb-size;
+ dma_unmap_single(vout-vid_dev-v4l2_dev.dev, addr,
+ size, DMA_TO_DEVICE);
+ return ret;
}
static int vidioc_streamon(struct file *file, void *fh, enum v4l2_buf_type i)
--
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 v2 3/3] V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
Changes from v1:
- None.
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 7d3410a..548f4cd 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1041,10 +1041,7 @@ static int vidioc_enum_fmt_vid_out(struct file *file,
void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
@@ -1213,10 +1210,7 @@ static int vidioc_enum_fmt_vid_overlay(struct file
*file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
--
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] V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4
V4L2 side changes to add NV12-color format support to OMAP4.
Signed-off-by: Amber Jain am...@ti.com
---
drivers/media/video/omap/omap_vout.c| 107 ++
drivers/media/video/omap/omap_voutdef.h |3 +
2 files changed, 95 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 548f4cd..e80b842 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -140,6 +140,10 @@ const static struct v4l2_fmtdesc omap_formats[] = {
.description = UYVY, packed,
.pixelformat = V4L2_PIX_FMT_UYVY,
},
+ {
+ .description = NV12 - YUV420 format,
+ .pixelformat = V4L2_PIX_FMT_NV12,
+ },
};
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
@@ -188,10 +192,20 @@ static int omap_vout_try_format(struct v4l2_pix_format
*pix)
pix-colorspace = V4L2_COLORSPACE_SRGB;
bpp = RGB32_BPP;
break;
+ case V4L2_PIX_FMT_NV12:
+ pix-colorspace = V4L2_COLORSPACE_JPEG;
+ bpp = 1;
+ break;
}
pix-bytesperline = pix-width * bpp;
+ pix-bytesperline = (pix-bytesperline + PAGE_SIZE - 1)
+ ~(PAGE_SIZE - 1);
+
pix-sizeimage = pix-bytesperline * pix-height;
+ /* :NOTE: NV12 has width bytes per line in both Y and UV sections */
+ if (V4L2_PIX_FMT_NV12 == pix-pixelformat)
+ pix-sizeimage += pix-sizeimage 1;
return bpp;
}
@@ -291,6 +305,7 @@ static int omap_vout_calculate_offset(struct
omap_vout_device *vout)
struct v4l2_pix_format *pix = vout-pix;
int *cropped_offset = vout-cropped_offset;
int ps = 2, line_length = 0;
+ u32 *cropped_uv_offset = vout-cropped_uv_offset;
ovid = vout-vid_info;
@@ -306,11 +321,17 @@ static int omap_vout_calculate_offset(struct
omap_vout_device *vout)
ps = 4;
else if (V4L2_PIX_FMT_RGB24 == pix-pixelformat)
ps = 3;
+ else if (V4L2_PIX_FMT_NV12 == pix-pixelformat)
+ ps = 1;
vout-ps = ps;
*cropped_offset = (line_length * ps) *
crop-top + crop-left * ps;
+
+ if (V4L2_PIX_FMT_NV12 == pix-pixelformat)
+ *cropped_uv_offset = (line_length * ps) *
+ (crop-top 1) + (crop-left ~1) * ps;
}
v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev, %s Offset:%x\n,
@@ -354,6 +375,9 @@ static int video_mode_to_dss_mode(struct omap_vout_device
*vout)
case V4L2_PIX_FMT_BGR32:
mode = OMAP_DSS_COLOR_RGBX32;
break;
+ case V4L2_PIX_FMT_NV12:
+ mode = OMAP_DSS_COLOR_NV12;
+ break;
default:
mode = -EINVAL;
}
@@ -365,7 +389,7 @@ static int video_mode_to_dss_mode(struct omap_vout_device
*vout)
*/
static int omapvid_setup_overlay(struct omap_vout_device *vout,
struct omap_overlay *ovl, int posx, int posy, int outw,
- int outh, u32 addr)
+ int outh, u32 addr, u32 uv_addr)
{
int ret = 0;
struct omap_overlay_info info;
@@ -399,7 +423,15 @@ static int omapvid_setup_overlay(struct omap_vout_device
*vout,
}
ovl-get_overlay_info(ovl, info);
- info.paddr = addr;
+
+ if (addr)
+ info.paddr = addr;
+
+ if (OMAP_DSS_COLOR_NV12 == vout-dss_mode)
+ info.p_uv_addr = uv_addr;
+ else
+ info.p_uv_addr = (u32) NULL;
+
info.vaddr = NULL;
info.width = cropwidth;
info.height = cropheight;
@@ -429,6 +461,9 @@ static int omapvid_setup_overlay(struct omap_vout_device
*vout,
info.pos_y, info.out_width, info.out_height, info.rotation_type,
info.screen_width);
+ v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev, info.puvaddr=%x\n,
+ info.p_uv_addr);
+
ret = ovl-set_overlay_info(ovl, info);
if (ret)
goto setup_ovl_err;
@@ -443,7 +478,7 @@ setup_ovl_err:
/*
* Initialize the overlay structure
*/
-static int omapvid_init(struct omap_vout_device *vout, u32 addr)
+static int omapvid_init(struct omap_vout_device *vout, u32 addr, u32 uv_addr)
{
int ret = 0, i;
struct v4l2_window *win;
@@ -494,7 +529,7 @@ static int omapvid_init(struct omap_vout_device *vout, u32
addr)
}
ret = omapvid_setup_overlay(vout, ovl, posx, posy,
- outw, outh, addr);
+ outw, outh, addr, uv_addr);
if (ret)
goto omapvid_init_err;
}
@@ -528,6 +563,7 @@ static void omap_vout_isr(void *arg, unsigned int
Re: [PATCH 1/3] s5p-csis: Handle all available power supplies
Hi Laurent,
On 07/06/2011 11:47 PM, Laurent Pinchart wrote:
Hi Sylwester,
On Wednesday 06 July 2011 19:13:39 Sylwester Nawrocki wrote:
On the SoCs this driver is intended to support the are three
separate pins to supply the MIPI-CSIS subsystem: 1.1V or 1.2V,
1.8V and power supply for an internal PLL.
This patch adds support for two separate voltage supplies
to cover properly board configurations where PMIC requires
to configure independently each external supply of the MIPI-CSI
device. The 1.8V and PLL supply are assigned a single vdd18
regulator supply as it seems more reasonable than creating
separate regulator supplies for them.
Reported-by: HeungJun Kim riverful@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/mipi-csis.c | 42
+ 1 files changed, 25 insertions(+), 17
deletions(-)
diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c
b/drivers/media/video/s5p-fimc/mipi-csis.c index ef056d6..4a529b4 100644
--- a/drivers/media/video/s5p-fimc/mipi-csis.c
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -81,6 +81,12 @@ static char *csi_clock_name[] = {
};
#define NUM_CSIS_CLOCKS ARRAY_SIZE(csi_clock_name)
+static const char * const csis_supply_name[] = {
+vdd11, /* 1.1V or 1.2V (s5pc100) MIPI CSI suppply */
+vdd18, /* VDD 1.8V and MIPI CSI PLL supply */
+};
+#define CSIS_NUM_SUPPLIES ARRAY_SIZE(csis_supply_name)
+
enum {
ST_POWERED = 1,
ST_STREAMING= 2,
@@ -109,9 +115,9 @@ struct csis_state {
struct platform_device *pdev;
struct resource *regs_res;
void __iomem *regs;
+struct regulator_bulk_data supply[CSIS_NUM_SUPPLIES];
I would have called this supplies, but that's nitpicking. Otherwise the patch
looks good to me.
No problem, I have already renamed it. It seems to make more sense like this.
Thanks for the review!
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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 07-07-2011 08:33, Hans Verkuil escreveu:
On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
I failed to see what information is provided by the presets name.
If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use index as the preset selection key.
Anyway,
it is too late
for such change. We need to live with that.
Adding the fps solves nothing. Because that still does not give you
specific timings.
You can have 1920x1080P60 that has quite different timings from the
CEA-861 standard
and that may not be supported by a TV.
If you are working with HDMI, then you may want to filter all
supported
presets to
those of the CEA standard.
That's one thing that is missing at the moment: that presets belonging
to a certain
standard get their own range. Since we only do CEA861 right now it
hasn't been an
issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 131
#define DV_PRESET_SPEC(flag) (flag 0xff)
#define DV_PRESET_IS_CEA861 1
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs, etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz-7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field of
* interlaced field formats
*/
__u32 reserved[4];
};
#define VIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#define VIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#define VIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time.
Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
check what line it wants,
It's not so easy as you think to find the right timings: you have to check
many parameters to be certain you have the right one and not some subtle
variation.
and do a S_DV_PRESET2, just like any other place
where V4L2 defines an ENUM function.
The enum won't change during application runtime, so, they can be stored
if the application would need to switch to other formats latter.
I think
this is a very desirable feature, particularly for apps running on
embedded
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Thursday, July 07, 2011 15:52:53 Mauro Carvalho Chehab wrote:
Em 07-07-2011 08:33, Hans Verkuil escreveu:
On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
I failed to see what information is provided by the presets name.
If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use index as the preset selection key.
Anyway,
it is too late
for such change. We need to live with that.
Adding the fps solves nothing. Because that still does not give you
specific timings.
You can have 1920x1080P60 that has quite different timings from the
CEA-861 standard
and that may not be supported by a TV.
If you are working with HDMI, then you may want to filter all
supported
presets to
those of the CEA standard.
That's one thing that is missing at the moment: that presets belonging
to a certain
standard get their own range. Since we only do CEA861 right now it
hasn't been an
issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 131
#define DV_PRESET_SPEC(flag) (flag 0xff)
#define DV_PRESET_IS_CEA8611
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs,
etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex.
74.25MHz-7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom
field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom
field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field
of
* interlaced field formats
*/
__u32 reserved[4];
};
#defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time.
Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
check what line it wants,
It's not so easy as you think to find the right timings: you have to check
many parameters to
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Em 06-07-2011 16:59, Marko Ristola escreveu: 06.07.2011 21:17, Devin Heitmueller kirjoitti: On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola marko.rist...@kolumbus.fi wrote: All that said, I believe that you are correct in that the business logic needs to ultimately be decided by the bridge driver, rather than having the dvb/tuner core blindly calling the sleep routines against the tuner and demod drivers without a full understanding of what impact it has on the board as a whole. You wrote it nicely and compactly. What do you think about tracking coarse last busy time rather than figuring out accurate idle time? dvb_frontend.c and V4L side would just poll the device: bridge-wake(). wake() will just store current busy timestamp to the bridge device with coarse accuracy, if subdevices are already at active state. If subdevices are powered off, it will first power them on and resume them, and then store busy timestamp. Bridge device would have a delayed task: Check after 3 minutes: If I haven't been busy for three minutes, I'll go to sleep. I'll suspend the subdevices and power them off. The delayed task would refresh itself: check again after last awake time + 3 minutes. Delayed task could be further developed to support multiple suspend states. There is still an issue: Devices that support FM radio may stay closed, but with radio powered on. This is supported since the beginning by radio application (part of xawtv package). If the device is on radio mode, the only reliable way to power the device off is if the device is muted. IMO, the proper solution is to provide a core resource locking mechanism, that will keep track about what device resources are in usage (tuner, analog audio/video demods, digital demods, sec, radio reception, i2c buses, etc), and some mechanisms like the above that will power the subdevice off when it is not being used for a given amount of time (a Kconfig option can be added so set the time to X minutes or to disable such mechanism, in order to preserve back compatibility). Having a core mechanism helps to assure that it will be properly implemented on all places. This locking mechanism will be controlled by the bridge driver. It is easy to say, but it may be hard to implement, as it may require some changes at both the V4L/DVB core and at the drivers. One special case for the locking mechanisms that may or may not be covered by such core resource locking is the access to the I2C buses. Currently, the DVB, V4L and remote controller stacks may try to use resources behind I2C at the same time. The I2C core has a locking schema, but it works only if a transaction is atomically commanded. So, if it requires multiple I2C transfers, all of them need to be grouped into one i2c xfer call. Complex operations like firmware transfers are protected by the I2C locking, so one driver might be generating RC polling events while a firmware is being transferring, causing it to fail. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3 03/17] [media] DocBook: Use the generic error code page also for MC API
On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote: Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 6ef476a..a7f73c9 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -5,6 +5,11 @@ tgroup cols=2 cs-str; tbody valign=top + !-- Keep it ordered alphabetically -- + row + entryEBADF/entry + entryparameterfd/parameter is not a valid open file descriptor./entry + /row row entryEBUSY/entry entryThe ioctl can't be handled because the device is busy. This is @@ -15,7 +20,16 @@ problem first (typically: stop the stream before retrying)./entry /row row + entryEFAULT/entry + entryparameterfd/parameter is not a valid open file descriptor./entry This seems to be a copy-and-paste error. The original text in media-func-ioctl.xml says this: paraparameterargp/parameter references an inaccessible memory area./para + /row + row entryEINVAL/entry + entryOne or more of the ioctl parameters are invalid. This is a widely widely - widely used +error code. see the individual ioctl requests for actual causes./entry see - See Regards, Hans + /row + row + entryEINVAL or ENOTTY/entry entryThe ioctl is not supported by the driver, actually meaning that the required functionality is not available./entry /row @@ -25,7 +39,7 @@ /row row entryENOSPC/entry - entryOn USB devices, the stream ioctl's can return this error meaning + entryOn USB devices, the stream ioctl's can return this error, meaning that this request would overcommit the usb bandwidth reserved for periodic transfers (up to 80% of the USB bandwidth)./entry /row diff --git a/Documentation/DocBook/media/v4l/media-func-ioctl.xml b/Documentation/DocBook/media/v4l/media-func-ioctl.xml index bda8604..e0ee285 100644 --- a/Documentation/DocBook/media/v4l/media-func-ioctl.xml +++ b/Documentation/DocBook/media/v4l/media-func-ioctl.xml @@ -63,54 +63,10 @@ /refsect1 refsect1 -titleReturn Value/title - -parafunctionioctl()/function returns returnvalue0/returnvalue on -success. On failure, returnvalue-1/returnvalue is returned, and the -varnameerrno/varname variable is set appropriately. Generic error codes -are listed below, and request-specific error codes are listed in the +return-value; +paraRequest-specific error codes are listed in the individual requests descriptions./para paraWhen an ioctl that takes an output or read/write parameter fails, the parameter remains unmodified./para - -variablelist - varlistentry - termerrorcodeEBADF/errorcode/term - listitem - paraparameterfd/parameter is not a valid open file descriptor. - /para - /listitem - /varlistentry - varlistentry - termerrorcodeEFAULT/errorcode/term - listitem - paraparameterargp/parameter references an inaccessible memory - area./para - /listitem - /varlistentry - varlistentry - termerrorcodeEINVAL/errorcode/term - listitem - paraThe parameterrequest/parameter or the data pointed to by - parameterargp/parameter is not valid. This is a very common error - code, see the individual ioctl requests listed in - xref linkend=media-user-func / for actual causes./para - /listitem - /varlistentry - varlistentry - termerrorcodeENOMEM/errorcode/term - listitem - paraInsufficient kernel memory was available to complete the - request./para - /listitem - /varlistentry - varlistentry - termerrorcodeENOTTY/errorcode/term - listitem - paraparameterfd/parameter is not associated with a character - special device./para - /listitem - /varlistentry -/variablelist /refsect1 /refentry diff --git a/Documentation/DocBook/media/v4l/media-ioc-device-info.xml b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml index 1f32373..2ce5214 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-device-info.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-device-info.xml @@ -127,7 +127,6 @@ /refsect1 refsect1 -titleReturn value/title -paraThis function doesn't return specific error codes./para +return-value; /refsect1 /refentry -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to
Re: [PATCH RFCv3 00/17] Error code fixes and return -ENOTTY for no-ioctl
On Wednesday, July 06, 2011 20:04:04 Mauro Carvalho Chehab wrote: This patch series contain some fixes on how error codes are handled at the media API's. It consists on two parts. The first part have the DocBook changes: - Create a generic errno xml file, used by all media API's (V4L, MC, LIRC and DVB); - Move the generic errorcodes to the new file; - Removes code duplication/inconsistency along the several API files; - Removes two bogus undefined errorcodes: EINTERNAL/ENOSIGNAL from the ioctl's. The second part have the code changes: - Some fixes on a few drivers that use EFAULT on a wrong way, and not compliant with the DVB API; - The usage of ENOTTY meaning that no ioctl is implemented. Except for patch 03/17 (see my comments there): Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans TODO: - Some DVB open/close API description are mentioning the non-existent EINTERNAL error code; - firedtv driver needs to be fixed with respect to the usage of -EFAULT (Stefan c/c). - The DVB driver uses a couple different error codes to mean that an ioctl is not implemented: ENOSYS and EOPNOTSUPP. The last one is used on most places. It would be great to standardize this error code as well, but further study is required. - There are still several error codes not present at gen-errors.xml. A match between what's currently used at the drivers and the API is needed. Probably, both code and DocBook needs to be changed, as, on several cases, different drivers return different error codes for the same error. Mauro Carvalho Chehab (17): [media] DocBook: Add a chapter to describe media errors [media] DocBook: Use the generic ioctl error codes for all V4L ioctl's [media] DocBook: Use the generic error code page also for MC API [media] DocBook/media-ioc-setup-link.xml: Remove EBUSY [media] DocBook: Remove V4L generic error description for ioctl() [media] DocBook: Add an error code session for LIRC interface [media] DocBook: Add return error codes to LIRC ioctl session [media] siano: bad parameter is -EINVAL and not -EFAULT [media] nxt6000: i2c bus error should return -EIO [media] DVB: Point to the generic error chapter [media] DocBook/audio.xml: Remove generic errors [media] DocBook/demux.xml: Remove generic errors [media] dvb-bt8xx: Don't return -EFAULT when a device is not found [media] DocBook/dvb: Use generic descriptions for the frontend API [media] DocBook/dvb: Use generic descriptions for the video API [media] v4l2 core: return -ENOTTY if an ioctl doesn't exist [media] return -ENOTTY for unsupported ioctl's at legacy drivers Documentation/DocBook/.gitignore |2 + Documentation/DocBook/media/Makefile | 42 ++- Documentation/DocBook/media/dvb/audio.xml | 372 +-- Documentation/DocBook/media/dvb/ca.xml |6 +- Documentation/DocBook/media/dvb/demux.xml | 121 +- Documentation/DocBook/media/dvb/dvbproperty.xml| 23 +- Documentation/DocBook/media/dvb/frontend.xml | 487 +--- Documentation/DocBook/media/dvb/video.xml | 418 + Documentation/DocBook/media/v4l/func-ioctl.xml | 72 +--- Documentation/DocBook/media/v4l/gen-errors.xml | 77 +++ .../DocBook/media/v4l/lirc_device_interface.xml|4 +- .../DocBook/media/v4l/media-func-ioctl.xml | 47 +-- .../DocBook/media/v4l/media-ioc-device-info.xml|3 +- .../DocBook/media/v4l/media-ioc-setup-link.xml |9 - Documentation/DocBook/media/v4l/v4l2.xml |2 + Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 13 +- .../DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml | 11 +- .../DocBook/media/v4l/vidioc-dbg-g-register.xml| 17 - Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 10 +- .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 11 +- .../media/v4l/vidioc-enum-frameintervals.xml | 11 - .../DocBook/media/v4l/vidioc-enum-framesizes.xml | 11 - .../DocBook/media/v4l/vidioc-enumaudio.xml | 12 +- .../DocBook/media/v4l/vidioc-enumaudioout.xml | 12 +- Documentation/DocBook/media/v4l/vidioc-g-audio.xml | 18 +- .../DocBook/media/v4l/vidioc-g-audioout.xml| 18 +- Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 17 - .../DocBook/media/v4l/vidioc-g-dv-preset.xml | 12 +- .../DocBook/media/v4l/vidioc-g-dv-timings.xml | 11 +- .../DocBook/media/v4l/vidioc-g-enc-index.xml | 17 - Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml | 19 +- Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | 20 +- Documentation/DocBook/media/v4l/vidioc-g-input.xml | 19 +- .../DocBook/media/v4l/vidioc-g-jpegcomp.xml| 17 - .../DocBook/media/v4l/vidioc-g-output.xml | 18 +-
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 07-07-2011 11:58, Hans Verkuil escreveu:
On Thursday, July 07, 2011 15:52:53 Mauro Carvalho Chehab wrote:
Em 07-07-2011 08:33, Hans Verkuil escreveu:
On Wednesday, July 06, 2011 21:39:46 Mauro Carvalho Chehab wrote:
Em 06-07-2011 09:14, Hans Verkuil escreveu:
Em 06-07-2011 08:31, Hans Verkuil escreveu:
Em 05-07-2011 10:20, Hans Verkuil escreveu:
I failed to see what information is provided by the presets name.
If
this were removed
from the ioctl, and fps would be added instead, the API would be
clearer. The only
adjustment would be to use index as the preset selection key.
Anyway,
it is too late
for such change. We need to live with that.
Adding the fps solves nothing. Because that still does not give you
specific timings.
You can have 1920x1080P60 that has quite different timings from the
CEA-861 standard
and that may not be supported by a TV.
If you are working with HDMI, then you may want to filter all
supported
presets to
those of the CEA standard.
That's one thing that is missing at the moment: that presets belonging
to a certain
standard get their own range. Since we only do CEA861 right now it
hasn't been an
issue, but it will.
I prepared a long email about that, but then I realized that we're
investing our time into
something broken, at the light of all DV timing standards. So, I've
dropped it and
started from scratch.
From what I've got, there are some hardware that can only do a limited
set
of DV timings.
If this were not the case, we could simply just use the
VIDIOC_S_DV_TIMINGS/VIDIOC_G_DV_TIMINGS,
and put the CEA 861 and VESA timings into some userspace library.
In other words, the PRESET API is meant to solve the case where
hardware
only support
a limited set of frequencies, that may or may not be inside the CEA
standard.
Let's assume we never added the current API, and discuss how it would
properly fulfill
the user needs. An API that would likely work is:
struct v4l2_dv_enum_preset2 {
__u32 index;
__u8 name[32]; /* Name of the preset timing */
struct v4l2_fract fps;
#define DV_PRESET_IS_PROGRESSIVE 131
#define DV_PRESET_SPEC(flag) (flag 0xff)
#define DV_PRESET_IS_CEA8611
#define DV_PRESET_IS_DMT 2
#define DV_PRESET_IS_CVF 3
#define DV_PRESET_IS_GTF 4
#define DV_PRESET_IS_VENDOR_SPECIFIC 5
__u32 flags; /* Interlaced/progressive, DV specs,
etc */
__u32 width; /* width in pixels */
__u32 height; /* height in lines */
__u32 polarities; /* Positive or negative polarity */
__u64 pixelclock; /* Pixel clock in HZ. Ex.
74.25MHz-7425 */
__u32 hfrontporch;/* Horizpontal front porch in pixels */
__u32 hsync; /* Horizontal Sync length in pixels */
__u32 hbackporch; /* Horizontal back porch in pixels */
__u32 vfrontporch;/* Vertical front porch in pixels */
__u32 vsync; /* Vertical Sync length in lines */
__u32 vbackporch; /* Vertical back porch in lines */
__u32 il_vfrontporch; /* Vertical front porch for bottom
field of
* interlaced field formats
*/
__u32 il_vsync; /* Vertical sync length for bottom
field of
* interlaced field formats
*/
__u32 il_vbackporch; /* Vertical back porch for bottom field
of
* interlaced field formats
*/
__u32 reserved[4];
};
#defineVIDIOC_ENUM_DV_PRESETS2 _IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2 _IOWR('V', 84, u32 index)
#defineVIDIOC_G_DV_PRESET2 _IOWR('V', 85, u32 index)
Such preset API seems to work for all cases. Userspace can use any DV
timing
information to select the desired format, and don't need to have a
switch
for
a preset macro to try to guess what the format actually means. Also,
there's no
need to touch at the API spec every time a new DV timeline is needed.
Also, it should be noticed that, since the size of the data on the
above
definitions
are different than the old ones, _IO macros will provide a different
magic
number,
so, adding these won't break the existing API.
So, I think we should work on this proposal, and mark the existing one
as
deprecated.
This proposal makes it very hard for applications to directly select a
format like 720p50 because the indices can change at any time.
Why? All the application needs to do is to call VIDIOC_ENUM_DV_PRESETS2,
check what line it wants,
It's not so easy as you think to find the right timings: you have to check
many parameters to be certain you have the right one and not some subtle
variation.
and do a
Re: [RFC PATCH] poll: add poll_requested_events() function
On Fri, 1 Jul 2011 15:37:30 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
The change makes sense to me, FWIW. One bit of trivia I noticed while
looking at it:
@@ -796,7 +792,7 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
* All waiters have already been registered, so don't provide
* a poll_table to them on the next loop iteration.
*/
- pt = NULL;
+ pt-qproc = NULL;
if (!count) {
count = wait-error;
if (signal_pending(current))
The comment at the beginning of this hunk is no longer accurate since the
poll_table is, indeed, still being supplied. The previous comment in the
same function:
/*
* Fish for events. If we found one, record it
* and kill the poll_table, so we don't
* needlessly register any other waiters after
* this. They'll get immediately deregistered
* when we break out and return.
*/
Could also use tweaking.
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: [RFC PATCH] poll: add poll_requested_events() function
On Thursday, July 07, 2011 18:42:55 Jonathan Corbet wrote:
On Fri, 1 Jul 2011 15:37:30 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
The change makes sense to me, FWIW. One bit of trivia I noticed while
looking at it:
@@ -796,7 +792,7 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
* All waiters have already been registered, so don't provide
* a poll_table to them on the next loop iteration.
*/
- pt = NULL;
+ pt-qproc = NULL;
if (!count) {
count = wait-error;
if (signal_pending(current))
The comment at the beginning of this hunk is no longer accurate since the
poll_table is, indeed, still being supplied. The previous comment in the
same function:
/*
* Fish for events. If we found one, record it
* and kill the poll_table, so we don't
* needlessly register any other waiters after
* this. They'll get immediately deregistered
* when we break out and return.
*/
Could also use tweaking.
Indeed! I'll make an RFCv3 tomorrow fixing this.
Thanks for looking at this!
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3 03/17] [media] DocBook: Use the generic error code page also for MC API
Em 07-07-2011 12:29, Hans Verkuil escreveu: On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote: Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 6ef476a..a7f73c9 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -5,6 +5,11 @@ tgroup cols=2 cs-str; tbody valign=top +!-- Keep it ordered alphabetically -- + row +entryEBADF/entry +entryparameterfd/parameter is not a valid open file descriptor./entry + /row row entryEBUSY/entry entryThe ioctl can't be handled because the device is busy. This is @@ -15,7 +20,16 @@ problem first (typically: stop the stream before retrying)./entry /row row +entryEFAULT/entry +entryparameterfd/parameter is not a valid open file descriptor./entry This seems to be a copy-and-paste error. The original text in media-func-ioctl.xml says this: paraparameterargp/parameter references an inaccessible memory area./para Ah, yes. Anyway, a latter patch changes it to: entryEFAULT/entry entryThere was a failure while copying data from/to userspace./entry /row referencing a parameter name there is a bad thing anyway, as this is now at the common ioctl error code. Instead of just using a posix-like error code: EFAULT Bad address (POSIX.1) I opted to use a more valuable description, explaining the reason for such error, e. g. that there was a failure at the data copy from/to userspace. It may be better to change it to: entryEFAULT/entry entryThere was a failure while copying data from/to userspace, probably caused by an invalid pointer reference./entry I think I'll add the above description at the latter patch. I was intending to add there the other possible error causes found at V4L/DVB API's and drivers, but the changes I did took me a longer time than I was expecting originally. I'll eventually do that when I have more time. It would be really great if we could find some volunteer to help syncing the media API specs with the code. + /row + row entryEINVAL/entry +entryOne or more of the ioctl parameters are invalid. This is a widely widely - widely used + error code. see the individual ioctl requests for actual causes./entry see - See Fixed. 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 RFCv3 03/17] [media] DocBook: Use the generic error code page also for MC API
On Thursday, July 07, 2011 19:15:24 Mauro Carvalho Chehab wrote: Em 07-07-2011 12:29, Hans Verkuil escreveu: On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote: Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 6ef476a..a7f73c9 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -5,6 +5,11 @@ tgroup cols=2 cs-str; tbody valign=top + !-- Keep it ordered alphabetically -- + row + entryEBADF/entry + entryparameterfd/parameter is not a valid open file descriptor./entry + /row row entryEBUSY/entry entryThe ioctl can't be handled because the device is busy. This is @@ -15,7 +20,16 @@ problem first (typically: stop the stream before retrying)./entry /row row + entryEFAULT/entry + entryparameterfd/parameter is not a valid open file descriptor./entry This seems to be a copy-and-paste error. The original text in media-func-ioctl.xml says this: paraparameterargp/parameter references an inaccessible memory area./para Ah, yes. Anyway, a latter patch changes it to: OK, I missed that. It was a bit confusing to review. entryEFAULT/entry entryThere was a failure while copying data from/to userspace./entry /row referencing a parameter name there is a bad thing anyway, as this is now at the common ioctl error code. Instead of just using a posix-like error code: EFAULT Bad address (POSIX.1) I opted to use a more valuable description, explaining the reason for such error, e. g. that there was a failure at the data copy from/to userspace. It may be better to change it to: entryEFAULT/entry entryThere was a failure while copying data from/to userspace, probably caused by an invalid pointer reference./entry I think I'll add the above description at the latter patch. I was intending to add there the other possible error causes found at V4L/DVB API's and drivers, but the changes I did took me a longer time than I was expecting originally. I'll eventually do that when I have more time. It would be really great if we could find some volunteer to help syncing the media API specs with the code. + /row + row entryEINVAL/entry + entryOne or more of the ioctl parameters are invalid. This is a widely widely - widely used + error code. see the individual ioctl requests for actual causes./entry see - See Fixed. OK, with these changes you have my Acked-by: Hans Verkuil hans.verk...@cisco.com as well for this patch. Just for my understanding: do you plan on merging this for 3.1? I have no objection to that. Together with the querycap version changes it is easy to add compatibility support to libv4l should that be necessary. I'm not convinced there won't be any fallout from this change, but at least there is a decent way of working around it if needed. And there is no doubt that -ENOTTY is a much better return code. When this is merged I'll modify v4l2-compliance, v4l2-ctl (if necessary) and qv4l2. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv3 03/17] [media] DocBook: Use the generic error code page also for MC API
Em 07-07-2011 14:28, Hans Verkuil escreveu: On Thursday, July 07, 2011 19:15:24 Mauro Carvalho Chehab wrote: Em 07-07-2011 12:29, Hans Verkuil escreveu: On Wednesday, July 06, 2011 20:03:52 Mauro Carvalho Chehab wrote: Instead of having their own generic error codes at the MC API, move its section to the generic one and be sure that all media ioctl's will point to it. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 6ef476a..a7f73c9 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -5,6 +5,11 @@ tgroup cols=2 cs-str; tbody valign=top + !-- Keep it ordered alphabetically -- + row + entryEBADF/entry + entryparameterfd/parameter is not a valid open file descriptor./entry + /row row entryEBUSY/entry entryThe ioctl can't be handled because the device is busy. This is @@ -15,7 +20,16 @@ problem first (typically: stop the stream before retrying)./entry /row row + entryEFAULT/entry + entryparameterfd/parameter is not a valid open file descriptor./entry This seems to be a copy-and-paste error. The original text in media-func-ioctl.xml says this: paraparameterargp/parameter references an inaccessible memory area./para Ah, yes. Anyway, a latter patch changes it to: OK, I missed that. It was a bit confusing to review. Yeah. Documentation patches are harder to handle than normal patches. I did several changes on the existing patches, but perfecting each patch individually will probably take forever. entryEFAULT/entry entryThere was a failure while copying data from/to userspace./entry /row referencing a parameter name there is a bad thing anyway, as this is now at the common ioctl error code. Instead of just using a posix-like error code: EFAULT Bad address (POSIX.1) I opted to use a more valuable description, explaining the reason for such error, e. g. that there was a failure at the data copy from/to userspace. It may be better to change it to: entryEFAULT/entry entryThere was a failure while copying data from/to userspace, probably caused by an invalid pointer reference./entry I think I'll add the above description at the latter patch. I was intending to add there the other possible error causes found at V4L/DVB API's and drivers, but the changes I did took me a longer time than I was expecting originally. I'll eventually do that when I have more time. It would be really great if we could find some volunteer to help syncing the media API specs with the code. + /row + row entryEINVAL/entry + entryOne or more of the ioctl parameters are invalid. This is a widely widely - widely used + error code. see the individual ioctl requests for actual causes./entry see - See Fixed. OK, with these changes you have my Acked-by: Hans Verkuil hans.verk...@cisco.com as well for this patch. Thanks! Just for my understanding: do you plan on merging this for 3.1? I have no objection to that. Together with the querycap version changes it is easy to add compatibility support to libv4l should that be necessary. I'm not convinced there won't be any fallout from this change, but at least there is a decent way of working around it if needed. And there is no doubt that -ENOTTY is a much better return code. Yes, that's my plan. Having both patch series merged together seemed a good idea to me, as it becomes easier for applications to benefit of that. When this is merged I'll modify v4l2-compliance, v4l2-ctl (if necessary) and qv4l2. OK. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Hi Mauro, Hans,
I am really surprised by the havoc caused by the little 2-line patch.
Let me sum up what I (don't) like in Hans' and Mauro's approaches:
Hans approach:
- extend v4l2_enum_dv_preset with fps and flags fields,
- allow enumerating presets by both index and preset code
- add standard to macro names for presets
Pros:
- backward compatible with existing api
- very simple and effective. Setting desired preset using only 2 lines
of code
- easy to add unfortunate 1080p59_94
- easy to differentiate 1080p59_94 from 1080p60 using VIDIOC_ENUM_DV_PRESET
Cons:
- number of existing macros must increase extensionally with number of
features. Height, progressiveness, frequency are already present.
Standard family is added in Hans' RFC. Some presets involve width.
Therefore multiple holes are expected making usage of macros very
unreliable.
- it is not possible to use VIDIOC_S_DV_PRESET to handle case when
application just wants a preset that has 720 height. The application has
to enumerate all existing/possible presets (number of possible
combinations may be large) to find a preset that suits to the
application's needs.
- unnecessary redundancy, preset is nothing more than a standardized index
Mauro's approach:
- enumerate all possible presets using VIDIOC_ENUM_DV_PRESETS2
- choose suitable preset using index field from
Pros:
- consistency: preset can only be addressed by index field,
- no preset macros
Cons:
- structure v4l2_dv_enum_preset2 contains BT.656/BT.1120 timing related
data, the structure should be more general. Most application would not
use timing fields, so maybe there is no need of adding them to the
structure.
- applications still has to enumerate through all possible combinations
to find a suitable preset
- not compatible with existing API, two way to configure DV hardware
I propose following requirements for DV preset api basing on pros and
cons from overmentioned approaches.
- an application should be able to choose a preset with desired
parameters using single ioctl call
- preset should be accessed using single key. I prefer to use index as a
key because it gives more flexibility to a driver.
- compatible with existing api as much as possible
What do you think about approach similar to S_FMT?
Please look at the code below.
struct v4l2_dv_preset2 {
u16 width;
u16 height;
v4l2_fract fps;
u32 flags; /* progressiveness, standard hints, rounding constraints */
u32 reserved[];
};
/* Values for the standard field */
#define V4L2_DV_BT_656_1120 0 /* BT.656/1120 timing type */
struct v4l2_enum_dv_preset2 {
u32 index;
char name[32];
struct v4l2_dv_preset2 preset;
struct v4l2_dv_timings timings; /* to be removed ? */
u32 reserved[];
};
#defineVIDIOC_ENUM_DV_PRESETS2_IOWR('V', 83, struct
v4l2_dv_enum_preset2)
#defineVIDIOC_S_DV_PRESET2_IOWR('V', 84, struct v4l2_dv_preset2)
#defineVIDIOC_G_DV_PRESET2_IOWR('V', 85, struct v4l2_dv_preset2)
#defineVIDIOC_TRY_DV_PRESET2_IOWR('V', 86, struct v4l2_dv_preset2)
To set a mode with height 720 lines the applications would execute code
below:
struct v4l2_dv_preset2 preset = {.height = 720 };
ioctl(fd, VIDIOC_S_DV_PRESET2, preset);
The preset is selected using the most interesting features like
width/height/frequency and progressiveness.
The driver would find the preset with vertical resolution as close as
possible to 720.
The width and fps is zero so driver is free to choose suitable/default ones.
The field flags may contain hind about choosing preset that belong to
specific DV standard family.
I do not feel competent in the field of DV standard. Could give me more
ideas about flags?
The flags could contain constraint bits similar to ones presented in
SELECTION api.
Maybe structures v4l2_dv_preset and v4l2_enum_dv_presets could be
utilized for purpose of presented api.
Maybe using some union/structure align magic it would be possible to
keep binary compatibility with existing programs.
For now, I have removed unfortunate 1080P59_94 format from S5P-TV driver.
I would be very happy if the driver was merged into 3.1.
I think that it would be not possible due to 1080p59_94 issue.
The driver did not lose much of its functionality because it still
supports 1080p60.
Moreover, adding 1080p59_94 is relatively trivial.
I hope you find this information useful.
Regards,
Tomasz Stanislawski
--
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: SV: SV: omap3isp - H3A auto white balance
Hi Jonathan, if you change the mt9v034_set_chip_control in mt9v034_configure to.. ret = mt9v034_set_chip_control(mt9v034, MT9V034_CHIP_CONTROL_RESERVED, 0); // Clear bit 9 for normal operation ..it will start streaming as you startup the driver. You could consider clearing all bits in mt9v034_configure and in mt9v034_s_stream you set the correct bits for streaming. Look at Laurents mt9v032 driver code. Regards, Daniel On Thu, 2011-07-07 at 17:19 +0100, Jonathan Cameron wrote: Hi Daniel, Thanks for the driver. Couple of quick queries. What do I need for streaming mode (and does this work well for you?) If I can get this working, I'm happy to pick up the job of patch cleanup for you as a thank you. Jonathan Hello again, Hi Daniel, On Wednesday 01 June 2011 10:49:43 Daniel Lundborg wrote: On Tuesday 31 May 2011 12:07:08 Daniel Lundborg wrote: [snip] Any chance you will submit the driver for inclusion in the kernel? Yes if there is an interest in it. I can create a patch from your omap3isp-next-sensors tree if you want. That would be nice, thank you. Here's the patch: [snip] The patch is corrupted as your mailer wraps lines. Could you please fix that, or send it as an attachement ? I will add it as an attachment to this email. Please also include a commit message with your SoB line. -- Regards, Laurent Pinchart I'm not sure how to add a commit message to the patch. Regards, Daniel Lundborg -- 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
[no subject]
unsubscribe -- 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: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Hi. IMO, your thoughts about core resource locking mechanism sound good. I say here some thoughts and examples how the resource locking mechanism might work. IMHO, It's good enough now if we are heading to a solution. At least I would not alone find a proper concept. 07.07.2011 18:14, Mauro Carvalho Chehab kirjoitti: Em 06-07-2011 16:59, Marko Ristola escreveu: 06.07.2011 21:17, Devin Heitmueller kirjoitti: On Wed, Jul 6, 2011 at 1:53 PM, Marko Ristola marko.rist...@kolumbus.fi wrote: IMO, the proper solution is to provide a core resource locking mechanism, that will keep track about what device resources are in usage (tuner, analog audio/video demods, digital demods, sec, radio reception, i2c buses, etc), and some mechanisms like the above that will power the subdevice off when it is not being used for a given amount of time (a Kconfig option can be added so set the time to X minutes or to disable such mechanism, in order to preserve back compatibility). One special case for the locking mechanisms that may or may not be covered by such core resource locking is the access to the I2C buses. Currently, the DVB, V4L and remote controller stacks may try to use resources behind I2C at the same time. The I2C core has a locking schema, but it works only if a transaction is atomically commanded. So, if it requires multiple I2C transfers, all of them need to be grouped into one i2c xfer call. Complex operations like firmware transfers are protected by the I2C locking, so one driver might be generating RC polling events while a firmware is being transferring, causing it to fail. A generic locking schema could have shared/exclusive locks by name (device name, pointer ?). A generic resource set of named locks could contain these locks. Firmware load would take an exclusive lock on I2C master for the whole transfer. RC polling would take a shared lock on I2C master and an exclusive lock on RC UART device. Or if there is no need to share I2C device, RC polling would just take exclusive lock on I2C Master. If I2C bus must be quiesced for 10ms after frontend's tuning action, I2C master exclusive lock could be held 10ms after last I2C transfer. i2c/bridge1 state should be protected if the frontend is behind an I2C bridge. The existing I2C xfer mutex would be as it is now: it is a lower level lock, no regressions to come. Taking a shared lock of tuner_power_switch would mark that the device must not be turned off. While holding the shared lock, no deferred watch would be needed. While releasing tuner_power_switch lock, usage timestamp on that name should be updated. If there are no more tuner_power_switch holders, delayed task could be activated and run after 3 minutes to power the device off if needed. Bridge drivers that don't have full runtime power saving support, would not introduce a callback which a delayed task would run to turn power off / on. Regards, Mauro IMO, suspend / resume code must be a separate thing. We might want to suspend the laptop while watching a DVB channel. We don't want to have runtime power management active while watching a DVB channel. Suspend quiesces the device possibly in one phase. It needs to have the device in a good state before suspending: take an exclusive I2C Master lock before going to suspend. While resuming, release I2C Master lock. So even though these details are incomplete, suspend/resume could perhaps be integrated with the generic advanced locking scheme. Regards, Marko -- 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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Jul 7 19:00:41 CEST 2011 git hash:df6aabbeb2b8799d97f3886fc994c318bc6a6843 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 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-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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
On Monday 04 July 2011 18:41:10 Hans von Marwijk wrote: In which GIT or HG repository can I find these patches. They are not in any of my public repositories yet. If you need a working driver, I recommend one of the following repositories: For kernel = 2.6.32: http://linuxtv.org/hg/~endriss/media_build_experimental For kernel 2.6.36, you might also use http://linuxtv.org/hg/~endriss/ngene-octopus-test They are equivalent and well tested. The patchsets contain the same code, except that the code was reformatted for kernel codingstyle. There is a small risk that this processing introduced bugs. ;-( CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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:v4l-dvb/for_v3.1] [media] rc: call input_sync after scancode reports
On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] rc: call input_sync after scancode reports Author: Jarod Wilson ja...@redhat.com Date:Thu Jun 23 10:40:55 2011 -0300 Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. Hmm, any chance to get it into 3.0? -- Dmitry -- 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:v4l-dvb/for_v3.1] [media] rc: call input_sync after scancode reports
On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] rc: call input_sync after scancode reports Author: Jarod Wilson ja...@redhat.com Date: Thu Jun 23 10:40:55 2011 -0300 Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. Hmm, any chance to get it into 3.0? Its actually already there, I think the branch was just mis-named, or something along those lines. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98c32bcded0e249fd48726930ae9f393e0e318b4 -- Jarod Wilson ja...@wilsonet.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] [staging] lirc_serial: allocate irq at init time
On Tue, Jul 5, 2011 at 1:21 PM, Greg KH g...@kroah.com wrote: On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote: There's really no good reason not to just grab the desired IRQ at driver init time, instead of every time the lirc device node is accessed. This also improves the speed and reliability with which a serial transmitter can operate, as back-to-back transmission attempts (i.e., channel change to a multi-digit channel) don't have to spend time acquiring and then releasing the IRQ for every digit, sometimes multiple times, if lircd has been told to use the min_repeat parameter. CC: de...@driverdev.osuosl.org Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/staging/lirc/lirc_serial.c | 44 +-- 1 files changed, 21 insertions(+), 23 deletions(-) This patch doesn't apply to the staging-next branch, care to respin it and resend it so I can apply it? This actually got merged into mainline a few days ago via the media tree. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c4b0afee3c1730cf9b0f6ad21729928d23d3918e Do you want me to take a look at what's in staging-next and fix that up to apply on top of the above? -- Jarod Wilson ja...@wilsonet.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:v4l-dvb/for_v3.1] [media] rc: call input_sync after scancode reports
On Thu, Jul 07, 2011 at 08:28:12PM -0400, Jarod Wilson wrote: On Thu, Jul 7, 2011 at 7:58 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Fri, Jul 01, 2011 at 09:34:45PM +0200, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] rc: call input_sync after scancode reports Author: Jarod Wilson ja...@redhat.com Date: Thu Jun 23 10:40:55 2011 -0300 Due to commit cdda911c34006f1089f3c87b1a1f31ab3a4722f2, evdev only becomes readable when the buffer contains an EV_SYN/SYN_REPORT event. If we get a repeat or a scancode we don't have a mapping for, we never call input_sync, and thus those events don't get reported in a timely fashion. Hmm, any chance to get it into 3.0? Its actually already there, I think the branch was just mis-named, or something along those lines. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98c32bcded0e249fd48726930ae9f393e0e318b4 Ah, good then. Thanks. -- Dmitry -- 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] [staging] lirc_serial: allocate irq at init time
On Thu, Jul 07, 2011 at 08:31:28PM -0400, Jarod Wilson wrote: On Tue, Jul 5, 2011 at 1:21 PM, Greg KH g...@kroah.com wrote: On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote: There's really no good reason not to just grab the desired IRQ at driver init time, instead of every time the lirc device node is accessed. This also improves the speed and reliability with which a serial transmitter can operate, as back-to-back transmission attempts (i.e., channel change to a multi-digit channel) don't have to spend time acquiring and then releasing the IRQ for every digit, sometimes multiple times, if lircd has been told to use the min_repeat parameter. CC: de...@driverdev.osuosl.org Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/staging/lirc/lirc_serial.c | 44 +-- 1 files changed, 21 insertions(+), 23 deletions(-) This patch doesn't apply to the staging-next branch, care to respin it and resend it so I can apply it? This actually got merged into mainline a few days ago via the media tree. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c4b0afee3c1730cf9b0f6ad21729928d23d3918e Do you want me to take a look at what's in staging-next and fix that up to apply on top of the above? No, if it went in there, that's fine with me. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pach under review.
Hi! I would like to have my patch[1] ready for linux 3.0. It's a simple one-liner to solve an easy to fix problem. Is there anything I can do o accelerate the review process? Please, CC me your answers as I'm not subscribed to the list. Tanks! [1] https://patchwork.kernel.org/patch/849142/ -- 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
