[GIT PATCHES FOR 3.0] gspca jpgl
The following changes since commit c21fd1a8c68ce3f49b00caf10337169262cfb8ad: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 (2011-05-21 00:13:03 -0700) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git jpgl Jean-François Moine (1): v4l: Documentation about the JPGL pixel format Documentation/DocBook/v4l/pixfmt.xml |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v2] v4l: add control definitions for codec devices.
Hi, -Original Message- From: Kamil Debski [mailto:k.deb...@samsung.com] Sent: Thursday, June 02, 2011 11:44 PM To: jtp.p...@samsung.com; linux-media@vger.kernel.org Cc: jaeryul...@samsung.com; june@samsung.com; janghyuck@samsung.com; kyungmin.p...@samsung.com; younglak1004@samsung.com; 'Marek Szyprowski' Subject: RE: [RFC/PATCH v2] v4l: add control definitions for codec devices. From: Jeongtae Park [mailto:jtp.p...@samsung.com] Sent: 02 June 2011 09:44 To: 'Kamil Debski'; linux-media@vger.kernel.org Cc: jaeryul...@samsung.com; june@samsung.com; janghyuck@samsung.com; kyungmin.p...@samsung.com; younglak1004@samsung.com; 'Marek Szyprowski' Subject: RE: [RFC/PATCH v2] v4l: add control definitions for codec devices. Hi, Thank you for your nice work. Here are my some comments. Hi, Thanks for your comments. I think I must have posted the wrong patch file... I will send the proper one, with some of your suggestion in a minute. -Original Message- From: Kamil Debski [mailto:k.deb...@samsung.com] Sent: Tuesday, May 31, 2011 6:08 PM Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com; k.deb...@samsung.com; jaeryul...@samsung.com; hverk...@xs4all.nl; laurent.pinch...@ideasonboard.com; jtp.p...@samsung.com Subject: [RFC/PATCH v2] v4l: add control definitions for codec devices. Hi, This is a second version of the patch that adds controls for the codec family of devices. I have implemented the suggestions I got from Hans Verkuil on the #v4l channel. Change log: - rename V4L2_CID_MIN_REQ_BUFS_(CAP/OUT) to V4L2_CID_MIN_BUFFERS_FOR_(CAPTURE/OUTPUT) - use existing controls for GOP size, number of frames and GOP closure - remove frame rate controls (in favour of the S_PARM call) - split level into separate controls for MPEG4 and H264 I would welcome further comments. Best regards, Kamil Debski Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/v4l/controls.xml | 733 include/linux/videodev2.h | 147 +++ 2 files changed, 880 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 6880798..7c2df42 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_MAX_REF_PIC/constantnbsp;/en try + entryboolean/entry + /row + rowentry spanname=descrThe maximum number of reference pictures used for encoding./entry + /row Is it boolean type? It is not, a copy-paste mistake on my side. [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_BETA/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrLoop filter alpha coefficient, defined in the standard./entry + /row alpha - beta. I agree. [snip] + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE/constantnbsp; /entry + entryboolean/entry + /row + rowentry spanname=descrPadding enable - use a color instead of repeating border pixels./entry + /row The description may be wrong. Thanks for pointing this out. + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_MB_RC_ENABLE/constantnbs p;/entry + entryboolean/entry + /row + rowentry spanname=descrMacroblock level rate control enable for H264./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RATE_NOMINATOR/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrFrames per second - nominator./entry + /row Removed as you mentioned. Yes, I think I had to mix up the patches that got sent. + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_FRAME_RATE_DENOMINATOR/constant nbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrFrames per second - denominator/entry + /row + Removed as you mentioned. Ditto. [snip] + + rowentry/entry/row + row + entry
Re: [PATCH] [media] V4L/videobuf2-memops: use pr_debug for debug messages
Hello Mauro,
On Wed, Jun 01, 2011 at 10:34:31PM -0300, Mauro Carvalho Chehab wrote:
Hi Kyungmin,
Em 01-06-2011 21:50, Kyungmin Park escreveu:
Acked-by: Kyungmin Park kyunginn.,p...@samsung.com
As this patch is really trivial and makes sense, I've just applied it earlier
today.
You somehow screwed up my name in the Author field more than I'm used
to:
$ git cat-file commit 215c52702775556f4caf5872cc84fa8810e6fc7d | grep Uwe
author Uwe Kleine-König u.kleine-koe...@pengutronix.de 1306959562
-0300
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Strange enough my name in the commitlog looks fine.
If you care to fix it, you can easily do so using git filter-branch.
E.g.:
$ git filter-branch --env-filter 'test x$GIT_COMMIT !=
x215c52702775556f4caf5872cc84fa8810e6fc7d || { GIT_AUTHOR_NAME=Uwe
Kleine-König; export GIT_AUTHOR_NAME; }' ^215c5270277^ HEAD
(Assuming an UTF-8 locale.)
This converts 215c527 to a commit c6cbbfc that has my name fixed and
rebases all following commits on top of this. In your master branch this
only affects 00c4526 (Merge /home/v4l/v4l/for_upstream)
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
HELLO
hello i like us to communicate as you reply to my mail hope to hear from you soon i will reply with my picture and more about me. with love Anna -- 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: [RFCv1 PATCH 4/5] DocBook: document autoclusters.
On Friday, May 27, 2011 16:57:54 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/video4linux/v4l2-controls.txt | 56
+++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 65d4652..6e277fe 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -452,6 +452,25 @@ In the example above the following are equivalent for
the VOLUME case:
ctrl == ctrl-cluster[AUDIO_CL_VOLUME] ==
state-audio_cluster[AUDIO_CL_VOLUME]
ctrl-cluster[AUDIO_CL_MUTE] == state-audio_cluster[AUDIO_CL_MUTE]
+In practice using cluster arrays like this becomes very tiresome. So instead
+the following equivalent method is used:
+
+ struct {
+ /* audio cluster */
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *mute;
+ };
+
+The anonymous struct is used to clearly 'cluster' these two control pointers,
+but it serves no other purpose. The effect is the same as creating an
+array with two control pointers. So you can just do:
+
+ state-volume = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+ state-mute = v4l2_ctrl_new_std(state-ctrl_handler, ...);
+ v4l2_ctrl_cluster(2, state-volume);
+
+And in foo_s_ctrl you can use these pointers directly: state-mute-val.
+
Note that controls in a cluster may be NULL. For example, if for some
reason mute was never added (because the hardware doesn't support that
particular feature), then mute will be NULL. So in that case we have a
@@ -474,6 +493,43 @@ controls, then the 'is_new' flag would be 1 for both
controls.
The 'is_new' flag is always 1 when called from v4l2_ctrl_handler_setup().
+Handling autogain/gain-type Controls with Auto Clusters
+===
+
+A common type of control cluster is one that handles 'auto-foo/foo'-type
+controls. Typical examples are autogain/gain, autoexposure/exposure,
+autowhitebalance/red balance/blue balance. In all cases you have one controls
+that determines whether another control is handled automatically by the
hardware,
+or whether it is under manual control from the user.
+
+If the cluster is in automatic mode, then the manual controls should be
+marked read-only if they are volatile and inactive if they are non-volatile.
I have slept on this some more and I really don't like the idea of marking
controls as read-only in this case. While this is fine in theory, in practice
it leads to awkward situations.
One problem with this is that when you set e.g. autogain and gain together using
VIDIOC_S_EXT_CTRLS you would have to return -EACCES if you set autogain to 1.
After all, if autogain is 1, then gain would be marked read-only and so setting
it should return -EACCES. But before the call to S_EXT_CTRLS the gain control is
marked writable (assuming autogain was 0). That's really unexpected behavior,
even though it is correct in theory.
Another problem is that there is no application currently that assumes that the
read-only flag can change on the fly. So control panels and such will not work
correctly. So making this change will most likely break existing applications.
I propose instead to change the behavior to set the INACTIVE flag instead.
So setting the gain control will always work, except that the manual gain
value won't be used (activated) until autogain is set to 0.
Reading the gain value will either return the manual gain that you set (if
gain is a non-volatile control) or the gain value as calculated by the autogain
hardware (if autogain is 1 and the gain control was marked volatile).
This will also simplify the patches (an additional bonus).
I will prepare an RFCv2 for this.
Regards,
Hans
+When the volatile controls are read the g_volatile_ctrl operation should
return
+the value that the hardware's automatic mode set up automatically.
+
+If the cluster is put in manual mode, then the manual controls should become
+writable/active again and the is_volatile flag should be ignored (so
+g_volatile_ctrl is no longer called while in manual mode).
+
+Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
+changing that control affects the control flags of the manual controls.
+
+In order to simplify this a special variation of v4l2_ctrl_cluster was
+introduced:
+
+void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
+ u8 manual_val, bool set_volatile);
+
+The first two arguments are identical to v4l2_ctrl_cluster. The third
argument
+tells the framework which value switches the cluster into manual mode. The
+last argument will optionally set is_volatile flag for the non-auto controls.
+
+The first control of the cluster
RE: [PATCH v2] [media] at91: add Atmel Image Sensor Interface (ISI) support
Hi, Guennadi
Guennadi Liakhovetski wrote on May 29, 2011 4:25 AM
Hi Josh
Thanks for the update. A general note: I much prefer the new IO accessors and
register names and values - thanks for changing that!
Thank you for the reviewing. I also think this version is clearer. :)
Base on the suggestion from you and J.C, I will send out the version 3 soon.
On Fri, 27 May 2011, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Signed-off-by: Josh Wu josh...@atmel.com
---
Modified in V2 patch:
[snip]
+
+#include linux/clk.h
+#include linux/completion.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
You had linux/module.h here in v1, I think, it is needed for various
MODULE_AUTHOR() etc. macros. Please, re-add.
I will add it.
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/delay.h
+
+#include mach/board.h
+#include mach/cpu.h
I still don't understand, why you need these two. If unneeded, please, remove.
I forgot to remove it. I'll remove this.
+
+#include media/videobuf2-dma-contig.h #include media/soc_camera.h
+#include media/soc_mediabus.h #include media/atmel-isi.h
Alphabetic order here too, please.
I will change the order.
+
+#define MAX_BUFFER_NUMS 32
NUM above doesn't need an S at the end - it's just a number of buffers,
not numbers.
sure, I will fix it.
+#define MAX_SUPPORT_WIDTH 2048
+#define MAX_SUPPORT_HEIGHT 2048
+#define VID_LIMIT_BYTES (16 * 1024 * 1024)
+#define MIN_FRAME_RATE 15
+#define FRAME_INTERVAL_MILLI_SEC(1000 / MIN_FRAME_RATE)
+
+/* ISI states */
+enum {
+ISI_STATE_IDLE = 0,
+ISI_STATE_READY,
+ISI_STATE_WAIT_SOF,
+};
+
+/* Frame buffer descriptor */
+struct fbd {
+/* Physical address of the frame buffer */
+u32 fb_address;
+/* DMA Control Register(only in HISI2) */
+u32 dma_ctrl;
Ok, several reviewers, including myself, asked you to remove #ifdef here, but
at least I didn't realise at that moment, that this struct describes
hareware-specific memory layout. So, how is it supposed to work now on
platforms, that don't have this field, i.e., !CONFIG_ARCH_AT91SAM9G45 and
!CONFIG_ARCH_AT91SAM9X5? Or are they not supported yet? Maybe you could
define two structs - later, when you also support other CPUs, and use a
union or something else?
This dma_ctrl is hardware related memory layout. In the ISI_V1 hardware
(AT91SAM9263, AVR32, etc), there is no dma_ctrl in the descriptor. In the
future I prefer to add another ISI_V1 fbd structure and a function to handle
these two structures according to hardware. But in this version I think ISI_V1
hardware platform is not supported.
+/* Physical address of the next fbd */
+u32 next_fbd_address;
+};
+
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl) {
+fb_desc-dma_ctrl = ctrl;
+}
+
+/* Frame buffer data */
+struct frame_buffer {
+struct vb2_buffer vb;
+struct fbd *p_fb_desc;
+u32 fb_desc_phys;
+struct list_head list;
+};
+
+struct atmel_isi {
+/* Protects the access of variables shared with the ISR */
+spinlock_t lock;
+void __iomem*regs;
+
+int sequence;
+/* State of the ISI module in capturing mode */
+int state;
+
+/* Capture/streaming wait queue for waiting for SOF */
+wait_queue_head_t capture_wq;
+
+struct vb2_alloc_ctx*alloc_ctx;
+
+/* Allocate descriptors for dma buffer use */
+struct fbd *p_fb_descriptors;
+u32 fb_descriptors_phys;
+int index_fb_desc;
+
+struct completion isi_complete;
You don't need to prefix members in structs, especially since you don't do
this with others. Just leave complete or something similar.
I will change the name.
[snip]
+
+if (!buf-p_fb_desc) {
+/* Initialize the dma descriptor */
+buf-p_fb_desc = isi-p_fb_descriptors[isi-index_fb_desc];
+buf-fb_desc_phys = isi-fb_descriptors_phys +
+isi-index_fb_desc * sizeof(struct fbd);
+
+buf-p_fb_desc-fb_address = vb2_dma_contig_plane_paddr(vb, 0);
+buf-p_fb_desc-next_fbd_address = 0;
+set_dma_ctrl(buf-p_fb_desc, ISI_DMA_CTRL_WB);
+isi-index_fb_desc++;
+if (isi-index_fb_desc MAX_BUFFER_NUMS) {
+dev_err(icd-dev.parent, Not enough dma
descriptors.\n);
Don't you have to check overflow _before_ using the
RE: [PATCH v2] [media] at91: add Atmel Image Sensor Interface (ISI) support
Hi, Jean-Christophe
Thank you for the review.
Jean-Christophe PLAGNIOL-VILLARD wrote on Friday, May 27, 2011 8:06 PM:
+/* ISI interrupt service routine */
+static irqreturn_t isi_interrupt(int irq, void *dev_id) {
+struct atmel_isi *isi = dev_id;
+u32 status, mask, pending;
+irqreturn_t ret = IRQ_NONE;
+
+spin_lock(isi-lock);
+
+status = isi_readl(isi, ISI_STATUS);
+mask = isi_readl(isi, ISI_INTMASK);
+pending = status mask;
+
+if (pending ISI_CTRL_SRST) {
+complete(isi-isi_complete);
+isi_writel(isi, ISI_INTDIS, ISI_CTRL_SRST);
+ret = IRQ_HANDLED;
+}
+if (pending ISI_CTRL_DIS) {
+complete(isi-isi_complete);
+isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
+ret = IRQ_HANDLED;
+}
no else here?
+
+if (pending ISI_SR_VSYNC) {
+switch (isi-state) {
+case ISI_STATE_IDLE:
+isi-state = ISI_STATE_READY;
+wake_up_interruptible(isi-capture_wq);
+break;
+}
really switch here?
I will remove the switch here.
I think this part of IRQ handling code need to refine a little bit. The SRST
and DIS_DONE is more independent. And other interrupts can compose together.
Following is the latest code, I think is more reasonable.
if (pending ISI_CTRL_SRST) {
complete(isi-complete);
isi_writel(isi, ISI_INTDIS, ISI_CTRL_SRST);
ret = IRQ_HANDLED;
} else if (pending ISI_CTRL_DIS) {
complete(isi-complete);
isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
ret = IRQ_HANDLED;
} else {
if ((pending ISI_SR_VSYNC)
(isi-state == ISI_STATE_IDLE)) {
isi-state = ISI_STATE_READY;
wake_up_interruptible(isi-vsync_wq);
ret = IRQ_HANDLED;
}
if (likely(pending ISI_SR_CXFR_DONE))
ret = atmel_isi_handle_streaming(isi);
}
+} else if (likely(pending ISI_SR_CXFR_DONE)) {
+ret = atmel_isi_handle_streaming(isi);
+}
+
+spin_unlock(isi-lock);
+
+return ret;
+}
+
+#define WAIT_ISI_RESET 1
+#define WAIT_ISI_DISABLE0
+static int atmel_isi_wait_status(int wait_reset, struct atmel_isi
+*isi)
I thinkhave teh atmel_isti first parameter is better
I will fix it.
+{
+unsigned long timeout;
+/*
+ * The reset or disable will only succeed if we have a
+ * pixel clock from the camera.
+ */
+init_completion(isi-isi_complete);
+
+if (wait_reset) {
+isi_writel(isi, ISI_INTEN, ISI_CTRL_SRST);
+isi_writel(isi, ISI_CTRL, ISI_CTRL_SRST);
+} else {
+isi_writel(isi, ISI_INTEN, ISI_CTRL_DIS);
+isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
+}
+
+timeout = wait_for_completion_timeout(isi-isi_complete,
+msecs_to_jiffies(100));
+if (timeout == 0)
+return -ETIMEDOUT;
+
+return 0;
+}
+
+/* --
+Videobuf operations
+
+--*/
+static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
+unsigned int *nplanes, unsigned long sizes[],
+void *alloc_ctxs[])
+{
+struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+struct atmel_isi *isi = ici-priv;
+unsigned long size;
+int ret, bytes_per_line;
+
+/* Reset ISI */
+ret = atmel_isi_wait_status(WAIT_ISI_RESET, isi);
+if (ret 0) {
+dev_err(icd-dev.parent, Reset ISI timed out\n);
+return ret;
+}
+/* Disable all interrupts */
+isi_writel(isi, ISI_INTDIS, ~0UL);
+
+bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
+icd-current_fmt-host_fmt);
+
+if (bytes_per_line 0)
+return bytes_per_line;
+
+size = bytes_per_line * icd-user_height;
+
+if (*nbuffers == 0)
+*nbuffers = MAX_BUFFER_NUMS;
+if (*nbuffers MAX_BUFFER_NUMS)
else here
I will add it.
+*nbuffers = MAX_BUFFER_NUMS;
+
+if (size * *nbuffers VID_LIMIT_BYTES)
+*nbuffers = VID_LIMIT_BYTES / size;
+
+*nplanes = 1;
+sizes[0] = size;
+alloc_ctxs[0] = isi-alloc_ctx;
+
+isi-sequence = 0;
+isi-active = NULL;
+
+dev_dbg(icd-dev.parent, %s, count=%d, size=%ld\n, __func__,
+*nbuffers, size);
+
+return 0;
+}
+
+static int buffer_init(struct vb2_buffer *vb) {
+struct frame_buffer *buf = container_of(vb, struct frame_buffer,
+vb);
+
+buf-p_fb_desc = NULL;
+buf-fb_desc_phys = 0;
memset 0?
OK.
+INIT_LIST_HEAD(buf-list);
RE: [PATCH v2] [media] at91: add Atmel Image Sensor Interface (ISI) support
Hi, Arnd On Friday, May 27, 2011 9:50 PM, Arnd Bergmann wrote On Friday 27 May 2011, Josh Wu wrote: This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Signed-off-by: Josh Wu josh...@atmel.com Looks good to me now. Acked-by: Arnd Bergmann a...@arndb.de Thank you very much. I'll send a version 3 code. Best Regards, Josh Wu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Ok, this will be converted to use a common cafe code, but I'll comment
on this version anyway, for your future reference.
On Wed, 1 Jun 2011, Kassey Lee wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is supported.
Signed-off-by: Kassey Lee y...@marvell.com
---
arch/arm/mach-mmp/include/mach/camera.h | 37 ++
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile|1 +
drivers/media/video/mv_camera.c | 1067
+++
4 files changed, 1112 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mv_camera.c
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..ff8cde1
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+#define MV_CAMERA_MASTER 1
+#define MV_CAMERA_DATAWIDTH_8 8
+#define MV_CAMERA_DATAWIDTH_10 0x20
+#define MV_CAMERA_PCLK_EN 0x40
+#define MV_CAMERA_MCLK_EN 0x80
+#define MV_CAMERA_PCP 0x100
+#define MV_CAMERA_HSP 0x200
+#define MV_CAMERA_VSP 0x400
+
+struct mv_cam_pdata {
+ int dphy[3];
+ unsigned long flags;
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int (*init_clk) (struct device *dev, int init);
+ void (*enable_clk) (struct device *dev, int on);
+ int (*get_mclk_src) (int src);
+};
+
+#endif
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3be180b..18ab3a5 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -891,6 +891,13 @@ config VIDEO_MX3
---help---
This is a v4l2 driver for the i.MX3x Camera Sensor Interface
+config VIDEO_MV_CCIC
+ tristate Marvell CMOS Camera Interface Controller driver
+ depends on VIDEO_DEV CPU_PXA910 SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell CCIC Interface
+
config VIDEO_PXA27x
tristate PXA27x Quick Capture Interface driver
depends on VIDEO_DEV PXA27x SOC_CAMERA
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 9519160..e3251c3 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o
obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
+obj-$(CONFIG_VIDEO_MV_CCIC) += mv_camera.o
Ok, I still _think_, mv_camera is too generic a name for this driver,
but it's up to you, really, just my thought.
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c
new file mode 100644
index 000..f19c43d
--- /dev/null
+++ b/drivers/media/video/mv_camera.c
@@ -0,0 +1,1067 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC
+ * (CMOS Capture Interface Controller)
+ *
+ * Copyright (C) 2011, Marvell International Ltd.
+ * Kassey Lee y...@marvell.com
+ * Angela Wan j...@marvell.com
+ * Lei Wen lei...@marvell.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/dma-mapping.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/time.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+
+#include
[PATCH v3] [media] at91: add Atmel Image Sensor Interface (ISI) support
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Signed-off-by: Josh Wu josh...@atmel.com
---
base on branch staging/for_v3.0
Modified in V3:
refined the interrupt handling code.
added a list to manage the allocated descriptors.
removed redundant code in isi_camera_set_bus_param().
return error when platform data is not provided.
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile|1 +
drivers/media/video/atmel-isi.c | 1074 +++
include/media/atmel-isi.h | 119 +
4 files changed, 1202 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/atmel-isi.c
create mode 100644 include/media/atmel-isi.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bb53de7..93d1098 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -952,6 +952,14 @@ config VIDEO_SAMSUNG_S5P_FIMC
To compile this driver as a module, choose M here: the
module will be called s5p-fimc.
+config VIDEO_ATMEL_ISI
+ tristate ATMEL Image Sensor Interface (ISI) support
+ depends on VIDEO_DEV SOC_CAMERA ARCH_AT91
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This module makes the ATMEL Image Sensor Interface available
+ as a v4l2 device.
+
config VIDEO_S5P_MIPI_CSIS
tristate Samsung S5P and EXYNOS4 MIPI CSI receiver driver
depends on VIDEO_V4L2 PM_RUNTIME PLAT_S5P VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f0fecd6..d9833f4 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o
+obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
new file mode 100644
index 000..a020bd3
--- /dev/null
+++ b/drivers/media/video/atmel-isi.c
@@ -0,0 +1,1074 @@
+/*
+ * Copyright (c) 2011 Atmel Corporation
+ * Josh Wu, josh...@atmel.com
+ *
+ * Based on previous work by Lars Haring, lars.har...@atmel.com
+ * and Sedji Gaouaou
+ * Based on the bttv driver for Bt848 with respective copyright holders
+ *
+ * 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.
+ */
+
+#include linux/clk.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include media/atmel-isi.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/videobuf2-dma-contig.h
+
+#define MAX_BUFFER_NUM 32
+#define MAX_SUPPORT_WIDTH 2048
+#define MAX_SUPPORT_HEIGHT 2048
+#define VID_LIMIT_BYTES(16 * 1024 * 1024)
+#define MIN_FRAME_RATE 15
+#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+
+/* ISI states */
+enum {
+ ISI_STATE_IDLE = 0,
+ ISI_STATE_READY,
+ ISI_STATE_WAIT_SOF,
+};
+
+/* Frame buffer descriptor */
+struct fbd {
+ /* Physical address of the frame buffer */
+ u32 fb_address;
+ /* DMA Control Register(only in HISI2) */
+ u32 dma_ctrl;
+ /* Physical address of the next fbd */
+ u32 next_fbd_address;
+};
+
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl)
+{
+ fb_desc-dma_ctrl = ctrl;
+}
+
+struct isi_dma_desc {
+ struct list_head list;
+ struct fbd *p_fbd;
+ u32 fbd_phys;
+};
+
+/* Frame buffer data */
+struct frame_buffer {
+ struct vb2_buffer vb;
+ struct fbd *p_fb_desc;
+ u32 fb_desc_phys;
+ struct list_head list;
+};
+
+struct atmel_isi {
+ /* Protects the access of variables shared with the ISR */
+ spinlock_t lock;
+ void __iomem*regs;
+
+ int sequence;
+ /* State of the ISI module in capturing mode */
+ int state;
+
+ /* Wait queue for waiting for SOF */
+ wait_queue_head_t vsync_wq;
+
+ struct vb2_alloc_ctx*alloc_ctx;
+
+ /* Allocate descriptors for dma buffer use */
+ struct fbd *p_fb_descriptors;
+ u32 fb_descriptors_phys;
+ struct
Re: [linux-dvb] XC4000 patches for kernel 2.6.37.2
Em 02-06-2011 22:41, Dmitri Belimov escreveu: On Thu, 02 Jun 2011 11:41:53 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: One of our TV card has this tuner. It works in analog mode. I try get right firmware cleanup and test. Can I use git://linuxtv.org/mchehab/experimental.git branch xc4000 for do it? Sure. Feel free to use it. I'll be adding there the xc4000-related patches until they're ok for review. 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: Anchor Chips V4L2 driver
Em 03-06-2011 02:40, John McMaster escreveu: I'd like to write a driver for an Anchor Chips (seems to be bought by Cypress) USB camera Linux driver sold as an AmScope MD1800. It seems like this implies I need to write a V4L2 driver. The camera does not seem its currently supported (checked on Fedora 13 / 2.6.34.8) and I did not find any information on it in mailing list archives. Does anyone know or can help me identify if a similar camera might already be supported? I've no idea. Better to wait for a couple days for developers to manifest about that, if they're already working on it. lsusb gives the following output: Bus 001 Device 111: ID 0547:4d88 Anchor Chips, Inc. I've started reading the Video for Linux Two API Specification which seems like a good starting point and will move onto using source code as appropriate. Any help would be appreciated. Thanks! You'll find other useful information at linuxtv.org wiki page. The better is to write it as a sub-driver for gspca. The gspca core have already all that it is needed for cameras. So, you'll need to focus only at the device-specific stuff. Cheers, 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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
On 06/01/2011 08:18 PM, Bjørn Mork wrote:
Bjørn Morkbj...@mork.no writes:
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index 7904ca4..d994592 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -669,7 +669,8 @@ static int dvb_init(struct em28xx *dev)
em28xx_cxd2820r_config,dev-i2c_adap, NULL);
if (dvb-fe[0]) {
struct i2c_adapter *i2c_tuner;
- i2c_tuner = cxd2820r_get_tuner_i2c_adapter(dvb-fe[0]);
+ /* we don't really attach i2c_tuner. Just reusing the
symbol logic */
+ i2c_tuner = dvb_attach(cxd2820r_get_tuner_i2c_adapter,
dvb-fe[0]);
Except that this really messes up the reference count, and need to have
a matching symbol_put... So you should probably code it with
symbol_request()/symbol_put() if you want to go this way instead of
the dvb_attach shortcut .
There is some other FEs having also I2C adapter, I wonder how those
handle this situation. I looked example from cx24123 and s5h1420
drivers, both used by flexcop.
Did you see what is magic used those devices?
best 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 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: Em 25-05-2011 17:42, Antti Palosaari escreveu: Antti Palosaari (7): em28xx-dvb: add module param options and use it for LNA That patch is ugly, for several reasons: 1) we don't want a generic options parameter, whose meaning changes from device to devices; I agree it is not proper solution, but in my mind it is better to offer some solution than no solution at all. 2) what happens if someone has two em28xx devices plugged? It depends depends devices, currently only nanoStick T2 only looks that param, other just ignore. If there is two nanoStics then both have same LNA settings. That's just like same behaviour as for example remote controller polling. Or for example DiBcom driver LNA, since it does have similar module param already. Will you you commit it if I rename it similarly as DiBcom? 3) the better would be to detect if LNA is needed, or to add a DVBS2API call to enable/disable LNA. True, but it needs some research. There is many hardware which gets signal input from demod or tuner and makes some fine tune according to that. We need to define some new callbacks for demod and tuner in order to do this kind of actions. Or just add new LNA param to API use it manually. 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: [PATCH] FE_GET_PROPERTY should be _IOW, because the associated structure is transferred from userspace to kernelspace. Keep the old ioctl around for compatibility so that existing code is not brok
On 06/01/2011 11:15 PM, Mauro Carvalho Chehab wrote: The dvb_usercopy will do the right thing, if we use _IOR or _IORW. It only works, because _IOC_READ triggers a copy_from_user, as a workaround for wrongly marked ioctls like this, according to a code comment. It does not really do the right thing, because in this special case the later call to copy_to_user isn't required. But it doesn't do any real harm either. I prefer to not apply this patch, as it won't fix anything. Adding an _OLD means that we'll need later to remove it, causing a regression. Ok, we may do like we did with V4L _OLD ioctl's that were marked as _OLD at 2.6.5 and were removed on a late 2.6.3x. Either way is fine for me. Regards, Andreas -- 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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Antti Palosaari cr...@iki.fi writes: There is some other FEs having also I2C adapter, I wonder how those handle this situation. I looked example from cx24123 and s5h1420 drivers, both used by flexcop. Did you see what is magic used those devices? None. They have the same problem, creating hard module dependencies even if they use dvb_attach() and CONFIG_MEDIA_ATTACH is set: bjorn@canardo:~$ modinfo b2c2-flexcop filename: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/b2c2/b2c2-flexcop.ko license:GPL description:B2C2 FlexcopII/II(b)/III digital TV receiver chip author: Patrick Boettcher patrick.boettc...@desy.de depends:s5h1420,dvb-core,cx24113,cx24123,i2c-core vermagic: 2.6.32-5-amd64 SMP mod_unload modversions parm: debug:set debug level (1=info,2=tuner,4=i2c,8=ts,16=sram,32=reg (|-able)). (debugging is not enabled) (int) parm: adapter_nr:DVB adapter numbers (array of short) This probably means that a generic i2c_tuner wrapper, similar to dvb_attach, would be useful. Bjørn -- 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: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
On 06/03/2011 03:50 PM, Bjørn Mork wrote: Antti Palosaaricr...@iki.fi writes: There is some other FEs having also I2C adapter, I wonder how those handle this situation. I looked example from cx24123 and s5h1420 drivers, both used by flexcop. Did you see what is magic used those devices? None. They have the same problem, creating hard module dependencies even if they use dvb_attach() and CONFIG_MEDIA_ATTACH is set: bjorn@canardo:~$ modinfo b2c2-flexcop filename: /lib/modules/2.6.32-5-amd64/kernel/drivers/media/dvb/b2c2/b2c2-flexcop.ko license:GPL description:B2C2 FlexcopII/II(b)/III digital TV receiver chip author: Patrick Boettcherpatrick.boettc...@desy.de depends:s5h1420,dvb-core,cx24113,cx24123,i2c-core vermagic: 2.6.32-5-amd64 SMP mod_unload modversions parm: debug:set debug level (1=info,2=tuner,4=i2c,8=ts,16=sram,32=reg (|-able)). (debugging is not enabled) (int) parm: adapter_nr:DVB adapter numbers (array of short) This probably means that a generic i2c_tuner wrapper, similar to dvb_attach, would be useful. For the cxd2820r it is also possible to return I2C adapter as pointer from dvb_attach like pointer to FE0 is carried for FE1 dvb_attach. What you think about that? 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
Fwd: XC4000: code cleanup
Mensagem original
Assunto: XC4000: code cleanup
Data: Fri, 03 Jun 2011 12:02:15 +0200
De: istva...@mailbox.hu istva...@mailbox.hu
Para: Devin Heitmueller dheitmuel...@kernellabs.com
CC: Dmitri Belimov d.beli...@gmail.com,Mauro Carvalho Chehab
mche...@redhat.com, thunde...@email.cz,linux-...@linuxtv.org
This is the first of a set of patches that update the original xc4000
sources to my modified version. It removes some unused code, and makes
a few minor formatting changes.
Signed-off-by: Istvan Varga istva...@mailbox.hu
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-02 17:36:36.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 11:50:53.0 +0200
@@ -55,8 +55,6 @@
/* Note that the last version digit is my internal build number (so I can
rev the firmware even if the core Xceive firmware was unchanged) */
#define XC4000_DEFAULT_FIRMWARE dvb-fe-xc4000-1.4.1.fw
-#define XC4000_DEFAULT_FIRMWARE_SIZE 18643
-
/* struct for storing firmware table */
struct firmware_description {
@@ -80,18 +78,18 @@
struct tuner_i2c_props i2c_props;
struct list_head hybrid_tuner_instance_list;
struct firmware_description *firm;
- int firm_size;
- __u16 firm_version;
- u32 if_khz;
- u32 freq_hz;
- u32 bandwidth;
- u8 video_standard;
- u8 rf_mode;
-// struct xc2028_ctrl ctrl;
+ int firm_size;
+ __u16 firm_version;
+ u32 if_khz;
+ u32 freq_hz;
+ u32 bandwidth;
+ u8 video_standard;
+ u8 rf_mode;
+ u8 ignore_i2c_write_errors;
+ /* struct xc2028_ctrl ctrl; */
struct firmware_properties cur_fw;
- __u16 hwmodel;
- __u16 hwvers;
- u8 ignore_i2c_write_errors;
+ __u16 hwmodel;
+ __u16 hwvers;
};
/* Misc Defines */
@@ -167,12 +165,12 @@
For the RESET and WAIT commands, the two following bytes will contain
immediately the length of the following transaction.
-
*/
+
struct XC_TV_STANDARD {
- char *Name;
- u16 AudioMode;
- u16 VideoMode;
+ const char *Name;
+ u16 AudioMode;
+ u16 VideoMode;
};
/* Tuner standards */
@@ -200,33 +198,6 @@
#define XC4000_FM_Radio_INPUT2 21
#define XC4000_FM_Radio_INPUT1 22
-/* WAS :
-static struct XC_TV_STANDARD XC4000_Standard[MAX_TV_STANDARD] = {
- {M/N-NTSC/PAL-BTSC, 0x0400, 0x8020},
- {M/N-NTSC/PAL-A2, 0x0600, 0x8020},
- {M/N-NTSC/PAL-EIAJ, 0x0440, 0x8020},
- {M/N-NTSC/PAL-Mono, 0x0478, 0x8020},
- {B/G-PAL-A2,0x0A00, 0x8049},
- {B/G-PAL-NICAM, 0x0C04, 0x8049},
- {B/G-PAL-MONO, 0x0878, 0x8059},
- {I-PAL-NICAM, 0x1080, 0x8009},
- {I-PAL-NICAM-MONO, 0x0E78, 0x8009},
- {D/K-PAL-A2,0x1600, 0x8009},
- {D/K-PAL-NICAM, 0x0E80, 0x8009},
- {D/K-PAL-MONO, 0x1478, 0x8009},
- {D/K-SECAM-A2 DK1, 0x1200, 0x8009},
- {D/K-SECAM-A2 L/DK3, 0x0E00, 0x8009},
- {D/K-SECAM-A2 MONO, 0x1478, 0x8009},
- {L-SECAM-NICAM, 0x8E82, 0x0009},
- {L'-SECAM-NICAM,0x8E82, 0x4009},
- {DTV6, 0x00C0, 0x8002},
- {DTV8, 0x00C0, 0x800B},
- {DTV7/8,0x00C0, 0x801B},
- {DTV7, 0x00C0, 0x8007},
- {FM Radio-INPUT2, 0x9802, 0x9002},
- {FM Radio-INPUT1, 0x0208, 0x9002}
-};*/
-
static struct XC_TV_STANDARD XC4000_Standard[MAX_TV_STANDARD] = {
{M/N-NTSC/PAL-BTSC, 0x, 0x8020},
{M/N-NTSC/PAL-A2, 0x, 0x8020},
@@ -253,7 +224,6 @@
{FM Radio-INPUT1, 0x0008, 0x9000}
};
-static int xc4000_is_firmware_loaded(struct dvb_frontend *fe);
static int xc4000_readreg(struct xc4000_priv *priv, u16 reg, u16 *val);
static int xc4000_TunerReset(struct dvb_frontend *fe);
@@ -275,10 +245,6 @@
return XC_RESULT_SUCCESS;
}
-/* This routine is never used because the only time we read data from the
- i2c bus is when we read registers, and we want that to be an atomic i2c
- transaction in case we are on a multi-master bus */
-
static void xc_wait(int wait_ms)
{
msleep(wait_ms);
@@ -431,7 +397,6 @@
return xc_write_reg(priv, XREG_RF_FREQ, freq_code); /* WAS: XREG_FINERFREQ */
}
-
static int xc_get_ADC_Envelope(struct xc4000_priv *priv, u16 *adc_envelope)
{
return xc4000_readreg(priv, XREG_ADC_ENV, adc_envelope);
@@ -476,12 +441,6 @@
return 0;
}
-/* WAS THERE
-static int xc_get_buildversion(struct xc4000_priv *priv, u16 *buildrev)
-{
- return xc4000_readreg(priv, XREG_BUILD, buildrev);
-}*/
-
static int xc_get_hsync_freq(struct xc4000_priv *priv, u32 *hsync_freq_hz)
{
u16 regData;
@@ -520,12 +479,10 @@
return lockState;
}
-#define XC_TUNE_ANALOG 0
-#define XC_TUNE_DIGITAL 1
static int xc_tune_channel(struct xc4000_priv *priv, u32 freq_hz, int mode)
{
- int found = 0;
- int result = 0;
+ int found = 0;
+ int result = 0;
dprintk(1, %s(%u)\n, __func__, freq_hz);
@@ -694,7 +651,6 @@
if (best_nr_matches 0) {
printk(Selecting best matching firmware (%d bits) for
type=, best_nr_matches);
-// dump_firm_type(type);
printk((%x), id %016llx:\n, type, (unsigned long
Re: XC4000: added card_type
Em 03-06-2011 09:38, istva...@mailbox.hu escreveu:
This patch adds support for selecting a card type in struct
xc4000_config, to allow for implementing some card specific code
in the driver.
Hi Istvan,
Please send your patches to linux-media@vger.kernel.org. The linux-dvb
ML is obsolete. I didn't remove it from the server just to avoid loosing
the mail history.
With respect to this specific patch, as Devin pointed, the proper way is to
set the configurable data via the boards entries, and not inside xc4000.
So, feel free to send us patches to cx88 and other bridge drivers whose
boards require different configs, in order to work with xc4000.
Thanks,
Mauro
Signed-off-by: Istvan Varga istva...@mailbox.hu
xc4000_card_type.patch
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c
xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-03
11:54:19.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03
14:32:59.0 +0200
@@ -85,6 +85,7 @@
u32 bandwidth;
u8 video_standard;
u8 rf_mode;
+ u8 card_type;
u8 ignore_i2c_write_errors;
/* struct xc2028_ctrl ctrl; */
struct firmware_properties cur_fw;
@@ -1426,6 +1427,16 @@
int instance;
u16 id = 0;
+ if (cfg-card_type != XC4000_CARD_GENERIC) {
+ if (cfg-card_type == XC4000_CARD_WINFAST_CX88) {
+ cfg-i2c_address = 0x61;
+ cfg-if_khz = 4560;
+ } else {/* default to PCTV 340E */
+ cfg-i2c_address = 0x61;
+ cfg-if_khz = 5400;
+ }
+ }
+
dprintk(1, %s(%d-%04x)\n, __func__,
i2c ? i2c_adapter_id(i2c) : -1,
cfg ? cfg-i2c_address : -1);
@@ -1435,6 +1446,8 @@
instance = hybrid_tuner_request_state(struct xc4000_priv, priv,
hybrid_tuner_instance_list,
i2c, cfg-i2c_address, xc4000);
+ if (cfg-card_type != XC4000_CARD_GENERIC)
+ priv-card_type = cfg-card_type;
switch (instance) {
case 0:
goto fail;
@@ -1450,7 +1463,7 @@
break;
}
- if (priv-if_khz == 0) {
+ if (cfg-if_khz != 0) {
/* If the IF hasn't been set yet, use the value provided by
the caller (occurs in hybrid devices where the analog
call to xc4000_attach occurs before the digital side) */
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.h
xc4000/drivers/media/common/tuners/xc4000.h
--- xc4000_orig/drivers/media/common/tuners/xc4000.h 2011-06-03
11:54:19.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.h 2011-06-03
14:29:32.0 +0200
@@ -27,8 +27,13 @@
struct dvb_frontend;
struct i2c_adapter;
+#define XC4000_CARD_GENERIC 0
+#define XC4000_CARD_PCTV_340E1
+#define XC4000_CARD_WINFAST_CX88 2
+
struct xc4000_config {
- u8 i2c_address;
+ u8 card_type; /* if card type is not generic, all other */
+ u8 i2c_address;/* parameters are automatically set */
u32 if_khz;
};
--
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
Fwd: XC4000: code cleanup
Mensagem original
Assunto: XC4000: code cleanup
Data: Fri, 03 Jun 2011 12:02:15 +0200
De: istva...@mailbox.hu istva...@mailbox.hu
Para: Devin Heitmueller dheitmuel...@kernellabs.com
CC: Dmitri Belimov d.beli...@gmail.com,Mauro Carvalho Chehab
mche...@redhat.com, thunde...@email.cz,linux-...@linuxtv.org
This is the first of a set of patches that update the original xc4000
sources to my modified version. It removes some unused code, and makes
a few minor formatting changes.
Signed-off-by: Istvan Varga istva...@mailbox.hu
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-02 17:36:36.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 11:50:53.0 +0200
@@ -55,8 +55,6 @@
/* Note that the last version digit is my internal build number (so I can
rev the firmware even if the core Xceive firmware was unchanged) */
#define XC4000_DEFAULT_FIRMWARE dvb-fe-xc4000-1.4.1.fw
-#define XC4000_DEFAULT_FIRMWARE_SIZE 18643
-
/* struct for storing firmware table */
struct firmware_description {
@@ -80,18 +78,18 @@
struct tuner_i2c_props i2c_props;
struct list_head hybrid_tuner_instance_list;
struct firmware_description *firm;
- int firm_size;
- __u16 firm_version;
- u32 if_khz;
- u32 freq_hz;
- u32 bandwidth;
- u8 video_standard;
- u8 rf_mode;
-// struct xc2028_ctrl ctrl;
+ int firm_size;
+ __u16 firm_version;
+ u32 if_khz;
+ u32 freq_hz;
+ u32 bandwidth;
+ u8 video_standard;
+ u8 rf_mode;
+ u8 ignore_i2c_write_errors;
+ /* struct xc2028_ctrl ctrl; */
struct firmware_properties cur_fw;
- __u16 hwmodel;
- __u16 hwvers;
- u8 ignore_i2c_write_errors;
+ __u16 hwmodel;
+ __u16 hwvers;
};
/* Misc Defines */
@@ -167,12 +165,12 @@
For the RESET and WAIT commands, the two following bytes will contain
immediately the length of the following transaction.
-
*/
+
struct XC_TV_STANDARD {
- char *Name;
- u16 AudioMode;
- u16 VideoMode;
+ const char *Name;
+ u16 AudioMode;
+ u16 VideoMode;
};
/* Tuner standards */
@@ -200,33 +198,6 @@
#define XC4000_FM_Radio_INPUT2 21
#define XC4000_FM_Radio_INPUT1 22
-/* WAS :
-static struct XC_TV_STANDARD XC4000_Standard[MAX_TV_STANDARD] = {
- {M/N-NTSC/PAL-BTSC, 0x0400, 0x8020},
- {M/N-NTSC/PAL-A2, 0x0600, 0x8020},
- {M/N-NTSC/PAL-EIAJ, 0x0440, 0x8020},
- {M/N-NTSC/PAL-Mono, 0x0478, 0x8020},
- {B/G-PAL-A2,0x0A00, 0x8049},
- {B/G-PAL-NICAM, 0x0C04, 0x8049},
- {B/G-PAL-MONO, 0x0878, 0x8059},
- {I-PAL-NICAM, 0x1080, 0x8009},
- {I-PAL-NICAM-MONO, 0x0E78, 0x8009},
- {D/K-PAL-A2,0x1600, 0x8009},
- {D/K-PAL-NICAM, 0x0E80, 0x8009},
- {D/K-PAL-MONO, 0x1478, 0x8009},
- {D/K-SECAM-A2 DK1, 0x1200, 0x8009},
- {D/K-SECAM-A2 L/DK3, 0x0E00, 0x8009},
- {D/K-SECAM-A2 MONO, 0x1478, 0x8009},
- {L-SECAM-NICAM, 0x8E82, 0x0009},
- {L'-SECAM-NICAM,0x8E82, 0x4009},
- {DTV6, 0x00C0, 0x8002},
- {DTV8, 0x00C0, 0x800B},
- {DTV7/8,0x00C0, 0x801B},
- {DTV7, 0x00C0, 0x8007},
- {FM Radio-INPUT2, 0x9802, 0x9002},
- {FM Radio-INPUT1, 0x0208, 0x9002}
-};*/
-
static struct XC_TV_STANDARD XC4000_Standard[MAX_TV_STANDARD] = {
{M/N-NTSC/PAL-BTSC, 0x, 0x8020},
{M/N-NTSC/PAL-A2, 0x, 0x8020},
@@ -253,7 +224,6 @@
{FM Radio-INPUT1, 0x0008, 0x9000}
};
-static int xc4000_is_firmware_loaded(struct dvb_frontend *fe);
static int xc4000_readreg(struct xc4000_priv *priv, u16 reg, u16 *val);
static int xc4000_TunerReset(struct dvb_frontend *fe);
@@ -275,10 +245,6 @@
return XC_RESULT_SUCCESS;
}
-/* This routine is never used because the only time we read data from the
- i2c bus is when we read registers, and we want that to be an atomic i2c
- transaction in case we are on a multi-master bus */
-
static void xc_wait(int wait_ms)
{
msleep(wait_ms);
@@ -431,7 +397,6 @@
return xc_write_reg(priv, XREG_RF_FREQ, freq_code); /* WAS: XREG_FINERFREQ */
}
-
static int xc_get_ADC_Envelope(struct xc4000_priv *priv, u16 *adc_envelope)
{
return xc4000_readreg(priv, XREG_ADC_ENV, adc_envelope);
@@ -476,12 +441,6 @@
return 0;
}
-/* WAS THERE
-static int xc_get_buildversion(struct xc4000_priv *priv, u16 *buildrev)
-{
- return xc4000_readreg(priv, XREG_BUILD, buildrev);
-}*/
-
static int xc_get_hsync_freq(struct xc4000_priv *priv, u32 *hsync_freq_hz)
{
u16 regData;
@@ -520,12 +479,10 @@
return lockState;
}
-#define XC_TUNE_ANALOG 0
-#define XC_TUNE_DIGITAL 1
static int xc_tune_channel(struct xc4000_priv *priv, u32 freq_hz, int mode)
{
- int found = 0;
- int result = 0;
+ int found = 0;
+ int result = 0;
dprintk(1, %s(%u)\n, __func__, freq_hz);
@@ -694,7 +651,6 @@
if (best_nr_matches 0) {
printk(Selecting best matching firmware (%d bits) for
type=, best_nr_matches);
-// dump_firm_type(type);
printk((%x), id %016llx:\n, type, (unsigned long
Re: [bug-report] unconditionally calling cxd2820r_get_tuner_i2c_adapter() from em28xx-dvb.c creates a hard module dependency
Antti Palosaari cr...@iki.fi writes: On 06/03/2011 03:50 PM, Bjørn Mork wrote: This probably means that a generic i2c_tuner wrapper, similar to dvb_attach, would be useful. For the cxd2820r it is also possible to return I2C adapter as pointer from dvb_attach like pointer to FE0 is carried for FE1 dvb_attach. What you think about that? I don't feel competent to answer that at all. It does seem like overloading an existing interface, but it might be OK. I just grepped a bit around for EXPORT_SYMBOL of anything except foo_attach, and found that there are a few frontend drivers which exports multiple symbols: bjorn@canardo:/usr/local/src/git/linux-2.6$ grep EXPORT_SYMBOL drivers/media/dvb/frontends/*.c|grep -v _attach drivers/media/dvb/frontends/cx24113.c:EXPORT_SYMBOL(cx24113_agc_callback); drivers/media/dvb/frontends/cx24123.c:EXPORT_SYMBOL(cx24123_get_tuner_i2c_adapter); drivers/media/dvb/frontends/cxd2820r_core.c:EXPORT_SYMBOL(cxd2820r_get_tuner_i2c_adapter); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_ctrl_agc_filter); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_get_rf_output); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_set_rf_output); drivers/media/dvb/frontends/dib0070.c:EXPORT_SYMBOL(dib0070_wbd_offset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_dcc_freq); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_pwm_gain_reset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_gain_control); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_current_gain); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_wbd_offset); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_get_tune_state); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_set_tune_state); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_register); drivers/media/dvb/frontends/dib0090.c:EXPORT_SYMBOL(dib0090_fw_register); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_get_tuner_i2c_master); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_pid_control); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_pid_parse); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_set_config); drivers/media/dvb/frontends/dib3000mc.c:EXPORT_SYMBOL(dib3000mc_i2c_enumeration); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_get_i2c_master); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_pid_filter_ctrl); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_pid_filter); drivers/media/dvb/frontends/dib7000m.c:EXPORT_SYMBOL(dib7000m_i2c_enumeration); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_set_wbd_ref); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_update_pll); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_set_gpio); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_ctrl_timf); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000pc_detection); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_get_i2c_master); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_pid_filter_ctrl); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_pid_filter); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7000p_i2c_enumeration); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_get_i2c_tuner); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_tuner_sleep); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_agc_restart); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_get_adc_power); drivers/media/dvb/frontends/dib7000p.c:EXPORT_SYMBOL(dib7090_slave_reset); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_wbd_ref); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_gpio); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pwm_agc_reset); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_adc_power); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_tune_state); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_tune_state); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_set_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_remove_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_slave_frontend); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_i2c_enumeration); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_get_i2c_master); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pid_filter_ctrl); drivers/media/dvb/frontends/dib8000.c:EXPORT_SYMBOL(dib8000_pid_filter); drivers/media/dvb/frontends/dib9000.c:EXPORT_SYMBOL(dib9000_fw_set_component_bus_speed); drivers/media/dvb/frontends/dib9000.c:EXPORT_SYMBOL(dib9000_get_tuner_interface);
Re: [GIT PULL FOR 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Antti Palosaari cr...@iki.fi writes: On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: Em 25-05-2011 17:42, Antti Palosaari escreveu: Antti Palosaari (7): em28xx-dvb: add module param options and use it for LNA That patch is ugly, for several reasons: 1) we don't want a generic options parameter, whose meaning changes from device to devices; I agree it is not proper solution, but in my mind it is better to offer some solution than no solution at all. 2) what happens if someone has two em28xx devices plugged? It depends depends devices, currently only nanoStick T2 only looks that param, other just ignore. If there is two nanoStics then both have same LNA settings. That's just like same behaviour as for example remote controller polling. Or for example DiBcom driver LNA, since it does have similar module param already. Will you you commit it if I rename it similarly as DiBcom? 3) the better would be to detect if LNA is needed, or to add a DVBS2API call to enable/disable LNA. True, but it needs some research. There is many hardware which gets signal input from demod or tuner and makes some fine tune according to that. We need to define some new callbacks for demod and tuner in order to do this kind of actions. Or just add new LNA param to API use it manually. Or option 4) just enable the LNA unconditionally. I did some testing in my environment, and I was unable to tune anything on either DVB-T or DVB-C without the LNA enabled. I'm of course aware that this depends on your signal, but have you actually seen a real life signal where tuning fails with the LNA enabled and works without it? I do believe that my DVB-C signal at least is pretty strong. Bjørn -- 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 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Here in the UK the mux strengths and parameters are all over the place. I have had situations in the past (with dib0700 I think) where I've had to twiddle the force_lna setting one way or the other depending on how they've decided to reconfigure my local transmitter. So I'd be cautious about flat-out enabling it the whole time. -- Steve Kerrison MEng Hons. http://www.stevekerrison.com/ On Fri, 2011-06-03 at 15:29 +0200, Bjørn Mork wrote: Antti Palosaari cr...@iki.fi writes: On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: Em 25-05-2011 17:42, Antti Palosaari escreveu: Antti Palosaari (7): em28xx-dvb: add module param options and use it for LNA That patch is ugly, for several reasons: 1) we don't want a generic options parameter, whose meaning changes from device to devices; I agree it is not proper solution, but in my mind it is better to offer some solution than no solution at all. 2) what happens if someone has two em28xx devices plugged? It depends depends devices, currently only nanoStick T2 only looks that param, other just ignore. If there is two nanoStics then both have same LNA settings. That's just like same behaviour as for example remote controller polling. Or for example DiBcom driver LNA, since it does have similar module param already. Will you you commit it if I rename it similarly as DiBcom? 3) the better would be to detect if LNA is needed, or to add a DVBS2API call to enable/disable LNA. True, but it needs some research. There is many hardware which gets signal input from demod or tuner and makes some fine tune according to that. We need to define some new callbacks for demod and tuner in order to do this kind of actions. Or just add new LNA param to API use it manually. Or option 4) just enable the LNA unconditionally. I did some testing in my environment, and I was unable to tune anything on either DVB-T or DVB-C without the LNA enabled. I'm of course aware that this depends on your signal, but have you actually seen a real life signal where tuning fails with the LNA enabled and works without it? I do believe that my DVB-C signal at least is pretty strong. Bjørn -- 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
TM5600 based tuner not working
Hi All, I had bought a USB 2.0 laptop TV tuner card (as mentioned on the device). It has a TM5600 chip with following written on it. TVMASTER TM5600 B HCCO2 D49KK 1 0923 2013F0F906F071003 Downloaded the v4l code and compiled on Ubuntu 2.6.32-25-generic. Loaded the drivers in following order. insmod v4l1-compat.ko insmod videodev.ko insmod v4l2-common.ko insmod videobuf-core.ko insmod videobuf-vmalloc.ko insmod tm6000.ko insmod tea5761.ko insmod mt20xx.ko insmod tda9887.ko insmod videodev.ko insmod tea5767.ko insmod xc5000.ko insmod tuner-xc2028.ko insmod tda8290.ko insmod tuner-types.ko insmod tuner-simple.ko insmod tuner.ko Kernel was able to detect the card with a usb id of (0x6000, 0x0001) tried to load the firmware which seems to succeed. === LOG BEGIN === kernel: [ 5125.600265] usb 2-1: new high speed USB device using ehci_hcd and address 9 kernel: [ 5125.742106] usb 2-1: configuration #1 chosen from 1 choice kernel: [ 5125.745661] tm6000: alt 0, interface 0, class 255 kernel: [ 5125.745669] tm6000: alt 0, interface 0, class 255 kernel: [ 5125.745675] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes) kernel: [ 5125.745681] tm6000: alt 1, interface 0, class 255 kernel: [ 5125.745686] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes) kernel: [ 5125.745692] tm6000: alt 1, interface 0, class 255 kernel: [ 5125.745698] tm6000: alt 2, interface 0, class 255 kernel: [ 5125.745703] tm6000: alt 2, interface 0, class 255 kernel: [ 5125.745709] tm6000: New video device @ 480 Mbps (6000:0001, ifnum 0) kernel: [ 5125.745714] tm6000: Found 10Moons UT 821 kernel: [ 5126.524188] Board version = 0x67980cf3 kernel: [ 5126.724163] tm6000 #5: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5127.012071] tm6000 #5: i2c eeprom 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5127.300225] tm6000 #5: i2c eeprom 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5127.588227] tm6000 #5: i2c eeprom 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5127.876192] tm6000 #5: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5128.164118] tm6000 #5: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5128.456206] tm6000 #5: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5128.744170] tm6000 #5: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5129.032200] tm6000 #5: i2c eeprom 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5129.320109] tm6000 #5: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5129.604091] tm6000 #5: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5129.892102] tm6000 #5: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5130.181833] tm6000 #5: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5130.468116] tm6000 #5: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5130.764229] tm6000 #5: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5131.053186] tm6000 #5: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 kernel: [ 5131.320180] kernel: [ 5131.323658] tuner 5-0061: chip found @ 0xc2 (tm6000 #5) kernel: [ 5131.323675] xc2028 5-0061: creating new instance kernel: [ 5131.323682] xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner kernel: [ 5131.323687] Setting firmware parameters for xc2028 kernel: [ 5131.323700] usb 2-1: firmware: requesting xc3028-v24.fw kernel: [ 5131.328769] xc2028 5-0061: Loading 77 firmware images from xc3028-v24.fw, type: xc2028 firmware, ver 2.4 kernel: [ 5131.432183] xc2028 5-0061: Loading firmware for type=BASE (1), id . kernel: [ 5165.608114] xc2028 5-0061: Loading firmware for type=(0), id b700. kernel: [ 5166.868179] SCODE (2000), id b700: kernel: [ 5166.868194] xc2028 5-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. kernel: [ 5167.328194] xc2028 5-0061: Loading firmware for type=BASE (1), id . kernel: [ 5201.500190] xc2028 5-0061: Loading firmware for type=(0), id b700. kernel: [ 5202.761170] SCODE (2000), id b700: kernel: [ 5202.761186] xc2028 5-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320 (60008000), id 8000. kernel: [ 5203.564193] xc2028 5-0061: Loading firmware for type=BASE (1), id . kernel: [ 5237.764133] xc2028 5-0061: Loading firmware for type=(0), id b700. kernel: [ 5239.028085] SCODE (2000), id b700: kernel: [ 5239.028101] xc2028 5-0061: Loading SCODE for
Re: Fwd: XC4000: code cleanup
Em 03-06-2011 10:11, Mauro Carvalho Chehab escreveu: Mensagem original Assunto: XC4000: code cleanup Data: Fri, 03 Jun 2011 12:02:15 +0200 De: istva...@mailbox.hu istva...@mailbox.hu Para: Devin Heitmueller dheitmuel...@kernellabs.com CC: Dmitri Belimov d.beli...@gmail.com,Mauro Carvalho Chehab mche...@redhat.com, thunde...@email.cz,linux-...@linuxtv.org This is the first of a set of patches that update the original xc4000 sources to my modified version. It removes some unused code, and makes a few minor formatting changes. Signed-off-by: Istvan Varga istva...@mailbox.hu Patch applied at: git://linuxtv.org/git/mchehab/experimental.git xc4000 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] FE_GET_PROPERTY should be _IOW, because the associated structure is transferred from userspace to kernelspace. Keep the old ioctl around for compatibility so that existing code is not brok
Em 03-06-2011 09:44, Andreas Oberritter escreveu: On 06/01/2011 11:15 PM, Mauro Carvalho Chehab wrote: The dvb_usercopy will do the right thing, if we use _IOR or _IORW. It only works, because _IOC_READ triggers a copy_from_user, as a workaround for wrongly marked ioctls like this, according to a code comment. It does not really do the right thing, because in this special case the later call to copy_to_user isn't required. But it doesn't do any real harm either. Yes, that's what I meant to say ;) The workaround for it is there already, so maybe there are other ioctl's using the wrong _IOC_ directions. As I said before, some ioctl's don't use _IOC_ directions, like for example the tty ioctls like TIO* ones. This happens on several very old drivers. So, ioctl core don't make any assumption about them. it is up to each driver (or subsystem core) to handle it. I prefer to not apply this patch, as it won't fix anything. Adding an _OLD means that we'll need later to remove it, causing a regression. Ok, we may do like we did with V4L _OLD ioctl's that were marked as _OLD at 2.6.5 and were removed on a late 2.6.3x. Either way is fine for me. I'm not against fixing it, but, in this case, we'll need to validate all DVB ioctl's and remove the IOC_READ hack for all non-_OLD controls, and writing a notice at features-to-be-removed announcing that the _OLD controls will be removed. Cheers, Mauro. Regards, Andreas -- 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: XC4000: added card_type
Em 03-06-2011 10:16, istva...@mailbox.hu escreveu: On 06/03/2011 02:46 PM, Devin Heitmueller wrote: I understand what you're trying to do here, but this is not a good approach. We do not want to be littering tuner drivers with card-specific if() statements. Also, this is inconsistent with the way all other tuner drivers work. The approach you are attempting may seem easier at first, but it gets very difficult to manage over time as the number of boards that use the driver increases. You should have the bridge driver be setting up the cfg structure and passing it to the xc4000 driver, just like the xc5000 and xc3028 do. Well, for now, I just create patches that reproduce all the changes I have made to the driver. Of course, these may not always be the best or most elegant possible solutions, and I expect many will not be accepted, or further changes/cleanup will be needed later. I do not think the number of boards that use this tuner is likely to increase much in the future, though, since the XC4000 seems to be a discontinued product (at least it no longer appears anywhere on the Xceive web site). While the xc4000 is not merged upstream, we may have such hack, but before merging, this issue should be solved. However, it seems better to just do the right thing since the beginning: just add a patch for cx88 adding the xc4000 boards there and filling the config stuff inside cx88 driver. Cheers, 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 2.6.40] PCTV nanoStick T2 290e (Sony CXD2820R DVB-T/T2/C)
Em 03-06-2011 09:34, Antti Palosaari escreveu: On 06/01/2011 04:27 PM, Mauro Carvalho Chehab wrote: Em 25-05-2011 17:42, Antti Palosaari escreveu: Antti Palosaari (7): em28xx-dvb: add module param options and use it for LNA That patch is ugly, for several reasons: 1) we don't want a generic options parameter, whose meaning changes from device to devices; I agree it is not proper solution, but in my mind it is better to offer some solution than no solution at all. 2) what happens if someone has two em28xx devices plugged? It depends depends devices, currently only nanoStick T2 only looks that param, other just ignore. If there is two nanoStics then both have same LNA settings. That's just like same behaviour as for example remote controller polling. Or for example DiBcom driver LNA, since it does have similar module param already. Will you you commit it if I rename it similarly as DiBcom? 3) the better would be to detect if LNA is needed, or to add a DVBS2API call to enable/disable LNA. True, but it needs some research. There is many hardware which gets signal input from demod or tuner and makes some fine tune according to that. We need to define some new callbacks for demod and tuner in order to do this kind of actions. Or just add new LNA param to API use it manually. I would then just add a LNA option via DVBS2API to allow enabling/disabling it. (LNA enabled seems to be the better default). Modprobe parameters for things like that sucks. Cheers, 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: XC4000: added card_type
On 06/03/2011 04:00 PM, Mauro Carvalho Chehab wrote: While the xc4000 is not merged upstream, we may have such hack, but before merging, this issue should be solved. However, it seems better to just do the right thing since the beginning: just add a patch for cx88 adding the xc4000 boards there and filling the config stuff inside cx88 driver. I do intend to remove the card_type code later, and only send cx88 patches once the interface is cleaned up. It is only included for now to have a working code without conflicting patches, and I do not know exactly what the config structure should eventually contain, that is, some of the current board-specific 'if' statements may actually turn out to be unnecessary and can be made the same for all cards. -- 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
XC4000: updated standards table
This patch makes the following changes to the standards table:
- added 'u16 int_freq' to struct XC_TV_STANDARD (needed for analog TV
and radio, 0 for DVB-T)
- added new standard for SECAM-D/K video with PAL-D/K audio
- the 'int_freq' values are now specified in the table
- changed VideoMode for NTSC and PAL-B/G standards
Signed-off-by: Istvan Varga istva...@mailbox.hu
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-03 14:33:40.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 15:41:55.0 +0200
@@ -94,7 +94,7 @@
};
/* Misc Defines */
-#define MAX_TV_STANDARD 23
+#define MAX_TV_STANDARD 24
#define XC_MAX_I2C_WRITE_LENGTH 64
/* Signal Types */
@@ -172,6 +172,7 @@
const char *Name;
u16 AudioMode;
u16 VideoMode;
+ u16 int_freq;
};
/* Tuner standards */
@@ -190,39 +191,41 @@
#define XC4000_DK_SECAM_A2DK1 12
#define XC4000_DK_SECAM_A2LDK3 13
#define XC4000_DK_SECAM_A2MONO 14
-#define XC4000_L_SECAM_NICAM 15
-#define XC4000_LC_SECAM_NICAM 16
-#define XC4000_DTV6 17
-#define XC4000_DTV8 18
-#define XC4000_DTV7_8 19
-#define XC4000_DTV7 20
-#define XC4000_FM_Radio_INPUT2 21
-#define XC4000_FM_Radio_INPUT1 22
+#define XC4000_DK_SECAM_NICAM 15
+#define XC4000_L_SECAM_NICAM 16
+#define XC4000_LC_SECAM_NICAM 17
+#define XC4000_DTV6 18
+#define XC4000_DTV8 19
+#define XC4000_DTV7_8 20
+#define XC4000_DTV7 21
+#define XC4000_FM_Radio_INPUT2 22
+#define XC4000_FM_Radio_INPUT1 23
static struct XC_TV_STANDARD XC4000_Standard[MAX_TV_STANDARD] = {
- {M/N-NTSC/PAL-BTSC, 0x, 0x8020},
- {M/N-NTSC/PAL-A2, 0x, 0x8020},
- {M/N-NTSC/PAL-EIAJ, 0x0040, 0x8020},
- {M/N-NTSC/PAL-Mono, 0x0078, 0x8020},
- {B/G-PAL-A2,0x, 0x8059},
- {B/G-PAL-NICAM, 0x0004, 0x8059},
- {B/G-PAL-MONO, 0x0078, 0x8059},
- {I-PAL-NICAM, 0x0080, 0x8049},
- {I-PAL-NICAM-MONO, 0x0078, 0x8049},
- {D/K-PAL-A2,0x, 0x8049},
- {D/K-PAL-NICAM, 0x0080, 0x8049},
- {D/K-PAL-MONO, 0x0078, 0x8049},
- {D/K-SECAM-A2 DK1, 0x, 0x8049},
- {D/K-SECAM-A2 L/DK3, 0x, 0x8049},
- {D/K-SECAM-A2 MONO, 0x0078, 0x8049},
- {L-SECAM-NICAM, 0x8080, 0x0009},
- {L'-SECAM-NICAM,0x8080, 0x4009},
- {DTV6, 0x00C0, 0x8002},
- {DTV8, 0x00C0, 0x800B},
- {DTV7/8,0x00C0, 0x801B},
- {DTV7, 0x00C0, 0x8007},
- {FM Radio-INPUT2, 0x0008, 0x9800},
- {FM Radio-INPUT1, 0x0008, 0x9000}
+ {M/N-NTSC/PAL-BTSC, 0x, 0x80A0, 4500},
+ {M/N-NTSC/PAL-A2, 0x, 0x80A0, 4600},
+ {M/N-NTSC/PAL-EIAJ, 0x0040, 0x80A0, 4500},
+ {M/N-NTSC/PAL-Mono, 0x0078, 0x80A0, 4500},
+ {B/G-PAL-A2, 0x, 0x8159, 5640},
+ {B/G-PAL-NICAM, 0x0004, 0x8159, 5740},
+ {B/G-PAL-MONO, 0x0078, 0x8159, 5500},
+ {I-PAL-NICAM, 0x0080, 0x8049, 6240},
+ {I-PAL-NICAM-MONO, 0x0078, 0x8049, 6000},
+ {D/K-PAL-A2, 0x, 0x8049, 6380},
+ {D/K-PAL-NICAM, 0x0080, 0x8049, 6200},
+ {D/K-PAL-MONO, 0x0078, 0x8049, 6500},
+ {D/K-SECAM-A2 DK1, 0x, 0x8049, 6340},
+ {D/K-SECAM-A2 L/DK3, 0x, 0x8049, 6000},
+ {D/K-SECAM-A2 MONO, 0x0078, 0x8049, 6500},
+ {D/K-SECAM-NICAM, 0x0080, 0x8049, 6200},
+ {L-SECAM-NICAM, 0x8080, 0x0009, 6200},
+ {L'-SECAM-NICAM, 0x8080, 0x4009, 6200},
+ {DTV6, 0x00C0, 0x8002,0},
+ {DTV8, 0x00C0, 0x800B,0},
+ {DTV7/8, 0x00C0, 0x801B,0},
+ {DTV7, 0x00C0, 0x8007,0},
+ {FM Radio-INPUT2, 0x0008, 0x9800,10700},
+ {FM Radio-INPUT1, 0x0008, 0x9000,10700}
};
static int xc4000_readreg(struct xc4000_priv *priv, u16 reg, u16 *val);
Re: [PATCH v3] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Fri, 3 Jun 2011, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Signed-off-by: Josh Wu josh...@atmel.com
---
base on branch staging/for_v3.0
Modified in V3:
refined the interrupt handling code.
added a list to manage the allocated descriptors.
removed redundant code in isi_camera_set_bus_param().
return error when platform data is not provided.
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile|1 +
drivers/media/video/atmel-isi.c | 1074
+++
include/media/atmel-isi.h | 119 +
4 files changed, 1202 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/atmel-isi.c
create mode 100644 include/media/atmel-isi.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bb53de7..93d1098 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -952,6 +952,14 @@ config VIDEO_SAMSUNG_S5P_FIMC
To compile this driver as a module, choose M here: the
module will be called s5p-fimc.
+config VIDEO_ATMEL_ISI
+ tristate ATMEL Image Sensor Interface (ISI) support
+ depends on VIDEO_DEV SOC_CAMERA ARCH_AT91
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This module makes the ATMEL Image Sensor Interface available
+ as a v4l2 device.
+
config VIDEO_S5P_MIPI_CSIS
tristate Samsung S5P and EXYNOS4 MIPI CSI receiver driver
depends on VIDEO_V4L2 PM_RUNTIME PLAT_S5P VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f0fecd6..d9833f4 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_PXA27x)+= pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o
obj-$(CONFIG_VIDEO_OMAP1)+= omap1_camera.o
+obj-$(CONFIG_VIDEO_ATMEL_ISI)+= atmel-isi.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
new file mode 100644
index 000..a020bd3
--- /dev/null
+++ b/drivers/media/video/atmel-isi.c
@@ -0,0 +1,1074 @@
+/*
+ * Copyright (c) 2011 Atmel Corporation
+ * Josh Wu, josh...@atmel.com
+ *
+ * Based on previous work by Lars Haring, lars.har...@atmel.com
+ * and Sedji Gaouaou
+ * Based on the bttv driver for Bt848 with respective copyright holders
+ *
+ * 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.
+ */
+
+#include linux/clk.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#include media/atmel-isi.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/videobuf2-dma-contig.h
+
+#define MAX_BUFFER_NUM 32
+#define MAX_SUPPORT_WIDTH2048
+#define MAX_SUPPORT_HEIGHT 2048
+#define VID_LIMIT_BYTES (16 * 1024 * 1024)
+#define MIN_FRAME_RATE 15
+#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
+
+/* ISI states */
+enum {
+ ISI_STATE_IDLE = 0,
+ ISI_STATE_READY,
+ ISI_STATE_WAIT_SOF,
+};
+
+/* Frame buffer descriptor */
+struct fbd {
+ /* Physical address of the frame buffer */
+ u32 fb_address;
+ /* DMA Control Register(only in HISI2) */
+ u32 dma_ctrl;
+ /* Physical address of the next fbd */
+ u32 next_fbd_address;
+};
+
+static void set_dma_ctrl(struct fbd *fb_desc, u32 ctrl)
+{
+ fb_desc-dma_ctrl = ctrl;
+}
+
+struct isi_dma_desc {
+ struct list_head list;
+ struct fbd *p_fbd;
+ u32 fbd_phys;
+};
+
+/* Frame buffer data */
+struct frame_buffer {
+ struct vb2_buffer vb;
+ struct fbd *p_fb_desc;
+ u32 fb_desc_phys;
Why don't you replace the above two members with struct isi_dma_desc *?
Then you also don't need to scan the DMA descriptor array in
.buf_cleanup().
+ struct list_head list;
+};
+
+struct atmel_isi {
+ /* Protects the access of variables shared with the ISR */
+ spinlock_t lock;
+ void __iomem*regs;
+
+ int sequence;
+ /* State of the ISI module in capturing mode */
+ int state;
+
+ /* Wait queue for waiting for SOF */
+ wait_queue_head_t
XC4000: added support for 7 MHz DVB-T
The following patch implements support for DVB-T with 7 MHz bandwidth.
Signed-off-by: Istvan Varga istva...@mailbox.hu
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-03 15:47:04.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 16:34:25.0 +0200
@@ -1183,15 +1183,28 @@
type = DTV6;
break;
case BANDWIDTH_7_MHZ:
- printk(KERN_ERR xc4000 bandwidth 7MHz not supported\n);
+ priv-bandwidth = BANDWIDTH_7_MHZ;
+ priv-video_standard = XC4000_DTV7;
+ priv-freq_hz = params-frequency - 225;
type = DTV7;
- return -EINVAL;
+ break;
case BANDWIDTH_8_MHZ:
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = XC4000_DTV8;
priv-freq_hz = params-frequency - 275;
type = DTV8;
break;
+ case BANDWIDTH_AUTO:
+ if (params-frequency 4) {
+priv-bandwidth = BANDWIDTH_7_MHZ;
+priv-freq_hz = params-frequency - 225;
+ } else {
+priv-bandwidth = BANDWIDTH_8_MHZ;
+priv-freq_hz = params-frequency - 275;
+ }
+ priv-video_standard = XC4000_DTV7_8;
+ type = DTV78;
+ break;
default:
printk(KERN_ERR xc4000 bandwidth not set!\n);
return -EINVAL;
XC4000: added mutex
This patch adds a mutex to xc4000_priv, to protect the driver
from being accessed by multiple processes at the same time.
Signed-off-by: Istvan Varga istva...@mailbox.hu
diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c
--- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-03 16:35:23.0 +0200
+++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 17:02:59.0 +0200
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/dvb/frontend.h
#include linux/i2c.h
+#include linux/mutex.h
#include asm/unaligned.h
#include dvb_frontend.h
@@ -91,6 +92,7 @@
struct firmware_properties cur_fw;
__u16 hwmodel;
__u16 hwvers;
+ struct mutex lock;
};
/* Misc Defines */
@@ -1144,10 +1146,12 @@
{
struct xc4000_priv *priv = fe-tuner_priv;
unsigned int type;
- int ret;
+ int ret = -EREMOTEIO;
dprintk(1, %s() frequency=%d (Hz)\n, __func__, params-frequency);
+ mutex_lock(priv-lock);
+
if (fe-ops.info.type == FE_ATSC) {
dprintk(1, %s() ATSC\n, __func__);
switch (params-u.vsb.modulation) {
@@ -1171,7 +1175,8 @@
type = DTV6;
break;
default:
- return -EINVAL;
+ ret = -EINVAL;
+ goto fail;
}
} else if (fe-ops.info.type == FE_OFDM) {
dprintk(1, %s() OFDM\n, __func__);
@@ -1207,28 +1212,29 @@
break;
default:
printk(KERN_ERR xc4000 bandwidth not set!\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto fail;
}
priv-rf_mode = XC_RF_MODE_AIR;
} else {
printk(KERN_ERR xc4000 modulation type not supported!\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto fail;
}
dprintk(1, %s() frequency=%d (compensated)\n,
__func__, priv-freq_hz);
/* Make sure the correct firmware type is loaded */
- if (check_firmware(fe, type, 0, priv-if_khz) != XC_RESULT_SUCCESS) {
- return -EREMOTEIO;
- }
+ if (check_firmware(fe, type, 0, priv-if_khz) != XC_RESULT_SUCCESS)
+ goto fail;
ret = xc_SetSignalSource(priv, priv-rf_mode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR
- xc4000: xc_SetSignalSource(%d) failed\n,
- priv-rf_mode);
- return -EREMOTEIO;
+ xc4000: xc_SetSignalSource(%d) failed\n,
+ priv-rf_mode);
+ goto fail;
}
ret = xc_SetTVStandard(priv,
@@ -1236,33 +1242,32 @@
XC4000_Standard[priv-video_standard].AudioMode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR xc4000: xc_SetTVStandard failed\n);
- return -EREMOTEIO;
- }
-#ifdef DJH_DEBUG
- ret = xc_set_IF_frequency(priv, priv-if_khz);
- if (ret != XC_RESULT_SUCCESS) {
- printk(KERN_ERR xc4000: xc_Set_IF_frequency(%d) failed\n,
- priv-if_khz);
- return -EIO;
+ goto fail;
}
-#endif
xc_tune_channel(priv, priv-freq_hz, XC_TUNE_DIGITAL);
if (debug)
xc_debug_dump(priv);
- return 0;
+ ret = 0;
+
+fail:
+ mutex_unlock(priv-lock);
+
+ return ret;
}
static int xc4000_set_analog_params(struct dvb_frontend *fe,
struct analog_parameters *params)
{
struct xc4000_priv *priv = fe-tuner_priv;
- int ret;
+ int ret = -EREMOTEIO;
dprintk(1, %s() frequency=%d (in units of 62.5khz)\n,
__func__, params-frequency);
+ mutex_lock(priv-lock);
+
/* Fix me: it could be air. */
priv-rf_mode = params-mode;
if (params-mode XC_RF_MODE_CABLE)
@@ -1317,16 +1322,15 @@
tune_channel:
/* FIXME - firmware type not being set properly */
- if (check_firmware(fe, DTV8, 0, priv-if_khz) != XC_RESULT_SUCCESS) {
- return -EREMOTEIO;
- }
+ if (check_firmware(fe, DTV8, 0, priv-if_khz) != XC_RESULT_SUCCESS)
+ goto fail;
ret = xc_SetSignalSource(priv, priv-rf_mode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR
- xc4000: xc_SetSignalSource(%d) failed\n,
- priv-rf_mode);
- return -EREMOTEIO;
+ xc4000: xc_SetSignalSource(%d) failed\n,
+ priv-rf_mode);
+ goto fail;
}
ret = xc_SetTVStandard(priv,
@@ -1334,7 +1338,7 @@
XC4000_Standard[priv-video_standard].AudioMode);
if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR xc4000: xc_SetTVStandard failed\n);
- return -EREMOTEIO;
+ goto fail;
}
xc_tune_channel(priv, priv-freq_hz, XC_TUNE_ANALOG);
@@ -1342,7 +1346,12 @@
if (debug)
xc_debug_dump(priv);
- return 0;
+ ret = 0;
+
+fail:
+ mutex_unlock(priv-lock);
+
+ return ret;
}
static int xc4000_get_frequency(struct dvb_frontend *fe, u32 *freq)
@@ -1367,8 +1376,12 @@
struct xc4000_priv *priv = fe-tuner_priv;
u16 lock_status = 0;
+ mutex_lock(priv-lock);
+
xc_get_lock_status(priv, lock_status);
+ mutex_unlock(priv-lock);
+
dprintk(1, %s() lock_status = 0x%08x\n, __func__, lock_status);
*status = lock_status;
@@ -1385,9 +1398,13 @@
static int xc4000_init(struct dvb_frontend *fe)
{
struct xc4000_priv *priv = fe-tuner_priv;
+ int ret;
dprintk(1, %s()\n, __func__);
- if (check_firmware(fe, DTV8, 0, priv-if_khz) != XC_RESULT_SUCCESS) {
+ mutex_lock(priv-lock);
+ ret = check_firmware(fe, DTV8, 0, priv-if_khz);
+ mutex_unlock(priv-lock);
+ if (ret != XC_RESULT_SUCCESS) {
printk(KERN_ERR xc4000: Unable to
XC4000: fixed frequency error
The xc_get_frequency_error() function reported the frequency error incorrectly. The data read from the hardware is a signed integer, in 15625 Hz units. The attached patch fixes the bug. Signed-off-by: Istvan Varga istva...@mailbox.hu diff -uNr xc4000_orig/drivers/media/common/tuners/xc4000.c xc4000/drivers/media/common/tuners/xc4000.c --- xc4000_orig/drivers/media/common/tuners/xc4000.c 2011-06-03 17:09:54.0 +0200 +++ xc4000/drivers/media/common/tuners/xc4000.c 2011-06-03 17:14:12.0 +0200 @@ -418,8 +418,9 @@ if (result != XC_RESULT_SUCCESS) return result; - tmp = (u32)regData; - (*freq_error_hz) = (tmp * 15625) / 1000; + tmp = (u32)regData 0xU; + tmp = (tmp 0x8000U ? tmp : 0x1U - tmp); + (*freq_error_hz) = tmp * 15625; return result; }
Re: [PATCH] [media] V4L/videobuf2-memops: use pr_debug for debug messages
Em 03-06-2011 04:39, Uwe Kleine-König escreveu:
Hello Mauro,
On Wed, Jun 01, 2011 at 10:34:31PM -0300, Mauro Carvalho Chehab wrote:
Hi Kyungmin,
Em 01-06-2011 21:50, Kyungmin Park escreveu:
Acked-by: Kyungmin Park kyunginn.,p...@samsung.com
As this patch is really trivial and makes sense, I've just applied it earlier
today.
You somehow screwed up my name in the Author field more than I'm used
to:
$ git cat-file commit 215c52702775556f4caf5872cc84fa8810e6fc7d | grep Uwe
author Uwe Kleine-König u.kleine-koe...@pengutronix.de 1306959562
-0300
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Strange enough my name in the commitlog looks fine.
You should thank Python for that. We use patchwork to retrieve patches. It is
written
in Python. Python seems to have serious troubles handling anything that it is
not pure
ASCII. In the past, a non-north-american name in Patchwork would be simply
discarded,
as python used to abort patchwork. Lots of locale-fix patches later trying to
address
this issue and now, it sometimes do the right thing.
If you care to fix it, you can easily do so using git filter-branch.
E.g.:
$ git filter-branch --env-filter 'test x$GIT_COMMIT !=
x215c52702775556f4caf5872cc84fa8810e6fc7d || { GIT_AUTHOR_NAME=Uwe
Kleine-König; export GIT_AUTHOR_NAME; }' ^215c5270277^ HEAD
(Assuming an UTF-8 locale.)
This converts 215c527 to a commit c6cbbfc that has my name fixed and
rebases all following commits on top of this. In your master branch this
only affects 00c4526 (Merge /home/v4l/v4l/for_upstream)
This breaks merge.
$ git push
To /home/v4l/bare_trees/v4l-dvb.git/
! [rejected]staging/for_v3.0 - staging/for_v3.0 (non-fast-forward)
Fortunately, as the patches on this branch are meant to go to v3.1,
I just renamed the branch to staging/for_v3.1, keeping the wrong patch
at the old branch. This way, the need of rebasing was avoided.
Best regards and thanks
Uwe
--
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 0/6] iommu: generic api migration and grouping
On Friday 03 June 2011, Ohad Ben-Cohen wrote: First stab at iommu consolidation: Hi Ohad, Great to see your progress here! - Migrate OMAP's iommu driver to the generic iommu API. With this in hand, users can now start using the generic iommu layer instead of calling omap-specific iommu API. New code that requires functionality missing from the generic iommu api, will add that functionality in the generic framework (e.g. adding framework awareness to multi page sizes, supported by the underlying hardware, will avoid the otherwise-inevitable code duplication when mapping a memory region). OMAP-specific api that is still exposed in the omap iommu driver can now be either moved to the generic iommu framework, or just removed (if not used). This api (and other omap-specific primitives like struct iommu) needs to be omapified (i.e. renamed to include an 'omap_' prefix). At this early point of this patch set this is too much churn though, so I'll do that in the following iteration, after (and if), the general direction is accepted. Sounds all good. - Migrate OMAP's iovmm (virtual memory manager) driver to the generic iommu API. With this in hand, iovmm no longer uses omap-specific api for mapping/unmapping operations. Nevertheless, iovmm is still coupled with omap's iommu even with this change: it assumes omap page sizes, and it uses omap's iommu objects to maintain its internal state. Further generalizing of iovmm strongly depends on our broader plans for providing a generic virtual memory manager and allocation framework (which, as discussed, should be separated from a specific mapper). iovmm has a mainline user: omap3isp, and therefore must be maintained, but new potential users will either have to generalize it, or come up with a different generic framework that will replace it. I think the future of iovmm is looking not so good. Marek Szyprowski is working on a generic version of the dma-mapping API (dma_map_ops) based on the iommu API. As far as I can tell, once we have that in place, we you can migrate omap3isp from iovmm to dma-mapping and remove iovmm. Of course if there are things missing from the dma-mapping API that are present in iovmm, we should know about them so that we can extend the dma-mapping API accordingly. - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well (so it doesn't break). As with iovmm, omap3isp still depends on omap's iommu, mainly because iovmm depends on it, but also for iommu context saving and restoring. It is definitely desirable to completely remove omap3isp's dependency on the omap-specific iommu layer, and that will be possible as the required functionality will be added to generic framework. ok. - Create a dedicated iommu drivers folder (and put the base iommu code there) - Move OMAP's and MSM's iommu drivers to that drivers iommu folder Putting all iommu drivers together will ease finding similarities between different platforms, with the intention of solving problems once, in a generic framework which everyone can use. I've only moved the omap and msm implementations for now, to demonstrate the idea (and support the ARM diet :), but if this is found desirable, we can bring in intel-iommu.c and amd_iommu.c as well. Yes, very good idea. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
since kernel 2.6.39.1 : kernel: dib0700: tx buffer length is larger than 4. Not supported
I get that message with the new kernel for this card : 2011-06-03T17:29:43.861+02:00 n22 kernel: usb 1-1: new high speed USB device number 10 using ehci_hcd 2011-06-03T17:29:43.975+02:00 n22 kernel: usb 1-1: New USB device found, idVendor=0ccd, idProduct=00ab 2011-06-03T17:29:43.975+02:00 n22 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2011-06-03T17:29:43.975+02:00 n22 kernel: usb 1-1: Product: Cinergy T XXS 2011-06-03T17:29:43.975+02:00 n22 kernel: usb 1-1: Manufacturer: TerraTec GmbH 2011-06-03T17:29:43.975+02:00 n22 kernel: usb 1-1: SerialNumber: 01 2011-06-03T17:29:43.975+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in cold state, will try to load a firmware 2011-06-03T17:29:44.028+02:00 n22 kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' 2011-06-03T17:29:44.230+02:00 n22 kernel: dib0700: firmware started successfully. 2011-06-03T17:29:44.731+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in warm state. 2011-06-03T17:29:44.731+02:00 n22 kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. 2011-06-03T17:29:44.731+02:00 n22 kernel: DVB: registering new adapter (Terratec Cinergy T USB XXS (HD)/ T3) 2011-06-03T17:29:44.922+02:00 n22 kernel: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... 2011-06-03T17:29:45.121+02:00 n22 kernel: DiB0070: successfully identified 2011-06-03T17:29:45.121+02:00 n22 kernel: Registered IR keymap rc-dib0700-rc5 2011-06-03T17:29:45.122+02:00 n22 kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc2/input16 2011-06-03T17:29:45.122+02:00 n22 kernel: rc2: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc2 2011-06-03T17:29:45.122+02:00 n22 kernel: dvb-usb: schedule remote query interval to 50 msecs. 2011-06-03T17:29:45.122+02:00 n22 kernel: dvb-usb: Terratec Cinergy T USB XXS (HD)/ T3 successfully initialized and connected. 2011-06-03T17:29:53.878+02:00 n22 kernel: dib0700: tx buffer length is larger than 4. Not supported. and wonders whether this is harmless or harmfull ... TIA -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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: AverMedia A306 (cx23385, xc3028, af9013) (A577 too ?)
On Thu, 2011-05-19 at 23:13 +0200, wal...@free.fr wrote: I've tried to use my A306 board on my system. All the main chips are fully supported by linux. I have the A307 (product ID 0xc939) and I'd like to coordinate with you regarding adapting your A306 support for it. If you use IRC at all, just tell me when to be in #linuxtv, and if not, we'll keep this on-list. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/media: fix uninitialized variable
mx1_camera_add_device() can return an
uninitialized value of ret.
Signed-off-by: Andre Bartke andre.bar...@gmail.com
---
drivers/media/video/mx1_camera.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index bc0c23a..d9fc4b2 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -444,7 +444,7 @@ static int mx1_camera_add_device(struct soc_camera_device
*icd)
{
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct mx1_camera_dev *pcdev = ici-priv;
- int ret;
+ int ret = 0;
if (pcdev-icd) {
ret = -EBUSY;
--
1.7.5.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] drivers/media/video: fix memory leak of snd_cx18_init()
cxsc is not freed in the error case. Signed-off-by: Andre Bartke andre.bar...@gmail.com --- drivers/media/video/cx18/cx18-alsa-main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/cx18/cx18-alsa-main.c b/drivers/media/video/cx18/cx18-alsa-main.c index d50d69d..a1e6c2a 100644 --- a/drivers/media/video/cx18/cx18-alsa-main.c +++ b/drivers/media/video/cx18/cx18-alsa-main.c @@ -192,6 +192,7 @@ static int snd_cx18_init(struct v4l2_device *v4l2_dev) err_exit_free: if (sc != NULL) snd_card_free(sc); + kfree(cxsc); err_exit: return ret; } -- 1.7.5.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] drivers/media: fix uninitialized variable
On Fri, 3 Jun 2011, Andre Bartke wrote:
mx1_camera_add_device() can return an
uninitialized value of ret.
Signed-off-by: Andre Bartke andre.bar...@gmail.com
Thanks, will push to 3.0
Guennadi
---
drivers/media/video/mx1_camera.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c
b/drivers/media/video/mx1_camera.c
index bc0c23a..d9fc4b2 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -444,7 +444,7 @@ static int mx1_camera_add_device(struct soc_camera_device
*icd)
{
struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
struct mx1_camera_dev *pcdev = ici-priv;
- int ret;
+ int ret = 0;
if (pcdev-icd) {
ret = -EBUSY;
--
1.7.5.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
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jun 3 19:00:36 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The mailing list linux-dvb@linuxtv is closed. use linux-media@vger.kernel.org instead
subscribe linux-media -- 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] V4L/videobuf2-memops: use pr_debug for debug messages
Hello Mauro,
On Fri, Jun 03, 2011 at 12:39:52PM -0300, Mauro Carvalho Chehab wrote:
Em 03-06-2011 04:39, Uwe Kleine-König escreveu:
Hello Mauro,
On Wed, Jun 01, 2011 at 10:34:31PM -0300, Mauro Carvalho Chehab wrote:
Hi Kyungmin,
Em 01-06-2011 21:50, Kyungmin Park escreveu:
Acked-by: Kyungmin Park kyunginn.,p...@samsung.com
As this patch is really trivial and makes sense, I've just applied it
earlier
today.
You somehow screwed up my name in the Author field more than I'm used
to:
$ git cat-file commit 215c52702775556f4caf5872cc84fa8810e6fc7d | grep Uwe
author Uwe Kleine-König u.kleine-koe...@pengutronix.de 1306959562
-0300
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Strange enough my name in the commitlog looks fine.
You should thank Python for that. We use patchwork to retrieve patches. It is
written
in Python. Python seems to have serious troubles handling anything that it is
not pure
ASCII. In the past, a non-north-american name in Patchwork would be simply
discarded,
as python used to abort patchwork. Lots of locale-fix patches later trying to
address
this issue and now, it sometimes do the right thing.
I added Jeremy Kerr to Cc:, maybe he is interested to look into that.
If you care to fix it, you can easily do so using git filter-branch.
E.g.:
$ git filter-branch --env-filter 'test x$GIT_COMMIT !=
x215c52702775556f4caf5872cc84fa8810e6fc7d || { GIT_AUTHOR_NAME=Uwe
Kleine-König; export GIT_AUTHOR_NAME; }' ^215c5270277^ HEAD
(Assuming an UTF-8 locale.)
This converts 215c527 to a commit c6cbbfc that has my name fixed and
rebases all following commits on top of this. In your master branch this
only affects 00c4526 (Merge /home/v4l/v4l/for_upstream)
This breaks merge.
$ git push
To /home/v4l/bare_trees/v4l-dvb.git/
! [rejected]staging/for_v3.0 - staging/for_v3.0 (non-fast-forward)
Fortunately, as the patches on this branch are meant to go to v3.1,
I just renamed the branch to staging/for_v3.1, keeping the wrong patch
at the old branch. This way, the need of rebasing was avoided.
I don't get what you mean here. Which merge is broken? Just in case you
didn't know, git push -f should be able to overwrite the remote branch,
with all the downside that brings that with it.
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] V4L/videobuf2-memops: use pr_debug for debug messages
Em 03-06-2011 16:50, Uwe Kleine-König escreveu: Fortunately, as the patches on this branch are meant to go to v3.1, I just renamed the branch to staging/for_v3.1, keeping the wrong patch at the old branch. This way, the need of rebasing was avoided. I don't get what you mean here. Which merge is broken? Just in case you didn't know, git push -f should be able to overwrite the remote branch, with all the downside that brings that with it. A git push -f will cause troubles on all clones of the media tree. Cheers, 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: The mailing list linux-dvb@linuxtv is closed. use linux-media@vger.kernel.org instead
Em 03-06-2011 16:03, Stefan-W. Hahn escreveu: subscribe linux-media Hi Stefan, In order to subscribe, you should send the subscribe message to: majord...@vger.kernel.org Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] rc-core support for Microsoft IR keyboard/mouse
This is a custom IR protocol decoder, for the RC-6-ish protocol used by the Microsoft Remote Keyboard. http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8 Its a standard keyboard with embedded thumb stick mouse pointer and mouse buttons, along with a number of media keys. The media keys are standard RC-6, identical to the signals from the stock MCE remotes, and will be handled as such. The keyboard and mouse signals will be decoded and delivered to the system by an input device registered specifically by this driver. Successfully tested with an mceusb-driven receiver, but this should actually work with any raw IR rc-core receiver. This work is inspired by lirc_mod_mce: http://mod-mce.sourceforge.net/ The documentation there and code aided in understanding and decoding the protocol, but the bulk of the code is actually borrowed more from the existing in-kernel decoders than anything. I did recycle the keyboard keycode table and a few defines from lirc_mod_mce though. Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/ir-mce_kbd-decoder.c | 383 + drivers/media/rc/ir-raw.c |1 + drivers/media/rc/rc-core-priv.h | 17 ++ drivers/media/rc/rc-main.c|1 + include/media/rc-map.h|3 +- 7 files changed, 416 insertions(+), 1 deletions(-) create mode 100644 drivers/media/rc/ir-mce_kbd-decoder.c diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 7d4bbc2..899f783 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -87,6 +87,17 @@ config IR_RC5_SZ_DECODER uses an IR protocol that is almost standard RC-5, but not quite, as it uses an additional bit). +config IR_MCE_KBD_DECODER + tristate Enable IR raw decoder for the MCE keyboard/mouse protocol + depends on RC_CORE + select BITREVERSE + default y + + ---help--- + Enable this option if you have a Microsoft Remote Keyboard for + Windows Media Center Edition, which you would like to use with + a raw IR receiver in your system. + config IR_LIRC_CODEC tristate Enable IR to LIRC bridge depends on RC_CORE diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile index 52830e5..f224db0 100644 --- a/drivers/media/rc/Makefile +++ b/drivers/media/rc/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o obj-$(CONFIG_IR_RC5_SZ_DECODER) += ir-rc5-sz-decoder.o +obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o # stand-alone IR receivers/transmitters diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c b/drivers/media/rc/ir-mce_kbd-decoder.c new file mode 100644 index 000..98d3bf5 --- /dev/null +++ b/drivers/media/rc/ir-mce_kbd-decoder.c @@ -0,0 +1,383 @@ +/* ir-mce_kbd-decoder.c - A decoder for the RC6-ish keyboard/mouse IR protocol + * used by the Microsoft Remote Keyboard for Windows Media Center Edition + * + * Copyright (C) 2011 by Jarod Wilson ja...@redhat.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation version 2 of the License. + * + * 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. + */ + +#include rc-core-priv.h + +/* + * This decoder currently supports: + * - RC6-like 29-bit IR signals used for mouse movement and buttons + * - RC6-like 32-bit IR signals used for standard keyboard keys + * + * The media keys on the keyboard send RC-6 signals that are inditinguishable + * from the keys of the same name on the stock MCE remote, and will be handled + * by the standard RC-6 decoder, and be made available to the system via the + * input device for the remote, rather than the keyboard/mouse one. + */ + +#define MCE_KBD_UNIT 33 /* ns */ +#define MCE_KBD_HEADER_NBITS 5 +#define MCE_KBD_MOUSE_NBITS29 +#define MCE_KBD_KEYBOARD_NBITS 32 +#define MCE_KBD_PREFIX_PULSE (8 * MCE_KBD_UNIT) +#define MCE_KBD_PREFIX_SPACE (1 * MCE_KBD_UNIT) +#define MCE_KBD_MAX_LEN(3 * MCE_KBD_UNIT) +#define MCE_KBD_BIT_START (1 * MCE_KBD_UNIT) +#define MCE_KBD_BIT_END(1 * MCE_KBD_UNIT) +#define MCE_KBD_BIT_0 (1 * MCE_KBD_UNIT) +#define MCE_KBD_BIT_SET(2 * MCE_KBD_UNIT) +#define MCE_KBD_MODE_MASK 0xf /* for the header bits */ +#define MCE_KBD_HEADER 0x4 +#define MCE_MOUSE_HEADER 0x1 +#define
Re: [RFCv2 PATCH 00/11] Control Event
Hi Hans, Thanks for the patch set. On Wednesday 25 May 2011 15:33:44 Hans Verkuil wrote: This is the second version of the patch series introducing a new event that is triggered when a control's value or state changes. One general comment. The API lets applications subscribe to events for individual controls. Should we also have an API to subscribe to events for all controls ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 09/11] vivi: support control events.
Hi Hans,
Thanks for the patch.
On Wednesday 25 May 2011 15:33:53 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/vivi.c | 161
++- 1 files changed, 97
insertions(+), 64 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 21d8f6a..93692ad 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -32,6 +32,7 @@
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-fh.h
+#include media/v4l2-event.h
#include media/v4l2-common.h
#define VIVI_MODULE_NAME vivi
@@ -157,54 +158,6 @@ struct vivi_dmaqueue {
static LIST_HEAD(vivi_devlist);
-struct vivi_dev {
- struct list_head vivi_devlist;
- struct v4l2_device v4l2_dev;
- struct v4l2_ctrl_handler ctrl_handler;
-
- /* controls */
- struct v4l2_ctrl *brightness;
- struct v4l2_ctrl *contrast;
- struct v4l2_ctrl *saturation;
- struct v4l2_ctrl *hue;
What's the reason for removing the brigthness, contrast, saturation and huer
controls from the vivi_dev structure ? You then need to call v4l2_ctrl_find()
several times per frame.
- struct v4l2_ctrl *volume;
- struct v4l2_ctrl *button;
- struct v4l2_ctrl *boolean;
- struct v4l2_ctrl *int32;
- struct v4l2_ctrl *int64;
- struct v4l2_ctrl *menu;
- struct v4l2_ctrl *string;
- struct v4l2_ctrl *bitmask;
-
- spinlock_t slock;
- struct mutex mutex;
-
- /* various device info */
- struct video_device*vfd;
-
- struct vivi_dmaqueue vidq;
-
- /* Several counters */
- unsigned ms;
- unsigned long jiffies;
- unsigned button_pressed;
-
- intmv_count;/* Controls bars movement */
-
- /* Input Number */
- intinput;
-
- /* video capture */
- struct vivi_fmt*fmt;
- unsigned int width, height;
- struct vb2_queue vb_vidq;
- enum v4l2_fieldfield;
- unsigned int field_count;
-
- u8 bars[9][3];
- u8 line[MAX_WIDTH * 4];
-};
-
/* --
DMA and thread functions
--*/
@@ -257,6 +210,50 @@ static struct bar_std bars[] = {
#define NUM_INPUTS ARRAY_SIZE(bars)
+struct vivi_dev {
+ struct list_head vivi_devlist;
+ struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
+
+ /* controls */
+ struct v4l2_ctrl *volume;
+ struct v4l2_ctrl *button;
+ struct v4l2_ctrl *boolean;
+ struct v4l2_ctrl *int32;
+ struct v4l2_ctrl *int64;
+ struct v4l2_ctrl *menu;
+ struct v4l2_ctrl *string;
+ struct v4l2_ctrl *bitmask;
+
+ spinlock_t slock;
+ struct mutex mutex;
+
+ /* various device info */
+ struct video_device*vfd;
+
+ struct vivi_dmaqueue vidq;
+
+ /* Several counters */
+ unsigned ms;
+ unsigned long jiffies;
+ unsigned button_pressed;
+
+ intmv_count;/* Controls bars movement */
+
+ /* Input Number */
+ intinput;
+
+ /* video capture */
+ struct vivi_fmt*fmt;
+ unsigned int width, height;
+ struct vb2_queue vb_vidq;
+ enum v4l2_fieldfield;
+ unsigned int field_count;
+
+ u8 bars[9][3];
+ u8 line[MAX_WIDTH * 4];
+};
+
#define TO_Y(r, g, b) \
(((16829 * r + 33039 * g + 6416 * b + 32768) 16) + 16)
/* RGB to V(Cr) Color transform */
@@ -451,6 +448,14 @@ static void gen_text(struct vivi_dev *dev, char
*basep,
static void vivi_fillbuff(struct vivi_dev *dev, struct vivi_buffer *buf)
{
+ struct v4l2_ctrl *brightness = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_BRIGHTNESS);
+ struct v4l2_ctrl *contrast = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_CONTRAST);
+ struct v4l2_ctrl *saturation = v4l2_ctrl_find(dev-ctrl_handler,
+ V4L2_CID_SATURATION);
+ struct v4l2_ctrl *hue =
Re: [RFCv2 PATCH 04/11] v4l2-ctrls: Replace v4l2_ctrl_activate/grab with v4l2_ctrl_flags.
Hi Hans, Thanks for the patch. On Wednesday 25 May 2011 15:33:48 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com This more generic function makes it possible to have a single function that takes care of flags handling, in particular with regards to sending a control event when the flags change. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- [snip] +/** v4l2_ctrl_flags_lock() - Clear and set flags for a control. + * @ctrl: The control whose flags should be changed. + * @clear_flags:Mask out these flags. + * @set_flags: Set these flags. * - * This sets or clears the V4L2_CTRL_FLAG_GRABBED flag atomically. - * Does nothing if @ctrl == NULL. - * This will usually be called when starting or stopping streaming in the - * driver. + * This clears and sets flags. Does nothing if @ctrl == NULL. * - * This function can be called regardless of whether the control handler - * is locked or not. + * This function expects that the control handler is unlocked and will lock + * it before changing flags. */ -void v4l2_ctrl_grab(struct v4l2_ctrl *ctrl, bool grabbed); +void v4l2_ctrl_flags_lock(struct v4l2_ctrl *ctrl, u32 clear_flags, u32 set_flags); The v4l2_ctrl_flags_lock() function doesn't seem to be used. Do we need it ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 05/11] v4l2-ctrls: add v4l2_fh pointer to the set control functions.
Hi Hans, Thanks for the patch. On Wednesday 25 May 2011 15:33:49 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com When an application changes a control you want to generate an event. However, you want to avoid sending such an event back to the application (file handle) that caused the change. Add the filehandle to the various set control functions. To implement per-file handle controls, the get/try functions will need the file handle as well. Should this patch handle that, or do you want to postpone it until a driver uses per-file handle controls ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 08/11] v4l2-ctrls: simplify event subscription.
Hi Hans,
Thanks for the patch.
On Wednesday 25 May 2011 15:33:52 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 31 +++
include/media/v4l2-ctrls.h | 25 +
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c
b/drivers/media/video/v4l2-ctrls.c index e2a7ac7..9807a20 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -831,6 +831,22 @@ int v4l2_ctrl_handler_init(struct v4l2_ctrl_handler
*hdl, }
EXPORT_SYMBOL(v4l2_ctrl_handler_init);
+/* Count the number of controls */
+unsigned v4l2_ctrl_handler_cnt(struct v4l2_ctrl_handler *hdl)
+{
+ struct v4l2_ctrl_ref *ref;
+ unsigned cnt = 0;
+
+ if (hdl == NULL)
+ return 0;
+ mutex_lock(hdl-lock);
+ list_for_each_entry(ref, hdl-ctrl_refs, node)
+ cnt++;
As you don't use the entry, you can replace list_for_each_entry with
list_for_each.
Should the handler keep a controls count ? In that case you wouldn't need this
function.
+ mutex_unlock(hdl-lock);
+ return cnt;
+}
+EXPORT_SYMBOL(v4l2_ctrl_handler_cnt);
+
/* Free all controls and control refs */
void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
{
@@ -1999,3 +2015,18 @@ void v4l2_ctrl_del_fh(struct v4l2_ctrl *ctrl, struct
v4l2_fh *fh) v4l2_ctrl_unlock(ctrl);
}
EXPORT_SYMBOL(v4l2_ctrl_del_fh);
+
+int v4l2_ctrl_sub_fh(struct v4l2_fh *fh, struct v4l2_event_subscription
*sub, +unsigned n)
I would rename this to v4l2_ctrl_subscribe_fh(). I had trouble understanding
what v4l2_ctrl_sub_fh() before reading the documentation. sub makes me think
about sub-devices and subtract, not subscription.
+{
+ int ret = 0;
+
+ if (!fh-events)
+ ret = v4l2_event_init(fh);
+ if (!ret)
+ ret = v4l2_event_alloc(fh, n);
+ if (!ret)
+ ret = v4l2_event_subscribe(fh, sub);
I tend to return errors when they occur instead of continuing to the end of
the function. Handling errors on the spot makes code easier to read in my
opinion, as I expect the main code flow to be the error-free path.
+ return ret;
+}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
