[PATCH v2 0/3] OMAP_VOUT: Allow omap_vout to build without VRFB
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's, making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS, since OMAP4 doesn't have VRFB block. A new enum called vout_rotation_type is introduced to differentiate between no rotation and vrfb rotation. A member rotation_type is introduced in omapvideo_info, this allows to call vrfb specific functions only if the rotation type is VOUT_ROT_VRFB. When the rotation_type is set to VOUT_ROT_NONE, the S_CTRL ioctl prevents the user setting a non zero rotation or non zero mirror value. Changes since v1: - add a patch to make rotation related functions names more descriptive. - remove unnecessary externs, add static to some local functions. - improve patch description. Archit Taneja (3): OMAP_VOUT: CLEANUP: Move generic functions and macros to common files OMAP_VOUT: CLEANUP: Make rotation related helper functions more descriptive OMAP_VOUT: Create separate file for VRFB related API's drivers/media/video/omap/Kconfig |7 +- drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 582 + drivers/media/video/omap/omap_vout_vrfb.c | 390 +++ drivers/media/video/omap/omap_vout_vrfb.h | 40 ++ drivers/media/video/omap/omap_voutdef.h | 78 drivers/media/video/omap/omap_voutlib.c | 46 +++ drivers/media/video/omap/omap_voutlib.h | 12 +- 8 files changed, 661 insertions(+), 495 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/media/video/omap/omap_vout_vrfb.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
[PATCH v2 1/3] OMAP_VOUT: CLEANUP: Move generic functions and macros to common files
Move the inline functions rotate_90_or_270(), rotation_enabled(), and
calc_rotation() from omap_vout.c to omap_voutdef.h.
Move the independent functions omap_vout_alloc_buffer() and
omap_vout_free_buffer() to omap_voutlib.c.
Remove extern identifier from function definitions in omap_voutlib.h
Add static identifier to functions that are used locally in omap_vout.c
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c| 117 +-
drivers/media/video/omap/omap_voutdef.h | 62
drivers/media/video/omap/omap_voutlib.c | 46
drivers/media/video/omap/omap_voutlib.h | 12 ++--
4 files changed, 119 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 5634097..1d4112b 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -35,17 +35,14 @@
#include linux/sched.h
#include linux/types.h
#include linux/platform_device.h
-#include linux/dma-mapping.h
#include linux/irq.h
#include linux/videodev2.h
-#include linux/slab.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include plat/dma.h
-#include plat/vram.h
#include plat/vrfb.h
#include video/omapdss.h
@@ -56,7 +53,6 @@ MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
MODULE_LICENSE(GPL);
-
/* Driver Configuration macros */
#define VOUT_NAME omap_vout
@@ -65,31 +61,6 @@ enum omap_vout_channels {
OMAP_VIDEO2,
};
-enum dma_channel_state {
- DMA_CHAN_NOT_ALLOTED,
- DMA_CHAN_ALLOTED,
-};
-
-#define QQVGA_WIDTH160
-#define QQVGA_HEIGHT 120
-
-/* Max Resolution supported by the driver */
-#define VID_MAX_WIDTH 1280/* Largest width */
-#define VID_MAX_HEIGHT 720 /* Largest height */
-
-/* Mimimum requirement is 2x2 for DSS */
-#define VID_MIN_WIDTH 2
-#define VID_MIN_HEIGHT 2
-
-/* 2048 x 2048 is max res supported by OMAP display controller */
-#define MAX_PIXELS_PER_LINE 2048
-
-#define VRFB_TX_TIMEOUT 1000
-#define VRFB_NUM_BUFS 4
-
-/* Max buffer size tobe allocated during init */
-#define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)
-
static struct videobuf_queue_ops video_vbq_ops;
/* Variables configurable through module params*/
static u32 video1_numbuffers = 3;
@@ -172,49 +143,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Allocate buffers
- */
-static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
-{
- u32 order, size;
- unsigned long virt_addr, addr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
- virt_addr = __get_free_pages(GFP_KERNEL, order);
- addr = virt_addr;
-
- if (virt_addr) {
- while (size 0) {
- SetPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- }
- *phys_addr = (u32) virt_to_phys((void *) virt_addr);
- return virt_addr;
-}
-
-/*
- * Free buffers
- */
-static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
-{
- u32 order, size;
- unsigned long addr = virtaddr;
-
- size = PAGE_ALIGN(buf_size);
- order = get_order(size);
-
- while (size 0) {
- ClearPageReserved(virt_to_page(addr));
- addr += PAGE_SIZE;
- size -= PAGE_SIZE;
- }
- free_pages((unsigned long) virtaddr, order);
-}
-
-/*
* Function for allocating video buffers
*/
static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
@@ -369,43 +297,6 @@ static void omap_vout_release_vrfb(struct omap_vout_device
*vout)
}
/*
- * Return true if rotation is 90 or 270
- */
-static inline int rotate_90_or_270(const struct omap_vout_device *vout)
-{
- return (vout-rotation == dss_rotation_90_degree ||
- vout-rotation == dss_rotation_270_degree);
-}
-
-/*
- * Return true if rotation is enabled
- */
-static inline int rotation_enabled(const struct omap_vout_device *vout)
-{
- return vout-rotation || vout-mirror;
-}
-
-/*
- * Reverse the rotation degree if mirroring is enabled
- */
-static inline int calc_rotation(const struct omap_vout_device *vout)
-{
- if (!vout-mirror)
- return vout-rotation;
-
- switch (vout-rotation) {
- case dss_rotation_90_degree:
- return dss_rotation_270_degree;
- case dss_rotation_270_degree:
- return dss_rotation_90_degree;
- case dss_rotation_180_degree:
- return dss_rotation_0_degree;
- default:
- return dss_rotation_180_degree;
- }
-}
-
-/*
* Free the V4L2 buffers
[PATCH v2 2/3] OMAP_VOUT: CLEANUP: Make rotation related helper functions more descriptive
Rename rotation_enabled() and rotate_90_or_270() to is_rotation_enabled()
and is_rotation_90_or_270() to make them more descriptive.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c| 26 +-
drivers/media/video/omap/omap_voutdef.h |4 ++--
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1d4112b..c29d1cb 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -343,7 +343,7 @@ static int omap_vout_vrfb_buffer_setup(struct
omap_vout_device *vout,
/* Allocate the VRFB buffers only if the buffers are not
* allocated during init time.
*/
- if ((rotation_enabled(vout)) !vout-vrfb_static_allocation)
+ if ((is_rotation_enabled(vout)) !vout-vrfb_static_allocation)
if (omap_vout_allocate_vrfb_buffers(vout, count, startindex))
return -ENOMEM;
@@ -419,7 +419,7 @@ static int omap_vout_calculate_offset(struct
omap_vout_device *vout)
if (V4L2_PIX_FMT_YUYV == pix-pixelformat ||
V4L2_PIX_FMT_UYVY == pix-pixelformat) {
- if (rotation_enabled(vout)) {
+ if (is_rotation_enabled(vout)) {
/*
* ps- Actual pixel size for YUYV/UYVY for
* VRFB/Mirroring is 4 bytes
@@ -439,7 +439,7 @@ static int omap_vout_calculate_offset(struct
omap_vout_device *vout)
vout-ps = ps;
vout-vr_ps = vr_ps;
- if (rotation_enabled(vout)) {
+ if (is_rotation_enabled(vout)) {
line_length = MAX_PIXELS_PER_LINE;
ctop = (pix-height - crop-height) - crop-top;
cleft = (pix-width - crop-width) - crop-left;
@@ -578,7 +578,7 @@ static int omapvid_setup_overlay(struct omap_vout_device
*vout,
/* Setup the input plane parameters according to
* rotation value selected.
*/
- if (rotate_90_or_270(vout)) {
+ if (is_rotation_90_or_270(vout)) {
cropheight = vout-crop.width;
cropwidth = vout-crop.height;
pixheight = vout-pix.width;
@@ -602,7 +602,7 @@ static int omapvid_setup_overlay(struct omap_vout_device
*vout,
info.out_width = outw;
info.out_height = outh;
info.global_alpha = vout-win.global_alpha;
- if (!rotation_enabled(vout)) {
+ if (!is_rotation_enabled(vout)) {
info.rotation = 0;
info.rotation_type = OMAP_DSS_ROT_DMA;
info.screen_width = pixwidth;
@@ -857,11 +857,11 @@ static int omap_vout_buffer_setup(struct videobuf_queue
*q, unsigned int *count,
if (V4L2_MEMORY_MMAP == vout-memory *count startindex)
*count = startindex;
- if ((rotation_enabled(vout)) *count VRFB_NUM_BUFS)
+ if ((is_rotation_enabled(vout)) *count VRFB_NUM_BUFS)
*count = VRFB_NUM_BUFS;
/* If rotation is enabled, allocate memory for VRFB space also */
- if (rotation_enabled(vout))
+ if (is_rotation_enabled(vout))
if (omap_vout_vrfb_buffer_setup(vout, count, startindex))
return -ENOMEM;
@@ -879,7 +879,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q,
unsigned int *count,
virt_addr = omap_vout_alloc_buffer(vout-buffer_size,
phy_addr);
if (!virt_addr) {
- if (!rotation_enabled(vout))
+ if (!is_rotation_enabled(vout))
break;
/* Free the VRFB buffers if no space for V4L2 buffers */
for (j = i; j *count; j++) {
@@ -973,7 +973,7 @@ static int omap_vout_buffer_prepare(struct videobuf_queue
*q,
vout-queued_buf_addr[vb-i] = (u8 *)vout-buf_phy_addr[vb-i];
}
- if (!rotation_enabled(vout))
+ if (!is_rotation_enabled(vout))
return 0;
dmabuf = vout-buf_phy_addr[vb-i];
@@ -1332,7 +1332,7 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*fh,
/* We dont support RGB24-packed mode if vrfb rotation
* is enabled*/
- if ((rotation_enabled(vout))
+ if ((is_rotation_enabled(vout))
f-fmt.pix.pixelformat == V4L2_PIX_FMT_RGB24) {
ret = -EINVAL;
goto s_fmt_vid_out_exit;
@@ -1340,7 +1340,7 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*fh,
/* get the framebuffer parameters */
- if (rotate_90_or_270(vout)) {
+ if (is_rotation_90_or_270(vout)) {
vout-fbuf.fmt.height = timing-x_res;
vout-fbuf.fmt.width = timing-y_res;
} else {
@@ -1520,7 +1520,7 @@ static int vidioc_s_crop(struct file
[PATCH v2 3/3] OMAP_VOUT: Create separate file for VRFB related API's
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's,
making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS,
since OMAP4 doesn't have VRFB block.
Added new enum vout_rotation_type and rotation_type member to omapvideo_info,
this is initialized based on the arch type in omap_vout_probe. The rotation_type
var is now used to choose between vrfb and non-vrfb calls.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/Kconfig |7 +-
drivers/media/video/omap/Makefile |1 +
drivers/media/video/omap/omap_vout.c | 453 ++---
drivers/media/video/omap/omap_vout_vrfb.c | 390 +
drivers/media/video/omap/omap_vout_vrfb.h | 40 +++
drivers/media/video/omap/omap_voutdef.h | 16 +
6 files changed, 536 insertions(+), 371 deletions(-)
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h
diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig
index e63233f..390ab09 100644
--- a/drivers/media/video/omap/Kconfig
+++ b/drivers/media/video/omap/Kconfig
@@ -1,11 +1,14 @@
+config VIDEO_OMAP2_VOUT_VRFB
+ bool
+
config VIDEO_OMAP2_VOUT
tristate OMAP2/OMAP3 V4L2-Display driver
depends on ARCH_OMAP2 || ARCH_OMAP3
select VIDEOBUF_GEN
select VIDEOBUF_DMA_CONTIG
select OMAP2_DSS
- select OMAP2_VRAM
- select OMAP2_VRFB
+ select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
+ select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB
default n
---help---
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/drivers/media/video/omap/Makefile
b/drivers/media/video/omap/Makefile
index b287880..fc410b4 100644
--- a/drivers/media/video/omap/Makefile
+++ b/drivers/media/video/omap/Makefile
@@ -4,4 +4,5 @@
# OMAP2/3 Display driver
omap-vout-y := omap_vout.o omap_voutlib.o
+omap-vout-$(CONFIG_VIDEO_OMAP2_VOUT_VRFB) += omap_vout_vrfb.o
obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index c29d1cb..0bc776c 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -48,6 +48,7 @@
#include omap_voutlib.h
#include omap_voutdef.h
+#include omap_vout_vrfb.h
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
@@ -143,41 +144,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
/*
- * Function for allocating video buffers
- */
-static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
- unsigned int *count, int startindex)
-{
- int i, j;
-
- for (i = 0; i *count; i++) {
- if (!vout-smsshado_virt_addr[i]) {
- vout-smsshado_virt_addr[i] =
- omap_vout_alloc_buffer(vout-smsshado_size,
- vout-smsshado_phy_addr[i]);
- }
- if (!vout-smsshado_virt_addr[i] startindex != -1) {
- if (V4L2_MEMORY_MMAP == vout-memory i = startindex)
- break;
- }
- if (!vout-smsshado_virt_addr[i]) {
- for (j = 0; j i; j++) {
- omap_vout_free_buffer(
- vout-smsshado_virt_addr[j],
- vout-smsshado_size);
- vout-smsshado_virt_addr[j] = 0;
- vout-smsshado_phy_addr[j] = 0;
- }
- *count = 0;
- return -ENOMEM;
- }
- memset((void *) vout-smsshado_virt_addr[i], 0,
- vout-smsshado_size);
- }
- return 0;
-}
-
-/*
* Try format
*/
static int omap_vout_try_format(struct v4l2_pix_format *pix)
@@ -270,36 +236,9 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
}
/*
- * Wakes up the application once the DMA transfer to VRFB space is completed.
- */
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
-{
- struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
-
- t-tx_status = 1;
- wake_up_interruptible(t-wait);
-}
-
-/*
- * Release the VRFB context once the module exits
- */
-static void omap_vout_release_vrfb(struct omap_vout_device *vout)
-{
- int i;
-
- for (i = 0; i VRFB_NUM_BUFS; i++)
- omap_vrfb_release_ctx(vout-vrfb_context[i]);
-
- if (vout-vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
- vout-vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout-vrfb_dma_tx.dma_ch);
- }
-}
-
-/*
[PATCH] V4L/DVB: videobuf: mmap.prot checking for IN and OUT device
for OUTPUT device, it will map the page as VM_WRITE
and for INPUT device, it will map the page as
VM_READ. mmap will check the if the prot
is matched with the device type, but not only
check VM_WRITE.
This is actually synced from videobuf2.
Signed-off-by: Kassey Lee y...@marvell.com
hi, Guennadi:
how about sync this enhencement from videbuf2 to videbuf when MMAP is used ?
---
drivers/media/video/videobuf-core.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index de4fa4e..202dd5d 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -1182,10 +1182,24 @@ int videobuf_mmap_mapper(struct videobuf_queue *q,
struct vm_area_struct *vma)
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
- if (!(vma-vm_flags VM_WRITE) || !(vma-vm_flags VM_SHARED)) {
- dprintk(1, mmap appl bug: PROT_WRITE and MAP_SHARED are
required\n);
+ /*
+* Check memory area access mode.
+*/
+ if (!(vma-vm_flags VM_SHARED)) {
+ dprintk(1, Invalid vma flags, VM_SHARED needed\n);
return -EINVAL;
}
+ if (V4L2_TYPE_IS_OUTPUT(q-type)) {
+ if (!(vma-vm_flags VM_WRITE)) {
+ dprintk(1, Invalid vma flags, VM_WRITE needed\n);
+ return -EINVAL;
+ }
+ } else {
+ if (!(vma-vm_flags VM_READ)) {
+ dprintk(1, Invalid vma flags, VM_READ needed\n);
+ return -EINVAL;
+ }
+ }
videobuf_queue_lock(q);
for (i = 0; i VIDEO_MAX_FRAME; i++) {
--
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
[RFCv6 PATCH 00/10] tuner-core: fix g_freq/s_std and g/s_tuner
Changes from RFCv5: - The first patch didn't set set_freq after set_mode in the case of TV. - Added a new patch that checks the tuner type for S_HW_FREQ_SEEK. - Moved the feature-removal patch to the front so the first 6 patches are all for v3.0. I will do some more testing today and if there are no more more issues I'll make a pull request. 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
[RFCv6 PATCH 02/10] tuner-core: fix tuner_resume: use t-mode instead of t-type.
From: Hans Verkuil hans.verk...@cisco.com set_mode is called with t-type, which is the tuner type. Instead, use t-mode which is the actual tuner mode (i.e. radio vs tv). Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/tuner-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index accd9d4..a5aaf25 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1241,7 +1241,7 @@ static int tuner_resume(struct i2c_client *c) tuner_dbg(resume\n); if (!t-standby) - if (set_mode(t, t-type) == 0) + if (set_mode(t, t-mode) == 0) set_freq(t, 0); return 0; -- 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
[RFCv6 PATCH 01/10] tuner-core: fix s_std and s_tuner.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in
s_std/s_tuner
first calls set_mode, and if that returns 0 (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 59 --
1 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 5748d04..accd9d4 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -742,19 +742,15 @@ static inline int check_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns -EINVAL, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
+ * Otherwise, changes the mode and returns 0.
*/
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
+static int set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -770,17 +766,27 @@ static int set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return 0;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq: frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return 0;
}
/*
@@ -1076,10 +1082,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_RADIO, 0) == -EINVAL)
- return 0;
+ if (set_mode(t, V4L2_TUNER_RADIO) == 0)
+ set_freq(t, 0);
return 0;
}
@@ -,25 +1116,22 @@ static int tuner_s_power(struct v4l2_subdev *sd, int on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0) == -EINVAL)
+ if (set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = std;
tuner_fixup_std(t);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
-
- if (set_mode_freq(client, t, f-type, f-frequency) == -EINVAL)
- return 0;
+ if (set_mode(t, f-type) == 0)
+ set_freq(t, f-frequency);
return 0;
}
@@ -1198,13 +1200,13 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, vt-type, 0) == -EINVAL)
+ if (set_mode(t, vt-type))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
t-audmode = vt-audmode;
+ set_freq(t, 0);
return 0;
}
@@ -1239,7 +1241,8 @@ static int tuner_resume(struct i2c_client *c)
[RFCv6 PATCH 07/10] v4l2-subdev.h: remove unused s_mode tuner op.
From: Hans Verkuil hans.verk...@cisco.com
s_mode is no longer used, so remove it.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/media/v4l2-subdev.h |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1562c4f..2245020 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -173,16 +173,13 @@ struct v4l2_subdev_core_ops {
struct v4l2_event_subscription *sub);
};
-/* s_mode: switch the tuner to a specific tuner mode. Replacement of s_radio.
-
- s_radio: v4l device was opened in Radio mode, to be replaced by s_mode.
+/* s_radio: v4l device was opened in radio mode.
s_type_addr: sets tuner type and its I2C addr.
s_config: sets tda9887 specific stuff, like port1, port2 and qss
*/
struct v4l2_subdev_tuner_ops {
- int (*s_mode)(struct v4l2_subdev *sd, enum v4l2_tuner_type);
int (*s_radio)(struct v4l2_subdev *sd);
int (*s_frequency)(struct v4l2_subdev *sd, struct v4l2_frequency *freq);
int (*g_frequency)(struct v4l2_subdev *sd, struct v4l2_frequency *freq);
--
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
[RFCv6 PATCH 05/10] bttv: fix s_tuner for radio.
From: Hans Verkuil hans.verk...@cisco.com Fix typo: g_tuner should have been s_tuner. Tested with a bttv card. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/bt8xx/bttv-driver.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index a97cf27..834a483 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -3474,7 +3474,7 @@ static int radio_s_tuner(struct file *file, void *priv, if (0 != t-index) return -EINVAL; - bttv_call_all(btv, tuner, g_tuner, t); + bttv_call_all(btv, tuner, s_tuner, t); return 0; } -- 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
[RFCv6 PATCH 09/10] tuner-core: simplify the standard fixup.
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 93 +++--
1 files changed, 28 insertions(+), 65 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 8dffe50..9b0d833 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -841,7 +841,8 @@ static void set_tv_freq(struct i2c_client *c, unsigned int
freq)
/**
* tuner_fixup_std - force a given video standard variant
*
- * @t: tuner internal struct
+ * @t: tuner internal struct
+ * @std: TV standard
*
* A few devices or drivers have problem to detect some standard variations.
* On other operational systems, the drivers generally have a per-country
@@ -851,57 +852,39 @@ static void set_tv_freq(struct i2c_client *c, unsigned
int freq)
* to distinguish all video standard variations, a modprobe parameter can
* be used to force a video standard match.
*/
-static int tuner_fixup_std(struct tuner *t)
+static v4l2_std_id tuner_fixup_std(struct tuner *t, v4l2_std_id std)
{
- if ((t-std V4L2_STD_PAL) == V4L2_STD_PAL) {
+ if (pal[0] != '-' (std V4L2_STD_PAL) == V4L2_STD_PAL) {
switch (pal[0]) {
case '6':
- tuner_dbg(insmod fixup: PAL = PAL-60\n);
- t-std = V4L2_STD_PAL_60;
- break;
+ return V4L2_STD_PAL_60;
case 'b':
case 'B':
case 'g':
case 'G':
- tuner_dbg(insmod fixup: PAL = PAL-BG\n);
- t-std = V4L2_STD_PAL_BG;
- break;
+ return V4L2_STD_PAL_BG;
case 'i':
case 'I':
- tuner_dbg(insmod fixup: PAL = PAL-I\n);
- t-std = V4L2_STD_PAL_I;
- break;
+ return V4L2_STD_PAL_I;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: PAL = PAL-DK\n);
- t-std = V4L2_STD_PAL_DK;
- break;
+ return V4L2_STD_PAL_DK;
case 'M':
case 'm':
- tuner_dbg(insmod fixup: PAL = PAL-M\n);
- t-std = V4L2_STD_PAL_M;
- break;
+ return V4L2_STD_PAL_M;
case 'N':
case 'n':
- if (pal[1] == 'c' || pal[1] == 'C') {
- tuner_dbg(insmod fixup: PAL = PAL-Nc\n);
- t-std = V4L2_STD_PAL_Nc;
- } else {
- tuner_dbg(insmod fixup: PAL = PAL-N\n);
- t-std = V4L2_STD_PAL_N;
- }
- break;
- case '-':
- /* default parameter, do nothing */
- break;
+ if (pal[1] == 'c' || pal[1] == 'C')
+ return V4L2_STD_PAL_Nc;
+ return V4L2_STD_PAL_N;
default:
tuner_warn(pal= argument not recognised\n);
break;
}
}
- if ((t-std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
+ if (secam[0] != '-' (std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
switch (secam[0]) {
case 'b':
case 'B':
@@ -909,63 +892,42 @@ static int tuner_fixup_std(struct tuner *t)
case 'G':
case 'h':
case 'H':
- tuner_dbg(insmod fixup: SECAM = SECAM-BGH\n);
- t-std = V4L2_STD_SECAM_B |
-V4L2_STD_SECAM_G |
-V4L2_STD_SECAM_H;
- break;
+ return V4L2_STD_SECAM_B |
+ V4L2_STD_SECAM_G |
+ V4L2_STD_SECAM_H;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: SECAM = SECAM-DK\n);
- t-std = V4L2_STD_SECAM_DK;
- break;
+ return V4L2_STD_SECAM_DK;
case 'l':
case 'L':
- if ((secam[1] == 'C') || (secam[1] == 'c')) {
- tuner_dbg(insmod fixup: SECAM = SECAM-L'\n);
- t-std = V4L2_STD_SECAM_LC;
- } else {
- tuner_dbg(insmod
[RFCv6 PATCH 08/10] tuner-core/v4l2-subdev: document that the type field has to be filled in.
From: Hans Verkuil hans.verk...@cisco.com
The tuner ops g_frequency, g_tuner and s_tuner require that the tuner type
field is filled in. Document this.
The tuner-core doc is based on a patch from Mauro Carvalho Chehab
mche...@redhat.com.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 29 +
include/media/v4l2-subdev.h |7 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index a5aaf25..8dffe50 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1135,6 +1135,16 @@ static int tuner_s_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
return 0;
}
+/**
+ * tuner_g_frequency - Get the tuned frequency for the tuner
+ * @sd: pointer to struct v4l2_subdev
+ * @f: pointer to struct v4l2_frequency
+ *
+ * At return, the structure f will be filled with tuner frequency
+ * if the tuner matches the f-type.
+ * Note: f-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_g_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
@@ -1157,6 +1167,16 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
return 0;
}
+/**
+ * tuner_g_tuner - Fill in tuner information
+ * @sd: pointer to struct v4l2_subdev
+ * @vt: pointer to struct v4l2_tuner
+ *
+ * At return, the structure vt will be filled with tuner information
+ * if the tuner matches vt-type.
+ * Note: vt-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
@@ -1197,6 +1217,15 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
return 0;
}
+/**
+ * tuner_s_tuner - Set the tuner's audio mode
+ * @sd: pointer to struct v4l2_subdev
+ * @vt: pointer to struct v4l2_tuner
+ *
+ * Sets the audio mode if the tuner matches vt-type.
+ * Note: vt-type should be initialized before calling it.
+ * This is done by either video_ioctl2 or by the bridge driver.
+ */
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 2245020..2884e3e 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -175,6 +175,13 @@ struct v4l2_subdev_core_ops {
/* s_radio: v4l device was opened in radio mode.
+ g_frequency: freq-type must be filled in. Normally done by video_ioctl2
+ or the bridge driver.
+
+ g_tuner:
+ s_tuner: vt-type must be filled in. Normally done by video_ioctl2 or the
+ bridge driver.
+
s_type_addr: sets tuner type and its I2C addr.
s_config: sets tda9887 specific stuff, like port1, port2 and qss
--
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
[RFCv6 PATCH 06/10] feature-removal-schedule: change in how radio device nodes are handled.
From: Hans Verkuil hans.verk...@cisco.com Radio devices have weird side-effects when used with combined TV/radio tuners and the V4L2 spec is ambiguous on how it should work. This results in inconsistent driver behavior which makes life hard for everyone. Be more strict in when and how the switch between radio and tv mode takes place and make sure all drivers behave the same. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/feature-removal-schedule.txt | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1a9446b..9df0e09 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -600,3 +600,25 @@ Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. Who: Laurent Pinchart laurent.pinch...@ideasonboard.com + +What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. + If not, return -EINVAL. +When: 3.2 +Why: It makes no sense to switch the tuner to radio mode by calling + VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by + calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a + move to more consistent handling of tv and radio tuners. +Who: Hans Verkuil hans.verk...@cisco.com + + + +What: Opening a radio device node will no longer automatically switch the + tuner mode from tv to radio. +When: 3.3 +Why: Just opening a V4L device should not change the state of the hardware + like that. It's very unexpected and against the V4L spec. Instead, you + switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second + and last step of the move to consistent handling of tv and radio tuners. +Who: Hans Verkuil hans.verk...@cisco.com + + -- 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
[RFCv6 PATCH 10/10] v4l2-ioctl.c: check for valid tuner type in S_HW_FREQ_SEEK.
From: Hans Verkuil hans.verk...@cisco.com
Prohibit attempts to change the tuner to a type that is different
from the device node the ioctl is called from. I.e. the type must
be RADIO for a radio node and ANALOG_TV for a video/vbi node.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ioctl.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 26bf3bf..55df143 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1946,13 +1946,19 @@ static long __video_do_ioctl(struct file *file,
case VIDIOC_S_HW_FREQ_SEEK:
{
struct v4l2_hw_freq_seek *p = arg;
+ enum v4l2_tuner_type type;
if (!ops-vidioc_s_hw_freq_seek)
break;
+ type = (vfd-vfl_type == VFL_TYPE_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
dbgarg(cmd,
- tuner=%d, type=%d, seek_upward=%d, wrap_around=%d\n,
- p-tuner, p-type, p-seek_upward, p-wrap_around);
- ret = ops-vidioc_s_hw_freq_seek(file, fh, p);
+ tuner=%u, type=%u, seek_upward=%u, wrap_around=%u,
spacing=%u\n,
+ p-tuner, p-type, p-seek_upward, p-wrap_around,
p-spacing);
+ if (p-type != type)
+ ret = -EINVAL;
+ else
+ ret = ops-vidioc_s_hw_freq_seek(file, fh, p);
break;
}
case VIDIOC_ENUM_FRAMESIZES:
--
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
[RFCv6 PATCH 04/10] pvrusb2: fix g/s_tuner support.
From: Hans Verkuil hans.verk...@cisco.com
The tuner-core subdev requires that the type field of v4l2_tuner is
filled in correctly. This is done in v4l2-ioctl.c, but pvrusb2 doesn't
use that yet, so we have to do it manually based on whether the current
input is radio or not.
Tested with my pvrusb2.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/pvrusb2/pvrusb2-hdw.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
index 9d0dd08..e98d382 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw.c
@@ -3046,6 +3046,8 @@ static void pvr2_subdev_update(struct pvr2_hdw *hdw)
if (hdw-input_dirty || hdw-audiomode_dirty || hdw-force_dirty) {
struct v4l2_tuner vt;
memset(vt, 0, sizeof(vt));
+ vt.type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
vt.audmode = hdw-audiomode_val;
v4l2_device_call_all(hdw-v4l2_dev, 0, tuner, s_tuner, vt);
}
@@ -5171,6 +5173,8 @@ void pvr2_hdw_status_poll(struct pvr2_hdw *hdw)
{
struct v4l2_tuner *vtp = hdw-tuner_signal_info;
memset(vtp, 0, sizeof(*vtp));
+ vtp-type = (hdw-input_val == PVR2_CVAL_INPUT_RADIO) ?
+ V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
hdw-tuner_signal_stale = 0;
/* Note: There apparently is no replacement for VIDIOC_CROPCAP
using v4l2-subdev - therefore we can't support that AT ALL right
--
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
[RFCv6 PATCH 03/10] v4l2-ioctl.c: prefill tuner type for g_frequency and g/s_tuner.
From: Hans Verkuil hans.verk...@cisco.com The subdevs are supposed to receive a valid tuner type for the g_frequency and g/s_tuner subdev ops. Some drivers do this, others don't. So prefill this in v4l2-ioctl.c based on whether the device node from which this is called is a radio node or not. The spec does not require applications to fill in the type, and if they leave it at 0 then the 'check_mode' call in tuner-core.c will return an error and the ioctl does nothing. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/v4l2-ioctl.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 213ba7d..26bf3bf 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -1822,6 +1822,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_g_tuner) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; ret = ops-vidioc_g_tuner(file, fh, p); if (!ret) dbgarg(cmd, index=%d, name=%s, type=%d, @@ -1840,6 +1842,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_s_tuner) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; dbgarg(cmd, index=%d, name=%s, type=%d, capability=0x%x, rangelow=%d, rangehigh=%d, signal=%d, afc=%d, @@ -1858,6 +1862,8 @@ static long __video_do_ioctl(struct file *file, if (!ops-vidioc_g_frequency) break; + p-type = (vfd-vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; ret = ops-vidioc_g_frequency(file, fh, p); if (!ret) dbgarg(cmd, tuner=%d, type=%d, frequency=%d\n, -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 13/06/2011 00:30, Bart Coninckx wrote: Hi all, hope you can help me this one, because there's not a whole of info about similar problems to be found. I have a Technotrend S2-3200 with CI and on three different distros I get this dvb_ca adaptor 0: PC card did not respond :( in /var/log/messages. Hi Bart, I've got the same card running under OpenSuse 11.4 and Mythtv 0.24.1 I also have the same warning message, but somehow, when Mythtv grabs the device, the CAM will be reset successfully (at least, in my case). In the past, I solved this annoyance by adding a sleep in the CAM init code [1] relevant to the S2-3200 until I found out Mythtv does something about it. [1] drivers/media/dvb/dvb-core/dvb_ca_en50221.c in function dvb_ca_en50221_thread(void) add a sleep of 5 or 10 secs between the 1st dprintk and the main loop. Hope this helps, -- Issa -- 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: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 06/14/11 12:43, Issa Gorissen wrote: On 13/06/2011 00:30, Bart Coninckx wrote: Hi all, hope you can help me this one, because there's not a whole of info about similar problems to be found. I have a Technotrend S2-3200 with CI and on three different distros I get this dvb_ca adaptor 0: PC card did not respond :( in /var/log/messages. Hi Bart, I've got the same card running under OpenSuse 11.4 and Mythtv 0.24.1 I also have the same warning message, but somehow, when Mythtv grabs the device, the CAM will be reset successfully (at least, in my case). In the past, I solved this annoyance by adding a sleep in the CAM init code [1] relevant to the S2-3200 until I found out Mythtv does something about it. [1] drivers/media/dvb/dvb-core/dvb_ca_en50221.c in function dvb_ca_en50221_thread(void) add a sleep of 5 or 10 secs between the 1st dprintk and the main loop. Hope this helps, -- Issa Issa, thx a mille for this. I actually haven't really tried in Mythtv itself, I was just experimenting with szap and mplayer. But I figured that if they aren't working there, they would not elsewhere. I do notice that while taking the card out and putting it back it, the CAM show as initialized successfully in dmesg. I will try your suggestion though. Off topic, but would you advice 11.4 in favor of 11.3? As a secondary route, I was thinking about using sasc-ng (softcamming, legal in this case) and the code seems not to want to compile on 11.4. Also 11.4 broke after updating the kernel. thx again! B. -- 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: Latest media-tree results in system hang, an no IR.
JD jdg8tb at gmail.com writes: With the latest media-tree, any access to my TV card (using tvtime and mplayer to watch through composite) results in my Arch Linux (2.6.39) system freezing. Here is the relavent part of my dmesg upon the freeze: http://codepad.org/q5MxDqAI I compiled the latest media-tree in order to, finally, get my infrared receiver working, however it still does not. An entry is made in /proc/bus/input/devices which points to /dev/input/event5; however. the /dev/lirc device node is not present, and using irw does not seem to recognise any input. Is anyone else experiencing such issues, and has anyone managed to get IR actually working on the HVR-1120. Thanks. I've have just tried this again on a fresh install of Arch Linux (Linux media 2.6.39-ARCH #1); however it is still a no-go. My steps are as follows: 1. git clone git://linuxtv.org/media_build.git 2. ./build.sh (reports it built fine with no errors) 3. reboot system (errors are now reported during boot-up, see dmesg) 4. try to access tv card using any program (mplayer or tvtime to watch composite), my X server crashes, I am thrown out to a TTY and the system appears unresponsive. dmesg (line 720 is where things start to appear interesting): http://codepad.org/OaeWUfAp lsmod: http://codepad.org/GMHFddGU lspci: http://codepad.org/paZ5hoCU Thanks. -- 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: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 14/06/2011 12:48, Bart Coninckx wrote: I will try your suggestion though. Off topic, but would you advice 11.4 in favor of 11.3? As a secondary route, I was thinking about using sasc-ng (softcamming, legal in this case) and the code seems not to want to compile on 11.4. Also 11.4 broke after updating the kernel. Except from the different kernel version, you can go for 11.3, as far as you're concerned only by TV related stuff. You might want to recompile the kernel with a newer version to get all the patches related to the S2 3200. Also, do not hesitate to try out different versions of the kernel if you stumble upon problem with the S2 3200; I had some trouble with it and some recent patches do not suit my setup (dish, cable length, diseqc switch, etc ...) For the sasc-ng matter, I did play with it last year but figured it is a time black hole when it does not work. I guess you have a legal subscription card. Then unless you like to play around, just drop softcams. And CAMs are not that expensive. -- Issa -- 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: Some fixes for alsa_stream
Hi, On 06/14/2011 04:01 AM, Mauro Carvalho Chehab wrote: Hi Devin, I've made a few fixes for your alsa_stream.c, used on tvtime. They are at: http://git.linuxtv.org/xawtv3.git In particular, those are the more interesting ones: commit a1bb5ade5c2b09d6d6d624d18025f9e2c4398495 alsa_stream: negotiate the frame rate Without this patch, one of my em28xx devices doesn't work. It uses 32 k rate, while the playback minimal rate is 44.1 k. I've changed the entire frame rate logic, to be more reliable, and to avoid needing to do frame rate conversion, if both capture and playback devices support the same rate. commit 8adb3d7442b22022b9ca897b0b914962adf41270 alsa_stream: Reduce CPU usage by putting the thread into blocking mode This is just an optimization. I can't see why are you using a non-block mode, as it works fine blocking. commit c67f7aeb86c1caceb7ab30439d169356ea5b1e72 alsa_stream.c: use mmap mode instead of the normal mode Instead of using the normal way, this patch implements mmap mode, and change it to be the default mode. This should also help to reduce CPU usage. hmm, does this include automatic fallback to read mode if mmap mode is not available, mmap mode does not work with a number of devices (such as pulseaudio's alsa plugin). 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
[PATCH] V4L1 API has been moved into legacy on the linuxtv.org site
Signed-off-by: Bjørn Mork bj...@mork.no --- Documentation/video4linux/API.html |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html index d72fd2a..256f8ef 100644 --- a/Documentation/video4linux/API.html +++ b/Documentation/video4linux/API.html @@ -9,7 +9,7 @@ table border=0 tr td - a href=http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html;V4L original API/a + a href=http://linuxtv.org/downloads/legacy/video4linux/API/V4L1_API.html;V4L original API/a /td td Obsoleted by V4L2 API -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] DVB API: Mention the dvbM device
Signed-off-by: Bjørn Mork bj...@mork.no --- Don't know why it was left out, but I found it very confusing when it is mention further down. However, this does make the next paragraph wrong, as there is no dvr specific include file. Documentation/DocBook/media/dvb/intro.xml |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/dvb/intro.xml b/Documentation/DocBook/media/dvb/intro.xml index 8223639..c75dc7c 100644 --- a/Documentation/DocBook/media/dvb/intro.xml +++ b/Documentation/DocBook/media/dvb/intro.xml @@ -154,6 +154,10 @@ are called:/para /listitem listitem +paraemphasis role=tt/dev/dvb/adapterN/dvrM/emphasis,/para +/listitem + listitem + paraemphasis role=tt/dev/dvb/adapterN/caM/emphasis,/para/listitem/itemizedlist parawhere N enumerates the DVB PCI cards in a system starting -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some fixes for alsa_stream
Em 14-06-2011 09:48, Hans de Goede escreveu: Hi, On 06/14/2011 04:01 AM, Mauro Carvalho Chehab wrote: Hi Devin, I've made a few fixes for your alsa_stream.c, used on tvtime. They are at: http://git.linuxtv.org/xawtv3.git In particular, those are the more interesting ones: commit a1bb5ade5c2b09d6d6d624d18025f9e2c4398495 alsa_stream: negotiate the frame rate Without this patch, one of my em28xx devices doesn't work. It uses 32 k rate, while the playback minimal rate is 44.1 k. I've changed the entire frame rate logic, to be more reliable, and to avoid needing to do frame rate conversion, if both capture and playback devices support the same rate. commit 8adb3d7442b22022b9ca897b0b914962adf41270 alsa_stream: Reduce CPU usage by putting the thread into blocking mode This is just an optimization. I can't see why are you using a non-block mode, as it works fine blocking. commit c67f7aeb86c1caceb7ab30439d169356ea5b1e72 alsa_stream.c: use mmap mode instead of the normal mode Instead of using the normal way, this patch implements mmap mode, and change it to be the default mode. This should also help to reduce CPU usage. hmm, does this include automatic fallback to read mode if mmap mode is not available, mmap mode does not work with a number of devices (such as pulseaudio's alsa plugin). No, it doesn't. I'm about to add an option at xawtv3 to allow users to manually select between mmap/normal, and to change the input/output devices. Well, pulseaudio is a bad behavioured boy that has several broken things, like preventing the removal of a V4L2 device for nothing. I won't be surprised if we notice even more problems with pulseaudio and V4L devices. At least on my test with fedora 15, audio is playing, even if pulseaudio is loaded. It should be noticed that the driver tries first to access the alsa driver directly, by using hw:0,0 output device. If it fails, it falls back to plughw:0,0. I'm not sure what's the name of the pulseaudio output, but I suspect that both are just bypassing pulseaudio, with is good ;) 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 -- 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: Some fixes for alsa_stream
Em 14-06-2011 10:05, Mauro Carvalho Chehab escreveu: Em 14-06-2011 09:48, Hans de Goede escreveu: Hi, On 06/14/2011 04:01 AM, Mauro Carvalho Chehab wrote: Hi Devin, I've made a few fixes for your alsa_stream.c, used on tvtime. They are at: http://git.linuxtv.org/xawtv3.git In particular, those are the more interesting ones: commit a1bb5ade5c2b09d6d6d624d18025f9e2c4398495 alsa_stream: negotiate the frame rate Without this patch, one of my em28xx devices doesn't work. It uses 32 k rate, while the playback minimal rate is 44.1 k. I've changed the entire frame rate logic, to be more reliable, and to avoid needing to do frame rate conversion, if both capture and playback devices support the same rate. commit 8adb3d7442b22022b9ca897b0b914962adf41270 alsa_stream: Reduce CPU usage by putting the thread into blocking mode This is just an optimization. I can't see why are you using a non-block mode, as it works fine blocking. commit c67f7aeb86c1caceb7ab30439d169356ea5b1e72 alsa_stream.c: use mmap mode instead of the normal mode Instead of using the normal way, this patch implements mmap mode, and change it to be the default mode. This should also help to reduce CPU usage. hmm, does this include automatic fallback to read mode if mmap mode is not available, mmap mode does not work with a number of devices (such as pulseaudio's alsa plugin). No, it doesn't. I'm about to add an option at xawtv3 to allow users to manually select between mmap/normal, and to change the input/output devices. The options are there: http://git.linuxtv.org/xawtv3.git?a=commit;h=81fc25c5c551ab54fbd90fa6aacd563f03ff73d3 this adds support for -v option inside the alsa_stream, and adds 3 options to allow manually enabling/disabling mmap and changing the detected alsa devices. Well, pulseaudio is a bad behavioured boy that has several broken things, like preventing the removal of a V4L2 device for nothing. I won't be surprised if we notice even more problems with pulseaudio and V4L devices. At least on my test with fedora 15, audio is playing, even if pulseaudio is loaded. It should be noticed that the driver tries first to access the alsa driver directly, by using hw:0,0 output device. If it fails, it falls back to plughw:0,0. I'm not sure what's the name of the pulseaudio output, but I suspect that both are just bypassing pulseaudio, with is good ;) 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some fixes for alsa_stream
Hi, On 06/14/2011 03:05 PM, Mauro Carvalho Chehab wrote: Em 14-06-2011 09:48, Hans de Goede escreveu: Hi, On 06/14/2011 04:01 AM, Mauro Carvalho Chehab wrote: Hi Devin, I've made a few fixes for your alsa_stream.c, used on tvtime. They are at: http://git.linuxtv.org/xawtv3.git In particular, those are the more interesting ones: commit a1bb5ade5c2b09d6d6d624d18025f9e2c4398495 alsa_stream: negotiate the frame rate Without this patch, one of my em28xx devices doesn't work. It uses 32 k rate, while the playback minimal rate is 44.1 k. I've changed the entire frame rate logic, to be more reliable, and to avoid needing to do frame rate conversion, if both capture and playback devices support the same rate. commit 8adb3d7442b22022b9ca897b0b914962adf41270 alsa_stream: Reduce CPU usage by putting the thread into blocking mode This is just an optimization. I can't see why are you using a non-block mode, as it works fine blocking. commit c67f7aeb86c1caceb7ab30439d169356ea5b1e72 alsa_stream.c: use mmap mode instead of the normal mode Instead of using the normal way, this patch implements mmap mode, and change it to be the default mode. This should also help to reduce CPU usage. hmm, does this include automatic fallback to read mode if mmap mode is not available, mmap mode does not work with a number of devices (such as pulseaudio's alsa plugin). No, it doesn't. I'm about to add an option at xawtv3 to allow users to manually select between mmap/normal, and to change the input/output devices. Hmm, we really don't need more cmdline options IMHO, it is quite easy to detect if an alsa device supports mmap mode, and if not fall back to r/w mode, I know several programs which do that (some if which I've written the patches to do this for myself). Well, pulseaudio is a bad behavioured boy that has several broken things, like preventing the removal of a V4L2 device for nothing. I won't be surprised if we notice even more problems with pulseaudio and V4L devices. At least on my test with fedora 15, audio is playing, even if pulseaudio is loaded. It should be noticed that the driver tries first to access the alsa driver directly, by using hw:0,0 output device. If it fails, it falls back to plughw:0,0. I'm not sure what's the name of the pulseaudio output, but I suspect that both are just bypassing pulseaudio, with is good ;) Right this means you're just bypassing pulse audio, which for a tvcard + tv-viewing app is a reasonable thing to do. Defaulting to hw:0,0 makes no sense to me though, we should default to either the audio devices belonging to the video device (as determined through sysfs), or to alsa's default input (which will likely be pulseaudio). 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 08/10] mm: cma: Contiguous Memory Allocator added
On Monday 13 June 2011, Marek Szyprowski wrote: cm_alloc/free are definitely not meant to be called from device drivers. They should be only considered as a backend for dma-mapping. 'Raw' contiguous memory block doesn't really make sense for the device drivers. What the drivers require is a contiguous memory block that is somehow mapped into respective bus address space, so dma-mapping framework is the right interface. alloc_pages(..., GFP_CMA) looks nice but in fact it is really impractical. The driver will need to map such buffer to dma context anyway, so imho dma_alloc_attributed() will give the drivers much more flexibility. In terms of dma-mapping the context argument isn't anything odd. Ok. If possible I would like to make cma something similar to declare_dma_coherent()friends, so the board/platform/bus startup code will just call declare_dma_contiguous() to enable support for cma for particular devices. Sounds good, I like that. This interface looks flawed to me for multiple reasons: * It requires you to call three distinct functions in order to do one thing, and they all take the same arguments (more or less). Why not have one function call at the latest possible point where you can still change the memory attributes, and have everything else happen automatically? Initialization part will be definitely simplified, I must confess that I was in hurry to post the patches before the weekend and just forgot to cleanup this part... Fair enough. In cases like this, it's often good to add a TODO section to the patch description, or a FIXME comment in the patch itself. * It requires you to pass the exact location of the area. I can see why you want that on certain machines that require DMA areas to be spread across multiple memory buses, but IMHO it's not appropriate for a generic API. IMHO we can also use some NULL context to indicate some global, system wide CMA area and again - in terms of dma-mapping api having a context isn't anything uncommon. Please explain the exact requirements that lead you to defining multiple contexts. My feeling is that in most cases we don't need them and can simply live with a single area. Depending on how obscure the cases are where we do need something beyond that, we can then come up with special-case solutions for them. * It requires you to hardcode the size in a machine specific source file. This probably seems to be a natural thing to do when you have worked a lot on the ARM architecture, but it's really not. We really want to get rid of board files and replace them with generic probing based on the device tree, and the size of the area is more policy than a property of the hardware that can be accurately described in the device tree or a board file. The problem is the fact that right now, we still have board files and we have to live with them for a while (with all advantages and disadvantages). I hope that you won't require me to rewrite the whole support for all ARM platforms to get rid of board files to get CMA merged ;) Of course not. But we need to know what we want a platform with device tree support to look like when it's using CMA, so we don't make it harder to change the platforms over than it already is. I see no problem defining CMA areas in device tree, as this is something really specific to particular board configuration. The problem with defining CMA areas in the device tree is that it's not a property of the hardware, but really policy. The device tree file should not contain anything related to a specific operating system because you might want to boot something on the board that doesn't know about CMA, and even when you only care about using Linux, the implementation might change to the point where hardcoded CMA areas no longer make sense. IMHO we should first aim for a solution that works almost everywhere without the kernel knowing what board it's running on, and then we can add quirks for devices that have special requirements. I think the situation is similar to the vmalloc virtual address space, which normally has a hardcoded size that works almost everywhere, but there are certain drivers etc that require much more, or there are situations where you want to make it smaller in order to avoid highmem. 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
Re: Some fixes for alsa_stream
On Tue, Jun 14, 2011 at 9:47 AM, Hans de Goede hdego...@redhat.com wrote: Hmm, we really don't need more cmdline options IMHO, it is quite easy to detect if an alsa device supports mmap mode, and if not fall back to r/w mode, I know several programs which do that (some if which I've written the patches to do this for myself). Agreed. It should be noticed that the driver tries first to access the alsa driver directly, by using hw:0,0 output device. If it fails, it falls back to plughw:0,0. I'm not sure what's the name of the pulseaudio output, but I suspect that both are just bypassing pulseaudio, with is good ;) Right this means you're just bypassing pulse audio, which for a tvcard + tv-viewing Actually, the ALSA client libraries route through PulseAudio (as long as Pulse is running). Basically PulseAudio is providing emulation for the ALSA interface even if you specify hw:1,0 as the device. app is a reasonable thing to do. Defaulting to hw:0,0 makes no sense to me though, we should default to either the audio devices belonging to the video device (as determined through sysfs), or to alsa's default input (which will likely be pulseaudio). Mauro was talking about the output device, not the input device. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote: Please explain the exact requirements that lead you to defining multiple contexts. Some devices may have access only to some banks of memory. Some devices may use different banks of memory for different purposes. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal mina86 Nazarewicz(o o) ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some fixes for alsa_stream
Em 14-06-2011 10:52, Devin Heitmueller escreveu: On Tue, Jun 14, 2011 at 9:47 AM, Hans de Goede hdego...@redhat.com wrote: Hmm, we really don't need more cmdline options IMHO, it is quite easy to detect if an alsa device supports mmap mode, and if not fall back to r/w mode, I know several programs which do that (some if which I've written the patches to do this for myself). Agreed. It should be noticed that the driver tries first to access the alsa driver directly, by using hw:0,0 output device. If it fails, it falls back to plughw:0,0. I'm not sure what's the name of the pulseaudio output, but I suspect that both are just bypassing pulseaudio, with is good ;) Right this means you're just bypassing pulse audio, which for a tvcard + tv-viewing Actually, the ALSA client libraries route through PulseAudio (as long as Pulse is running). Basically PulseAudio is providing emulation for the ALSA interface even if you specify hw:1,0 as the device. I'm not so sure about that. This probably depends on how the alsa library is configured, and this is distribution-specific. I'm almost sure that pulseaudio won't touch on hw: on Fedora. app is a reasonable thing to do. Defaulting to hw:0,0 makes no sense to me though, we should default to either the audio devices belonging to the video device (as determined through sysfs), or to alsa's default input (which will likely be pulseaudio). Mauro was talking about the output device, not the input device. Yes. The default for capture is the one detected via sysfs. The default for playback is not really hw:0,0. It defaults to the first hw: that it is not associated with a video device. I don't like the idea of defaulting to pulseaudio: on my own experiences, the addition of pulseaudio didn't bring me any benefit, but it causes several troubles that I needed to workaround, like disabling the access to the master volume control on a Sony Vaio notebook while setting it to 0 (I had to manually add some scripting at rc.local to fix), limiting the max volume to half of the maximum (very bad effect on some notebooks), preventing rmmod of V4L devices, and not working when the development user is different than the console owner, even when it is at the audio group. I can't think on even a single benefit of using it on my usecase. Besides that, video playback generates too much IO, and, on slower machines, it demands a lot of CPU time. Not having an extra software layer is a good thing to do for the default. If someone wants to use pulseaudio, all they need to do is to pass an extra parameter. That's said, I was not able yet to discover what are the alsa names for pulseaudio devices. Any ideas on how to get it? 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 1/8] marvell-cam: Move cafe-ccic into its own directory
On Tue, 14 Jun 2011 10:23:58 +0800 Kassey Lee kassey1...@gmail.com wrote: Jon, Here is my comments. Thanks for having a look. +config VIDEO_CAFE_CCIC + tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support + depends on PCI I2C VIDEO_V4L2 + select VIDEO_OV7670 why need binds with sensor ? suppose CCIC driver and sensor driver are independent, even if your hardware only support OV7670 We all agree that needs to change. This particular patch, though, is concerned with moving a working driver into a new directory; making that sort of functional change would not be appropriate here. +#include media/ov7670.h ccic would not be aware of the sensor name. Ditto. Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some fixes for alsa_stream
Hi, On 06/14/2011 04:17 PM, Mauro Carvalho Chehab wrote: Em 14-06-2011 10:52, Devin Heitmueller escreveu: snip Yes. The default for capture is the one detected via sysfs. The default for playback is not really hw:0,0. It defaults to the first hw: that it is not associated with a video device. I have a really weird idea, why not make the default output device be default, so that xawtv will use whatever the distro (or user if overriden by the user) has configured as default alsa output device? This will do the right thing for pulseaudio and not pulseaudio users alike. 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: Some fixes for alsa_stream
Em 14-06-2011 11:37, Hans de Goede escreveu: Hi, On 06/14/2011 04:17 PM, Mauro Carvalho Chehab wrote: Em 14-06-2011 10:52, Devin Heitmueller escreveu: snip Yes. The default for capture is the one detected via sysfs. The default for playback is not really hw:0,0. It defaults to the first hw: that it is not associated with a video device. I have a really weird idea, why not make the default output device be default, so that xawtv will use whatever the distro (or user if overriden by the user) has configured as default alsa output device? This will do the right thing for pulseaudio and not pulseaudio users alike. Pulseaudio sucks. See what happens when I pass -alsa-pb default argument to pulseaudio: 1) ssh section. User is the same as the console owner: ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused Cannot open ALSA Playback device default: Connection refused 2) console, with mmap enabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Access type not available for playback: Invalid argument Unable to set parameters for playback stream: Invalid argument Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz with mmap enabled write error: File descriptor in bad state ... write error: File descriptor in bad state 3) console, with mmap disabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz write error: Input/output error ... write error: Input/output error Pulseaudio needs first to be fixed in order to work like an alsa device, before having applications supporting it as default. 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: Some fixes for alsa_stream
On Tue, Jun 14, 2011 at 10:45 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Pulseaudio sucks. See what happens when I pass -alsa-pb default argument to pulseaudio: 1) ssh section. User is the same as the console owner: ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused Cannot open ALSA Playback device default: Connection refused 2) console, with mmap enabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Access type not available for playback: Invalid argument Unable to set parameters for playback stream: Invalid argument Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz with mmap enabled write error: File descriptor in bad state ... write error: File descriptor in bad state 3) console, with mmap disabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz write error: Input/output error ... write error: Input/output error Pulseaudio needs first to be fixed in order to work like an alsa device, before having applications supporting it as default. People have been screaming about Pulseaudio for *years*, and those concerns/complaints have largely fallen on deaf ears. Lennart works for Red Hat too - maybe you can convince him to take these issues seriously. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
On Tue, 14 Jun 2011 10:58:47 +0800
Kassey Lee kassey1...@gmail.com wrote:
+#include linux/wait.h
+#include linux/delay.h
+#include linux/io.h
+
Would be good to sort headers alphabetically
Um, I suppose. You're sure you don't want inverse Christmas-tree ordering?
:)
+static int cafe_smbus_write_done(struct mcam_camera *mcam)
+{
+ unsigned long flags;
+ int c1;
+
+ /*
+ * We must delay after the interrupt, or the controller gets
confused
+ * and never does give us good status. Fortunately, we don't do
this
+ * often.
+ */
+ udelay(20);
+ spin_lock_irqsave(mcam-dev_lock, flags);
+ c1 = mcam_reg_read(mcam, REG_TWSIC1);
+ spin_unlock_irqrestore(mcam-dev_lock, flags);
do you really want to use spin_lock to protect REG_TWSIC1, this
register is not access in ISR ?
I use the spinlock to protect all accesses to the MMIO space; I don't think
it makes sense to have multiple threads mucking around in there at ths same
time.
Also, once again, this is a reshuffle of code which has worked for years; I
don't think it's the right time to mess with the locking decisions.
+/*
+ * Controller-level stuff
+ */
+
+static void cafe_ctlr_init(struct mcam_camera *mcam)
cafe_init is enough
Disagree. This is controller-level (as opposed to TWSI) programming, so
the related functions have ctlr in them. This doesn't seem like a level
of detail that needs a great deal of discussion...?
+#define cam_err(cam, fmt, arg...) \
+ dev_err((cam)-dev, fmt, ##arg);
+#define cam_warn(cam, fmt, arg...) \
+ dev_warn((cam)-dev, fmt, ##arg);
+#define cam_dbg(cam, fmt, arg...) \
+ dev_dbg((cam)-dev, fmt, ##arg);
+
you 've define these in cafe_driver.c, better to share one
Do look at the cafe version:
#define cam_err(cam, fmt, arg...) \
dev_err((cam)-pdev-dev, fmt, ##arg);
They're not the same, so can't be shared. Probably the cafe ones should be
renamed to cafe_err() or whatever to avoid this sort of confusion.
+static void mcam_ctlr_image(struct mcam_camera *cam)
+{
+ int imgsz;
+ struct v4l2_pix_format *fmt = cam-pix_format;
+
+ imgsz = ((fmt-height IMGSZ_V_SHIFT) IMGSZ_V_MASK) |
+ (fmt-bytesperline IMGSZ_H_MASK);
Superfluous parenthesis
See http://lwn.net/Articles/382023/ :)
I feel that use of parentheses to make order of evaluation in complex
expressions explicit is no sin.
+static void mcam_ctlr_irq_enable(struct mcam_camera *cam)
mcam_irq_enable is OK
Sure, it would be OK; there isn't the distinction with the TWSI IRQs that
the cafe driver has. I also don't think that the longer name contributes
greatly to global warming.
+/*
+ * We have found the sensor on the i2c. Let's try to have a
+ * conversation.
+ */
+static int mcam_cam_init(struct mcam_camera *cam)
+{
+ struct v4l2_dbg_chip_ident chip;
+ int ret;
+
+ mutex_lock(cam-s_mutex);
+ if (cam-state != S_NOTREADY)
+ cam_warn(cam, Cam init with device in funky state %d,
+ cam-state);
+ ret = __mcam_cam_reset(cam);
+ if (ret)
+ goto out;
+ chip.ident = V4L2_IDENT_NONE;
+ chip.match.type = V4L2_CHIP_MATCH_I2C_ADDR;
+ chip.match.addr = cam-sensor_addr;
+ ret = sensor_call(cam, core, g_chip_ident, chip);
+ if (ret)
+ goto out;
+ cam-sensor_type = chip.ident;
+ if (cam-sensor_type != V4L2_IDENT_OV7670) {
again, CCIC do not need to know sensor's name.
And, again, that will be fixed. But that's a job for a separate patch.
+static int mcam_vidioc_reqbufs(struct file *filp, void *priv,
+ struct v4l2_requestbuffers *req)
+{
+ struct mcam_camera *cam = filp-private_data;
+ int ret = 0; /* Silence warning */
+
+ /*
+ * Make sure it's something we can do. User pointers could be
+ * implemented without great pain, but that's not been done yet.
+ */
+ if (req-memory != V4L2_MEMORY_MMAP)
+ return -EINVAL;
only MMAP ?
Yes, the current code doesn't do USERPTR, never has. The vb2 conversion
(already working in my tree here, BTW) will fix that.
+static int mcam_vidioc_qbuf(struct file *filp, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct mcam_camera *cam = filp-private_data;
+ struct mcam_sio_buffer *sbuf;
+ int ret = -EINVAL;
+ unsigned long flags;
+
+ mutex_lock(cam-s_mutex);
+ if (buf-index = cam-n_sbufs)
+ goto out;
+ sbuf = cam-sb_bufs + buf-index;
+ if (sbuf-v4lbuf.flags V4L2_BUF_FLAG_QUEUED) {
+ ret = 0; /* Already queued?? */
+ goto out;
+ }
+ if (sbuf-v4lbuf.flags V4L2_BUF_FLAG_DONE) {
+ /* Spec
Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200
On 06/13/11 22:55, Sébastien RAILLARD (COEXSI) wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Bart Coninckx Sent: lundi 13 juin 2011 19:14 To: linux-media@vger.kernel.org Subject: Re: dvb_ca adaptor 0: PC card did not respond :( with Technotrend S2-3200 On 06/13/11 00:30, Bart Coninckx wrote: Hi all, hope you can help me this one, because there's not a whole of info about similar problems to be found. I have a Technotrend S2-3200 with CI and on three different distros I get this dvb_ca adaptor 0: PC card did not respond :( in /var/log/messages. I guess this is the reason why I cannot see encrypted channels on Linux. Unencrypted works fine. In Windows XP the cord works fine too. I tried Opensuse 11.4, the latest Mythbuntu and the latest Mythdora. Can anyone give any hints on how to go about this? Your reporting isn't very clear: - When you try under Linux and Windows, is-it the same PC with the same configuration? - Does-it work with unscrambled channels on Windows ? - Can you decrypt scrambled channels on Windows ? - Does-it work with unscrambled channels on Linux ? - Can you decrypt scrambled channels on Linux ? Sorry, I figured that this would be clear, but: - it is the same PC with a Windows install on another drive - it works scrambled and unscrambled in Windows - it works unscrambled on Linux - no, I cannot, that is the main problem. I thin it is related to the PC card did not respond message. Thank you! B. -- 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
[RFCv1 PATCH 0/8] Allocate events per-event-type, v4l2-ctrls cleanup
This patch series consists of two parts: the first four patches change the way events are allocated and what to do when the event queue is full. These first four patches are the most important ones to review. The big change is that event allocation now happens when subscribing an event. So you not only specify which event you want to subscribe to for a particular filehandle, but also how many events should be reserved for that event type. Currently the driver specifies the number of events to allocate, but later this can be something that the application might want to set manually. This ensures that for each event type you will never entirely miss all events of a particular type. Currently this is a real possibility. The other change is that instead of dropping the new event if there is no more space available, the oldest event is dropped. This ensures that you get at least the latest state. And optionally a merge function can be provided that merges information of two events into one. This allows the control event to require just one event: if a new event is raised, then the new and old one can be merged and all state is preserved. Only the intermediate steps are no longer available. This makes for very good behavior of events and is IMHO a requirement for using the control event in a real production environment. The second four patches reorganize the way extended controls are processed in the control framework. This is the first step towards allowing control changes from within interrupt handlers. The main purpose is to move as much code as possible out of the critical sections. This reduces the size of those sections, making it easier to eventually switch to spinlocks for certain kinds of controls. It's lots of internal churn, so it's probably not easy to review. There are no real functional changes, however. 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
[RFCv1 PATCH 1/8] v4l2-events/fh: merge v4l2_events into v4l2_fh
From: Hans Verkuil hans.verk...@cisco.com
Drivers that supported events used to be rare, but now that controls can also
raise events this will become much more common since almost all drivers have
controls.
This means that keeping struct v4l2_events as a separate struct make no more
sense. Merging it into struct v4l2_fh simplifies things substantially as it
is now an integral part of the filehandle struct.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-fileops.c |6 +-
drivers/media/video/v4l2-ctrls.c|2 -
drivers/media/video/v4l2-event.c| 93 --
drivers/media/video/v4l2-fh.c | 17 ++
drivers/media/video/v4l2-subdev.c | 10 +---
drivers/media/video/vivi.c |2 +-
drivers/usb/gadget/uvc_v4l2.c | 10 +---
include/media/v4l2-event.h | 11
include/media/v4l2-fh.h | 13 +++-
9 files changed, 49 insertions(+), 115 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
index 75c0354..e507766 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -722,8 +722,8 @@ unsigned int ivtv_v4l2_dec_poll(struct file *filp,
poll_table *wait)
/* If there are subscribed events, then only use the new event
API instead of the old video.h based API. */
- if (!list_empty(id-fh.events-subscribed)) {
- poll_wait(filp, id-fh.events-wait, wait);
+ if (!list_empty(id-fh.subscribed)) {
+ poll_wait(filp, id-fh.wait, wait);
/* Turn off the old-style vsync events */
clear_bit(IVTV_F_I_EV_VSYNC_ENABLED, itv-i_flags);
if (v4l2_event_pending(id-fh))
@@ -761,7 +761,7 @@ unsigned int ivtv_v4l2_enc_poll(struct file *filp,
poll_table * wait)
if (v4l2_event_pending(id-fh))
res |= POLLPRI;
else
- poll_wait(filp, id-fh.events-wait, wait);
+ poll_wait(filp, id-fh.wait, wait);
if (s-q_full.length || s-q_io.length)
return res | POLLIN | POLLRDNORM;
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index d084cea..f581910 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -2069,8 +2069,6 @@ int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
struct v4l2_ctrl_handler *hdl = fh-ctrl_handler;
int ret = 0;
- if (!fh-events)
- ret = v4l2_event_init(fh);
if (!ret) {
if (hdl-nr_of_refs * 2 n)
n = hdl-nr_of_refs * 2;
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 670f2f8..70fa82d 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -32,35 +32,11 @@
static void v4l2_event_unsubscribe_all(struct v4l2_fh *fh);
-int v4l2_event_init(struct v4l2_fh *fh)
-{
- fh-events = kzalloc(sizeof(*fh-events), GFP_KERNEL);
- if (fh-events == NULL)
- return -ENOMEM;
-
- init_waitqueue_head(fh-events-wait);
-
- INIT_LIST_HEAD(fh-events-free);
- INIT_LIST_HEAD(fh-events-available);
- INIT_LIST_HEAD(fh-events-subscribed);
-
- fh-events-sequence = -1;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(v4l2_event_init);
-
int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
{
- struct v4l2_events *events = fh-events;
unsigned long flags;
- if (!events) {
- WARN_ON(1);
- return -ENOMEM;
- }
-
- while (events-nallocated n) {
+ while (fh-nallocated n) {
struct v4l2_kevent *kev;
kev = kzalloc(sizeof(*kev), GFP_KERNEL);
@@ -68,8 +44,8 @@ int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
return -ENOMEM;
spin_lock_irqsave(fh-vdev-fh_lock, flags);
- list_add_tail(kev-list, events-free);
- events-nallocated++;
+ list_add_tail(kev-list, fh-free);
+ fh-nallocated++;
spin_unlock_irqrestore(fh-vdev-fh_lock, flags);
}
@@ -87,40 +63,31 @@ EXPORT_SYMBOL_GPL(v4l2_event_alloc);
void v4l2_event_free(struct v4l2_fh *fh)
{
- struct v4l2_events *events = fh-events;
-
- if (!events)
- return;
-
- list_kfree(events-free, struct v4l2_kevent, list);
- list_kfree(events-available, struct v4l2_kevent, list);
+ list_kfree(fh-free, struct v4l2_kevent, list);
+ list_kfree(fh-available, struct v4l2_kevent, list);
v4l2_event_unsubscribe_all(fh);
-
- kfree(events);
- fh-events = NULL;
}
EXPORT_SYMBOL_GPL(v4l2_event_free);
static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
{
- struct v4l2_events *events = fh-events;
[RFCv1 PATCH 2/8] v4l2-ctrls/event: remove struct v4l2_ctrl_fh, instead use v4l2_subscribed_event
From: Hans Verkuil hans.verk...@cisco.com
The v4l2_ctrl_fh struct connected v4l2_ctrl with v4l2_fh so the control
would know which filehandles subscribed to it. However, it is much easier
to use struct v4l2_subscribed_event directly for that and get rid of that
intermediate struct.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 50 ++---
drivers/media/video/v4l2-event.c | 34 +
include/media/v4l2-ctrls.h | 17 +---
include/media/v4l2-event.h |9 +++
4 files changed, 47 insertions(+), 63 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index f581910..079f952 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -581,15 +581,15 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
static void send_event(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 changes)
{
struct v4l2_event ev;
- struct v4l2_ctrl_fh *pos;
+ struct v4l2_subscribed_event *sev;
- if (list_empty(ctrl-fhs))
+ if (list_empty(ctrl-ev_subs))
return;
fill_event(ev, ctrl, changes);
- list_for_each_entry(pos, ctrl-fhs, node)
- if (pos-fh != fh)
- v4l2_event_queue_fh(pos-fh, ev);
+ list_for_each_entry(sev, ctrl-ev_subs, node)
+ if (sev-fh sev-fh != fh)
+ v4l2_event_queue_fh(sev-fh, ev);
}
/* Helper function: copy the current control value back to the caller */
@@ -867,7 +867,7 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
{
struct v4l2_ctrl_ref *ref, *next_ref;
struct v4l2_ctrl *ctrl, *next_ctrl;
- struct v4l2_ctrl_fh *ctrl_fh, *next_ctrl_fh;
+ struct v4l2_subscribed_event *sev, *next_sev;
if (hdl == NULL || hdl-buckets == NULL)
return;
@@ -881,10 +881,8 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
/* Free all controls owned by the handler */
list_for_each_entry_safe(ctrl, next_ctrl, hdl-ctrls, node) {
list_del(ctrl-node);
- list_for_each_entry_safe(ctrl_fh, next_ctrl_fh, ctrl-fhs,
node) {
- list_del(ctrl_fh-node);
- kfree(ctrl_fh);
- }
+ list_for_each_entry_safe(sev, next_sev, ctrl-ev_subs, node)
+ list_del(sev-node);
kfree(ctrl);
}
kfree(hdl-buckets);
@@ -1084,7 +1082,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
INIT_LIST_HEAD(ctrl-node);
- INIT_LIST_HEAD(ctrl-fhs);
+ INIT_LIST_HEAD(ctrl-ev_subs);
ctrl-handler = hdl;
ctrl-ops = ops;
ctrl-id = id;
@@ -2027,41 +2025,31 @@ int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val)
}
EXPORT_SYMBOL(v4l2_ctrl_s_ctrl);
-void v4l2_ctrl_add_fh(struct v4l2_ctrl_handler *hdl,
- struct v4l2_ctrl_fh *ctrl_fh,
- struct v4l2_event_subscription *sub)
+void v4l2_ctrl_add_event(struct v4l2_ctrl *ctrl,
+ struct v4l2_subscribed_event *sev)
{
- struct v4l2_ctrl *ctrl = v4l2_ctrl_find(hdl, sub-id);
-
v4l2_ctrl_lock(ctrl);
- list_add_tail(ctrl_fh-node, ctrl-fhs);
+ list_add_tail(sev-node, ctrl-ev_subs);
if (ctrl-type != V4L2_CTRL_TYPE_CTRL_CLASS
- (sub-flags V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
+ (sev-flags V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
struct v4l2_event ev;
fill_event(ev, ctrl, V4L2_EVENT_CTRL_CH_VALUE |
V4L2_EVENT_CTRL_CH_FLAGS);
- v4l2_event_queue_fh(ctrl_fh-fh, ev);
+ v4l2_event_queue_fh(sev-fh, ev);
}
v4l2_ctrl_unlock(ctrl);
}
-EXPORT_SYMBOL(v4l2_ctrl_add_fh);
+EXPORT_SYMBOL(v4l2_ctrl_add_event);
-void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct v4l2_fh *fh)
+void v4l2_ctrl_del_event(struct v4l2_ctrl *ctrl,
+ struct v4l2_subscribed_event *sev)
{
- struct v4l2_ctrl_fh *pos;
-
v4l2_ctrl_lock(ctrl);
- list_for_each_entry(pos, ctrl-fhs, node) {
- if (pos-fh == fh) {
- list_del(pos-node);
- kfree(pos);
- break;
- }
- }
+ list_del(sev-node);
v4l2_ctrl_unlock(ctrl);
}
-EXPORT_SYMBOL(v4l2_ctrl_del_fh);
+EXPORT_SYMBOL(v4l2_ctrl_del_event);
int v4l2_ctrl_subscribe_fh(struct v4l2_fh *fh,
struct v4l2_event_subscription *sub, unsigned n)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 70fa82d..dc68f60 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -213,7 +213,6 @@ int v4l2_event_subscribe(struct
[RFCv1 PATCH 5/8] v4l2-ctrls: don't initially set CH_VALUE for write-only controls
From: Hans Verkuil hans.verk...@cisco.com
When sending the SEND_INITIAL event for write-only controls the
V4L2_EVENT_CTRL_CH_VALUE flag should not be set. It's meaningless.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 63a44fd..1b0422e 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -2032,9 +2032,11 @@ void v4l2_ctrl_add_event(struct v4l2_ctrl *ctrl,
if (ctrl-type != V4L2_CTRL_TYPE_CTRL_CLASS
(sev-flags V4L2_EVENT_SUB_FL_SEND_INITIAL)) {
struct v4l2_event ev;
+ u32 changes = V4L2_EVENT_CTRL_CH_FLAGS;
- fill_event(ev, ctrl, V4L2_EVENT_CTRL_CH_VALUE |
- V4L2_EVENT_CTRL_CH_FLAGS);
+ if (!(ctrl-flags V4L2_CTRL_FLAG_WRITE_ONLY))
+ changes |= V4L2_EVENT_CTRL_CH_VALUE;
+ fill_event(ev, ctrl, changes);
v4l2_event_queue_fh(sev-fh, ev);
}
v4l2_ctrl_unlock(ctrl);
--
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
[RFCv1 PATCH 6/8] v4l2-ctrls: improve discovery of controls of the same cluster
From: Hans Verkuil hans.verk...@cisco.com
The implementation of VIDIOC_G/S/TRY_EXT_CTRLS in the control framework has
to figure out which controls in the control list belong to the same cluster.
Since controls belonging to the same cluster need to be handled as a unit,
this is important information.
It did that by going over the controls in the list and for each control that
belonged to a multi-control cluster it would walk the remainder of the list
to try and find controls that belong to that same cluster.
This approach has two disadvantages:
1) it was a potentially quadratic algorithm (although highly unlikely that
it would ever be that bad in practice).
2) it took place with the control handler's lock held.
Since we want to make it possible in the future to change control values
from interrupt context, doing a lot of work while holding a lock is not a
good idea.
In the new code the algorithm is no longer quadratic but linear in the
number of controls in the list. Also, it now can be done beforehand.
Another change that was made was to so the try and set at the same time.
Before when S_TRY_EXT_CTRLS was called it would 'try' the controls first,
and then it would 'set' them. The idea was that any 'try' errors would
prevent the 'set' from happening, thus avoiding having partially set
control lists.
However, this caused more problems than it solved because between the 'try'
and the 'set' changes might have happened, so it had to try a second time,
and since actual controls with a try_ctrl op are very rare (and those that
we have just adjust values and do not return an error), I've decided to
drop that two-stage approach and just combine try and set.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 279 +++--
include/media/v4l2-ctrls.h |3 +
2 files changed, 146 insertions(+), 136 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 1b0422e..8fe4e47 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -32,12 +32,14 @@
(has_op(master, op) ? master-ops-op(master) : 0)
/* Internal temporary helper struct, one for each v4l2_ext_control */
-struct ctrl_helper {
+struct v4l2_ctrl_helper {
+ /* Pointer to the control reference of the master control */
+ struct v4l2_ctrl_ref *mref;
/* The control corresponding to the v4l2_ext_control ID field. */
struct v4l2_ctrl *ctrl;
- /* Used internally to mark whether this control was already
- processed. */
- bool handled;
+ /* v4l2_ext_control index of the next control belonging to the
+ same cluster, or 0 if there isn't any. */
+ u32 next;
};
/* Small helper function to determine if the autocluster is set to manual
@@ -678,20 +680,6 @@ static int new_to_user(struct v4l2_ext_control *c,
return 0;
}
-static int ctrl_to_user(struct v4l2_ext_control *c,
- struct v4l2_ctrl *ctrl)
-{
- if (ctrl-is_volatile)
- return new_to_user(c, ctrl);
- return cur_to_user(c, ctrl);
-}
-
-static int ctrl_is_volatile(struct v4l2_ext_control *c,
- struct v4l2_ctrl *ctrl)
-{
- return ctrl-is_volatile;
-}
-
/* Copy the new value to the current value. */
static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
bool update_inactive)
@@ -779,13 +767,11 @@ static int cluster_changed(struct v4l2_ctrl *master)
return diff;
}
-/* Validate a new control */
-static int validate_new(struct v4l2_ctrl *ctrl)
+/* Validate integer-type control */
+static int validate_new_int(const struct v4l2_ctrl *ctrl, s32 *pval)
{
- s32 val = ctrl-val;
- char *s = ctrl-string;
+ s32 val = *pval;
u32 offset;
- size_t len;
switch (ctrl-type) {
case V4L2_CTRL_TYPE_INTEGER:
@@ -798,11 +784,11 @@ static int validate_new(struct v4l2_ctrl *ctrl)
offset = val - ctrl-minimum;
offset = ctrl-step * (offset / ctrl-step);
val = ctrl-minimum + offset;
- ctrl-val = val;
+ *pval = val;
return 0;
case V4L2_CTRL_TYPE_BOOLEAN:
- ctrl-val = !!ctrl-val;
+ *pval = !!val;
return 0;
case V4L2_CTRL_TYPE_MENU:
@@ -815,9 +801,28 @@ static int validate_new(struct v4l2_ctrl *ctrl)
case V4L2_CTRL_TYPE_BUTTON:
case V4L2_CTRL_TYPE_CTRL_CLASS:
- ctrl-val64 = 0;
+ *pval = 0;
return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+/* Validate a new control */
+static int validate_new(const struct v4l2_ctrl *ctrl, struct v4l2_ext_control
*c)
+{
+ char *s = c-string;
+ size_t len;
+
+ switch (ctrl-type) {
+ case V4L2_CTRL_TYPE_INTEGER:
+
[RFCv1 PATCH 8/8] v4l2-ctrls: v4l2_ctrl_handler_setup code simplification
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 040d5c9..627a1e4 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1410,26 +1410,21 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler
*hdl)
int i;
/* Skip if this control was already handled by a cluster. */
- if (ctrl-done)
+ /* Skip button controls and read-only controls. */
+ if (ctrl-done || ctrl-type == V4L2_CTRL_TYPE_BUTTON ||
+ (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY))
continue;
for (i = 0; i master-ncontrols; i++) {
if (master-cluster[i]) {
cur_to_new(master-cluster[i]);
master-cluster[i]-is_new = 1;
+ master-cluster[i]-done = true;
}
}
-
- /* Skip button controls and read-only controls. */
- if (ctrl-type == V4L2_CTRL_TYPE_BUTTON ||
- (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY))
- continue;
ret = call_op(master, s_ctrl);
if (ret)
break;
- for (i = 0; i master-ncontrols; i++)
- if (master-cluster[i])
- master-cluster[i]-done = true;
}
mutex_unlock(hdl-lock);
return ret;
--
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
[RFCv1 PATCH 7/8] v4l2-ctrls: split try_or_set_ext_ctrls()
From: Hans Verkuil hans.verk...@cisco.com
Split try_or_set_ext_ctrls() into a validate_ctrls() part ('Phase 1')
and merge the second part ('Phase 2') into try_set_ext_ctrls().
This makes a lot more sense and it also does the validation before
trying to try/set the controls.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 88 ++
1 files changed, 41 insertions(+), 47 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8fe4e47..040d5c9 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1800,8 +1800,8 @@ EXPORT_SYMBOL(v4l2_ctrl_g_ctrl);
/* Core function that calls try/s_ctrl and ensures that the new value is
copied to the current value on a set.
Must be called with ctrl-handler-lock held. */
-static int try_or_set_control_cluster(struct v4l2_fh *fh,
- struct v4l2_ctrl *master, bool set)
+static int try_or_set_cluster(struct v4l2_fh *fh,
+ struct v4l2_ctrl *master, bool set)
{
bool update_flag;
int ret;
@@ -1843,23 +1843,18 @@ static int try_or_set_control_cluster(struct v4l2_fh
*fh,
return 0;
}
-/* Try or set controls. */
-static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
- struct v4l2_ctrl_handler *hdl,
- struct v4l2_ext_controls *cs,
- struct v4l2_ctrl_helper *helpers,
- bool set)
+/* Validate controls. */
+static int validate_ctrls(struct v4l2_ext_controls *cs,
+ struct v4l2_ctrl_helper *helpers, bool set)
{
- unsigned i, j;
+ unsigned i;
int ret = 0;
- /* Phase 1: validation */
cs-error_idx = cs-count;
for (i = 0; i cs-count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
- if (!set)
- cs-error_idx = i;
+ cs-error_idx = i;
if (ctrl-flags V4L2_CTRL_FLAG_READ_ONLY)
return -EACCES;
@@ -1875,8 +1870,38 @@ static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
if (ret)
return ret;
}
+ return 0;
+}
+
+/* Try or try-and-set controls */
+static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
+struct v4l2_ext_controls *cs,
+bool set)
+{
+ struct v4l2_ctrl_helper helper[4];
+ struct v4l2_ctrl_helper *helpers = helper;
+ unsigned i, j;
+ int ret;
+
+ cs-error_idx = cs-count;
+ cs-ctrl_class = V4L2_CTRL_ID2CLASS(cs-ctrl_class);
+
+ if (hdl == NULL)
+ return -EINVAL;
+
+ if (cs-count == 0)
+ return class_check(hdl, cs-ctrl_class);
- /* Phase 2: set/try controls */
+ if (cs-count ARRAY_SIZE(helper)) {
+ helpers = kmalloc(sizeof(helper[0]) * cs-count, GFP_KERNEL);
+ if (!helpers)
+ return -ENOMEM;
+ }
+ ret = prepare_ext_ctrls(hdl, cs, helpers);
+ if (!ret)
+ ret = validate_ctrls(cs, helpers, set);
+ if (ret set)
+ cs-error_idx = cs-count;
for (i = 0; !ret i cs-count; i++) {
struct v4l2_ctrl *master;
u32 idx = i;
@@ -1901,50 +1926,19 @@ static int try_or_set_ext_ctrls(struct v4l2_fh *fh,
} while (!ret idx);
if (!ret)
- ret = try_or_set_control_cluster(fh, master, set);
+ ret = try_or_set_cluster(fh, master, set);
/* Copy the new values back to userspace. */
if (!ret) {
idx = i;
do {
ret = user_to_new(cs-controls + idx,
- helpers[idx].ctrl);
+ helpers[idx].ctrl);
idx = helpers[idx].next;
} while (!ret idx);
}
v4l2_ctrl_unlock(master);
}
- return ret;
-}
-
-/* Try or try-and-set controls */
-static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
-struct v4l2_ext_controls *cs,
-bool set)
-{
- struct v4l2_ctrl_helper helper[4];
- struct v4l2_ctrl_helper *helpers = helper;
- int ret;
-
- cs-error_idx = cs-count;
- cs-ctrl_class = V4L2_CTRL_ID2CLASS(cs-ctrl_class);
-
- if (hdl == NULL)
- return -EINVAL;
-
- if (cs-count == 0)
- return class_check(hdl, cs-ctrl_class);
-
- if (cs-count ARRAY_SIZE(helper)) {
- helpers = kmalloc(sizeof(helper[0]) *
[RFCv1 PATCH 3/8] v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh
From: Hans Verkuil hans.verk...@cisco.com
The driver had to decide how many events to allocate when the v4l2_fh struct
was created. It was possible to add more events afterwards, but there was no
way to ensure that you wouldn't miss important events if the event queue
would fill up for that filehandle.
In addition, once there were no more free events, any new events were simply
dropped on the floor.
For the control event in particular this made life very difficult since
control status/value changes could just be missed if the number of allocated
events and the speed at which the application read events was too low to keep
up with the number of generated events. The application would have no idea
what the latest state was for a control since it could have missed the latest
control change.
So this patch makes some major changes in how events are allocated. Instead
of allocating events per-filehandle they are now allocated when subscribing an
event. So for that particular event type N events (determined by the driver)
are allocated. Those events are reserved for that particular event type.
This ensures that you will not miss events for a particular type altogether.
In addition, if there are N events in use and a new event is raised, then
the oldest event is dropped and the new one is added. So the latest event
is always available.
This can be further improved by adding the ability to merge the state of
two events together, ensuring that no data is lost at all. This will be
added in the next patch.
This also makes it possible to allow the user to determine the number of
events that will be allocated. This is not implemented at the moment, but
would be trivial.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/ivtv/ivtv-fileops.c |4 --
drivers/media/video/ivtv/ivtv-ioctl.c |4 +-
drivers/media/video/omap3isp/ispccdc.c |3 +-
drivers/media/video/omap3isp/ispstat.c |3 +-
drivers/media/video/v4l2-ctrls.c| 18 --
drivers/media/video/v4l2-event.c| 88 ---
drivers/media/video/v4l2-fh.c |4 +-
drivers/media/video/v4l2-subdev.c |7 ---
drivers/media/video/vivi.c |2 +-
drivers/usb/gadget/uvc_v4l2.c | 12 +
include/media/v4l2-ctrls.h | 19 ---
include/media/v4l2-event.h | 18 +-
include/media/v4l2-fh.h |2 -
include/media/v4l2-subdev.h |2 -
14 files changed, 54 insertions(+), 132 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-fileops.c
b/drivers/media/video/ivtv/ivtv-fileops.c
index e507766..5796262 100644
--- a/drivers/media/video/ivtv/ivtv-fileops.c
+++ b/drivers/media/video/ivtv/ivtv-fileops.c
@@ -957,10 +957,6 @@ static int ivtv_serialized_open(struct ivtv_stream *s,
struct file *filp)
return -ENOMEM;
}
v4l2_fh_init(item-fh, s-vdev);
- if (s-type == IVTV_DEC_STREAM_TYPE_YUV ||
- s-type == IVTV_DEC_STREAM_TYPE_MPG) {
- res = v4l2_event_alloc(item-fh, 60);
- }
if (res 0) {
v4l2_fh_exit(item-fh);
kfree(item);
diff --git a/drivers/media/video/ivtv/ivtv-ioctl.c
b/drivers/media/video/ivtv/ivtv-ioctl.c
index a81b4be..99b2bdc 100644
--- a/drivers/media/video/ivtv/ivtv-ioctl.c
+++ b/drivers/media/video/ivtv/ivtv-ioctl.c
@@ -1444,13 +1444,11 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh,
struct v4l2_event_subscripti
switch (sub-type) {
case V4L2_EVENT_VSYNC:
case V4L2_EVENT_EOS:
- break;
case V4L2_EVENT_CTRL:
- return v4l2_ctrl_subscribe_fh(fh, sub, 0);
+ return v4l2_event_subscribe(fh, sub, 0);
default:
return -EINVAL;
}
- return v4l2_event_subscribe(fh, sub);
}
static int ivtv_log_status(struct file *file, void *fh)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index 39d501b..6766247 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1691,7 +1691,7 @@ static int ccdc_subscribe_event(struct v4l2_subdev *sd,
struct v4l2_fh *fh,
if (sub-type != V4L2_EVENT_OMAP3ISP_HS_VS)
return -EINVAL;
- return v4l2_event_subscribe(fh, sub);
+ return v4l2_event_subscribe(fh, sub, OMAP3ISP_CCDC_NEVENTS);
}
static int ccdc_unsubscribe_event(struct v4l2_subdev *sd, struct v4l2_fh *fh,
@@ -2162,7 +2162,6 @@ static int ccdc_init_entities(struct isp_ccdc_device
*ccdc)
sd-grp_id = 1 16; /* group ID for isp subdevs */
v4l2_set_subdevdata(sd, ccdc);
sd-flags |= V4L2_SUBDEV_FL_HAS_EVENTS | V4L2_SUBDEV_FL_HAS_DEVNODE;
- sd-nevents = OMAP3ISP_CCDC_NEVENTS;
pads[CCDC_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
pads[CCDC_PAD_SOURCE_VP].flags = MEDIA_PAD_FL_SOURCE;
diff --git
[RFCv1 PATCH 4/8] v4l2-event: add optional 'merge' callback to merge two events
From: Hans Verkuil hans.verk...@cisco.com
When the event queue for a subscribed event is full, then the oldest
event is dropped. It would be nice if the contents of that oldest
event could be merged with the next-oldest. That way no information is
lost, only intermediate steps are lost.
This patch adds an optional merge function that will be called to do
this job and implements it for the control event.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-event.c | 27 ++-
include/media/v4l2-event.h |5 +
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
index 9e325dd..aeec2d5 100644
--- a/drivers/media/video/v4l2-event.c
+++ b/drivers/media/video/v4l2-event.c
@@ -113,6 +113,7 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh, const
struct v4l2_event *e
{
struct v4l2_subscribed_event *sev;
struct v4l2_kevent *kev;
+ bool copy_payload = true;
/* Are we subscribed? */
sev = v4l2_event_subscribed(fh, ev-type, ev-id);
@@ -130,12 +131,23 @@ static void __v4l2_event_queue_fh(struct v4l2_fh *fh,
const struct v4l2_event *e
sev-in_use--;
sev-first = sev_pos(sev, 1);
fh-navailable--;
+ if (sev-merge) {
+ if (sev-elems == 1) {
+ sev-merge(kev-event, ev, kev-event);
+ copy_payload = false;
+ } else {
+ struct v4l2_kevent *second_oldest =
+ sev-events + sev_pos(sev, 0);
+ sev-merge(second_oldest-event,
second_oldest-event, kev-event);
+ }
+ }
}
/* Take one and fill it. */
kev = sev-events + sev_pos(sev, sev-in_use);
kev-event.type = ev-type;
- kev-event.u = ev-u;
+ if (copy_payload)
+ kev-event.u = ev-u;
kev-event.id = ev-id;
kev-event.timestamp = *ts;
kev-event.sequence = fh-sequence;
@@ -184,6 +196,17 @@ int v4l2_event_pending(struct v4l2_fh *fh)
}
EXPORT_SYMBOL_GPL(v4l2_event_pending);
+static void ctrls_merge(struct v4l2_event *dst,
+ const struct v4l2_event *new,
+ const struct v4l2_event *old)
+{
+ u32 changes = new-u.ctrl.changes | old-u.ctrl.changes;
+
+ if (dst == old)
+ dst-u.ctrl = new-u.ctrl;
+ dst-u.ctrl.changes = changes;
+}
+
int v4l2_event_subscribe(struct v4l2_fh *fh,
struct v4l2_event_subscription *sub, unsigned elems)
{
@@ -210,6 +233,8 @@ int v4l2_event_subscribe(struct v4l2_fh *fh,
sev-flags = sub-flags;
sev-fh = fh;
sev-elems = elems;
+ if (ctrl)
+ sev-merge = ctrls_merge;
spin_lock_irqsave(fh-vdev-fh_lock, flags);
found_ev = v4l2_event_subscribed(fh, sub-type, sub-id);
diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
index 8d681e5..111b2bc 100644
--- a/include/media/v4l2-event.h
+++ b/include/media/v4l2-event.h
@@ -55,6 +55,11 @@ struct v4l2_subscribed_event {
struct v4l2_fh *fh;
/* list node that hooks into the object's event list (if there is one)
*/
struct list_headnode;
+ /* Optional callback that can merge two events.
+ Note that 'dst' can be the same as either 'new' or 'old'. */
+ void(*merge)(struct v4l2_event *dst,
+const struct v4l2_event *new,
+const struct v4l2_event *old);
/* the number of elements in the events array */
unsignedelems;
/* the index of the events containing the oldest available event */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 02/10] lib: genalloc: Generic allocator improvements
On 06/10/2011 06:52 AM, Alan Cox wrote: I plan to replace it with lib/bitmap.c bitmap_* based allocator (similar like it it is used by dma_declare_coherent_memory() and friends in drivers/base/dma-coherent.c). We need something really simple for CMA area management. IMHO allocate_resource and friends a bit too heavy here, but good to know that such allocator also exists. Not sure I'd class allocate_resource as heavyweight but providing it's using something that already exists rather than inventing yet another allocator. This wants dealing with before it goes upstream though so the chaneges in lib/*c etc never have to reach mainline and then get changed back. Even if CMA doesn't end up using genalloc, there are existing consumers of the API and I think the _aligned function has value. I agree that allocate_resource isn't overly heavy, but comparatively genalloc is really simple and lightweight for a driver to manage a contiguous address space without a lot of extra thought. I think both APIs serve slightly different masters, but if somebody thought about it long enough there could be some consolidation (same goes for the internal guts of dma_declare_coherent_memory). I agree with Michal - if genalloc goes deprecated, then so be it, but as long as it lives, I think its useful to get these functions upstream. Jordan -- 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
buffer index when streaming user-ptr buffers
In the V4L2 spec, the description for v4l2_buffer.index says This field is only used for memory mapping I/O... However, in v4l-utils/contrib/capture-example.c, even user-pointer buffers are indeed given a buf.index before being passed to VIDIOC_QBUF. And at least in the OMAP ISP driver, this information is relied upon in QBUF regardless of V4L2_MEMORY_MMAP/USERPTR. videobuf-core also uses v4l2_buffer-index even if b-memory == V4L2_MEMORY_USERPTR. Is this a bug in the OMAP driver and videobuf-core, and an unnecessary assignment in capture-example? Or is the V4L2 spec out of touch/ out of date? -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: Some fixes for alsa_stream
Em 14-06-2011 11:48, Devin Heitmueller escreveu: On Tue, Jun 14, 2011 at 10:45 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Pulseaudio sucks. See what happens when I pass -alsa-pb default argument to pulseaudio: 1) ssh section. User is the same as the console owner: ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused Cannot open ALSA Playback device default: Connection refused 2) console, with mmap enabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Access type not available for playback: Invalid argument Unable to set parameters for playback stream: Invalid argument Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz with mmap enabled write error: File descriptor in bad state ... write error: File descriptor in bad state 3) console, with mmap disabled: Alsa devices: cap: hw:1,0 (/dev/video0), out: default Alsa stream started, capturing from hw:1,0, playing back on default at 1 Hz write error: Input/output error ... write error: Input/output error Pulseaudio needs first to be fixed in order to work like an alsa device, before having applications supporting it as default. Hans, Feel free to add pulseaudio support for it, if you want. I don't have time (or interest) on fixing support for it. Even after fixed, I think that it is safer to keep the default behavior to directly use alsa, but it is a good idea to allow users to override. People have been screaming about Pulseaudio for *years*, and those concerns/complaints have largely fallen on deaf ears. Hmm.. I forgot to add a disclaimer on my previous post that my comments express my own opinion, doesn't reflect the opinion of my employer, and so on ;) Seriously speaking, I'm not saying that pulseaudio is bad. I just said it didn't bring anything that _I_ was needing, and that, on the other hand, it broke several things, requiring some tricks to workaround about it. Well, it works most of the time, and, on my development machines, I generally don't start X, as I prefer to work via ssh. Lennart works for Red Hat too - maybe you can convince him to take these issues seriously. I don't have much contact with Lennart. Red Hat is a big company. I'll talk with him if I have an opportunity, but I don't think I'll be able to convince him. My usecase is to use my development machines as if they were servers, working on them remotely via ssh and tty consoles. This is not the typical usage for pulseaudio. Clearly, it were designed thinking on a normal desktop user, as pulseaudio is started via X session. 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 08/10] mm: cma: Contiguous Memory Allocator added
On Tuesday 14 June 2011, Michal Nazarewicz wrote: On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote: Please explain the exact requirements that lead you to defining multiple contexts. Some devices may have access only to some banks of memory. Some devices may use different banks of memory for different purposes. For all I know, that is something that is only true for a few very special Samsung devices, and is completely unrelated of the need for contiguous allocations, so this approach becomes pointless as soon as the next generation of that chip grows an IOMMU, where we don't handle the special bank attributes. Also, the way I understood the situation for the Samsung SoC during the Budapest discussion, it's only a performance hack, not a functional requirement, unless you count '1080p playback' as a functional requirement. Supporting contiguous allocation is a very useful goal and many people want this, but supporting a crazy one-off hardware design with lots of generic infrastructure is going a bit too far. If you can't be more specific than 'some devices may need this', I would suggest going forward without having multiple regions: * Remove the registration of specific addresses from the initial patch set (but keep the patch). * Add a heuristic plus command-line override to automatically come up with a reasonable location+size for *one* CMA area in the system. * Ship the patch to add support for multiple CMA areas with the BSP for the boards that need it (if any). * Wait for someone on a non-Samsung SoC to run into the same problem, then have /them/ get the final patch in. Even if you think you can convince enough people that having support for distinct predefined regions is a good idea, I would recommend splitting that out of the initial merge so we can have that discussion separately from the other issues. 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
[PATCH 0/4 v9] Multi Format Codec 5.1 driver for s5pv210 and exynos4 SoC
Hi, This is the ninth version of the MFC 5.1 driver. Both encoding and decoding is supported. The encoding part was done Jeongtae Park with some of my modifications. Changes in videodev2.h have been split to two patches: 1) v4l: add fourcc definitons for compressed formats. (http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30740) This one has been already discussed on the mailing list (sent on the 23/03/2011). However there is one change in the names of VC1 fourccs: - V4L2_PIX_FMT_VC1_AP changed to V4L2_PIX_FMT_VC1_ANNEX_G - V4L2_PIX_FMT_VC1 changed to V4L2_PIX_FMT_VC1_ANNEX_L 2) v4l: add control definitions for codec devices. I am posting the newest version of this patch in this patch set. The changes from v3 that was posted on the list: (http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/33438) - use already existing controls instead of creating new (during the discussion it turned out that some controls mean the same as already existing ones) - V4L2_CID_MPEG_LEVEL control hase been split into two separate for MPEG4 and H264 - use V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_MAX_BYTES instead of *_MAX_BITS - use V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE instead of *_SYMBOL_MODE - added CYCLIC to V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB - V4L2_CID_MFC51_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER is no longer MFC specific - new names for vop_time_increment and vop_time_increment_resolution controls - extended the documentation and corrected mistakes in the doc Another major change is use of the dma_contig memory allocator. This removes the dependence on other subsystems, which could delay merging of MFC. I have also removed the per buffer controls implemented by Jeongtae from this version. Handling of such controls was complicated and is not necessary for the driver to work. We will get back to this feature after the first version of MFC get merged. The branch with all necessary patches applied can be found here (in couple of hours): http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/mfc-for-mauro This driver requires platform modification that can be found here (it will also sync in a couple of hours): http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/mfc-for-kgene The platform modification have been sent today to the linux-samsung-soc list. Best regards, Kamil Debski * Changelog: == Changes since v8 == 1) Change code to use only dma_contig memory allocator, this removes any dependencies on other subsystems that could delay the merging of MFC to the mainline. 2) Support for per buffer controls have been removed, it will be added at later time after the initial version gets merged in mainline. This is because the support for per buffer controls was overly complicated and offered little added functionality. 3) Due to licensing issues support for DIVX has been removed from the driver. 4) Update the code to work with latest version of codec controls patch. == Changes since v7 == 1) New fourcc definitions for codecs - Fourcc definitions based on the new RFC 2) New controls defined in videodev2.h - Controls definitions based on the new RFC 3) Support for multiple memory allocators - DMA Pool, CMA and IOMMU - Now one can choose memory allocator in the kernel config. 4) Improved method of handling shared memory - by using memory barriers - Problems with using the shared memory registers have been previously addressed with cleaning and invalidating cache. Now it is handles by memory barriers and proper mapping. 5) Fixed packed PB sequence numbering - Numbering of sequence numbers was corrected for streams with packed PB. 6) Proper poll mechanism has been included - Previously poll would not distinguish between queues. == Changes since v6 == 1) Stream seeking handling - done by running stream off and then stream on from another point of the stream 2) Support for streams during which the resolution is changed - done by calling stream off, reallocating the buffers and stream on again to resume 3) Power domain handling 4) Clock gating hw related operations - This has introduced a large reduction in power use 5) Support for IOMMU allocator - Using IOMMU as the memory allocator removes the cache problem and the need for reserving continuous memory at system boot 6) Flags of v4l2_buffer are set accordingly to the returned buffer frame type V4L2_BUF_FLAG_(KEY|P|B)FRAME 7) Fixed display delay handling of H264. Now dealy of 0 frames is possible, although it may cause that the frames are returned out of order. 8) Minor changes - global s5p_mfc_dev variable has been removed - improved Packed PB handling - fixed error handling - separate for decoding and display frames - some cosmetic changes to simplify the code and make it more readable ==
[PATCH 2/4 v9] v4l: add control definitions for codec devices.
Add control definitions and documentation for controls specific to codec devices. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml | 958 ++ include/linux/videodev2.h| 171 + 2 files changed, 1129 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 6880798..6b0d06a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry + entryinteger/entry + entryThis is a read-only control that can be read by the application +and used as a hint to determine the number of CAPTURE buffers to pass to REQBUFS. +The value is the minimum number of CAPTURE buffers that is necessary for hardware +to work./entry + /row + row + entryconstantV4L2_CID_MIN_BUFFERRS_FOR_OUTPUT/constant/entry + entryinteger/entry + entryThis is a read-only control that can be read by the application +and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. +The value is the minimum number of OUTPUT buffers that is necessary for hardware +to work./entry + /row + row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry entryID of the first custom (driver specific) control. @@ -1409,6 +1425,948 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit /tbody /entrytbl /row + + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf enabled the decoder expects a single slice in one OUTPUT buffer, otherwise +the decoder expects a single frame in one input buffer. Applicable to the decoder, all codecs. +/entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnable writing sample aspect ratio in the Video Usability Information. +Applicable to the H264 encoder./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_video_h264_vui_sar_idc/entry + /row + rowentry spanname=descrVUI sample aspect ratio indicator for H.264 encoding. The value +is defined in the table E-1 in the standard. Applicable to the H264 encoder./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_UNSPECIFIED/constantnbsp;/entry + entryUnspecified/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_1x1/constantnbsp;/entry + entry1x1/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_12x11/constantnbsp;/entry + entry12x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_10x11/constantnbsp;/entry + entry10x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_16x11/constantnbsp;/entry + entry16x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_40x33/constantnbsp;/entry + entry40x33/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_24x11/constantnbsp;/entry + entry24x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_20x11/constantnbsp;/entry + entry20x11/entry + /row + row +
[PATCH 3/4 v9] v4l2-ctrl: add codec controls support to the control framework
Add support for the codec controls to the v4l2 control framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ctrls.c | 281 ++
1 files changed, 281 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..acc76f5 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -216,6 +216,118 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
75 useconds,
NULL,
};
+ static const char * const multi_slice[] = {
+ Single,
+ Max macroblocks,
+ Max bits,
+ NULL,
+ };
+ static const char * const force_frame[] = {
+ Disabled,
+ I frame,
+ Not coded,
+ NULL,
+ };
+ static const char * const header_mode[] = {
+ Separate buffer,
+ Joined with 1st frame,
+ NULL,
+ };
+ static const char * const frame_skip[] = {
+ Disabled,
+ Level limit,
+ VBV/CPB limit,
+ NULL,
+ };
+ static const char * const h264_profile[] = {
+ Baseline,
+ Constrained Baseline,
+ Main,
+ Extended,
+ High,
+ High 10,
+ High 422,
+ High 444 Predictive,
+ High 10 Intra,
+ High 422 Intra,
+ High 444 Intra,
+ CAVLC 444 Intra,
+ Scalable Baseline,
+ Scalable High,
+ Scalable High Intra,
+ Multiview High,
+ NULL,
+ };
+ static const char * const mpeg4_profile[] = {
+ Simple,
+ Adcanved simple,
+ Core,
+ Simple scalable,
+ Advanced Coding Efficency,
+ NULL,
+ };
+ static const char * const mpeg_h264_level[] = {
+ 1,
+ 1b,
+ 1.1,
+ 1.2,
+ 1.3,
+ 2,
+ 2.1,
+ 2.2,
+ 3,
+ 3.1,
+ 3.2,
+ 4,
+ 4.1,
+ 4.2,
+ 5,
+ 5.1,
+ NULL,
+ };
+ static const char * const mpeg_mpeg4_level[] = {
+ 0,
+ 0b,
+ 1,
+ 2,
+ 3,
+ 3b,
+ 4,
+ 5,
+ NULL,
+ };
+ static const char * const h264_loop_filter[] = {
+ Enabled,
+ Disabled,
+ Disabled at slice boundary,
+ NULL,
+ };
+ static const char * const symbol_mode[] = {
+ CAVLC,
+ CABAC,
+ NULL,
+ };
+ static const char * vui_sar_idc[] = {
+ Unspecified,
+ 1:1,
+ 12:11,
+ 10:11,
+ 16:11,
+ 40:33,
+ 24:11,
+ 20:11,
+ 32:11,
+ 80:33,
+ 18:11,
+ 15:11,
+ 64:33,
+ 160:99,
+ 4:3,
+ 3:2,
+ 2:1,
+ Extended SAR,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -256,6 +368,28 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
+ return multi_slice;
+ case V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE:
+ return force_frame;
+ case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
+ return header_mode;
+ case V4L2_CID_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE:
+ return frame_skip;
+ case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
+ return h264_profile;
+ case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
+ return mpeg_h264_level;
+ case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+ return mpeg_mpeg4_level;
+ case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
+ return h264_loop_filter;
+ case V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE:
+ return symbol_mode;
+ case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
+ return mpeg4_profile;
+ case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
+ return vui_sar_idc;
default:
return NULL;
}
@@ -389,6 +523,72 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
case
[PATCH 1/4 v9] v4l: add fourcc definitions for compressed formats.
Add fourcc definitions and documentation for the following compressed formats: H264, H264 without start codes, MPEG1/2/4 ES, DIVX versions 3.11, 4, 5.0-5.0.2, 5.03 and up, XVID, VC1 Annex G and Annex L compliant. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml |7 ++- Documentation/DocBook/media/v4l/pixfmt.xml | 67 +- include/linux/videodev2.h| 21 +++-- 3 files changed, 88 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a920ee8..6880798 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -670,7 +670,8 @@ caption of a Tab page in a GUI, for example./entry /rowrowentry spanname=descrThe MPEG-1, -2 or -4 output stream type. One cannot assume anything here. Each hardware MPEG encoder tends to support different subsets of the available MPEG -stream types. The currently defined stream types are:/entry +stream types. This control is specific to multiplexed MPEG streams. +The currently defined stream types are:/entry /row row entrytbl spanname=descr cols=2 @@ -800,6 +801,7 @@ frequency. Possible values are:/entry entry spanname=idconstantV4L2_CID_MPEG_AUDIO_ENCODING/constantnbsp;/entry entryenumnbsp;v4l2_mpeg_audio_encoding/entry /rowrowentry spanname=descrMPEG Audio encoding. +This control is specific to multiplexed MPEG streams. Possible values are:/entry /row row @@ -1250,7 +1252,8 @@ and reproducible audio bitstream. 0 = unmuted, 1 = muted./entry entry spanname=idconstantV4L2_CID_MPEG_VIDEO_ENCODING/constantnbsp;/entry entryenumnbsp;v4l2_mpeg_video_encoding/entry /rowrowentry spanname=descrMPEG Video encoding -method. Possible values are:/entry +method. This control is specific to multiplexed MPEG streams. +Possible values are:/entry /row row entrytbl spanname=descr cols=2 diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 88e5c21..7f0f447 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -741,10 +741,75 @@ information./para row id=V4L2-PIX-FMT-MPEG entryconstantV4L2_PIX_FMT_MPEG/constant/entry entry'MPEG'/entry - entryMPEG stream. The actual format is determined by + entryMPEG multiplexed stream. The actual format is determined by extended control constantV4L2_CID_MPEG_STREAM_TYPE/constant, see xref linkend=mpeg-control-id /./entry /row + row id=V4L2-PIX-FMT-H264 + entryconstantV4L2_PIX_FMT_H264/constant/entry + entry'H264'/entry + entryH264 video elementary stream with start codes./entry + /row + row id=V4L2-PIX-FMT-H264-NO-SC + entryconstantV4L2_PIX_FMT_H264_NO_SC/constant/entry + entry'AVC1'/entry + entryH264 video elementary stream without start codes./entry + /row + row id=V4L2-PIX-FMT-H263 + entryconstantV4L2_PIX_FMT_H263/constant/entry + entry'H263'/entry + entryH263 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG1 + entryconstantV4L2_PIX_FMT_MPEG1/constant/entry + entry'MPG1'/entry + entryMPEG1 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG2 + entryconstantV4L2_PIX_FMT_MPEG2/constant/entry + entry'MPG2'/entry + entryMPEG2 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG4 + entryconstantV4L2_PIX_FMT_MPEG4/constant/entry + entry'MPG4'/entry + entryMPEG4 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-DIVX3 + entryconstantV4L2_PIX_FMT_DIVX3/constant/entry + entry'DIV3'/entry + entryDivx 3.11 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-DIVX4 + entryconstantV4L2_PIX_FMT_DIVX4/constant/entry + entry'DIV4'/entry + entryDivx 4 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-DIVX500 + entryconstantV4L2_PIX_FMT_DIVX500/constant/entry + entry'DX50'/entry + entryDivx 5.0-5.0.2 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-DIVX5 + entryconstantV4L2_PIX_FMT_DIVX5/constant/entry + entry'DIV5'/entry + entryDivx 5.0.3+ video elementary
Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote: Please explain the exact requirements that lead you to defining multiple contexts. On Tuesday 14 June 2011, Michal Nazarewicz wrote: Some devices may have access only to some banks of memory. Some devices may use different banks of memory for different purposes. On Tue, 14 Jun 2011 18:03:00 +0200, Arnd Bergmann wrote: For all I know, that is something that is only true for a few very special Samsung devices, Maybe. I'm just answering your question. :) Ah yes, I forgot that separate regions for different purposes could decrease fragmentation. I would suggest going forward without having multiple regions: Is having support for multiple regions a bad thing? Frankly, removing this support will change code from reading context passed as argument to code reading context from global variable. Nothing is gained; functionality is lost. * Remove the registration of specific addresses from the initial patch set (but keep the patch). * Add a heuristic plus command-line override to automatically come up with a reasonable location+size for *one* CMA area in the system. I'm not arguing those. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal mina86 Nazarewicz(o o) ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: buffer index when streaming user-ptr buffers
Hi Michael, On Tuesday 14 June 2011 17:50:13 Michael Jones wrote: In the V4L2 spec, the description for v4l2_buffer.index says This field is only used for memory mapping I/O... However, in v4l-utils/contrib/capture-example.c, even user-pointer buffers are indeed given a buf.index before being passed to VIDIOC_QBUF. And at least in the OMAP ISP driver, this information is relied upon in QBUF regardless of V4L2_MEMORY_MMAP/USERPTR. videobuf-core also uses v4l2_buffer-index even if b-memory == V4L2_MEMORY_USERPTR. Is this a bug in the OMAP driver and videobuf-core, and an unnecessary assignment in capture-example? Or is the V4L2 spec out of touch/ out of date? The spec is out of date. The index field is used for userptr buffers as well. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
Hi, On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote: On Tuesday 14 June 2011, Michal Nazarewicz wrote: On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote: Please explain the exact requirements that lead you to defining multiple contexts. Some devices may have access only to some banks of memory. Some devices may use different banks of memory for different purposes. For all I know, that is something that is only true for a few very special Samsung devices, and is completely unrelated of the need for contiguous allocations, so this approach becomes pointless as soon as the next generation of that chip grows an IOMMU, where we don't handle the special bank attributes. Also, the way I understood the situation for the Samsung SoC during the Budapest discussion, it's only a performance hack, not a functional requirement, unless you count '1080p playback' as a functional requirement. Hm, I think that was something similar but not quite the same: talking about having allocations split to lie between two banks of RAM to maximise the read/write speed for performance reasons. That's something that can be handled in the allocator, rather than an API constraint, as this is. Not that I know of any hardware which is limited as such, but eh. Cheers, Daniel -- 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 08/10] mm: cma: Contiguous Memory Allocator added
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote: On Tue, 14 Jun 2011 18:03:00 +0200, Arnd Bergmann wrote: For all I know, that is something that is only true for a few very special Samsung devices, Maybe. I'm just answering your question. :) Ah yes, I forgot that separate regions for different purposes could decrease fragmentation. That is indeed a good point, but having a good allocator algorithm could also solve this. I don't know too much about these allocation algorithms, but there are probably multiple working approaches to this. I would suggest going forward without having multiple regions: Is having support for multiple regions a bad thing? Frankly, removing this support will change code from reading context passed as argument to code reading context from global variable. Nothing is gained; functionality is lost. What is bad IMHO is making them the default, which forces the board code to care about memory management details. I would much prefer to have contiguous allocation parameters tuned automatically to just work on most boards before we add ways to do board-specific hacks. 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
Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote: Is having support for multiple regions a bad thing? Frankly, removing this support will change code from reading context passed as argument to code reading context from global variable. Nothing is gained; functionality is lost. On Tue, 14 Jun 2011 20:30:07 +0200, Arnd Bergmann wrote: What is bad IMHO is making them the default, which forces the board code to care about memory management details. I would much prefer to have contiguous allocation parameters tuned automatically to just work on most boards before we add ways to do board-specific hacks. I see those as orthogonal problems. The code can have support for multiple contexts but by default use a single global context exported as cma_global variable (or some such). And I'm not arguing against having “contiguous allocation parameters tuned automatically to just work on most boards”. I just don't see the reason to delete functionality that is already there, does not add much code and can be useful. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal mina86 Nazarewicz(o o) ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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:Tue Jun 14 19:00:32 CEST 2011 git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc 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: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS 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: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On 14 June 2011 12:01, Daniel Stone dani...@collabora.com wrote: Hi, On Tue, Jun 14, 2011 at 06:03:00PM +0200, Arnd Bergmann wrote: On Tuesday 14 June 2011, Michal Nazarewicz wrote: On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote: Please explain the exact requirements that lead you to defining multiple contexts. Some devices may have access only to some banks of memory. Some devices may use different banks of memory for different purposes. For all I know, that is something that is only true for a few very special Samsung devices, and is completely unrelated of the need for contiguous allocations, so this approach becomes pointless as soon as the next generation of that chip grows an IOMMU, where we don't handle the special bank attributes. Also, the way I understood the situation for the Samsung SoC during the Budapest discussion, it's only a performance hack, not a functional requirement, unless you count '1080p playback' as a functional requirement. Coming in mid topic... I've seen this split bank allocation in Qualcomm and TI SoCs, with Samsung, that makes 3 major SoC vendors (I would be surprised if Nvidia didn't also need to do this) - so I think some configurable method to control allocations is necessarily. The chips can't do decode without it (and by can't do I mean 1080P and higher decode is not functionally useful). Far from special, this would appear to be the default. Hm, I think that was something similar but not quite the same: talking about having allocations split to lie between two banks of RAM to maximise the read/write speed for performance reasons. That's something that can be handled in the allocator, rather than an API constraint, as this is. Not that I know of any hardware which is limited as such, but eh. Cheers, Daniel ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- 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: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote: I've seen this split bank allocation in Qualcomm and TI SoCs, with Samsung, that makes 3 major SoC vendors (I would be surprised if Nvidia didn't also need to do this) - so I think some configurable method to control allocations is necessarily. The chips can't do decode without it (and by can't do I mean 1080P and higher decode is not functionally useful). Far from special, this would appear to be the default. Thanks for the insight, that's a much better argument than 'something may need it'. Are those all chips without an IOMMU or do we also need to solve the IOMMU case with split bank allocation? I think I'd still prefer to see the support for multiple regions split out into one of the later patches, especially since that would defer the question of how to do the initialization for this case and make sure we first get a generic way. You've convinced me that we need to solve the problem of allocating memory from a specific bank eventually, but separating it from the one at hand (contiguous allocation) should help getting the important groundwork in at first. The possible conflict that I still see with per-bank CMA regions are: * It completely destroys memory power management in cases where that is based on powering down entire memory banks. * We still need to solve the same problem in case of IOMMU mappings at some point, even if today's hardware doesn't have this combination. It would be good to use the same solution for both. 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
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On 06/14/2011 02:42 PM, Arnd Bergmann wrote: On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote: I've seen this split bank allocation in Qualcomm and TI SoCs, with Samsung, that makes 3 major SoC vendors (I would be surprised if Nvidia didn't also need to do this) - so I think some configurable method to control allocations is necessarily. The chips can't do decode without it (and by can't do I mean 1080P and higher decode is not functionally useful). Far from special, this would appear to be the default. Thanks for the insight, that's a much better argument than 'something may need it'. Are those all chips without an IOMMU or do we also need to solve the IOMMU case with split bank allocation? Yes. The IOMMU case with split bank allocation is key, especially for shared buffers. Consider the case where video is using a certain bank for performance purposes and that frame is shared with the GPU. Jordan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] marvell-cam: Move cafe-ccic into its own directory
Jon, if you agree to change it in another patch, and now just to keep it with the driver that works for years. that is OK. thanks. I am looking forward your patch based on VB2, because based on current cafe_ccic.c, it is hard to share with my driver. 2011/6/14 Jonathan Corbet cor...@lwn.net: On Tue, 14 Jun 2011 10:23:58 +0800 Kassey Lee kassey1...@gmail.com wrote: Jon, Here is my comments. Thanks for having a look. +config VIDEO_CAFE_CCIC + tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support + depends on PCI I2C VIDEO_V4L2 + select VIDEO_OV7670 why need binds with sensor ? suppose CCIC driver and sensor driver are independent, even if your hardware only support OV7670 We all agree that needs to change. This particular patch, though, is concerned with moving a working driver into a new directory; making that sort of functional change would not be appropriate here. +#include media/ov7670.h ccic would not be aware of the sensor name. Ditto. Thanks, jon -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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
