Re: [patch 2/7] drivers/media/video/pms.c needs version.h
a...@linux-foundation.org wrote: From: Andrew Morton a...@linux-foundation.org i386 allmodconfig: drivers/media/video/pms.c: In function 'pms_querycap': drivers/media/video/pms.c:682: error: implicit declaration of function 'KERNEL_VERSION' @@ -24,6 +24,7 @@ #include linux/delay.h #include linux/errno.h #include linux/fs.h +#include linux/version.h #include linux/kernel.h #include linux/slab.h #include linux/mm.h Hmm... changeset feba2f81 already added linux/version.h: @@ -27,20 +29,21 @@ #include linux/mm.h #include linux/ioport.h #include linux/init.h +#include linux/version.h +#include linux/mutex.h +#include asm/uaccess.h #include asm/io.h ... So I think this patch got obsoleted. 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: [patch 1/7] drivers/media/video: move dereference after NULL test
Hi Julia,
From: Julia Lawall ju...@diku.dk
diff -puN
drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/davinci/vpif_display.c
---
a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/davinci/vpif_display.c
@@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
- return -1;
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
IMO, the better would be to move the if to happen before the usage of std_info,
and make it return
a proper error code, instead of -1.
Murali,
Any comments?
diff -puN
drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/saa7134/saa7134-alsa.c
---
a/drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(sn
unsigned int idx;
int err, addr;
- if (snd_BUG_ON(!chip))
- return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
The better here is to keep the BUG_ON and moving this initialization:
struct snd_card *card = chip-card;
to happen after the test.
for (idx = 0; idx ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff -puN
drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/usbvideo/quickcam_messenger.c
---
a/drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uv
static void qcm_stop_data(struct uvd *uvd)
{
- struct qcm *cam = (struct qcm *) uvd-user_data;
+ struct qcm *cam;
int i, j;
int ret;
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+ cam = (struct qcm *) uvd-user_data;
ret = qcm_camera_off(uvd);
if (ret)
OK.
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: [PATCH v2 00/10] add linux driver for chip TLG2300
Instead of a country code, the driver should use the V4L2_STD_ macros to If we are in the radio mode, I do not have any video standard, how can I choose the right audio setting in this situation? In the case of radio, the frequency ranges are controlled via the tuner Do you mean that the frequency range can be used to set the pre-emphasis? I am not sure about this. ioctls. There's no standard way to control the preemphasis, but I recommend adding a ctrl to select between 50us/75us and no preemphasis. Best Regards Huang Shijie -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2.1 0/2] Mem-to-mem device framework
Hiremath, Vaibhav wrote: -Original Message- From: Pawel Osciak [mailto:p.osc...@samsung.com] Sent: Monday, December 28, 2009 8:19 PM To: 'Hans Verkuil' Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Marek Szyprowski; kyungmin.p...@samsung.com; Hiremath, Vaibhav; Karicheri, Muralidharan; 'Guru Raj'; 'Xiaolin Zhang'; 'Magnus Damm'; 'Sakari Ailus' Subject: RE: [PATCH/RFC v2.1 0/2] Mem-to-mem device framework Hello Hans, On Wednesday 23 December 2009 16:06:18 Hans Verkuil wrote: Thank you for working on this! It's much appreciated. Now I've noticed that patches regarding memory-to-memory and memory pool tend to get very few comments. I suspect that the main reason is that these are SoC-specific features that do not occur in consumer-type products. So most v4l developers do not have the interest and motivation (and time!) to look into this. Thank you very much for your response. We were a bit surprised with the lack of responses as there seemed to be a good number of people interested in this area. I'm hoping that everybody interested would take a look at the test device posted along with the patches. It's virtual, no specific hardware required, but it demonstrates the concepts behind the framework, including transactions. [Hiremath, Vaibhav] I was on vacation and resumed today itself, I will go through these patch series this weekend and will get back to you. I just had cursory look and I would say it should be really good starting point for us to support mem-to-mem devices.\ Hmm... it seems to me that those patches are still under discussion/analysis. I'll mark them as RFC at the Patchwork. Please let me know after you, SoC guys, go into a consensus about it. Then, please submit me the final version. 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: [PATCH v2 00/10] add linux driver for chip TLG2300
Huang Shijie wrote:
Instead of a country code, the driver should use the V4L2_STD_
macros to
If we are in the radio mode, I do not have any video standard, how can I
choose
the right audio setting in this situation?
In the case of radio, the frequency ranges are controlled via the tuner
Do you mean that the frequency range can be used to set the pre-emphasis?
I am not sure about this.
No, I don't meant that.
The differences of FM radio standards are basically the preemphasis and the
frequency ranges.
For frequency ranges, V4L2_TUNER_RADIO allows specifying the maximum/minimum
values.
For preemphasis, you should implement V4L2_CID_TUNE_PREEMPHASIS ctrl. This
CTRL has 3 states:
static const char *tune_preemphasis[] = {
No preemphasis,
50 useconds,
75 useconds,
NULL,
};
At v4l2-common.c, there are some functions that helps to implement it
at the driver, like:
v4l2_ctrl_get_menu, v4l2_ctrl_get_name and v4l2_ctrl_query_fill.
Take a look at si4713-i2c.c for an example on how to use it.
Ah, please submit those changes as another series of patches. This helps me
to not needing to review the entire changeset again.
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: [PATCH v2 00/10] add linux driver for chip TLG2300
The differences of FM radio standards are basically the preemphasis and the
frequency ranges.
For frequency ranges, V4L2_TUNER_RADIO allows specifying the maximum/minimum
values.
For preemphasis, you should implement V4L2_CID_TUNE_PREEMPHASIS ctrl. This
CTRL has 3 states:
static const char *tune_preemphasis[] = {
No preemphasis,
50 useconds,
75 useconds,
NULL,
};
At v4l2-common.c, there are some functions that helps to implement it
at the driver, like:
v4l2_ctrl_get_menu, v4l2_ctrl_get_name and v4l2_ctrl_query_fill.
Take a look at si4713-i2c.c for an example on how to use it.
Thanks you very much for the explanation.
Ah, please submit those changes as another series of patches. This helps me
to not needing to review the entire changeset again.
Ok. no problem.
Cheers,
Mauro
Best Regards
Huang Shijie
--
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] mfd: Add support for the timberdale FPGA.
Hi Richard,
Richard Röjfors wrote:
The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
board
russelville.
The driver is a PCI driver which chunks up the I/O memory and distributes
interrupts
to a number of platform devices for each IP inside the FPGA.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
I'm not sure how to deal with this patch. It doesn't contain anything related
to V4L2 inside it, nor it applies to drivers/media, but it depends on the
radio-timb
driver that you submitted us.
As this patch will be committed at mfd tree, the better is if Samuel can review
this patch and give his ack. I'll add it together with the V4L2 driver and
submit them
via my tree.
Samuel,
Would this way work for you?
Cheers,
Mauro.
---
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8782978..f92673b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -348,6 +348,17 @@ config AB4500_CORE
read/write functions for the devices to get access to this chip.
This chip embeds various other multimedia funtionalities as well.
+config MFD_TIMBERDALE
+ tristate Support for the Timberdale FPGA
+ select MFD_CORE
+ depends on PCI
+ ---help---
+ This is the core driver for the timberdale FPGA. This device is a
+ multifunction device which exposes numerous platform devices.
+
+ The timberdale FPGA can be found on the Intel Atom development board
+ for in-vehicle infontainment, called Russellville.
+
endmenu
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e09eb48..53375ac 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -55,4 +55,6 @@ obj-$(CONFIG_AB3100_CORE) += ab3100-core.o
obj-$(CONFIG_AB3100_OTP) += ab3100-otp.o
obj-$(CONFIG_AB4500_CORE)+= ab4500-core.o
obj-$(CONFIG_MFD_88PM8607) += 88pm8607.o
-obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
\ No newline at end of file
+obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
+
+obj-$(CONFIG_MFD_TIMBERDALE) += timberdale.o
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
new file mode 100644
index 000..90f745b
--- /dev/null
+++ b/drivers/mfd/timberdale.c
@@ -0,0 +1,667 @@
+/*
+ * timberdale.c timberdale FPGA MFD driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/mfd/core.h
+
+#include linux/timb_gpio.h
+
+#include linux/i2c.h
+#include linux/i2c-ocores.h
+#include linux/i2c/tsc2007.h
+
+#include linux/spi/spi.h
+#include linux/spi/xilinx_spi.h
+#include linux/spi/max7301.h
+#include linux/spi/mc33880.h
+
+#include timberdale.h
+
+#define DRIVER_NAME timberdale
+
+struct timberdale_device {
+ resource_size_t ctl_mapbase;
+ unsigned char __iomem *ctl_membase;
+ struct {
+ u32 major;
+ u32 minor;
+ u32 config;
+ } fw;
+};
+
+/*--*/
+
+static struct tsc2007_platform_data timberdale_tsc2007_platform_data = {
+ .model = 2003,
+ .x_plate_ohms = 100
+};
+
+static struct i2c_board_info timberdale_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO(tsc2007, 0x48),
+ .platform_data = timberdale_tsc2007_platform_data,
+ .irq = IRQ_TIMBERDALE_TSC_INT
+ },
+};
+
+static __devinitdata struct ocores_i2c_platform_data
+timberdale_ocores_platform_data = {
+ .regstep = 4,
+ .clock_khz = 62500,
+ .devices = timberdale_i2c_board_info,
+ .num_devices = ARRAY_SIZE(timberdale_i2c_board_info)
+};
+
+const static __devinitconst struct resource timberdale_ocores_resources[] = {
+ {
+ .start = OCORESOFFSET,
+ .end= OCORESEND,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_TIMBERDALE_I2C,
+ .end= IRQ_TIMBERDALE_I2C,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+const struct max7301_platform_data timberdale_max7301_platform_data = {
+ .base = 200
+};
+
+const struct
Re: [PATCH] mfd: Add support for the timberdale FPGA.
On 02/03/2010 10:16 AM, Mauro Carvalho Chehab wrote: Hi Richard, Richard Röjfors wrote: The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference board russelville. The driver is a PCI driver which chunks up the I/O memory and distributes interrupts to a number of platform devices for each IP inside the FPGA. Signed-off-by: Richard Röjforsrichard.rojf...@pelagicore.com I'm not sure how to deal with this patch. It doesn't contain anything related to V4L2 inside it, nor it applies to drivers/media, Sorry my address book tricked me. I was suppose to send it to LKML not the Media mailing list. I will resend the patch with the correct addresses in it. but it depends on the radio-timb driver that you submitted us. Actually this MFD has more devices than in the current patch. These will be incrementally added when the corresponding drivers goes into the kernel. Sorry for the inconvenience. --Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New DVB-Statistics API - please vote
Mauro Carvalho Chehab wrote: after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options Only me and Manu manifested with opinions on this thread. Not sure why nobody else gave their comments. Maybe all interested people just decided to take a long vacation and are not listening to their emails ;) Seriously, from what I understand, this is an API improvement and we need to take a decision on it. So, your opinions are important. --- Let me draw a summary of this subject, trying to be impartial. The original proposal were made by Manu. My proposal is derived from Manu's original one, both will equally provide the same features. The main difference is that Manu's proposal use a struct to get the statistics while my proposal uses DVBS2API. With both API proposals, all values are get at the same time by the driver. the DVBS2API adds a small delay to fill the fields, but the extra delay is insignificant, when compared with the I/O delays needed to retrieve the values from the hardware. Due to the usage of DVBS2API, it is possible to retrieve a subset of statistics. When obtaining a subset, the DVBS2API latency is considerable faster, as less data needed to be transfered from the hardware. The DVBS2API also offers the possibility of expanding the statistics group, since it is not rigid as an struct. One criteria that should be reminded is that, according with Linux Kernel rules, any userspace API is stable. This means that applications compiled against an older API version should keep running with the latest kernel. So, whatever decided, the statistics API should always maintain backward compatibility. --- During the end of the year, I did some work with an ISDB-T driver for Siano, and I realized that the usage of the proposed struct won't fit well for ISDB-T. The reason is that, on ISDB-T, the transmission uses up to 3 hierarchical layers. Each layer may have different OFDM parameters, so the devices (at least, this is the case for Siano) has a group of statistics per layer. I'm afraid that newer standards may also bring different ways to present statistics, and the current proposal won't fit well. So, in my opinion, if it is chosen any struct-based approach, we'll have a bad time to maintain it, as it won't fit into all cases, and we'll need to add some tricks to extend the struct. So, my vote is for the DVBS2API approach, where a new group of statistics can easily be added, on an elegant way, without needing of re-discussing the better API or to find a way to extend the size of an struct without breaking backward compatibility. 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: [PATCH] mfd: Add support for the timberdale FPGA.
Richard Röjfors wrote: On 02/03/2010 10:16 AM, Mauro Carvalho Chehab wrote: Hi Richard, Richard Röjfors wrote: The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference board russelville. The driver is a PCI driver which chunks up the I/O memory and distributes interrupts to a number of platform devices for each IP inside the FPGA. Signed-off-by: Richard Röjforsrichard.rojf...@pelagicore.com I'm not sure how to deal with this patch. It doesn't contain anything related to V4L2 inside it, nor it applies to drivers/media, Sorry my address book tricked me. I was suppose to send it to LKML not the Media mailing list. I will resend the patch with the correct addresses in it. but it depends on the radio-timb driver that you submitted us. Actually this MFD has more devices than in the current patch. These will be incrementally added when the corresponding drivers goes into the kernel. Ah, ok. Sorry for the inconvenience. No problem. -- 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: [PATCH v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
Hans Verkuil wrote: On Wednesday 27 January 2010 17:22:10 Richard Röjfors wrote: This patch adds radio-timb to the Makefile and Kconfig. +config RADIO_TIMBERDALE +tristate Enable the Timberdale radio driver +depends on MFD_TIMBERDALE VIDEO_V4L2 HAS_IOMEM I think you need a dependency on I2C as well. It is not needed. VIDEO_V4L2 already takes care of properly handling it. -- 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: [PATCH v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
Richard Röjfors wrote: This patch adds radio-timb to the Makefile and Kconfig. On your next submission, please fold with patch 1/2. Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com --- diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 3f40f37..46fd8c4 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -429,4 +429,14 @@ config RADIO_TEF6862 To compile this driver as a module, choose M here: the module will be called TEF6862. +config RADIO_TIMBERDALE + tristate Enable the Timberdale radio driver + depends on MFD_TIMBERDALE VIDEO_V4L2 HAS_IOMEM + select RADIO_TEF6862 + select RADIO_SAA7706H + ---help--- + This is a kind of umbrella driver for the Radio Tuner and DSP + found behind the Timberdale FPGA on the Russellville board. + Enable this driver will automatically select the DSP and tuner. + endif # RADIO_ADAPTERS diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index 01922ad..8973850 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/ obj-$(CONFIG_USB_MR800) += radio-mr800.o obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o +obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o EXTRA_CFLAGS += -Isound -- 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 -- 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: [PATCH] mfd: Add support for the timberdale FPGA.
Hi Mauro,
On Wed, Feb 03, 2010 at 09:16:07AM +, Mauro Carvalho Chehab wrote:
Hi Richard,
Richard Röjfors wrote:
The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
board
russelville.
The driver is a PCI driver which chunks up the I/O memory and distributes
interrupts
to a number of platform devices for each IP inside the FPGA.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
I'm not sure how to deal with this patch. It doesn't contain anything related
to V4L2 inside it, nor it applies to drivers/media, but it depends on the
radio-timb
driver that you submitted us.
Actually, there are no build dependencies between those 2 drivers, which is
very good.
As this patch will be committed at mfd tree, the better is if Samuel can
review
this patch and give his ack. I'll add it together with the V4L2 driver and
submit them
via my tree.
I'm going to review this patch right now. Typically, mfd core drivers and
their subdevices are submitted as a patchset via my tree, because the
subdevices drivers have dependencies with the core. The mfd core driver is
submitted without any dependencies, and then when the subdevices drivers are
submitted, we add relevant code to the mfd driver. This way we prevent any
build breakage or bisection mess.
The timberdale chip right now doesnt depend on anything, but will soon depend
on the radio driver that's on your tree, but also on a sound and on a network
driver. You'd have to take all those if Richard wants to push them right now.
So, what I propose is to take the timberdale mfd core driver and the radio
one, with your SOB. Then when Richard wants to submit additional subdevices
drivers I'll be able to take them and we'll avoid polluting your tree with non
media related drivers. Does that make sense to you ?
Cheers,
Samuel.
Samuel,
Would this way work for you?
Cheers,
Mauro.
---
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8782978..f92673b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -348,6 +348,17 @@ config AB4500_CORE
read/write functions for the devices to get access to this chip.
This chip embeds various other multimedia funtionalities as well.
+config MFD_TIMBERDALE
+ tristate Support for the Timberdale FPGA
+ select MFD_CORE
+ depends on PCI
+ ---help---
+ This is the core driver for the timberdale FPGA. This device is a
+ multifunction device which exposes numerous platform devices.
+
+ The timberdale FPGA can be found on the Intel Atom development board
+ for in-vehicle infontainment, called Russellville.
+
endmenu
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e09eb48..53375ac 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -55,4 +55,6 @@ obj-$(CONFIG_AB3100_CORE) += ab3100-core.o
obj-$(CONFIG_AB3100_OTP) += ab3100-otp.o
obj-$(CONFIG_AB4500_CORE)+= ab4500-core.o
obj-$(CONFIG_MFD_88PM8607) += 88pm8607.o
-obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
\ No newline at end of file
+obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
+
+obj-$(CONFIG_MFD_TIMBERDALE) += timberdale.o
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
new file mode 100644
index 000..90f745b
--- /dev/null
+++ b/drivers/mfd/timberdale.c
@@ -0,0 +1,667 @@
+/*
+ * timberdale.c timberdale FPGA MFD driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/mfd/core.h
+
+#include linux/timb_gpio.h
+
+#include linux/i2c.h
+#include linux/i2c-ocores.h
+#include linux/i2c/tsc2007.h
+
+#include linux/spi/spi.h
+#include linux/spi/xilinx_spi.h
+#include linux/spi/max7301.h
+#include linux/spi/mc33880.h
+
+#include timberdale.h
+
+#define DRIVER_NAME timberdale
+
+struct timberdale_device {
+ resource_size_t ctl_mapbase;
+ unsigned char __iomem *ctl_membase;
+ struct {
+ u32 major;
+ u32 minor;
+ u32 config;
+ } fw;
Re: [PATCH] mfd: Add support for the timberdale FPGA.
Samuel Ortiz wrote: I'm not sure how to deal with this patch. It doesn't contain anything related to V4L2 inside it, nor it applies to drivers/media, but it depends on the radio-timb driver that you submitted us. Actually, there are no build dependencies between those 2 drivers, which is very good. Yes, it is great. As this patch will be committed at mfd tree, the better is if Samuel can review this patch and give his ack. I'll add it together with the V4L2 driver and submit them via my tree. I'm going to review this patch right now. Typically, mfd core drivers and their subdevices are submitted as a patchset via my tree, because the subdevices drivers have dependencies with the core. The mfd core driver is submitted without any dependencies, and then when the subdevices drivers are submitted, we add relevant code to the mfd driver. This way we prevent any build breakage or bisection mess. The drivers at media are generally very complex with dependencies on several other subsystems. In general, almost all depends on i2c, alsa and input, and an increasing number of drivers has also dependencies with platform_data added at arch-dependent includes/drivers. Yet, this specific driver is simple. I generally tend to add those drivers via my tree, since it is generally simpler to prevent breakage/bisection troubles, but it is also ok for me if you want to add them via your tree, after I get my ack. The timberdale chip right now doesnt depend on anything, but will soon depend on the radio driver that's on your tree, but also on a sound and on a network driver. You'd have to take all those if Richard wants to push them right now. There were one or two minor changes requested on radio-timb patchset. After that changes, we're ready to merge it. So, what I propose is to take the timberdale mfd core driver and the radio one, with your SOB. Then when Richard wants to submit additional subdevices drivers I'll be able to take them and we'll avoid polluting your tree with non media related drivers. Does that make sense to you ? Yes, it does. I don't think Richard is urging with those patches, so my idea is to keep them for linux-next. It would equally work for me if you add the patches on your tree after my ack. The only merge conflicts we may expect from V4L side are related to Kconfig/Makefile, and those will be easy to fix during the merge period. -- 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: New DVB-Statistics API - please vote
Mauro Carvalho Chehab wrote: after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options Only me and Manu manifested with opinions on this thread. Not sure why nobody else gave their comments. Maybe all interested people just decided to take a long vacation and are not listening to their emails ;) Seriously, from what I understand, this is an API improvement and we need to take a decision on it. So, your opinions are important. --- Let me draw a summary of this subject, trying to be impartial. The original proposal were made by Manu. My proposal is derived from Manu's original one, both will equally provide the same features. The main difference is that Manu's proposal use a struct to get the statistics while my proposal uses DVBS2API. With both API proposals, all values are get at the same time by the driver. the DVBS2API adds a small delay to fill the fields, but the extra delay is insignificant, when compared with the I/O delays needed to retrieve the values from the hardware. Due to the usage of DVBS2API, it is possible to retrieve a subset of statistics. When obtaining a subset, the DVBS2API latency is considerable faster, as less data needed to be transfered from the hardware. The DVBS2API also offers the possibility of expanding the statistics group, since it is not rigid as an struct. One criteria that should be reminded is that, according with Linux Kernel rules, any userspace API is stable. This means that applications compiled against an older API version should keep running with the latest kernel. So, whatever decided, the statistics API should always maintain backward compatibility. --- During the end of the year, I did some work with an ISDB-T driver for Siano, and I realized that the usage of the proposed struct won't fit well for ISDB-T. The reason is that, on ISDB-T, the transmission uses up to 3 hierarchical layers. Each layer may have different OFDM parameters, so the devices (at least, this is the case for Siano) has a group of statistics per layer. I'm afraid that newer standards may also bring different ways to present statistics, and the current proposal won't fit well. So, in my opinion, if it is chosen any struct-based approach, we'll have a bad time to maintain it, as it won't fit into all cases, and we'll need to add some tricks to extend the struct. So, my vote is for the DVBS2API approach, where a new group of statistics can easily be added, on an elegant way, without needing of re-discussing the better API or to find a way to extend the size of an struct without breaking backward compatibility. From a purely technical standpoint the DVBS2API is by definition more flexible and future-proof. The V4L API has taken the same approach with controls (basically exactly the same mechanism). Should it be necessary in the future to set multiple properties atomically, then the same technique as V4L can be used (see VIDIOC_S_EXT_CTRLS). The alternative is to make structs with lots of reserved fields. It depends on how predictable the API is expected to be. Sometimes you can be reasonably certain that there won't be too many additions in the future and then using reserved fields is perfectly OK. Just my 5 cents based on my V4L experience. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [RESEND PATCH] ir-kbd-i2c: Allow to disable Hauppauge filter through module parameter
Hi Samuel,
Samuel Rakitnican wrote:
Some Hauppauge devices have id=0 so such devices won't work.
For such devices add a module parameter that allow to turn
off filtering.
Signed-off-by: Samuel Rakitničan semiroc...@gmail.com
Instead of a modprobe parameter, the proper fix is to make the usage of the
complete RC5 code received from this IR. This way, the handling of the
IR will depend only at the IR table used by the device.
Please take a look at the code at em28xx (seek for ir-full_code) to see
how to implement it.
Cheers,
Mauro.
---
diff -r 82bbb3bd0f0a linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cMon Jan 11 11:47:33 2010
-0200
+++ b/linux/drivers/media/video/ir-kbd-i2c.cSat Jan 16 16:39:14 2010
+0100
@@ -61,6 +61,10 @@
module_param(hauppauge, int, 0644);/* Choose Hauppauge remote */
MODULE_PARM_DESC(hauppauge, Specify Hauppauge remote: 0=black, 1=grey
(defaults to 0));
+static int haup_filter = 1;
+module_param(haup_filter, int, 0644);
+MODULE_PARM_DESC(haup_filter, Hauppauge filter for other remotes,
default is 1 (On));
+
#define DEVNAME ir-kbd-i2c
#define dprintk(level, fmt, arg...)if (debug = level) \
@@ -96,24 +100,27 @@
if (!start)
/* no key pressed */
return 0;
-/*
- * Hauppauge remotes (black/silver) always use
- * specific device ids. If we do not filter the
- * device ids then messages destined for devices
- * such as TVs (id=0) will get through causing
- * mis-fired events.
- *
- * We also filter out invalid key presses which
- * produce annoying debug log entries.
- */
-ircode= (start 12) | (toggle 11) | (dev 6) | code;
-if ((ircode 0x1fff)==0x1fff)
-/* invalid key press */
-return 0;
-if (dev!=0x1e dev!=0x1f)
-/* not a hauppauge remote */
-return 0;
+if (haup_filter != 0) {
+/*
+ * Hauppauge remotes (black/silver) always use
+ * specific device ids. If we do not filter the
+ * device ids then messages destined for devices
+ * such as TVs (id=0) will get through causing
+ * mis-fired events.
+ *
+ * We also filter out invalid key presses which
+ * produce annoying debug log entries.
+ */
+ircode = (start 12) | (toggle 11) | (dev 6) | code;
+if ((ircode 0x1fff) == 0x1fff)
+/* invalid key press */
+return 0;
+
+if (dev != 0x1e dev != 0x1f)
+/* not a hauppauge remote */
+return 0;
+}
if (!range)
code += 64;
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hans Verkuil wrote: Hi Mauro, On Fri, 29 Jan 2010, Hans Verkuil wrote: (resent: forgot to mail it to the linux-media list) Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - saa7134: remove stray unlock_kernel This is a high-prio bugfix that must go to 2.6.33! Dmitri, this patch will fix the kernel oops in your latest stack trace. Just to remind you: When will this regression fix be merged? It is important that this is sent upstream for 2.6.33! Sent today. I need to wait for a couple days between the -git merge and sending upstream, to allow the patch to go to linux-next. 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: [HG PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-bug
Andy Walls wrote: On Mon, 2010-02-01 at 16:45 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: Mauro, Please pull from http://linuxtv.org/hg/~awalls/v4l-dvb-bug for the following 5 *high priority* changesets: Hmm... I don't think cx18 alsa code went to 2.3.33. That may explain why they got rejected at fixes.git tree: Hmmm. Aorry for the confusion. I thought the cx18-alsa patches had gone. If some of the patches need to go to the fixes.git tree, please rebase them against the tree and send me a new pull request. Otherwise, please let me know for me to apply at the patches for 2.6.34. These patches only need to go with the cx18-alsa patches - wherever they are. Ok. I added them at the normal tree. As for me using git: I'm supposed to be getting cable Internet service Wednesday of this week. (Ha! I don't think the cable company will be laying cable in 10 inches of snow.) When I do get hooked up, I'll plan on moving to git. Well, except for the snow, that's good news! 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: [patch 1/7] drivers/media/video: move dereference after NULL test
On Wed, 3 Feb 2010, Mauro Carvalho Chehab wrote:
Hi Julia,
From: Julia Lawall ju...@diku.dk
diff -puN
drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
drivers/media/video/davinci/vpif_display.c
---
a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/davinci/vpif_display.c
@@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
int index;
std_info-stdid = vid_ch-stdid;
- if (!std_info)
- return -1;
for (index = 0; index ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
IMO, the better would be to move the if to happen before the usage of
std_info, and make it return
a proper error code, instead of -1.
The initializations are as follows:
static int vpif_get_std_info(struct channel_obj *ch)
{
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
struct video_obj *vid_ch = ch-video;
struct vpif_params *vpifparams = ch-vpifparams;
struct vpif_channel_config_params *std_info = vpifparams-std_info;
While std_info could be an invalid address, I don't think it would be
likely to be NULL. An option would be to test whether ch is NULL. But
the function is static, and at all of the call sites either ch or a
pointer derived from it has already been dereferenced, so perhaps the test
is not necessary.
julia
--
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/~jfrancois/v4l-dvb/
Hans de Goede wrote: Hi, On 02/01/2010 07:36 PM, Mauro Carvalho Chehab wrote: Jean-Francois Moine wrote: Hi Douglas, I believe it is you to whom the pull requests must be addressed. In fact, the current workflow is different: I'll handle all patches (except for those that are pure backport patches or to some files that are present only at v4l-dvb -hg tree). After having them added to my -git tree, then Douglas will backport them to -hg. Ah, ok, and do you still accept pull requests from hg trees. As much I think moving over to git is a good thing (I use it everywhere else), I must say the hg tree's stand alone compile behavior (so without having to rebuild your entire kernel), is very very convenient. Well, the kernel building system has some very fancy things like: make drivers/media/gspca/ (to compile all gspca drivers but don't generate the .ko) make drivers/media/video/gspca/gspca_sonixj.ko To generate the gspca_sonixj.ko module This is a way faster than what the -hg building system have. -- 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: [PATCH] mfd: Add support for the timberdale FPGA.
On Wed, Feb 03, 2010 at 10:18:17AM +, Mauro Carvalho Chehab wrote: Samuel Ortiz wrote: I'm going to review this patch right now. Typically, mfd core drivers and their subdevices are submitted as a patchset via my tree, because the subdevices drivers have dependencies with the core. The mfd core driver is submitted without any dependencies, and then when the subdevices drivers are submitted, we add relevant code to the mfd driver. This way we prevent any build breakage or bisection mess. The drivers at media are generally very complex with dependencies on several other subsystems. In general, almost all depends on i2c, alsa and input, and an increasing number of drivers has also dependencies with platform_data added at arch-dependent includes/drivers. Yet, this specific driver is simple. I generally tend to add those drivers via my tree, since it is generally simpler to prevent breakage/bisection troubles, I see that we have similar issues :) but it is also ok for me if you want to add them via your tree, after I get my ack. Great, let's to that then. The timberdale chip right now doesnt depend on anything, but will soon depend on the radio driver that's on your tree, but also on a sound and on a network driver. You'd have to take all those if Richard wants to push them right now. There were one or two minor changes requested on radio-timb patchset. After that changes, we're ready to merge it. All right, I'd appreciate if you could cc me on the relevant thread. So, what I propose is to take the timberdale mfd core driver and the radio one, with your SOB. Then when Richard wants to submit additional subdevices drivers I'll be able to take them and we'll avoid polluting your tree with non media related drivers. Does that make sense to you ? Yes, it does. I don't think Richard is urging with those patches, so my idea is to keep them for linux-next. It would equally work for me if you add the patches on your tree after my ack. The only merge conflicts we may expect from V4L side are related to Kconfig/Makefile, and those will be easy to fix during the merge period. Ok, thanks again for your understanding. This is definitely material for the next merge window, so I'll merge it into my for-next branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- 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: New DVB-Statistics API - please vote
On Wed, Feb 3, 2010 at 2:40 PM, Hans Verkuil hverk...@xs4all.nl wrote: Mauro Carvalho Chehab wrote: after the last thread which asked about signal statistics details degenerated into a discussion about the technical possibilites for implementing an entirely new API, which lead to nothing so far, I wanted to open a new thread to bring this forward. Maybe some more people can give their votes for the different options Only me and Manu manifested with opinions on this thread. Not sure why nobody else gave their comments. Maybe all interested people just decided to take a long vacation and are not listening to their emails ;) Seriously, from what I understand, this is an API improvement and we need to take a decision on it. So, your opinions are important. --- Let me draw a summary of this subject, trying to be impartial. The original proposal were made by Manu. My proposal is derived from Manu's original one, both will equally provide the same features. The main difference is that Manu's proposal use a struct to get the statistics while my proposal uses DVBS2API. With both API proposals, all values are get at the same time by the driver. the DVBS2API adds a small delay to fill the fields, but the extra delay is insignificant, when compared with the I/O delays needed to retrieve the values from the hardware. Due to the usage of DVBS2API, it is possible to retrieve a subset of statistics. When obtaining a subset, the DVBS2API latency is considerable faster, as less data needed to be transfered from the hardware. The DVBS2API also offers the possibility of expanding the statistics group, since it is not rigid as an struct. One criteria that should be reminded is that, according with Linux Kernel rules, any userspace API is stable. This means that applications compiled against an older API version should keep running with the latest kernel. So, whatever decided, the statistics API should always maintain backward compatibility. --- During the end of the year, I did some work with an ISDB-T driver for Siano, and I realized that the usage of the proposed struct won't fit well for ISDB-T. The reason is that, on ISDB-T, the transmission uses up to 3 hierarchical layers. Each layer may have different OFDM parameters, so the devices (at least, this is the case for Siano) has a group of statistics per layer. I'm afraid that newer standards may also bring different ways to present statistics, and the current proposal won't fit well. So, in my opinion, if it is chosen any struct-based approach, we'll have a bad time to maintain it, as it won't fit into all cases, and we'll need to add some tricks to extend the struct. So, my vote is for the DVBS2API approach, where a new group of statistics can easily be added, on an elegant way, without needing of re-discussing the better API or to find a way to extend the size of an struct without breaking backward compatibility. From a purely technical standpoint the DVBS2API is by definition more flexible and future-proof. The V4L API has taken the same approach with controls (basically exactly the same mechanism). Should it be necessary in the future to set multiple properties atomically, then the same technique as V4L can be used (see VIDIOC_S_EXT_CTRLS). The alternative is to make structs with lots of reserved fields. It depends on how predictable the API is expected to be. Sometimes you can be reasonably certain that there won't be too many additions in the future and then using reserved fields is perfectly OK. Just my 5 cents based on my V4L experience. In fact, I don't see the advantage using a specific get/set, since what i proposed just reads back basic data types such as a u32 for any instance and those being standard for any digital communication system. It makes no sense to go for a get/set approach. For example there cannot be multiple properties for any digital system such as BER, just that there are different measure s such as kilograms, pounds, grams etc. Which is what the whole patch is meant to do in a performance critical manner. The whole patch is a kind of get/set and and hence it doesn't need a get/set at the micro level. To contradict the reverse, as an example, I can state that weight is not measured in centimeters or inches or feet, to put it in laymans terms. if you say that it needs to be expressed as such, then i very well see that there is something conceptually wrong in your thought. My 2 cents, for those who don't understand the issue. Regards, Manu -- 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 v3 0/1] radio: Add radio-timb
On the intel russellville board there is a radio DSP, radio tuner and a RDS block. This umbrella driver uses two subdevs (DSP and tuner). Since v2, the RDS support has been removed from the patch. The current API in V4L2 and the simplicity of the Radio DSP makes it a bit complicated to implement the RDS support properly. It will be added at a later stage. --Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] radio: Add radio-timb
This patch add supports for the radio system on the Intel Russellville board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 3f40f37..c242939 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -429,4 +429,14 @@ config RADIO_TEF6862
To compile this driver as a module, choose M here: the
module will be called TEF6862.
+config RADIO_TIMBERDALE
+ tristate Enable the Timberdale radio driver
+ depends on MFD_TIMBERDALE VIDEO_V4L2
+ select RADIO_TEF6862
+ select RADIO_SAA7706H
+ ---help---
+ This is a kind of umbrella driver for the Radio Tuner and DSP
+ found behind the Timberdale FPGA on the Russellville board.
+ Enabling this driver will automatically select the DSP and tuner.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 01922ad..8973850 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/
obj-$(CONFIG_USB_MR800) += radio-mr800.o
obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
+obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..c650865
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,260 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/version.h
+#include linux/io.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/timb_radio.h
+
+#define DRIVER_NAME timb-radio
+
+struct timbradio {
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct v4l2_subdev *sd_dsp;
+ struct video_device *video_dev;
+ struct v4l2_device v4l2_dev;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v-driver, DRIVER_NAME, sizeof(v-driver));
+ strlcpy(v-card, Timberdale Radio, sizeof(v-card));
+ snprintf(v-bus_info, sizeof(v-bus_info), platform:DRIVER_NAME);
+ v-version = KERNEL_VERSION(0, 0, 1);
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_tuner, v);
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_tuner, v);
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a-index = 0;
+ strlcpy(a-name, Radio, sizeof(a-name));
+ a-capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+
+static int timbradio_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ return a-index ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_frequency, f);
+}
+
+static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_frequency, f);
+}
+
+static int timbradio_vidioc_queryctrl(struct file *file, void *priv,
Re: [PATCH 3/8] drivers/media/video/hdpvr: introduce missing kfree
Hej, On Tue, Feb 02, 2010 at 01:19:15PM -0200, Mauro Carvalho Chehab wrote: Janne Grunau wrote: On Fri, Sep 11, 2009 at 06:21:35PM +0200, Julia Lawall wrote: Error handling code following a kzalloc should free the allocated data. Thanks for the report. I'll commit a different patch which adds the buffer to the buffer list as soon it is allocated. The hdpvr_free_buffers() in the error handling code will clean it up then. See below: Any news about this subject? The current upstream code still misses the change bellow it was fixed differently in cd0e280f kind regards, Janne -- 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 3/8] drivers/media/video/hdpvr: introduce missing kfree
Janne Grunau wrote: Hej, On Tue, Feb 02, 2010 at 01:19:15PM -0200, Mauro Carvalho Chehab wrote: Janne Grunau wrote: On Fri, Sep 11, 2009 at 06:21:35PM +0200, Julia Lawall wrote: Error handling code following a kzalloc should free the allocated data. Thanks for the report. I'll commit a different patch which adds the buffer to the buffer list as soon it is allocated. The hdpvr_free_buffers() in the error handling code will clean it up then. See below: Any news about this subject? The current upstream code still misses the change bellow it was fixed differently in cd0e280f Thanks! I'm removing it from my queue :) Now, the only hdpvr patch is this one: hdpvr-video: cleanup signedness http://patchwork.kernel.org/patch/74902 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: [PATCH] hdpvr-video: cleanup signedness
On Sat, Jan 23, 2010 at 02:44:34PM +0100, Németh Márton wrote: From: Márton Németh nm...@freemail.hu The fifth parameter of usb_bulk_msg() is a pointer to signed (see linux/usb.h) so also call this function with pointer to signed. This will remove the following sparse warning (see make C=1): * warning: incorrect type in argument 5 (different signedness) expected int *actual_length got unsigned int *noident Signed-off-by: Márton Németh nm...@freemail.hu Thanks, I'll send a git pull request including the second patch for Mauro later today. cheers Janne -- 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 v3 1/1] radio: Add radio-timb
Hi Richard,
On Wed, 3 Feb 2010, Richard R?jfors wrote:
This patch add supports for the radio system on the Intel Russellville board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
Signed-off-by: Richard R?jfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 3f40f37..c242939 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -429,4 +429,14 @@ config RADIO_TEF6862
To compile this driver as a module, choose M here: the
module will be called TEF6862.
+config RADIO_TIMBERDALE
+ tristate Enable the Timberdale radio driver
+ depends on MFD_TIMBERDALE VIDEO_V4L2
+ select RADIO_TEF6862
+ select RADIO_SAA7706H
+ ---help---
+ This is a kind of umbrella driver for the Radio Tuner and DSP
+ found behind the Timberdale FPGA on the Russellville board.
+ Enabling this driver will automatically select the DSP and tuner.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 01922ad..8973850 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/
obj-$(CONFIG_USB_MR800) += radio-mr800.o
obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
+obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-timb.c
b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..c650865
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,260 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/version.h
+#include linux/io.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/timb_radio.h
+
+#define DRIVER_NAME timb-radio
+
+struct timbradio {
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct v4l2_subdev *sd_dsp;
+ struct video_device *video_dev;
Recommend removing '*' here. See notes below.
+ struct v4l2_device v4l2_dev;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v-driver, DRIVER_NAME, sizeof(v-driver));
+ strlcpy(v-card, Timberdale Radio, sizeof(v-card));
+ snprintf(v-bus_info, sizeof(v-bus_info), platform:DRIVER_NAME);
+ v-version = KERNEL_VERSION(0, 0, 1);
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_tuner, v);
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_tuner, v);
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a-index = 0;
+ strlcpy(a-name, Radio, sizeof(a-name));
+ a-capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+
+static int timbradio_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ return a-index ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_frequency, f);
+}
+
+static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return
[GIT PULL] V4L HD PVR updates
Hi Mauro, please pull from git://git.jannau.net/linux hdpvr for following patches: Janne Grunau (1): V4L/DVB: hdpvr: add new USB product id Márton Németh (2): hdpvr-video: cleanup signedness hdpvr-core: make module parameters local drivers/media/video/hdpvr/hdpvr-core.c |5 +++-- drivers/media/video/hdpvr/hdpvr-video.c |3 ++- drivers/media/video/hdpvr/hdpvr.h |1 + 3 files changed, 6 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] V4L HD PVR updates
Janne Grunau wrote: Hi Mauro, please pull from git://git.jannau.net/linux hdpvr Didn't work: $ git pull git://git.jannau.net/linux fatal: The remote end hung up unexpectedly I can see via the web interface, but the git method is not working. pulling via http is also broken: $ git pull http://git.jannau.net/linux fatal: http://git.jannau.net/linux/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server? -- 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: Any saa711x users out there?
On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The better is to allow enabling/disabling the anti-alias via ctrl. Whatever default is chosen, the driver may adjust the control default at the board initialization, or even blocking the control when the other mode of operation is broken. I have here a few devices with saa7113 and saa7114. I think I have also one device with saa7111, but I need to check. If I'm right, it will take some time for me to prepare the saa7111 environment. The saa7113/7114 devices are easier to setup, as they are usb. I actually am not very familiar with how custom controls work for v4l devices in terms of board specific configuration, as I'm more familiar with the way that you can provide a config struct during dvb_attach() for DVB devices. I've obviously seen how they can be set from userland, but have never dug into the specific as to how a bridge would set the parameters. I actually have a test tree here which includes the change (as well as a couple of unrelated em28xx fixes I'm working on). http://www.kernellabs.com/hg/~dheitmueller/em28xx-test The change in that tree just flips on the Anti-alias filter bit in the saa7115_misc_init struct, so it ends up being applied for 7113/7114/7115. However, I'm wondering if it makes sense to just have it on by default for all three boards (which is a *much* simpler change than adding a custom control and making sure it gets set properly by the bridge in all the various cases such as surviving a powerdown/powerup of the chip). BTW, the tree above just forces the bit on for all three boards - I'm not proposing that should be the final fix, but it is enough to allow people to evaluate the effects of the change. I've got a PVR-350 board with a saa7115 which I will do some testing on. If I see the artifacts on that board without the change, that bolsters the argument that the current default may just be wrong in general. Mauro, the hg logs suggest that you added the saa7115 support (and in fact appear to have introduced the issue in question). Do you remember what board you were using when you added the support? Also, how did you arrive at the defaults that you used? Were they based on some sort of i2c bus trace, or did you just set them by reading the datasheet? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb: return -ENOMEM if kzalloc failed in dvb_usb_device_init()
On Tue, Feb 2, 2010 at 3:29 PM, Oliver Neukum oli...@neukum.org wrote:
Am Dienstag, 2. Februar 2010 15:29:46 schrieb Roel Kluin:
If in a cold state and the download succeeded ret is zero, but we
should return -ENOMEM.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Or shouldn't we?
We should and we do if cold==0.
The bug is caused by this:
if (cold) {
info(found a '%s' in cold state, will try to load a
firmware,desc-name);
ret = dvb_usb_download_firmware(udev,props);
if (!props-no_reconnect || ret != 0)
return ret;
}
which overwrites ret
Is that an ack or do you want me to add an int (e.g. rc) that
handles the dvb_usb_download_firmware() return value?
Roel
--
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 v4] radio: Add radio-timb
Hi Richard,
Looks good to me!
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
This patch add supports for the radio system on the Intel Russellville
board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 3f40f37..c242939 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -429,4 +429,14 @@ config RADIO_TEF6862
To compile this driver as a module, choose M here: the
module will be called TEF6862.
+config RADIO_TIMBERDALE
+ tristate Enable the Timberdale radio driver
+ depends on MFD_TIMBERDALE VIDEO_V4L2
+ select RADIO_TEF6862
+ select RADIO_SAA7706H
+ ---help---
+ This is a kind of umbrella driver for the Radio Tuner and DSP
+ found behind the Timberdale FPGA on the Russellville board.
+ Enabling this driver will automatically select the DSP and tuner.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 01922ad..8973850 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/
obj-$(CONFIG_USB_MR800) += radio-mr800.o
obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
+obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-timb.c
b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..0de457f
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,244 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/version.h
+#include linux/io.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include media/timb_radio.h
+
+#define DRIVER_NAME timb-radio
+
+struct timbradio {
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct v4l2_subdev *sd_dsp;
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v-driver, DRIVER_NAME, sizeof(v-driver));
+ strlcpy(v-card, Timberdale Radio, sizeof(v-card));
+ snprintf(v-bus_info, sizeof(v-bus_info), platform:DRIVER_NAME);
+ v-version = KERNEL_VERSION(0, 0, 1);
+ v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, g_tuner, v);
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_tuner, v);
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a-index = 0;
+ strlcpy(a-name, Radio, sizeof(a-name));
+ a-capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+static int timbradio_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ return a-index ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr-sd_tuner, tuner, s_frequency, f);
+}
+
+static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr =
Re: git problem with uvcvideo
Mauro Carvalho Chehab wrote: However, the html URL is currently broken: $ rm -rf uvcvideo/ git clone -l --bare /git/linux-2.6.git/ uvcvideo cd uvcvideo git remote add uvcvideo http://linuxtv.org/git/pinchartl/uvcvideo.git git remote update Initialized empty Git repository in /home/mchehab/tst/uvcvideo/uvcvideo/ Updating uvcvideo Probably, the rewrite rules at the server for http are incomplete. I'll see if I can fix it. Fixed. Basically, for http: to work, the http server shouldn't call gitweb handler. So, a different URL is needed for gitweb and for git pull... Also, I needed to enable an post-update hook to be sure that some references are generated after a push. I've updated the gitweb to display the proper URL's. Basically, the gitweb interface is available via http://git.linuxtv.org. So, for uvcvideo, we have: http://git.linuxtv.org/pinchartl/uvcvideo.git (gitweb interface, for browsing) For adding a remote to that tree, you should use either: git remote add uvcvideo git://linuxtv.org/pinchartl/uvcvideo.git or git remote add uvcvideo http://linuxtv.org/git/pinchartl/uvcvideo.git Both is working, but using the git: URL is better. The http: URL should be used only when behind a firewall that blocks the git port (tcp port 9418). -- 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: Any saa711x users out there?
Devin Heitmueller wrote: On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The better is to allow enabling/disabling the anti-alias via ctrl. Whatever default is chosen, the driver may adjust the control default at the board initialization, or even blocking the control when the other mode of operation is broken. I have here a few devices with saa7113 and saa7114. I think I have also one device with saa7111, but I need to check. If I'm right, it will take some time for me to prepare the saa7111 environment. The saa7113/7114 devices are easier to setup, as they are usb. I actually am not very familiar with how custom controls work for v4l devices in terms of board specific configuration, as I'm more familiar with the way that you can provide a config struct during dvb_attach() for DVB devices. I've obviously seen how they can be set from userland, but have never dug into the specific as to how a bridge would set the parameters. Just call: v4l2_device_call_all(dev-v4l2_dev, 0, core, g_ctrl, ctrl); For get a control, and: v4l2_device_call_all(dev-v4l2_dev, 0, core, s_ctrl, ctrl); to set a control. I actually have a test tree here which includes the change (as well as a couple of unrelated em28xx fixes I'm working on). http://www.kernellabs.com/hg/~dheitmueller/em28xx-test The change in that tree just flips on the Anti-alias filter bit in the saa7115_misc_init struct, so it ends up being applied for 7113/7114/7115. However, I'm wondering if it makes sense to just have it on by default for all three boards (which is a *much* simpler change than adding a custom control and making sure it gets set properly by the bridge in all the various cases such as surviving a powerdown/powerup of the chip). The chip powerup/powerdown should preserve all controls, anyway. I think we need a general logic here to save/restore those values on those cases, including hibernation/suspend. In the past, several of those drivers like saa711x used to store the register values into a shadow array (although the old code were ugly and haven't any suspend/resume logic). Maybe we can resurrect this idea, in order to quickly recover from a powerdown/powerup situation. In general, the shadow array will have only 256 bytes on those chips. BTW, the tree above just forces the bit on for all three boards - I'm not proposing that should be the final fix, but it is enough to allow people to evaluate the effects of the change. I'll test it later. I've got a PVR-350 board with a saa7115 which I will do some testing on. If I see the artifacts on that board without the change, that bolsters the argument that the current default may just be wrong in general. Mauro, the hg logs suggest that you added the saa7115 support (and in fact appear to have introduced the issue in question). Do you remember what board you were using when you added the support? Also, how did you arrive at the defaults that you used? Were they based on some sort of i2c bus trace, or did you just set them by reading the datasheet? Well, we used to have different drivers on that time. Basically, the code from all saa711x drivers got merged and the init arrays were added as seen at the original driver. Then, fix patches were applied in order to make everybody happy. A large number of tests were done on that time, as we've got contributions from several developers. For sure we used some PVR boards, pvrusb2, WinTV USB2 and some bttv based boards with saa711x chips. Later, we've got feedback also from NT100x boards (usbvision driver) and I suspect we had tests with other drivers as well. Some Zoran boards also use saa711x chips, and, after the port to V4L2, they're now using the same 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
[PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Mauro, Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene for the following 20 changesets: 01/20: ngene: Initial check-in http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=643e6259c1e1 02/20: ngene: Driver compiles now http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=0cb4c76e0684 03/20: ngene: Always use firmware loader http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=f586430fa0a5 04/20: ngene: Additional clean-up http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=72664e3f8e78 05/20: ngene: Added Media-Pointer MP-S2/CineS2 DVB-S2 Twin Tuner http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=a9380f45ba62 06/20: ngene: Remove firmware debugging http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=6a564d8f7e34 07/20: ngene: Fix unloading of module http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=fe5e20348961 08/20: ngene: Speed-up tuning http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=64a1898585c4 09/20: ngene: Change severity of some diagnostic messages http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=6f2370074c10 10/20: ngene: Remove kernel version check for dvb_[un]register_adapter http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=515a0140628d 11/20: DVB: Export dvb_ringbuffer_flush() again http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=c6e778666d25 12/20: ngene: Added module parameter one_adapter http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1ac2889c024a 13/20: ngene: Code cleanup http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=e92b32e5f122 14/20: [nGene] Trivial I2C related fixes/cleanups http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=13fadcb7d30e 15/20: ngene: Mystique SaTiX-S2 Dual http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=9ffa528e3ae5 16/20: ngene: Adapt to current frontend drivers http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=4edcdbe14c20 17/20: ngene: Set ADC ranges to 1Vpp http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=2af4b3e4d6bb 18/20: ngene: Workaround for command timeout http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=fb39caf2848a 19/20: ngene: Take care of late interrupts http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=43517d28deef 20/20: ngene: Use correct name for cineS2 cards http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=6aca2983b62d a/linux/drivers/media/dvb/ngene/ngene-ioctls.h| 286 - a/linux/drivers/media/dvb/ngene/ngene-snd.c | 421 -- a/linux/drivers/media/dvb/ngene/ngene-v4l2.c | 1978 -- b/linux/drivers/media/dvb/ngene/Kconfig |9 b/linux/drivers/media/dvb/ngene/Makefile | 11 b/linux/drivers/media/dvb/ngene/ngene-core.c | 4316 ++ b/linux/drivers/media/dvb/ngene/ngene-ioctls.h| 286 + b/linux/drivers/media/dvb/ngene/ngene-snd.c | 421 ++ b/linux/drivers/media/dvb/ngene/ngene-v4l2.c | 1978 ++ b/linux/drivers/media/dvb/ngene/ngene.h | 958 linux/drivers/media/dvb/Kconfig |4 linux/drivers/media/dvb/Makefile |3 linux/drivers/media/dvb/dvb-core/dvb_ringbuffer.c |1 linux/drivers/media/dvb/ngene/ngene-core.c| 675 +-- linux/drivers/media/dvb/ngene/ngene.h | 83 15 files changed, 8352 insertions(+), 3078 deletions(-) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 6/6] DaVinci - Adding platform board changes for vpfe capture on DM365
Kevin,
Please respond by today if you have any comments against this patch so that I
can add it to my development repository at linuxtv.org and ask Mauro to pull
this to your tree. As we are approaching the merge window for 2.6.34
and so many patches pending to be merged to 2.6.34, I would appreciate your
prompt response on this.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, February 01, 2010 5:27 PM
To: linux-media@vger.kernel.org; khil...@deeprootsystems.com
Cc: hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
Karicheri, Muralidharan
Subject: [PATCH v3 6/6] DaVinci - Adding platform board changes for vpfe
capture on DM365
From: Murali Karicheri m-kariche...@ti.com
This patch adds following changes:-
1) add sub device configuration data for TVP5146 used by vpfe capture
2) registers platform devices for vpfe_capture, isif and vpss
3) defines hardware resources for the devices listed under 2)
4) defines clock aliase for isif driver
5) adding setup_pinmux() for isif
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to linux-next of v4l-dvb
- updated to add clock aliase (v3) and rebased to latest for merge
- review comments incorporated (v2)
arch/arm/mach-davinci/board-dm365-evm.c| 71 +++
arch/arm/mach-davinci/dm365.c | 102
+++-
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 174 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index b476395..c216783 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -37,6 +37,8 @@
#include mach/nand.h
#include mach/keyscan.h
+#include media/tvp514x.h
+
static inline int have_imager(void)
{
/* REVISIT when it's supported, trigger via Kconfig */
@@ -306,6 +308,73 @@ static void dm365evm_mmc_configure(void)
davinci_cfg_reg(DM365_SD1_DATA0);
}
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .i2c_adapter_id = 1,
+ .card_name = DM365 EVM,
+ .ccdc = ISIF,
+};
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -497,6 +566,8 @@ static struct davinci_uart_config uart_config
__initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f53735c..ce9da43 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1008,6 +1008,97 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = isp5,
+ .start =
Re: DM1105: could not attach frontend 195d:1105
On 3 февраля 2010 00:07:36 Nameer Kazzaz wrote:
Nameer Kazzaz wrote:
Igor M. Liplianin wrote:
On 2 февраля 2010 17:21:46 Nameer Kazzaz wrote:
Hi Igor,
What do you think ? if I can help you solve this, let me know
what I
can do.
Thanks
Nameer
Nameer Kazzaz wrote:
Hi there,
dmesg output with patched dm1105.c against current v4l-dvb 'modprob
dm1105 card=4'
dm1105 :05:0f.0: PCI INT A - GSI 16 (level, low) - IRQ 16
DVB: registering new adapter (dm1105)
dm1105 :05:0f.0: MAC dd49b0dc
dm1105 :05:0f.0: could not attach frontend
dm1105 :05:0f.0: PCI INT A disabled
Thanks
Nameer Kazzaz
Igor M. Liplianin wrote:
On 20 ?? 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x //
later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 //
later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to
code
like that at the bottom. It still doesn't work, but feels a lot
closer.
Before I keep playing with values, I want to check I'm on the right
track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I
put the
logic into fe_attach because there was already card-specific
logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input
= 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or
0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK,
dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET ,
dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage
function.
Try attached patch against current v4l-dvb tree with modprobe option
card=4
modprobe dm1105 card=4
Hi Nameer,
You can modify sended by me patch to guess GPIO pin. Simply try all
of them, it is only 17. Just replace all appearances DM1105_GPIO(15)
with number you want.
Ok I will do that.
Thanks
Nameer
Hi Igor,
I tried all DM1105_GPIO(0) to DM1105_GPIO(17), same error. Any Idea ?
Nameer
Hi
I have
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Wed Feb 3 19:00:04 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14108:556072389bd6 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-rc5-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[PATCH] radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
The -EINVAL was overwritten by the si470x_disconnect_check().
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Is this needed?
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 4da0f15..65b4a92 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -748,12 +748,13 @@ static int si470x_vidioc_s_tuner(struct file *file, void
*priv,
struct v4l2_tuner *tuner)
{
struct si470x_device *radio = video_drvdata(file);
- int retval = -EINVAL;
+ int retval;
/* safety checks */
retval = si470x_disconnect_check(radio);
if (retval)
goto done;
+ retval = -EINVAL;
if (tuner-index != 0)
goto done;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/15] - tm6000 build hunk
--- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -32,7 +32,7 @@ #include tm6000.h #include tm6000-regs.h #include tuner-xc2028.h -#include tuner-xc5000.h +#include xc5000.h #define TM6000_BOARD_UNKNOWN0 #define TM5600_BOARD_GENERIC1 -- Stefan Ringel stefan.rin...@arcor.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
[PATCH 2/15] - tm6000 add Terratec Cinergy Hybrid XE
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -44,6 +44,10 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
-
+[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+.name = Terratec Cinergy Hybrid XE,
+.tuner_type = TUNER_XC2028, /* has a XC3028 */
+.tuner_addr = 0xc2 1,
+.demod_addr = 0x1e 1,
+.type = TM6010,
+.caps = {
+.has_tuner= 1,
+.has_dvb = 1,
+.has_zl10353 = 1,
+.has_eeprom = 1,
+.has_remote = 1,
+},
+.gpio_addr_tun_reset = TM6010_GPIO_2,
+}
};
/* table of devices that work with this driver */
@@ -221,12 +239,13 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info =
TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
+{ USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
@@ -302,15 +344,19 @@ static void tm6000_config_tuner (struct
tm6000_core *dev)
memset(xc2028_cfg, 0, sizeof(xc2028_cfg));
memset (ctl,0,sizeof(ctl));
-ctl.mts = 1;
-ctl.read_not_reliable = 1;
+ctl.input1 = 1;
+ctl.read_not_reliable = 0;
ctl.msleep = 10;
-
+ctl.demod = XC3028_FE_ZARLINK456;
+ctl.vhfbw7 = 1;
+ctl.uhfbw8 = 1;
+ctl.switch_mode = 1;
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv = ctl;
switch(dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
+case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
ctl.fname = xc3028L-v36.fw;
break;
default:
--
Stefan Ringel stefan.rin...@arcor.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 1/15] - tm6000 build hunk
Stefan Ringel wrote: OK, patch is correct, but you should: - Use the email subject to summarize what the patch does - Add more detailed patch description; - Add your Signed-off-by. In this specific case, you could have: Subject: Fix compilation breakage Signed-off-by: your name y...@email (this is a really trivial patch - so, you don't need a detailed description) --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -32,7 +32,7 @@ #include tm6000.h #include tm6000-regs.h #include tuner-xc2028.h -#include tuner-xc5000.h +#include xc5000.h #define TM6000_BOARD_UNKNOWN0 #define TM5600_BOARD_GENERIC1 -- 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
[PATCH 4/15] - tm6000.h
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
enum tm6000_mode {
TM6000_MODE_UNKNOWN=0,
@@ -202,6 +211,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
@@ -209,7 +221,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev,
u8 reqtype, u8 req,
int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_init (struct tm6000_core *dev);
-int tm6000_init_after_firmware (struct tm6000_core *dev);
int tm6000_init_analog_mode (struct tm6000_core *dev);
int tm6000_init_digital_mode (struct tm6000_core *dev);
@@ -231,7 +242,12 @@ int tm6000_set_standard (struct tm6000_core *dev,
v4l2_std_id *norm);
int tm6000_i2c_register(struct tm6000_core *dev);
int tm6000_i2c_unregister(struct tm6000_core *dev);
+#if 1
/* In tm6000-queue.c */
+#if 0
+int tm6000_init_isoc(struct tm6000_core *dev, int max_packets);
+void tm6000_uninit_isoc(struct tm6000_core *dev);
+#endif
int tm6000_v4l2_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -276,3 +292,4 @@ extern int tm6000_debug;
__FUNCTION__ , ##arg); } while (0)
+#endif
--
Stefan Ringel stefan.rin...@arcor.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
[PATCH 5/15] - tm6000 bugfix i2c transfer
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -86,6 +86,11 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
msgs[i].len == 1 ? 0 : msgs[i].buf[1],
msgs[i + 1].buf, msgs[i + 1].len);
i++;
+
+if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+tm6000_set_reg(dev, 0x32, 0,0);
+tm6000_set_reg(dev, 0x33, 0,0);
+}
if (i2c_debug = 2)
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
@@ -99,6 +104,12 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
REQ_16_SET_GET_I2C_WR1_RDN,
addr | msgs[i].buf[0] 8, 0,
msgs[i].buf + 1, msgs[i].len - 1);
+
+
+if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+tm6000_set_reg(dev, 0x32, 0,0);
+tm6000_set_reg(dev, 0x33, 0,0);
+}
}
if (i2c_debug = 2)
printk(\n);
@@ -198,7 +209,7 @@ static struct i2c_algorithm tm6000_algo = {
static struct i2c_adapter tm6000_adap_template = {
.owner = THIS_MODULE,
-.class = I2C_CLASS_TV_ANALOG,
+.class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL,
.name = tm6000,
.id = I2C_HW_B_TM6000,
.algo = tm6000_algo
--
Stefan Ringel stefan.rin...@arcor.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 2/15] - tm6000 add Terratec Cinergy Hybrid XE
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by:
(first letter is on upper case)
The patch looks ok to my eyes.
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -44,6 +44,10 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
-
+[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+.name = Terratec Cinergy Hybrid XE,
+.tuner_type = TUNER_XC2028, /* has a XC3028 */
+.tuner_addr = 0xc2 1,
+.demod_addr = 0x1e 1,
+.type = TM6010,
+.caps = {
+.has_tuner= 1,
+.has_dvb = 1,
+.has_zl10353 = 1,
+.has_eeprom = 1,
+.has_remote = 1,
+},
+.gpio_addr_tun_reset = TM6010_GPIO_2,
+}
};
/* table of devices that work with this driver */
@@ -221,12 +239,13 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info =
TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
+{ USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
@@ -302,15 +344,19 @@ static void tm6000_config_tuner (struct
tm6000_core *dev)
memset(xc2028_cfg, 0, sizeof(xc2028_cfg));
memset (ctl,0,sizeof(ctl));
-ctl.mts = 1;
-ctl.read_not_reliable = 1;
+ctl.input1 = 1;
+ctl.read_not_reliable = 0;
ctl.msleep = 10;
-
+ctl.demod = XC3028_FE_ZARLINK456;
+ctl.vhfbw7 = 1;
+ctl.uhfbw8 = 1;
+ctl.switch_mode = 1;
xc2028_cfg.tuner = TUNER_XC2028;
xc2028_cfg.priv = ctl;
switch(dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
+case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
ctl.fname = xc3028L-v36.fw;
break;
default:
--
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
[PATCH 7/15] - tm6000
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -23,12 +23,15 @@
// Use the tm6000-hack, instead of the proper initialization code
//#define HACK 1
+#include compat.h
#include linux/videodev2.h
#include media/v4l2-common.h
#include media/videobuf-vmalloc.h
#include tm6000-usb-isoc.h
#include linux/i2c.h
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,15)
#include linux/mutex.h
+#endif
#include media/v4l2-device.h
@@ -78,6 +81,10 @@ struct tm6000_dmaqueue {
/* thread for generating video stream*/
struct task_struct *kthread;
wait_queue_head_t wq;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
+struct semaphore *notify;
+intrmmod:1;
+#endif
/* Counters to control fps rate */
intframe;
intini_jiffies;
--
Stefan Ringel stefan.rin...@arcor.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 3/15] - tm6000 bugfix hunk in init_dev
This is too generic: tm6000 bugfix hunk in init_dev A better subject would be: [PATCH 3/15] tm6000: avoid unregister the driver after success at tm6000_init_dev PS.: don't mind to re-submit those patches where just the subject has troubles. I'll fix it locally. I'm pointing the issues to save me some time on your next patcheset submission ;) For the patchsets that you forgot to sign (1/15 for example), just reply your own email with Signed-off-by:. Cheers, Mauro Stefan Ringel wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -402,6 +448,7 @@ static int tm6000_init_dev(struct tm6000_core *dev) } #endif } +return 0; err2: v4l2_device_unregister(dev-v4l2_dev); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/15] - tm6000 bugfix
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -459,13 +506,13 @@ static int tm6000_usb_probe(struct usb_interface
*interface,
/* Check to see next free device and mark as used */
nr=find_first_zero_bit(tm6000_devused,TM6000_MAXBOARDS);
if (nr = TM6000_MAXBOARDS) {
-printk (tm6000: Supports only %i em28xx
boards.\n,TM6000_MAXBOARDS);
+printk (tm6000: Supports only %i tm60xx
boards.\n,TM6000_MAXBOARDS);
usb_put_dev(usbdev);
return -ENOMEM;
}
--
Stefan Ringel stefan.rin...@arcor.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 4/15] - tm6000.h
This one is a very obscure patch. What are you doing this patch and why?
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
enum tm6000_mode {
TM6000_MODE_UNKNOWN=0,
@@ -202,6 +211,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
@@ -209,7 +221,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev,
u8 reqtype, u8 req,
int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_init (struct tm6000_core *dev);
-int tm6000_init_after_firmware (struct tm6000_core *dev);
int tm6000_init_analog_mode (struct tm6000_core *dev);
int tm6000_init_digital_mode (struct tm6000_core *dev);
@@ -231,7 +242,12 @@ int tm6000_set_standard (struct tm6000_core *dev,
v4l2_std_id *norm);
int tm6000_i2c_register(struct tm6000_core *dev);
int tm6000_i2c_unregister(struct tm6000_core *dev);
+#if 1
/* In tm6000-queue.c */
+#if 0
+int tm6000_init_isoc(struct tm6000_core *dev, int max_packets);
+void tm6000_uninit_isoc(struct tm6000_core *dev);
+#endif
int tm6000_v4l2_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -276,3 +292,4 @@ extern int tm6000_debug;
__FUNCTION__ , ##arg); } while (0)
+#endif
--
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
[PATCH 9/15] - tm6000 analog digital switch
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -15,6 +15,7 @@
#include linux/delay.h
#include media/tuner.h
#include linux/mutex.h
+#include compat.h
#include asm/unaligned.h
#include tuner-i2c.h
#include tuner-xc2028.h
@@ -994,6 +995,13 @@ static int generic_set_freq(struct dvb_frontend
*fe, u32 freq /* in HZ */,
buf[0], buf[1], buf[2], buf[3],
freq / 100, (freq % 100) / 1000);
+if (priv-ctrl.switch_mode) {
+if (new_mode == T_ANALOG_TV)
+do_tuner_callback(fe, SWITCH_TV_MODE, 0);
+if (new_mode == T_DIGITAL_TV)
+do_tuner_callback(fe, SWITCH_TV_MODE, 1);
+}
+
rc = 0;
ret:
--- a/drivers/media/common/tuners/tuner-xc2028.h
+++ b/drivers/media/common/tuners/tuner-xc2028.h
@@ -42,6 +42,7 @@ struct xc2028_ctrl {
unsigned intdisable_power_mgmt:1;
unsigned intread_not_reliable:1;
unsigned intdemod;
+unsigned intswitch_mode:1;
enum firmware_typetype:2;
};
@@ -54,6 +55,7 @@ struct xc2028_config {
/* xc2028 commands for callback */
#define XC2028_TUNER_RESET0
#define XC2028_RESET_CLK1
+#define SWITCH_TV_MODE2
#if defined(CONFIG_MEDIA_TUNER_XC2028) ||
(defined(CONFIG_MEDIA_TUNER_XC2028_MODULE) defined(MODULE))
extern struct dvb_frontend *xc2028_attach(struct dvb_frontend *fe,
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -269,13 +291,33 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
TM6000_GPIO_CLK, 0);
if (rc0)
return rc;
-msleep(100);
+msleep(10);
rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
-msleep(100);
+msleep(10);
+break;
+}
+break;
+
+case SWITCH_TV_MODE:
+/* switch between analog and digital */
+switch (arg) {
+case 0:
+printk(KERN_INFO switch to analog);
+tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_5, 1);
+printk(KERN_INFO analog);
+break;
+case 1:
+printk(KERN_INFO switch to digital);
+tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_5, 0);
+printk(KERN_INFO digital);
break;
}
+break;
}
+
return (rc);
}
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -235,7 +268,8 @@ int tm6000_dvb_register(struct tm6000_core *dev)
.i2c_adap = dev-i2c_adap,
.i2c_addr = dev-tuner_addr,
};
-
+
+dvb-frontend-callback = tm6000_tuner_callback;
ret = dvb_register_frontend(dvb-adapter, dvb-frontend);
if (ret 0) {
printk(KERN_ERR
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -269,13 +291,33 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
TM6000_GPIO_CLK, 0);
if (rc0)
return rc;
-msleep(100);
+msleep(10);
rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
-msleep(100);
+msleep(10);
+break;
+}
+break;
+
+case SWITCH_TV_MODE:
+/* switch between analog and digital */
+switch (arg) {
+case 0:
+printk(KERN_INFO switch to analog);
+tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_5, 1);
+printk(KERN_INFO analog);
+break;
+case 1:
+printk(KERN_INFO switch to digital);
+tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_5, 0);
+printk(KERN_INFO digital);
break;
}
+break;
}
+
return (rc);
}
--
Stefan Ringel stefan.rin...@arcor.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
[PATCH 2/15] - tm6000 add digital init for tm6010
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -219,33 +219,53 @@ int tm6000_init_analog_mode (struct tm6000_core *dev)
int tm6000_init_digital_mode (struct tm6000_core *dev)
{
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00ff, 0x08);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00ff, 0x00);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x003f, 0x01);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00df, 0x08);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e2, 0x0c);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e8, 0xff);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00eb, 0xd8);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c0, 0x40);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c1, 0xd0);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c3, 0x09);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00da, 0x37);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d1, 0xd8);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d2, 0xc0);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d6, 0x60);
-
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e2, 0x0c);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e8, 0xff);
- tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00eb, 0x08);
- msleep(50);
-
- tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x00);
- msleep(50);
- tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x01);
- msleep(50);
- tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x00);
- msleep(100);
-
+ if (dev-dev_type == TM6010) {
+ int val;
+ u8 buf[2];
+
+ /* digital init */
+ val = tm6000_get_reg(dev, REQ_07_SET_GET_AVREG, 0xcc, 0);
+ val = ~0x60;
+ tm6000_set_reg(dev, REQ_07_SET_GET_AVREG, 0xcc, val);
+ val = tm6000_get_reg(dev, REQ_07_SET_GET_AVREG, 0xc0, 0);
+ val |= 0x40;
+ tm6000_set_reg(dev, REQ_07_SET_GET_AVREG, 0xc0, val);
+ tm6000_set_reg(dev, REQ_07_SET_GET_AVREG, 0xfe, 0x28);
+ tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0xe2, 0xfc);
+ tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0xe6, 0xff);
+ tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0xf1, 0xfe);
+ tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2);
+ printk (KERN_INFO buf %#x %#x \n, buf[0], buf[1]);
+
+
+ } else {
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00ff, 0x08);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00ff, 0x00);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x003f, 0x01);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00df, 0x08);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e2, 0x0c);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e8, 0xff);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00eb, 0xd8);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c0, 0x40);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c1, 0xd0);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00c3, 0x09);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00da, 0x37);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d1, 0xd8);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d2, 0xc0);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00d6, 0x60);
+
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e2, 0x0c);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00e8, 0xff);
+ tm6000_set_reg (dev, REQ_07_SET_GET_AVREG, 0x00eb, 0x08);
+ msleep(50);
+
+ tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x00);
+ msleep(50);
+ tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x01);
+ msleep(50);
+ tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT, 0x0020, 0x00);
+ msleep(100);
+ }
return 0;
}
--
Stefan Ringel stefan.rin...@arcor.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
[PATCH 11/15] - tm6000 add init for tm6010
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -394,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+
+/* additional from Terratec Cinergy Hybrid XE */
+{ REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+{ REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+{ REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+{ REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+{ REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
@@ -404,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+u8 buf[40];
if (dev-dev_type == TM6010) {
tab = tm6010_init_tab;
@@ -424,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
}
}
-msleep(5); /* Just to be conservative */
-
-/* Check board version - maybe 10Moons specific */
-board=tm6000_get_reg16 (dev, 0x40, 0, 0);
-if (board =0) {
-printk (KERN_INFO Board version = 0x%04x\n,board);
-} else {
-printk (KERN_ERR Error %i while retrieving board
version\n,board);
-}
-
+/* hack */
if (dev-dev_type == TM6010) {
-/* Turn xceive 3028 on */
-tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3, 0x01);
-msleep(11);
-}
-
-/* Reset GPIO1 and GPIO4. */
-for (i=0; i 2; i++) {
-rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
-dev-tuner_reset_gpio, 0x00);
-if (rc0) {
-printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
-return rc;
-}
-
-msleep(10); /* Just to be conservative */
-rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
-dev-tuner_reset_gpio, 0x01);
-if (rc0) {
-printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
-return rc;
-}
-
-msleep(10);
-rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 0);
-if (rc0) {
-printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
-return rc;
-}
-
-msleep(10);
-rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4, 1);
-if (rc0) {
-printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
-return rc;
-}
-
-if (!i) {
-rc=tm6000_get_reg16(dev, 0x40,0,0);
-if (rc=0) {
-printk (board=%d\n, rc);
+
+msleep(15);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_4, 0);
+msleep(15);
+
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_1, 0);
+
+msleep(50);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_1, 1);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+msleep(15);
+buf[0] = 0x12;
+buf[1] = 0x34;
+tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x, buf, 2);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x, buf, 2);
+
+msleep(15);
+buf[0] = 0x00;
+buf[1] = 0x01;
+tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x, buf, 39);
+
+msleep(15);
+buf[0] = 0x00;
+buf[1] = 0x00;
+tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2);
+
+msleep(15);
+tm6000_read_write_usb (dev, 0xc0, 0x10, 0x7f1f, 0x, buf, 2);
+//printk(KERN_INFO buf %#x %#x \n, buf[0], buf [1]);
+msleep(15);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_4, 1);
+msleep(15);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_0, 1);
+msleep(15);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_7, 0);
+msleep(15);
+tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+TM6010_GPIO_5, 1);
+
+msleep(15);
+
+for (i=0; i size; i++) {
+rc= tm6000_set_reg (dev, tab[i].req, tab[i].reg, tab[i].val);
+if (rc0) {
+printk (KERN_ERR Error %i while setting req %d,
+ reg %d to value %d\n, rc,
+ tab[i].req,tab[i].reg, tab[i].val);
+return
[PATCH 14/15] - zl10353
signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/media/dvb/frontends/zl10353.h +++ b/drivers/media/dvb/frontends/zl10353.h @@ -45,6 +45,8 @@ struct zl10353_config /* clock control registers (0x51-0x54) */ u8 clock_ctl_1; /* default: 0x46 */ u8 pll_0;/* default: 0x15 */ + + int tm6000:1; }; #if defined(CONFIG_DVB_ZL10353) || (defined(CONFIG_DVB_ZL10353_MODULE) defined(MODULE)) -- Stefan Ringel stefan.rin...@arcor.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 9/15] - tm6000 analog digital switch
Stefan Ringel wrote: @@ -994,6 +995,13 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, Your emailer is damaging the patches. The above should be in the same line, otherwise the patch won't apply. It seems that you're using Thunderbird, right? User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0 You should really read the README.patches (http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches) before submitting your work. In particular, at the end of Part II, there are the procedures for submissions via email. It ends with: BE CAREFUL: several emailers including Thunderdird breaks long lines, causing patch corruption. In the specific case of Thunderbird, an extension is needed to send the patches, called Asalted Patches: https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/; So, please get the asalted-patches extension, apply it on your Thunderbird, review your patch series based on the contents of README.patches and re-submit. -- 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: [linux-dvb] Twinhan dtv 3030 mantis
Hi, Starting with 2.6.33 the mantis driver is included in mainline kernel. I have a pre5 installation that works great. I run *buntu 9.10 as well but when I saw that the kernel had mantis support I compiled my own. Just remember to add mantis as a kernel module, it's not on by default. Jakob Sundberg Niklas Claesson wrote: Hi, I'm trying to use this tv-card with ubuntu 9.10. I've installed Manu's drivers from http://jusst.de/hg/mantis-v4l-dvb/ and did modprobe mantis which resulted in the following in /var/log/messages Jan 31 20:57:40 niklas-desktop kernel: [ 179.000227] Mantis :05:02.0: PCI INT A - GSI 23 (level, low) - IRQ 23 Jan 31 20:57:40 niklas-desktop kernel: [ 179.001234] DVB: registering new adapter (Mantis DVB adapter) Jan 31 20:57:41 niklas-desktop kernel: [ 179.672664] *pde = bac3e067 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672676] Modules linked in: mantis(+) mantis_core ir_common ir_core tda665x lnbp21 mb86a16 stb6100 tda10021 tda10023 zl10353 stb0899 stv0299 dvb_core joydev hidp binfmt_misc ppdev bridge stp bnep arc4 ecb snd_hda_codec_analog rtl8187 mac80211 led_class eeprom_93cx6 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm usblp snd_seq_dummy iptable_filter ip_tables x_tables btusb cfg80211 asus_atk0110 lirc_imon lirc_dev lp parport snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc nvidia(P) usbhid skge ohci1394 ieee1394 sky2 intel_agp agpgart Jan 31 20:57:41 niklas-desktop kernel: [ 179.672743] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672748] Pid: 2768, comm: modprobe Tainted: P (2.6.31-17-generic #54-Ubuntu) System Product Name Jan 31 20:57:41 niklas-desktop kernel: [ 179.672752] EIP: 0060:[f8517480] EFLAGS: 00010292 CPU: 1 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672761] EIP is at dvb_unregister_frontend+0x10/0xe0 [dvb_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672764] EAX: EBX: f398f800 ECX: f6a51cc0 EDX: Jan 31 20:57:41 niklas-desktop kernel: [ 179.672767] ESI: EDI: f398f9fc EBP: f4983dec ESP: f4983dc8 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672771] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672779] f4983dec f851c07e f398f800 f398f9fc f4983dec f398f800 f398f800 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672797] 0 f4983e2c f85955d5 f70fc858 f8599b50 f398f800 f398fc70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672804] 0 f398f848 f398fc64 f398fc58 f85a9500 f398fbfc f398f9ac f398f800 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672820] [f851c07e] ? dvb_net_release+0x1e/0xb0 [dvb_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672827] [f85955d5] ? mantis_dvb_init+0x398/0x3de [mantis_core] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672833] [f85a6606] ? mantis_pci_probe+0x1d7/0x2f8 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672839] [c03285ae] ? local_pci_probe+0xe/0x10 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672843] [c0329330] ? pci_device_probe+0x60/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672848] [c03a2e30] ? really_probe+0x50/0x140 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672852] [c0570cea] ? _spin_lock_irqsave+0x2a/0x40 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672855] [c03a2f39] ? driver_probe_device+0x19/0x20 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672859] [c03a2fb9] ? __driver_attach+0x79/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672862] [c03a2488] ? bus_for_each_dev+0x48/0x70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672866] [c03a2cf9] ? driver_attach+0x19/0x20 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672869] [c03a2f40] ? __driver_attach+0x0/0x80 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672872] [c03a26df] ? bus_add_driver+0xbf/0x2a0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672876] [c0329270] ? pci_device_remove+0x0/0x40 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672879] [c03a3245] ? driver_register+0x65/0x120 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672883] [c0329550] ? __pci_register_driver+0x40/0xb0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672887] [f85a642d] ? mantis_init+0x17/0x19 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672890] [c010112c] ? do_one_initcall+0x2c/0x190 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672894] [f85a6416] ? mantis_init+0x0/0x19 [mantis] Jan 31 20:57:41 niklas-desktop kernel: [ 179.672899] [c0173711] ? sys_init_module+0xb1/0x1f0 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672903] [c01e83ed] ? sys_write+0x3d/0x70 Jan 31 20:57:41 niklas-desktop kernel: [ 179.672906] [c010336c] ? syscall_call+0x7/0xb Jan 31 20:57:41 niklas-desktop kernel: [ 179.672961] ---[ end trace 035b3cc151b9cf1a ]--- I can't even get the drivers from http://jusst.de/hg/mantis/ to compile: Kernel build directory is
[PATCH 15/15] - tm6000 hack with different demodulator parameter
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/hack.c
+++ b/drivers/staging/tm6000/hack.c
@@ -37,7 +37,6 @@ static inline int tm6000_snd_control_msg(struct
tm6000_core *dev, __u8 request,
static int pseudo_zl10353_pll(struct tm6000_core *tm6000_dev, struct
dvb_frontend_parameters *p)
{
-int ret;
u8 *data = kzalloc(50*sizeof(u8), GFP_KERNEL);
printk(KERN_ALERT should set frequency %u\n, p-frequency);
@@ -51,7 +50,7 @@ printk(KERN_ALERT and bandwith %u\n,
p-u.ofdm.bandwidth);
}
// init ZL10353
-data[0] = 0x0b;
+/*data[0] = 0x0b;
ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x501e, 0x00, data,
0x1);
msleep(15);
data[0] = 0x80;
@@ -159,7 +158,7 @@ printk(KERN_ALERT and bandwith %u\n,
p-u.ofdm.bandwidth);
msleep(15);
data[0] = 0x5a;
ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x651e,
0x00, data, 0x1);
-msleep(15);
+msleep(15)
data[0] = 0xe9;
ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x661e,
0x00, data, 0x1);
msleep(15);
@@ -189,7 +188,162 @@ printk(KERN_ALERT and bandwith %u\n,
p-u.ofdm.bandwidth);
msleep(15);
break;
}
-
+*/
+switch(p-u.ofdm.bandwidth) {
+case BANDWIDTH_8_MHZ:
+data[0] = 0x03;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+msleep(40);
+data[0] = 0x44;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+msleep(40);
+data[0] = 0x40;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+msleep(40);
+data[0] = 0x46;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x521e,0,data,1);
+msleep(40);
+data[0] = 0x15;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x531e,0,data,1);
+msleep(40);
+data[0] = 0x0f;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x541e,0,data,1);
+msleep(40);
+data[0] = 0x80;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+msleep(40);
+data[0] = 0x01;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+msleep(40);
+data[0] = 0x00;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+msleep(40);
+data[0] = 0x8b;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x631e,0,data,1);
+msleep(40);
+data[0] = 0x75;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xcc1e,0,data,1);
+msleep(40);
+data[0] = 0xe6; //0x19;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6c1e,0,data,1);
+msleep(40);
+data[0] = 0x09; //0xf7;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6d1e,0,data,1);
+msleep(40);
+data[0] = 0x67;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x651e,0,data,1);
+msleep(40);
+data[0] = 0xe5;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x661e,0,data,1);
+msleep(40);
+data[0] = 0x75;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5c1e,0,data,1);
+msleep(40);
+data[0] = 0x17;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5f1e,0,data,1);
+msleep(40);
+data[0] = 0x40;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5e1e,0,data,1);
+msleep(40);
+data[0] = 0x01;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x701e,0,data,1);
+msleep(40);
+break;
+case BANDWIDTH_7_MHZ:
+data[0] = 0x03;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+msleep(40);
+data[0] = 0x44;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+msleep(40);
+data[0] = 0x40;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+msleep(40);
+data[0] = 0x46;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x521e,0,data,1);
+msleep(40);
+data[0] = 0x15;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x531e,0,data,1);
+msleep(40);
+data[0] = 0x0f;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x541e,0,data,1);
+msleep(40);
+data[0] = 0x80;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+msleep(40);
+data[0] = 0x01;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+msleep(40);
+data[0] = 0x00;
+tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+msleep(40);
+data[0]
Re: [PATCH 13/15] - xc2028 bugfix for firmware 3.6 - Zarlink use without shift in DTV8 or DTV78
On Wed, Feb 3, 2010 at 3:36 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1122,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ if ((priv-ctrl.fname == xc3028L-v36.fw) (priv-ctrl.demod
== XC3028_FE_ZARLINK456) ((type DTV78) | (type DTV8)) ) {
+ demod = priv-ctrl.demod;
+ } else {
+ demod = priv-ctrl.demod + 200;
+ }
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
@@ -1123,8 +1135,8 @@ static int xc2028_set_params(struct dvb_frontend *fe,
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
*/
- if (type DTV7)
- demod += 500;
+ if (type DTV7)
+ demod += 500;
}
Independent of the validity of this patch, you should not be
submitting patches that have a mix of whitespace changes and actual
changes. In the above case (the if type DTV7 part), it looks like
these shouldn't have been included at all since it makes no functional
change.
It sounds like a nit-pick, but the reality is that its inclusion had
me staring at it for 30 seconds trying to figure out whether there was
an *actual* difference there or if it was purely whitespace.
return generic_set_freq(fe, p-frequency,
@@ -1240,6 +1252,10 @@ static const struct dvb_tuner_ops
xc2028_dvb_tuner_ops = {
.get_rf_strength = xc2028_signal,
.set_params = xc2028_set_params,
.sleep = xc2028_sleep,
+#if 0
+ int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
+ int (*get_status)(struct dvb_frontend *fe, u32 *status);
+#endif
};
Likewise, you should not be including unrelated changes in patches -
the above #if 0 section not only is never compiled in to the code
(presumably it is debug code), but it has nothing to do with the fix
this patch is claiming to address.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] - tm6000 hack with different demodulator parameter
On Wed, Feb 3, 2010 at 3:40 PM, Stefan Ringel stefan.rin...@arcor.de wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/staging/tm6000/hack.c +++ b/drivers/staging/tm6000/hack.c snip This patch shouldn't be merged at all. You should figure out the correct zl10353_config that is required, and hold off on submission until you have the correct fix. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] - zl10353
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/media/dvb/frontends/zl10353.h +++ b/drivers/media/dvb/frontends/zl10353.h @@ -45,6 +45,8 @@ struct zl10353_config /* clock control registers (0x51-0x54) */ u8 clock_ctl_1; /* default: 0x46 */ u8 pll_0; /* default: 0x15 */ + + int tm6000:1; }; Why is this being submitted as its own patch? It is code that is not used by *anything*. If you really did require a new field in the zl10353 config, that field should be added in the same patch as whatever requires it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/15] - tm6000.h
Am 03.02.2010 21:25, schrieb Mauro Carvalho Chehab:
This one is a very obscure patch. What are you doing this patch and why?
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
? different between git and hg ? not mine
enum tm6000_mode {
TM6000_MODE_UNKNOWN=0,
@@ -202,6 +211,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
I use that for tuner callback in tm6000-dvb -- frontend structure
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
@@ -209,7 +221,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev,
u8 reqtype, u8 req,
int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_init (struct tm6000_core *dev);
-int tm6000_init_after_firmware (struct tm6000_core *dev);
int tm6000_init_analog_mode (struct tm6000_core *dev);
int tm6000_init_digital_mode (struct tm6000_core *dev);
@@ -231,7 +242,12 @@ int tm6000_set_standard (struct tm6000_core *dev,
v4l2_std_id *norm);
int tm6000_i2c_register(struct tm6000_core *dev);
int tm6000_i2c_unregister(struct tm6000_core *dev);
+#if 1
/* In tm6000-queue.c */
+#if 0
+int tm6000_init_isoc(struct tm6000_core *dev, int max_packets);
+void tm6000_uninit_isoc(struct tm6000_core *dev);
+#endif
? different between git and hg ? not mine
int tm6000_v4l2_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -276,3 +292,4 @@ extern int tm6000_debug;
__FUNCTION__ , ##arg); } while (0)
+#endif
--
Stefan Ringel stefan.rin...@arcor.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 12/15] - tm6000 bugfix tuner reset time and tuner param
On Wed, Feb 3, 2010 at 3:31 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -221,12 +239,13 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info =
TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
{ USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
-static int tm6000_tuner_callback(void *ptr, int component, int command,
int arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
{
Why was the static removed from this declaration? What could possibly
be calling this from outside the module? And if there were something
that needed it, the declaration would have to be moved to a header
file so it could be included elsewhere (which should be in this same
patch).
Just to be clear, the fact that I am going through these patches
should not be taken personally - I'm just trying to give you some
advice on what you need to do to ensure the patches can be accepted
upstream and be reviewed with minimal cost to the other developers.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/15] - tm6000 analog digital switch
Am 03.02.2010 21:40, schrieb Mauro Carvalho Chehab: Stefan Ringel wrote: @@ -994,6 +995,13 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, Your emailer is damaging the patches. The above should be in the same line, otherwise the patch won't apply. It seems that you're using Thunderbird, right? User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0 You should really read the README.patches (http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches) before submitting your work. In particular, at the end of Part II, there are the procedures for submissions via email. It ends with: BE CAREFUL: several emailers including Thunderdird breaks long lines, causing patch corruption. In the specific case of Thunderbird, an extension is needed to send the patches, called Asalted Patches: https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/; So, please get the asalted-patches extension, apply it on your Thunderbird, review your patch series based on the contents of README.patches and re-submit. I use thunderbird 3, but the patch is for 2. It that compatible ? -- Stefan Ringel stefan.rin...@arcor.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 4/15] - tm6000.h
On Wed, Feb 3, 2010 at 3:50 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
Am 03.02.2010 21:25, schrieb Mauro Carvalho Chehab:
This one is a very obscure patch. What are you doing this patch and why?
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
? different between git and hg ? not mine
Stefan,
The patches *you submitted* included this #if 1. Regardless of
whether it's differences between git and hg or some other weird merge
bug, you are responsible for the patches you submit. You should be
reviewing each patch before sending it, and if it contains things you
do not understand why they are there, then you need to resolve those
inconsistencies before submitting the patch.
Reviewing each patch individually before sending also helps avoid
avoid things like submitting patches which make arbitrary/unnecessary
whitespace changes.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] - zl10353
Am 03.02.2010 21:49, schrieb Devin Heitmueller: On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/media/dvb/frontends/zl10353.h +++ b/drivers/media/dvb/frontends/zl10353.h @@ -45,6 +45,8 @@ struct zl10353_config /* clock control registers (0x51-0x54) */ u8 clock_ctl_1; /* default: 0x46 */ u8 pll_0;/* default: 0x15 */ + + int tm6000:1; }; Why is this being submitted as its own patch? It is code that is not used by *anything*. If you really did require a new field in the zl10353 config, that field should be added in the same patch as whatever requires it. Devin Actually doesn't work zl10353 with tm6010, it have a little different between a few registers, so I think that I use it. for example: zl10353 use 0x64 , but not mine (0x63) register 0x5f is 0x17 not 0x13 register 0x5e is 0x40 not 0x00 for auto and tuner go is 0x70 not 0x71 the other register are ok. I have no idea how I can set it. -- Stefan Ringel stefan.rin...@arcor.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 12/15] - tm6000 bugfix tuner reset time and tuner param
Am 03.02.2010 21:52, schrieb Devin Heitmueller:
On Wed, Feb 3, 2010 at 3:31 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -221,12 +239,13 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info =
TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
{ USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
-static int tm6000_tuner_callback(void *ptr, int component, int command,
int arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
{
Why was the static removed from this declaration? What could possibly
be calling this from outside the module? And if there were something
that needed it, the declaration would have to be moved to a header
file so it could be included elsewhere (which should be in this same
patch).
Just to be clear, the fact that I am going through these patches
should not be taken personally - I'm just trying to give you some
advice on what you need to do to ensure the patches can be accepted
upstream and be reviewed with minimal cost to the other developers.
Devin
1. It broke by building.
2. callback for dvb frontend (tm6000-dvb.c) so can the tuner a reset
send if it goes in DVB mode (it must reload the firmware)
--
Stefan Ringel stefan.rin...@arcor.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 9/15] - tm6000 analog digital switch
Stefan Ringel wrote: Am 03.02.2010 21:40, schrieb Mauro Carvalho Chehab: So, please get the asalted-patches extension, apply it on your Thunderbird, review your patch series based on the contents of README.patches and re-submit. I use thunderbird 3, but the patch is for 2. It that compatible ? Yes. I have it applied to Fedora 12 thunderbird 3, and to RHEL5 thunderbird 2. It works fine on both. -- 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: [PATCH 4/15] - tm6000.h
Stefan Ringel wrote:
Am 03.02.2010 21:25, schrieb Mauro Carvalho Chehab:
This one is a very obscure patch. What are you doing this patch and why?
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
? different between git and hg ? not mine
On git, all #if 0/#if 1 are stripped (except if an explicit comment /* keep */
is added). We do this way to avoid polluting upstream kernel code with temporary
developers only code.
enum tm6000_mode {
TM6000_MODE_UNKNOWN=0,
@@ -202,6 +211,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
I use that for tuner callback in tm6000-dvb -- frontend structure
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
@@ -209,7 +221,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev,
u8 reqtype, u8 req,
int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index);
int tm6000_init (struct tm6000_core *dev);
-int tm6000_init_after_firmware (struct tm6000_core *dev);
int tm6000_init_analog_mode (struct tm6000_core *dev);
int tm6000_init_digital_mode (struct tm6000_core *dev);
@@ -231,7 +242,12 @@ int tm6000_set_standard (struct tm6000_core *dev,
v4l2_std_id *norm);
int tm6000_i2c_register(struct tm6000_core *dev);
int tm6000_i2c_unregister(struct tm6000_core *dev);
+#if 1
/* In tm6000-queue.c */
+#if 0
+int tm6000_init_isoc(struct tm6000_core *dev, int max_packets);
+void tm6000_uninit_isoc(struct tm6000_core *dev);
+#endif
? different between git and hg ? not mine
int tm6000_v4l2_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -276,3 +292,4 @@ extern int tm6000_debug;
__FUNCTION__ , ##arg); } while (0)
+#endif
--
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: [PATCH 1/15] - tm6000 build hunk
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -32,7 +32,7 @@ #include tm6000.h #include tm6000-regs.h #include tuner-xc2028.h -#include tuner-xc5000.h +#include xc5000.h #define TM6000_BOARD_UNKNOWN0 #define TM5600_BOARD_GENERIC1 -- Stefan Ringel stefan.rin...@arcor.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] radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
Hello Roel,
no, the default value of retval makes no difference to the function.
Retval is set by si470x_disconnect_check and si470x_set_register.
After each call, retval is checked.
There is no need to reset it passed.
The only reason, there is a default value is my static code checker, saying
variables should have default values.
Setting it to -EINVAL seems more reasonable to me than setting it 0.
In fact the patch would bring up the warning on setting default values again.
Bye,
Toby
Am Mittwoch 03 Februar 2010 20:48:05 schrieb Roel Kluin:
The -EINVAL was overwritten by the si470x_disconnect_check().
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
Is this needed?
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 4da0f15..65b4a92 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -748,12 +748,13 @@ static int si470x_vidioc_s_tuner(struct file *file,
void *priv,
struct v4l2_tuner *tuner)
{
struct si470x_device *radio = video_drvdata(file);
- int retval = -EINVAL;
+ int retval;
/* safety checks */
retval = si470x_disconnect_check(radio);
if (retval)
goto done;
+ retval = -EINVAL;
if (tuner-index != 0)
goto done;
--
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] V4L HD PVR updates
On Wed, Feb 03, 2010 at 01:37:19PM -0200, Mauro Carvalho Chehab wrote: Janne Grunau wrote: Hi Mauro, please pull from git://git.jannau.net/linux hdpvr Didn't work: $ git pull git://git.jannau.net/linux fatal: The remote end hung up unexpectedly sorry, missing git-daemon-export-ok. fixed, please try again. Janne -- 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] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Hi Mauro,
Mauro Carvalho Chehab wrote:
Hi Oliver,
Oliver Endriss wrote:
Mauro,
Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene
It were not an easy to work on this changeset, since it hit a bug at
gentree.pl script.
Basically, this drivers use #elseif directive instead of #elif, making
gentree.pl to
die, and generating broken converted patches. It took some time to discover
and fix
the bug.
Anyway, I've applied the converted patches on a temporary git tree:
http://git.linuxtv.org/mchehab/ngene.git
Please double check if everything is ok there.
I noticed that all '#if 0' code has been stripped.
While this is ok (and desired) for the kernel, this stuff should be
preserved at the development trees. This code might be useful, whenever
addional features or cards are to be added.
I had to add a hack at one of the patches, due to the frontend
incompatibilities
at stv090x, starting on this changeset:
Author: Matthias Benesch two...@freenet.de
Date: Sat Dec 19 12:48:22 2009 -0300
V4L/DVB: ngene: Added Media-Pointer MP-S2/CineS2 DVB-S2 Twin Tuner
The hack were removed on this one:
Author: Oliver Endriss o.endr...@gmx.de
Date: Mon Feb 1 22:01:31 2010 -0300
V4L/DVB: ngene: Adapt to current frontend drivers
There was no problem with HG, because
- the first changeset was applied before the incompatibility occurred
- the second was applied as a fix for the incompatibility
I don't know how this could be avoided. Except for dropping the HG tree
and creating a new one.
After applying all the patches, I'm getting this error:
drivers/media/dvb/ngene/ngene-core.c: In function ‘ngene_i2c_init’:
drivers/media/dvb/ngene/ngene-core.c:860: warning: passing argument 1 of
‘__mutex_init’ from incompatible pointer type
On this line:
mutex_init(adap-bus_lock);
Strange, I do not get any warnings with kernel 2.6.32.3 and gcc 4.1.2.
The line causing the problems is
mutex_init(adap-bus_lock);
mutex.h:
# define mutex_init(mutex) \
...
__mutex_init((mutex), #mutex, __key); \
...
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
adap is a pointer to 'struct i2c_adapter':
i2c.h:
struct i2c_adapter {
...
struct mutex bus_lock;
...
I do not see any problem here.
Something must have been changed in recent git.
Could you try if
#include linux/mutex.h
helps?
The final diff also hit a few troubles at the driver, as pointed by
checkpatch.pl:
WARNING: Use #include linux/io.h instead of asm/io.h
#113: FILE: drivers/media/dvb/ngene/ngene-core.c:35:
+#include asm/io.h
WARNING: line over 80 characters
#348: FILE: drivers/media/dvb/ngene/ngene-core.c:270:
+ HOST_TO_NGENE, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
WARNING: line over 80 characters
#352: FILE: drivers/media/dvb/ngene/ngene-core.c:274:
+ NGENE_TO_HOST, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
ERROR: that open brace { should be on the previous line
#1693: FILE: drivers/media/dvb/ngene/ngene-core.c:1615:
+ u8 tsin4_config[6] =
+ {3072 / 64, 3072 / 64, 0, 3072 / 64, 3072 / 64, 0};
ERROR: that open brace { should be on the previous line
#1695: FILE: drivers/media/dvb/ngene/ngene-core.c:1617:
+ u8 default_config[6] =
+ {4096 / 64, 4096 / 64, 0, 2048 / 64, 2048 / 64, 0};
WARNING: Use #include linux/scatterlist.h instead of asm/scatterlist.h
#2142: FILE: drivers/media/dvb/ngene/ngene.h:32:
+#include asm/scatterlist.h
WARNING: do not add new typedefs
#2313: FILE: drivers/media/dvb/ngene/ngene.h:203:
+typedef struct EVENT_BUFFER *PEVENT_BUFFER;
WARNING: do not add new typedefs
#2601: FILE: drivers/media/dvb/ngene/ngene.h:491:
+typedef struct HW_SCATTER_GATHER_ELEMENT *PHW_SCATTER_GATHER_ELEMENT;
WARNING: do not add new typedefs
#2602: FILE: drivers/media/dvb/ngene/ngene.h:492:
+typedef struct FWRB *PFWRB;
WARNING: do not add new typedefs
#2667: FILE: drivers/media/dvb/ngene/ngene.h:557:
+typedef struct {
total: 2 errors, 8 warnings, 2935 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Now I remember, why I never wanted to submit anything to the kernel
again. As always it was a pleasure to work for this stupid tool. :-(
The two 80 col warnings and the two errors don't seem relevant, but please
fix the other warnings.
As usual, after receiving your fixes for the above, I'll review the driver
manually.
Except for the mutex_init() problem, everything should be fixed with
this changeset: http://linuxtv.org/hg/~endriss/ngene/rev/8ad7907e3020
Please check.
Oliver
--
VDR Remote
Re: [PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Am 03.02.2010 21:02, schrieb Mauro Carvalho Chehab:
...
ERROR: that open brace { should be on the previous line
#1693: FILE: drivers/media/dvb/ngene/ngene-core.c:1615:
+ u8 tsin4_config[6] =
+ {3072 / 64, 3072 / 64, 0, 3072 / 64, 3072 / 64, 0};
ERROR: that open brace { should be on the previous line
#1695: FILE: drivers/media/dvb/ngene/ngene-core.c:1617:
+ u8 default_config[6] =
+ {4096 / 64, 4096 / 64, 0, 2048 / 64, 2048 / 64, 0};
...
WARNING: do not add new typedefs
#2313: FILE: drivers/media/dvb/ngene/ngene.h:203:
+typedef struct EVENT_BUFFER *PEVENT_BUFFER;
WARNING: do not add new typedefs
#2601: FILE: drivers/media/dvb/ngene/ngene.h:491:
+typedef struct HW_SCATTER_GATHER_ELEMENT *PHW_SCATTER_GATHER_ELEMENT;
WARNING: do not add new typedefs
#2602: FILE: drivers/media/dvb/ngene/ngene.h:492:
+typedef struct FWRB *PFWRB;
WARNING: do not add new typedefs
#2667: FILE: drivers/media/dvb/ngene/ngene.h:557:
+typedef struct {
total: 2 errors, 8 warnings, 2935 lines checked
Sorry but the kernel guys seems to have a lot of time to waste, if they have
time to care about
these warnings ;)
--
Helmut Auer, hel...@helmutauer.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: [PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Oliver Endriss wrote:
Hi Mauro,
Mauro Carvalho Chehab wrote:
Hi Oliver,
Oliver Endriss wrote:
Mauro,
Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene
It were not an easy to work on this changeset, since it hit a bug at
gentree.pl script.
Basically, this drivers use #elseif directive instead of #elif, making
gentree.pl to
die, and generating broken converted patches. It took some time to discover
and fix
the bug.
Anyway, I've applied the converted patches on a temporary git tree:
http://git.linuxtv.org/mchehab/ngene.git
Please double check if everything is ok there.
I noticed that all '#if 0' code has been stripped.
While this is ok (and desired) for the kernel, this stuff should be
preserved at the development trees. This code might be useful, whenever
addional features or cards are to be added.
As Douglas will be pulling from -hg, the #if's will be there.
I had to add a hack at one of the patches, due to the frontend
incompatibilities
at stv090x, starting on this changeset:
Author: Matthias Benesch two...@freenet.de
Date: Sat Dec 19 12:48:22 2009 -0300
V4L/DVB: ngene: Added Media-Pointer MP-S2/CineS2 DVB-S2 Twin Tuner
The hack were removed on this one:
Author: Oliver Endriss o.endr...@gmx.de
Date: Mon Feb 1 22:01:31 2010 -0300
V4L/DVB: ngene: Adapt to current frontend drivers
There was no problem with HG, because
- the first changeset was applied before the incompatibility occurred
- the second was applied as a fix for the incompatibility
I don't know how this could be avoided. Except for dropping the HG tree
and creating a new one.
A good idea is to split the Kconfig/Makefile changes into a separate patch.
At the final submission, all that is needed is to move it to the end of the
patch series.
Anyway, the hack I did wouldn't cause any harm, and will prevent breaking the
useful
bisect tool, when tracking for some bugs on kernel.
After applying all the patches, I'm getting this error:
drivers/media/dvb/ngene/ngene-core.c: In function ‘ngene_i2c_init’:
drivers/media/dvb/ngene/ngene-core.c:860: warning: passing argument 1 of
‘__mutex_init’ from incompatible pointer type
On this line:
mutex_init(adap-bus_lock);
Strange, I do not get any warnings with kernel 2.6.32.3 and gcc 4.1.2.
The line causing the problems is
mutex_init(adap-bus_lock);
mutex.h:
# define mutex_init(mutex) \
...
__mutex_init((mutex), #mutex, __key); \
...
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
adap is a pointer to 'struct i2c_adapter':
i2c.h:
struct i2c_adapter {
...
struct mutex bus_lock;
...
I do not see any problem here.
Ah, the realtime patches:
drivers/i2c/i2c-core.c: rt_mutex_init(adap-bus_lock);
Several mutexes are currently changing, to improve kernel responsiveness.
Something must have been changed in recent git.
Could you try if
#include linux/mutex.h
helps?
It doesn't. It is really a bad idea to initialize an i2c mutex inside the
driver.
Instead, the driver should be calling i2c_register_adapter().
There are other initializations there that i2c core needs to do, in order
to work properly.
The final diff also hit a few troubles at the driver, as pointed by
checkpatch.pl:
WARNING: Use #include linux/io.h instead of asm/io.h
#113: FILE: drivers/media/dvb/ngene/ngene-core.c:35:
+#include asm/io.h
WARNING: line over 80 characters
#348: FILE: drivers/media/dvb/ngene/ngene-core.c:270:
+HOST_TO_NGENE, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
WARNING: line over 80 characters
#352: FILE: drivers/media/dvb/ngene/ngene-core.c:274:
+NGENE_TO_HOST, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
ERROR: that open brace { should be on the previous line
#1693: FILE: drivers/media/dvb/ngene/ngene-core.c:1615:
+u8 tsin4_config[6] =
+{3072 / 64, 3072 / 64, 0, 3072 / 64, 3072 / 64, 0};
ERROR: that open brace { should be on the previous line
#1695: FILE: drivers/media/dvb/ngene/ngene-core.c:1617:
+u8 default_config[6] =
+{4096 / 64, 4096 / 64, 0, 2048 / 64, 2048 / 64, 0};
WARNING: Use #include linux/scatterlist.h instead of asm/scatterlist.h
#2142: FILE: drivers/media/dvb/ngene/ngene.h:32:
+#include asm/scatterlist.h
WARNING: do not add new typedefs
#2313: FILE: drivers/media/dvb/ngene/ngene.h:203:
+typedef struct EVENT_BUFFER *PEVENT_BUFFER;
WARNING: do not add new typedefs
#2601: FILE: drivers/media/dvb/ngene/ngene.h:491:
+typedef struct HW_SCATTER_GATHER_ELEMENT *PHW_SCATTER_GATHER_ELEMENT;
WARNING: do not add new typedefs
#2602: FILE: drivers/media/dvb/ngene/ngene.h:492:
+typedef struct FWRB *PFWRB;
WARNING: do not add new typedefs
#2667: FILE:
Re: [PATCH] AVerTV MCE 116 Plus radio
On Tue, 2010-02-02 at 13:29 -0200, Mauro Carvalho Chehab wrote:
Hi Andy,
This patch has never been applied or nacked. From your last comment, it
seems that you're waiting for Aleksandr Signed-of-by:.
If this is still the case, I suggest you to wait for a couple days. If he
doesn't
send it, it is safe to add it without his SOB, since it is really a trivial
change.
I'd like to look at this one once more. The extra 50 ms and another
reset may be avoidable.
cx25840-core.c:set_input() gets called for s_frequency so I'd like not
to add 50 ms if not needed.
Regards,
Andy
Cheers,
Mauro.
Andy Walls wrote:
On Sun, 2009-10-11 at 04:01 +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:11:59AM +0300, Aleksandr V. Piskunov wrote:
On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
Added FM radio support to Avermedia AVerTV MCE 116 Plus card
What leaves me puzzled, radio only works ok with ivtv newi2c=1
With default newi2c audio is tinny, metallic, with some strange static.
Similar problem with pvr-150 was reported years ago, guess issue is still
unresolved, perhaps something with cx25840..
This particular tinny audio problem is definitely I2C speed related, to
be
more precise, audio only goes bad if i2c-algo-bit is being run with udelay
less than 15, i.e. i2c bus frequency is higher than 30 KHz.
So with default udelay=10 or udelay=5 (optimal for IR reciever on that
board)
radio goes bad. Running with newi2c=1 is ok, but again it isn't optimal
for IR
reciever on AVerTV M116.
I2C reads/writes to cx25840 themself are ok, verified using register
readback
after each write/write4. Problem seems to be that with cx25840 register
writes
coming too fast on higher i2c bus speed, switching register 0x808 _from_
TV standard autodetection mode (0xff) _to_ FM radio mode (0xf9) leaves
chip
audio detection routine in inconsistent state.
The only solution I found is to do standard routine (assert_reset + write +
deassert_reset) followed by 50ms delay and another reset.
Following patch works_for_me, can be improved to only delay/doublereset
when
really needed, etc. Andy, could you comment/review?
Aleksandr,
Could you provide your Signed-off-by for this patch? I'm going to
commit it as is.
Thanks,
Andy
diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -626,7 +642,13 @@
if (state-radio) {
cx25840_write(client, 0x808, 0xf9);
cx25840_write(client, 0x80b, 0x00);
- }
+ /* Double reset cx2384x after setting FM radio mode, helps to
+ avoid tinny audio when ivtv I2C bus is being run on
+ frequency higher than 30 KHz */
+ cx25840_and_or(client, 0x810, ~0x01, 0);
+ msleep(50);
+ cx25840_and_or(client, 0x810, ~0x01, 1);
+ }
else if (std V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
that causes audio to drop out. For these models the
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] V4L HD PVR updates
Janne Grunau wrote: On Wed, Feb 03, 2010 at 01:37:19PM -0200, Mauro Carvalho Chehab wrote: Janne Grunau wrote: Hi Mauro, please pull from git://git.jannau.net/linux hdpvr Didn't work: $ git pull git://git.jannau.net/linux fatal: The remote end hung up unexpectedly sorry, missing git-daemon-export-ok. fixed, please try again. Worked, thanks! -- 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: [PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Hi,
Mauro Carvalho Chehab wrote:
Oliver Endriss wrote:
Mauro Carvalho Chehab wrote:
Oliver Endriss wrote:
Mauro,
Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene
It were not an easy to work on this changeset, since it hit a bug at
gentree.pl script.
Basically, this drivers use #elseif directive instead of #elif, making
gentree.pl to
die, and generating broken converted patches. It took some time to
discover and fix
the bug.
Anyway, I've applied the converted patches on a temporary git tree:
http://git.linuxtv.org/mchehab/ngene.git
Please double check if everything is ok there.
I noticed that all '#if 0' code has been stripped.
While this is ok (and desired) for the kernel, this stuff should be
preserved at the development trees. This code might be useful, whenever
addional features or cards are to be added.
As Douglas will be pulling from -hg, the #if's will be there.
Ok, fine.
I had to add a hack at one of the patches, due to the frontend
incompatibilities
at stv090x, starting on this changeset:
Author: Matthias Benesch two...@freenet.de
Date: Sat Dec 19 12:48:22 2009 -0300
V4L/DVB: ngene: Added Media-Pointer MP-S2/CineS2 DVB-S2 Twin Tuner
The hack were removed on this one:
Author: Oliver Endriss o.endr...@gmx.de
Date: Mon Feb 1 22:01:31 2010 -0300
V4L/DVB: ngene: Adapt to current frontend drivers
There was no problem with HG, because
- the first changeset was applied before the incompatibility occurred
- the second was applied as a fix for the incompatibility
I don't know how this could be avoided. Except for dropping the HG tree
and creating a new one.
A good idea is to split the Kconfig/Makefile changes into a separate patch.
At the final submission, all that is needed is to move it to the end of the
patch series.
Ok.
Anyway, the hack I did wouldn't cause any harm, and will prevent breaking the
useful
bisect tool, when tracking for some bugs on kernel.
After applying all the patches, I'm getting this error:
drivers/media/dvb/ngene/ngene-core.c: In function ‘ngene_i2c_init’:
drivers/media/dvb/ngene/ngene-core.c:860: warning: passing argument 1 of
‘__mutex_init’ from incompatible pointer type
On this line:
mutex_init(adap-bus_lock);
Strange, I do not get any warnings with kernel 2.6.32.3 and gcc 4.1.2.
The line causing the problems is
mutex_init(adap-bus_lock);
mutex.h:
# define mutex_init(mutex) \
...
__mutex_init((mutex), #mutex, __key); \
...
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
adap is a pointer to 'struct i2c_adapter':
i2c.h:
struct i2c_adapter {
...
struct mutex bus_lock;
...
I do not see any problem here.
Ah, the realtime patches:
drivers/i2c/i2c-core.c: rt_mutex_init(adap-bus_lock);
Several mutexes are currently changing, to improve kernel responsiveness.
Something must have been changed in recent git.
Could you try if
#include linux/mutex.h
helps?
It doesn't. It is really a bad idea to initialize an i2c mutex inside the
driver.
Ack. See below.
Instead, the driver should be calling i2c_register_adapter().
No, i2c_register_adapter() is a static function.
i2c_add_adapter is the right way. As it calls i2c_register_adapter(),
mutex_init() can be removed, and everything is fine.
There are other initializations there that i2c core needs to do, in order
to work properly.
The final diff also hit a few troubles at the driver, as pointed by
checkpatch.pl:
WARNING: Use #include linux/io.h instead of asm/io.h
#113: FILE: drivers/media/dvb/ngene/ngene-core.c:35:
+#include asm/io.h
WARNING: line over 80 characters
#348: FILE: drivers/media/dvb/ngene/ngene-core.c:270:
+ HOST_TO_NGENE, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
WARNING: line over 80 characters
#352: FILE: drivers/media/dvb/ngene/ngene-core.c:274:
+ NGENE_TO_HOST, buf[0], buf[1], buf[2], buf[3], buf[4], buf[5],
buf[6], buf[7]);
ERROR: that open brace { should be on the previous line
#1693: FILE: drivers/media/dvb/ngene/ngene-core.c:1615:
+ u8 tsin4_config[6] =
+ {3072 / 64, 3072 / 64, 0, 3072 / 64, 3072 / 64, 0};
ERROR: that open brace { should be on the previous line
#1695: FILE: drivers/media/dvb/ngene/ngene-core.c:1617:
+ u8 default_config[6] =
+ {4096 / 64, 4096 / 64, 0, 2048 / 64, 2048 / 64, 0};
WARNING: Use #include linux/scatterlist.h instead of asm/scatterlist.h
#2142: FILE: drivers/media/dvb/ngene/ngene.h:32:
+#include asm/scatterlist.h
WARNING: do not add new typedefs
#2313: FILE: drivers/media/dvb/ngene/ngene.h:203:
+typedef struct EVENT_BUFFER *PEVENT_BUFFER;
WARNING:
Re: [PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Hi,
Oliver Endriss wrote:
Mauro Carvalho Chehab wrote:
Oliver Endriss wrote:
Mauro Carvalho Chehab wrote:
After applying all the patches, I'm getting this error:
drivers/media/dvb/ngene/ngene-core.c: In function ‘ngene_i2c_init’:
drivers/media/dvb/ngene/ngene-core.c:860: warning: passing argument 1 of
‘__mutex_init’ from incompatible pointer type
On this line:
mutex_init(adap-bus_lock);
Strange, I do not get any warnings with kernel 2.6.32.3 and gcc 4.1.2.
The line causing the problems is
mutex_init(adap-bus_lock);
mutex.h:
# define mutex_init(mutex) \
...
__mutex_init((mutex), #mutex, __key); \
...
extern void __mutex_init(struct mutex *lock, const char *name,
struct lock_class_key *key);
adap is a pointer to 'struct i2c_adapter':
i2c.h:
struct i2c_adapter {
...
struct mutex bus_lock;
...
I do not see any problem here.
Ah, the realtime patches:
drivers/i2c/i2c-core.c: rt_mutex_init(adap-bus_lock);
Several mutexes are currently changing, to improve kernel responsiveness.
Something must have been changed in recent git.
Could you try if
#include linux/mutex.h
helps?
It doesn't. It is really a bad idea to initialize an i2c mutex inside the
driver.
Ack. See below.
Instead, the driver should be calling i2c_register_adapter().
No, i2c_register_adapter() is a static function.
i2c_add_adapter is the right way. As it calls i2c_register_adapter(),
mutex_init() can be removed, and everything is fine.
I committed a fix for both I2C issues.
Please pull http://linuxtv.org/hg/~endriss/ngene/rev/d3b4eb4a7bd9
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
Tobias Lorenz wrote: Hello Roel, no, the default value of retval makes no difference to the function. Retval is set by si470x_disconnect_check and si470x_set_register. After each call, retval is checked. There is no need to reset it passed. The only reason, there is a default value is my static code checker, saying variables should have default values. Setting it to -EINVAL seems more reasonable to me than setting it 0. In fact the patch would bring up the warning on setting default values again. Well, your static code checker is then broken ;) struct si470x_device *radio = video_drvdata(file); -int retval = -EINVAL; +int retval; /* safety checks */ retval = si470x_disconnect_check(radio); You may just do then: int retval = si470x_disconnect_check(radio); if (retval) goto done; +retval = -EINVAL; if (tuner-index != 0) goto done; -- 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 -- 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: Any saa711x users out there?
On Tue, 2010-02-02 at 17:51 -0500, Devin Heitmueller wrote: Hello all, I am doing some quality improvements for a couple of the em28xx/saa7113 designs, and I found a pretty serious problem which appears to have been there for some time. In fact, the regression was introduced when the saa7115 support was added in 2005 (hg revision 2750). This change resulted in the anti-alias filtering being disabled by default for the saa7113 (the saa7115_init_misc block clears bit 7 of register 0x02). Without this change, vertical lines appear in the chroma on a fixed interval. The big issue is that the driver is shared with other saa7113 products, as well as products that have the saa7111, saa7114, and saa7115. So I have to figure out whether to just force on the AA filter for the saa7113, or whether it should be enabled for the others, or whether I can even turn it on for saa7113 in general or need to hack something in there to only do it for the two or three products I am testing with. So here's where I could use some help: If you have a product that uses one of the above chips, please speak up. I will be setting up a test tree where people can try out the change and see if it makes their situation better, worse, or no change. I have a PVR-350 with an SAA7115 IIRC. Other ivtv boards have SAA7114 chips. I don't see any in ivtv-cards.c that have an SAA7113 explcitily listed. Whether or not an anti-alias filter is needed is a completely knowable answer given: 1. The TV norm and hence the Luma and Chroma signal characteristics 2. The A/D sample rate 3. The parameters of any decimations or non-integer resampling being performed If you don't undersample, i.e. Fs/2 single-sided BW of the signal being sampled, then you don't need an anti alias filter before you sample, otherwise you do. The same sort of thing goes for decimation of digital samples. If the decimation is going to cause aliases to fold down into the spectrum, you need a digital LPF before the decimation to band limit the digital signal. This should not be a user control, this should be a configuration setting that is knowable by the bridge driver and/or the module driving the SAA7113. With all that said, if you have a baseband Luma or Chroma signal with strong spurious high frequency components (crappy source, or you're overdriving the front end and getting intermods), then keep the anti-alias filter turned on as the assumption of a bandlimited input signal is violated in this case. In the SAA7113 the anti-alias filter introduces a delay of 50 ns. At 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of delay. Just turn it on in and leave it on in the SAA7113 to handle the unexpected input signal case. Regards, Andy Devin -- 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] fix memory leak media IR keytable
Signed-off-by: Yoichi Yuasa yu...@linux-mips.org
---
drivers/media/IR/ir-keytable.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index b521ed9..44501d9 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -422,8 +422,10 @@ int ir_input_register(struct input_dev *input_dev,
ir_dev-rc_tab.size = ir_roundup_tablesize(rc_tab-size);
ir_dev-rc_tab.scan = kzalloc(ir_dev-rc_tab.size *
sizeof(struct ir_scancode), GFP_KERNEL);
- if (!ir_dev-rc_tab.scan)
+ if (!ir_dev-rc_tab.scan) {
+ kfree(ir_dev);
return -ENOMEM;
+ }
IR_dprintk(1, Allocated space for %d keycode entries (%zd bytes)\n,
ir_dev-rc_tab.size,
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/15] - zl10353
Stefan Ringel wrote:
Am 03.02.2010 21:49, schrieb Devin Heitmueller:
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/dvb/frontends/zl10353.h
+++ b/drivers/media/dvb/frontends/zl10353.h
@@ -45,6 +45,8 @@ struct zl10353_config
/* clock control registers (0x51-0x54) */
u8 clock_ctl_1; /* default: 0x46 */
u8 pll_0;/* default: 0x15 */
+
+ int tm6000:1;
};
Why is this being submitted as its own patch? It is code that is not
used by *anything*. If you really did require a new field in the
zl10353 config, that field should be added in the same patch as
whatever requires it.
Devin
Hi Stefan,
Due to the problem with your emailer, most of the patches failed:
2/15 3/15 4/15 5/15 6/15 7/15 2/15 (the second one 8th in the sequence)
9/15 11/15 12/15 13/15 and 15/15.
In brief, only two patches applied: the 1/15 and a patch also called 2/15
(I suspect it is the 10th patch).
So, after reading our comments, reading README.patches and applying the
Asaulted-patches extension to your thunderbird, please resubmit the patches.
Actually doesn't work zl10353 with tm6010, it have a little different
between a few registers, so I think that I use it.
for example:
zl10353 use 0x64 , but not mine (0x63)
register 0x5f is 0x17 not 0x13
register 0x5e is 0x40 not 0x00 for auto
and tuner go is 0x70 not 0x71
the other register are ok. I have no idea how I can set it.
I agree with Devin that the patch 14/15 shouldn't be applied as-is.
I have no idea why zl10353 needs a different setup, but you don't need
to add an extra parameter to identify the bridge driver. There's a field
at struct i2c_client that can be used: i2c_adapter-id.
This is already initialized with I2C_HW_B_TM6000 (although it currently
uses a fake value).
It is still ugly to do some specific initialization like this, but, when
we have no other glue, due to the lack of datasheets, this is a better
alternative than adding an extra fake parameter at the config struct.
All you need is some code like:
diff --git a/linux/drivers/media/dvb/frontends/zl10353.c
b/linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c
+++ b/linux/drivers/media/dvb/frontends/zl10353.c
@@ -597,6 +597,10 @@ static int zl10353_init(struct dvb_front
zl10353_read_register(state, 0x51) != zl10353_reset_attach[2]) {
rc = zl10353_write(fe, zl10353_reset_attach,
sizeof(zl10353_reset_attach));
+
+ if (state-i2c-id == I2C_HW_B_TM6000) {
+ /* Do special init needed by tm6000 driver */
+ }
#if 1
if (debug_regs)
zl10353_dump_regs(fe);
diff --git a/linux/drivers/staging/tm6000/tm6000-i2c.c
b/linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c
@@ -33,8 +33,6 @@
#include tuner-xc2028.h
-/*FIXME: Hack to avoid needing to patch i2c-id.h */
-#define I2C_HW_B_TM6000 I2C_HW_B_EM28XX
/* --- */
static unsigned int i2c_debug = 0;
diff --git a/linux/include/linux/i2c-id.h b/linux/include/linux/i2c-id.h
--- a/linux/include/linux/i2c-id.h
+++ b/linux/include/linux/i2c-id.h
@@ -42,6 +42,7 @@
#define I2C_HW_B_AU08280x010023 /* auvitek au0828 usb bridge */
#define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */
#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */
+#define I2C_HW_B_TM60000x010026 /* TM5600/6000/6010 video
bridge */
/* --- SGI adapters*/
#define I2C_HW_SGI_VINO0x16
--
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: ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?
On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote: Hi, I'm writing some code repacking the program stream that ivtv delivers into a transport stream (BTW: is there existing code for this?). Buy a CX23418 based board. That chip's firmware can produce a TS. I think Compro and LeadTek cards are available in Europe and are supported by the cx18 driver. Since many players needs the PCR I would like to use the SCR of the PS and place it in the adaption field of the TS (if wikipedia [1] and my interpretation of it is correct it should be the same). I stumbled upon the ps-analyzer.cpp in the test-directory of the ivtv-utils (1.4.0). From line 190 to 198 the SCR and SCR extension are extracted from the PS-header. But referring to [2] the SCR extension has 9 bits, the highest 2 bits in the fifth byte after the sync bytes and the lower 7 bits in the sixth byte. The last bit is a marker bit (always 1). So instead of scr_ext = (hdr[4] 0x1) 8; scr_ext |= hdr[5]; I think it should be scr_ext = (unsigned)(hdr[4] 0x3) 7; scr_ext |= (hdr[5] 0xfe) 1; Given the non-authoritative MPEG-2 documents I have, yes, you appear to be correct on this. Please keep in mind that ps-analyzer.cpp is simply a debug tool from an ivtv developer perspective. You base prodcution software off of it at your own risk. :) And the bitrate is coded in the next 22 bits, so it should be mux_rate = (unsigned)(hdr[6]) 14; mux_rate |= (unsigned)(hdr[7]) 6; mux_rate |= (unsigned)(hdr[8] 0xfc) 2; Am I correct? I did not check this one, but I would not be surprised if ps-analyzer had this wrong too. Regards, Andy Regards, Lars. [1] http://en.wikipedia.org/wiki/Presentation_time_stamp [2] http://en.wikipedia.org/wiki/MPEG_program_stream -- -- 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: ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?
On Thursday 04 February 2010 04:16:03 Andy Walls wrote: On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote: Hi, I'm writing some code repacking the program stream that ivtv delivers into a transport stream (BTW: is there existing code for this?). Buy a CX23418 based board. That chip's firmware can produce a TS. I think Compro and LeadTek cards are available in Europe and are supported by the cx18 driver. Since many players needs the PCR I would like to use the SCR of the PS and place it in the adaption field of the TS (if wikipedia [1] and my interpretation of it is correct it should be the same). I stumbled upon the ps-analyzer.cpp in the test-directory of the ivtv-utils (1.4.0). From line 190 to 198 the SCR and SCR extension are extracted from the PS-header. But referring to [2] the SCR extension has 9 bits, the highest 2 bits in the fifth byte after the sync bytes and the lower 7 bits in the sixth byte. The last bit is a marker bit (always 1). So instead of scr_ext = (hdr[4] 0x1) 8; scr_ext |= hdr[5]; I think it should be scr_ext = (unsigned)(hdr[4] 0x3) 7; scr_ext |= (hdr[5] 0xfe) 1; Given the non-authoritative MPEG-2 documents I have, yes, you appear to be correct on this. Please keep in mind that ps-analyzer.cpp is simply a debug tool from an ivtv developer perspective. You base prodcution software off of it at your own risk. :) And the bitrate is coded in the next 22 bits, so it should be mux_rate = (unsigned)(hdr[6]) 14; mux_rate |= (unsigned)(hdr[7]) 6; mux_rate |= (unsigned)(hdr[8] 0xfc) 2; Am I correct? Yes, you are correct. I miscounted the bits when I wrote this originally. Thanks for reporting this! Regards, Hans I did not check this one, but I would not be surprised if ps-analyzer had this wrong too. Regards, Andy Regards, Lars. [1] http://en.wikipedia.org/wiki/Presentation_time_stamp [2] http://en.wikipedia.org/wiki/MPEG_program_stream -- -- 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 -- 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
