Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
On Tuesday 13 January 2009 03:03:34 Aguirre Rodriguez, Sergio Alberto wrote:
> Signed-off-by: Sakari Ailus
> Signed-off-by: Sergio Aguirre
> ---
> drivers/media/video/Kconfig |8 +
> drivers/media/video/Makefile |2 +
> drivers/media/video/omap34xxcam.c | 2017
> +
> drivers/media/video/omap34xxcam.h | 215
> 4 files changed, 2242 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/omap34xxcam.c
> create mode 100644 drivers/media/video/omap34xxcam.h
>
...
> +/**
> + * vidioc_default - private IOCTL handler
> + * @file: ptr. to system file structure
> + * @fh: ptr to hold address of omap34xxcam_fh struct (per-filehandle
> data) + * @cmd: ioctl cmd value
> + * @arg: ioctl arg value
> + *
> + * If the sensor being used is a "smart sensor", this request is
> returned to + * caller with -EINVAL err code. Otherwise if the
> control id is the private + * VIDIOC_PRIVATE_ISP_AEWB_REQ to update
> the analog gain or exposure, + * then this request is forwared
> directly to the sensor to incorporate the + * feedback. The request
> is then passed on to the ISP private IOCTL handler, + *
> isp_handle_private()
> + */
> +static int vidioc_default(struct file *file, void *fh, int cmd, void
> *arg) +{
> + struct omap34xxcam_fh *ofh = file->private_data;
> + struct omap34xxcam_videodev *vdev = ofh->vdev;
> + int rval;
> +
> + if (vdev->vdev_sensor_config.sensor_isp) {
> + rval = -EINVAL;
> + } else {
> + switch (cmd) {
> + case VIDIOC_ENUM_FRAMESIZES:
> + rval = vidioc_enum_framesizes(file, fh, arg);
> + goto out;
> + case VIDIOC_ENUM_FRAMEINTERVALS:
> + rval = vidioc_enum_frameintervals(file, fh,
> arg); + goto out;
These two have proper v4l2_ioctl_ops entries, so there is no need to handle
them in vidioc_default.
> + case VIDIOC_PRIVATE_ISP_AEWB_REQ:
> + {
> + /* Need to update sensor first */
> + struct isph3a_aewb_data *data;
> + struct v4l2_control vc;
> +
> + data = (struct isph3a_aewb_data *) arg;
> + if (data->update & SET_EXPOSURE) {
> + vc.id = V4L2_CID_EXPOSURE;
> + vc.value = data->shutter;
> + mutex_lock(&vdev->mutex);
> + rval =
> vidioc_int_s_ctrl(vdev->vdev_sensor, +
> &vc); +
> mutex_unlock(&vdev->mutex);
> + if (rval)
> + goto out;
> + }
> + if (data->update & SET_ANALOG_GAIN) {
> + vc.id = V4L2_CID_GAIN;
> + vc.value = data->gain;
> + mutex_lock(&vdev->mutex);
> + rval =
> vidioc_int_s_ctrl(vdev->vdev_sensor, +
> &vc); +
> mutex_unlock(&vdev->mutex);
> + if (rval)
> + goto out;
> + }
> + }
> + break;
> + case VIDIOC_PRIVATE_ISP_AF_REQ: {
> + /* Need to update lens first */
> + struct isp_af_data *data;
> + struct v4l2_control vc;
> +
> + if (!vdev->vdev_lens) {
> + rval = -EINVAL;
> + goto out;
> + }
> + data = (struct isp_af_data *) arg;
> + if (data->update & LENS_DESIRED_POSITION) {
> + vc.id = V4L2_CID_FOCUS_ABSOLUTE;
> + vc.value =
> data->desired_lens_direction; +
> mutex_lock(&vdev->mutex);
> + rval =
> vidioc_int_s_ctrl(vdev->vdev_lens, &vc); +
>mutex_unlock(&vdev->mutex);
> + if (rval)
> + goto out;
> + }
> + if (data->update & REQUEST_STATISTICS) {
> + vc.id = V4L2_CID_FOCUS_ABSOLUTE;
> + mutex_lock(&vdev->mutex);
> + rval =
> vidioc_int_g_ctrl(vdev->vdev_lens, &vc); +
>mutex_unlock(&vdev->mutex);
> + if (rval)
> + goto out;
> + data->xtrastats.lens_position =
> vc.value; +
Re: KWorld ATSC 115 all static
Hi, Am Montag, den 12.01.2009, 21:10 -0500 schrieb CityK: > Hans Verkuil wrote: > > Yes, I can. I'll do saa7134 since I have an empress card anyway. It > > should be quite easy (the cx18 complication is not an issue here). > > > > Regards, > > > > Hans > > Thanks Hans! > yes, Hans is a very fine guy. But don't hope for too much for DVB/ATSC related stuff soon. We know about the problems caused by switching antenna inputs from a digital demod, it was a famous hack from Chris on cx88xx and Mike did good work to port it to saa713x, but unfortunately there was some ongoing loss on the other side of the planet then later. I doubt that Hans is already aware of it at this stage, but since these days bugs are fixed from guys without even having hardware, and this is good progress, likely they will add new devices the same way too soon. I seem to be far behind currently, all caused by the HDTV hype ;) Cheers, Hermann -- 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: saa7134: race between device initialization and first interrupt
On Mon, 2009-01-12 at 11:13 -0800, Trent Piepho wrote: > On Sun, 11 Jan 2009, Andy Walls wrote: > > On Mon, 2009-01-12 at 00:54 +0100, hermann pitton wrote: > > > Am Samstag, den 10.01.2009, 22:05 -0500 schrieb Andy Walls: > > > > On Sun, 2009-01-11 at 03:32 +0100, hermann pitton wrote: > > > > > Am Samstag, den 10.01.2009, 07:37 -0500 schrieb Andy Walls: > > > > > > On Sat, 2009-01-10 at 13:02 +0100, Marcin Slusarz wrote: > > > > > > > On Fri, Jan 09, 2009 at 09:48:07PM -0500, Andy Walls wrote: > > > > > > > > but not clearing the state of SAA7134_IRQ_REPORT, maybe > > > > > > > > something like > > > > > > > > this (I don't have a SAA7134 datasheet): > > > > > > > > > > > > > > > > saa_writel(SAA7134_IRQ_REPORT, 0x); > > > > > > > > > > > > > > > > So when saa7134_initdev() calls request_irq(..., saa7134_irq, > > > > > > > > IRQF_SHARED | IRQF_DISABLED, ...), it gets an IRQ that is > > > > > > > > shared with > > > > > > > > another device. > > Keep in mind that PCI writes are posted, so 'writel(...);request_irq(...);' > might result in the irq being requested (which only involves the CPU and > kernel) before the device receives and processes the write (which involves > the CPU, pci bridge(s), and the saa7134 device). Yeah, but the next read back will flush the write through the bridge - PCI ordering rules. > IMHO, a better solution is to just not request the irq until the driver is > read to handle interrupts. That seems a lot safer than depending on the > irq handler not doing anything bad if it's called while the driver is still > initializing. Yes. Agree. I was looking for something simple. I see Mauro already applied my little one liner. It won't do any harm (clears the report register after disabling notifications), but a more deterministic inhibition of the saa7134_irq() handler until really ready would be safer. > > > Andy, I allowed shared interrupts on several machines with multiple > > > saa713x cards and current v4l-dvb, but I'm still not able to reproduce > > > the oops. So can't try the fix. Who has the oops and can try? > > What you need to have is the saa713x sharing an interrupt with a different > device which generates a lot of interrupts while the saa713x driver is > being loaded. Even then it's a race and isn't going to happen every time. Agree. > > So "dev->input" is NULL when saa7134-tvaudio.c:mute_input_7133() is > > called and that is what causes the Oops. It was called by the > > saa7134_irq() handler trying to take action, shortly after request_irq() > > was called. Can you think of why this would happen? > > I have no doubt that the original idea that SAA7134_IRQ_REPORT isn't clear > when the driver loads is correct. Why shouldn't the bits be set? And if > they are, we should see an Oops that looks exactly like this one. Yes, my thoughts. Regards. Andy -- 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
On Mon, 2009-01-12 at 06:09 -0500, Brandon Jenkins wrote: > On Sun, Jan 4, 2009 at 7:54 PM, Andy Walls wrote: > > Mauro, > > > > Adding one more to my pull request. > > > > Please pull from: > > > > http://linuxtv.org/hg/~awalls/v4l-dvb > > > > for the following changes: > > > > cx18: Fix bad audio in first analog capture. > > cx18, cx2341x: Fix bugs in cx18 AC3 control and comply with V4L2 spec > > cx18, cx2341x, ivtv: Add AC-3 audio encoding control to cx18 > > cx18: Additional debug to display outgoing mailbox parameters > > cx18: Fix a PLL divisor update for the I2S master clock > > > > Regards, > > Andy > > > > diffstat: > > drivers/media/video/cx18/cx18-av-firmware.c |4 - > > drivers/media/video/cx18/cx18-driver.c | 19 - > > drivers/media/video/cx18/cx18-driver.h |2 > > drivers/media/video/cx18/cx18-fileops.c |8 +- > > drivers/media/video/cx18/cx18-mailbox.c | 46 +--- > > drivers/media/video/cx18/cx23418.h | 16 > > drivers/media/video/cx2341x.c | 101 > > ++-- > > drivers/media/video/ivtv/ivtv-driver.h |2 > > drivers/media/video/ivtv/ivtv-fileops.c |8 +- > > include/media/cx2341x.h |6 + > > 10 files changed, 175 insertions(+), 37 deletions(-) > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Andy, > > I don't think these changes were ever merged in. I noticed newer > activity in your dev tree though since this request. Is it safe to > grab that as well, or should I go back to this date? They should be safe. Please note that I'm recovering from a hard down of my main machine [root partition superblock got corrupted along with a lot of the filesystem :( ] so I won't be doing to much more in the next day or three or four... -Andy > Thanks, > > Brandon > -- > 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: FM transmitter support under v4l2?
On Mon, 12 Jan 2009 15:00:10 +0530 Trilok Soni wrote: > Hi Mauro, > > >> > >> FYI..now maemo kernel team seems to have written Si4713 FM transmitter > >> driver interfaced over I2C. It is available in the kernel diff here. > >> > >> http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.27-20084805r03.diff.gz > >> > >> Please download and unzip it and search for > >> > >> radio-si4713.c > > > > Hi Trilok. Thanks for pointing us for the driver. > > > > The driver seems interesting, but I see a few issues with their approach: > > > > 1) it is creating a sysfs API for controlling some of the characteristics of > > the radio. Public API's should be discussed with enough care at > > linux-media@vger.kernel.org before their addition on a driver, and properly > > documented. Also, IMO, the better would be to use VIDIOC_[G|C]_CTRL calls > > for > > this, or to create another ioctl for handling FM transmission; > > Yes, I came across it. It might be because Eduardo just want's to make > it functional and didn't had much time to communicate with community > while making next Nokia Internet Table work with this chip. I can see > that you have CCed him, and he might want to start the interaction now > to formalize the FM transmitter related controls/APIs. Yes. > > > > > 2) a V4L2 application has no means to determine that the device is a FM > > transmission device. We need to add some capability flags to inform this to > > userspace. > > > > Right, a formal cap flag is good. I don't have access to such > in-development Nokia device, and Eduardo can help us here to send a > patch. I've contacted him. We'll likely comment about it on the next days. Maybe we can hold this discussion for a few days, since we need right now to focus on the 14 OMAP3 patches. > > > While there, I noticed also a driver for radio-tea5761 and a patch for > > common/tuners/tea5761.c. This also deserves review at > > linux-me...@vger.kernel.org. > > > > I need to look at this in the diff. Thanks for the 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: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Hi Stanley, I'm currently have that patch on hold, along with the ISP wrapper because I'm reworking them, and also I wanted first to be sure the OMAP3 camera core gets pushed (that's why I included only one sensor driver, to be able to test at least the camera core), and that way I feel it'll be more easier that the OV3640 sensor gets accepted after that. Thanks for the interest. Regards, Sergio > -Original Message- > From: stanley.miao [mailto:stanley.m...@windriver.com] > Sent: Monday, January 12, 2009 8:31 PM > To: Aguirre Rodriguez, Sergio Alberto > Cc: linux-o...@vger.kernel.org; video4linux-l...@redhat.com; Nagalla, > Hari; Sakari Ailus; Tuukka.O Toivonen; linux-media@vger.kernel.org > Subject: Re: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor > driver v2 > > Hi,Sergio, > > I saw you had a ov3640 patch in omapzoom tree. Why don't you submit it > together ? > > Stanley. > > On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto > wrote: > > Hi, > > > > I'm sending the following patchset for review to the relevant lists > (linux-omap, v4l, linux-media). > > > > Includes: > > - Omap3 camera core + ISP drivers. > > - MT9P012 sensor driver (adapted to 3430SDP) > > - DW9710 lens driver (adapted to work with MT9P012 for SDP) > > - Necessary v4l2-int-device changes to make above drivers work > > - Redefine OMAP3 ISP platform device. > > - Review comments fixed from: (Thanks a lot for their time and help) > >- Hans Verkuil > >- Tony Lindgreen > >- Felipe Balbi > >- Vaibhav Hiremath > >- David Brownell > > > > Some notes: > > - Uses v4l2-int-device solution. > > - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 > > - Applies cleanly on top of commit > 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: > Emu_pwrdm is switched off by hardware even when sdti is in use) > > - ISP wrappers dropped from the patchset, as a rework is going on > currently. > > > > > > I appreciate in advance your time. > > > > Regards, > > Sergio > > > > -- > > video4linux-list mailing list > > Unsubscribe mailto:video4linux-list- > requ...@redhat.com?subject=unsubscribe > > https://www.redhat.com/mailman/listinfo/video4linux-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
Re: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Hi,Sergio, I saw you had a ov3640 patch in omapzoom tree. Why don't you submit it together ? Stanley. On Mon, 2009-01-12 at 20:03 -0600, Aguirre Rodriguez, Sergio Alberto wrote: > Hi, > > I'm sending the following patchset for review to the relevant lists > (linux-omap, v4l, linux-media). > > Includes: > - Omap3 camera core + ISP drivers. > - MT9P012 sensor driver (adapted to 3430SDP) > - DW9710 lens driver (adapted to work with MT9P012 for SDP) > - Necessary v4l2-int-device changes to make above drivers work > - Redefine OMAP3 ISP platform device. > - Review comments fixed from: (Thanks a lot for their time and help) >- Hans Verkuil >- Tony Lindgreen >- Felipe Balbi >- Vaibhav Hiremath >- David Brownell > > Some notes: > - Uses v4l2-int-device solution. > - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 > - Applies cleanly on top of commit 0ec95b96fd77036a13398c66901e11cd301190d0 > by Jouni Hogander (OMAP3: PM: Emu_pwrdm is switched off by hardware even when > sdti is in use) > - ISP wrappers dropped from the patchset, as a rework is going on currently. > > > I appreciate in advance your time. > > Regards, > Sergio > > -- > video4linux-list mailing list > Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/video4linux-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
Re: KWorld ATSC 115 all static
Hans Verkuil wrote: > Yes, I can. I'll do saa7134 since I have an empress card anyway. It > should be quite easy (the cx18 complication is not an issue here). > > Regards, > > Hans Thanks Hans! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 13/14] OMAP: CAM: Add DW9710 Lens Driver
This adds the DW9710 Lens driver
Signed-off-by: Sergio Aguirre
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |1 +
drivers/media/video/dw9710.c | 548 +
drivers/media/video/dw9710_priv.h | 57
include/media/dw9710.h| 35 +++
5 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/dw9710.c
create mode 100644 drivers/media/video/dw9710_priv.h
create mode 100644 include/media/dw9710.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 1616c32..10075c3 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -313,6 +313,14 @@ config VIDEO_MT9P012
MT9P012 camera. It is currently working with the TI OMAP3
camera controller.
+config VIDEO_DW9710
+ tristate "Lens driver for DW9710"
+ depends on I2C && VIDEO_V4L2
+ ---help---
+ This is a Video4Linux2 lens driver for the Dongwoon
+ DW9710 coil. It is currently working with the TI OMAP3
+ camera controller and micron MT9P012 sensor.
+
config VIDEO_SAA7110
tristate "Philips SAA7110 video decoder"
depends on VIDEO_V4L1 && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f73b65c..41c71d5 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_MT9P012)+= mt9p012.o
+obj-$(CONFIG_VIDEO_DW9710) += dw9710.o
obj-$(CONFIG_VIDEO_OMAP3) += omap34xxcam.o isp/
diff --git a/drivers/media/video/dw9710.c b/drivers/media/video/dw9710.c
new file mode 100644
index 000..362cb0d
--- /dev/null
+++ b/drivers/media/video/dw9710.c
@@ -0,0 +1,548 @@
+/*
+ * drivers/media/video/dw9710.c
+ *
+ * DW9710 Coil Motor (LENS) driver
+ *
+ * Copyright (C) 2008 Texas Instruments.
+ *
+ * Contributors:
+ * Troy Laramy
+ * Mohit Jalori
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "dw9710_priv.h"
+
+static struct dw9710_device dw9710 = {
+ .state = DW9710_LENS_NOT_DETECTED,
+ .current_lens_posn = DW9710_DEF_LENS_POSN,
+};
+
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_FOCUS_ABSOLUTE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Focus, Absolute",
+ .minimum = 0,
+ .maximum = DW9710_MAX_FOCUS_POS,
+ .step = DW9710_LENS_POSN_STEP,
+ .default_value = DW9710_DEF_LENS_POSN,
+ },
+ .current_value = DW9710_DEF_LENS_POSN,
+ }
+};
+
+/**
+ * find_vctrl - Finds the requested ID in the video control structure array
+ * @id: ID of control to search the video control array for
+ *
+ * Returns the index of the requested ID from the control structure array
+ */
+static int find_vctrl(int id)
+{
+ int i;
+
+ if (id < V4L2_CID_BASE)
+ return -EDOM;
+
+ for (i = (ARRAY_SIZE(video_control) - 1); i >= 0; i--) {
+ if (video_control[i].qc.id == id)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * dw9710_reg_read - Reads a value from a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Pointer to u16 for returning value of register to read.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_read(struct i2c_client *client, u16 *value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+
+ if (!client->adapter)
+ return -ENODEV;
+
+ msg->addr = client->addr;
+ msg->flags = I2C_M_RD;
+ msg->len = 2;
+ msg->buf = data;
+
+ data[0] = 0;
+ data[1] = 0;
+
+ err = i2c_transfer(client->adapter, msg, 1);
+
+ if (err >= 0) {
+ err = ((data[0] & 0xFF) << 8) | (data[1]);
+ *value = err;
+ return 0;
+ }
+ return err;
+}
+
+/**
+ * dw9710_reg_write - Writes a value to a register in DW9710 Coil driver
device.
+ * @client: Pointer to structure of I2C client.
+ * @value: Value of register to write.
+ *
+ * Returns zero if successful, or non-zero otherwise.
+ **/
+static int dw9710_reg_write(struct i2c_client *client, u16 value)
+{
+ int err;
+ struct i2c_msg msg[1];
+ unsigned char data[2];
+ int retry = 0;
+
+ if (!client->adapter)
+ return -ENODEV;
+
[REVIEW PATCH 14/14] OMAP34XX: CAM: Add Sensors Support
This adds support in OMAP34xx SDP board file for
MT9P012 Sensor and DW9710 Lens driver.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/board-3430sdp.c | 319 ++-
1 files changed, 318 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ade186b..8fa1d4d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -40,6 +41,31 @@
#include
#include
+#ifdef CONFIG_VIDEO_OMAP3
+#include
+#include <../drivers/media/video/omap34xxcam.h>
+#include <../drivers/media/video/isp/ispreg.h>
+#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
+/* Sensor specific GPIO signals */
+#define MT9P012_RESET_GPIO 98
+#define MT9P012_STANDBY_GPIO 58
+
+#define MT9P012_USE_XCLKA 0
+#define MT9P012_USE_XCLKB 1
+
+#define VAUX_2_8_V 0x09
+#define VAUX_DEV_GRP_P10x20
+#define VAUX_DEV_GRP_NONE 0x00
+
+#include
+static enum v4l2_power mt9p012_previous_power = V4L2_POWER_OFF;
+#endif
+#endif
+
+#ifdef CONFIG_VIDEO_DW9710
+#include
+#endif
+
#include
#include
#include
@@ -238,6 +264,281 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
+#ifdef CONFIG_VIDEO_OMAP3
+#define DEBUG_BASE 0x0800
+#define REG_SDP3430_FPGA_GPIO_2 (0x50)
+#define FPGA_SPR_GPIO1_3v3 (0x1 << 14)
+#define FPGA_GPIO6_DIR_CTRL(0x1 << 6)
+
+static void __iomem *fpga_map_addr;
+
+static void enable_fpga_vio_1v8(u8 enable)
+{
+ u16 reg_val;
+
+ fpga_map_addr = ioremap(DEBUG_BASE, 4096);
+ reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+
+ /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
+ if (reg_val & FPGA_SPR_GPIO1_3v3) {
+ reg_val |= FPGA_SPR_GPIO1_3v3;
+ reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ /* give a few milli sec to settle down
+* Let the sensor also settle down.. if required..
+*/
+ if (enable)
+ mdelay(10);
+ }
+
+ if (enable) {
+ reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ }
+ /* Vrise time for the voltage - should be less than 1 ms */
+ mdelay(1);
+}
+#endif
+
+#ifdef CONFIG_VIDEO_DW9710
+static int dw9710_lens_power_set(enum v4l2_power power)
+{
+
+ /* The power change depends on MT9P012 powerup, so if we request a
+* power state different from sensor, we should return error
+*/
+ if ((mt9p012_previous_power != V4L2_POWER_OFF) &&
+ (power != mt9p012_previous_power))
+ return -EIO;
+
+ switch (power) {
+ case V4L2_POWER_OFF:
+ /* Power Down Sequence */
+#ifdef CONFIG_TWL4030_CORE
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ VAUX_DEV_GRP_NONE, TWL4030_VAUX2_DEV_GRP);
+#else
+#error "no power companion board defined!"
+#endif
+ enable_fpga_vio_1v8(0);
+ gpio_free(MT9P012_RESET_GPIO);
+ iounmap(fpga_map_addr);
+ gpio_free(MT9P012_STANDBY_GPIO);
+ break;
+ case V4L2_POWER_ON:
+ /* Request and configure gpio pins */
+ if (gpio_request(MT9P012_STANDBY_GPIO,
+ "mt9p012_standby_gpio")) {
+ printk(KERN_WARNING "Could not request GPIO %d"
+ " for MT9P012\n",
+ MT9P012_STANDBY_GPIO);
+ return -EIO;
+ }
+
+ /* Request and configure gpio pins */
+ if (gpio_request(MT9P012_RESET_GPIO, "mt9p012_reset_gpio"))
+ return -EIO;
+
+ /* set to output mode */
+ gpio_direction_output(MT9P012_STANDBY_GPIO, true);
+ /* set to output mode */
+ gpio_direction_output(MT9P012_RESET_GPIO, true);
+
+ /* STANDBY_GPIO is active HIGH for set LOW to release */
+ gpio_set_value(MT9P012_STANDBY_GPIO, 1);
+
+ /* nRESET is active LOW. set HIGH to release reset */
+ gpio_set_value(MT9P012_RESET_GPIO, 1);
+
+ /* turn on digital power */
+ enable_fpga_vio_1v8(1);
+#ifdef CONFIG_TWL4030_CORE
+ /* turn on analog power */
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ VAUX_2_8_V, TWL4030_VAUX2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODU
[REVIEW PATCH 10/14] OMAP: CAM: Add ISP gain tables
This adds the OMAP ISP gain tables. Includes: * Blue Gamma gain table * CFA gain table * Green Gamma gain table * Luma Enhancement gain table * Noise filter gain table * Red Gamma gain table Signed-off-by: Sergio Aguirre --- drivers/media/video/isp/bluegamma_table.h| 1040 ++ drivers/media/video/isp/cfa_coef_table.h | 592 +++ drivers/media/video/isp/greengamma_table.h | 1040 ++ drivers/media/video/isp/luma_enhance_table.h | 144 drivers/media/video/isp/noise_filter_table.h | 79 ++ drivers/media/video/isp/redgamma_table.h | 1040 ++ 6 files changed, 3935 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/isp/bluegamma_table.h create mode 100644 drivers/media/video/isp/cfa_coef_table.h create mode 100644 drivers/media/video/isp/greengamma_table.h create mode 100644 drivers/media/video/isp/luma_enhance_table.h create mode 100644 drivers/media/video/isp/noise_filter_table.h create mode 100644 drivers/media/video/isp/redgamma_table.h diff --git a/drivers/media/video/isp/bluegamma_table.h b/drivers/media/video/isp/bluegamma_table.h new file mode 100644 index 000..9ec8376 --- /dev/null +++ b/drivers/media/video/isp/bluegamma_table.h @@ -0,0 +1,1040 @@ +/* + * drivers/media/video/isp/bluegamma_table.h + * + * Gamma Table values for BLUE for TI's OMAP3 Camera ISP + * + * Copyright (C) 2008 Texas Instruments, Inc. + * + * This package 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. + * + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + */ + +0, +0, +1, +2, +3, +3, +4, +5, +6, +8, +10, +12, +14, +16, +18, +20, +22, +23, +25, +26, +28, +29, +31, +32, +34, +35, +36, +37, +39, +40, +41, +42, +43, +44, +45, +46, +47, +48, +49, +50, +51, +52, +52, +53, +54, +55, +56, +57, +58, +59, +60, +61, +62, +63, +63, +64, +65, +66, +66, +67, +68, +69, +69, +70, +71, +72, +72, +73, +74, +75, +75, +76, +77, +78, +78, +79, +80, +81, +81, +82, +83, +84, +84, +85, +86, +87, +88, +88, +89, +90, +91, +91, +92, +93, +94, +94, +95, +96, +97, +97, +98, +98, +99, +99, +100, +100, +101, +101, +102, +103, +104, +104, +105, +106, +107, +108, +108, +109, +110, +111, +111, +112, +113, +114, +114, +115, +116, +117, +117, +118, +119, +119, +120, +120, +121, +121, +122, +122, +123, +123, +124, +124, +125, +125, +126, +126, +127, +127, +128, +128, +129, +129, +130, +130, +131, +131, +132, +132, +133, +133, +134, +134, +135, +135, +136, +136, +137, +137, +138, +138, +139, +139, +140, +140, +141, +141, +142, +142, +143, +143, +144, +144, +145, +145, +146, +146, +147, +147, +148, +148, +149, +149, +150, +150, +151, +151, +152, +152, +153, +153, +153, +153, +154, +154, +154, +154, +155, +155, +156, +156, +157, +157, +158, +158, +158, +159, +159, +159, +160, +160, +160, +161, +161, +162, +162, +163, +163, +164, +164, +164, +164, +165, +165, +165, +165, +166, +166, +167, +167, +168, +168, +169, +169, +170, +170, +170, +170, +171, +171, +171, +171, +172, +172, +173, +173, +174, +174, +175, +175, +176, +176, +176, +176, +177, +177, +177, +177, +178, +178, +178, +178, +179, +179, +179, +179, +180, +180, +180, +180, +181, +181, +181, +181, +182, +182, +182, +182, +183, +183, +183, +183, +184, +184, +184, +184, +185, +185, +185, +185, +186, +186, +186, +186, +187, +187, +187, +187, +188, +188, +188, +188, +189, +189, +189, +189, +190, +190, +190, +190, +191, +191, +191, +191, +192, +192, +192, +192, +193, +193, +193, +193, +194, +194, +194, +194, +195, +195, +195, +195, +196, +196, +196, +196, +197, +197, +197, +197, +198, +198, +198, +198, +199, +199, +199, +199, +200, +200, +200, +200, +201, +201, +201, +201, +202, +202, +202, +203, +203, +203, +203, +204, +204, +204, +204, +205, +205, +205, +205, +206, +206, +206, +206, +207, +207, +207, +207, +208, +208, +208, +208, +209, +209, +209, +209, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +210, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +211, +212, +212, +212, +212, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +213, +214, +214, +214, +214, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +215, +216, +216, +216, +216, +217, +217, +217, +217, +218, +218, +218, +218, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +219, +220, +220, +220, +220, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +221, +222, +222, +222, +222, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +223, +224, +224, +224, +224, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +225, +226, +226, +226, +226, +227, +227, +227, +227, +227, +227, +227, +227, +227,
[REVIEW PATCH 03/14] OMAP34XX: CAM: Resources fixes
This patch reassigns resources of a omap3isp platform device,
which is more adequate than the older one. This is needed for
using __raw_[readl,writel] calls after ioremapping the specified
platform resources in ISP driver.
Signed-off-by: Sergio Aguirre
---
arch/arm/mach-omap2/devices.c | 76 ++--
arch/arm/plat-omap/include/mach/omap34xx.h | 53 +++-
2 files changed, 123 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d7e848e..4617c8b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -56,10 +56,68 @@ static inline void omap_init_camera(void)
#elif defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
-static struct resource cam_resources[] = {
+static struct resource omap34xxcam_resources[] = {
+};
+
+static struct resource omap3isp_resources[] = {
+ {
+ .start = OMAP3_ISP_BASE,
+ .end= OMAP3_ISP_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CBUFF_BASE,
+ .end= OMAP3_ISP_CBUFF_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CCP2_BASE,
+ .end= OMAP3_ISP_CCP2_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CCDC_BASE,
+ .end= OMAP3_ISP_CCDC_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_HIST_BASE,
+ .end= OMAP3_ISP_HIST_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_H3A_BASE,
+ .end= OMAP3_ISP_H3A_END,
+ .flags = IORESOURCE_MEM,
+ },
{
- .start = OMAP34XX_CAMERA_BASE,
- .end= OMAP34XX_CAMERA_BASE + 0x1B70,
+ .start = OMAP3_ISP_PREV_BASE,
+ .end= OMAP3_ISP_PREV_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_RESZ_BASE,
+ .end= OMAP3_ISP_RESZ_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_SBL_BASE,
+ .end= OMAP3_ISP_SBL_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_MMU_BASE,
+ .end= OMAP3_ISP_MMU_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CSI2A_BASE,
+ .end= OMAP3_ISP_CSI2A_END,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP3_ISP_CSI2PHY_BASE,
+ .end= OMAP3_ISP_CSI2PHY_END,
.flags = IORESOURCE_MEM,
},
{
@@ -71,13 +129,21 @@ static struct resource cam_resources[] = {
static struct platform_device omap_cam_device = {
.name = "omap34xxcam",
.id = -1,
- .num_resources = ARRAY_SIZE(cam_resources),
- .resource = cam_resources,
+ .num_resources = ARRAY_SIZE(omap34xxcam_resources),
+ .resource = omap34xxcam_resources,
+};
+
+static struct platform_device omap_isp_device = {
+ .name = "omap3isp",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap3isp_resources),
+ .resource = omap3isp_resources,
};
static inline void omap_init_camera(void)
{
platform_device_register(&omap_cam_device);
+ platform_device_register(&omap_isp_device);
}
#else
static inline void omap_init_camera(void)
diff --git a/arch/arm/plat-omap/include/mach/omap34xx.h
b/arch/arm/plat-omap/include/mach/omap34xx.h
index 27a1e45..d19c423 100644
--- a/arch/arm/plat-omap/include/mach/omap34xx.h
+++ b/arch/arm/plat-omap/include/mach/omap34xx.h
@@ -56,7 +56,32 @@
#define OMAP34XX_SR1_BASE 0x480C9000
#define OMAP34XX_SR2_BASE 0x480CB000
-#define OMAP34XX_CAMERA_BASE (L4_34XX_BASE + 0xBC000)
+#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000)
+#define OMAP3430_ISP_CBUFF_BASE(OMAP3430_ISP_BASE + 0x0100)
+#define OMAP3430_ISP_CCP2_BASE (OMAP3430_ISP_BASE + 0x0400)
+#define OMAP3430_ISP_CCDC_BASE (OMAP3430_ISP_BASE + 0x0600)
+#define OMAP3430_ISP_HIST_BASE (OMAP3430_ISP_BASE + 0x0A00)
+#define OMAP3430_ISP_H3A_BASE (OMAP3430_ISP_BASE + 0x0C00)
+#define OMAP3430_ISP_PREV_BASE (OMAP3430_ISP_BASE + 0x0E00)
+#define OMAP3430_ISP_RESZ_BASE (OMAP3430_ISP_BASE + 0x100
[REVIEW PATCH 02/14] v4l2-int-device: add support for VIDIOC_QUERYMENU
Signed-off-by: Tuukka Toivonen
Signed-off-by: Sergio Aguirre
---
include/media/v4l2-int-device.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 85a1834..052ffe0 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -178,6 +178,7 @@ enum v4l2_int_ioctl_num {
vidioc_int_s_fmt_cap_num,
vidioc_int_try_fmt_cap_num,
vidioc_int_queryctrl_num,
+ vidioc_int_querymenu_num,
vidioc_int_g_ctrl_num,
vidioc_int_s_ctrl_num,
vidioc_int_cropcap_num,
@@ -279,6 +280,7 @@ V4L2_INT_WRAPPER_1(g_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(s_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(try_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(queryctrl, struct v4l2_queryctrl, *);
+V4L2_INT_WRAPPER_1(querymenu, struct v4l2_querymenu, *);
V4L2_INT_WRAPPER_1(g_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(s_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(cropcap, struct v4l2_cropcap, *);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 01/14] V4L: Int if: Dummy slave
This patch implements a dummy slave that has no functionality. Helps
managing slaves in the OMAP 3 camera driver; no need to check for NULL
pointers.
Signed-off-by: Sakari Ailus
Signed-off-by: Sergio Aguirre
---
drivers/media/video/v4l2-int-device.c | 19 +++
include/media/v4l2-int-device.h |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-int-device.c
b/drivers/media/video/v4l2-int-device.c
index a935bae..cba1c9c 100644
--- a/drivers/media/video/v4l2-int-device.c
+++ b/drivers/media/video/v4l2-int-device.c
@@ -32,6 +32,25 @@
static DEFINE_MUTEX(mutex);
static LIST_HEAD(int_list);
+static struct v4l2_int_slave dummy_slave = {
+ /* Dummy pointer to avoid underflow in find_ioctl. */
+ .ioctls = (void *)0x8000,
+ .num_ioctls = 0,
+};
+
+static struct v4l2_int_device dummy = {
+ .type = v4l2_int_type_slave,
+ .u = {
+ .slave = &dummy_slave,
+ },
+};
+
+struct v4l2_int_device *v4l2_int_device_dummy()
+{
+ return &dummy;
+}
+EXPORT_SYMBOL_GPL(v4l2_int_device_dummy);
+
void v4l2_int_device_try_attach_all(void)
{
struct v4l2_int_device *m, *s;
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 9c2df41..85a1834 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -84,6 +84,8 @@ struct v4l2_int_device {
void *priv;
};
+struct v4l2_int_device *v4l2_int_device_dummy(void);
+
void v4l2_int_device_try_attach_all(void);
int v4l2_int_device_register(struct v4l2_int_device *d);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2
Hi, I'm sending the following patchset for review to the relevant lists (linux-omap, v4l, linux-media). Includes: - Omap3 camera core + ISP drivers. - MT9P012 sensor driver (adapted to 3430SDP) - DW9710 lens driver (adapted to work with MT9P012 for SDP) - Necessary v4l2-int-device changes to make above drivers work - Redefine OMAP3 ISP platform device. - Review comments fixed from: (Thanks a lot for their time and help) - Hans Verkuil - Tony Lindgreen - Felipe Balbi - Vaibhav Hiremath - David Brownell Some notes: - Uses v4l2-int-device solution. - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 - Applies cleanly on top of commit 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: Emu_pwrdm is switched off by hardware even when sdti is in use) - ISP wrappers dropped from the patchset, as a rework is going on currently. I appreciate in advance your time. Regards, Sergio -- 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
TT S2-3200 card - which repo to choose
Hi, folks. What's the most up-to-date repo to use for a TT S2-3200 card? s2-lipliandvb or V4L-DVB? Currently I' m using s2-lipliandvb, but with all the work being done because of kernel pull, I lost track. Any thoughts on what version works best? Any significant differences? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: [PATCH] Terratec Cinergy DT XS Diversity new USB ID (0ccd:0081)
This time with the patch as attachment:
The following patch adds support for a new version of the
Terratec Cinergy DT USB XS Diversity Dual DVB-T TV tuner stick.
The USB ID of the new stick is 0ccd:0081.
The hardware of the stick has changed, when compared to the first version of
this stick, but it still uses quite standard components, so that only minor
changes are needed to the sources.
The patch has been successfully tested with hotplugging the device and then
2 x tzap and 2 x mplayer, to watch two different TV programs simultaneously.
The stick works with both, the old and new firmwares:
- dvb-usb-dib0700-1.10.fw and
- dvb-usb-dib0700-1.20.fw
Priority: normal
Signed-off-by: Nicolas Fournier
diff -r 0293688d353f linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Mon Jan 12 09:09:08 2009 -0800
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Tue Jan 13 00:24:42 2009 +0100
@@ -1394,6 +1394,8 @@ struct usb_device_id dib0700_usb_id_tabl
/* 40 */{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV801E) },
{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV801E_SE) },
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_EXPRESS) },
+ { USB_DEVICE(USB_VID_TERRATEC,
+ USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1659,7 +1661,7 @@ struct dvb_usb_device_properties dib0700
}
},
- .num_device_descs = 4,
+ .num_device_descs = 5,
.devices = {
{ "DiBcom STK7070PD reference design",
{ &dib0700_usb_id_table[17], NULL },
@@ -1675,6 +1677,10 @@ struct dvb_usb_device_properties dib0700
},
{ "Hauppauge Nova-TD-500 (84xxx)",
{ &dib0700_usb_id_table[36], NULL },
+{ NULL },
+ },
+ { "Terratec Cinergy DT USB XS Diversity",
+{ &dib0700_usb_id_table[43], NULL },
{ NULL },
}
}
diff -r 0293688d353f linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Mon Jan 12 09:09:08 2009 -0800
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Tue Jan 13 00:25:38 2009 +0100
@@ -162,6 +162,7 @@
#define USB_PID_AVERMEDIA_A3090xa309
#define USB_PID_TECHNOTREND_CONNECT_S2400 0x3006
#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY 0x005a
+#define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2 0x0081
#define USB_PID_TERRATEC_CINERGY_HT_USB_XE 0x0058
#define USB_PID_TERRATEC_CINERGY_HT_EXPRESS 0x0060
#define USB_PID_TERRATEC_CINERGY_T_EXPRESS 0x0062
Re: saa7134: race between device initialization and first interrupt
Hi,
Am Sonntag, den 11.01.2009, 20:22 -0500 schrieb Andy Walls:
> >
> > So "dev->input" is NULL when saa7134-tvaudio.c:mute_input_7133() is
> > called and that is what causes the Oops. It was called by the
> > saa7134_irq() handler trying to take action, shortly after request_irq()
> > was called. Can you think of why this would happen?
> >
> Hermann,
>
> I just looked at request_irq() on my Fedora 7
>
>
> int request_irq(unsigned int irq, irq_handler_t handler,
> unsigned long irqflags, const char *devname, void *dev_id)
> {
> [...]
> #ifdef CONFIG_DEBUG_SHIRQ
> if (irqflags & IRQF_SHARED) {
> /*
> * It's a shared IRQ -- the driver ought to be prepared for it
> * to happen immediately, so let's make sure
> * We do this before actually registering it, to make sure
> that
> * a 'real' IRQ doesn't run in parallel with our fake
> */
> unsigned long flags;
>
> local_irq_save(flags);
> handler(irq, dev_id);
> local_irq_restore(flags);
> }
> #endif
> [...]
>
> Maybe the kernels with the reported oops were built with
> CONFIG_DEBUG_SHIRQ set, which will call the saa7134_irq() handler
> immediately. CONFIG_DEBUG_SHIRQ is obviously intended to "smoke out"
> device driver irq handlers that could experience an intermittent oops
> with shared irqs.
>
> Maybe you could enable this in you kernel and reproduce the Ooops?
only on the 2.6.27.2 on the amd quad this was not enabled.
The Fedora 8 and Fedora 10 kernels do have it enabled and it seems to
make no difference and the old 2.6.22 i did not check yet.
I'll send configs and other info of all 4 machines I can test on off
list. Maybe there are ideas for stress tests to hit the supposed race.
Cheers,
Hermann
> Regards,
> Andy
>
> > I don't know. If no one here can test it and confirm a fix, maybe we
> > just forget about it until someone with hardware complains?
--
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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7134 for the following: - ivtv: fix memory leak - v4l2-device: fix buggy macro - v4l2-subdev: add v4l2_ext_controls support The first two are bug fixes with prio high and must go to 2.6.29. It would be nice if the third one can go to 2.6.29 as well, but it is a nice-to-have only. Thanks, Hans diffstat: drivers/media/video/ivtv/ivtv-driver.c |4 +++- drivers/media/video/v4l2-subdev.c |6 ++ include/media/v4l2-device.h|8 include/media/v4l2-subdev.h|3 +++ 4 files changed, 16 insertions(+), 5 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Mon Jan 12 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10220:036cad8c8b51 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc1-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc1-armv5-ixp: WARNINGS linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc1-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc1-i686: WARNINGS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc1-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc1-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc1-powerpc64: WARNINGS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc1-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc1): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 -- 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: saa7134: race between device initialization and first interrupt
On Sun, 11 Jan 2009, Andy Walls wrote: > On Mon, 2009-01-12 at 00:54 +0100, hermann pitton wrote: > > Am Samstag, den 10.01.2009, 22:05 -0500 schrieb Andy Walls: > > > On Sun, 2009-01-11 at 03:32 +0100, hermann pitton wrote: > > > > Am Samstag, den 10.01.2009, 07:37 -0500 schrieb Andy Walls: > > > > > On Sat, 2009-01-10 at 13:02 +0100, Marcin Slusarz wrote: > > > > > > On Fri, Jan 09, 2009 at 09:48:07PM -0500, Andy Walls wrote: > > > > > > > but not clearing the state of SAA7134_IRQ_REPORT, maybe something > > > > > > > like > > > > > > > this (I don't have a SAA7134 datasheet): > > > > > > > > > > > > > > saa_writel(SAA7134_IRQ_REPORT, 0x); > > > > > > > > > > > > > > So when saa7134_initdev() calls request_irq(..., saa7134_irq, > > > > > > > IRQF_SHARED | IRQF_DISABLED, ...), it gets an IRQ that is shared > > > > > > > with > > > > > > > another device. Keep in mind that PCI writes are posted, so 'writel(...);request_irq(...);' might result in the irq being requested (which only involves the CPU and kernel) before the device receives and processes the write (which involves the CPU, pci bridge(s), and the saa7134 device). IMHO, a better solution is to just not request the irq until the driver is read to handle interrupts. That seems a lot safer than depending on the irq handler not doing anything bad if it's called while the driver is still initializing. > > Andy, I allowed shared interrupts on several machines with multiple > > saa713x cards and current v4l-dvb, but I'm still not able to reproduce > > the oops. So can't try the fix. Who has the oops and can try? What you need to have is the saa713x sharing an interrupt with a different device which generates a lot of interrupts while the saa713x driver is being loaded. Even then it's a race and isn't going to happen every time. > So "dev->input" is NULL when saa7134-tvaudio.c:mute_input_7133() is > called and that is what causes the Oops. It was called by the > saa7134_irq() handler trying to take action, shortly after request_irq() > was called. Can you think of why this would happen? I have no doubt that the original idea that SAA7134_IRQ_REPORT isn't clear when the driver loads is correct. Why shouldn't the bits be set? And if they are, we should see an Oops that looks exactly like this one. -- 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] v4l/tvp514x: make the module aware of rich people
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> Sent: Monday, January 12, 2009 11:55 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; Mauro Carvalho Chehab; video4linux-
> l...@redhat.com
> Subject: [PATCH] v4l/tvp514x: make the module aware of rich people
>
> because they might design two of those chips on a single board.
> You never know.
>
[Hiremath, Vaibhav] Thanks, it was in my todo list. I will verify this patch
tomorrow and let you know.
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/media/video/tvp514x.c | 52 +++---
> --
> 1 files changed, 30 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/video/tvp514x.c
> b/drivers/media/video/tvp514x.c
> index 8e23aa5..f9eb6dc 100644
> --- a/drivers/media/video/tvp514x.c
> +++ b/drivers/media/video/tvp514x.c
> @@ -103,7 +103,7 @@ struct tvp514x_std_info {
> * @route: input and output routing at chip level
> */
> struct tvp514x_decoder {
> - struct v4l2_int_device *v4l2_int_device;
> + struct v4l2_int_device v4l2_int_device;
> const struct tvp514x_platform_data *pdata;
> struct i2c_client *client;
>
> @@ -1369,17 +1369,14 @@ static struct tvp514x_decoder tvp514x_dev =
> {
> .current_std = STD_NTSC_MJ,
> .std_list = tvp514x_std_list,
> .num_stds = ARRAY_SIZE(tvp514x_std_list),
> -
> -};
> -
> -static struct v4l2_int_device tvp514x_int_device = {
> - .module = THIS_MODULE,
> - .name = TVP514X_MODULE_NAME,
> - .priv = &tvp514x_dev,
> - .type = v4l2_int_type_slave,
> - .u = {
> - .slave = &tvp514x_slave,
> - },
> + .v4l2_int_device = {
> + .module = THIS_MODULE,
> + .name = TVP514X_MODULE_NAME,
> + .type = v4l2_int_type_slave,
> + .u = {
> + .slave = &tvp514x_slave,
> + },
> + },
> };
>
> /**
> @@ -1392,18 +1389,26 @@ static struct v4l2_int_device
> tvp514x_int_device = {
> static int
> tvp514x_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> {
> - struct tvp514x_decoder *decoder = &tvp514x_dev;
> + struct tvp514x_decoder *decoder;
> int err;
>
> /* Check if the adapter supports the needed features */
> if (!i2c_check_functionality(client->adapter,
> I2C_FUNC_SMBUS_BYTE_DATA))
> return -EIO;
>
> - decoder->pdata = client->dev.platform_data;
> - if (!decoder->pdata) {
> + decoder = kzalloc(sizeof(*decoder), GFP_KERNEL);
> + if (!decoder)
> + return -ENOMEM;
> +
> + if (!client->dev.platform_data) {
> v4l_err(client, "No platform data!!\n");
> - return -ENODEV;
> + err = -ENODEV;
> + goto out_free;
> }
> +
> + *decoder = tvp514x_dev;
> + decoder->v4l2_int_device.priv = decoder;
> + decoder->pdata = client->dev.platform_data;
> /*
>* Fetch platform specific data, and configure the
>* tvp514x_reg_list[] accordingly. Since this is one
> @@ -1419,23 +1424,26 @@ tvp514x_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
>*/
> decoder->id = (struct i2c_device_id *)id;
> /* Attach to Master */
> - strcpy(tvp514x_int_device.u.slave->attach_to, decoder->pdata-
> >master);
> - decoder->v4l2_int_device = &tvp514x_int_device;
> + strcpy(decoder->v4l2_int_device.u.slave->attach_to, decoder-
> >pdata->master);
> decoder->client = client;
> i2c_set_clientdata(client, decoder);
>
> /* Register with V4L2 layer as slave device */
> - err = v4l2_int_device_register(decoder->v4l2_int_device);
> + err = v4l2_int_device_register(&decoder->v4l2_int_device);
> if (err) {
> i2c_set_clientdata(client, NULL);
> v4l_err(client,
> "Unable to register to v4l2. Err[%d]\n", err);
> + goto out_free;
>
> } else
> v4l_info(client, "Registered to v4l2 master %s!!\n",
> decoder->pdata->master);
> -
> return 0;
> +
> +out_free:
> + kfree(decoder);
> + return err;
> }
>
> /**
> @@ -1452,9 +1460,9 @@ static int __exit tvp514x_remove(struct
> i2c_client *client)
> if (!client->adapter)
> return -ENODEV; /* our client isn't attached */
>
> - v4l2_int_device_unregister(decoder->v4l2_int_device);
> + v4l2_int_device_unregister(&decoder->v4l2_int_device);
> i2c_set_clientdata(client, NULL);
> -
> + kfree(decoder);
> return 0;
> }
> /*
> --
> 1.5.6.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] af9015
Lindsay Mathieson wrote: I see the trunk now supports the DigitalNow TinyTwin (af9015), but only for one tuner. Is it possible to enable the second tuner or are there still issues with that? Yes it is possible to enable second tuner by module param, modprobe dvb-usb-af9015 dual_mode=1. But I just tested and looks like no picture at all from 2nd tuner. I have no idea when it was gone totally broken... Anyhow, on single mode it should work 100% well. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l/tvp514x: make the module aware of rich people
because they might design two of those chips on a single board.
You never know.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/media/video/tvp514x.c | 52 +++-
1 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 8e23aa5..f9eb6dc 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -103,7 +103,7 @@ struct tvp514x_std_info {
* @route: input and output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device *v4l2_int_device;
+ struct v4l2_int_device v4l2_int_device;
const struct tvp514x_platform_data *pdata;
struct i2c_client *client;
@@ -1369,17 +1369,14 @@ static struct tvp514x_decoder tvp514x_dev = {
.current_std = STD_NTSC_MJ,
.std_list = tvp514x_std_list,
.num_stds = ARRAY_SIZE(tvp514x_std_list),
-
-};
-
-static struct v4l2_int_device tvp514x_int_device = {
- .module = THIS_MODULE,
- .name = TVP514X_MODULE_NAME,
- .priv = &tvp514x_dev,
- .type = v4l2_int_type_slave,
- .u = {
- .slave = &tvp514x_slave,
- },
+ .v4l2_int_device = {
+ .module = THIS_MODULE,
+ .name = TVP514X_MODULE_NAME,
+ .type = v4l2_int_type_slave,
+ .u = {
+ .slave = &tvp514x_slave,
+ },
+ },
};
/**
@@ -1392,18 +1389,26 @@ static struct v4l2_int_device tvp514x_int_device = {
static int
tvp514x_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct tvp514x_decoder *decoder = &tvp514x_dev;
+ struct tvp514x_decoder *decoder;
int err;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
- decoder->pdata = client->dev.platform_data;
- if (!decoder->pdata) {
+ decoder = kzalloc(sizeof(*decoder), GFP_KERNEL);
+ if (!decoder)
+ return -ENOMEM;
+
+ if (!client->dev.platform_data) {
v4l_err(client, "No platform data!!\n");
- return -ENODEV;
+ err = -ENODEV;
+ goto out_free;
}
+
+ *decoder = tvp514x_dev;
+ decoder->v4l2_int_device.priv = decoder;
+ decoder->pdata = client->dev.platform_data;
/*
* Fetch platform specific data, and configure the
* tvp514x_reg_list[] accordingly. Since this is one
@@ -1419,23 +1424,26 @@ tvp514x_probe(struct i2c_client *client, const struct
i2c_device_id *id)
*/
decoder->id = (struct i2c_device_id *)id;
/* Attach to Master */
- strcpy(tvp514x_int_device.u.slave->attach_to, decoder->pdata->master);
- decoder->v4l2_int_device = &tvp514x_int_device;
+ strcpy(decoder->v4l2_int_device.u.slave->attach_to,
decoder->pdata->master);
decoder->client = client;
i2c_set_clientdata(client, decoder);
/* Register with V4L2 layer as slave device */
- err = v4l2_int_device_register(decoder->v4l2_int_device);
+ err = v4l2_int_device_register(&decoder->v4l2_int_device);
if (err) {
i2c_set_clientdata(client, NULL);
v4l_err(client,
"Unable to register to v4l2. Err[%d]\n", err);
+ goto out_free;
} else
v4l_info(client, "Registered to v4l2 master %s!!\n",
decoder->pdata->master);
-
return 0;
+
+out_free:
+ kfree(decoder);
+ return err;
}
/**
@@ -1452,9 +1460,9 @@ static int __exit tvp514x_remove(struct i2c_client
*client)
if (!client->adapter)
return -ENODEV; /* our client isn't attached */
- v4l2_int_device_unregister(decoder->v4l2_int_device);
+ v4l2_int_device_unregister(&decoder->v4l2_int_device);
i2c_set_clientdata(client, NULL);
-
+ kfree(decoder);
return 0;
}
/*
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [hg:v4l-dvb] zoran: Fix a few CodingStyle issues rised by the previous patch
On Mon, 12 Jan 2009 09:29:54 -0800 (PST) Trent Piepho wrote: > On Sun, 11 Jan 2009, Mauro Carvalho Chehab wrote: > > On Sun, 11 Jan 2009 14:06:01 -0800 (PST) > > Trent Piepho wrote: > > > On Sun, 11 Jan 2009, Patch from Mauro Carvalho Chehab wrote: > > > > From: Mauro Carvalho Chehab > > > > zoran: Fix a few CodingStyle issues rised by the previous patch > > > > > > My first patch wasn't meant to be applied yet, I was going to ask you pull > > > a series from my repository. There was a change Jean suggested and that > > > todo comment at the end wasn't supposed to go in. And now the patches > > > after it won't apply cleanly. > > > > Ah, I didn't know that you're intending to ask me to pull. I generally try > > to > > apply earlier patches that fixes regressions upstream. > > > > > Do you intend to fold these two patches into one at git? If so, then let > > > me add another patch to fold into it as well. > > > > Yes, I can fold The tree patches into one on -git. > > Here is the series. The first patch should be merged with the other two. > > http://linuxtv.org/hg/~tap/zoran > Committed, thanks. Please, always c/c linux-media@vger.kernel.org when asking me to pull patches. 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: Introduction
On Mon, 12 Jan 2009 07:33:19 -0800 (PST) Uri Shkolnik wrote: > Mauro, > > My name is Uri Shkolnik, I work at Siano Mobile Silicon as a software > architect. > > I tried to get in touch with you lately, but I had probably used the wrong > email address, so forgive me for contacting by replying to a post of yours to > the one of the LinuxTV mailing lists... No problem, but I suspect you're suffering some troubles on your anti-spam filters. I've already answered to you twice on your previous emails, from my infradead.org account. > Siano develops DTV chip-sets (multi-standards, multi-interfaces) which are > used by Siano's many customers and partners. > Couple of years ago, our Linux support was minimal, but that situation has > changed, and proximately a year ago, we started to get more an more demand > for Linux kernel support, and we started to offer a minimal set of drivers. > > At the beginning, we used the excellent services given to us by Michael > Krufky, and actually everything we want to publish went through him. > > Recently, the number of Siano-based Linux projects and products increased > significantly. > > With the fast growing number of customers and projects, the number of > additional interfaces, DTV standards and changes fast growth we needed a > different approach. > > On mid-November, we took the second approach which is suggested at the > README.patches file, and submitted the patches to the linux-dvb mailing list, > till today, except some people who took those patches and apply them locally > on their systems, nothing has been done with those patches, and the main > mercurial tree has not been updated with them. The current way we work is that we have some driver maintainers. The driver maintainer is responsible for picking the patch at the mailing lists and apply on their trees, after their review. They then ask me to pull from your trees. This year, we've made one change: now, the patches should be sent to linux-me...@vger.kernel.org. This mailing list is monitored by a robot that picks the patches and add they at a database. the database can be accessed publicly via http://patchwork.kernel.org. This way, people can check each patches. This will also help me to have more control of patches that were lost in the mailing lists. >From my view, as the subsystem maintainer, I prefer to get the patches directly from the manufacturer, of course provided that the manufacturer actively maintains the driver and understands the development model used on Kernel. > The current state is that a huge gap has been opened between the LinuxTV > repository (and from it to the Linux kernel git) offering and what we have at > Siano. > > We would like to close this gap ASAP and maintain an on-going, easy > synchronizing process. > > It seems that the best method to archive this goal is to have maintainer > permissions on media/dvb/siano directory. There are two ways for us to work to archive the goal to minimize the gap: 1) you may send the patches via linux-media@vger.kernel.org, c/c me on they; 2) you may create a Mercurial tree for you. From time to time, you sync your tree with the development one, add your patches there and ask me to pull. It would be better if you could host the tree on some site from you. If you can't do it, we may create you an account at linuxtv.org. If the volume of updates by month is not big, (1) may work better. It also allows a better patch review from the community, so, it is currently the preferred way. Michael, Please let me know if you have any objections on having the Siano developers sending us their patches directly. -- 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: Fw: [PATCH] v4l/dvb: remove err macro from few usb devices
Alexey Klimov wrote: Hello, all Dean, so you think that we don't need s2255 name in the beginning of message and we doesn't need s2255_dev_err macros, right ? As i remember pr_err is just printk with KERN_ERR.. Not at all. We must have s2255 in the beginning of the message. I wasn't sure only about pr_err, but it looks ok now. The s2255_dev_err macros are a good idea. Thanks, Dean -- 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: [linux-dvb] [PATCH] cx88-dvb: Fix order of frontend allocations (Re: current v4l-dvb - cannot access /dev/dvb/: No such file or directory)
I don't have the hardware to test with. Please try this patch.
Hi
I tested the patch and it helped me to get the drivers back to normal
state! My system has hvr-1300 and hvr-4000 and only 1 lnb without diseq.
I am using 2.6.27.7 kernel and I did two test runs.
- First I build the current drivers in http://linuxtv.org/hg/v4l-dvb/
(revision http://linuxtv.org/hg/v4l-dvb/rev/036cad8c8b51)
With this driver version linux failed to boot at all.
- Then I merged your patch by hand on top of this v4l-dvb version
and I got the drivers back to normal version.
With vdr-1.6.0 I was able to tune both the dvb-t channels from hvr-1300
and dvb-s channels from hvr-4000. This vdr 1.6.0 uses old non
S2API/backward compatibility layer of the drivers. I attach your patch
just in case, as I did the merge by hand.
There is still some problem either within the S2API implementation itself
for the HVR-4000 or in the way how VDR-1.7.1, 1.7.2 and 1.7.3
uses S2API because I have not been able to use these newer VDR versions
that use S2API for tuning to S/S2 channels. Technotrend TT S2 3200 users
are however able to use these same VDR versions for tuning to S/S2
channels.
DVB-T channels from hvr-1300 tunes ok with vdr-1.7.3.
I have tested this multiple different versions of D2API drivers both from
the liplianis tree, stock drivers in 2.6.28 kernel and v4l-dvb tree.
Mika
Signed-off-by: Andy Walls
diff -r a28c39659c25 linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c Sat Jan 10 16:04:45 2009 -0500
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c Sun Jan 11 19:13:10 2009 -0500
@@ -621,33 +621,40 @@ static struct stv0288_config tevii_tuner
.set_ts_params = cx24116_set_ts_param,
};
+static int cx8802_alloc_frontends(struct cx8802_dev *dev)
+{
+ struct cx88_core *core = dev->core;
+ struct videobuf_dvb_frontend *fe = NULL;
+ int i;
+
+ mutex_init(&dev->frontends.lock);
+ INIT_LIST_HEAD(&dev->frontends.felist);
+
+ if (!core->board.num_frontends)
+ return -ENODEV;
+
+ printk(KERN_INFO "%s() allocating %d frontend(s)\n", __func__,
+core->board.num_frontends);
+ for (i = 1; i <= core->board.num_frontends; i++) {
+ fe = videobuf_dvb_alloc_frontend(&dev->frontends, i);
+ if (!fe) {
+ printk(KERN_ERR "%s() failed to alloc\n", __func__);
+ videobuf_dvb_dealloc_frontends(&dev->frontends);
+ return -ENOMEM;
+ }
+ }
+ return 0;
+}
+
static int dvb_register(struct cx8802_dev *dev)
{
struct cx88_core *core = dev->core;
struct videobuf_dvb_frontend *fe0, *fe1 = NULL;
int mfe_shared = 0; /* bus not shared by default */
- int i;
if (0 != core->i2c_rc) {
printk(KERN_ERR "%s/2: no i2c-bus available, cannot attach dvb
drivers\n", core->name);
goto frontend_detach;
- }
-
- if (!core->board.num_frontends)
- return -EINVAL;
-
- mutex_init(&dev->frontends.lock);
- INIT_LIST_HEAD(&dev->frontends.felist);
-
- printk(KERN_INFO "%s() allocating %d frontend(s)\n", __func__,
-core->board.num_frontends);
- for (i = 1; i <= core->board.num_frontends; i++) {
- fe0 = videobuf_dvb_alloc_frontend(&dev->frontends, i);
- if (!fe0) {
- printk(KERN_ERR "%s() failed to alloc\n", __func__);
- videobuf_dvb_dealloc_frontends(&dev->frontends);
- goto frontend_detach;
- }
}
/* Get the first frontend */
@@ -1253,6 +1260,8 @@ static int cx8802_dvb_probe(struct cx880
struct cx88_core *core = drv->core;
struct cx8802_dev *dev = drv->core->dvbdev;
int err;
+ struct videobuf_dvb_frontend *fe;
+ int i;
dprintk( 1, "%s\n", __func__);
dprintk( 1, " ->being probed by Card=%d Name=%s, PCI %02x:%02x\n",
@@ -1268,39 +1277,34 @@ static int cx8802_dvb_probe(struct cx880
/* If vp3054 isn't enabled, a stub will just return 0 */
err = vp3054_i2c_probe(dev);
if (0 != err)
- goto fail_probe;
+ goto fail_core;
/* dvb stuff */
printk(KERN_INFO "%s/2: cx2388x based DVB/ATSC card\n", core->name);
dev->ts_gen_cntrl = 0x0c;
+ err = cx8802_alloc_frontends(dev);
+ if (err)
+ goto fail_core;
+
err = -ENODEV;
- if (core->board.num_frontends) {
- struct videobuf_dvb_frontend *fe;
- int i;
-
- for (i = 1; i <= core->board.num_frontends; i++) {
- fe =
videobuf_dvb_get_frontend(&core->dvbdev->frontends, i);
- if (fe == NULL) {
- printk(KERN_ERR "%s() failed to get
frontend(%d)\n",
+
Re: [PATCH] pwc: add support for webcam snapshot button (2)
Hi all
Maybe Linux Media team has not received my patch. I also CC'ed my former
email to linux-media mailing list, but it has been filtered out by Linux
Media mail server's policy for some reason, so I resend the patch.
*** PATCH BEGINS FROM HERE ***
This patch adds support for Philips webcam snapshot button as an
event input device, for consistency with other webcam drivers.
Signed-off-by: Pham Thanh Nam
diff -uNr a/linux/drivers/media/video/pwc/Kconfig
b/linux/drivers/media/video/pwc/Kconfig
--- a/linux/drivers/media/video/pwc/Kconfig 2009-01-03
20:03:43.0 +0700
+++ b/linux/drivers/media/video/pwc/Kconfig 2009-01-09
16:09:45.0 +0700
@@ -35,3 +35,13 @@
Say Y here in order to have the pwc driver generate verbose
debugging
messages.
A special module options 'trace' is used to control the verbosity.
+
+config USB_PWC_INPUT_EVDEV
+ bool "USB Philips Cameras input events device support"
+ default y
+ depends on USB_PWC && INPUT
+ ---help---
+ This option makes USB Philips cameras register the snapshot button
as
+ an input device to report button events.
+
+ If you are in doubt, say Y.
diff -uNr a/linux/drivers/media/video/pwc/pwc.h
b/linux/drivers/media/video/pwc/pwc.h
--- a/linux/drivers/media/video/pwc/pwc.h 2009-01-03 20:03:43.0
+0700
+++ b/linux/drivers/media/video/pwc/pwc.h 2009-01-09 17:06:04.0
+0700
@@ -38,6 +38,9 @@
#include
#include
#include
+#ifdef CONFIG_USB_PWC_INPUT_EVDEV
+#include
+#endif
#include "pwc-uncompress.h"
#include
@@ -256,6 +259,9 @@
int pan_angle; /* in degrees * 100 */
int tilt_angle; /* absolute angle; 0,0 is home position
*/
int snapshot_button_status; /* set to 1 when the user push the
button, reset to 0 when this value is read */
+#ifdef CONFIG_USB_PWC_INPUT_EVDEV
+ struct input_dev *button_dev; /* webcam snapshot button input */
+#endif
/*** Misc. data ***/
wait_queue_head_t frameq; /* When waiting for a frame to finish...
*/
diff -uNr a/linux/drivers/media/video/pwc/pwc-if.c
b/linux/drivers/media/video/pwc/pwc-if.c
--- a/linux/drivers/media/video/pwc/pwc-if.c2009-01-03
20:03:43.0 +0700
+++ b/linux/drivers/media/video/pwc/pwc-if.c2009-01-10
11:26:44.0 +0700
@@ -53,6 +53,7 @@
- Xavier Roche: QuickCam Pro 4000 ID
- Jens Knudsen: QuickCam Zoom ID
- J. Debert: QuickCam for Notebooks ID
+ - Pham Thanh Nam: webcam snapshot button as an event input device
*/
#include
@@ -61,6 +62,13 @@
#include
#include
#include
+#ifdef CONFIG_USB_PWC_INPUT_EVDEV
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 18)
+#include
+#else
+#include
+#endif
+#endif
#include
#include
#include
@@ -587,6 +595,23 @@
pdev->vframe_count);
}
+static void pwc_snapshot_button(struct pwc_device *pdev, int down)
+{
+ if (down) {
+ PWC_TRACE("Snapshot button pressed.\n");
+ pdev->snapshot_button_status = 1;
+ } else {
+ PWC_TRACE("Snapshot button released.\n");
+ }
+
+#ifdef CONFIG_USB_PWC_INPUT_EVDEV
+ if (pdev->button_dev) {
+ input_report_key(pdev->button_dev, BTN_0, down);
+ input_sync(pdev->button_dev);
+ }
+#endif
+}
+
static int pwc_rcv_short_packet(struct pwc_device *pdev, const struct
pwc_frame_buf *fbuf)
{
int awake = 0;
@@ -604,13 +629,7 @@
pdev->vframes_error++;
}
if ((ptr[0] ^ pdev->vmirror) & 0x01) {
- if (ptr[0] & 0x01) {
- pdev->snapshot_button_status = 1;
- PWC_TRACE("Snapshot button pressed.\n");
- }
- else {
- PWC_TRACE("Snapshot button released.\n");
- }
+ pwc_snapshot_button(pdev, ptr[0] & 0x01);
}
if ((ptr[0] ^ pdev->vmirror) & 0x02) {
if (ptr[0] & 0x02)
@@ -634,12 +653,7 @@
else if (pdev->type == 740 || pdev->type == 720) {
unsigned char *ptr = (unsigned char *)fbuf->data;
if ((ptr[0] ^ pdev->vmirror) & 0x01) {
- if (ptr[0] & 0x01) {
- pdev->snapshot_button_status = 1;
- PWC_TRACE("Snapshot button pressed.\n");
- }
- else
- PWC_TRACE("Snapshot button released.\n");
+ pwc_snapshot_button(pdev, ptr[0] & 0x01);
}
pdev->vmirror = ptr[0] & 0x03;
}
@@ -1221,6 +1235,15 @@
{
pwc_remove_sysfs_files(pdev->vdev);
video_unregister_device(pdev->vdev);
+
+#ifdef CONFIG_USB_PWC_INPUT_EVDEV
+ if (pdev->butto
Re: [patch] add video_nr module param to gspca
Hi. Jean-Francois Moine wrote: Looking at the video drivers, I found that only half of these ones have this parameter. Then, I think it should be better to remove it everywhere! OK, that might be a solution too. :) In fact, setting the video number in the right driver before plugging any video device is rather complicated while setting udev rules is easy and has to be done only once... No, its not like that. You only add the strings like options gspca video_nr=1 in your /etc/modprobe.conf, and you are done. ALSA went even further and introduced the option "order", so that you write: options snd order=snd-intel8x0,snd-hda-intel for example. So, from some point of view, this is actually easier than the udev solution (eg. I always did that and never played with udev :), but indeed, having two ways of doing the same thing is usually confusing, so I am not trying to talk you into applying my patch. :) If there is an intention to deprecate the "video_nr" thing, then it certainly doesn't apply. -- 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb
On Sun, Jan 4, 2009 at 7:54 PM, Andy Walls wrote: > Mauro, > > Adding one more to my pull request. > > Please pull from: > > http://linuxtv.org/hg/~awalls/v4l-dvb > > for the following changes: > > cx18: Fix bad audio in first analog capture. > cx18, cx2341x: Fix bugs in cx18 AC3 control and comply with V4L2 spec > cx18, cx2341x, ivtv: Add AC-3 audio encoding control to cx18 > cx18: Additional debug to display outgoing mailbox parameters > cx18: Fix a PLL divisor update for the I2S master clock > > Regards, > Andy > > diffstat: > drivers/media/video/cx18/cx18-av-firmware.c |4 - > drivers/media/video/cx18/cx18-driver.c | 19 - > drivers/media/video/cx18/cx18-driver.h |2 > drivers/media/video/cx18/cx18-fileops.c |8 +- > drivers/media/video/cx18/cx18-mailbox.c | 46 +--- > drivers/media/video/cx18/cx23418.h | 16 > drivers/media/video/cx2341x.c | 101 > ++-- > drivers/media/video/ivtv/ivtv-driver.h |2 > drivers/media/video/ivtv/ivtv-fileops.c |8 +- > include/media/cx2341x.h |6 + > 10 files changed, 175 insertions(+), 37 deletions(-) > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Andy, I don't think these changes were ever merged in. I noticed newer activity in your dev tree though since this request. Is it safe to grab that as well, or should I go back to this date? Thanks, Brandon -- 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] cx88-dvb: Fix order of frontend allocations (Re: [linux-dvb] current v4l-dvb - cannot access /dev/dvb/: No such file or directory)
Andy Walls wrote:
On Fri, 2009-01-09 at 15:40 +0300, Goga777 wrote:
hI
With today v4l-dvb I couldn't run my hvr4000 card on 2.6.27 kernel
[ 14.555162] cx88/2: cx2388x dvb driver version 0.0.6 loaded
[ 14.555231] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 14.555303] cx88[0]/2: subsystem: 0070:6900, board: Hauppauge WinTV-HVR4000
DVB-S/S2/T/Hybrid [card=68]
[ 14.555374] cx88[0]/2: cx2388x based DVB/ATSC card
[ 14.555446] BUG: unable to handle kernel NULL pointer dereference at
[ 14.60] IP: [] __mutex_lock_common+0x3c/0xe4
[ 14.555652] *pde =
[ 14.555735] Oops: 0002 [#1] SMP
[ 14.555851] Modules linked in: cx88_dvb(+) cx88_vp3054_i2c videobuf_dvb
wm8775 dvb_core tuner_simple tuner_types snd_seq_dummy tda9887 snd_seq_oss(+)
snd_intel8x0(+) tda8290 snd_seq_midi snd_seq_midi_event snd_ac97_codec
cx88_alsa(+) snd_seq ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_rawmidi
snd_timer tuner snd_seq_device psmouse snd serio_raw ivtv(+) cx8800 cx8802
cx88xx soundcore cx2341x ir_common ns558 i2c_i801 v4l2_common videodev
i2c_algo_bit gameport v4l1_compat snd_page_alloc tveeprom pcspkr floppy
videobuf_dma_sg videobuf_core btcx_risc i2c_core parport_pc parport button
intel_agp agpgart shpchp pci_hotplug rng_core iTCO_wdt sd_mod evdev usbhid hid
ff_memless ext3 jbd mbcache ide_cd_mod cdrom ide_disk ata_piix libata dock
8139too usb_storage scsi_mod piix 8139cp mii ide_co
re uhci_hcd ehci_hcd usbcore thermal processor fan thermal_sys
[ 14.557013]
[ 14.557013] Pid: 2310, comm: modprobe Not tainted (2.6.27.1-custom-default1
#1)
[ 14.557013] EIP: 0060:[] EFLAGS: 00010246 CPU: 1
[ 14.557013] EIP is at __mutex_lock_common+0x3c/0xe4
[ 14.557013] EAX: de653e98 EBX: de739118 ECX: de739120 EDX:
[ 14.557013] ESI: dd4209e0 EDI: de73911c EBP: de653eb0 ESP: de653e88
[ 14.557013] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 14.557013] Process modprobe (pid: 2310, ti=de652000 task=dd4209e0
task.ti=de652000)
[ 14.557013] Stack: 3535352e 5d343733 0002 de739120 de739120
c044a6c0 de739110
[ 14.557013]de739118 0001 de653ebc c02e6d38 c02e6b88 de653ec4
c02e6b88 de653ed8
[ 14.557013]e1ac7115 de6a9000 0001 de653f0c e1aeca62
de739004 de739000
[ 14.557013] Call Trace:
[ 14.557013] [] ? __mutex_lock_slowpath+0x17/0x1a
[ 14.557013] [] ? mutex_lock+0x12/0x14
[ 14.557013] [] ? mutex_lock+0x12/0x14
[ 14.557013] [] ? videobuf_dvb_get_frontend+0x19/0x40
[videobuf_dvb]
[ 14.557013] [] ? cx8802_dvb_probe+0xc9/0x1945 [cx88_dvb]
[ 14.557013] [] ? cx8802_register_driver+0xbd/0x1ac [cx8802]
[ 14.557013] [] ? cx8802_register_driver+0x106/0x1ac [cx8802]
[ 14.557013] [] ? dvb_init+0x22/0x27 [cx88_dvb]
[ 14.557013] [] ? _stext+0x42/0x11a
[ 14.557013] [] ? dvb_init+0x0/0x27 [cx88_dvb]
[ 14.557013] [] ? __blocking_notifier_call_chain+0xe/0x51
[ 14.557013] [] ? sys_init_module+0x8c/0x17d
[ 14.557013] [] ? syscall_call+0x7/0xb
[ 14.557013] [] ? round_jiffies_relative+0x14/0x16
[ 14.557013] ===
[ 14.557013] Code: 78 04 89 f8 89 55 e0 64 8b 35 00 30 3f c0 e8 2e 0c 00 00 8d 43
08 89 45 e4 8b 53 0c 8d 45 e8 8b 4d e4 89 43 0c 89 4d e8 89 55 ec <89> 02 89 75
f0 83 c8 ff 87 03 48 74 55 8a 45 e0 8b 4d e0 83 e0
[ 14.557013] EIP: [] __mutex_lock_common+0x3c/0xe4 SS:ESP
0068:de653e88
[ 14.565211] ---[ end trace 94d8b014e067ac7b ]---
I don't have the hardware to test with. Please try this patch.
Regards,
Andy
Hi
I got the same error on my box with a hvr4000 and tt3200.
This path solved this issue for me.
--
pierre
Signed-off-by: Andy Walls
diff -r a28c39659c25 linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c Sat Jan 10 16:04:45 2009 -0500
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c Sun Jan 11 19:13:10 2009 -0500
@@ -621,33 +621,40 @@ static struct stv0288_config tevii_tuner
.set_ts_params = cx24116_set_ts_param,
};
+static int cx8802_alloc_frontends(struct cx8802_dev *dev)
+{
+ struct cx88_core *core = dev->core;
+ struct videobuf_dvb_frontend *fe = NULL;
+ int i;
+
+ mutex_init(&dev->frontends.lock);
+ INIT_LIST_HEAD(&dev->frontends.felist);
+
+ if (!core->board.num_frontends)
+ return -ENODEV;
+
+ printk(KERN_INFO "%s() allocating %d frontend(s)\n", __func__,
+core->board.num_frontends);
+ for (i = 1; i <= core->board.num_frontends; i++) {
+ fe = videobuf_dvb_alloc_frontend(&dev->frontends, i);
+ if (!fe) {
+ printk(KERN_ERR "%s() failed to alloc\n", __func__);
+ videobuf_dvb_dealloc_frontends(&dev->frontends);
+ return -ENOMEM;
+ }
+ }
+ return 0;
+}
+
static int dvb_register(struct cx8802_dev *dev)
{
struct cx88_core *core = dev->core;
struct video
Re: FM transmitter support under v4l2?
Hi Mauro, >> >> FYI..now maemo kernel team seems to have written Si4713 FM transmitter >> driver interfaced over I2C. It is available in the kernel diff here. >> >> http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.27-20084805r03.diff.gz >> >> Please download and unzip it and search for >> >> radio-si4713.c > > Hi Trilok. Thanks for pointing us for the driver. > > The driver seems interesting, but I see a few issues with their approach: > > 1) it is creating a sysfs API for controlling some of the characteristics of > the radio. Public API's should be discussed with enough care at > linux-media@vger.kernel.org before their addition on a driver, and properly > documented. Also, IMO, the better would be to use VIDIOC_[G|C]_CTRL calls for > this, or to create another ioctl for handling FM transmission; Yes, I came across it. It might be because Eduardo just want's to make it functional and didn't had much time to communicate with community while making next Nokia Internet Table work with this chip. I can see that you have CCed him, and he might want to start the interaction now to formalize the FM transmitter related controls/APIs. > > 2) a V4L2 application has no means to determine that the device is a FM > transmission device. We need to add some capability flags to inform this to > userspace. > Right, a formal cap flag is good. I don't have access to such in-development Nokia device, and Eduardo can help us here to send a patch. > While there, I noticed also a driver for radio-tea5761 and a patch for > common/tuners/tea5761.c. This also deserves review at > linux-me...@vger.kernel.org. > I need to look at this in the diff. Thanks for the review. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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
