[PATCH 0/1 v2] media/video: vpif: fixing function name start to vpif_config_params
This patch address the issue that a function named config_vpif_params should be vpif_config_params. However this name is shared with two structures defined already. So I changed the structures to config_vpif_params (origin was vpif_config_params) v2 changes: softer wording in description and the structs are now defined without _t Dror Cohen (1): fixing function name start to vpif_config_params drivers/media/video/davinci/vpif.c |6 +++--- drivers/media/video/davinci/vpif_capture.c |2 +- drivers/media/video/davinci/vpif_capture.h |2 +- drivers/media/video/davinci/vpif_display.c |2 +- drivers/media/video/davinci/vpif_display.h |2 +- 5 files changed, 7 insertions(+), 7 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1 v2] media/video: vpif: fixing function name start to vpif_config_params
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index af96802..04dd8fa 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -301,12 +301,12 @@ static void vpif_set_mode_info(const struct
vpif_channel_config_params *config,
regw(value, vpifregs[channel_id].v_cfg);
}
-/* config_vpif_params
+/* vpif_config_params
* Function to set the parameters of a channel
* Mainly modifies the channel ciontrol register
* It sets frame format, yc mux mode
*/
-static void config_vpif_params(struct vpif_params *vpifparams,
+static void vpif_config_params(struct vpif_params *vpifparams,
u8 channel_id, u8 found)
{
const struct vpif_channel_config_params *config = vpifparams-std_info;
@@ -374,7 +374,7 @@ int vpif_set_video_params(struct vpif_params *vpifparams,
u8 channel_id)
found = 2;
}
- config_vpif_params(vpifparams, channel_id, found);
+ vpif_config_params(vpifparams, channel_id, found);
regw(0x80, VPIF_REQ_SIZE);
regw(0x01, VPIF_EMULATION_CTRL);
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 9604695..59104e6 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -67,7 +67,7 @@ MODULE_PARM_DESC(ch3_numbuffers, Channel1 buffer count
(default:3));
MODULE_PARM_DESC(ch2_bufsize, Channel0 buffer size (default:1920 x 1080 x
2));
MODULE_PARM_DESC(ch3_bufsize, Channel1 buffer size (default:720 x 576 x 2));
-static struct vpif_config_params config_params = {
+static struct config_vpif_params config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index a693d4e..8863de1 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -144,7 +144,7 @@ struct vpif_device {
struct v4l2_subdev **sd;
};
-struct vpif_config_params {
+struct config_vpif_params {
u8 min_numbuffers;
u8 numbuffers[VPIF_CAPTURE_NUM_CHANNELS];
s8 device_type;
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index e6488ee..652440d 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -70,7 +70,7 @@ MODULE_PARM_DESC(ch3_numbuffers, Channel3 buffer count
(default:3));
MODULE_PARM_DESC(ch2_bufsize, Channel2 buffer size (default:1920 x 1080 x
2));
MODULE_PARM_DESC(ch3_bufsize, Channel3 buffer size (default:720 x 576 x 2));
-static struct vpif_config_params config_params = {
+static struct config_vpif_params config_params = {
.min_numbuffers = 3,
.numbuffers[0] = 3,
.numbuffers[1] = 3,
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index 56879d1..3e14807 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -154,7 +154,7 @@ struct vpif_device {
};
-struct vpif_config_params {
+struct config_vpif_params {
u32 min_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u32 channel_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
u8 numbuffers[VPIF_DISPLAY_NUM_CHANNELS];
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
Hello Konke, On 8/7/12 5:11 PM, Konke Radlow wrote: diff --git a/configure.ac b/configure.ac index 8ddcc9d..1109c4d 100644 --- a/configure.ac +++ b/configure.ac @@ -146,9 +148,12 @@ AC_ARG_WITH(libv4l2subdir, AS_HELP_STRING(--with-libv4l2subdir=DIR,set libv4l2 l AC_ARG_WITH(libv4lconvertsubdir, AS_HELP_STRING(--with-libv4lconvertsubdir=DIR,set libv4lconvert library subdir [default=libv4l]), libv4lconvertsubdir=$withval, libv4lconvertsubdir=libv4l) +AC_ARG_WITH(libv4l2rdssubdir, AS_HELP_STRING(--with-libv4l2rdssubdir=DIR,set libv4l2rds library subdir [default=libv4l]), + libv4l2rdssubdir=$withval, libv4l2rdssubdir=libv4l) + AC_ARG_WITH(udevdir, AS_HELP_STRING(--with-udevdir=DIR,set udev directory [default=/lib/udev]), udevdir=$withval, udevdir=/lib/udev) - + libv4l1privdir=$libdir/$libv4l1subdir libv4l2privdir=$libdir/$libv4l2subdir libv4l2plugindir=$libv4l2privdir/plugins please remove these changes. They are not needed for the RDS library. Thanks, Gregor -- 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: build docs fails: parser error : Failure to process entity sub-enum-freq-bands
It works for me. make DOCBOOKS=media_api.xml htmldocs Perhaps you need to do a make cleandocs first? Regards, Hans On Thu August 9 2012 01:17:57 Antti Palosaari wrote: That is from current staging/for_v3.7 [crope@localhost linux]$ make htmldocs HTMLDocumentation/DocBook/media_api.html warning: failed to load external entity /home/crope/linuxtv/code/linux/Documentation/DocBook/vidioc-enum-freq-bands.xml /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Failure to process entity sub-enum-freq-bands sub-enum-freq-bands; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Entity 'sub-enum-freq-bands' not defined sub-enum-freq-bands; ^ warning: failed to load external entity /home/crope/linuxtv/code/linux/Documentation/DocBook/selections-common.xml /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Failure to process entity sub-selections-common sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Entity 'sub-selections-common' not defined sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:625: parser error : chunk is not well balanced ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Failure to process entity sub-v4l2 sub-v4l2; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Entity 'sub-v4l2' not defined sub-v4l2; ^ unable to parse /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml /usr/bin/cp: cannot stat `*.*htm*': No such file or directory make[1]: *** [Documentation/DocBook/media_api.html] Error 1 make: *** [htmldocs] Error 2 [crope@localhost linux]$ regards Antti -- 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: build docs fails: parser error : Failure to process entity sub-enum-freq-bands
On 08/09/2012 10:29 AM, Hans Verkuil wrote: It works for me. make DOCBOOKS=media_api.xml htmldocs Perhaps you need to do a make cleandocs first? make cleandocs resolves the problems. Sorry for the noise. regards Antti Regards, Hans On Thu August 9 2012 01:17:57 Antti Palosaari wrote: That is from current staging/for_v3.7 [crope@localhost linux]$ make htmldocs HTMLDocumentation/DocBook/media_api.html warning: failed to load external entity /home/crope/linuxtv/code/linux/Documentation/DocBook/vidioc-enum-freq-bands.xml /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Failure to process entity sub-enum-freq-bands sub-enum-freq-bands; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:542: parser error : Entity 'sub-enum-freq-bands' not defined sub-enum-freq-bands; ^ warning: failed to load external entity /home/crope/linuxtv/code/linux/Documentation/DocBook/selections-common.xml /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Failure to process entity sub-selections-common sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:600: parser error : Entity 'sub-selections-common' not defined sub-selections-common; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/v4l2.xml:625: parser error : chunk is not well balanced ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Failure to process entity sub-v4l2 sub-v4l2; ^ /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml:73: parser error : Entity 'sub-v4l2' not defined sub-v4l2; ^ unable to parse /home/crope/linuxtv/code/linux/Documentation/DocBook/media_api.xml /usr/bin/cp: cannot stat `*.*htm*': No such file or directory make[1]: *** [Documentation/DocBook/media_api.html] Error 1 make: *** [htmldocs] Error 2 [crope@localhost linux]$ regards Antti -- http://palosaari.fi/ -- 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/2] dma-buf: add reference counting for exporter module
This patch adds reference counting on a module that exported dma-buf and
implements its operations. This prevents the module from being unloaded while
DMABUF file is in use.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
CC: linux-...@vger.kernel.org
---
Documentation/dma-buf-sharing.txt |3 ++-
drivers/base/dma-buf.c|9 -
include/linux/dma-buf.h |2 ++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index ad86fb8..2613057 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -49,7 +49,8 @@ The dma_buf buffer sharing API usage contains the following
steps:
The buffer exporter announces its wish to export a buffer. In this, it
connects its own private buffer data, provides implementation for operations
that can be performed on the exported dma_buf, and flags for the file
- associated with this buffer.
+ associated with this buffer. The operations structure has owner field.
+ You should initialize this to THIS_MODULE in most cases.
Interface:
struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..a1d9cab 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -27,6 +27,7 @@
#include linux/dma-buf.h
#include linux/anon_inodes.h
#include linux/export.h
+#include linux/module.h
static inline int is_dma_buf_file(struct file *);
@@ -40,6 +41,7 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file-private_data;
dmabuf-ops-release(dmabuf);
+ module_put(dmabuf-ops-owner);
kfree(dmabuf);
return 0;
}
@@ -105,9 +107,14 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}
+ if (!try_module_get(ops-owner))
+ return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
- if (dmabuf == NULL)
+ if (dmabuf == NULL) {
+ module_put(ops-owner);
return ERR_PTR(-ENOMEM);
+ }
dmabuf-priv = priv;
dmabuf-ops = ops;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..22953de 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -37,6 +37,7 @@ struct dma_buf_attachment;
/**
* struct dma_buf_ops - operations possible on struct dma_buf
+ * @owner: the module that implements dma_buf operations
* @attach: [optional] allows different devices to 'attach' themselves to the
* given buffer. It might return -EBUSY to signal that backing storage
* is already allocated and incompatible with the requirements
@@ -70,6 +71,7 @@ struct dma_buf_attachment;
* @vunmap: [optional] unmaps a vmap from the buffer
*/
struct dma_buf_ops {
+ struct module *owner;
int (*attach)(struct dma_buf *, struct device *,
struct dma_buf_attachment *);
--
1.7.9.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 v2 2/2] drm: set owner field to for all DMABUF exporters
This patch sets owner field in DMABUF operations for all DMABUF exporters in
DRM subsystem. This prevents an exporting module from being unloaded while
exported DMABUF descriptor is in use.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
drivers/gpu/drm/nouveau/nouveau_prime.c|1 +
drivers/gpu/drm/radeon/radeon_prime.c |1 +
drivers/staging/omapdrm/omap_gem_dmabuf.c |1 +
5 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 613bf8a..cf3bc6d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -164,6 +164,7 @@ static void exynos_gem_dmabuf_kunmap(struct dma_buf
*dma_buf,
}
static struct dma_buf_ops exynos_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf= exynos_gem_map_dma_buf,
.unmap_dma_buf = exynos_gem_unmap_dma_buf,
.kmap = exynos_gem_dmabuf_kmap,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index aa308e1..07ff03b 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -152,6 +152,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
}
static const struct dma_buf_ops i915_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = i915_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index a25cf2c..8605033 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -127,6 +127,7 @@ static void nouveau_gem_prime_vunmap(struct dma_buf
*dma_buf, void *vaddr)
}
static const struct dma_buf_ops nouveau_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = nouveau_gem_map_dma_buf,
.unmap_dma_buf = nouveau_gem_unmap_dma_buf,
.release = nouveau_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
b/drivers/gpu/drm/radeon/radeon_prime.c
index 6bef46a..4061fd3 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -127,6 +127,7 @@ static void radeon_gem_prime_vunmap(struct dma_buf
*dma_buf, void *vaddr)
mutex_unlock(dev-struct_mutex);
}
const static struct dma_buf_ops radeon_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = radeon_gem_map_dma_buf,
.unmap_dma_buf = radeon_gem_unmap_dma_buf,
.release = radeon_gem_dmabuf_release,
diff --git a/drivers/staging/omapdrm/omap_gem_dmabuf.c
b/drivers/staging/omapdrm/omap_gem_dmabuf.c
index 42728e0..6a4dd67 100644
--- a/drivers/staging/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/staging/omapdrm/omap_gem_dmabuf.c
@@ -179,6 +179,7 @@ out_unlock:
}
struct dma_buf_ops omap_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = omap_gem_map_dma_buf,
.unmap_dma_buf = omap_gem_unmap_dma_buf,
.release = omap_gem_dmabuf_release,
--
1.7.9.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 v2 0/2] Enhance DMABUF with reference counting for exporter module
Hello, This patchset adds reference counting for an exporter module to DMABUF framework. Moreover, it adds setup of an owner field for exporters in DRM subsystem. v1: Original v2: - split patch into DMABUF and DRM part - allow owner to be NULL Regards, Tomasz Stanislawski Tomasz Stanislawski (2): dma-buf: add reference counting for exporter module drm: set owner field to for all DMABUF exporters Documentation/dma-buf-sharing.txt |3 ++- drivers/base/dma-buf.c |9 - drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 + drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 + drivers/gpu/drm/nouveau/nouveau_prime.c|1 + drivers/gpu/drm/radeon/radeon_prime.c |1 + drivers/staging/omapdrm/omap_gem_dmabuf.c |1 + include/linux/dma-buf.h|2 ++ 8 files changed, 17 insertions(+), 2 deletions(-) -- 1.7.9.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: [PATCH 1/3] dma-fence: dma-buf synchronization (v7)
Hey Sumit, Op 08-08-12 08:35, Sumit Semwal schreef: Hi Maarten, On 8 August 2012 00:17, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Op 07-08-12 19:53, Maarten Lankhorst schreef: A dma-fence can be attached to a buffer which is being filled or consumed by hw, to allow userspace to pass the buffer without waiting to another device. For example, userspace can call page_flip ioctl to display the next frame of graphics after kicking the GPU but while the GPU is still rendering. The display device sharing the buffer with the GPU would attach a callback to get notified when the GPU's rendering-complete IRQ fires, to update the scan-out address of the display, without having to wake up userspace. Thanks for this patchset; Could you please also fill up Documentation/dma-buf-sharing.txt, to include the relevant bits? We've tried to make sure the Documentation corresponding is kept up-to-date as the framework has grown, and new features are added to it - and I think features as important as dma-fence and dmabufmgr do warrant a healthy update. Ok I'll clean it up and add the documentation, one other question. If code that requires dmabuf needs to select CONFIG_DMA_SHARED_BUFFER, why does dma-buf.h have fallbacks for !CONFIG_DMA_SHARED_BUFFER? This seems weird, would you have any objection if I removed those? ~Maarten -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] Update MFC v4l2 driver to support MFC6.x
The patchset adds support for MFCv6 firmware in s5p-mfc driver. The first two patches will update the existing MFCv5 driver framework for making it suitable for supporting co-existence with a newer hardware version. The last two patches add support for MFCv6 firmware. This patchset have to be applied on patches [1] and [2] posted earlier which adds the required v4l2 controls. Changelog: - Separate patch for callback based architecture. - Patches divided to enable incremental compilation. - Working MFCv6 encoder and decoder. - Addressed review comments given for v3 patchset. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48972.html [2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48973.html Arun Kumar K (1): [media] s5p-mfc: Update MFCv5 driver for callback based architecture Jeongtae Park (3): [media] s5p-mfc: Add MFC variant data to device context [media] s5p-mfc: MFCv6 register definitions [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x drivers/media/video/Kconfig |4 +- drivers/media/video/s5p-mfc/Makefile |7 +- drivers/media/video/s5p-mfc/regs-mfc-v6.h| 429 ++ drivers/media/video/s5p-mfc/regs-mfc.h | 29 + drivers/media/video/s5p-mfc/s5p_mfc.c| 224 ++-- drivers/media/video/s5p-mfc/s5p_mfc_cmd.c| 98 +- drivers/media/video/s5p-mfc/s5p_mfc_cmd.h| 13 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c | 164 +++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 155 ++ drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/video/s5p-mfc/s5p_mfc_common.h | 156 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 188 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h |1 + drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 223 ++- drivers/media/video/s5p-mfc/s5p_mfc_dec.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 205 ++-- drivers/media/video/s5p-mfc/s5p_mfc_enc.h|1 + drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 11 +- drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 1405 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 178 ++- drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c | 1761 +++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h | 85 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1944 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/video/s5p-mfc/s5p_mfc_pm.c |3 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 47 - drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 90 -- 28 files changed, 5645 insertions(+), 1867 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.c delete mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.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 v4 2/4] [media] s5p-mfc: Add MFC variant data to device context
From: Jeongtae Park jtp.p...@samsung.com
MFC variant data replaces various macros used in the driver
which will change in a different version of MFC hardware.
Also does a cleanup of MFC context structure and common files.
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Signed-off-by: Janghyuck Kim janghyuck@samsung.com
Signed-off-by: Jaeryul Oh jaeryul...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/video/s5p-mfc/regs-mfc.h |2 +-
drivers/media/video/s5p-mfc/s5p_mfc.c| 78 +-
drivers/media/video/s5p-mfc/s5p_mfc_cmd_v5.c |4 +-
drivers/media/video/s5p-mfc/s5p_mfc_common.h | 66 ++---
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c |7 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 44 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr_v5.c | 213 +-
7 files changed, 243 insertions(+), 171 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/regs-mfc.h
b/drivers/media/video/s5p-mfc/regs-mfc.h
index a19bece..f596410 100644
--- a/drivers/media/video/s5p-mfc/regs-mfc.h
+++ b/drivers/media/video/s5p-mfc/regs-mfc.h
@@ -414,5 +414,5 @@
#define S5P_FIMV_SHARED_EXTENDED_SAR 0x0078
#define S5P_FIMV_SHARED_H264_I_PERIOD 0x009C
#define S5P_FIMV_SHARED_RC_CONTROL_CONFIG 0x00A0
-
+#define S5P_FIMV_SHARED_DISP_FRAME_TYPE_SHIFT 2
#endif /* _REGS_FIMV_H */
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index ab66680..be8d689 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -421,7 +421,6 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
unsigned int reason, unsigned int err)
{
struct s5p_mfc_dev *dev;
- unsigned int guard_width, guard_height;
if (ctx == NULL)
return;
@@ -433,40 +432,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx
*ctx,
ctx-img_width = s5p_mfc_get_img_width(dev);
ctx-img_height = s5p_mfc_get_img_height(dev);
- ctx-buf_width = ALIGN(ctx-img_width,
- S5P_FIMV_NV12MT_HALIGN);
- ctx-buf_height = ALIGN(ctx-img_height,
- S5P_FIMV_NV12MT_VALIGN);
- mfc_debug(2, SEQ Done: Movie dimensions %dx%d,
- buffer dimensions: %dx%d\n, ctx-img_width,
- ctx-img_height, ctx-buf_width,
- ctx-buf_height);
- if (ctx-codec_mode == S5P_FIMV_CODEC_H264_DEC) {
- ctx-luma_size = ALIGN(ctx-buf_width *
- ctx-buf_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-chroma_size = ALIGN(ctx-buf_width *
-ALIGN((ctx-img_height 1),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = ALIGN(ctx-buf_width *
- ALIGN((ctx-buf_height 2),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- } else {
- guard_width = ALIGN(ctx-img_width + 24,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN(ctx-img_height + 16,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-luma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- guard_width = ALIGN(ctx-img_width + 16,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN((ctx-img_height 1) + 4,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-chroma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = 0;
- }
+ s5p_mfc_dec_calc_dpb_size(ctx);
+
ctx-dpb_count = s5p_mfc_get_dpb_count(dev);
if (ctx-img_width == 0 || ctx-img_height == 0)
ctx-state = MFCINST_ERROR;
@@ -960,6 +927,9 @@ static int s5p_mfc_probe(struct platform_device *pdev)
return -ENODEV;
}
+ dev-variant = (struct s5p_mfc_variant *)
+ platform_get_device_id(pdev)-driver_data;
+
ret = s5p_mfc_init_pm(dev);
if (ret 0) {
dev_err(pdev-dev, failed to get mfc clock source\n);
@@ -1207,9 +1177,43 @@ static const struct dev_pm_ops s5p_mfc_pm_ops = {
NULL)
};
[PATCH v4 3/4] [media] s5p-mfc: MFCv6 register definitions
From: Jeongtae Park jtp.p...@samsung.com Adds register definitions for MFC v6.x firmware Signed-off-by: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Janghyuck Kim janghyuck@samsung.com Signed-off-by: Jaeryul Oh jaeryul...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/video/s5p-mfc/regs-mfc-v6.h | 429 + 1 files changed, 429 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h diff --git a/drivers/media/video/s5p-mfc/regs-mfc-v6.h b/drivers/media/video/s5p-mfc/regs-mfc-v6.h new file mode 100644 index 000..2f25c5d --- /dev/null +++ b/drivers/media/video/s5p-mfc/regs-mfc-v6.h @@ -0,0 +1,429 @@ +/* + * Register definition file for Samsung MFC V6.x Interface (FIMV) driver + * + * Copyright (c) 2012 Samsung Electronics + * http://www.samsung.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _REGS_FIMV_V6_H +#define _REGS_FIMV_V6_H + +#define S5P_FIMV_REG_SIZE_V6 (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) +#define S5P_FIMV_REG_COUNT_V6 ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4) + +/* Number of bits that the buffer address should be shifted for particular + * MFC buffers. */ +#define S5P_FIMV_MEM_OFFSET_V6 0 + +#define S5P_FIMV_START_ADDR_V6 0x +#define S5P_FIMV_END_ADDR_V6 0xfd80 + +#define S5P_FIMV_REG_CLEAR_BEGIN_V60xf000 +#define S5P_FIMV_REG_CLEAR_COUNT_V61024 + +/* Codec Common Registers */ +#define S5P_FIMV_RISC_ON_V60x +#define S5P_FIMV_RISC2HOST_INT_V6 0x003C +#define S5P_FIMV_HOST2RISC_INT_V6 0x0044 +#define S5P_FIMV_RISC_BASE_ADDRESS_V6 0x0054 + +#define S5P_FIMV_MFC_RESET_V6 0x1070 + +#define S5P_FIMV_HOST2RISC_CMD_V6 0x1100 +#define S5P_FIMV_H2R_CMD_EMPTY_V6 0 +#define S5P_FIMV_H2R_CMD_SYS_INIT_V6 1 +#define S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 2 +#define S5P_FIMV_CH_SEQ_HEADER_V6 3 +#define S5P_FIMV_CH_INIT_BUFS_V6 4 +#define S5P_FIMV_CH_FRAME_START_V6 5 +#define S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 6 +#define S5P_FIMV_H2R_CMD_SLEEP_V6 7 +#define S5P_FIMV_H2R_CMD_WAKEUP_V6 8 +#define S5P_FIMV_CH_LAST_FRAME_V6 9 +#define S5P_FIMV_H2R_CMD_FLUSH_V6 10 +/* RMVME: REALLOC used? */ +#define S5P_FIMV_CH_FRAME_START_REALLOC_V6 5 + +#define S5P_FIMV_RISC2HOST_CMD_V6 0x1104 +#define S5P_FIMV_R2H_CMD_EMPTY_V6 0 +#define S5P_FIMV_R2H_CMD_SYS_INIT_RET_V6 1 +#define S5P_FIMV_R2H_CMD_OPEN_INSTANCE_RET_V6 2 +#define S5P_FIMV_R2H_CMD_SEQ_DONE_RET_V6 3 +#define S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET_V6 4 + +#define S5P_FIMV_R2H_CMD_CLOSE_INSTANCE_RET_V6 6 +#define S5P_FIMV_R2H_CMD_SLEEP_RET_V6 7 +#define S5P_FIMV_R2H_CMD_WAKEUP_RET_V6 8 +#define S5P_FIMV_R2H_CMD_COMPLETE_SEQ_RET_V6 9 +#define S5P_FIMV_R2H_CMD_DPB_FLUSH_RET_V6 10 +#define S5P_FIMV_R2H_CMD_NAL_ABORT_RET_V6 11 +#define S5P_FIMV_R2H_CMD_FW_STATUS_RET_V6 12 +#define S5P_FIMV_R2H_CMD_FRAME_DONE_RET_V6 13 +#define S5P_FIMV_R2H_CMD_FIELD_DONE_RET_V6 14 +#define S5P_FIMV_R2H_CMD_SLICE_DONE_RET_V6 15 +#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16 +#define S5P_FIMV_R2H_CMD_ERR_RET_V632 + +#define S5P_FIMV_FW_VERSION_V6 0xF000 + +#define S5P_FIMV_INSTANCE_ID_V60xF008 +#define S5P_FIMV_CODEC_TYPE_V6 0xF00C +#define S5P_FIMV_CONTEXT_MEM_ADDR_V6 0xF014 +#define S5P_FIMV_CONTEXT_MEM_SIZE_V6 0xF018 +#define S5P_FIMV_PIXEL_FORMAT_V6 0xF020 + +#define S5P_FIMV_METADATA_ENABLE_V60xF024 +#define S5P_FIMV_DBG_BUFFER_ADDR_V60xF030 +#define S5P_FIMV_DBG_BUFFER_SIZE_V60xF034 +#define S5P_FIMV_RET_INSTANCE_ID_V60xF070 + +#define S5P_FIMV_ERROR_CODE_V6 0xF074 +#define S5P_FIMV_ERR_WARNINGS_START_V6 160 +#define S5P_FIMV_ERR_DEC_MASK_V6 0x +#define S5P_FIMV_ERR_DEC_SHIFT_V6 0 +#define S5P_FIMV_ERR_DSPL_MASK_V6 0x +#define S5P_FIMV_ERR_DSPL_SHIFT_V6 16 + +#define S5P_FIMV_DBG_BUFFER_OUTPUT_SIZE_V6 0xF078 +#define S5P_FIMV_METADATA_STATUS_V60xF07C +#define S5P_FIMV_METADATA_ADDR_MB_INFO_V6 0xF080 +#define S5P_FIMV_METADATA_SIZE_MB_INFO_V6 0xF084 + +/* Decoder Registers */ +#define S5P_FIMV_D_CRC_CTRL_V6 0xF0B0 +#define S5P_FIMV_D_DEC_OPTIONS_V6 0xF0B4 +#define S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V64 +#define S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6 3 +#define S5P_FIMV_D_OPT_LF_CTRL_SHIFT_V61
[GIT PULL FOR v3.6] DocBook fixes for 3.6
The first patch fixes a long standing invalid doc chunk first fixed by Sylwester here: http://patchwork.linuxtv.org/patch/11271/ I've taken that patch as is and only rebased it so it applies cleanly. It is in state 'Changes requested' but nobody ever actually requested any changes, and it is an obviously wrong piece of documentation that refers to something that doesn't exist. The second patch updates various copyright years and version numbers and updates a few other odds 'n ends that were never properly updated. Regards, Hans The following changes since commit c3707357c6c651652a87a05eabd7582f90a4: [media] az6007: Update copyright (2012-08-06 09:25:12 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git docfixes for you to fetch changes up to 1bb7364ed7f469186f5c1cc96dda399062097946: DocBook: various version/copyright year updates. (2012-08-09 13:00:58 +0200) Hans Verkuil (2): Remove documentation chunk of non-existent V4L2_CID_AUTO_FOCUS_AREA DocBook: various version/copyright year updates. Documentation/DocBook/media/dvb/dvbapi.xml |2 +- Documentation/DocBook/media/v4l/compat.xml | 16 Documentation/DocBook/media/v4l/v4l2.xml | 14 +++--- Documentation/DocBook/media_api.tmpl |9 + 4 files changed, 13 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwc: Use vb2 queue mutex through a single name
Hi, Thanks for the patch, I've added it to my tree for 3.7: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.7-wip Regards, Hans On 07/15/2012 08:00 AM, Ezequiel Garcia wrote: This lock was being taken using two different names (pointers) in the same function. Both names refer to the same lock, so this wasn't an error; but it looked very strange. Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- drivers/media/video/pwc/pwc-if.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c index de7c7ba..b5d0729 100644 --- a/drivers/media/video/pwc/pwc-if.c +++ b/drivers/media/video/pwc/pwc-if.c @@ -1127,7 +1127,7 @@ static void usb_pwc_disconnect(struct usb_interface *intf) v4l2_device_disconnect(pdev-v4l2_dev); video_unregister_device(pdev-vdev); mutex_unlock(pdev-v4l2_lock); - mutex_unlock(pdev-vb_queue.lock); + mutex_unlock(pdev-vb_queue_lock); #ifdef CONFIG_USB_PWC_INPUT_EVDEV if (pdev-button_dev) -- 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] [media] gspca: dubious one-bit signed bitfield
Hi,
Thanks for the patch, I've added it to my tree for 3.7:
http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.7-wip
Regards,
Hans
On 08/05/2012 02:34 PM, Emil Goode wrote:
This patch changes some signed integers to unsigned because
they are not intended for negative values and sparse
is making noise about it.
Sparse gives eight of these errors:
drivers/media/video/gspca/ov519.c:144:29: error: dubious one-bit signed bitfield
Signed-off-by: Emil Goode emilgo...@gmail.com
---
drivers/media/video/gspca/ov519.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/gspca/ov519.c
b/drivers/media/video/gspca/ov519.c
index bfc7cef..c1a21bf 100644
--- a/drivers/media/video/gspca/ov519.c
+++ b/drivers/media/video/gspca/ov519.c
@@ -141,14 +141,14 @@ enum sensors {
/* table of the disabled controls */
struct ctrl_valid {
- int has_brightness:1;
- int has_contrast:1;
- int has_exposure:1;
- int has_autogain:1;
- int has_sat:1;
- int has_hvflip:1;
- int has_autobright:1;
- int has_freq:1;
+ unsigned int has_brightness:1;
+ unsigned int has_contrast:1;
+ unsigned int has_exposure:1;
+ unsigned int has_autogain:1;
+ unsigned int has_sat:1;
+ unsigned int has_hvflip:1;
+ unsigned int has_autobright:1;
+ unsigned int has_freq:1;
};
static const struct ctrl_valid valid_controls[] = {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.6-rc1] media updates part 2
Em 08-08-2012 19:28, David Rientjes escreveu: On Tue, 31 Jul 2012, Mauro Carvalho Chehab wrote: [media] radio-shark: New driver for the Griffin radioSHARK USB radio receiver This one gives me a build warning if CONFIG_LEDS_CLASS is disabled: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Could you please test the enclosed patch? Thanks! Mauro - [media] radio-shark: make sure LEDS_CLASS is selected As reported by David: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Reported-by: Dadiv Rientjes rient...@google.com Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 8090b87..be68ec2 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -60,6 +60,7 @@ config RADIO_MAXIRADIO config RADIO_SHARK tristate Griffin radioSHARK USB radio receiver depends on USB SND + select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. @@ -77,6 +78,7 @@ config RADIO_SHARK config RADIO_SHARK2 tristate Griffin radioSHARK2 USB radio receiver depends on USB + select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
Hi Konke,
As Gregor already mentioned there is no need to define libv4l2rdssubdir in
configure.ac ,
so please drop that.
Other then that I've some minor remarks (comments inline), with all those
fixed, this one is could to go. So hopefully the next version can be added
to git master!
On 08/07/2012 05:11 PM, Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac|7 +-
lib/include/libv4l2rds.h| 228 ++
lib/libv4l2rds/Makefile.am | 11 +
lib/libv4l2rds/libv4l2rds.c | 953 +++
lib/libv4l2rds/libv4l2rds.pc.in | 11 +
6 files changed, 1211 insertions(+), 2 deletions(-)
create mode 100644 lib/include/libv4l2rds.h
create mode 100644 lib/libv4l2rds/Makefile.am
create mode 100644 lib/libv4l2rds/libv4l2rds.c
create mode 100644 lib/libv4l2rds/libv4l2rds.pc.in
snip
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..4aa8593
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,228 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include time.h
+#include sys/types.h
+#include sys/mman.h
+#include config.h
You should never include config.h in a public header, also
are all the headers really needed for the prototypes in this header?
I don't think so! Please move all the unneeded ones to the libv4l2rds.c
file!
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if HAVE_VISIBILITY
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds struct */
+#define V4L2_RDS_VERSION (1)
+
What is the purpose of this field? Once we've released a v4l-utils with this
library we are stuck to the API we've defined, having a version field
changing it,
won't stop us from breaking existing apps, so once we've an official release we
simply cannot make ABI breaking changes, which is why most of my review sofar
has concentrated on the API side :)
I suggest dropping this define and the version field from the struct.
+/* Constants used to define the size of arrays used to store RDS information */
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
+* 32 distinct groups, 18 can be used for ODA purposes
*/
+#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be defined
+* AF Method B does not impose a limit on the number of
AFs
+* but it is not fully supported at the moment and will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_fields bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40/* Music / Speech flag */
+#define V4L2_RDS_PTYN 0x80/* Program Type Name */
+#define V4L2_RDS_RT0x100 /* Radio-Text */
+#define V4L2_RDS_TIME 0x200 /* Date and Time information */
+#define V4L2_RDS_TMC 0x400 /* TMC availability */
+#define V4L2_RDS_AF0x800 /* AF (alternative freq) available */
+#define V4L2_RDS_ECC 0x1000 /* Extended County Code */
+#define V4L2_RDS_LC0x2000 /* Language Code */
+
+/* Define Constants for the state of the RDS decoding process
+ * used to address the relevant bit in the decode_information bitmask */
+#define V4L2_RDS_GROUP_NEW 0x01/* New group received */
Re: [GIT PULL for 3.6-rc1] media updates part 2
Hi, My bad, sorry about this. Mauro's patch looks good. An alternative fix would be to #ifdefify the led code in the drivers themselves. Regards, Hans On 08/09/2012 01:38 PM, Mauro Carvalho Chehab wrote: Em 08-08-2012 19:28, David Rientjes escreveu: On Tue, 31 Jul 2012, Mauro Carvalho Chehab wrote: [media] radio-shark: New driver for the Griffin radioSHARK USB radio receiver This one gives me a build warning if CONFIG_LEDS_CLASS is disabled: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Could you please test the enclosed patch? Thanks! Mauro - [media] radio-shark: make sure LEDS_CLASS is selected As reported by David: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Reported-by: Dadiv Rientjes rient...@google.com Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 8090b87..be68ec2 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -60,6 +60,7 @@ config RADIO_MAXIRADIO config RADIO_SHARK tristate Griffin radioSHARK USB radio receiver depends on USB SND + select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. @@ -77,6 +78,7 @@ config RADIO_SHARK config RADIO_SHARK2 tristate Griffin radioSHARK2 USB radio receiver depends on USB + select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] Add rds-ctl tool (with changes proposed in RFC)
Hi,
Comments inline.
On 08/07/2012 05:11 PM, Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac |1 +
utils/rds-ctl/Makefile.am |5 +
utils/rds-ctl/rds-ctl.cpp | 959 +
4 files changed, 967 insertions(+), 1 deletion(-)
create mode 100644 utils/rds-ctl/Makefile.am
create mode 100644 utils/rds-ctl/rds-ctl.cpp
diff --git a/Makefile.am b/Makefile.am
index 621d8d9..8ef0d00 100644
--- a/Makefile.am
+++ b/Makefile.am
Snip
+static void print_rds_data(const struct v4l2_rds *handle, uint32_t
updated_fields)
+{
+ if (params.options[OptPrintBlock])
+ updated_fields = 0x;
+
+ if ((updated_fields V4L2_RDS_PI)
+ (handle-valid_fields V4L2_RDS_PI)) {
+ printf(\nPI: %04x, handle-pi);
+ print_rds_pi(handle);
+ }
+
+ if (updated_fields V4L2_RDS_PS
+ handle-valid_fields V4L2_RDS_PS) {
+ printf(\nPS: );
+ for (int i = 0; i 8; ++i) {
+ /* filter out special characters */
+ if (handle-ps[i] = 0x20 handle-ps[i] = 0x7E)
+ printf(%lc,handle-ps[i]);
+ else
+ printf( );
+ }
Since ps now is a 0 terminated UTF-8 string you should be able to just do:
printf(\nPS: %s, handle-ps);
And likewise for the other strings.
+ }
+
+ if (updated_fields V4L2_RDS_PTY handle-valid_fields
V4L2_RDS_PTY)
+ printf(\nPTY: %0u - %s,handle-pty,
v4l2_rds_get_pty_str(handle));
+
+ if (updated_fields V4L2_RDS_PTYN handle-valid_fields
V4L2_RDS_PTYN) {
+ printf(\nPTYN: );
+ for (int i = 0; i 8; ++i) {
+ /* filter out special characters */
+ if (handle-ptyn[i] = 0x20 handle-ptyn[i] = 0x7E)
+ printf(%lc,handle-ptyn[i]);
+ else
+ printf( );
+ }
Likewise.
+ }
+
+ if (updated_fields V4L2_RDS_TIME) {
+ printf(\nTime: %s, ctime(handle-time));
+ }
+ if (updated_fields V4L2_RDS_RT handle-valid_fields V4L2_RDS_RT)
{
+ printf(\nRT: );
+ for (int i = 0; i handle-rt_length; ++i) {
+ /* filter out special characters */
+ if (handle-rt[i] = 0x20 handle-rt[i] = 0x7E)
+ printf(%lc,handle-rt[i]);
+ else
+ printf( );
+ }
Likewise.
+ }
+
+ if (updated_fields V4L2_RDS_TP handle-valid_fields V4L2_RDS_TP)
+ printf(\nTP: %s TA: %s, (handle-tp)? yes:no,
+ handle-ta? yes:no);
+ if (updated_fields V4L2_RDS_MS handle-valid_fields V4L2_RDS_MS)
+ printf(\nMS Flag: %s, (handle-ms)? Music : Speech);
+ if (updated_fields V4L2_RDS_ECC handle-valid_fields
V4L2_RDS_ECC)
+ printf(\nECC: %X%x, Country: %u - %s,
+ handle-ecc 4, handle-ecc 0x0f, handle-pi 12,
+ v4l2_rds_get_country_str(handle));
+ if (updated_fields V4L2_RDS_LC handle-valid_fields V4L2_RDS_LC)
+ printf(\nLanguage: %u - %s , handle-lc,
+ v4l2_rds_get_language_str(handle));
+ if (updated_fields V4L2_RDS_DI handle-valid_fields V4L2_RDS_DI)
+ print_decoder_info(handle-di);
+ if (updated_fields V4L2_RDS_ODA
+ handle-decode_information V4L2_RDS_ODA) {
+ for (int i = 0; i handle-rds_oda.size; ++i)
+ printf(\nODA Group: %02u%c, AID:
%08x,handle-rds_oda.oda[i].group_id,
+ handle-rds_oda.oda[i].group_version,
handle-rds_oda.oda[i].aid);
+ }
+ if (updated_fields V4L2_RDS_AF handle-valid_fields V4L2_RDS_AF)
+ print_rds_af(handle-rds_af);
+ if (params.options[OptPrintBlock])
+ printf(\n);
+}
+
+static void read_rds(struct v4l2_rds *handle, const int fd, const int
wait_limit)
+{
+ int byte_cnt = 0;
+ int error_cnt = 0;
+ uint32_t updated_fields = 0x00;
+ struct v4l2_rds_data rds_data; /* read buffer for rds blocks */
+
+ while (!params.terminate_decoding) {
+ memset(rds_data, 0, sizeof(rds_data));
+ if ((byte_cnt=read(fd, rds_data, 3)) != 3) {
+ if (byte_cnt == 0) {
+ printf(\nEnd of input file reached \n);
+ break;
+ } else if(++error_cnt 2) {
+ fprintf(stderr, \nError reading from
+ device (no RDS data available)\n);
+
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
On Thu August 9 2012 13:58:07 Hans de Goede wrote:
Hi Konke,
As Gregor already mentioned there is no need to define libv4l2rdssubdir in
configure.ac ,
so please drop that.
Other then that I've some minor remarks (comments inline), with all those
fixed, this one is could to go. So hopefully the next version can be added
to git master!
On 08/07/2012 05:11 PM, Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac|7 +-
lib/include/libv4l2rds.h| 228 ++
lib/libv4l2rds/Makefile.am | 11 +
lib/libv4l2rds/libv4l2rds.c | 953
+++
lib/libv4l2rds/libv4l2rds.pc.in | 11 +
6 files changed, 1211 insertions(+), 2 deletions(-)
create mode 100644 lib/include/libv4l2rds.h
create mode 100644 lib/libv4l2rds/Makefile.am
create mode 100644 lib/libv4l2rds/libv4l2rds.c
create mode 100644 lib/libv4l2rds/libv4l2rds.pc.in
snip
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..4aa8593
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,228 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as
published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335
USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include time.h
+#include sys/types.h
+#include sys/mman.h
+#include config.h
You should never include config.h in a public header, also
are all the headers really needed for the prototypes in this header?
I don't think so! Please move all the unneeded ones to the libv4l2rds.c
file!
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if HAVE_VISIBILITY
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds
struct */
+#define V4L2_RDS_VERSION (1)
+
What is the purpose of this field? Once we've released a v4l-utils with this
library we are stuck to the API we've defined, having a version field
changing it,
won't stop us from breaking existing apps, so once we've an official release
we
simply cannot make ABI breaking changes, which is why most of my review sofar
has concentrated on the API side :)
I suggest dropping this define and the version field from the struct.
I think it is useful, actually. The v4l2_rds struct is allocated by the
v4l2_rds_create
so at least in theory it is possible to extend the struct in the future without
breaking
existing apps, provided you have a version number to check.
Regards,
Hans
+/* Constants used to define the size of arrays used to store RDS
information */
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
+* 32 distinct groups, 18 can be used for ODA purposes
*/
+#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be
defined
+* AF Method B does not impose a limit on the number of
AFs
+* but it is not fully supported at the moment and will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_fields bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40/* Music / Speech flag */
+#define V4L2_RDS_PTYN 0x80/* Program Type Name */
+#define V4L2_RDS_RT0x100 /*
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
On Tue August 7 2012 17:11:54 Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac|7 +-
lib/include/libv4l2rds.h| 228 ++
lib/libv4l2rds/Makefile.am | 11 +
lib/libv4l2rds/libv4l2rds.c | 953
+++
lib/libv4l2rds/libv4l2rds.pc.in | 11 +
6 files changed, 1211 insertions(+), 2 deletions(-)
create mode 100644 lib/include/libv4l2rds.h
create mode 100644 lib/libv4l2rds/Makefile.am
create mode 100644 lib/libv4l2rds/libv4l2rds.c
create mode 100644 lib/libv4l2rds/libv4l2rds.pc.in
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..4aa8593
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,228 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335
USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include time.h
+#include sys/types.h
+#include sys/mman.h
+#include config.h
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if HAVE_VISIBILITY
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds struct
*/
+#define V4L2_RDS_VERSION (1)
+
+/* Constants used to define the size of arrays used to store RDS information
*/
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b.
Of these
+ * 32 distinct groups, 18 can be used for ODA purposes
*/
+#define MAX_AF_CNT 25/* AF Method A allows a maximum of 25 AFs to be
defined
+ * AF Method B does not impose a limit on the number of
AFs
+ * but it is not fully supported at the moment and will
+ * not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_fields bitmask */
+#define V4L2_RDS_PI 0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP 0x04/* Traffic Program */
+#define V4L2_RDS_PS 0x08/* Program Service Name */
+#define V4L2_RDS_TA 0x10/* Traffic Announcement */
+#define V4L2_RDS_DI 0x20/* Decoder Information */
+#define V4L2_RDS_MS 0x40/* Music / Speech flag */
+#define V4L2_RDS_PTYN0x80/* Program Type Name */
+#define V4L2_RDS_RT 0x100 /* Radio-Text */
+#define V4L2_RDS_TIME0x200 /* Date and Time information */
+#define V4L2_RDS_TMC 0x400 /* TMC availability */
+#define V4L2_RDS_AF 0x800 /* AF (alternative freq) available */
+#define V4L2_RDS_ECC 0x1000 /* Extended County Code */
+#define V4L2_RDS_LC 0x2000 /* Language Code */
+
+/* Define Constants for the state of the RDS decoding process
+ * used to address the relevant bit in the decode_information bitmask */
+#define V4L2_RDS_GROUP_NEW 0x01/* New group received */
+#define V4L2_RDS_ODA 0x02/* Open Data Group announced */
+
+/* Decoder Information (DI) codes
+ * used to decode the DI information according to the RDS standard */
+#define V4L2_RDS_FLAG_STEREO 0x01
+#define V4L2_RDS_FLAG_ARTIFICIAL_HEAD0x02
+#define V4L2_RDS_FLAG_COMPRESSED 0x04
+#define V4L2_RDS_FLAG_STATIC_PTY 0x08
+
+/* struct to encapsulate one complete RDS group */
+/* This structure is used internally to store data until a complete RDS
+ * group was received and group id dependent decoding can be done.
+ * It is also used to provide external access to uninterpreted RDS groups
+ * when manual decoding is required (e.g. special ODA types) */
+struct v4l2_rds_group {
+ uint16_t pi;/* Program Identification */
+ char group_version; /* group version ('A' /
Re: [alsa-devel] [PATCH v8] media: Add stk1160 new driver
Hi Mauro, On Mon, Aug 6, 2012 at 4:13 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On a second thought, perhaps it makes sense to have a git repo (on linuxtv.org) for me to work on stk1160. That way I could simply send git pull requests instead of patches. I'm not sure if this is a better workflow and/or would allow for easier reviewing. Well, I just got an answer from vger administrator. He told me the patch was exceeding the allowed limit. Which I later discovered it was documented here: http://vger.kernel.org/majordomo-info.html Apparently, there is a 100, 000 characters limit. So, how do we proceed? Ping! Could you take a look at this? I'd like to solve the pending issues (see previous mails), in order to know if the driver will need further work. ... or perhaps we can leave this for after the merge window, when you (and everyone) are be less busy. I *really* hope I'm not spamming. In that case, feel free to say so. Thanks, Ezequiel. -- 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: [alsa-devel] [PATCH v8] media: Add stk1160 new driver
Em 09-08-2012 09:24, Ezequiel Garcia escreveu: Hi Mauro, On Mon, Aug 6, 2012 at 4:13 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On a second thought, perhaps it makes sense to have a git repo (on linuxtv.org) for me to work on stk1160. That way I could simply send git pull requests instead of patches. I'm not sure if this is a better workflow and/or would allow for easier reviewing. Well, I just got an answer from vger administrator. He told me the patch was exceeding the allowed limit. Which I later discovered it was documented here: http://vger.kernel.org/majordomo-info.html Apparently, there is a 100, 000 characters limit. So, how do we proceed? Ping! Could you take a look at this? I'd like to solve the pending issues (see previous mails), in order to know if the driver will need further work. ... or perhaps we can leave this for after the merge window, when you (and everyone) are be less busy. I *really* hope I'm not spamming. In that case, feel free to say so. The merge window was closed already. I pushed this patch directly into patchwork, so I should be handling it sooner or later. Unfortunately, I had a crash on my home volume group, and I'm busy those days recovering data from it. It seems I'll be able to recover everything, but I'll need to move about 800GB of data between two disks (one of them is a slow one), plus my backup machine. I'll likely break it into several smaller logical volumes, in order to help me to keep the backup updated. So, that'll keep me busy for a while. In the meantime, I'm working on a slow notebook. So, I might still be able to review and add some patches upstream, especially the more trivial ones. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.6-rc1] media updates part 2
Em 09-08-2012 09:00, Hans de Goede escreveu: Hi, My bad, sorry about this. Mauro's patch looks good. Hmm... menuconfig NEW_LEDS bool LED Support help Say Y to enable Linux LED support. This allows control of supported LEDs from both userspace and optionally, by kernel events (triggers). This is not related to standard keyboard LEDs which are controlled via the input system. if NEW_LEDS config LEDS_CLASS ... It seems that the patch also need to select or depend on NEW_LEDS. An alternative fix would be to #ifdefify the led code in the drivers themselves. Yeah, that would work as well, although the code would look uglier. IMHO, using select/depend is better. Regards, Mauro Regards, Hans On 08/09/2012 01:38 PM, Mauro Carvalho Chehab wrote: Em 08-08-2012 19:28, David Rientjes escreveu: On Tue, 31 Jul 2012, Mauro Carvalho Chehab wrote: [media] radio-shark: New driver for the Griffin radioSHARK USB radio receiver This one gives me a build warning if CONFIG_LEDS_CLASS is disabled: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Could you please test the enclosed patch? Thanks! Mauro - [media] radio-shark: make sure LEDS_CLASS is selected As reported by David: ERROR: led_classdev_register [drivers/media/radio/shark2.ko] undefined! ERROR: led_classdev_unregister [drivers/media/radio/shark2.ko] undefined! Reported-by: Dadiv Rientjes rient...@google.com Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 8090b87..be68ec2 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -60,6 +60,7 @@ config RADIO_MAXIRADIO config RADIO_SHARK tristate Griffin radioSHARK USB radio receiver depends on USB SND +select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. @@ -77,6 +78,7 @@ config RADIO_SHARK config RADIO_SHARK2 tristate Griffin radioSHARK2 USB radio receiver depends on USB +select LEDS_CLASS ---help--- Choose Y here if you have this radio receiver. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add Nokia N900 (RX51) IR diode support
These patches add the support for sending IR remote controller codes on the Nokia N900 phone. The code is taken from the public N900 kernel release and modified to work with today's kernel. The code has been tested with a real Nokia N900 device and confirmed to work. I can identify only one known issue; The IR pulses being sent become *veeery* long if the device chooses to go into any sleep modes during transmitting the IR pulses. The driver makes an attempt to set up PM latency constraints, but apparently those don't apply as there is currently only no-op PM layer available. Therefore, I guess this driver doesn't actually work properly unless there is some background load that prevents the device from enterint sleep modes or the sleep modes are disabled altogether. However, once a proper PM layer implementation becomes available, I expect this problem to resolve itself. The same code used to work with the actual N900 kernel that has those implemented. Any comments regarding the patches are welcome. I guess media list won't take in omap patches and omap list doesn't take media patches. So I wrote the patches so that they can be applied independently. If you want me to remove the #ifdef hacks from the board file (that is needed to break the build dependency between the patches), then the ir-rx51.c patch needs to be applied before the board file patch. But I though it would be more flexible this way. I'm open to suggestions on how you are willing to accept the patches. Timo Kokkonen (2): media: rc: Introduce RX51 IR transmitter driver ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data arch/arm/mach-omap2/board-rx51-peripherals.c | 27 ++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile|1 + drivers/media/rc/ir-rx51.c | 496 ++ drivers/media/rc/ir-rx51.h | 10 + 5 files changed, 544 insertions(+), 0 deletions(-) create mode 100644 drivers/media/rc/ir-rx51.c create mode 100644 drivers/media/rc/ir-rx51.h -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: rc: Introduce RX51 IR transmitter driver
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt to the changes that has happen in the kernel during the past
five years, such as the change in the include paths
- The OMAP DM-timers require much more care nowadays. The timers need
to be enabled and disabled or otherwise many actions fail. Timers
must not be freed without first stopping them or otherwise the timer
cannot be requested again.
The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-rx51.c | 496
drivers/media/rc/ir-rx51.h | 10 +
4 files changed, 517 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/ir-rx51.c
create mode 100644 drivers/media/rc/ir-rx51.h
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 5180390..ab35d2e 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -270,6 +270,16 @@ config IR_IGUANA
To compile this driver as a module, choose M here: the module will
be called iguanair.
+config IR_RX51
+ tristate Nokia N900 IR transmitter diode
+ depends on MACH_NOKIA_RX51 OMAP_DM_TIMER
+ ---help---
+ Say Y or M here if you want to enable support for the IR
+ transmitter diode built in the Nokia N900 (RX51) device.
+
+ The driver uses omap DM timers for gereating the carrier
+ wave and pulses.
+
config RC_LOOPBACK
tristate Remote Control Loopback Driver
depends on RC_CORE
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f871d19..d384f30 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o
obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
+obj-$(CONFIG_IR_RX51) += ir-rx51.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c
new file mode 100644
index 000..66d2607
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.c
@@ -0,0 +1,496 @@
+/*
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Based on lirc_serial.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/uaccess.h
+#include linux/platform_device.h
+#include linux/sched.h
+#include linux/wait.h
+
+#include plat/dmtimer.h
+#include plat/clock.h
+#include plat/omap-pm.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+#include ir-rx51.h
+
+#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE | \
+ LIRC_CAN_SET_SEND_CARRIER | \
+ LIRC_CAN_SEND_PULSE)
+
+#define DRIVER_NAME lirc_rx51
+
+#define WBUF_LEN 256
+
+#define TIMER_MAX_VALUE 0x
+
+struct lirc_rx51 {
+ struct omap_dm_timer *pwm_timer;
+ struct omap_dm_timer *pulse_timer;
+ struct device*dev;
+ struct lirc_rx51_platform_data *pdata;
+ wait_queue_head_t wqueue;
+
+ unsigned long fclk_khz;
+ unsigned intfreq; /* carrier frequency */
+ unsigned intduty_cycle; /* carrier duty cycle */
+ unsigned intirq_num;
+ unsigned intmatch;
+ int wbuf[WBUF_LEN];
+ int wbuf_index;
+ unsigned long device_is_open;
+ unsigned intpwm_timer_num;
+};
+
+static void lirc_rx51_on(struct lirc_rx51 *lirc_rx51)
+{
+ omap_dm_timer_set_pwm(lirc_rx51-pwm_timer, 0, 1,
+ OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE);
+}
+
+static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
+{
+
[PATCH 2/2] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..4a5a71b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -46,6 +47,10 @@
#include ../drivers/staging/iio/light/tsl2563.h
#include linux/lis3lv02d.h
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include ../../../drivers/media/rc/ir-rx51.h
+#endif
+
#include mux.h
#include hsmmc.h
#include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+ .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+ .pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+ .name = lirc_rx51,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_lirc_data,
+ },
+};
+
+static void __init rx51_init_lirc(void)
+{
+ platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+ rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
__video_register_device: warning cannot be reached if warn_if_nr_in_use
In file drivers/media/video/v4l2-dev.c
int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
{
[...]
vdev-minor = i + minor_offset;
878:vdev-num = nr;
vdev-num is set to nr here.
[...]
if (nr != -1 nr != vdev-num warn_if_nr_in_use)
printk(KERN_WARNING %s: requested %s%d, got %s\n, __func__,
name_base, nr, video_device_node_name(vdev));
so nr != vdev-num is always false. The warning can never be printed.
Thanks
Richard
--
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: __video_register_device: warning cannot be reached if warn_if_nr_in_use
On Thu August 9 2012 14:55:02 Richard Zhao wrote:
In file drivers/media/video/v4l2-dev.c
int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
{
[...]
vdev-minor = i + minor_offset;
878: vdev-num = nr;
vdev-num is set to nr here.
[...]
if (nr != -1 nr != vdev-num warn_if_nr_in_use)
printk(KERN_WARNING %s: requested %s%d, got %s\n, __func__,
name_base, nr, video_device_node_name(vdev));
so nr != vdev-num is always false. The warning can never be printed.
Hmm, true. The question is, should we just fix this, or drop the warning
altogether?
Clearly nobody missed that warning.
I'm inclined to drop the warning altogether and so also the
video_register_device_no_warn
inline function.
What do others think?
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 2/2] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
Hi Timo,
On 08/09/12 15:41, Timo Kokkonen wrote:
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30
++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..4a5a71b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -46,6 +47,10 @@
#include ../drivers/staging/iio/light/tsl2563.h
#include linux/lis3lv02d.h
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include ../../../drivers/media/rc/ir-rx51.h
+#endif
That is not really nice...
You should place the struct lirc_rx51_platform_data and
other stuff used outside of the driver in: include/media/
so you will not have to add that long and ugly relative path.
+
#include mux.h
#include hsmmc.h
#include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+ .set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+ .pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+ .name = lirc_rx51,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_lirc_data,
+ },
+};
+
+static void __init rx51_init_lirc(void)
+{
+ platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+ rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
Regards,
Igor.
--
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/2] media: rc: Introduce RX51 IR transmitter driver
On 08/09/12 15:41, Timo Kokkonen wrote:
This is the driver for the IR transmitter diode found on the Nokia
N900 (also known as RX51) device. The driver is mostly the same as
found in the original 2.6.28 based kernel that comes with the device.
The following modifications have been made compared to the original
driver version:
- Adopt to the changes that has happen in the kernel during the past
five years, such as the change in the include paths
- The OMAP DM-timers require much more care nowadays. The timers need
to be enabled and disabled or otherwise many actions fail. Timers
must not be freed without first stopping them or otherwise the timer
cannot be requested again.
The code has been tested with sending IR codes with N900 device
running Debian userland. The device receiving the codes was Anysee
DVB-C USB receiver.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/ir-rx51.c | 496
drivers/media/rc/ir-rx51.h | 10 +
I think the file ir-rx51.h should be placed in include/media instead.
[...]
4 files changed, 517 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/ir-rx51.c
create mode 100644 drivers/media/rc/ir-rx51.h
[...]
diff --git a/drivers/media/rc/ir-rx51.h b/drivers/media/rc/ir-rx51.h
new file mode 100644
index 000..104aa89
--- /dev/null
+++ b/drivers/media/rc/ir-rx51.h
@@ -0,0 +1,10 @@
+#ifndef _LIRC_RX51_H
+#define _LIRC_RX51_H
+
+struct lirc_rx51_platform_data {
+ int pwm_timer;
+
+ int(*set_max_mpu_wakeup_lat)(struct device *dev, long t);
+};
+
+#endif
--
Regards,
Igor.
--
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: __video_register_device: warning cannot be reached if warn_if_nr_in_use
Hans Verkuil hverk...@xs4all.nl wrote:
On Thu August 9 2012 14:55:02 Richard Zhao wrote:
In file drivers/media/video/v4l2-dev.c
int __video_register_device(struct video_device *vdev, int type, int
nr,
int warn_if_nr_in_use, struct module *owner)
{
[...]
vdev-minor = i + minor_offset;
878: vdev-num = nr;
vdev-num is set to nr here.
[...]
if (nr != -1 nr != vdev-num warn_if_nr_in_use)
printk(KERN_WARNING %s: requested %s%d, got %s\n, __func__,
name_base, nr, video_device_node_name(vdev));
so nr != vdev-num is always false. The warning can never be printed.
Hmm, true. The question is, should we just fix this, or drop the
warning altogether?
Clearly nobody missed that warning.
I'm inclined to drop the warning altogether and so also the
video_register_device_no_warn
inline function.
What do others think?
+1
Richard
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
--
From android phone
--
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: __video_register_device: warning cannot be reached if warn_if_nr_in_use
On 08/09/2012 03:19 PM, Hans Verkuil wrote:
On Thu August 9 2012 14:55:02 Richard Zhao wrote:
In file drivers/media/video/v4l2-dev.c
int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
{
[...]
vdev-minor = i + minor_offset;
878: vdev-num = nr;
vdev-num is set to nr here.
[...]
if (nr != -1 nr != vdev-num warn_if_nr_in_use)
printk(KERN_WARNING %s: requested %s%d, got %s\n, __func__,
name_base, nr, video_device_node_name(vdev));
so nr != vdev-num is always false. The warning can never be printed.
Hmm, true. The question is, should we just fix this, or drop the warning
altogether?
Clearly nobody missed that warning.
I'm inclined to drop the warning altogether and so also the
video_register_device_no_warn
inline function.
What do others think?
Yeah, let's remove it.
--
Regards,
Sylwester
--
Sylwester Nawrocki
ì‹¤ë² ìŠ¤í„° ë‚˜ë¸Œë¡œì¸ í‚¤
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v8] media: Add stk1160 new driver
On Thu, Aug 9, 2012 at 9:33 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-08-2012 09:24, Ezequiel Garcia escreveu: Hi Mauro, On Mon, Aug 6, 2012 at 4:13 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On a second thought, perhaps it makes sense to have a git repo (on linuxtv.org) for me to work on stk1160. That way I could simply send git pull requests instead of patches. I'm not sure if this is a better workflow and/or would allow for easier reviewing. Well, I just got an answer from vger administrator. He told me the patch was exceeding the allowed limit. Which I later discovered it was documented here: http://vger.kernel.org/majordomo-info.html Apparently, there is a 100, 000 characters limit. So, how do we proceed? Ping! Could you take a look at this? I'd like to solve the pending issues (see previous mails), in order to know if the driver will need further work. ... or perhaps we can leave this for after the merge window, when you (and everyone) are be less busy. I *really* hope I'm not spamming. In that case, feel free to say so. The merge window was closed already. Yes, you're right. I'm still unsure about the work flow. I pushed this patch directly into patchwork, so I should be handling it sooner or later. Yes, I noticed it after sending the mail. Unfortunately, I had a crash on my home volume group, and I'm busy those days recovering data from it. It seems I'll be able to recover everything, but I'll need to move about 800GB of data between two disks (one of them is a slow one), plus my backup machine. I'll likely break it into several smaller logical volumes, in order to help me to keep the backup updated. So, that'll keep me busy for a while. In the meantime, I'm working on a slow notebook. So, I might still be able to review and add some patches upstream, especially the more trivial ones. Ouch! I'm sorry to hear that. I hope you can recover soon. I'll stay tuned for your comments (and I'll stop bothering). Thanks for your reply! Ezequiel. -- 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/2] ARM: mach-omap2: board-rx51-peripherals: Add lirc-rx51 data
On 08/09/12 16:19, Igor Grinberg wrote:
Hi Timo,
On 08/09/12 15:41, Timo Kokkonen wrote:
The IR diode on the RX51 is connected to the GPT9. This data is needed
for the IR driver to function.
Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 30
++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index df2534d..4a5a71b 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -34,6 +34,7 @@
#include plat/gpmc.h
#include plat/onenand.h
#include plat/gpmc-smc91x.h
+#include plat/omap-pm.h
#include mach/board-rx51.h
@@ -46,6 +47,10 @@
#include ../drivers/staging/iio/light/tsl2563.h
#include linux/lis3lv02d.h
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+#include ../../../drivers/media/rc/ir-rx51.h
+#endif
That is not really nice...
You should place the struct lirc_rx51_platform_data and
other stuff used outside of the driver in: include/media/
so you will not have to add that long and ugly relative path.
Yeah, you're right. I'll change that. Thanks.
-Timo
+
#include mux.h
#include hsmmc.h
#include common-board-devices.h
@@ -1220,6 +1225,30 @@ static void __init rx51_init_tsc2005(void)
gpio_to_irq(RX51_TSC2005_IRQ_GPIO);
}
+#if defined(CONFIG_IR_RX51) || defined(CONFIG_IR_RX51_MODULE)
+static struct lirc_rx51_platform_data rx51_lirc_data = {
+.set_max_mpu_wakeup_lat = omap_pm_set_max_mpu_wakeup_lat,
+.pwm_timer = 9, /* Use GPT 9 for CIR */
+};
+
+static struct platform_device rx51_lirc_device = {
+.name = lirc_rx51,
+.id = -1,
+.dev= {
+.platform_data = rx51_lirc_data,
+},
+};
+
+static void __init rx51_init_lirc(void)
+{
+platform_device_register(rx51_lirc_device);
+}
+#else
+static void __init rx51_init_lirc(void)
+{
+}
+#endif
+
void __init rx51_peripherals_init(void)
{
rx51_i2c_init();
@@ -1230,6 +1259,7 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
rx51_init_tsc2005();
rx51_init_si4713();
+rx51_init_lirc();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
they are gone. And btw: I'm sorry for fiddling with your build environment in such a way. I have to admit that the additions I made were based more on copying from existing libraries than really understanding the effects of each command. Regards, Konke On Thu, Aug 9, 2012 at 7:22 AM, Gregor Jasny gja...@googlemail.com wrote: Hello Konke, On 8/7/12 5:11 PM, Konke Radlow wrote: diff --git a/configure.ac b/configure.ac index 8ddcc9d..1109c4d 100644 --- a/configure.ac +++ b/configure.ac @@ -146,9 +148,12 @@ AC_ARG_WITH(libv4l2subdir, AS_HELP_STRING(--with-libv4l2subdir=DIR,set libv4l2 l AC_ARG_WITH(libv4lconvertsubdir, AS_HELP_STRING(--with-libv4lconvertsubdir=DIR,set libv4lconvert library subdir [default=libv4l]), libv4lconvertsubdir=$withval, libv4lconvertsubdir=libv4l) +AC_ARG_WITH(libv4l2rdssubdir, AS_HELP_STRING(--with-libv4l2rdssubdir=DIR,set libv4l2rds library subdir [default=libv4l]), + libv4l2rdssubdir=$withval, libv4l2rdssubdir=libv4l) + AC_ARG_WITH(udevdir, AS_HELP_STRING(--with-udevdir=DIR,set udev directory [default=/lib/udev]), udevdir=$withval, udevdir=/lib/udev) - + libv4l1privdir=$libdir/$libv4l1subdir libv4l2privdir=$libdir/$libv4l2subdir libv4l2plugindir=$libv4l2privdir/plugins please remove these changes. They are not needed for the RDS library. Thanks, Gregor -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] dma-buf: add reference counting for exporter module
On Thu, Aug 09, 2012 at 11:36:21AM +0200, Tomasz Stanislawski wrote: This patch adds reference counting on a module that exported dma-buf and implements its operations. This prevents the module from being unloaded while DMABUF file is in use. Why force all of the modules to be changed by hand, and not just do this automatically by changing the register function to include the THIS_MODULE macro in it? Much like the pci_register_driver() function is implemented in include/linux/pci.h? That makes it impossible for driver authors to get it wrong, which is always a good sign of a correct api. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Add libv4l2rds library (with changes proposed in RFC)
On Thu, Aug 9, 2012 at 11:58 AM, Hans de Goede hdego...@redhat.com wrote:
Other then that I've some minor remarks (comments inline), with all those
fixed, this one is could to go. So hopefully the next version can be added
to git master!
I'm very happy to hear that :)
On 08/07/2012 05:11 PM, Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac|7 +-
lib/include/libv4l2rds.h| 228 ++
lib/libv4l2rds/Makefile.am | 11 +
lib/libv4l2rds/libv4l2rds.c | 953
+++
lib/libv4l2rds/libv4l2rds.pc.in | 11 +
6 files changed, 1211 insertions(+), 2 deletions(-)
create mode 100644 lib/include/libv4l2rds.h
create mode 100644 lib/libv4l2rds/Makefile.am
create mode 100644 lib/libv4l2rds/libv4l2rds.c
create mode 100644 lib/libv4l2rds/libv4l2rds.pc.in
snip
diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h
new file mode 100644
index 000..4aa8593
--- /dev/null
+++ b/lib/include/libv4l2rds.h
@@ -0,0 +1,228 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ * Author: Konke Radlow korad...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as
published by
+ * the Free Software Foundation; either version 2.1 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA
02110-1335 USA
+ */
+
+#ifndef __LIBV4L2RDS
+#define __LIBV4L2RDS
+
+#include errno.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include unistd.h
+#include stdint.h
+#include time.h
+#include sys/types.h
+#include sys/mman.h
+#include config.h
You should never include config.h in a public header, also
are all the headers really needed for the prototypes in this header?
I don't think so! Please move all the unneeded ones to the libv4l2rds.c
file!
That's true, I don't know why I had all these include directives in the public
header. After cleaning up we're left with only three (stdbool, stdint
and videodev2)
+
+#include linux/videodev2.h
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+#if HAVE_VISIBILITY
+#define LIBV4L_PUBLIC __attribute__ ((visibility(default)))
+#else
+#define LIBV4L_PUBLIC
+#endif
+
+/* used to define the current version (version field) of the v4l2_rds
struct */
+#define V4L2_RDS_VERSION (1)
+
What is the purpose of this field? Once we've released a v4l-utils with this
library we are stuck to the API we've defined, having a version field
changing it,
won't stop us from breaking existing apps, so once we've an official release
we
simply cannot make ABI breaking changes, which is why most of my review
sofar
has concentrated on the API side :)
I suggest dropping this define and the version field from the struct.
As Hans mentioned this version field is not supposed to denote the API version,
but rather the version of the v4l2_rds_handle struct. This struct could then
theoretically be updated in the future and provide applications a way
of verifying
their compatibility with the rds-library version installed on the system.
+/* Constants used to define the size of arrays used to store RDS
information */
+#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or
b. Of these
+* 32 distinct groups, 18 can be used for ODA
purposes */
+#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be
defined
+* AF Method B does not impose a limit on the
number of AFs
+* but it is not fully supported at the moment and
will
+* not receive more than 25 AFs */
+
+/* Define Constants for the possible types of RDS information
+ * used to address the relevant bit in the valid_fields bitmask */
+#define V4L2_RDS_PI0x01/* Program Identification */
+#define V4L2_RDS_PTY 0x02/* Program Type */
+#define V4L2_RDS_TP0x04/* Traffic Program */
+#define V4L2_RDS_PS0x08/* Program Service Name */
+#define V4L2_RDS_TA0x10/* Traffic Announcement */
+#define V4L2_RDS_DI0x20/* Decoder Information */
+#define V4L2_RDS_MS0x40/* Music / Speech flag */
+#define V4L2_RDS_PTYN 0x80/* Program Type Name */
+#define V4L2_RDS_RT
Re: [RFC PATCH 2/2] Add rds-ctl tool (with changes proposed in RFC)
On Thu, Aug 9, 2012 at 12:05 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
Comments inline.
On 08/07/2012 05:11 PM, Konke Radlow wrote:
---
Makefile.am |3 +-
configure.ac |1 +
utils/rds-ctl/Makefile.am |5 +
utils/rds-ctl/rds-ctl.cpp | 959
+
4 files changed, 967 insertions(+), 1 deletion(-)
create mode 100644 utils/rds-ctl/Makefile.am
create mode 100644 utils/rds-ctl/rds-ctl.cpp
diff --git a/Makefile.am b/Makefile.am
index 621d8d9..8ef0d00 100644
--- a/Makefile.am
+++ b/Makefile.am
Snip
+static void print_rds_data(const struct v4l2_rds *handle, uint32_t
updated_fields)
+{
+ if (params.options[OptPrintBlock])
+ updated_fields = 0x;
+
+ if ((updated_fields V4L2_RDS_PI)
+ (handle-valid_fields V4L2_RDS_PI)) {
+ printf(\nPI: %04x, handle-pi);
+ print_rds_pi(handle);
+ }
+
+ if (updated_fields V4L2_RDS_PS
+ handle-valid_fields V4L2_RDS_PS) {
+ printf(\nPS: );
+ for (int i = 0; i 8; ++i) {
+ /* filter out special characters */
+ if (handle-ps[i] = 0x20 handle-ps[i] =
0x7E)
+ printf(%lc,handle-ps[i]);
+ else
+ printf( );
+ }
Since ps now is a 0 terminated UTF-8 string you should be able to just do:
printf(\nPS: %s, handle-ps);
And likewise for the other strings.
changed as proposed, and works like a charm :)
Other then that this looks good to me.
Regards,
Hans
thank you for the review
Regards,
Konke
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] dma-buf: add reference counting for exporter module
Hi Greg, On 08/09/2012 04:23 PM, Greg KH wrote: On Thu, Aug 09, 2012 at 11:36:21AM +0200, Tomasz Stanislawski wrote: This patch adds reference counting on a module that exported dma-buf and implements its operations. This prevents the module from being unloaded while DMABUF file is in use. Why force all of the modules to be changed by hand, and not just do this automatically by changing the register function to include the THIS_MODULE macro in it? Much like the pci_register_driver() function is implemented in include/linux/pci.h? Thank you for the hint. The owner field belongs to dma_buf_ops structure that is often a 'const' entity. Therefore owner field would have to be moved to 'struct dma_buf' to avoid 'deconstification' issues. Regards, Tomasz Stanislawski That makes it impossible for driver authors to get it wrong, which is always a good sign of a correct api. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mantis: fix silly crash case
From: Alan Cox a...@linux.intel.com
If we set mantis-fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing really.
Signed-off-by: Alan Cox a...@linux.intel.com
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=16473
---
drivers/media/dvb/mantis/mantis_dvb.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index e5180e4..5d15c6b 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -248,8 +248,10 @@ int __devinit mantis_dvb_init(struct mantis_pci *mantis)
err5:
tasklet_kill(mantis-tasklet);
dvb_net_release(mantis-dvbnet);
- dvb_unregister_frontend(mantis-fe);
- dvb_frontend_detach(mantis-fe);
+ if (mantis-fe) {
+ dvb_unregister_frontend(mantis-fe);
+ dvb_frontend_detach(mantis-fe);
+ }
err4:
mantis-demux.dmx.remove_frontend(mantis-demux.dmx, mantis-fe_mem);
--
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: support for Elgato eyetv one
Thanks for the reply! I had no idea that it would be that complex. From the moment I joined this mailing board in order to add the information above, I received no less than 193 e-mails! It's great to see that are that many people working on linux drivers! Good luck and keep up the good work! -- 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: support for Elgato eyetv one
On 08/09/2012 07:13 PM, Dutchdude wrote: Thanks for the reply! I had no idea that it would be that complex. From the moment I joined this mailing board in order to add the information above, I received no less than 193 e-mails! It's great to see that are that many people working on linux drivers! Good luck and keep up the good work! But (unfortunately) for the computer digital television receivers there is very few developers :-] Linux-Media contains much stuff, two APIs DVB and V4L2, and most development is happening currently on V4L2 interface. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for 3.6-rc1] media updates part 2
On Thu, 9 Aug 2012, Mauro Carvalho Chehab wrote: Yeah, that would work as well, although the code would look uglier. IMHO, using select/depend is better. Agreed, I think it should be depends on LEDS_CLASS rather than select it if there is a hard dependency that cannot be fixed with extracting the led support in the driver to #ifdef CONFIG_LEDS_CLASS code. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] media: Add stk1160 new driver
Patch looks ok. Just a few comments: Em 06-08-2012 10:38, Ezequiel Garcia escreveu: This driver adds support for stk1160 usb bridge as used in some video/audio usb capture devices. It is a complete rewrite of staging/media/easycap driver and it's expected as a replacement. --- Please don't add a --- here. Everything after a --- are discarded by my scripts (and by most other kernel developer scripts). Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Takashi Iwai ti...@suse.de Cc: Hans Verkuil hverk...@xs4all.nl Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Hmm... weren't it reviewed already be them? Signed-off-by: Ezequiel Garcia elezegar...@gmail.com diff --git a/drivers/media/video/stk1160/Makefile b/drivers/media/video/stk1160/Makefile new file mode 100644 index 000..8f66a78 --- /dev/null +++ b/drivers/media/video/stk1160/Makefile @@ -0,0 +1,12 @@ +obj-stk1160-ac97-$(CONFIG_VIDEO_STK1160_AC97) := stk1160-ac97.o + +stk1160-y := stk1160-core.o \ + stk1160-v4l.o \ + stk1160-video.o \ + stk1160-i2c.o \ + $(obj-stk1160-ac97-y) + +obj-$(CONFIG_VIDEO_STK1160) += stk1160.o + +ccflags-y += -Wall You shouldn't be adding the above here. +ccflags-y += -Idrivers/media/video Ah, please split this patch into two patches: one with the new driver addition, and another one with the removal of the driver at staging. That will help to make the patch smaller, and avoids mixing two different things at the same place. 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 v8] media: Add stk1160 new driver
On Thu, Aug 9, 2012 at 5:25 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Patch looks ok. Just a few comments: Em 06-08-2012 10:38, Ezequiel Garcia escreveu: This driver adds support for stk1160 usb bridge as used in some video/audio usb capture devices. It is a complete rewrite of staging/media/easycap driver and it's expected as a replacement. --- Please don't add a --- here. Everything after a --- are discarded by my scripts (and by most other kernel developer scripts). Mmm, that line was meant to separate commit message from message intended for developers/reviewers. Do you feel all the text should be part of the commit message? Anyway, I know currently it's wrong, since the SOB should be part of commit message. Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Takashi Iwai ti...@suse.de Cc: Hans Verkuil hverk...@xs4all.nl Cc: Sylwester Nawrocki sylvester.nawro...@gmail.com Hmm... weren't it reviewed already be them? Yes, Hans and Sylwester reviewed the various versions and Takashi reviewed the alsa part. I added a Cc, so they could review the changes made after their comments. Do you think I should drop it in v9? Signed-off-by: Ezequiel Garcia elezegar...@gmail.com diff --git a/drivers/media/video/stk1160/Makefile b/drivers/media/video/stk1160/Makefile new file mode 100644 index 000..8f66a78 --- /dev/null +++ b/drivers/media/video/stk1160/Makefile @@ -0,0 +1,12 @@ +obj-stk1160-ac97-$(CONFIG_VIDEO_STK1160_AC97) := stk1160-ac97.o + +stk1160-y := stk1160-core.o \ + stk1160-v4l.o \ + stk1160-video.o \ + stk1160-i2c.o \ + $(obj-stk1160-ac97-y) + +obj-$(CONFIG_VIDEO_STK1160) += stk1160.o + +ccflags-y += -Wall You shouldn't be adding the above here. Okey. +ccflags-y += -Idrivers/media/video Ah, please split this patch into two patches: one with the new driver addition, and another one with the removal of the driver at staging. That will help to make the patch smaller, and avoids mixing two different things at the same place. No problem. I hope the easycap removal patch passes through vger! Thanks, You are welcome :-) Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Aug 9 19:00:28 CEST 2012 git hash:c3707357c6c651652a87a05eabd7582f90a4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.6] Add adv7604/ad9389b drivers
Hi Hans,
It follows a few notes about what I've seen at the two initial patches.
I didn't review the other ones, as they should follow whatever agreed
at the API/spec changes.
It should be noticed that I'm not a monitor-set expert (while I have
some past experiences playing with monitor's EDID information, due to
some bugs I noticed in the past with some monitors I used to have).
So, it would be nice to have someone from drivers/video to do a review
on this series (or at least, the API/spec changes).
Regards,
Mauro
-
Em 23-07-2012 08:36, Hans Verkuil escreveu:
Hi all!
There haven't been any comments since either RFCv1 or RFCv2.
(http://www.spinics.net/lists/linux-media/msg48529.html and
http://www.spinics.net/lists/linux-media/msg50413.html)
So I'm making this pull request now.
The only changes since RFCv2 are some documentation fixes:
- Add a note that the SUBDEV_G/S_EDID ioctls are experimental
- Add the proper revision/experimental references.
- Update the spec version to 3.6.
Regards,
Hans
The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41:
Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44
-0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git hdmi2
for you to fetch changes up to d3e17e09dfd48ce8a8f7c6d80ca777230b487855:
ad9389b: driver for the Analog Devices AD9389B video encoder. (2012-07-23
13:34:01 +0200)
Hans Verkuil (7):
v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
+struct v4l2_subdev_edid {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ __u8 __user *edid;
+};
Hmm you'll need compat32 bits for this struct. Maybe also packing it.
V4L2 spec: document the new DV controls and ioctls.
Documentation/DocBook/media/v4l/controls.xml | 149
Documentation/DocBook/media/v4l/v4l2.xml | 1 +
.../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152
+
3 files changed, 302 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 6c27f7b..9b0a161 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4274,4 +4274,153 @@ interface and may change in the future./para
/table
/section
+
+section id=dv-controls
+ titleDigital Video Control Reference/title
+
+ note
+ titleExperimental/title
+
+ paraThis is an link
+ linkend=experimentalexperimental/link interface and may
+ change in the future./para
+ /note
+
+ para
+ The Digital Video control class is intended to control receivers
+ and transmitters for VGA, DVI, HDMI and DisplayPort. These controls
+ are generally expected to be private to the receiver or transmitter
+ subdevice that implements them, so they are only exposed on the
+ filename/dev/v4l-subdev*/filename device node.
+ /para
+
+ paraNote that these devices can have multiple input or output pads
which are
+ hooked up to e.g. HDMI connectors. Even though the subdevice will
receive or
+ transmit video from/to only one of those pads, the other pads can
still be
+ active when it comes to EDID and HDCP processing, allowing the device
+ to do the fairly slow EDID/HDCP handling in advance. This allows for
quick
+ switching between connectors./para
+
+ paraThese pads appear in several of the controls in this section as
+ bitmasks, one bit for each pad starting at bit 0. The maximum value of
+ the control is the set of valid pads./para
+
+ table pgwide=1 frame=none id=dv-control-id
+ titleDigital Video Control IDs/title
+
+ tgroup cols=4
+ colspec colname=c1 colwidth=1* /
+ colspec colname=c2 colwidth=6* /
+ colspec colname=c3 colwidth=2* /
+ colspec colname=c4 colwidth=6* /
+ spanspec namest=c1 nameend=c2 spanname=id /
+ spanspec namest=c2 nameend=c4 spanname=descr /
+ thead
+ row
+ entry spanname=id align=leftID/entry
+ entry align=leftType/entry
+ /rowrow rowsep=1entry spanname=descr
align=leftDescription/entry
+ /row
+ /thead
+ tbody valign=top
+ rowentry/entry/row
+ row
+ entry spanname=idconstantV4L2_CID_DV_CLASS/constant/entry
+ entryclass/entry
+ /row
+ row
+ entry spanname=descrThe DV class descriptor./entry
Please replace 'DV' by digital video.
Btw, It may be useful to have a glossary with an acronym glossary for the ones
we won't
get rid of it (EDID, DVI, HDCP, ...), if possible pointing to an
[PATCH RFC 3/3] dvb_frontend: do not allow statistic IOCTLs when sleeping
Demodulator cannot perform statistic IOCTLs when it is not tuned.
Return -EPERM in such case.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 34 +++
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4fc11eb..40efcde 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -2157,27 +2157,43 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
err = fe-ops.read_status(fe, status);
break;
}
+
case FE_READ_BER:
- if (fe-ops.read_ber)
- err = fe-ops.read_ber(fe, (__u32*) parg);
+ if (fe-ops.read_ber) {
+ if (fepriv-thread)
+ err = fe-ops.read_ber(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_SIGNAL_STRENGTH:
- if (fe-ops.read_signal_strength)
- err = fe-ops.read_signal_strength(fe, (__u16*) parg);
+ if (fe-ops.read_signal_strength) {
+ if (fepriv-thread)
+ err = fe-ops.read_signal_strength(fe, (__u16
*) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_SNR:
- if (fe-ops.read_snr)
- err = fe-ops.read_snr(fe, (__u16*) parg);
+ if (fe-ops.read_snr) {
+ if (fepriv-thread)
+ err = fe-ops.read_snr(fe, (__u16 *) parg);
+ else
+ err = -EPERM;
+ }
break;
case FE_READ_UNCORRECTED_BLOCKS:
- if (fe-ops.read_ucblocks)
- err = fe-ops.read_ucblocks(fe, (__u32*) parg);
+ if (fe-ops.read_ucblocks) {
+ if (fepriv-thread)
+ err = fe-ops.read_ucblocks(fe, (__u32 *) parg);
+ else
+ err = -EPERM;
+ }
break;
-
case FE_DISEQC_RESET_OVERLOAD:
if (fe-ops.diseqc_reset_overload) {
err = fe-ops.diseqc_reset_overload(fe);
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 2/3] dvb_frontend: return -ENOTTY for unimplement IOCTL
Earlier it was returning -EOPNOTSUPP.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 4548fc9..4fc11eb 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1830,7 +1830,7 @@ static int dvb_frontend_ioctl(struct file *file,
struct dvb_frontend *fe = dvbdev-priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
- int err = -EOPNOTSUPP;
+ int err = -ENOTTY;
dev_dbg(fe-dvb-device, %s: (%d)\n, __func__, _IOC_NR(cmd));
if (fepriv-exit != DVB_FE_NO_EXIT)
@@ -1948,7 +1948,7 @@ static int dvb_frontend_ioctl_properties(struct file
*file,
}
} else
- err = -EOPNOTSUPP;
+ err = -ENOTTY;
out:
kfree(tvp);
@@ -2081,7 +2081,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
struct dvb_frontend *fe = dvbdev-priv;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dtv_frontend_properties *c = fe-dtv_property_cache;
- int cb_err, err = -EOPNOTSUPP;
+ int cb_err, err = -ENOTTY;
if (fe-dvb-fe_ioctl_override) {
cb_err = fe-dvb-fe_ioctl_override(fe, cmd, parg,
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 1/3] dvb_frontend: use Kernel dev_* logging
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 226 +++---
1 file changed, 116 insertions(+), 110 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 13cf4d2..4548fc9 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -66,8 +66,6 @@ MODULE_PARM_DESC(dvb_powerdown_on_sleep, 0: do not power
down, 1: turn LNB volt
module_param(dvb_mfe_wait_time, int, 0644);
MODULE_PARM_DESC(dvb_mfe_wait_time, Wait up to mfe_wait_time seconds on
open() for multi-frontend to become available (default:5 seconds));
-#define dprintk if (dvb_frontend_debug) printk
-
#define FESTATE_IDLE 1
#define FESTATE_RETUNE 2
#define FESTATE_TUNING_FAST 4
@@ -207,7 +205,7 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe,
fe_status_t status)
struct dvb_frontend_event *e;
int wp;
- dprintk (%s\n, __func__);
+ dev_dbg(fe-dvb-device, %s:\n, __func__);
if ((status FE_HAS_LOCK) has_get_frontend(fe))
dtv_get_frontend(fe, fepriv-parameters_out);
@@ -237,7 +235,7 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dvb_fe_events *events = fepriv-events;
- dprintk (%s\n, __func__);
+ dev_dbg(fe-dvb-device, %s:\n, __func__);
if (events-overflow) {
events-overflow = 0;
@@ -282,10 +280,9 @@ static void dvb_frontend_clear_events(struct dvb_frontend
*fe)
static void dvb_frontend_init(struct dvb_frontend *fe)
{
- dprintk (DVB: initialising adapter %i frontend %i (%s)...\n,
-fe-dvb-num,
-fe-id,
-fe-ops.info.name);
+ dev_dbg(fe-dvb-device,
+ %s: initialising adapter %i frontend %i (%s)...\n,
+ __func__, fe-dvb-num, fe-id, fe-ops.info.name);
if (fe-ops.init)
fe-ops.init(fe);
@@ -319,8 +316,9 @@ EXPORT_SYMBOL(dvb_frontend_retune);
static void dvb_frontend_swzigzag_update_delay(struct dvb_frontend_private
*fepriv, int locked)
{
int q2;
+ struct dvb_frontend *fe = fepriv-dvbdev-priv;
- dprintk (%s\n, __func__);
+ dev_dbg(fe-dvb-device, %s:\n, __func__);
if (locked)
(fepriv-quality) = (fepriv-quality * 220 + 36*256) / 256;
@@ -412,10 +410,11 @@ static int dvb_frontend_swzigzag_autotune(struct
dvb_frontend *fe, int check_wra
return 1;
}
- dprintk(%s: drift:%i inversion:%i auto_step:%i
- auto_sub_step:%i started_auto_step:%i\n,
- __func__, fepriv-lnb_drift, fepriv-inversion,
- fepriv-auto_step, fepriv-auto_sub_step,
fepriv-started_auto_step);
+ dev_dbg(fe-dvb-device, %s: drift:%i inversion:%i auto_step:%i \
+ auto_sub_step:%i started_auto_step:%i\n,
+ __func__, fepriv-lnb_drift, fepriv-inversion,
+ fepriv-auto_step, fepriv-auto_sub_step,
+ fepriv-started_auto_step);
/* set the frontend itself */
c-frequency += fepriv-lnb_drift;
@@ -614,7 +613,7 @@ static int dvb_frontend_thread(void *data)
bool re_tune = false;
- dprintk(%s\n, __func__);
+ dev_dbg(fe-dvb-device, %s:\n, __func__);
fepriv-check_wrapped = 0;
fepriv-quality = 0;
@@ -660,10 +659,10 @@ restart:
algo = fe-ops.get_frontend_algo(fe);
switch (algo) {
case DVBFE_ALGO_HW:
- dprintk(%s: Frontend ALGO = DVBFE_ALGO_HW\n,
__func__);
+ dev_dbg(fe-dvb-device, %s: Frontend ALGO =
DVBFE_ALGO_HW\n, __func__);
if (fepriv-state FESTATE_RETUNE) {
- dprintk(%s: Retune requested,
FESTATE_RETUNE\n, __func__);
+ dev_dbg(fe-dvb-device, %s: Retune
requested, FESTATE_RETUNE\n, __func__);
re_tune = true;
fepriv-state = FESTATE_TUNED;
} else {
@@ -674,19 +673,19 @@ restart:
fe-ops.tune(fe, re_tune,
fepriv-tune_mode_flags, fepriv-delay, s);
if (s != fepriv-status
!(fepriv-tune_mode_flags FE_TUNE_MODE_ONESHOT)) {
- dprintk(%s: state changed, adding
current state\n, __func__);
+ dev_dbg(fe-dvb-device, %s: state
changed, adding current state\n, __func__);
dvb_frontend_add_event(fe, s);
fepriv-status = s;
}
[PATCH RFC 0/3] dvb-frontend statistic IOCTL validation
I added some logic to prevent statistic queries in case demodulator is clearly in state statistic query is invalid. Currently there could be checks in device driver but usually not. Garbage is usually returned and in some cases even I/O errors are generated as demod is put sleep and cannot answer any request. I selected EPERM as error code for such cases. There was some other potential codes, but this one sounds best. And after quick grepping it is used by V4L2 for similar situation. Other error codes I found somehow suitable are: #define EPERM1 /* Operation not permitted */ #define EAGAIN 11 /* Try again */ #define EACCES 13 /* Permission denied */ #define EBUSY 16 /* Device or resource busy */ #define ENODATA 61 /* No data available */ #define ECANCELED 125 /* Operation Canceled */ Any comments? Antti Palosaari (3): dvb_frontend: use Kernel dev_* logging dvb_frontend: return -ENOTTY for unimplement IOCTL dvb_frontend: do not allow statistic IOCTLs when sleeping drivers/media/dvb/dvb-core/dvb_frontend.c | 266 -- 1 file changed, 144 insertions(+), 122 deletions(-) -- 1.7.11.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] add LNA support for DVB API
On 07/12/2012 04:04 AM, Antti Palosaari wrote:
Any comment about that?
Should I store value to cache?
Should I offer get too?
Should I offer way to query possible values?
I think that implementation is quite simply and safe to add. Lets extend
later if really needed...
regards
Antti
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-core/dvb_frontend.c |5 +
drivers/media/dvb/dvb-core/dvb_frontend.h |1 +
include/linux/dvb/frontend.h |4 +++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index b54c297..fe22aaa 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1020,6 +1020,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
_DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_LNA, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1723,6 +1724,10 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c-interleaving = tvp-u.data;
break;
+ case DTV_LNA:
+ if (fe-ops.set_lna)
+ r = fe-ops.set_lna(fe, tvp-u.data);
+ break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 31a3d1c..628a821 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -302,6 +302,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
+ int (*set_lna)(struct dvb_frontend *, int);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 2dd5823..e28802a 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -350,8 +350,9 @@ struct dvb_frontend_event {
#define DTV_ATSCMH_SCCC_CODE_MODE_D 59
#define DTV_INTERLEAVING 60
+#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_INTERLEAVING
+#define DTV_MAX_COMMANDDTV_LNA
typedef enum fe_pilot {
PILOT_ON,
@@ -424,6 +425,7 @@ enum atscmh_rs_code_mode {
ATSCMH_RSCODE_RES= 3,
};
+#define LNA_AUTO INT_MIN
struct dtv_cmds_h {
char*name; /* A display name for debugging purposes */
--
http://palosaari.fi/
--
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 17/24] au0828: fix possible race condition in usage of dev-ctrlmsg
Em 06-08-2012 23:47, Devin Heitmueller escreveu:
The register read function is referencing the dev-ctrlmsg structure outside
of the dev-mutex lock, which can cause corruption of the value if multiple
callers are invoking au0828_readreg() simultaneously.
Use a stack variable to hold the result, and copy the buffer returned by
usb_control_msg() to that variable.
It is NOT OK to use stack to send and/or receive control messages. The USB core
uses DMA transfers for sending/receiving data via USB; the memory used by stack
is not warranted to be at the DMA-able area. This problem is more frequent on
ARM-based machines, but even on Intel, the urb_control_msg() may fail.
In reality, the whole recv_control_msg() function can probably be collapsed
into au0288_readreg() since it is the only caller.
Also get rid of cmd_msg_dump() since the only case in which the function is
ever called only is ever passed a single byte for the response (and it is
already logged).
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
---
drivers/media/video/au0828/au0828-core.c | 40
+-
1 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-core.c
b/drivers/media/video/au0828/au0828-core.c
index 65914bc..745a80a 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -56,9 +56,12 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
u32 au0828_readreg(struct au0828_dev *dev, u16 reg)
{
- recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, dev-ctrlmsg, 1);
- dprintk(8, %s(0x%04x) = 0x%02x\n, __func__, reg, dev-ctrlmsg[0]);
- return dev-ctrlmsg[0];
+ u8 result = 0;
+
+ recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, result, 1);
As explained above, this won't work, as result is at stack, not warranted to be
at the
DMA-able area. So, either you could lock this function, or you'll need to
allocate
it with kmalloc() and free it after using the data.
+ dprintk(8, %s(0x%04x) = 0x%02x\n, __func__, reg, result);
+
+ return result;
}
u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
@@ -67,24 +70,6 @@ u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32
val)
return send_control_msg(dev, CMD_REQUEST_OUT, val, reg);
}
-static void cmd_msg_dump(struct au0828_dev *dev)
-{
- int i;
-
- for (i = 0; i sizeof(dev-ctrlmsg); i += 16)
- dprintk(2, %s() %02x %02x %02x %02x %02x %02x %02x %02x
- %02x %02x %02x %02x %02x %02x %02x %02x\n,
- __func__,
- dev-ctrlmsg[i+0], dev-ctrlmsg[i+1],
- dev-ctrlmsg[i+2], dev-ctrlmsg[i+3],
- dev-ctrlmsg[i+4], dev-ctrlmsg[i+5],
- dev-ctrlmsg[i+6], dev-ctrlmsg[i+7],
- dev-ctrlmsg[i+8], dev-ctrlmsg[i+9],
- dev-ctrlmsg[i+10], dev-ctrlmsg[i+11],
- dev-ctrlmsg[i+12], dev-ctrlmsg[i+13],
- dev-ctrlmsg[i+14], dev-ctrlmsg[i+15]);
-}
-
static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
u16 index)
{
@@ -118,24 +103,23 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
int status = -ENODEV;
mutex_lock(dev-mutex);
if (dev-usbdev) {
-
- memset(dev-ctrlmsg, 0, sizeof(dev-ctrlmsg));
-
- /* cp must be memory that has been allocated by kmalloc */
status = usb_control_msg(dev-usbdev,
usb_rcvctrlpipe(dev-usbdev, 0),
request,
USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
value, index,
- cp, size, 1000);
+ dev-ctrlmsg, size, 1000);
status = min(status, 0);
if (status 0) {
printk(KERN_ERR %s() Failed receiving control message,
error %d.\n,
__func__, status);
- } else
- cmd_msg_dump(dev);
+ }
+
+ /* the host controller requires heap allocated memory, which
+is why we didn't just pass cp into usb_control_msg */
+ memcpy(cp, dev-ctrlmsg, size);
}
mutex_unlock(dev-mutex);
return status;
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tda18212: silence compiler warning
Trivial fix.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/common/tuners/tda18212.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/common/tuners/tda18212.c
b/drivers/media/common/tuners/tda18212.c
index 602c2e3..a14e8b6 100644
--- a/drivers/media/common/tuners/tda18212.c
+++ b/drivers/media/common/tuners/tda18212.c
@@ -287,7 +287,7 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
{
struct tda18212_priv *priv = NULL;
int ret;
- u8 val;
+ u8 uninitialized_var(val);
priv = kzalloc(sizeof(struct tda18212_priv), GFP_KERNEL);
if (priv == NULL)
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] tda18212: use Kernel dev_* logging
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/common/tuners/tda18212.c | 35 ++
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/media/common/tuners/tda18212.c
b/drivers/media/common/tuners/tda18212.c
index a14e8b6..5d9f028 100644
--- a/drivers/media/common/tuners/tda18212.c
+++ b/drivers/media/common/tuners/tda18212.c
@@ -18,8 +18,6 @@
*51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
-#define pr_fmt(fmt) KBUILD_MODNAME : fmt
-
#include tda18212.h
struct tda18212_priv {
@@ -29,16 +27,6 @@ struct tda18212_priv {
u32 if_frequency;
};
-#define dbg(fmt, arg...) \
-do { \
- if (debug) \
- pr_info(%s: fmt, __func__, ##arg); \
-} while (0)
-
-static int debug;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, Turn on/off debugging (default:off).);
-
/* write multiple registers */
static int tda18212_wr_regs(struct tda18212_priv *priv, u8 reg, u8 *val,
int len)
@@ -61,8 +49,8 @@ static int tda18212_wr_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
if (ret == 1) {
ret = 0;
} else {
- pr_warn(i2c wr failed ret:%d reg:%02x len:%d\n,
- ret, reg, len);
+ dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x \
+ len=%d\n, KBUILD_MODNAME, ret, reg, len);
ret = -EREMOTEIO;
}
return ret;
@@ -93,8 +81,8 @@ static int tda18212_rd_regs(struct tda18212_priv *priv, u8
reg, u8 *val,
memcpy(val, buf, len);
ret = 0;
} else {
- pr_warn(i2c rd failed ret:%d reg:%02x len:%d\n,
- ret, reg, len);
+ dev_warn(priv-i2c-dev, %s: i2c rd failed=%d reg=%02x \
+ len=%d\n, KBUILD_MODNAME, ret, reg, len);
ret = -EREMOTEIO;
}
@@ -157,8 +145,10 @@ static int tda18212_set_params(struct dvb_frontend *fe)
[DVBC_8] = { 0x92, 0x53, 0x03 },
};
- dbg(delsys=%d RF=%d BW=%d\n,
- c-delivery_system, c-frequency, c-bandwidth_hz);
+ dev_dbg(priv-i2c-dev,
+ %s: delivery_system=%d frequency=%d bandwidth_hz=%d\n,
+ __func__, c-delivery_system, c-frequency,
+ c-bandwidth_hz);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
@@ -247,7 +237,7 @@ exit:
return ret;
error:
- dbg(failed:%d\n, ret);
+ dev_dbg(priv-i2c-dev, %s: failed=%d\n, __func__, ret);
goto exit;
}
@@ -306,13 +296,16 @@ struct dvb_frontend *tda18212_attach(struct dvb_frontend
*fe,
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0); /* close I2C-gate */
- dbg(ret:%d chip ID:%02x\n, ret, val);
+ dev_dbg(priv-i2c-dev, %s: ret=%d chip id=%02x\n, __func__, ret,
+ val);
if (ret || val != 0xc7) {
kfree(priv);
return NULL;
}
- pr_info(NXP TDA18212HN successfully identified\n);
+ dev_info(priv-i2c-dev,
+ %s: NXP TDA18212HN successfully identified\n,
+ KBUILD_MODNAME);
memcpy(fe-ops.tuner_ops, tda18212_tuner_ops,
sizeof(struct dvb_tuner_ops));
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] tda18218: silence compiler warning
Trivial fix.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/common/tuners/tda18218.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
index dfb3a83..8a6f9ca 100644
--- a/drivers/media/common/tuners/tda18218.c
+++ b/drivers/media/common/tuners/tda18218.c
@@ -282,7 +282,7 @@ struct dvb_frontend *tda18218_attach(struct dvb_frontend
*fe,
struct i2c_adapter *i2c, struct tda18218_config *cfg)
{
struct tda18218_priv *priv = NULL;
- u8 val;
+ u8 uninitialized_var(val);
int ret;
/* chip default registers values */
static u8 def_regs[] = {
--
1.7.11.2
--
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 17/24] au0828: fix possible race condition in usage of dev-ctrlmsg
On Thu, Aug 9, 2012 at 7:48 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 06-08-2012 23:47, Devin Heitmueller escreveu:
The register read function is referencing the dev-ctrlmsg structure outside
of the dev-mutex lock, which can cause corruption of the value if multiple
callers are invoking au0828_readreg() simultaneously.
Use a stack variable to hold the result, and copy the buffer returned by
usb_control_msg() to that variable.
It is NOT OK to use stack to send and/or receive control messages. The USB
core
uses DMA transfers for sending/receiving data via USB; the memory used by
stack
is not warranted to be at the DMA-able area. This problem is more frequent on
ARM-based machines, but even on Intel, the urb_control_msg() may fail.
In reality, the whole recv_control_msg() function can probably be collapsed
into au0288_readreg() since it is the only caller.
Also get rid of cmd_msg_dump() since the only case in which the function is
ever called only is ever passed a single byte for the response (and it is
already logged).
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
---
drivers/media/video/au0828/au0828-core.c | 40
+-
1 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/au0828/au0828-core.c
b/drivers/media/video/au0828/au0828-core.c
index 65914bc..745a80a 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -56,9 +56,12 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
u32 au0828_readreg(struct au0828_dev *dev, u16 reg)
{
- recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, dev-ctrlmsg, 1);
- dprintk(8, %s(0x%04x) = 0x%02x\n, __func__, reg, dev-ctrlmsg[0]);
- return dev-ctrlmsg[0];
+ u8 result = 0;
+
+ recv_control_msg(dev, CMD_REQUEST_IN, 0, reg, result, 1);
As explained above, this won't work, as result is at stack, not warranted to
be at the
DMA-able area. So, either you could lock this function, or you'll need to
allocate
it with kmalloc() and free it after using the data.
+ dprintk(8, %s(0x%04x) = 0x%02x\n, __func__, reg, result);
+
+ return result;
}
u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32 val)
@@ -67,24 +70,6 @@ u32 au0828_writereg(struct au0828_dev *dev, u16 reg, u32
val)
return send_control_msg(dev, CMD_REQUEST_OUT, val, reg);
}
-static void cmd_msg_dump(struct au0828_dev *dev)
-{
- int i;
-
- for (i = 0; i sizeof(dev-ctrlmsg); i += 16)
- dprintk(2, %s() %02x %02x %02x %02x %02x %02x %02x %02x
- %02x %02x %02x %02x %02x %02x %02x %02x\n,
- __func__,
- dev-ctrlmsg[i+0], dev-ctrlmsg[i+1],
- dev-ctrlmsg[i+2], dev-ctrlmsg[i+3],
- dev-ctrlmsg[i+4], dev-ctrlmsg[i+5],
- dev-ctrlmsg[i+6], dev-ctrlmsg[i+7],
- dev-ctrlmsg[i+8], dev-ctrlmsg[i+9],
- dev-ctrlmsg[i+10], dev-ctrlmsg[i+11],
- dev-ctrlmsg[i+12], dev-ctrlmsg[i+13],
- dev-ctrlmsg[i+14], dev-ctrlmsg[i+15]);
-}
-
static int send_control_msg(struct au0828_dev *dev, u16 request, u32 value,
u16 index)
{
@@ -118,24 +103,23 @@ static int recv_control_msg(struct au0828_dev *dev,
u16 request, u32 value,
int status = -ENODEV;
mutex_lock(dev-mutex);
if (dev-usbdev) {
-
- memset(dev-ctrlmsg, 0, sizeof(dev-ctrlmsg));
-
- /* cp must be memory that has been allocated by kmalloc */
status = usb_control_msg(dev-usbdev,
usb_rcvctrlpipe(dev-usbdev, 0),
request,
USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
value, index,
- cp, size, 1000);
+ dev-ctrlmsg, size, 1000);
status = min(status, 0);
if (status 0) {
printk(KERN_ERR %s() Failed receiving control
message, error %d.\n,
__func__, status);
- } else
- cmd_msg_dump(dev);
+ }
+
+ /* the host controller requires heap allocated memory, which
+is why we didn't just pass cp into usb_control_msg */
+ memcpy(cp, dev-ctrlmsg, size);
}
mutex_unlock(dev-mutex);
return status;
Regards,
Mauro
Hi Mauro,
You seem to have misinterpreted the patch description. The actual
call to usb_control_msg() does use a heap allocated memory region.
However we copy the result to a stack variable after the call to
usb_control_msg. This is done so that dev-ctrlmsg[] is used
exclusively inside of the mutex (and not accessed after the mutex is
