[PATCH 1/5] [media] mb86a20s: add i2c_gate_ctrl
The register 0xfe controls the i2c-bus from the mb86a20s to tuner.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/frontends/mb86a20s.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..f3c4013 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -370,6 +370,17 @@ static int mb86a20s_i2c_readreg(struct mb86a20s_state
*state,
mb86a20s_i2c_writeregdata(state, state-config-demod_address, \
regdata, ARRAY_SIZE(regdata))
+static int mb86a20s_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ struct mb86a20s_state *state = fe-demodulator_priv;
+
+ /* Enable/Disable I2C bus for tuner control */
+ if (enable)
+ return mb86a20s_writereg(state, 0xfe, 0);
+ else
+ return mb86a20s_writereg(state, 0xfe, 1);
+}
+
static int mb86a20s_initfe(struct dvb_frontend *fe)
{
struct mb86a20s_state *state = fe-demodulator_priv;
@@ -626,6 +637,7 @@ static struct dvb_frontend_ops mb86a20s_ops = {
.release = mb86a20s_release,
+ .i2c_gate_ctrl = mb86a20s_i2c_gate_ctrl,
.init = mb86a20s_initfe,
.set_frontend = mb86a20s_set_frontend,
.get_frontend = mb86a20s_get_frontend,
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] [media] mb86a20s: Add support for TBS-Tech ISDB-T Full Seg DTB08
This code allows free programming of some registers of the mb86a20s
demodulator. All registers that need changes received an identification
(REG_IDCFG).
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/frontends/mb86a20s.c | 203
drivers/media/dvb/frontends/mb86a20s.h | 100
2 files changed, 303 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index f3c4013..bc7e868 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -1,6 +1,7 @@
/*
* Fujitu mb86a20s ISDB-T/ISDB-Tsb Module driver
*
+ * Copyright (C) 2011 Manoel Pinheiro pinus...@pdtv.cjb.net
* Copyright (C) 2010 Mauro Carvalho Chehab mche...@redhat.com
* Copyright (C) 2009-2010 Douglas Landgraf dougsl...@redhat.com
*
@@ -45,8 +46,19 @@ struct mb86a20s_state {
struct dvb_frontend frontend;
bool need_init;
+ int config_regs_size;
+ const struct mb86a20s_config_regs_val *config_regs;
};
+struct mb86a20s_config_regs {
+ u8 id_cfg;
+ u8 type;/* 0=8 bits wo/sub, 1=8 bits w/sub
+* 2=16 bits wo/sub, 3=16 bits w/sub, 4=24 bits */
+ u8 reg;
+ u8 subreg;
+ u32 init_val;
+};
+
struct regdata {
u8 reg;
u8 data;
@@ -309,6 +321,104 @@ static struct regdata mb86a20s_reset_reception[] = {
{ 0x08, 0x00 },
};
+/*
+ * Initial registers for Pixelview USB hybrid PV-B308U
+ */
+static struct mb86a20s_config_regs mb86a20s_init_regs[] = {
+ { REGNONE_IDCFG, 0x00, 0x70, 0x00, 0x0f },
+ { REGNONE_IDCFG, 0x00, 0x70, 0x00, 0xff },
+ { REGNONE_IDCFG, 0x00, 0x08, 0x00, 0x01 },
+ { REG09_IDCFG, 0x00, 0x09, 0x00, 0x3e },
+ { REG50D1_IDCFG, 0x01, 0x50, 0xd1, 0x22 },
+ { REG39_IDCFG, 0x00, 0x39, 0x00, 0x01 },
+ { REG71_IDCFG, 0x00, 0x71, 0x00, 0x00 },
+ { REG282A_IDCFG, 0x04, 0x28, 0x2a, 0xff80 },
+ { REG2820_IDCFG, 0x04, 0x28, 0x20, 0x33dfa9 },
+ { REG2822_IDCFG, 0x04, 0x28, 0x22, 0x1ff0 },
+ { REGNONE_IDCFG, 0x00, 0x3b, 0x00, 0x21 },
+ { REG3C_IDCFG, 0x00, 0x3c, 0x00, 0x3a },
+ { REG01_IDCFG, 0x00, 0x01, 0x00, 0x0d },
+ { REG0408_IDCFG, 0x01, 0x04, 0x08, 0x05 },
+ { REG040E_IDCFG, 0x03, 0x04, 0x0e, 0x0014 },
+ { REG040B_IDCFG, 0x01, 0x04, 0x0b, 0x8c },
+ { REG0400_IDCFG, 0x03, 0x04, 0x00, 0x0007 },
+ { REG0402_IDCFG, 0x03, 0x04, 0x02, 0x0fa0 },
+ { REG0409_IDCFG, 0x01, 0x04, 0x09, 0x00 },
+ { REG040A_IDCFG, 0x01, 0x04, 0x0a, 0xff },
+ { REG0427_IDCFG, 0x01, 0x04, 0x27, 0x64 },
+ { REG0428_IDCFG, 0x01, 0x04, 0x28, 0x00 },
+ { REG041E_IDCFG, 0x01, 0x04, 0x1e, 0xff },
+ { REG0429_IDCFG, 0x01, 0x04, 0x29, 0x0a },
+ { REG0432_IDCFG, 0x01, 0x04, 0x32, 0x0a },
+ { REG0414_IDCFG, 0x01, 0x04, 0x14, 0x02 },
+ { REG0404_IDCFG, 0x03, 0x04, 0x04, 0x0022 },
+ { REG0406_IDCFG, 0x03, 0x04, 0x06, 0x0ed8 },
+ { REG0412_IDCFG, 0x01, 0x04, 0x12, 0x00 },
+ { REG0413_IDCFG, 0x01, 0x04, 0x13, 0xff },
+ { REG0415_IDCFG, 0x01, 0x04, 0x15, 0x4e },
+ { REG0416_IDCFG, 0x01, 0x04, 0x16, 0x20 },
+ { REGNONE_IDCFG, 0x00, 0x52, 0x00, 0x01 },
+ { REG50A7_IDCFG, 0x04, 0x50, 0xa7, 0x },
+ { REG50AA_IDCFG, 0x04, 0x50, 0xaa,0x },
+ { REG50AD_IDCFG, 0x04, 0x50, 0xad, 0x },
+ { REGNONE_IDCFG, 0x00, 0x5e, 0x00, 0x07 },
+ { REG50DC_IDCFG, 0x03, 0x50, 0xdc, 0x01f4 },
+ { REG50DE_IDCFG, 0x03, 0x50, 0xde, 0x01f4 },
+ { REG50E0_IDCFG, 0x03, 0x50, 0xe0, 0x01f4 },
+ { REG50B0_IDCFG, 0x01, 0x50, 0xb0, 0x07 },
+ { REG50B2_IDCFG, 0x03, 0x50, 0xb2, 0x },
+ { REG50B4_IDCFG, 0x03, 0x50, 0xb4, 0x },
+ { REG50B6_IDCFG, 0x03, 0x50, 0xb6, 0x },
+ { REG5050_IDCFG, 0x01, 0x50, 0x50, 0x02 },
+ { REG5051_IDCFG, 0x01, 0x50, 0x51, 0x04 },
+ { REG45_IDCFG, 0x00, 0x45, 0x00, 0x04 },
+ { REGNONE_IDCFG, 0x00, 0x48, 0x00, 0x04 },
+ { REG50D5_IDCFG, 0x01, 0x50, 0xd5, 0x01 },
+ { REG50D6_IDCFG, 0x01, 0x50, 0xd6, 0x1f },
+ { REG50D2_IDCFG, 0x01, 0x50, 0xd2, 0x03 },
+ { REG50D7_IDCFG, 0x01, 0x50, 0xd7, 0x3f },
+ { REG2874_IDCFG, 0x04, 0x28, 0x74, 0x0040 },
+ { REG2846_IDCFG, 0x04, 0x28, 0x46, 0x2c0c },
+ { REG0440_IDCFG, 0x01, 0x04, 0x40, 0x01 },
+ { REG2800_IDCFG, 0x01, 0x28, 0x00, 0x10 },
+ { REG2805_IDCFG, 0x01, 0x28, 0x05, 0x02 },
+ { REGNONE_IDCFG, 0x00, 0x1c, 0x00, 0x01 },
+ { REG2806_IDCFG, 0x04, 0x28, 0x06, 0x0003 },
+ { REG2807_IDCFG, 0x04, 0x28, 0x07, 0x000d },
+ { REG2808_IDCFG, 0x04, 0x28, 0x08, 0x0002 },
+ { REG2809_IDCFG, 0x04, 0x28, 0x09, 0x0001 },
+ { REG280A_IDCFG, 0x04, 0x28, 0x0a, 0x0021 },
+ { REG280B_IDCFG, 0x04, 0x28, 0x0b, 0x0029 },
+ { REG280C_IDCFG, 0x04, 0x28, 0x0c, 0x0016 },
+
[PATCH 3/5] [media] Add Keytable for tbs_dtb08 remote controller
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-tbs-dtb08.c | 77 +++
include/media/rc-map.h |1 +
3 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/rc/keymaps/rc-tbs-dtb08.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index b57fc83..670febd 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-rc6-mce.o \
rc-real-audio-220-32-keys.o \
rc-streamzap.o \
+ rc-tbs-dtb08.o \
rc-tbs-nec.o \
rc-technisat-usb2.o \
rc-terratec-cinergy-xs.o \
diff --git a/drivers/media/rc/keymaps/rc-tbs-dtb08.c
b/drivers/media/rc/keymaps/rc-tbs-dtb08.c
new file mode 100644
index 000..bd2562a
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-tbs-dtb08.c
@@ -0,0 +1,77 @@
+/*
+ * TBS-Tech ISDB-T Full Seg DTB08 remote controller keytable
+ *
+ * Copyright (C) 2011 Manoel Pinheiro pinus...@pdtv.cjb.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include media/rc-map.h
+
+static struct rc_map_table tbs_dtb08[] = {
+ { 0x10, KEY_POWER },/* power */
+ { 0x06, KEY_MUTE }, /* mute */
+ { 0x4c, KEY_1 },
+ { 0x04, KEY_2 },
+ { 0x00, KEY_3 },
+ { 0x1e, KEY_4 },
+ { 0x0e, KEY_5 },
+ { 0x1a, KEY_6 },
+ { 0x14, KEY_7 },
+ { 0x0f, KEY_8 },
+ { 0x0c, KEY_9 },
+ { 0x1c, KEY_0 },
+ { 0x40, KEY_CHANNELUP },/* ch+ */
+ { 0x0a, KEY_CHANNELDOWN }, /* ch- */
+ { 0x19, KEY_VOLUMEUP }, /* vol+ */
+ { 0x17, KEY_VOLUMEDOWN }, /* vol- */
+ { 0x11, KEY_OK }, /* ok */
+ { 0x09, KEY_SHUFFLE }, /* scrn shot */
+ { 0x1f, KEY_UP },
+ { 0x1b, KEY_LEFT },
+ { 0x15, KEY_RIGHT },
+ { 0x16, KEY_DOWN },
+ { 0x4d, KEY_FAVORITES },/* fav */
+ { 0x01, KEY_ZOOM },
+ { 0x03, KEY_EPG },
+ { 0x1d, KEY_PLAY },
+ { 0x0d, KEY_STOP },
+ /* { 0x12, FIXME: }, *//* recall */
+};
+
+static struct rc_map_list tbs_dtb08_map = {
+ .map = {
+ .scan= tbs_dtb08,
+ .size= ARRAY_SIZE(tbs_dtb08),
+ .rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
+ .name= RC_MAP_TBS_DTB08,
+ }
+};
+
+static int __init init_rc_map_tbs_dtb08(void)
+{
+ return rc_map_register(tbs_dtb08_map);
+}
+
+static void __exit exit_rc_map_tbs_dtb08(void)
+{
+ rc_map_unregister(tbs_dtb08_map);
+}
+
+module_init(init_rc_map_tbs_dtb08)
+module_exit(exit_rc_map_tbs_dtb08)
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Manoel Pinheiro pinus...@pdtv.cjb.net);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 4e1409e..9a8159a 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -130,6 +130,7 @@ void rc_map_init(void);
#define RC_MAP_RC6_MCE rc-rc6-mce
#define RC_MAP_REAL_AUDIO_220_32_KEYSrc-real-audio-220-32-keys
#define RC_MAP_STREAMZAP rc-streamzap
+#define RC_MAP_TBS_DTB08 rc-tbs-dtb08
#define RC_MAP_TBS_NEC rc-tbs-nec
#define RC_MAP_TECHNISAT_USB2rc-technisat-usb2
#define RC_MAP_TERRATEC_CINERGY_XS rc-terratec-cinergy-xs
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] [media] Add support for TBS-Tech ISDB-T Full Seg DTB08
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com --- drivers/media/dvb/dvb-usb/Kconfig |8 drivers/media/dvb/dvb-usb/Makefile |3 +++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/Kconfig b/drivers/media/dvb/dvb-usb/Kconfig index e85304c..dd922c9 100644 --- a/drivers/media/dvb/dvb-usb/Kconfig +++ b/drivers/media/dvb/dvb-usb/Kconfig @@ -373,3 +373,11 @@ config DVB_USB_TECHNISAT_USB2 select DVB_STV6110x if !DVB_FE_CUSTOMISE help Say Y here to support the Technisat USB2 DVB-S/S2 device + +config DVB_USB_TBSDTB08 +tristate TBS-Tech ISDB-T Full Seg DTB08 USB2.0 support +depends on DVB_USB +select DVB_MB86A20S +select MEDIA_TUNER_TDA18271 if !MEDIA_TUNER_CUSTOMISE +help + Say Y here to support the TBS-Tech Full Seg DTB08 ISDB-T USB2.0 receivers diff --git a/drivers/media/dvb/dvb-usb/Makefile b/drivers/media/dvb/dvb-usb/Makefile index 4bac13d..bd449fa 100644 --- a/drivers/media/dvb/dvb-usb/Makefile +++ b/drivers/media/dvb/dvb-usb/Makefile @@ -94,6 +94,9 @@ obj-$(CONFIG_DVB_USB_LME2510) += dvb-usb-lmedm04.o dvb-usb-technisat-usb2-objs = technisat-usb2.o obj-$(CONFIG_DVB_USB_TECHNISAT_USB2) += dvb-usb-technisat-usb2.o +dvb-usb-tbsdtb08-objs = tbs-dtb08.o +obj-$(CONFIG_DVB_USB_TBSDTB08) += dvb-usb-tbsdtb08.o + EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/ # due to tuner-xc3028 EXTRA_CFLAGS += -Idrivers/media/common/tuners -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] [media] Add support for TBS-Tech ISDB-T Full Seg DTB08
Need patches:
[PATCH 1/5] [media] mb86a20s: add i2c_gate_ctrl
[PATCH 2/5] [media] mb86a20s: Add support for TBS-Tech ISDB-T Full Seg DTB08
[PATCH 3/5] [media] Add Keytable for tbs_dtb08 remote controller
[PATCH 4/5] [media] Add support for TBS-Tech ISDB-T Full Seg DTB08
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/dvb-usb/tbs-dtb08.c | 576 +
drivers/media/dvb/dvb-usb/tbs-dtb08.h | 30 ++
2 files changed, 606 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/dvb-usb/tbs-dtb08.c
create mode 100644 drivers/media/dvb/dvb-usb/tbs-dtb08.h
diff --git a/drivers/media/dvb/dvb-usb/tbs-dtb08.c
b/drivers/media/dvb/dvb-usb/tbs-dtb08.c
new file mode 100644
index 000..b654efd
--- /dev/null
+++ b/drivers/media/dvb/dvb-usb/tbs-dtb08.c
@@ -0,0 +1,576 @@
+/*
+ * TBS-Tech ISDB-T Full Seg DTB08 device driver
+ *
+ * Copyright (C) 2010-2011 Manoel Pinheiro pinus...@pdtv.cjb.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/module.h
+#include linux/dvb/version.h
+
+#include tbs-dtb08.h
+#include tda18271.h
+#include mb86a20s.h
+
+#defineDEMOD_I2C_ADDR 0x20
+#defineTUNER_I2C_ADDR 0xc0
+
+#ifndef USB_PID_TBS_DTB08
+#define USB_PID_TBS_DTB08 0xdb08
+#endif
+
+#define USB_VID_TBS_734C 0x734c
+
+#define TBS_DTB08_WRITE_MSG0
+#define TBS_DTB08_READ_MSG 1
+
+#define TBS_DTB08_RC_QUERY 0xb8
+#define TBS_DTB08_LED_CONTROL 5
+
+#define FX2_IE_EX0 7
+#define FX2_EX0_ENABLE 1
+#define FX2_EX0_DISABLE0
+#define FX2_I2CTL 6
+#define I2CTL_100Khz 0
+#define I2CTL_400Khz 1
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+static DEFINE_MUTEX(tbs_dtb08_usb_mutex);
+
+static int fx2_renum = 0;
+static unsigned char demod_ok = 0;
+
+static int tbs_dtb08_op_rw(struct usb_device *udev, u8 request, u16 value,
+ u16 index, u8 *data, u16 len, int flags)
+{
+ int ret;
+ uint pipe;
+ u8 request_type;
+ u8 buf[64];
+
+ if ((ret = mutex_lock_interruptible(tbs_dtb08_usb_mutex)))
+ return -EAGAIN;
+
+ if (len 64)
+ len = 64;
+
+ pipe = (flags == TBS_DTB08_READ_MSG) ? usb_rcvctrlpipe(udev, 0)
+ : usb_sndctrlpipe(udev, 0);
+ request_type = (flags == TBS_DTB08_READ_MSG) ? USB_DIR_IN : USB_DIR_OUT;
+
+ if (flags == TBS_DTB08_WRITE_MSG)
+ memcpy(buf, data, len);
+
+ ret = usb_control_msg(udev, pipe, request, request_type |
USB_TYPE_VENDOR,
+ value, index , buf, len, 2000);
+
+ if (flags == TBS_DTB08_READ_MSG)
+ memcpy(data, buf, len);
+
+ if (ret 0)
+ printk(KERN_ERR tbs_dtb08.c: %s ret=%d\n, __func__, ret);
+
+ mutex_unlock(tbs_dtb08_usb_mutex);
+
+ return ret;
+}
+
+static int tbs_dtb08_i2c_reg_read(struct usb_device *udev, u8 addr,
+ u8 reg, u8 *data, u8 len)
+{
+ int i, ret;
+ u8 val, buf[64];
+
+ if (len 64)
+ len = 64;
+ if (len 1)
+ return -EINVAL;
+
+ for (i = 0; i 5; i++) {
+ ret = tbs_dtb08_op_rw(udev, 0x81, 0, 0, val, 1,
TBS_DTB08_READ_MSG);
+ if (ret == 0 val == 0) break;
+ msleep(1);
+ }
+
+ buf[0] = len;
+ buf[1] = addr;
+ buf[2] = reg;
+
+ ret = tbs_dtb08_op_rw(udev, 0x90, 0, 0, buf, 3, TBS_DTB08_WRITE_MSG);
+
+ for (i = 0; i 5; i++) {
+ ret = tbs_dtb08_op_rw(udev, 0x81, 0, 0, val, 1,
TBS_DTB08_READ_MSG);
+ if (ret == 0 val == 0) break;
+ msleep(1);
+ }
+
+ memset(buf, 0, sizeof(buf));
+
+ ret = tbs_dtb08_op_rw(udev, 0x91, 0, 0, buf, len, TBS_DTB08_READ_MSG);
+ memcpy(data, buf, len);
+
+ return ret;
+}
+
+static int tbs_dtb08_i2c_reg_write(struct usb_device *udev, u8 addr, u8 reg,
+ u8 *data, u8 len)
+{
+ int i, ret;
+ u8 buf[64];
+
+ if (len 62)
+ len = 62;
+ if (len 1)
+ return -EINVAL;
+
+ buf[0] = len + 2;
+ buf[1] = addr;
+ buf[2] = reg;
+
+ memcpy(buf[3], data, len);
+
+ for (i = 0; i 5; i++) {
+ ret =
Re: Improving kernel - userspace (usbfs) usb device hand off
Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. On 06/10/2011 04:48 PM, Alan Stern wrote: On Fri, 10 Jun 2011, Hans de Goede wrote: Hi all, The current API for managing kernel - userspace is a bit rough around the edges, so I would like to discuss extending the API. First of all an example use case scenarios where the current API falls short. 1) Redirection of USB devices to a virtual machine, qemu, vbox, etc. all have the ability to redirect a USB device to the virtual machine, and they all use usbfs for this. The first thing which will happen here when the user selects a device to redirect is a IOCTL_USBFS_DISCONNECT. This causes the kernel driver to see a device unplug, with no chances for the kernel driver to do anything against this. Now lets say the user does the following: -write a file to a usb flash disk -redirect the flash disk to a vm Currently this will cause the usb mass storage driver to see a disconnect, and any possible still pending writes are lost ... This is IMHO unacceptable, but currently there is nothing we can do to avoid this. You haven't given a proper description of the problem. See below. I think I've given an excellent description of the problem, drivers can be unbound from devices, and there is no way for drivers to block this. All I'm asking for is for a new usbfs try_disconnect ioctl which the currently bound driver has a chance blocking nothing more nothing less. snip dual mode camera stuff So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. This is not completely true, I cannot rmmod usb-storage as long as disks using it are mounted. I know this is done through the global module usage count, so this is not per usb-storage device. But extending the ref counting to be per usb-storage device should not be hard. All the accounting is already done for this. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. Yes, and what I'm asking for is for an easy way for these programs to be careful. A way for them to ask the kernel, which in general is responsible for things like this and traditionally does resource management and things which come with that like refcounting: unbind the driver from this device unless the device is currently in use. Why can't this be done in userspace, simply put: 1) Process a checks if the usb-storage device is not used 2) Process b mounts it after the check 3) Process a unbinds the driver Yes this can be avoided if all binding/unbinding and all mounting happens under control of a single instance. However this requires completely re-inventing userspace... Also note that the notion of this can be extended to other devices, want to ubs-redirect a usb printer to a vm better not do it halfway through a printjob being spooled. Want to usb-redirect a usb webcam to a vm, better not do it while something is streaming video from the webcam, etc. etc. And please don't come with the inevitable if it hurts do not do that argument. We want to provide this kind of functionality to non tech savy computer users, and things should just work, including telling the user that the device is currently in use rather then wrecking his printjob or filesystem. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash on unplug with the uvc driver in linuxtv/staging/for_v3.1
Hi Hans, On Thursday 09 June 2011 13:22:03 Hans de Goede wrote: Hi, When I unplug a uvc camera *while streaming* I get: [15824.809741] BUG: unable to handle kernel NULL pointer dereference at (null) [snip] I've not tested if this also impacts 3.0!! It probably does. Thanks for the report. I'll fix it. I also get the following during building linuxtv/staging/for_v3.1: CC [M] drivers/media/video/uvc/uvc_entity.o drivers/media/video/uvc/uvc_entity.c: In function ‘uvc_mc_register_entities’: drivers/media/video/uvc/uvc_entity.c:110:6: warning: ‘ret’ may be used uninitialized in this function [-Wuninitialized] Mauro sent a patch to fix that. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dual sveon stv22 Afatech af9015 support (kworld clone)
Hello:
I have patched af9015.c and dvb-usb-ids to support sveon stv22 ( KWorld USB
Dual DVB-T TV Stick (DVB-T 399U) clone ) dual with
-
#define USB_PID_SVEON_STV22 0xe401
--
in dvb-usb-ids.h file
and
-
/* 30 */{USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_UB383_T)},
{USB_DEVICE(USB_VID_KWORLD_2,
USB_PID_KWORLD_395U_4)},
{USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22)},
{0},
};
--
{
.name = Sveon STV22 Dual USB DVB-T Tuner HDTV ,
.cold_ids = {af9015_usb_table[32], NULL},
.warm_ids = {NULL},
},
-
in af9015.c
i expect to help you to extends linux dvb usb support.
thanks for your time
Emilio David Diaus Lopez
--
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] usbvision: remove (broken) image format conversion
Hi Hans de G., Em 26-04-2011 08:54, Hans de Goede escreveu: If you could give it a shot that would be great. I've some hardware to test this with (although I've never actually tested that hardware), so I can hopefully pick things up if you cannot finish things before you need to return the hardware. As Ondrej couldn't work on that while he was with the hardware, could you please try to address this issue? Thanks, Mauro Em 03-05-2011 13:37, Ondrej Zary escreveu: On Tuesday 03 May 2011 12:29:45 Mauro Carvalho Chehab wrote: Em 26-04-2011 17:40, Ondrej Zary escreveu: On Tuesday 26 April 2011 14:33:20 Hans Verkuil wrote: After digging in the code for hours, I'm giving this up. It's not worth it. The ISOC_MODE_YUV422 mode works as V4L2_PIX_FMT_YVYU with VLC and mplayer+libv4lconvert, reducing the loop (and dropping strech_*) in usbvision_parse_lines_422() to: scratch_get(usbvision, frame-data + (frame-v4l2_linesize * frame-curline), 2 * frame-frmwidth); The ISOC_MODE_YUV420 is some weird custom format with 64-byte lines of YYUV. usbvision_parse_lines_420() is real mess with that scratch_* crap everywhere. ISOC_MODE_COMPRESS: There are callbacks to usbvision_request_intra() and also usbvision_adjust_compression(). This is not going to work outside the kernel. So I can redo the conversion removal patch to keep the RGB formats and also provide another one to remove the testpattern (it oopses too). But I'm not going to do any major changes in the driver. While in a perfect world, this should be moved to userspace, I'm ok on keeping it there, but the OOPS/Panic conditions should be fixed. Could you please work on a patch fixing the broken stuff, without removing the conversions? I've already returned the hardware so I can't test the driver anymore. Did the YUV422P conversion ever work? The initialization of u and v pointers is missing in usbvision_parse_compress() function for YUV422P case. The following oops was captured when trying to fix YVU420. Seems to be related to the u pointer too... [ 181.169233] usbvision_parse_compress before conversion [ 181.169233] usbvision_parse_compress idx=0, format=842094169 [ 181.169233] usbvision_parse_compress YVU420 f=e088d000, Y=e0a3e000 [ 181.169233] usbvision_parse_compress YVU420 frame=df016b68 [ 181.169233] usbvision_parse_compress YVU420 frame-curline=0 [ 181.169233] usbvision_parse_compress YVU420 u=e08a4700, U=e0a50c00, v=e089fc00, V=e0a55700 [ 181.169233] BUG: unable to handle kernel paging request at e08a4700 [ 181.169233] IP: [e097fd57] usbvision_parse_compress+0x599/0x76e [usbvision] [ 181.169233] *pde = 1f0c2067 *pte = [ 181.169233] Oops: 0002 [#1] SMP [ 181.169233] last sysfs file: /sys/devices/pci:00/:00:1d.0/usb2/2-1/i2c-0/uevent [ 181.169233] Modules linked in: savage drm loop usbvision v4l2_common snd_fm801 snd_tea575x_tuner videodev snd_intel8x0 e [ 181.169233] [ 181.169233] Pid: 0, comm: swapper Not tainted 2.6.39-rc2 #2/848P-ICH5 [ 181.169233] EIP: 0060:[e097fd57] EFLAGS: 00010046 CPU: 0 [ 181.169233] EIP is at usbvision_parse_compress+0x599/0x76e [usbvision] [ 181.169233] EAX: EBX: df016b68 ECX: e08a4700 EDX: e0a50c81 [ 181.169233] ESI: EDI: e088d001 EBP: 00a0 ESP: df021cb4 [ 181.169233] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 181.169233] Process swapper (pid: 0, ti=df02 task=c12dde60 task.ti=c12b) [ 181.169233] Stack: [ 181.169233] e0986ed3 e09861a4 e08a4700 e0a50c00 e089fc00 e0a55700 0003 e089fc00 [ 181.169233] e08a4700 00c0 0140 df021f14 df021d52 0506 00060027 0009 [ 181.169233] 00c0 3293 00605a25 ff00605a fff0 55d501fc 82995568 a0060124 [ 181.169233] Call Trace: [ 181.169233] [e0c9c69d] ? uhci_urb_enqueue+0x712/0x725 [uhci_hcd] [ 181.169233] [e08f4155] ? usb_hcd_submit_urb+0x4be/0x53d [usbcore] [ 181.169233] [c11e9840] ? printk+0xe/0x16 [ 181.169233] [e0980486] ? usbvision_isoc_irq+0x55a/0x17a0 [usbvision] [ 181.169233] [e097f5f9] ? usbvision_write_reg_irq+0xd5/0x10f [usbvision] [ 181.169233] [e0981505] ? usbvision_isoc_irq+0x15d9/0x17a0 [usbvision] [ 181.169233] [c1026eb2] ? try_to_wake_up+0x13b/0x13b [ 181.169233] [c117057c] ? ata_scsi_qc_complete+0x2b4/0x2c2 [ 181.169233] [c101e899] ? __wake_up+0x2c/0x3b [ 181.169233] [e08f33e5] ? usb_hcd_giveback_urb+0x46/0x71 [usbcore] [ 181.169233] [e0c9a98d] ? uhci_giveback_urb+0xea/0x15d [uhci_hcd] [ 181.169233] [e0c9aff7] ? uhci_scan_schedule+0x526/0x777 [uhci_hcd] [ 181.169233] [c117951b] ? __ata_sff_port_intr+0x97/0xa2 [ 181.169233] [e0c9c9f8] ? uhci_irq+0xbf/0xcd [uhci_hcd] [ 181.169233] [e08f2d2e] ? usb_hcd_irq+0x1e/0x5f [usbcore] [ 181.169233] [c1058581] ? handle_irq_event_percpu+0x1e/0x106 [ 181.169233] [c1059edc] ? handle_edge_irq+0xa0/0xa0 [ 181.169233] [c105868a] ? handle_irq_event+0x21/0x37 [ 181.169233] [c1059edc] ?
Re: [PATCH 09/10] rc-core: lirc use unsigned int
Em 06-05-2011 06:46, David Härdeman escreveu:
On Wed, 04 May 2011 12:23:03 -0300, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 28-04-2011 12:13, David Härdeman escreveu:
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Patch looked ok to me (except for one small issue - see bellow).
...
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index 569b07b..2b1d2df 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -953,13 +953,13 @@ static void ene_set_idle(struct rc_dev *rdev,
bool
idle)
}
/* outside interface: transmit */
-static int ene_transmit(struct rc_dev *rdev, int *buf, u32 n)
+static int ene_transmit(struct rc_dev *rdev, unsigned *buf, unsigned
n)
{
struct ene_device *dev = rdev-priv;
unsigned long flags;
dev-tx_buffer = buf;
- dev-tx_len = n / sizeof(int);
+ dev-tx_len = n;
That hunk seems wrong to me. Or is it a bug fix that you're solving?
My fault, I didn't mention in the patch description that the third
argument of the tx function is also changed to mean array size rather
than size in number of bytes.
Sorry for the long delay. Got sidetracked with other things.
Patch applied.
Thanks,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tea575x: allow multiple opens
Change locking to allow tea575x-radio device to be opened multiple times.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-06-11
14:50:55.0 +0200
@@ -49,7 +49,7 @@ struct snd_tea575x {
bool tuned; /* tuned to a station */
unsigned int val; /* hw value */
unsigned long freq; /* frequency */
- unsigned long in_use; /* set if the device is in use */
+ struct mutex mutex;
struct snd_tea575x_ops *ops;
void *private_data;
u8 card[32];
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-06-11
14:57:28.0 +0200
@@ -282,26 +282,9 @@ static int vidioc_s_input(struct file *f
return 0;
}
-static int snd_tea575x_exclusive_open(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- return test_and_set_bit(0, tea-in_use) ? -EBUSY : 0;
-}
-
-static int snd_tea575x_exclusive_release(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- clear_bit(0, tea-in_use);
- return 0;
-}
-
static const struct v4l2_file_operations tea575x_fops = {
.owner = THIS_MODULE,
- .open = snd_tea575x_exclusive_open,
- .release= snd_tea575x_exclusive_release,
- .ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
};
static const struct v4l2_ioctl_ops tea575x_ioctl_ops = {
@@ -340,13 +323,14 @@ int snd_tea575x_init(struct snd_tea575x
if (snd_tea575x_read(tea) != 0x55AA)
return -ENODEV;
- tea-in_use = 0;
tea-val = TEA575X_BIT_BAND_FM | TEA575X_BIT_SEARCH_10_40;
tea-freq = 90500 * 16; /* 90.5Mhz default */
snd_tea575x_set_freq(tea);
tea-vd = tea575x_radio;
video_set_drvdata(tea-vd, tea);
+ mutex_init(tea-mutex);
+ tea-vd.lock = tea-mutex;
v4l2_ctrl_handler_init(tea-ctrl_handler, 1);
tea-vd.ctrl_handler = tea-ctrl_handler;
--
Ondrej Zary
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 0/7] tuner-core: fix g_freq/s_std and g/s_tuner
While testing the new multi-standard tuner of the HVR-1600 (the cx18 driver) I came across a number of bugs in tuner-core that were recently introduced. This patch series fixes those bugs and cleans up some code that confused me. The bugs fixed in this series are: 1) 'type' is set by the driver, not the application for g_tuner and g_frequency, so don't check that field. 2) s_std and s_tuner both setup the tuner first, and then apply the new std or audmode. This should be the other way around. 3) s_tuner should not check the tuner 'type' field since applications don't need to set this. 'audmode' should just be applied to the current tuner mode. All these bugs were introduced in 2.6.39. So if acked, then this patch series should at least to into v3.0 and possibly into 2.6.39-stable. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 1/7] tuner-core: rename check_mode to supported_mode
From: Hans Verkuil hans.verk...@cisco.com
The check_mode function checks whether a mode is supported. So calling it
supported_mode is more appropriate. In addition it returned either 0 or
-EINVAL which suggests that the -EINVAL error should be passed on. However,
that's not the case so change the return type to bool.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 5748d04..083b9f1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -723,22 +723,19 @@ static int tuner_remove(struct i2c_client *client)
*/
/**
- * check_mode - Verify if tuner supports the requested mode
+ * supported_mode - Verify if tuner supports the requested mode
* @t: a pointer to the module's internal struct_tuner
*
* This function checks if the tuner is capable of tuning analog TV,
* digital TV or radio, depending on what the caller wants. If the
- * tuner can't support that mode, it returns -EINVAL. Otherwise, it
- * returns 0.
+ * tuner can't support that mode, it returns false. Otherwise, it
+ * returns true.
* This function is needed for boards that have a separate tuner for
* radio (like devices with tea5767).
*/
-static inline int check_mode(struct tuner *t, enum v4l2_tuner_type mode)
+static bool supported_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
- if ((1 mode t-mode_mask) == 0)
- return -EINVAL;
-
- return 0;
+ return 1 mode t-mode_mask;
}
/**
@@ -759,7 +756,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
if (mode != t-mode) {
- if (check_mode(t, mode) == -EINVAL) {
+ if (!supported_mode(t, mode)) {
tuner_dbg(Tuner doesn't support mode %d.
Putting tuner to sleep\n, mode);
t-standby = true;
@@ -1138,7 +1135,7 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, f-type) == -EINVAL)
+ if (!supported_mode(t, f-type))
return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
@@ -1161,7 +1158,7 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, vt-type) == -EINVAL)
+ if (!supported_mode(t, vt-type))
return 0;
vt-type = t-mode;
if (analog_ops-get_afc)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 2/7] tuner-core: change return type of set_mode_freq to bool
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 23 ++-
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 083b9f1..ee43e0a 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -746,11 +746,11 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
* @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
- * debug message and returns -EINVAL, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
+ * debug message and returns false, changing its state to standby.
+ * Otherwise, changes the state and sets frequency to the last value
+ * and returns true.
*/
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
+static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
enum v4l2_tuner_type mode, unsigned int freq)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -762,7 +762,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
t-standby = true;
if (analog_ops-standby)
analog_ops-standby(t-fe);
- return -EINVAL;
+ return false;
}
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
@@ -777,7 +777,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
set_tv_freq(client, t-tv_freq);
}
- return 0;
+ return true;
}
/*
@@ -1075,8 +1075,7 @@ static int tuner_s_radio(struct v4l2_subdev *sd)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_RADIO, 0) == -EINVAL)
- return 0;
+ set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
return 0;
}
@@ -1110,7 +1109,7 @@ static int tuner_s_std(struct v4l2_subdev *sd,
v4l2_std_id std)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
return 0;
t-std = std;
@@ -1124,9 +1123,7 @@ static int tuner_s_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, f-type, f-frequency) == -EINVAL)
- return 0;
-
+ set_mode_freq(client, t, f-type, f-frequency);
return 0;
}
@@ -1197,7 +1194,7 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, vt-type, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, vt-type, 0))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 6/7] tuner-core: fix g_tuner
From: Hans Verkuil hans.verk...@cisco.com g_tuner just returns the tuner data for the current tuner mode and the application does not have to set the tuner type. So don't test for a valid tuner type. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/tuner-core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 8ef7790..7280998 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1120,8 +1120,6 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt) struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops; struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops; - if (!supported_mode(t, vt-type)) - return 0; vt-type = t-mode; if (analog_ops-get_afc) vt-afc = analog_ops-get_afc(t-fe); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and reserved are the only writable fields.
So remove the type check. Instead, just set the audmode if the current
tuner mode is set to radio.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 7280998..0ffcf54 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1156,12 +1156,10 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- if (!set_mode(t, vt-type))
- return 0;
-
- if (t-mode == V4L2_TUNER_RADIO)
+ if (t-mode == V4L2_TUNER_RADIO) {
t-audmode = vt-audmode;
- set_freq(t, 0);
+ set_freq(t, 0);
+ }
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 3/7] tuner-core: fix g_frequency support.
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the frequency never gets filled in.
Remove this check.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index ee43e0a..4d8dcea 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1132,8 +1132,6 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (!supported_mode(t, f-type))
- return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
u32 abs_freq;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 5/7] tuner-core: fix s_std and s_tuner.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 57 -
1 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index d0630f9..8ef7790 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -739,19 +739,15 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns false, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value
- * and returns true.
+ * Otherwise, changes the state and returns true.
*/
-static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
+static bool set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -767,17 +763,27 @@ static bool set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return true;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq: frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return true;
}
/*
@@ -1034,9 +1040,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
+ set_mode(t, V4L2_TUNER_RADIO);
+ set_freq(t, 0);
return 0;
}
@@ -1068,24 +1074,23 @@ static int tuner_s_power(struct v4l2_subdev *sd, int on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
+ if (!set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = tuner_fixup_std(t, std);
if (t-std != std)
tuner_dbg(Fixup standard %llx to %llx\n, std, t-std);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, f-type, f-frequency);
+ if (set_mode(t, f-type))
+ set_freq(t, f-frequency);
return 0;
}
@@ -1152,13 +1157,13 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, vt-type, 0))
+ if (!set_mode(t, vt-type))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
t-audmode = vt-audmode;
+ set_freq(t, 0);
return 0;
}
@@ -1193,8 +1198,8 @@ static int tuner_resume(struct i2c_client *c)
tuner_dbg(resume\n);
if (!t-standby)
- set_mode_freq(c, t, t-type, 0);
-
Re: [PATCH] tea575x: allow multiple opens
On Saturday, June 11, 2011 15:28:59 Ondrej Zary wrote:
Change locking to allow tea575x-radio device to be opened multiple times.
Very nice!
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-06-11
14:50:55.0 +0200
@@ -49,7 +49,7 @@ struct snd_tea575x {
bool tuned; /* tuned to a station */
unsigned int val; /* hw value */
unsigned long freq; /* frequency */
- unsigned long in_use; /* set if the device is in use */
+ struct mutex mutex;
struct snd_tea575x_ops *ops;
void *private_data;
u8 card[32];
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-06-11
14:57:28.0 +0200
@@ -282,26 +282,9 @@ static int vidioc_s_input(struct file *f
return 0;
}
-static int snd_tea575x_exclusive_open(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- return test_and_set_bit(0, tea-in_use) ? -EBUSY : 0;
-}
-
-static int snd_tea575x_exclusive_release(struct file *file)
-{
- struct snd_tea575x *tea = video_drvdata(file);
-
- clear_bit(0, tea-in_use);
- return 0;
-}
-
static const struct v4l2_file_operations tea575x_fops = {
.owner = THIS_MODULE,
- .open = snd_tea575x_exclusive_open,
- .release= snd_tea575x_exclusive_release,
- .ioctl = video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
};
static const struct v4l2_ioctl_ops tea575x_ioctl_ops = {
@@ -340,13 +323,14 @@ int snd_tea575x_init(struct snd_tea575x
if (snd_tea575x_read(tea) != 0x55AA)
return -ENODEV;
- tea-in_use = 0;
tea-val = TEA575X_BIT_BAND_FM | TEA575X_BIT_SEARCH_10_40;
tea-freq = 90500 * 16; /* 90.5Mhz default */
snd_tea575x_set_freq(tea);
tea-vd = tea575x_radio;
video_set_drvdata(tea-vd, tea);
+ mutex_init(tea-mutex);
+ tea-vd.lock = tea-mutex;
v4l2_ctrl_handler_init(tea-ctrl_handler, 1);
tea-vd.ctrl_handler = tea-ctrl_handler;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] rc-core support for Microsoft IR keyboard/mouse
Em 03-06-2011 18:28, Jarod Wilson escreveu:
This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard.
http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8
Its a standard keyboard with embedded thumb stick mouse pointer and
mouse buttons, along with a number of media keys. The media keys are
standard RC-6, identical to the signals from the stock MCE remotes, and
will be handled as such. The keyboard and mouse signals will be decoded
and delivered to the system by an input device registered specifically
by this driver.
Successfully tested with an mceusb-driven receiver, but this should
actually work with any raw IR rc-core receiver.
This work is inspired by lirc_mod_mce:
http://mod-mce.sourceforge.net/
The documentation there and code aided in understanding and decoding the
protocol, but the bulk of the code is actually borrowed more from the
existing in-kernel decoders than anything. I did recycle the keyboard
keycode table and a few defines from lirc_mod_mce though.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
I did only a quick review, and everything looks fine for me. Just two comments:
+#if 0
+ /* Adding this reference means two input devices are associated with
+ * this rc-core device, which ir-keytable doesn't cope with yet */
+ idev-dev.parent = dev-dev;
+#endif
Well, it was never tested with such config ;) Feel free to fix rc-core.
+static unsigned char kbd_keycodes[256] = {
+ 0, 0, 0, 0, 30, 48, 46, 32, 18, 33, 34, 35, 23,
36, 37, 38,
+ 50, 49, 24, 25, 16, 19, 31, 20, 22, 47, 17, 45, 21,
44, 2, 3,
+ 4, 5, 6, 7, 8, 9, 10, 11, 28, 1, 14, 15, 57,
12, 13, 26,
+ 27, 43, 43, 39, 40, 41, 51, 52, 53, 58, 59, 60, 61,
62, 63, 64,
+ 65, 66, 67, 68, 87, 88, 99, 70, 119, 110, 102, 104, 111,
107, 109, 106,
+105, 108, 103, 69, 98, 55, 74, 78, 96, 79, 80, 81, 75,
76, 77, 71,
+ 72, 73, 82, 83, 86, 127, 116, 117, 183, 184, 185, 186, 187,
188, 189, 190,
+191, 192, 193, 194, 134, 138, 130, 132, 128, 129, 131, 137, 133,
135, 136, 113,
+115, 114, 0, 0, 0, 121, 0, 89, 93, 124, 92, 94, 95,
0, 0, 0,
+122, 123, 90, 91, 85, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,
+ 29, 42, 56, 125, 97, 54, 100, 126, 164, 166, 165, 163, 161,
115, 114, 113,
+150, 158, 159, 128, 136, 177, 178, 176, 142, 152, 173, 140
+};
This table looks weird to me: too much magic numbers there. Shouldn't
the above be replaced by KEY_* definitions?
Cheers,
Mauro
-
PS.: I would like to have one of those keyboards, in order to test some things
here,
in special, for the xorg input/event proposal on my TODO list ;) Is it a cheap
device?
I may try to buy one the next time I would travel to US.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 3/7] tuner-core: fix g_frequency support.
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the frequency never gets filled in.
Remove this check.
This patch is wrong, as it breaks support for devices with multiple
tuners (e. g. a tea5767 for radio and another tuner for TV).
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tuner-core.c
b/drivers/media/video/tuner-core.c
index ee43e0a..4d8dcea 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1132,8 +1132,6 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (!supported_mode(t, f-type))
- return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
u32 abs_freq;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 6/7] tuner-core: fix g_tuner
Em 11-06-2011 10:34, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com g_tuner just returns the tuner data for the current tuner mode and the application does not have to set the tuner type. So don't test for a valid tuner type. This also breaks support for a separate radio tuner, as both TV and radio tuners will touch at the g_tuner struct. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/tuner-core.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 8ef7790..7280998 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1120,8 +1120,6 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt) struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops; struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops; - if (!supported_mode(t, vt-type)) - return 0; vt-type = t-mode; if (analog_ops-get_afc) vt-afc = analog_ops-get_afc(t-fe); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 3/7] tuner-core: fix g_frequency support.
On Saturday, June 11, 2011 15:44:43 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the frequency never gets filled in.
Remove this check.
This patch is wrong, as it breaks support for devices with multiple
tuners (e. g. a tea5767 for radio and another tuner for TV).
Thanks for catching this, I had it right in an earlier version, but it
got lost somewhere along the way.
What should happen is that this should be added at the beginning:
if (t-standby)
return 0;
Ditto for g_tuner. If the current mode is not supported, standby is set to
true.
Regards,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tuner-core.c
b/drivers/media/video/tuner-core.c
index ee43e0a..4d8dcea 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1132,8 +1132,6 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (!supported_mode(t, f-type))
- return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
u32 abs_freq;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and reserved are the only writable fields.
So remove the type check. Instead, just set the audmode if the current
tuner mode is set to radio.
I suspect that this patch also breaks support for a separate radio tuner.
if tuner-type is not properly filled, then the easiest fix would be to
revert some changes done at the tuner cleanup/fixup patches applied on .39.
Yet, the previous logic were trying to hint the device mode, with is bad
(that's why it was changed).
The proper change seems to add a parameter to this callback, set by the
bridge driver, informing if the device is using radio or video mode.
We need also to patch the V4L API specs, as it allows using a video node
for radio, and vice versa. This is not well supported, and it seems silly
to keep it at the specs and needing to add hints at the drivers due to
that.
Cheers,
Mauro
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tuner-core.c
b/drivers/media/video/tuner-core.c
index 7280998..0ffcf54 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -1156,12 +1156,10 @@ static int tuner_s_tuner(struct v4l2_subdev *sd,
struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- if (!set_mode(t, vt-type))
- return 0;
-
- if (t-mode == V4L2_TUNER_RADIO)
+ if (t-mode == V4L2_TUNER_RADIO) {
t-audmode = vt-audmode;
- set_freq(t, 0);
+ set_freq(t, 0);
+ }
return 0;
}
--
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
[RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Second version of this patch series. It's the same as RFCv1, except that I dropped the g_frequency and g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) because I need to think more on those, and I added a new fix for tuner_resume which was broken as well. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 1/5] tuner-core: rename check_mode to supported_mode
From: Hans Verkuil hans.verk...@cisco.com
The check_mode function checks whether a mode is supported. So calling it
supported_mode is more appropriate. In addition it returned either 0 or
-EINVAL which suggests that the -EINVAL error should be passed on. However,
that's not the case so change the return type to bool.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 5748d04..083b9f1 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -723,22 +723,19 @@ static int tuner_remove(struct i2c_client *client)
*/
/**
- * check_mode - Verify if tuner supports the requested mode
+ * supported_mode - Verify if tuner supports the requested mode
* @t: a pointer to the module's internal struct_tuner
*
* This function checks if the tuner is capable of tuning analog TV,
* digital TV or radio, depending on what the caller wants. If the
- * tuner can't support that mode, it returns -EINVAL. Otherwise, it
- * returns 0.
+ * tuner can't support that mode, it returns false. Otherwise, it
+ * returns true.
* This function is needed for boards that have a separate tuner for
* radio (like devices with tea5767).
*/
-static inline int check_mode(struct tuner *t, enum v4l2_tuner_type mode)
+static bool supported_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
- if ((1 mode t-mode_mask) == 0)
- return -EINVAL;
-
- return 0;
+ return 1 mode t-mode_mask;
}
/**
@@ -759,7 +756,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
if (mode != t-mode) {
- if (check_mode(t, mode) == -EINVAL) {
+ if (!supported_mode(t, mode)) {
tuner_dbg(Tuner doesn't support mode %d.
Putting tuner to sleep\n, mode);
t-standby = true;
@@ -1138,7 +1135,7 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, f-type) == -EINVAL)
+ if (!supported_mode(t, f-type))
return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
@@ -1161,7 +1158,7 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (check_mode(t, vt-type) == -EINVAL)
+ if (!supported_mode(t, vt-type))
return 0;
vt-type = t-mode;
if (analog_ops-get_afc)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 2/5] tuner-core: change return type of set_mode_freq to bool
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 23 ++-
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 083b9f1..ee43e0a 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -746,11 +746,11 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
* @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
- * debug message and returns -EINVAL, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
+ * debug message and returns false, changing its state to standby.
+ * Otherwise, changes the state and sets frequency to the last value
+ * and returns true.
*/
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
+static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
enum v4l2_tuner_type mode, unsigned int freq)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -762,7 +762,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
t-standby = true;
if (analog_ops-standby)
analog_ops-standby(t-fe);
- return -EINVAL;
+ return false;
}
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
@@ -777,7 +777,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
set_tv_freq(client, t-tv_freq);
}
- return 0;
+ return true;
}
/*
@@ -1075,8 +1075,7 @@ static int tuner_s_radio(struct v4l2_subdev *sd)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_RADIO, 0) == -EINVAL)
- return 0;
+ set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
return 0;
}
@@ -1110,7 +1109,7 @@ static int tuner_s_std(struct v4l2_subdev *sd,
v4l2_std_id std)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
return 0;
t-std = std;
@@ -1124,9 +1123,7 @@ static int tuner_s_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, f-type, f-frequency) == -EINVAL)
- return 0;
-
+ set_mode_freq(client, t, f-type, f-frequency);
return 0;
}
@@ -1197,7 +1194,7 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, vt-type, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, vt-type, 0))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 3/5] tuner-core: simplify the standard fixup.
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index ee43e0a..462a8f4 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -832,7 +832,7 @@ static void set_tv_freq(struct i2c_client *c, unsigned int
freq)
/**
* tuner_fixup_std - force a given video standard variant
*
- * @t: tuner internal struct
+ * @std: TV standard
*
* A few devices or drivers have problem to detect some standard variations.
* On other operational systems, the drivers generally have a per-country
@@ -842,57 +842,39 @@ static void set_tv_freq(struct i2c_client *c, unsigned
int freq)
* to distinguish all video standard variations, a modprobe parameter can
* be used to force a video standard match.
*/
-static int tuner_fixup_std(struct tuner *t)
+static v4l2_std_id tuner_fixup_std(struct tuner *t, v4l2_std_id std)
{
- if ((t-std V4L2_STD_PAL) == V4L2_STD_PAL) {
+ if (pal[0] != '-' (std V4L2_STD_PAL) == V4L2_STD_PAL) {
switch (pal[0]) {
case '6':
- tuner_dbg(insmod fixup: PAL = PAL-60\n);
- t-std = V4L2_STD_PAL_60;
- break;
+ return V4L2_STD_PAL_60;
case 'b':
case 'B':
case 'g':
case 'G':
- tuner_dbg(insmod fixup: PAL = PAL-BG\n);
- t-std = V4L2_STD_PAL_BG;
- break;
+ return V4L2_STD_PAL_BG;
case 'i':
case 'I':
- tuner_dbg(insmod fixup: PAL = PAL-I\n);
- t-std = V4L2_STD_PAL_I;
- break;
+ return V4L2_STD_PAL_I;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: PAL = PAL-DK\n);
- t-std = V4L2_STD_PAL_DK;
- break;
+ return V4L2_STD_PAL_DK;
case 'M':
case 'm':
- tuner_dbg(insmod fixup: PAL = PAL-M\n);
- t-std = V4L2_STD_PAL_M;
- break;
+ return V4L2_STD_PAL_M;
case 'N':
case 'n':
- if (pal[1] == 'c' || pal[1] == 'C') {
- tuner_dbg(insmod fixup: PAL = PAL-Nc\n);
- t-std = V4L2_STD_PAL_Nc;
- } else {
- tuner_dbg(insmod fixup: PAL = PAL-N\n);
- t-std = V4L2_STD_PAL_N;
- }
- break;
- case '-':
- /* default parameter, do nothing */
- break;
+ if (pal[1] == 'c' || pal[1] == 'C')
+ return V4L2_STD_PAL_Nc;
+ return V4L2_STD_PAL_N;
default:
tuner_warn(pal= argument not recognised\n);
break;
}
}
- if ((t-std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
+ if (secam[0] != '-' (std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
switch (secam[0]) {
case 'b':
case 'B':
@@ -900,63 +882,42 @@ static int tuner_fixup_std(struct tuner *t)
case 'G':
case 'h':
case 'H':
- tuner_dbg(insmod fixup: SECAM = SECAM-BGH\n);
- t-std = V4L2_STD_SECAM_B |
-V4L2_STD_SECAM_G |
-V4L2_STD_SECAM_H;
- break;
+ return V4L2_STD_SECAM_B |
+ V4L2_STD_SECAM_G |
+ V4L2_STD_SECAM_H;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: SECAM = SECAM-DK\n);
- t-std = V4L2_STD_SECAM_DK;
- break;
+ return V4L2_STD_SECAM_DK;
case 'l':
case 'L':
- if ((secam[1] == 'C') || (secam[1] == 'c')) {
- tuner_dbg(insmod fixup: SECAM = SECAM-L'\n);
- t-std = V4L2_STD_SECAM_LC;
- } else {
- tuner_dbg(insmod fixup: SECAM = SECAM-L\n);
-
[RFCv2 PATCH 4/5] tuner-core: fix s_std and s_tuner.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 57 -
1 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 462a8f4..e5ec145 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -739,19 +739,15 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns false, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value
- * and returns true.
+ * Otherwise, changes the state and returns true.
*/
-static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
+static bool set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -767,17 +763,27 @@ static bool set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return true;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq: frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return true;
}
/*
@@ -1034,9 +1040,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
+ set_mode(t, V4L2_TUNER_RADIO);
+ set_freq(t, 0);
return 0;
}
@@ -1068,24 +1074,23 @@ static int tuner_s_power(struct v4l2_subdev *sd, int on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
+ if (!set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = tuner_fixup_std(t, std);
if (t-std != std)
tuner_dbg(Fixup standard %llx to %llx\n, std, t-std);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, f-type, f-frequency);
+ if (set_mode(t, f-type))
+ set_freq(t, f-frequency);
return 0;
}
@@ -1154,13 +1159,13 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, vt-type, 0))
+ if (!set_mode(t, vt-type))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
t-audmode = vt-audmode;
+ set_freq(t, 0);
return 0;
}
@@ -1195,8 +1200,8 @@ static int tuner_resume(struct i2c_client *c)
tuner_dbg(resume\n);
if (!t-standby)
- set_mode_freq(c, t, t-type, 0);
-
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: Second version of this patch series. It's the same as RFCv1, except that I dropped the g_frequency and g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) because I need to think more on those, and I added a new fix for tuner_resume which was broken as well. Hi Hans, I appreciate your taking the time to refactor this code (no doubt it really needed it). All that I ask is that you please actually *try* the resulting patches with VLC and a tuner that supports standby in order to ensure that it didn't cause any regressions. This stuff was brittle to begin with, and there are lots of opportunities for obscure/unexpected effects resulting from what appear to be sane changes. The last series of patches that went in were in response to this stuff being very broken, and I would hate to see a regression in existing applications after we finally got it working. Thanks, 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: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote: On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: Second version of this patch series. It's the same as RFCv1, except that I dropped the g_frequency and g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) because I need to think more on those, and I added a new fix for tuner_resume which was broken as well. Hi Hans, I appreciate your taking the time to refactor this code (no doubt it really needed it). All that I ask is that you please actually *try* the resulting patches with VLC and a tuner that supports standby in order to ensure that it didn't cause any regressions. That's easier said than done. I don't think I have tuners of that type. Do you happen to know not-too-expensive cards that you can buy that have this sort of tuners? It may be useful to be able to test this myself. This stuff was brittle to begin with, and there are lots of opportunities for obscure/unexpected effects resulting from what appear to be sane changes. The last series of patches that went in were in response to this stuff being very broken, and I would hate to see a regression in existing applications after we finally got it working. Yeah, it seems that whenever you touch this tuner code something breaks for at least one card. There is so much legacy here... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
Hans Verkuil hverk...@xs4all.nl wrote: On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote: On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: Second version of this patch series. It's the same as RFCv1, except that I dropped the g_frequency and g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series) because I need to think more on those, and I added a new fix for tuner_resume which was broken as well. Hi Hans, I appreciate your taking the time to refactor this code (no doubt it really needed it). All that I ask is that you please actually *try* the resulting patches with VLC and a tuner that supports standby in order to ensure that it didn't cause any regressions. That's easier said than done. I don't think I have tuners of that type. Do you happen to know not-too-expensive cards that you can buy that have this sort of tuners? It may be useful to be able to test this myself. This stuff was brittle to begin with, and there are lots of opportunities for obscure/unexpected effects resulting from what appear to be sane changes. The last series of patches that went in were in response to this stuff being very broken, and I would hate to see a regression in existing applications after we finally got it working. Yeah, it seems that whenever you touch this tuner code something breaks for at least one card. There is so much legacy here... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Devin, I think I have a Gotview or compro card with an xc2028. Is that tuner capable of standby? Would the cx18 or ivtv driver need to actively support using stand by? -Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel - userspace (usbfs) usb device hand off
On Sat, 11 Jun 2011, Hans de Goede wrote: Hi, Given the many comments in this thread, I'm just going reply to this one, and try to also answer any other ones in this mail. As far as the dual mode camera is involved, I agree that that should be fixed in the existing v4l2 drivers + libgphoto. I think that Felipe's solution to also handle the stillcam part in kernel space for dual mode cameras (and add a libgphoto cam driver which knows how to talk the new kernel API for this), is the best solution. Unfortunately this will involve quite a bit of work, but so be it. Hans, It appears to me that the solution ought to be at hand, actually. I was not aware of the recent changes in libusb, which I understand are supposed to allow a kernel driver to be hooked up again. To review the situation: 1. As of approximately 2 years ago, libusb already was so configured as to suspend the kernel module for a dual-mode device if a userspace-based program tried to claim the device. 2. At this point with the more recent versions of libusb (see the last message from yesterday, from Xiaofan Chen), we are supposed to be able to re-activate the kernel module for the device when it is relinquished by userspace. This ought to take care of the problems completely, provided that the new capabilities of libusb are actually used and called upon in libgphoto2. I have checked on what is happening, just now, on my own machine. I have libusb version 1.08 which ought to be recent enough. The advertised abilities did not work, however. Presumably, what is missing is on the other end of the problem, most likely in the functions in libgphoto2 which hook up a camera. That code would presumably need to call upon the new functionality of libusb. My currently installed version of libgphoto2 (from svn, but several months old) clearly does not contain the needed functionality. But it might have been put in recently and I did not notice. I guess that the first thing to do is to update my gphoto tree and then to see what happens. If things still don't work, then something needs to be updated and then things ought to work. I will try to see that something gets done about this. Thank you for raising the old issue of dual-mode devices yet again, and thanks to Xiaofan Chen for pointing out that the needed missing half of the functionality is supposed to exist now in libusb. That had escaped my attention. Theodore Kilgore -- 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] Add support for PCTV452E.
i've been using the patches in the latest media_tree for some hours - the S2-3650 CI seems to work. There's one thing that disturbs me, though - when it scans / locks on a frequency, another device on the same PC, using the same stb6100, gets stuck for a moment. Any ideas what might be the cause for that? The two devices do not share common RF input signal, but are on the same USB bus: Bus 001 Device 004: ID 734c:5980 TBS Technologies China Bus 001 Device 003: ID 0b48:300a TechnoTrend AG TT-connect S2-3650 CI The TBS device is a QBOX2 SI, which works with their official driver from their web-site. There's also a third DVB device in the system - a TT S-2400 (which is on the other USB bus, though), which does not exhibit any problems related with the first two devices, nor causes them to get stuck when it's scanning. I'll try to switch devices around and see if anything changes. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls awa...@md.metrocast.net wrote: Devin, I think I have a Gotview or compro card with an xc2028. Is that tuner capable of standby? Would the cx18 or ivtv driver need to actively support using stand by? An xc2028/xc3028 should be fine, as that does support standby. The problems we saw with VLC were related to calls like G_TUNER returning prematurely if the device was in standby, leaving the returned structure populated with garbage. FWIW, I don't dispute your assertion that Hans found legitimate bugs - just that we need to be careful to not cause regressions in the cases that the last round of bug fixes addressed. 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: Improving kernel - userspace (usbfs) usb device hand off
On Sat, 11 Jun 2011, Hans de Goede wrote: So what do we need to make this situation better: 1) A usb_driver callback alternative to the disconnect callback, I propose to call this soft_disconnect. This serves 2 purposes a) It will allow the driver to tell the caller that that is not a good idea by returning an error code (think usb mass storage driver and mounted filesystem Not feasible. usb-storage has no idea whether or not a device it controls has a mounted filesystem. (All it does is send SCSI commands to a device and get back the results.) Since that's the main use case you're interested in, this part of the proposal seems destined to fail. This is not completely true, I cannot rmmod usb-storage as long as disks using it are mounted. I know this is done through the global module usage count, so this is not per usb-storage device. But extending the ref counting to be per usb-storage device should not be hard. All the accounting is already done for this. It would be harder than you think. All the accounting is _not_ already being done. What you're talking about would amount to a significant change in the driver model core and the SCSI core. It isn't just a USB thing. But userspace _does_ know where the mounted filesystems are. Therefore userspace should be responsible for avoiding programs that want to take control of devices holding these filesystems. That's the reason why usbfs device nodes are owned by root and have 0644 mode; there're can be written to only by programs with superuser privileges -- and such programs are supposed to be careful about what they do. Yes, and what I'm asking for is for an easy way for these programs to be careful. A way for them to ask the kernel, which in general is responsible for things like this and traditionally does resource management and things which come with that like refcounting: unbind the driver from this device unless the device is currently in use. Sure. At the moment the kernel does not keep track of whether a device is currently in use -- at least, not in the way you mean. I'm not saying this can't be done. But it would be a bigger job than you think, and this isn't the appropriate thread to discuss it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Sat, Jun 11, 2011 at 11:53 AM, Hans Verkuil hverk...@xs4all.nl wrote: Do you happen to know not-too-expensive cards that you can buy that have this sort of tuners? It may be useful to be able to test this myself. Anything with an xc3028 or xc5000 would have this issue. I don't really keep close track of current shipping DVB products, but the 3028 was definitely very chip in products from a couple of years ago. 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: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
On Sat, Jun 11, 2011 at 1:02 PM, Hans Verkuil hverk...@xs4all.nl wrote: OK, but how do you get it into standby in the first place? (I must be missing something here...) The tuner core puts the chip into standby when the last V4L filehandle is closed. Yes, I realize this violates the V4L spec since you should be able to make multiple calls with something like v4l2-ctl, but nobody has ever come up with a better mechanism for knowing when to put the device to sleep. We've been forced to choose between the purist perspective, which is properly preserving state, never powering down the tuner and sucking up 500ma on the USB port when not using the tuner, versus powering down the tuner when the last party closes the filehandle, which preserves power but breaks v4l2 conformance and in some cases is highly noticeable with tuners that require firmware to be reloaded when being powered back up. 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: [RFCv2 PATCH 4/5] tuner-core: fix s_std and s_tuner.
On Saturday, June 11, 2011 17:05:30 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 57 -
1 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/tuner-core.c
b/drivers/media/video/tuner-core.c
index 462a8f4..e5ec145 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -739,19 +739,15 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client: struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode:enum v4l2_type (radio or TV)
- * @freq:frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns false, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value
- * and returns true.
+ * Otherwise, changes the state and returns true.
*/
-static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
- enum v4l2_tuner_type mode, unsigned int freq)
+static bool set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -767,17 +763,27 @@ static bool set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return true;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq:frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return true;
}
/*
@@ -1034,9 +1040,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
+ set_mode(t, V4L2_TUNER_RADIO);
+ set_freq(t, 0);
return 0;
}
@@ -1068,24 +1074,23 @@ static int tuner_s_power(struct v4l2_subdev *sd, int
on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
+ if (!set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = tuner_fixup_std(t, std);
if (t-std != std)
tuner_dbg(Fixup standard %llx to %llx\n, std, t-std);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency
*f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, f-type, f-frequency);
+ if (set_mode(t, f-type))
+ set_freq(t, f-frequency);
return 0;
}
@@ -1154,13 +1159,13 @@ static int tuner_g_tuner(struct v4l2_subdev *sd,
struct v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, vt-type, 0))
+ if (!set_mode(t, vt-type))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
t-audmode = vt-audmode;
+ set_freq(t, 0);
This 'if' is missing {}. I'll fix that.
Regards,
Hans
return 0;
}
@@
Re: [RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: Em 11-06-2011 10:34, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com According to the spec the tuner type field is not used when calling S_TUNER: index, audmode and reserved are the only writable fields. So remove the type check. Instead, just set the audmode if the current tuner mode is set to radio. I suspect that this patch also breaks support for a separate radio tuner. if tuner-type is not properly filled, then the easiest fix would be to revert some changes done at the tuner cleanup/fixup patches applied on .39. Yet, the previous logic were trying to hint the device mode, with is bad (that's why it was changed). The proper change seems to add a parameter to this callback, set by the bridge driver, informing if the device is using radio or video mode. We need also to patch the V4L API specs, as it allows using a video node for radio, and vice versa. This is not well supported, and it seems silly to keep it at the specs and needing to add hints at the drivers due to that. So, just to make sure I understand correctly what you want. The bridge or platform drivers will fill in the vf-type (for g/s_frequency) or vt-type (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, TV for anything else. What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this in. Will we just overwrite vf-type or will we check and return -EINVAL if the app tries to set e.g. a TV frequency on /dev/radio? Is VIDIOC_S_FREQUENCY allowed to change the tuner mode? E.g. if /dev/radio was opened, and now I open /dev/video and call S_FREQUENCY with the TV tuner type, should that change the tuner to tv mode? I think the type passed to S_FREQUENCY should 1) match the device node's type (if not, then return -EINVAL) and 2) should match the current mode (if not, then return -EBUSY). So attempts to change the TV frequency when in radio mode should fail. This second rule should also be valid for S_TUNER. What should G_TUNER return on a video node when in radio mode or vice versa? For G_FREQUENCY you can still return the last used frequency, but that's much more ambiguous for G_TUNER. One option is to set rxsubchans, signal and afc all to 0 if you query G_TUNER when 'in the wrong mode'. The VIDIOC_G/S_MODULATOR ioctls do not have a type and they are RADIO only, so that's OK. And how do we switch between radio and TV? Right now opening the radio node will set the tuner in radio mode, and calling S_STD will change the mode to TV again. As mentioned above, what S_FREQUENCY is supposed to do is undefined at the moment. What about this: Opening /dev/radio effectively starts the radio mode. So if there is TV capture in progress, then the open should return -EBUSY. Otherwise it switches the tuner to radio mode. And it stays in radio mode until the last filehandle of /dev/radio is closed. At that point it will automatically switch back to TV mode (if there is one, of course). While it is in radio mode calls to S_STD and S_FREQUENCY from /dev/video will return -EBUSY. Any attempt to start streaming from /dev/video will also return -EBUSY (radio 'streaming' is in progress after all). Effectively, S_STD no longer switches back to TV mode. That only happens when the last user of /dev/radio left. It certainly sounds a lot saner to me. Of course, I'm ignoring DVB in this story. You may have to negotiate between radio, Tv and DVB. Anyway, this all sounds very nice, but it's a heck of a lot of work. I'd much rather just fix this bug without changing the spec and behavior of drivers. That's a nice project perhaps for a rainy day (or week...), but not for a fix that is needed asap and that works for kernel v3.0. The whole radio/tv/dvb tuner selection is a big mess and needs to be solved, but let's do that in a separate project. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] marvell-cam: Move cafe-ccic into its own directory
This driver will soon become a family of drivers, so let's give it its own
place to live. This move requires putting ov7670.h into include/media, but
there are no code changes.
Cc: Daniel Drake d...@laptop.org
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Kconfig| 11 ++-
drivers/media/video/Makefile |2 +-
drivers/media/video/marvell-ccic/Kconfig |9 +
drivers/media/video/marvell-ccic/Makefile |1 +
.../video/{ = marvell-ccic}/cafe_ccic-regs.h |0
drivers/media/video/{ = marvell-ccic}/cafe_ccic.c |2 +-
drivers/media/video/ov7670.c |3 +--
{drivers/media/video = include/media}/ov7670.h|0
8 files changed, 15 insertions(+), 13 deletions(-)
create mode 100644 drivers/media/video/marvell-ccic/Kconfig
create mode 100644 drivers/media/video/marvell-ccic/Makefile
rename drivers/media/video/{ = marvell-ccic}/cafe_ccic-regs.h (100%)
rename drivers/media/video/{ = marvell-ccic}/cafe_ccic.c (99%)
rename {drivers/media/video = include/media}/ov7670.h (100%)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bb53de7..4847c2c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -707,6 +707,8 @@ source drivers/media/video/cx18/Kconfig
source drivers/media/video/saa7164/Kconfig
+source drivers/media/video/marvell-ccic/Kconfig
+
config VIDEO_M32R_AR
tristate AR devices
depends on M32R VIDEO_V4L2
@@ -726,15 +728,6 @@ config VIDEO_M32R_AR_M64278
To compile this driver as a module, choose M here: the
module will be called arv.
-config VIDEO_CAFE_CCIC
- tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support
- depends on PCI I2C VIDEO_V4L2
- select VIDEO_OV7670
- ---help---
- This is a video4linux2 driver for the Marvell 88ALP01 integrated
- CMOS camera controller. This is the controller found on first-
- generation OLPC systems.
-
config VIDEO_SR030PC30
tristate SR030PC30 VGA camera sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f0fecd6..42b6a7a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -127,7 +127,7 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
-obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
+obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
new file mode 100644
index 000..80136a8
--- /dev/null
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_CAFE_CCIC
+ tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support
+ depends on PCI I2C VIDEO_V4L2
+ select VIDEO_OV7670
+ ---help---
+ This is a video4linux2 driver for the Marvell 88ALP01 integrated
+ CMOS camera controller. This is the controller found on first-
+ generation OLPC systems.
+
diff --git a/drivers/media/video/marvell-ccic/Makefile
b/drivers/media/video/marvell-ccic/Makefile
new file mode 100644
index 000..1234725
--- /dev/null
+++ b/drivers/media/video/marvell-ccic/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
diff --git a/drivers/media/video/cafe_ccic-regs.h
b/drivers/media/video/marvell-ccic/cafe_ccic-regs.h
similarity index 100%
rename from drivers/media/video/cafe_ccic-regs.h
rename to drivers/media/video/marvell-ccic/cafe_ccic-regs.h
diff --git a/drivers/media/video/cafe_ccic.c
b/drivers/media/video/marvell-ccic/cafe_ccic.c
similarity index 99%
rename from drivers/media/video/cafe_ccic.c
rename to drivers/media/video/marvell-ccic/cafe_ccic.c
index 6647033..809964b 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/marvell-ccic/cafe_ccic.c
@@ -36,6 +36,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/ov7670.h
#include linux/device.h
#include linux/wait.h
#include linux/list.h
@@ -47,7 +48,6 @@
#include asm/uaccess.h
#include asm/io.h
-#include ov7670.h
#include cafe_ccic-regs.h
#define CAFE_VERSION 0x02
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index d4e7c11..8aa0585 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,8 +19,7 @@
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
#include media/v4l2-mediabus.h
-
-#include ov7670.h
+#include media/ov7670.h
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
diff --git a/drivers/media/video/ov7670.h b/include/media/ov7670.h
similarity index 100%
rename from drivers/media/video/ov7670.h
rename to include/media/ov7670.h
Refactor cafe_ccic and add Armada 610 driver [V2]
Here is the second posting of the cafe_ccic driver rework and the addition
of the Armada 610 camera driver. Things have been somewhat cleaned up
since the first time around, and I think that this series is ready to be
queued for 3.1. Mauro, if you agree, the whole series can be pulled from:
git://git.lwn.net/linux-2.6.git for-mauro
Some notes:
- The videobuf2 conversion is not yet done. My plan is to complete that
in the very near future and have it ready for 3.1 as well. In any case,
though, I want this point to exist in the mainline history since it has
a working version of both drivers without substantially changing how the
cafe_ccic driver works. If I later break the XO 1 for somebody, this
will be an important bisection point.
- The movement of cafe_ccic code generates a bunch of checkpatch errors,
but they are all from code which has been in mainline for years. If the
coding style nits bug people I'll happily generate a patch to fix them
all (may do so anyway), but I didn't want to add a bunch of noise when
everything else was in flux.
- Guennadi, I've not added the intermediate Kconfig variable you
suggested; it seemed like it was just more complication for no real
benefit. If you feel strongly about it, though, I'll make the change.
The changes in the series are:
Jonathan Corbet (8):
marvell-cam: Move cafe-ccic into its own directory
marvell-cam: Separate out the Marvell camera core
marvell-cam: Pass sensor parameters from the platform
marvell-cam: Remove the untested comment
marvell-cam: Move Cafe-specific register definitions to cafe-driver.c
marvell-cam: Right-shift i2c slave ID's in the cafe driver
marvell-cam: Allocate the i2c adapter in the platform driver
marvell-cam: Basic working MMP camera driver
drivers/media/video/Kconfig | 11 +-
drivers/media/video/Makefile|3 +-
drivers/media/video/cafe_ccic-regs.h| 166 --
drivers/media/video/cafe_ccic.c | 2267 ---
drivers/media/video/marvell-ccic/Kconfig| 20 +
drivers/media/video/marvell-ccic/Makefile |6 +
drivers/media/video/marvell-ccic/cafe-driver.c | 648 +++
drivers/media/video/marvell-ccic/mcam-core.c| 1683 +
drivers/media/video/marvell-ccic/mcam-core.h| 259 +++
drivers/media/video/marvell-ccic/mmp-driver.c | 339
drivers/media/video/ov7670.c|3 +-
include/media/mmp-camera.h |9 +
{drivers/media/video = include/media}/ov7670.h |0
include/media/v4l2-chip-ident.h |3 +-
14 files changed, 2971 insertions(+), 2446 deletions(-)
delete mode 100644 drivers/media/video/cafe_ccic-regs.h
delete mode 100644 drivers/media/video/cafe_ccic.c
create mode 100644 drivers/media/video/marvell-ccic/Kconfig
create mode 100644 drivers/media/video/marvell-ccic/Makefile
create mode 100644 drivers/media/video/marvell-ccic/cafe-driver.c
create mode 100644 drivers/media/video/marvell-ccic/mcam-core.c
create mode 100644 drivers/media/video/marvell-ccic/mcam-core.h
create mode 100644 drivers/media/video/marvell-ccic/mmp-driver.c
create mode 100644 include/media/mmp-camera.h
rename {drivers/media/video = include/media}/ov7670.h (100%)
Thanks,
jon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] marvell-cam: Pass sensor parameters from the platform
Depending on the controller, the ov7670 sensor may be told to work with a
different clock speed or to use the SMBUS protocol. Remove the wired-in
code and pass that information from the platform layer. The Cafe driver
now just assumes it's running on an OLPC XO 1; I do not believe it has ever
run anywhere else.
Cc: Daniel Drake d...@laptop.org
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |6 ++
drivers/media/video/marvell-ccic/mcam-core.c | 22 ++
drivers/media/video/marvell-ccic/mcam-core.h |2 ++
3 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 3f38f2a..08edf95 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -404,6 +404,12 @@ static int cafe_pci_probe(struct pci_dev *pdev,
mcam-plat_power_down = cafe_ctlr_power_down;
mcam-dev = pdev-dev;
/*
+* Set the clock speed for the XO 1; I don't believe this
+* driver has ever run anywhere else.
+*/
+ mcam-clock_speed = 45;
+ mcam-use_smbus = 1;
+ /*
* Get set up on the PCI bus.
*/
ret = pci_enable_device(pdev);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 18fce9e..0d60234 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -7,7 +7,6 @@
#include linux/kernel.h
#include linux/module.h
#include linux/fs.h
-#include linux/dmi.h
#include linux/mm.h
#include linux/i2c.h
#include linux/interrupt.h
@@ -1536,22 +1535,7 @@ int mccic_irq(struct mcam_camera *cam, unsigned int irqs)
* Registration and such.
*/
-/* FIXME this is really platform stuff */
-static const struct dmi_system_id olpc_xo1_dmi[] = {
- {
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, OLPC),
- DMI_MATCH(DMI_PRODUCT_NAME, XO),
- DMI_MATCH(DMI_PRODUCT_VERSION, 1),
- },
- },
- { }
-};
-
static struct ov7670_config sensor_cfg = {
- /* This controller only does SMBUS */
- .use_smbus = true,
-
/*
* Exclude QCIF mode, because it only captures a tiny portion
* of the sensor FOV
@@ -1590,13 +1574,11 @@ int mccic_register(struct mcam_camera *cam)
mcam_ctlr_init(cam);
- /* Apply XO-1 clock speed */
- if (dmi_check_system(olpc_xo1_dmi))
- sensor_cfg.clock_speed = 45;
-
/*
* Try to find the sensor.
*/
+ sensor_cfg.clock_speed = cam-clock_speed;
+ sensor_cfg.use_smbus = cam-use_smbus;
cam-sensor_addr = ov7670_info.addr;
cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev,
cam-i2c_adapter, ov7670_info, NULL);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.h
b/drivers/media/video/marvell-ccic/mcam-core.h
index 0b55b8e..21485e7 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.h
+++ b/drivers/media/video/marvell-ccic/mcam-core.h
@@ -42,6 +42,8 @@ struct mcam_camera {
spinlock_t dev_lock;
struct device *dev; /* For messages, dma alloc */
unsigned int chip_id;
+ short int clock_speed; /* Sensor clock speed, default 30 */
+ short int use_smbus;/* SMBUS or straight I2c? */
/*
* Callbacks from the core to the platform code.
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] marvell-cam: Move Cafe-specific register definitions to cafe-driver.c
Nobody else ever needs to see these, so let's hide them.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c | 63
drivers/media/video/marvell-ccic/mcam-core.h | 56 +-
2 files changed, 64 insertions(+), 55 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 91ba74b..1027265 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -57,6 +57,69 @@ struct cafe_camera {
};
/*
+ * Most of the camera controller registers are defined in mcam-core.h,
+ * but the Cafe platform has some additional registers of its own;
+ * they are described here.
+ */
+
+/*
+ * General purpose register has a couple of GPIOs used for sensor
+ * power and reset on OLPC XO 1.0 systems.
+ */
+#define REG_GPR0xb4
+#define GPR_C1EN0x0020/* Pad 1 (power down) enable */
+#define GPR_C0EN0x0010/* Pad 0 (reset) enable */
+#define GPR_C1 0x0002/* Control 1 value */
+/*
+ * Control 0 is wired to reset on OLPC machines. For ov7x sensors,
+ * it is active low.
+ */
+#define GPR_C0 0x0001/* Control 0 value */
+
+/*
+ * These registers control the SMBUS module for communicating
+ * with the sensor.
+ */
+#define REG_TWSIC0 0xb8/* TWSI (smbus) control 0 */
+#define TWSIC0_EN 0x0001/* TWSI enable */
+#define TWSIC0_MODE 0x0002/* 1 = 16-bit, 0 = 8-bit */
+#define TWSIC0_SID 0x03fc/* Slave ID */
+#define TWSIC0_SID_SHIFT 2
+#define TWSIC0_CLKDIV 0x0007fc00/* Clock divider */
+#define TWSIC0_MASKACK 0x0040/* Mask ack from sensor */
+#define TWSIC0_OVMAGIC 0x0080/* Make it work on OV sensors */
+
+#define REG_TWSIC1 0xbc/* TWSI control 1 */
+#define TWSIC1_DATA 0x/* Data to/from camchip */
+#define TWSIC1_ADDR 0x00ff/* Address (register) */
+#define TWSIC1_ADDR_SHIFT 16
+#define TWSIC1_READ 0x0100/* Set for read op */
+#define TWSIC1_WSTAT0x0200/* Write status */
+#define TWSIC1_RVALID 0x0400/* Read data valid */
+#define TWSIC1_ERROR0x0800/* Something screwed up */
+
+/*
+ * Here's the weird global control registers
+ */
+#define REG_GL_CSR 0x3004 /* Control/status register */
+#define GCSR_SRS 0x0001 /* SW Reset set */
+#define GCSR_SRC 0x0002 /* SW Reset clear */
+#define GCSR_MRS 0x0004 /* Master reset set */
+#define GCSR_MRC 0x0008 /* HW Reset clear */
+#define GCSR_CCIC_EN 0x4000/* CCIC Clock enable */
+#define REG_GL_IMASK 0x300c /* Interrupt mask register */
+#define GIMSK_CCIC_EN 0x0004/* CCIC Interrupt enable
*/
+
+#define REG_GL_FCR 0x3038 /* GPIO functional control register */
+#define GFCR_GPIO_ON0x08 /* Camera GPIO enabled */
+#define REG_GL_GPIOR 0x315c /* GPIO register */
+#define GGPIO_OUT 0x8 /* GPIO output */
+#define GGPIO_VAL 0x8 /* Output pin value */
+
+#define REG_LEN (REG_GL_IMASK + 4)
+
+
+/*
* Debugging and related.
*/
#define cam_err(cam, fmt, arg...) \
diff --git a/drivers/media/video/marvell-ccic/mcam-core.h
b/drivers/media/video/marvell-ccic/mcam-core.h
index 21485e7..e8a7de0 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.h
+++ b/drivers/media/video/marvell-ccic/mcam-core.h
@@ -249,64 +249,10 @@ int mccic_resume(struct mcam_camera *cam);
#define REG_CLKCTRL0x88/* Clock control */
#define CLK_DIV_MASK0x/* Upper bits RW reserved */
-#define REG_GPR0xb4/* General purpose register. This
- controls inputs to the power and reset
- pins on the OV7670 used with OLPC;
- other deployments could differ. */
-#define GPR_C1EN0x0020/* Pad 1 (power down) enable */
-#define GPR_C0EN0x0010/* Pad 0 (reset) enable */
-#define GPR_C1 0x0002/* Control 1 value */
-/*
- * Control 0 is wired to reset on OLPC machines. For ov7x sensors,
- * it is active low, for 0v6x, instead, it's active high. What
- * fun.
- */
-#define GPR_C0 0x0001/* Control 0 value */
-
-#define REG_TWSIC0 0xb8/* TWSI (smbus) control 0 */
-#define TWSIC0_EN 0x0001/* TWSI enable */
-#define TWSIC0_MODE 0x0002/* 1 = 16-bit, 0 = 8-bit */
-#define TWSIC0_SID 0x03fc
[PATCH 4/8] marvell-cam: Remove the untested comment
This code is, indeed, tested :) Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/media/video/marvell-ccic/cafe-driver.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c b/drivers/media/video/marvell-ccic/cafe-driver.c index 08edf95..91ba74b 100644 --- a/drivers/media/video/marvell-ccic/cafe-driver.c +++ b/drivers/media/video/marvell-ccic/cafe-driver.c @@ -14,9 +14,6 @@ * v4l2_device/v4l2_subdev conversion by: * Copyright (C) 2009 Hans Verkuil hverk...@xs4all.nl * - * Note: this conversion is untested! Please contact the linux-media - * mailinglist if you can test this, together with the test results. - * * This file may be distributed under the terms of the GNU General * Public License, version 2. */ -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] marvell-cam: Allocate the i2c adapter in the platform driver
The upcoming mmp-camera driver will need an i2c_adapter structure allocated
externally, so change the core adapter to a pointer and require the
platform code to fill it in.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 +++--
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.h |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 3dbc7e5..6a29cc1 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -334,9 +334,13 @@ static struct i2c_algorithm cafe_smbus_algo = {
static int cafe_smbus_setup(struct cafe_camera *cam)
{
- struct i2c_adapter *adap = cam-mcam.i2c_adapter;
+ struct i2c_adapter *adap;
int ret;
+ adap = kzalloc(sizeof(*adap), GFP_KERNEL);
+ if (adap == NULL)
+ return -ENOMEM;
+ cam-mcam.i2c_adapter = adap;
cafe_smbus_enable_irq(cam);
adap-owner = THIS_MODULE;
adap-algo = cafe_smbus_algo;
@@ -351,7 +355,8 @@ static int cafe_smbus_setup(struct cafe_camera *cam)
static void cafe_smbus_shutdown(struct cafe_camera *cam)
{
- i2c_del_adapter(cam-mcam.i2c_adapter);
+ i2c_del_adapter(cam-mcam.i2c_adapter);
+ kfree(cam-mcam.i2c_adapter);
}
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index d5f18a3..014b70b 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -1581,7 +1581,7 @@ int mccic_register(struct mcam_camera *cam)
sensor_cfg.use_smbus = cam-use_smbus;
cam-sensor_addr = ov7670_info.addr;
cam-sensor = v4l2_i2c_new_subdev_board(cam-v4l2_dev,
- cam-i2c_adapter, ov7670_info, NULL);
+ cam-i2c_adapter, ov7670_info, NULL);
if (cam-sensor == NULL) {
ret = -ENODEV;
goto out_unregister;
diff --git a/drivers/media/video/marvell-ccic/mcam-core.h
b/drivers/media/video/marvell-ccic/mcam-core.h
index e8a7de0..5effa82 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.h
+++ b/drivers/media/video/marvell-ccic/mcam-core.h
@@ -37,7 +37,7 @@ struct mcam_camera {
* These fields should be set by the platform code prior to
* calling mcam_register().
*/
- struct i2c_adapter i2c_adapter;
+ struct i2c_adapter *i2c_adapter;
unsigned char __iomem *regs;
spinlock_t dev_lock;
struct device *dev; /* For messages, dma alloc */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] marvell-cam: Basic working MMP camera driver
Now we have a camera working over the marvell cam controller core. It
works like the cafe driver and has all the same limitations, contiguous DMA
only being one of them. But it's a start.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Makefile |1 +
drivers/media/video/marvell-ccic/Kconfig | 11 +
drivers/media/video/marvell-ccic/Makefile |4 +
drivers/media/video/marvell-ccic/mcam-core.c | 28 ++-
drivers/media/video/marvell-ccic/mmp-driver.c | 339 +
include/media/mmp-camera.h|9 +
include/media/v4l2-chip-ident.h |3 +-
7 files changed, 386 insertions(+), 9 deletions(-)
create mode 100644 drivers/media/video/marvell-ccic/mmp-driver.c
create mode 100644 include/media/mmp-camera.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 42b6a7a..89478f0 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/
+obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/video/marvell-ccic/Kconfig
b/drivers/media/video/marvell-ccic/Kconfig
index 80136a8..b4f7260 100644
--- a/drivers/media/video/marvell-ccic/Kconfig
+++ b/drivers/media/video/marvell-ccic/Kconfig
@@ -7,3 +7,14 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+config VIDEO_MMP_CAMERA
+ tristate Marvell Armada 610 integrated camera controller support
+ depends on ARCH_MMP I2C VIDEO_V4L2
+ select VIDEO_OV7670
+ select I2C_GPIO
+ ---help---
+ This is a Video4Linux2 driver for the integrated camera
+ controller found on Marvell Armada 610 application
+ processors (and likely beyond). This is the controller found
+ in OLPC XO 1.75 systems.
+
diff --git a/drivers/media/video/marvell-ccic/Makefile
b/drivers/media/video/marvell-ccic/Makefile
index 462b385c..05a792c 100644
--- a/drivers/media/video/marvell-ccic/Makefile
+++ b/drivers/media/video/marvell-ccic/Makefile
@@ -1,2 +1,6 @@
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
cafe_ccic-y := cafe-driver.o mcam-core.o
+
+obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o
+mmp_camera-y := mmp-driver.o mcam-core.o
+
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 014b70b..3e6a5e8 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -167,7 +167,7 @@ static void mcam_set_config_needed(struct mcam_camera *cam,
int needed)
/*
- * Debugging and related. FIXME these are broken
+ * Debugging and related.
*/
#define cam_err(cam, fmt, arg...) \
dev_err((cam)-dev, fmt, ##arg);
@@ -202,7 +202,8 @@ static void mcam_ctlr_dma(struct mcam_camera *cam)
mcam_reg_clear_bit(cam, REG_CTRL1, C1_TWOBUFS);
} else
mcam_reg_set_bit(cam, REG_CTRL1, C1_TWOBUFS);
- mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only for now */
+ if (cam-chip_id == V4L2_IDENT_CAFE)
+ mcam_reg_write(cam, REG_UBAR, 0); /* 32 bits only */
}
static void mcam_ctlr_image(struct mcam_camera *cam)
@@ -358,8 +359,8 @@ static void mcam_ctlr_power_up(struct mcam_camera *cam)
unsigned long flags;
spin_lock_irqsave(cam-dev_lock, flags);
- mcam_reg_clear_bit(cam, REG_CTRL1, C1_PWRDWN);
cam-plat_power_up(cam);
+ mcam_reg_clear_bit(cam, REG_CTRL1, C1_PWRDWN);
spin_unlock_irqrestore(cam-dev_lock, flags);
msleep(5); /* Just to be sure */
}
@@ -369,8 +370,13 @@ static void mcam_ctlr_power_down(struct mcam_camera *cam)
unsigned long flags;
spin_lock_irqsave(cam-dev_lock, flags);
- cam-plat_power_down(cam);
+ /*
+* School of hard knocks department: be sure we do any register
+* twiddling on the controller *before* calling the platform
+* power down routine.
+*/
mcam_reg_set_bit(cam, REG_CTRL1, C1_PWRDWN);
+ cam-plat_power_down(cam);
spin_unlock_irqrestore(cam-dev_lock, flags);
}
@@ -1622,14 +1628,20 @@ out_unregister:
void mccic_shutdown(struct mcam_camera *cam)
{
- if (cam-users 0)
+ /*
+* If we have no users (and we really, really should have no
+* users) the device will already be powered down. Trying to
+* take it down again will wedge the machine, which is frowned
+* upon.
+*/
+ if (cam-users 0) {
cam_warn(cam, Removing a device with users!\n);
+ mcam_ctlr_power_down(cam);
+ }
+ mcam_free_dma_bufs(cam);
if (cam-n_sbufs 0)
/* What if they are still
[PATCH 6/8] marvell-cam: Right-shift i2c slave ID's in the cafe driver
This makes the cafe i2c implement consistent with the rest of Linux so that
the core can use the same slave ID everywhere.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 -
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 1027265..3dbc7e5 100644
--- a/drivers/media/video/marvell-ccic/cafe-driver.c
+++ b/drivers/media/video/marvell-ccic/cafe-driver.c
@@ -84,7 +84,14 @@ struct cafe_camera {
#define TWSIC0_EN 0x0001/* TWSI enable */
#define TWSIC0_MODE 0x0002/* 1 = 16-bit, 0 = 8-bit */
#define TWSIC0_SID 0x03fc/* Slave ID */
-#define TWSIC0_SID_SHIFT 2
+/*
+ * Subtle trickery: the slave ID field starts with bit 2. But the
+ * Linux i2c stack wants to treat the bottommost bit as a separate
+ * read/write bit, which is why slave ID's are usually presented
+ * 1. For consistency with that behavior, we shift over three
+ * bits instead of two.
+ */
+#define TWSIC0_SID_SHIFT 3
#define TWSIC0_CLKDIV 0x0007fc00/* Clock divider */
#define TWSIC0_MASKACK 0x0040/* Mask ack from sensor */
#define TWSIC0_OVMAGIC 0x0080/* Make it work on OV sensors */
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 0d60234..d5f18a3 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -1549,7 +1549,7 @@ int mccic_register(struct mcam_camera *cam)
{
struct i2c_board_info ov7670_info = {
.type = ov7670,
- .addr = 0x42,
+ .addr = 0x42 1,
.platform_data = sensor_cfg,
};
int ret;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv3 PATCH 0/6] tuner-core: fix g_freq/s_std and g/s_tuner
Third version of this patch series. Pretty much the same as RFCv2 (except for a small fix in the fourth patch) except for patch 6. This it my attempt to fix tuner-core without having to change any drivers. It just keeps track of whether the current application mode is valid for this tuner. If not, then g_freq and g/s_tuner do nothing. -- 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
[RFCv3 PATCH 2/6] tuner-core: change return type of set_mode_freq to bool
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 23 ++-
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 083b9f1..ee43e0a 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -746,11 +746,11 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
* @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
- * debug message and returns -EINVAL, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value, if
- * the tuner can sleep or if it supports both Radio and TV.
+ * debug message and returns false, changing its state to standby.
+ * Otherwise, changes the state and sets frequency to the last value
+ * and returns true.
*/
-static int set_mode_freq(struct i2c_client *client, struct tuner *t,
+static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
enum v4l2_tuner_type mode, unsigned int freq)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -762,7 +762,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
t-standby = true;
if (analog_ops-standby)
analog_ops-standby(t-fe);
- return -EINVAL;
+ return false;
}
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
@@ -777,7 +777,7 @@ static int set_mode_freq(struct i2c_client *client, struct
tuner *t,
set_tv_freq(client, t-tv_freq);
}
- return 0;
+ return true;
}
/*
@@ -1075,8 +1075,7 @@ static int tuner_s_radio(struct v4l2_subdev *sd)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_RADIO, 0) == -EINVAL)
- return 0;
+ set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
return 0;
}
@@ -1110,7 +1109,7 @@ static int tuner_s_std(struct v4l2_subdev *sd,
v4l2_std_id std)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
return 0;
t-std = std;
@@ -1124,9 +1123,7 @@ static int tuner_s_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, f-type, f-frequency) == -EINVAL)
- return 0;
-
+ set_mode_freq(client, t, f-type, f-frequency);
return 0;
}
@@ -1197,7 +1194,7 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct tuner *t = to_tuner(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (set_mode_freq(client, t, vt-type, 0) == -EINVAL)
+ if (!set_mode_freq(client, t, vt-type, 0))
return 0;
if (t-mode == V4L2_TUNER_RADIO)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv3 PATCH 3/6] tuner-core: simplify the standard fixup.
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index ee43e0a..462a8f4 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -832,7 +832,7 @@ static void set_tv_freq(struct i2c_client *c, unsigned int
freq)
/**
* tuner_fixup_std - force a given video standard variant
*
- * @t: tuner internal struct
+ * @std: TV standard
*
* A few devices or drivers have problem to detect some standard variations.
* On other operational systems, the drivers generally have a per-country
@@ -842,57 +842,39 @@ static void set_tv_freq(struct i2c_client *c, unsigned
int freq)
* to distinguish all video standard variations, a modprobe parameter can
* be used to force a video standard match.
*/
-static int tuner_fixup_std(struct tuner *t)
+static v4l2_std_id tuner_fixup_std(struct tuner *t, v4l2_std_id std)
{
- if ((t-std V4L2_STD_PAL) == V4L2_STD_PAL) {
+ if (pal[0] != '-' (std V4L2_STD_PAL) == V4L2_STD_PAL) {
switch (pal[0]) {
case '6':
- tuner_dbg(insmod fixup: PAL = PAL-60\n);
- t-std = V4L2_STD_PAL_60;
- break;
+ return V4L2_STD_PAL_60;
case 'b':
case 'B':
case 'g':
case 'G':
- tuner_dbg(insmod fixup: PAL = PAL-BG\n);
- t-std = V4L2_STD_PAL_BG;
- break;
+ return V4L2_STD_PAL_BG;
case 'i':
case 'I':
- tuner_dbg(insmod fixup: PAL = PAL-I\n);
- t-std = V4L2_STD_PAL_I;
- break;
+ return V4L2_STD_PAL_I;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: PAL = PAL-DK\n);
- t-std = V4L2_STD_PAL_DK;
- break;
+ return V4L2_STD_PAL_DK;
case 'M':
case 'm':
- tuner_dbg(insmod fixup: PAL = PAL-M\n);
- t-std = V4L2_STD_PAL_M;
- break;
+ return V4L2_STD_PAL_M;
case 'N':
case 'n':
- if (pal[1] == 'c' || pal[1] == 'C') {
- tuner_dbg(insmod fixup: PAL = PAL-Nc\n);
- t-std = V4L2_STD_PAL_Nc;
- } else {
- tuner_dbg(insmod fixup: PAL = PAL-N\n);
- t-std = V4L2_STD_PAL_N;
- }
- break;
- case '-':
- /* default parameter, do nothing */
- break;
+ if (pal[1] == 'c' || pal[1] == 'C')
+ return V4L2_STD_PAL_Nc;
+ return V4L2_STD_PAL_N;
default:
tuner_warn(pal= argument not recognised\n);
break;
}
}
- if ((t-std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
+ if (secam[0] != '-' (std V4L2_STD_SECAM) == V4L2_STD_SECAM) {
switch (secam[0]) {
case 'b':
case 'B':
@@ -900,63 +882,42 @@ static int tuner_fixup_std(struct tuner *t)
case 'G':
case 'h':
case 'H':
- tuner_dbg(insmod fixup: SECAM = SECAM-BGH\n);
- t-std = V4L2_STD_SECAM_B |
-V4L2_STD_SECAM_G |
-V4L2_STD_SECAM_H;
- break;
+ return V4L2_STD_SECAM_B |
+ V4L2_STD_SECAM_G |
+ V4L2_STD_SECAM_H;
case 'd':
case 'D':
case 'k':
case 'K':
- tuner_dbg(insmod fixup: SECAM = SECAM-DK\n);
- t-std = V4L2_STD_SECAM_DK;
- break;
+ return V4L2_STD_SECAM_DK;
case 'l':
case 'L':
- if ((secam[1] == 'C') || (secam[1] == 'c')) {
- tuner_dbg(insmod fixup: SECAM = SECAM-L'\n);
- t-std = V4L2_STD_SECAM_LC;
- } else {
- tuner_dbg(insmod fixup: SECAM = SECAM-L\n);
-
[RFCv3 PATCH 5/6] tuner-core: fix tuner_resume: use t-mode instead of t-type.
From: Hans Verkuil hans.verk...@cisco.com set_mode is called with t-type, which is the tuner type. Instead, use t-mode which is the actual tuner mode (i.e. radio vs tv). Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/video/tuner-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index bf7fc33..ffe5de3 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1201,7 +1201,7 @@ static int tuner_resume(struct i2c_client *c) tuner_dbg(resume\n); if (!t-standby) - if (set_mode(t, t-type)) + if (set_mode(t, t-mode)) set_freq(t, 0); return 0; } -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv3 PATCH 4/6] tuner-core: fix s_std and s_tuner.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true (i.e. the mode is supported)
then they set t-std/t-audmode and call set_freq.
This fixes a bug where changing std or audmode would actually change it to
the previous value.
Discovered while testing analog TV standards for cx18 with a tda18271 tuner.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 60 +-
1 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 462a8f4..bf7fc33 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -739,19 +739,15 @@ static bool supported_mode(struct tuner *t, enum
v4l2_tuner_type mode)
}
/**
- * set_mode_freq - Switch tuner to other mode.
- * @client:struct i2c_client pointer
+ * set_mode - Switch tuner to other mode.
* @t: a pointer to the module's internal struct_tuner
* @mode: enum v4l2_type (radio or TV)
- * @freq: frequency to set (0 means to use the previous one)
*
* If tuner doesn't support the needed mode (radio or TV), prints a
* debug message and returns false, changing its state to standby.
- * Otherwise, changes the state and sets frequency to the last value
- * and returns true.
+ * Otherwise, changes the state and returns true.
*/
-static bool set_mode_freq(struct i2c_client *client, struct tuner *t,
-enum v4l2_tuner_type mode, unsigned int freq)
+static bool set_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
@@ -767,17 +763,27 @@ static bool set_mode_freq(struct i2c_client *client,
struct tuner *t,
t-mode = mode;
tuner_dbg(Changing to mode %d\n, mode);
}
+ return true;
+}
+
+/**
+ * set_freq - Set the tuner to the desired frequency.
+ * @t: a pointer to the module's internal struct_tuner
+ * @freq: frequency to set (0 means to use the current frequency)
+ */
+static void set_freq(struct tuner *t, unsigned int freq)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(t-sd);
+
if (t-mode == V4L2_TUNER_RADIO) {
- if (freq)
- t-radio_freq = freq;
- set_radio_freq(client, t-radio_freq);
+ if (!freq)
+ freq = t-radio_freq;
+ set_radio_freq(client, freq);
} else {
- if (freq)
- t-tv_freq = freq;
- set_tv_freq(client, t-tv_freq);
+ if (!freq)
+ freq = t-tv_freq;
+ set_tv_freq(client, freq);
}
-
- return true;
}
/*
@@ -1034,9 +1040,9 @@ static void tuner_status(struct dvb_frontend *fe)
static int tuner_s_radio(struct v4l2_subdev *sd)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, V4L2_TUNER_RADIO, 0);
+ if (set_mode(t, V4L2_TUNER_RADIO))
+ set_freq(t, 0);
return 0;
}
@@ -1068,24 +1074,23 @@ static int tuner_s_power(struct v4l2_subdev *sd, int on)
static int tuner_s_std(struct v4l2_subdev *sd, v4l2_std_id std)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, V4L2_TUNER_ANALOG_TV, 0))
+ if (!set_mode(t, V4L2_TUNER_ANALOG_TV))
return 0;
t-std = tuner_fixup_std(t, std);
if (t-std != std)
tuner_dbg(Fixup standard %llx to %llx\n, std, t-std);
-
+ set_freq(t, 0);
return 0;
}
static int tuner_s_frequency(struct v4l2_subdev *sd, struct v4l2_frequency *f)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- set_mode_freq(client, t, f-type, f-frequency);
+ if (set_mode(t, f-type))
+ set_freq(t, f-frequency);
return 0;
}
@@ -1154,13 +1159,14 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
static int tuner_s_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- if (!set_mode_freq(client, t, vt-type, 0))
+ if (!set_mode(t, vt-type))
return 0;
- if (t-mode == V4L2_TUNER_RADIO)
+ if (t-mode == V4L2_TUNER_RADIO) {
t-audmode = vt-audmode;
+ set_freq(t, 0);
+ }
return 0;
}
@@ -1195,8 +1201,8 @@ static int tuner_resume(struct i2c_client *c)
tuner_dbg(resume\n);
[RFCv3 PATCH 6/6] tuner-core: fix g_frequency and g/s_tuner
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY and VIDIOC_G/S_TUNER should not check the tuner type,
instead that is something the driver fills in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the call just returns.
But the call should only return if the current selected mode is not
supported by this tuner. So add a 'valid_mode' bool to keep track of
that status and use it instead of calling supported_mode().
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index ffe5de3..094f277 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -127,7 +127,8 @@ struct tuner {
unsigned intaudmode;
enum v4l2_tuner_type mode;
- unsigned intmode_mask; /* Combination of allowable modes */
+ unsigned intmode_mask; /* Combination of allowable modes */
+ boolactive_mode; /* Current tuner mode is active */
boolstandby;/* Standby mode */
@@ -597,7 +598,7 @@ static int tuner_probe(struct i2c_client *client,
t-name = (tuner unset);
t-type = UNSET;
t-audmode = V4L2_TUNER_MODE_STEREO;
- t-standby = 1;
+ t-standby = true;
t-radio_freq = 87.5 * 16000; /* Initial freq range */
t-tv_freq = 400 * 16; /* Sets freq to VHF High - needed for some PLL's
to properly start */
@@ -685,6 +686,7 @@ register_client:
t-mode = V4L2_TUNER_ANALOG_TV;
else
t-mode = V4L2_TUNER_RADIO;
+ t-active_mode = true;
set_type(client, t-type, t-mode_mask, t-config, t-fe.callback);
list_add_tail(t-list, tuner_list);
@@ -756,11 +758,13 @@ static bool set_mode(struct tuner *t, enum
v4l2_tuner_type mode)
tuner_dbg(Tuner doesn't support mode %d.
Putting tuner to sleep\n, mode);
t-standby = true;
+ t-active_mode = false;
if (analog_ops-standby)
analog_ops-standby(t-fe);
return false;
}
t-mode = mode;
+ t-active_mode = true;
tuner_dbg(Changing to mode %d\n, mode);
}
return true;
@@ -1034,7 +1038,7 @@ static void tuner_status(struct dvb_frontend *fe)
}
/*
- * Function to splicitly change mode to radio. Probably not needed anymore
+ * Function to explicitly change mode to radio. Probably not needed anymore
*/
static int tuner_s_radio(struct v4l2_subdev *sd)
@@ -1099,7 +1103,7 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
struct tuner *t = to_tuner(sd);
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (!supported_mode(t, f-type))
+ if (!t-active_mode)
return 0;
f-type = t-mode;
if (fe_tuner_ops-get_frequency !t-standby) {
@@ -1122,7 +1126,7 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
struct analog_demod_ops *analog_ops = t-fe.ops.analog_ops;
struct dvb_tuner_ops *fe_tuner_ops = t-fe.ops.tuner_ops;
- if (!supported_mode(t, vt-type))
+ if (!t-active_mode)
return 0;
vt-type = t-mode;
if (analog_ops-get_afc)
@@ -1160,7 +1164,7 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
{
struct tuner *t = to_tuner(sd);
- if (!set_mode(t, vt-type))
+ if (!t-active_mode)
return 0;
if (t-mode == V4L2_TUNER_RADIO) {
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.
Hans Verkuil hverk...@xs4all.nl wrote: On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: Em 11-06-2011 10:34, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com According to the spec the tuner type field is not used when calling S_TUNER: index, audmode and reserved are the only writable fields. So remove the type check. Instead, just set the audmode if the current tuner mode is set to radio. I suspect that this patch also breaks support for a separate radio tuner. if tuner-type is not properly filled, then the easiest fix would be to revert some changes done at the tuner cleanup/fixup patches applied on .39. Yet, the previous logic were trying to hint the device mode, with is bad (that's why it was changed). The proper change seems to add a parameter to this callback, set by the bridge driver, informing if the device is using radio or video mode. We need also to patch the V4L API specs, as it allows using a video node for radio, and vice versa. This is not well supported, and it seems silly to keep it at the specs and needing to add hints at the drivers due to that. So, just to make sure I understand correctly what you want. The bridge or platform drivers will fill in the vf-type (for g/s_frequency) or vt-type (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, TV for anything else. What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this in. Will we just overwrite vf-type or will we check and return -EINVAL if the app tries to set e.g. a TV frequency on /dev/radio? Is VIDIOC_S_FREQUENCY allowed to change the tuner mode? E.g. if /dev/radio was opened, and now I open /dev/video and call S_FREQUENCY with the TV tuner type, should that change the tuner to tv mode? I think the type passed to S_FREQUENCY should 1) match the device node's type (if not, then return -EINVAL) and 2) should match the current mode (if not, then return -EBUSY). So attempts to change the TV frequency when in radio mode should fail. This second rule should also be valid for S_TUNER. What should G_TUNER return on a video node when in radio mode or vice versa? For G_FREQUENCY you can still return the last used frequency, but that's much more ambiguous for G_TUNER. One option is to set rxsubchans, signal and afc all to 0 if you query G_TUNER when 'in the wrong mode'. The VIDIOC_G/S_MODULATOR ioctls do not have a type and they are RADIO only, so that's OK. And how do we switch between radio and TV? Right now opening the radio node will set the tuner in radio mode, and calling S_STD will change the mode to TV again. As mentioned above, what S_FREQUENCY is supposed to do is undefined at the moment. What about this: Opening /dev/radio effectively starts the radio mode. So if there is TV capture in progress, then the open should return -EBUSY. Otherwise it switches the tuner to radio mode. And it stays in radio mode until the last filehandle of /dev/radio is closed. At that point it will automatically switch back to TV mode (if there is one, of course). While it is in radio mode calls to S_STD and S_FREQUENCY from /dev/video will return -EBUSY. Any attempt to start streaming from /dev/video will also return -EBUSY (radio 'streaming' is in progress after all). Effectively, S_STD no longer switches back to TV mode. That only happens when the last user of /dev/radio left. It certainly sounds a lot saner to me. Of course, I'm ignoring DVB in this story. You may have to negotiate between radio, Tv and DVB. Anyway, this all sounds very nice, but it's a heck of a lot of work. I'd much rather just fix this bug without changing the spec and behavior of drivers. That's a nice project perhaps for a rainy day (or week...), but not for a fix that is needed asap and that works for kernel v3.0. The whole radio/tv/dvb tuner selection is a big mess and needs to be solved, but let's do that in a separate project. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html You have to be able to stream from a video node /dev/video24 when /dev/radio is open. /dev/radio is a control only node. (Under current spec behavior.) Also there is at least one non-test app out there, brought up on the ivtv lists a few months ago in the context of v4l2 priorty handling, that, IIRC, makes calls on /dev/video24 with /dev/radio open. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jun 11 19:02:27 CEST 2011 git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 7/7] tuner-core: s_tuner should not change tuner mode.
Em 11-06-2011 14:27, Hans Verkuil escreveu: On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote: Em 11-06-2011 10:34, Hans Verkuil escreveu: From: Hans Verkuil hans.verk...@cisco.com According to the spec the tuner type field is not used when calling S_TUNER: index, audmode and reserved are the only writable fields. So remove the type check. Instead, just set the audmode if the current tuner mode is set to radio. I suspect that this patch also breaks support for a separate radio tuner. if tuner-type is not properly filled, then the easiest fix would be to revert some changes done at the tuner cleanup/fixup patches applied on .39. Yet, the previous logic were trying to hint the device mode, with is bad (that's why it was changed). The proper change seems to add a parameter to this callback, set by the bridge driver, informing if the device is using radio or video mode. We need also to patch the V4L API specs, as it allows using a video node for radio, and vice versa. This is not well supported, and it seems silly to keep it at the specs and needing to add hints at the drivers due to that. So, just to make sure I understand correctly what you want. The bridge or platform drivers will fill in the vf-type (for g/s_frequency) or vt-type (for g/s_tuner) based on the device node: RADIO if /dev/radio is used, TV for anything else. Yes. I remember I've reviewed the bridge drivers when I rewrote the tuner code. Of course, I might have left something else. Btw, the older code were also requiring it. The cx18 implementation were merged after the changes, so maybe it is not doing the right thing. What about VIDIOC_S_FREQUENCY? The spec says that the app needs to fill this in. Will we just overwrite vf-type or will we check and return -EINVAL if the app tries to set e.g. a TV frequency on /dev/radio? That's a very good question. What happens is that the V4L2 API used to allow opening a /dev/radio device for TV (or even for VBI). IMHO, this were a trouble at the API specs. I think that this were changed on newer versions of the spec. Is VIDIOC_S_FREQUENCY allowed to change the tuner mode? E.g. if /dev/radio was opened, and now I open /dev/video and call S_FREQUENCY with the TV tuner type, should that change the tuner to tv mode? Yes. I think that some applications like kradio just keeps the device node opened. If we return -EBUSY, those applications will break. The reverse is more tricky: e. g. if /dev/video is streaming, I think that the bridge driver should return -EBUSY if the device can't do both TV and radio at the same time, but this is something that it is device-specific, so such logic, if needed, should be implemented at the bridge driver. I think the type passed to S_FREQUENCY should 1) match the device node's type (if not, then return -EINVAL) and 2) should match the current mode (if not, then return -EBUSY). So attempts to change the TV frequency when in radio mode should fail. This second rule should also be valid for S_TUNER. See above. What should G_TUNER return on a video node when in radio mode or vice versa? For G_FREQUENCY you can still return the last used frequency, but that's much more ambiguous for G_TUNER. One option is to set rxsubchans, signal and afc all to 0 if you query G_TUNER when 'in the wrong mode'. The current logic should handle this case well. I tested it carefully. Basically, if the device is on Radio mode, and has a separate tuner for TV, the TV tuner should not touch the structure. The Radio tuner should properly fill the values. Calls to G_TUNER/G_FREQUENCY shouldn't switch the device mode, or they may break applications like kradio, that may be always there during the entire KDE section. The VIDIOC_G/S_MODULATOR ioctls do not have a type and they are RADIO only, so that's OK. And how do we switch between radio and TV? Right now opening the radio node will set the tuner in radio mode, and calling S_STD will change the mode to TV again. As mentioned above, what S_FREQUENCY is supposed to do is undefined at the moment. If S_FREQUENCY is called from /dev/video (or /dev/vbi), it should set it to TV. If it is called from /dev/radio, it should put the device on radio mode. The current logic already does that. I tested it on several devices, with both tea5767 and without it. What about this: Opening /dev/radio effectively starts the radio mode. So if there is TV capture in progress, then the open should return -EBUSY. Otherwise it switches the tuner to radio mode. And it stays in radio mode until the last filehandle of /dev/radio is closed. At that point it will automatically switch back to TV mode (if there is one, of course). No. This would break existing applications. The mode switch should be done at S_FREQUENCY (e. g. when the radio application is tuning into a channel). While it is in radio mode calls to S_STD and S_FREQUENCY from /dev/video will return -EBUSY. Any attempt to start
