[PATCH 25/47] [media] mt2063: Simplify mt2063_setTune logic
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 37 ++---
1 files changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 3c0b3f1..53e3960 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -323,34 +323,6 @@ static u32 MT2063_ClearPowerMaskBits(struct mt2063_state
*state, enum MT2063_Mas
/*/
/* From drivers/media/common/tuners/mt2063_cfg.h */
-unsigned int mt2063_setTune(struct dvb_frontend *fe, u32 f_in,
- u32 bw_in,
- enum MTTune_atv_standard tv_type)
-{
- struct dvb_frontend_ops *frontend_ops = NULL;
- struct dvb_tuner_ops *tuner_ops = NULL;
- struct tuner_state t_state;
- struct mt2063_state *state = fe-tuner_priv;
- int err = 0;
-
- t_state.frequency = f_in;
- t_state.bandwidth = bw_in;
- state-tv_type = tv_type;
- if (fe-ops)
- frontend_ops = fe-ops;
- if (frontend_ops-tuner_ops)
- tuner_ops = frontend_ops-tuner_ops;
- if (tuner_ops-set_state) {
- if ((err =
-tuner_ops-set_state(fe, DVBFE_TUNER_FREQUENCY,
- t_state)) 0) {
- printk(%s: Invalid parameter\n, __func__);
- return err;
- }
- }
-
- return err;
-}
unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe)
{
@@ -2862,19 +2834,16 @@ static u32 MT2063_Tune(struct mt2063_state *state, u32
f_in)
return status;
}
-static u32 MT_Tune_atv(void *h, u32 f_in, u32 bw_in,
- enum MTTune_atv_standard tv_type)
+unsigned int mt2063_setTune(void *h, u32 f_in, u32 bw_in,
+ enum MTTune_atv_standard tv_type)
{
-
u32 status = 0;
-
s32 pict_car = 0;
s32 pict2chanb_vsb = 0;
s32 pict2chanb_snd = 0;
s32 pict2snd1 = 0;
s32 pict2snd2 = 0;
s32 ch_bw = 0;
-
s32 if_mid = 0;
s32 rcvr_mode = 0;
u32 mode_get = 0;
@@ -3290,7 +3259,7 @@ static int mt2063_set_state(struct dvb_frontend *fe,
//set frequency
status =
- MT_Tune_atv(state,
+ mt2063_setTune(state,
tunstate-frequency, tunstate-bandwidth,
state-tv_type);
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/47] [media] mt2063: Rework on the publicly-exported functions
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 44 ++
drivers/media/common/tuners/mt2063.h |2 +-
2 files changed, 14 insertions(+), 32 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 53e3960..0bf6292 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -320,53 +320,34 @@ static u32 MT2063_SoftwareShutdown(struct mt2063_state
*state, u8 Shutdown);
static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state, enum
MT2063_Mask_Bits Bits);
-/*/
-/* From drivers/media/common/tuners/mt2063_cfg.h */
-
-
+/*
+ * Ancillary routines visible outside mt2063
+ */
unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe)
{
struct mt2063_state *state = fe-tuner_priv;
- struct dvb_frontend_ops *frontend_ops = fe-ops;
- struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
int err = 0;
- if (fe-ops)
- frontend_ops = fe-ops;
- if (frontend_ops-tuner_ops)
- tuner_ops = frontend_ops-tuner_ops;
- if (tuner_ops-set_state) {
- err = MT2063_SoftwareShutdown(state, 1);
- if (err 0) {
- printk(%s: Invalid parameter\n, __func__);
- return err;
- }
- }
+ err = MT2063_SoftwareShutdown(state, 1);
+ if (err 0)
+ printk(KERN_ERR %s: Couldn't shutdown\n, __func__);
return err;
}
+EXPORT_SYMBOL_GPL(tuner_MT2063_SoftwareShutdown);
unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe)
{
struct mt2063_state *state = fe-tuner_priv;
- struct dvb_frontend_ops *frontend_ops = fe-ops;
- struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
int err = 0;
- if (fe-ops)
- frontend_ops = fe-ops;
- if (frontend_ops-tuner_ops)
- tuner_ops = frontend_ops-tuner_ops;
- if (tuner_ops-set_state) {
- err = MT2063_ClearPowerMaskBits(state, MT2063_ALL_SD);
- if (err 0) {
- printk(%s: Invalid parameter\n, __func__);
- return err;
- }
- }
+ err = MT2063_ClearPowerMaskBits(state, MT2063_ALL_SD);
+ if (err 0)
+ printk(KERN_ERR %s: Invalid parameter\n, __func__);
return err;
}
+EXPORT_SYMBOL_GPL(tuner_MT2063_ClearPowerMaskBits);
/*
* mt2063_write - Write data into the I2C bus
@@ -1173,6 +1154,7 @@ unsigned int mt2063_lockStatus(struct mt2063_state *state)
*/
return 0;
}
+EXPORT_SYMBOL_GPL(mt2063_lockStatus);
/
**
@@ -,8 +3315,8 @@ error:
kfree(state);
return NULL;
}
+EXPORT_SYMBOL_GPL(mt2063_attach);
-EXPORT_SYMBOL(mt2063_attach);
MODULE_PARM_DESC(verbose, Set Verbosity level);
MODULE_AUTHOR(Henry);
diff --git a/drivers/media/common/tuners/mt2063.h
b/drivers/media/common/tuners/mt2063.h
index 27273bf..a95c11e 100644
--- a/drivers/media/common/tuners/mt2063.h
+++ b/drivers/media/common/tuners/mt2063.h
@@ -27,8 +27,8 @@ unsigned int mt2063_setTune(struct dvb_frontend *fe, u32 f_in,
u32 bw_in,
enum MTTune_atv_standard tv_type);
+/* FIXME: Should use the standard DVB attachment interfaces */
unsigned int mt2063_lockStatus(struct dvb_frontend *fe);
-unsigned int tuner_MT2063_Open(struct dvb_frontend *fe);
unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe);
unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe);
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/47] [media] mt2063: Move data structures to the driver
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 529 +-
drivers/media/common/tuners/mt2063.h | 526 -
2 files changed, 528 insertions(+), 527 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 43e543e..0c4ae7f 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -12,6 +12,534 @@
static unsigned int verbose;
module_param(verbose, int, 0644);
+/* Internal structures and types */
+
+#define DVBFE_TUNER_OPEN 99
+#define DVBFE_TUNER_SOFTWARE_SHUTDOWN 100
+#define DVBFE_TUNER_CLEAR_POWER_MASKBITS 101
+
+#define MT2063_ERROR (1 31)
+#define MT2063_USER_ERROR (1 30)
+
+/* Macro to be used to check for errors */
+#define MT2063_IS_ERROR(s) (((s) 30) != 0)
+#define MT2063_NO_ERROR(s) (((s) 30) == 0)
+
+#define MT2063_OK (0x)
+
+/* Unknown error */
+#define MT2063_UNKNOWN (0x8001)
+
+/* Error: Upconverter PLL is not locked */
+#define MT2063_UPC_UNLOCK (0x8002)
+
+/* Error: Downconverter PLL is not locked */
+#define MT2063_DNC_UNLOCK (0x8004)
+
+/* Error: Two-wire serial bus communications error */
+#define MT2063_COMM_ERR (0x8008)
+
+/* Error: Tuner handle passed to function was invalid */
+#define MT2063_INV_HANDLE (0x8010)
+
+/* Error: Function argument is invalid (out of range) */
+#define MT2063_ARG_RANGE(0x8020)
+
+/* Error: Function argument (ptr to return value) was NULL */
+#define MT2063_ARG_NULL (0x8040)
+
+/* Error: Attempt to open more than MT_TUNER_CNT tuners */
+#define MT2063_TUNER_CNT_ERR(0x8080)
+
+/* Error: Tuner Part Code / Rev Code mismatches expected value */
+#define MT2063_TUNER_ID_ERR (0x8100)
+
+/* Error: Tuner Initialization failure */
+#define MT2063_TUNER_INIT_ERR (0x8200)
+
+#define MT2063_TUNER_OPEN_ERR (0x8400)
+
+/* User-definable fields (see mt_userdef.h) */
+#define MT2063_USER_DEFINED1(0x1000)
+#define MT2063_USER_DEFINED2(0x2000)
+#define MT2063_USER_DEFINED3(0x4000)
+#define MT2063_USER_DEFINED4(0x8000)
+#define MT2063_USER_MASK(0x4000f000)
+#define MT2063_USER_SHIFT (12)
+
+/* Info: Mask of bits used for # of LO-related spurs that were avoided during
tuning */
+#define MT2063_SPUR_CNT_MASK(0x001f)
+#define MT2063_SPUR_SHIFT (16)
+
+/* Info: Tuner timeout waiting for condition */
+#define MT2063_TUNER_TIMEOUT(0x0040)
+
+/* Info: Unavoidable LO-related spur may be present in the output */
+#define MT2063_SPUR_PRESENT_ERR (0x0080)
+
+/* Info: Tuner input frequency is out of range */
+#define MT2063_FIN_RANGE(0x0100)
+
+/* Info: Tuner output frequency is out of range */
+#define MT2063_FOUT_RANGE (0x0200)
+
+/* Info: Upconverter frequency is out of range (may be reason for
MT_UPC_UNLOCK) */
+#define MT2063_UPC_RANGE(0x0400)
+
+/* Info: Downconverter frequency is out of range (may be reason for
MT_DPC_UNLOCK) */
+#define MT2063_DNC_RANGE(0x0800)
+
+/*
+ * Data Types
+ */
+
+#define MAX_UDATA (4294967295) /* max value storable in u32 */
+
+/*
+ * Define an MT_CNT macro for each type of tuner that will be built
+ * into your application (e.g., MT2121, MT2060). MT_TUNER_CNT
+ * must be set to the SUM of all of the MT_CNT macros.
+ *
+ * #define MT2050_CNT (1)
+ * #define MT2060_CNT (1)
+ * #define MT2111_CNT (1)
+ * #define MT2121_CNT (3)
+ */
+
+
+#define MT2063_TUNER_CNT (1) /* total num of MicroTuner
tuners */
+#define MT2063_I2C (0xC0)
+
+/*
+ * Constant defining the version of the following structure
+ * and therefore the API for this code.
+ *
+ * When compiling the tuner driver, the preprocessor will
+ * check against this version number to make sure that
+ * it matches the version that the tuner driver knows about.
+ */
+/* Version 010201 = 1.21 */
+#define MT2063_AVOID_SPURS_INFO_VERSION 010201
+
+/* DECT Frequency Avoidance */
+#define MT2063_DECT_AVOID_US_FREQS 0x0001
+
+#define MT2063_DECT_AVOID_EURO_FREQS0x0002
+
+#define MT2063_EXCLUDE_US_DECT_FREQUENCIES(s) (((s)
MT2063_DECT_AVOID_US_FREQS) != 0)
+
+#define MT2063_EXCLUDE_EURO_DECT_FREQUENCIES(s) (((s)
MT2063_DECT_AVOID_EURO_FREQS) != 0)
+
+enum MT2063_DECT_Avoid_Type {
+ MT2063_NO_DECT_AVOIDANCE = 0, /* Do not
create DECT exclusion zones. */
+
[PATCH 21/47] [media] mt2063: Don't violate the DVB API
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 51 ++
1 files changed, 9 insertions(+), 42 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index c5e95dd..6c73bfd 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -10,10 +10,6 @@ module_param(verbose, int, 0644);
/* Internal structures and types */
-/* FIXME: we probably don't need these new FE get/set property types for tuner
*/
-#define DVBFE_TUNER_SOFTWARE_SHUTDOWN 100
-#define DVBFE_TUNER_CLEAR_POWER_MASKBITS 101
-
/* FIXME: Those two error codes need conversion*/
/* Error: Upconverter PLL is not locked */
#define MT2063_UPC_UNLOCK (0x8002)
@@ -411,6 +407,9 @@ static u32 MT2063_GetParam(struct mt2063_state *state, enum
MT2063_Param param,
static u32 MT2063_SetReg(struct mt2063_state *state, u8 reg, u8 val);
static u32 MT2063_SetParam(struct mt2063_state *state, enum MT2063_Param param,
enum MT2063_DNC_Output_Enable nValue);
+static u32 MT2063_SoftwareShutdown(struct mt2063_state *state, u8 Shutdown);
+static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state, enum
MT2063_Mask_Bits Bits);
+
/*/
/* From drivers/media/common/tuners/mt2063_cfg.h */
@@ -466,34 +465,12 @@ unsigned int mt2063_lockStatus(struct dvb_frontend *fe)
return err;
}
-unsigned int tuner_MT2063_Open(struct dvb_frontend *fe)
-{
- struct dvb_frontend_ops *frontend_ops = fe-ops;
- struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
- struct tuner_state t_state;
- int err = 0;
-
- if (fe-ops)
- frontend_ops = fe-ops;
- if (frontend_ops-tuner_ops)
- tuner_ops = frontend_ops-tuner_ops;
- if (tuner_ops-set_state) {
- if ((err =
-tuner_ops-set_state(fe, DVBFE_TUNER_OPEN,
- t_state)) 0) {
- printk(%s: Invalid parameter\n, __func__);
- return err;
- }
- }
-
- return err;
-}
unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe)
{
+ struct mt2063_state *state = fe-tuner_priv;
struct dvb_frontend_ops *frontend_ops = fe-ops;
struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
- struct tuner_state t_state;
int err = 0;
if (fe-ops)
@@ -501,9 +478,8 @@ unsigned int tuner_MT2063_SoftwareShutdown(struct
dvb_frontend *fe)
if (frontend_ops-tuner_ops)
tuner_ops = frontend_ops-tuner_ops;
if (tuner_ops-set_state) {
- if ((err =
-tuner_ops-set_state(fe, DVBFE_TUNER_SOFTWARE_SHUTDOWN,
- t_state)) 0) {
+ err = MT2063_SoftwareShutdown(state, 1);
+ if (err 0) {
printk(%s: Invalid parameter\n, __func__);
return err;
}
@@ -514,9 +490,9 @@ unsigned int tuner_MT2063_SoftwareShutdown(struct
dvb_frontend *fe)
unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe)
{
+ struct mt2063_state *state = fe-tuner_priv;
struct dvb_frontend_ops *frontend_ops = fe-ops;
struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
- struct tuner_state t_state;
int err = 0;
if (fe-ops)
@@ -524,9 +500,8 @@ unsigned int tuner_MT2063_ClearPowerMaskBits(struct
dvb_frontend *fe)
if (frontend_ops-tuner_ops)
tuner_ops = frontend_ops-tuner_ops;
if (tuner_ops-set_state) {
- if ((err =
-tuner_ops-set_state(fe, DVBFE_TUNER_CLEAR_POWER_MASKBITS,
- t_state)) 0) {
+ err = MT2063_ClearPowerMaskBits(state, MT2063_ALL_SD);
+ if (err 0) {
printk(%s: Invalid parameter\n, __func__);
return err;
}
@@ -3771,14 +3746,6 @@ static int mt2063_set_state(struct dvb_frontend *fe,
case DVBFE_TUNER_REFCLOCK:
break;
- case DVBFE_TUNER_SOFTWARE_SHUTDOWN:
- status = MT2063_SoftwareShutdown(state, 1);
- break;
- case DVBFE_TUNER_CLEAR_POWER_MASKBITS:
- status =
- MT2063_ClearPowerMaskBits(state,
- MT2063_ALL_SD);
- break;
default:
break;
}
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/47] [media] mt2063: Rewrite read/write logic at the driver
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 262 ++
1 files changed, 73 insertions(+), 189 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 534e970..0ae6c15 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -1,4 +1,3 @@
-
#include linux/init.h
#include linux/kernel.h
#include linux/module.h
@@ -541,15 +540,15 @@ unsigned int tuner_MT2063_ClearPowerMaskBits(struct
dvb_frontend *fe)
return err;
}
-/*/
-
-//i2c operation
-static int mt2063_writeregs(struct mt2063_state *state, u8 reg1,
- u8 *data, int len)
+/*
+ * mt2063_write - Write data into the I2C bus
+ */
+static u32 mt2063_write(struct mt2063_state *state,
+ u8 reg, u8 *data, u32 len)
{
+ struct dvb_frontend *fe = state-frontend;
int ret;
- u8 buf[60]; /* = { reg1, data }; */
-
+ u8 buf[60];
struct i2c_msg msg = {
.addr = state-config-tuner_address,
.flags = 0,
@@ -557,11 +556,12 @@ static int mt2063_writeregs(struct mt2063_state *state,
u8 reg1,
.len = len + 1
};
- msg.buf[0] = reg1;
+ msg.buf[0] = reg;
memcpy(msg.buf + 1, data, len);
- //printk(mt2063_writeregs state-i2c=%p\n, state-i2c);
+ fe-ops.i2c_gate_ctrl(fe, 1);
ret = i2c_transfer(state-i2c, msg, 1);
+ fe-ops.i2c_gate_ctrl(fe, 0);
if (ret 0)
printk(mt2063_writeregs error ret=%d\n, ret);
@@ -569,156 +569,40 @@ static int mt2063_writeregs(struct mt2063_state *state,
u8 reg1,
return ret;
}
-static int mt2063_read_regs(struct mt2063_state *state, u8 reg1, u8 * b, u8
len)
-{
- int ret;
- u8 b0[] = { reg1 };
- struct i2c_msg msg[] = {
- {
-.addr = state-config-tuner_address,
-.flags = I2C_M_RD,
-.buf = b0,
-.len = 1}, {
-.addr = state-config-tuner_address,
-.flags = I2C_M_RD,
-.buf = b,
-.len = len}
- };
-
- //printk(mt2063_read_regs state-i2c=%p\n, state-i2c);
- ret = i2c_transfer(state-i2c, msg, 2);
- if (ret 0)
- printk(mt2063_readregs error ret=%d\n, ret);
-
- return ret;
-}
-
-//context of mt2063_userdef.c Henry ==
-//#
-//=
-/*
-**
-** Name: MT_WriteSub
-**
-** Description:Write values to device using a two-wire serial bus.
-**
-** Parameters: hUserData - User-specific I/O parameter that was
-** passed to tuner's Open function.
-** addr - device serial bus address (value passed
-** as parameter to MT_Open)
-** subAddress - serial bus sub-address (Register Address)
-** pData - pointer to the Data to be written to the
-** device
-** cnt- number of bytes/registers to be written
-**
-** Returns:status:
-** MT_OK- No errors
-** MT_COMM_ERR - Serial bus communications error
-** user-defined
-**
-** Notes: This is a callback function that is called from the
-** the tuning algorithm. You MUST provide code for this
-** function to write data using the tuner's 2-wire serial
-** bus.
-**
-** The hUserData parameter is a user-specific argument.
-** If additional arguments are needed for the user's
-** serial bus read/write functions, this argument can be
-** used to supply the necessary information.
-** The hUserData parameter is initialized in the tuner's Open
-** function.
-**
-** Revision History:
-**
-** SCR Date Author Description
-** -
-** N/A 03-25-2004DADOriginal
-**
-*/
-static u32 MT2063_WriteSub(struct mt2063_state *state,
- u8 subAddress, u8 *pData, u32 cnt)
-{
- u32 status = 0; /* Status to be returned*/
- struct dvb_frontend *fe = state-frontend;
-
- /*
-** ToDo: Add code here to implement a serial-bus write
-** operation to the MT tuner. If
[PATCH 19/47] [media] mt2063: Simplify some functions
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 150 +++---
1 files changed, 12 insertions(+), 138 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 0ae6c15..1011635 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -75,7 +75,6 @@ struct MT2063_ExclZone_t {
* Structure of data needed for Spur Avoidance
*/
struct MT2063_AvoidSpursData_t {
- u32 nAS_Algorithm;
u32 f_ref;
u32 f_in;
u32 f_LO1;
@@ -410,7 +409,6 @@ struct mt2063_state {
static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
u32 f_min, u32 f_max);
static u32 MT2063_ReInit(struct mt2063_state *state);
-static u32 MT2063_Close(struct mt2063_state *state);
static u32 MT2063_GetReg(struct mt2063_state *state, u8 reg, u8 * val);
static u32 MT2063_GetParam(struct mt2063_state *state, enum MT2063_Param
param, u32 * pValue);
static u32 MT2063_SetReg(struct mt2063_state *state, u8 reg, u8 val);
@@ -606,29 +604,9 @@ static u32 mt2063_read(struct mt2063_state *state,
return (status);
}
-/*
-**
-** Name: MT_Sleep
-**
-** Description:Delay execution for nMinDelayTime milliseconds
-**
-** Parameters: hUserData - User-specific I/O parameter that was
-** passed to tuner's Open function.
-** nMinDelayTime - Delay time in milliseconds
-**
-** Returns:None.
-**
-** Notes: This is a callback function that is called from the
-** the tuning algorithm. You MUST provide code that
-** blocks execution for the specified period of time.
-**
-** Revision History:
-**
-** SCR Date Author Description
-** -
-** N/A 03-25-2004DADOriginal
-**
-*/
+/*
+ * FIXME: Is this really needed?
+ */
static int MT2063_Sleep(struct dvb_frontend *fe)
{
/*
@@ -640,78 +618,19 @@ static int MT2063_Sleep(struct dvb_frontend *fe)
return 0;
}
-//end of mt2063_userdef.c
-//=
-//#
-//=
-
-//context of mt2063_spuravoid.c Henry ==
-//#
-//=
-
-/*
-**
-** Name: mt_spuravoid.c
-**
-** Description:Microtune spur avoidance software module.
-** Supports Microtune tuner drivers.
-**
-** CVS ID: $Id: mt_spuravoid.c,v 1.3 2008/06/26 15:39:52 software Exp
$
-** CVS Source: $Source:
/export/home/cvsroot/software/tuners/MT2063/mt_spuravoid.c,v $
-**
-** Revision History:
-**
-** SCR Date Author Description
-** -
-** 082 03-25-2005JWSOriginal multi-tuner support - requires
-** MT_CNT declarations
-** 096 04-06-2005DADVer 1.11: Fix divide by 0 error if maxH==0.
-** 094 04-06-2005JWSVer 1.11 Added uceil and ufloor to get rid
-** of compiler warnings
-** N/A 04-07-2005DADVer 1.13: Merged single- and multi-tuner spur
-** avoidance into a single module.
-** 103 01-31-2005DADVer 1.14: In MT_AddExclZone(), if the range
-** (f_min, f_max) 0, ignore the entry.
-** 115 03-23-2007DADFix declaration of spur due to truncation
-** errors.
-** 117 03-29-2007RSKVer 1.15: Re-wrote to match search order from
-** tuner DLL.
-** 137 06-18-2007DADVer 1.16: Fix possible divide-by-0 error for
-** multi-tuners that have
-** (delta IF1) (f_out-f_outbw/2).
-** 147 07-27-2007RSKVer 1.17: Corrected calculation (-) to (+)
-** Added logic to force f_Center within 1/2
f_Step.
-** 177 S 02-26-2008RSKVer 1.18: Corrected calculation using LO1
MAX/2
-** Type casts added to preserve correct sign.
-** N/A I 06-17-2008RSKVer 1.19: Refactoring avoidance of DECT
-** frequencies into MT_ResetExclZones().
-** N/A I 06-20-2008RSKVer 1.21: New VERSION number for ver checking.
-**
[PATCH] [media] Don't test for ops-info.type inside drivers
Now, ops-info.type is handled inside the dvb_frontend
core, only for DVBv3 calls, and according with the
delivery system. So, drivers should not care or use it,
otherwise, it may have issues with DVBv5 calls.
The drivers that were still using it were detected via
this small temporary hack:
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -29,13 +29,16 @@
#include linux/types.h
typedef enum fe_type {
+#if defined(__DVB_CORE__) || !defined (__KERNEL__)
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC
+#else
+FE_FOOO
+#endif
} fe_type_t;
-
typedef enum fe_caps {
FE_IS_STUPID= 0,
FE_CAN_INVERSION_AUTO = 0x1,
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tda827x.c |7 ++-
drivers/media/dvb/firewire/firedtv-fe.c |6 +-
drivers/staging/media/as102/as102_fe.c |1 -
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/common/tuners/tda827x.c
b/drivers/media/common/tuners/tda827x.c
index e180def..a0d1762 100644
--- a/drivers/media/common/tuners/tda827x.c
+++ b/drivers/media/common/tuners/tda827x.c
@@ -540,9 +540,14 @@ static int tda827xa_set_params(struct dvb_frontend *fe)
}
tuner_freq = c-frequency;
- if (fe-ops.info.type == FE_QAM) {
+ switch (c-delivery_system) {
+ case SYS_DVBC_ANNEX_A:
+ case SYS_DVBC_ANNEX_C:
dprintk(%s select tda827xa_dvbc\n, __func__);
frequency_map = tda827xa_dvbc;
+ break;
+ default:
+ break;
}
i = 0;
diff --git a/drivers/media/dvb/firewire/firedtv-fe.c
b/drivers/media/dvb/firewire/firedtv-fe.c
index 39f5caa..6fe9793 100644
--- a/drivers/media/dvb/firewire/firedtv-fe.c
+++ b/drivers/media/dvb/firewire/firedtv-fe.c
@@ -173,7 +173,6 @@ void fdtv_frontend_init(struct firedtv *fdtv, const char
*name)
switch (fdtv-type) {
case FIREDTV_DVB_S:
ops-delsys[0] = SYS_DVBS;
- fi-type= FE_QPSK;
fi-frequency_min = 95;
fi-frequency_max = 215;
@@ -193,8 +192,7 @@ void fdtv_frontend_init(struct firedtv *fdtv, const char
*name)
case FIREDTV_DVB_S2:
ops-delsys[0] = SYS_DVBS;
- ops-delsys[1] = SYS_DVBS;
- fi-type= FE_QPSK;
+ ops-delsys[1] = SYS_DVBS2;
fi-frequency_min = 95;
fi-frequency_max = 215;
@@ -215,7 +213,6 @@ void fdtv_frontend_init(struct firedtv *fdtv, const char
*name)
case FIREDTV_DVB_C:
ops-delsys[0] = SYS_DVBC_ANNEX_A;
- fi-type= FE_QAM;
fi-frequency_min = 4700;
fi-frequency_max = 86600;
@@ -234,7 +231,6 @@ void fdtv_frontend_init(struct firedtv *fdtv, const char
*name)
case FIREDTV_DVB_T:
ops-delsys[0] = SYS_DVBT;
- fi-type= FE_OFDM;
fi-frequency_min = 4900;
fi-frequency_max = 86100;
diff --git a/drivers/staging/media/as102/as102_fe.c
b/drivers/staging/media/as102/as102_fe.c
index 06bfe84..bdc5a38 100644
--- a/drivers/staging/media/as102/as102_fe.c
+++ b/drivers/staging/media/as102/as102_fe.c
@@ -282,7 +282,6 @@ static struct dvb_frontend_ops as102_fe_ops = {
.delsys = { SYS_DVBT },
.info = {
.name = Unknown AS102 device,
- .type = FE_OFDM,
.frequency_min = 17400,
.frequency_max = 86200,
.frequency_stepsize = 17,
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l2: v4l2-fh: v4l2_fh_is_singular should use list head to test
2012/1/4 Sakari Ailus sakari.ai...@iki.fi: Hi Scott, Thanks for the patch. On Wed, Dec 21, 2011 at 10:30:54AM -0500, Scott Jiang wrote: list_is_singular accepts a list head to test whether a list has just one entry. fh-list is the entry, fh-vdev-fh_list is the list head. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/media/video/v4l2-fh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c index 9e3fc04..8292c4a 100644 --- a/drivers/media/video/v4l2-fh.c +++ b/drivers/media/video/v4l2-fh.c @@ -113,7 +113,7 @@ int v4l2_fh_is_singular(struct v4l2_fh *fh) if (fh == NULL || fh-vdev == NULL) return 0; spin_lock_irqsave(fh-vdev-fh_lock, flags); - is_singular = list_is_singular(fh-list); + is_singular = list_is_singular(fh-vdev-fh_list); spin_unlock_irqrestore(fh-vdev-fh_lock, flags); return is_singular; } Is there an issue that this patch resolves, or am I missing something? As far as I can see, the list_is_singular() test returns the same result whether you are testing a list item which is part of the list, or its head in struct video_device. Yes, the result is the same. But I don't think it's a good example because it may abuse this api. Can anybody figure out what this api needs you to pass in? I confess I am not sure about that. Scott -- 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: subdev support for querying struct v4l2_input *
2012/1/5 Steven Toth st...@kernellabs.com: Hans, In the cx23885 driver as part of vidioc_enum_input call, I have a need to return V4L2_IN_ST_NO_SIGNAL in the status field as part of struct v4l2_input. Thus, when no signal is detected by the video decoder it can be signalled to the calling application. v4l2_subdev_video_ops-g_input_status Scott -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: updated DVB-T frequencies for Italy
-- Forwarded Message -- Subject: updated DVB-T frequencies for Italy Date: Sun, 13 Feb 2011, 07:26:43 From: Marco d'Itri m...@linux.it To: Debian Bug Tracking System sub...@bugs.debian.org CC: debian-ital...@lists.debian.org Package: dvb-apps Version: 1.1.1+rev1355-1 Severity: normal Tags: patch In Italy there are way too many broadcasting sites, even more than one covering the same city, so it not really practical to ship a frequencies file for each one. Also, frequencies are still changing due to the progressing switchover. The attached file lists all frequencies used in Italy with reasonable modulation parameters and allows performing a complete frequencies scan no matter where the user is located. I recommend removing the other italian files since (at least) many of them are out of date (they list pre-switchover frequencies) and are redundant anyway. -- ciao, Marco - # This file lists all frequencies used in Western Europe for DVB-T. # The transmission parameters listed here are the ones generally used in # Italy, broadcast neworks in other countries do use different parameters. # Moreover, other countries use a bandwidth of 8 MHz also for Band III # channels. # # Compiled in December 2010 by Marco d'Itri m...@linux.it. # # References: # http://en.wikipedia.org/wiki/Band_I#Europe # http://en.wikipedia.org/wiki/Band_III#Europe # http://en.wikipedia.org/wiki/File:VHF_Usage.svg # http://en.wikipedia.org/wiki/Television_channel_frequencies # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy ### VHF - Band III ### # 5 T 17750 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 6 T 18450 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 7 T 19150 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 8 T 19850 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 9 T 20550 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 10 T 21250 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 11 T 21950 7MHz 2/3 NONE QAM64 8k 1/32 NONE # 12 T 22650 7MHz 2/3 NONE QAM64 8k 1/32 NONE ### UHF - Band IV ### # 21 T 47400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 22 T 48200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 23 T 49000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 24 T 49800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 25 T 50600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 26 T 51400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 27 T 52200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 28 T 53000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 29 T 53800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 30 T 54600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 31 T 55400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 32 T 56200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 33 T 57000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 34 T 57800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 35 T 58600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 36 T 59400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 37 T 60200 8MHz 2/3 NONE QAM64 8k 1/32 NONE ### UHF - Band V ### # 38 T 61000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 39 T 61800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 40 T 62600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 41 T 63400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 42 T 64300 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 43 T 65000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 44 T 65800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 45 T 66600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 46 T 67400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 47 T 68200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 48 T 69000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 49 T 69800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 50 T 70600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 51 T 71400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 52 T 72200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 53 T 73000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 54 T 73800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 55 T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 56 T 75400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 57 T 76200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 58 T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 59 T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 60 T 78600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 61 T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 62 T 80200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 63 T 81000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 64 T 81800 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 65 T 82600 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 66 T 83400 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 67 T 84200 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 68 T 85000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # 69 T 85800 8MHz 2/3 NONE QAM64 8k 1/32 NONE signature.asc Description: This is a digitally signed message part.
[patch] [media] af9013: change to
This is just a cleanup, it doesn't change how the code works. These
are compound conditions and not bitwise operations so it should be
and not .
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index e6ba3e0..1413c51 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -120,8 +120,8 @@ static int af9013_wr_regs(struct af9013_state *priv, u16
reg, const u8 *val,
int ret, i;
u8 mbox = (0 7)|(0 6)|(1 1)|(1 0);
- if ((priv-config.ts_mode == AF9013_TS_USB)
- ((reg 0xff00) != 0xff00) ((reg 0xff00) != 0xae00)) {
+ if ((priv-config.ts_mode == AF9013_TS_USB)
+ ((reg 0xff00) != 0xff00) ((reg 0xff00) != 0xae00)) {
mbox |= ((len - 1) 2);
ret = af9013_wr_regs_i2c(priv, mbox, reg, val, len);
} else {
@@ -142,8 +142,8 @@ static int af9013_rd_regs(struct af9013_state *priv, u16
reg, u8 *val, int len)
int ret, i;
u8 mbox = (0 7)|(0 6)|(1 1)|(0 0);
- if ((priv-config.ts_mode == AF9013_TS_USB)
- ((reg 0xff00) != 0xff00) ((reg 0xff00) != 0xae00)) {
+ if ((priv-config.ts_mode == AF9013_TS_USB)
+ ((reg 0xff00) != 0xff00) ((reg 0xff00) != 0xae00)) {
mbox |= ((len - 1) 2);
ret = af9013_rd_regs_i2c(priv, mbox, reg, val, len);
} else {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [media] saa7134: use correct array offset
Smatch complains that i can be one passed the end of the array if we
don't hit the break statement. We should be using the audio here like
we do in the other places.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
Compile tested only. Please review carefully.
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index ec1df6f..b7a99be 100644
--- a/drivers/media/video/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -605,7 +605,7 @@ static int tvaudio_thread(void *data)
if (kthread_should_stop())
break;
if (UNSET == dev-thread.mode) {
- rx = tvaudio_getstereo(dev,tvaudio[i]);
+ rx = tvaudio_getstereo(dev, tvaudio[audio]);
mode = saa7134_tvaudio_rx2mode(rx);
} else {
mode = dev-thread.mode;
--
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 -next] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
If ctrls-count is too high the multiplication could overflow and
array_size would be lower than expected. Mauro and Hans Verkuil
suggested that we cap it at 1024. That comes from the maximum
number of controls with lots of room for expantion.
$ grep V4L2_CID include/linux/videodev2.h | wc -l
211
Cc: stable sta...@vger.kernel.org
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index d2f981a..4942f81 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1133,6 +1133,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
/* User-class control IDs defined by V4L2 */
+#define V4L2_CID_MAX_CTRLS 1024
#define V4L2_CID_BASE (V4L2_CTRL_CLASS_USER | 0x900)
#define V4L2_CID_USER_BASE V4L2_CID_BASE
/* IDs reserved for driver specific controls */
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..639abee 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2226,6 +2226,10 @@ static int check_array_args(unsigned int cmd, void
*parg, size_t *array_size,
struct v4l2_ext_controls *ctrls = parg;
if (ctrls-count != 0) {
+ if (ctrls-count V4L2_CID_MAX_CTRLS) {
+ ret = -EINVAL;
+ break;
+ }
*user_ptr = (void __user *)ctrls-controls;
*kernel_ptr = (void *)ctrls-controls;
*array_size = sizeof(struct v4l2_ext_control)
signature.asc
Description: Digital signature
[patch -longterm v2] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
If p-count is too high the multiplication could overflow and
array_size would be lower than expected. Mauro and Hans Verkuil
suggested that we cap it at 1024. That comes from the maximum
number of controls with lots of room for expantion.
$ grep V4L2_CID include/linux/videodev2.h | wc -l
211
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index b59e78c..9e2088c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -858,6 +858,7 @@ struct v4l2_querymenu {
#define V4L2_CTRL_FLAG_NEXT_CTRL 0x8000
/* User-class control IDs defined by V4L2 */
+#define V4L2_CID_MAX_CTRLS 1024
#define V4L2_CID_BASE (V4L2_CTRL_CLASS_USER | 0x900)
#define V4L2_CID_USER_BASE V4L2_CID_BASE
/* IDs reserved for driver specific controls */
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 265bfb5..d7332c7 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -414,6 +414,9 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count V4L2_CID_MAX_CTRLS)
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
@@ -1912,6 +1915,9 @@ long video_ioctl2(struct file *file,
p-error_idx = p-count;
user_ptr = (void __user *)p-controls;
if (p-count) {
+ err = -EINVAL;
+ if (p-count V4L2_CID_MAX_CTRLS)
+ goto out_ext_ctrl;
ctrls_size = sizeof(struct v4l2_ext_control) * p-count;
/* Note: v4l2_ext_controls fits in sbuf[] so mbuf is
still NULL. */
mbuf = kmalloc(ctrls_size, GFP_KERNEL);
signature.asc
Description: Digital signature
Re: [PATCH] v4l2: v4l2-fh: v4l2_fh_is_singular should use list head to test
On Thu, Jan 05, 2012 at 10:52:02AM +0800, Scott Jiang wrote: 2012/1/4 Sakari Ailus sakari.ai...@iki.fi: Hi Scott, Thanks for the patch. On Wed, Dec 21, 2011 at 10:30:54AM -0500, Scott Jiang wrote: list_is_singular accepts a list head to test whether a list has just one entry. fh-list is the entry, fh-vdev-fh_list is the list head. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/media/video/v4l2-fh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c index 9e3fc04..8292c4a 100644 --- a/drivers/media/video/v4l2-fh.c +++ b/drivers/media/video/v4l2-fh.c @@ -113,7 +113,7 @@ int v4l2_fh_is_singular(struct v4l2_fh *fh) if (fh == NULL || fh-vdev == NULL) return 0; spin_lock_irqsave(fh-vdev-fh_lock, flags); - is_singular = list_is_singular(fh-list); + is_singular = list_is_singular(fh-vdev-fh_list); spin_unlock_irqrestore(fh-vdev-fh_lock, flags); return is_singular; } Is there an issue that this patch resolves, or am I missing something? As far as I can see, the list_is_singular() test returns the same result whether you are testing a list item which is part of the list, or its head in struct video_device. Yes, the result is the same. But I don't think it's a good example because it may abuse this api. Can anybody figure out what this api needs you to pass in? I confess I am not sure about that. That's true; it's more correct (and intuitive as well) to use the real list head for the purpose. But if the implementation really changed I bet a huge number of other things would break as well. Acked-by: Sakari Ailus sakari.ai...@iki.fi Hans: you wrote the patch adding this code (dfddb244); what do you think? Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 7/8] media: video: introduce object detection driver module
Hi Sylwester, Thanks for your review. On Fri, Dec 30, 2011 at 1:16 AM, Sylwester Nawrocki snj...@gmail.com wrote: Hi Ming, On 12/14/2011 03:00 PM, Ming Lei wrote: This patch introduces object detection generic driver. The driver is responsible for all v4l2 stuff, buffer management and other general things, and doesn't touch object detection hardware directly. Several interfaces are exported to low level drivers (such as the coming omap4 FD driver) which will communicate with object detection hw module. So the driver will make driving object detection hw modules more easy. TODO: - implement object detection setting interfaces with v4l2 controls or ext controls Signed-off-by: Ming Lei ming@canonical.com --- v2: - extend face detection driver to object detection driver - introduce subdevice and media entity - provide support to detect object from media HW --- drivers/media/video/Kconfig | 2 + drivers/media/video/Makefile | 1 + drivers/media/video/odif/Kconfig | 7 + drivers/media/video/odif/Makefile | 1 + drivers/media/video/odif/odif.c | 890 + drivers/media/video/odif/odif.h | 157 +++ 6 files changed, 1058 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/odif/Kconfig create mode 100644 drivers/media/video/odif/Makefile create mode 100644 drivers/media/video/odif/odif.c create mode 100644 drivers/media/video/odif/odif.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 5684a00..8740ee9 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1166,3 +1166,5 @@ config VIDEO_SAMSUNG_S5P_MFC MFC 5.1 driver for V4L2. endif # V4L_MEM2MEM_DRIVERS + +source drivers/media/video/odif/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index bc797f2..259c8d8 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -197,6 +197,7 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ +obj-$(CONFIG_ODIF) += odif/ ccflags-y += -Idrivers/media/dvb/dvb-core ccflags-y += -Idrivers/media/dvb/frontends diff --git a/drivers/media/video/odif/Kconfig b/drivers/media/video/odif/Kconfig new file mode 100644 index 000..5090bd6 --- /dev/null +++ b/drivers/media/video/odif/Kconfig @@ -0,0 +1,7 @@ +config ODIF + depends on VIDEO_DEV VIDEO_V4L2 + select VIDEOBUF2_PAGE + tristate Object Detection module + help + The ODIF is a object detection module, which can be integrated into + some SoCs to detect objects in images or video. diff --git a/drivers/media/video/odif/Makefile b/drivers/media/video/odif/Makefile new file mode 100644 index 000..a55ff66 --- /dev/null +++ b/drivers/media/video/odif/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_ODIF) += odif.o diff --git a/drivers/media/video/odif/odif.c b/drivers/media/video/odif/odif.c new file mode 100644 index 000..381ab9d --- /dev/null +++ b/drivers/media/video/odif/odif.c @@ -0,0 +1,890 @@ +/* + * odif.c -- object detection module driver + * + * Copyright (C) 2011 Ming Lei (ming@canonical.com) + * + * This file is based on drivers/media/video/vivi.c. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +/*/ + +#include linux/module.h +#include linux/fs.h +#include linux/mm.h +#include linux/signal.h +#include linux/wait.h +#include linux/poll.h +#include linux/mman.h +#include linux/pm_runtime.h +#include linux/delay.h +#include linux/platform_device.h +#include linux/interrupt.h +#include asm/uaccess.h +#include asm/byteorder.h +#include asm/io.h +#include odif.h + +#define input_from_user(dev) \ + (dev-input == OD_INPUT_FROM_USER_SPACE) + +#define DEFAULT_PENDING_RESULT_CNT 8 + +static unsigned debug = 0; +module_param(debug, uint, 0644); +MODULE_PARM_DESC(debug, activates debug info); + +static unsigned result_cnt_threshold = DEFAULT_PENDING_RESULT_CNT;
Re: v4l: how to get blanking clock count?
Hi Scott, On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote: I the case of your bridge, that may not be possible, but that's the only one I've heard of so I think it's definitely a special case. In that case the sensor driver can't be allowed to change the blanking periods while streaming is ongoing. I agree, it's just a matter of adding proper logic at the sensor driver. However it might be a bit tricky, the bridge would have to validate blanking values before actually enabling streaming. Yes, this value doesn't affect the result image. The hardware only raises a error interrupt to signify that a horizontal tracking overflow has occurred, that means the programmed number of samples did not match up with the actual number of samples counted between assertions of HSYNC(I can only set active samples now). Is there no way to disable this tracking, and just rely on hsync as everyone else does? Sounds like the hardware tries to do something it shouldn't... -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
[ANN] IRC meeting on new sensor control interface, 2012-01-09 14:00 GMT+2
Hi all, I'd like to announce that we'll have an IRC meeting on #v4l-meeting channel on the new sensor control interface. The date is next Monday 2012-01-09 14:00 GMT + 2. Most important background information is this; it discusses how image sensors should be controlled: URL:http://www.spinics.net/lists/linux-media/msg40861.html These changes currently depend on - Integer menu controls [1], - Selection IOCTL for subdevs [2] and - validate_pipeline() V4L2 subdev pad op. The full patchset, with all the latest patches for the above, is available here. What also is there, is the SMIA++ driver which uses these interfaces. It can be used on the Nokia N9. URL:http://www.spinics.net/lists/linux-media/msg41765.html Questions and comments are always very, very welcome by e-mail as usual. The purpose of the meeting is to have a possibility for real-time discussion on the topic. [1] http://www.spinics.net/lists/linux-media/msg40796.html [2] http://www.spinics.net/lists/linux-media/msg41503.html Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: v4l: how to get blanking clock count?
2012/1/4 Sakari Ailus sakari.ai...@iki.fi: Hi Scott, On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote: I the case of your bridge, that may not be possible, but that's the only one I've heard of so I think it's definitely a special case. In that case the sensor driver can't be allowed to change the blanking periods while streaming is ongoing. I agree, it's just a matter of adding proper logic at the sensor driver. However it might be a bit tricky, the bridge would have to validate blanking values before actually enabling streaming. Yes, this value doesn't affect the result image. The hardware only raises a error interrupt to signify that a horizontal tracking overflow has occurred, that means the programmed number of samples did not match up with the actual number of samples counted between assertions of HSYNC(I can only set active samples now). Is there no way to disable this tracking, and just rely on hsync as everyone else does? Sounds like the hardware tries to do something it shouldn't... If I disable this interrupt, other errors like fifo underflow are ignored. Perhaps I can add a parameter in platform data to let user decide to register this interrupt or not. Scott -- 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: v4l: how to get blanking clock count?
On Wed, Jan 04, 2012 at 05:10:40PM +0800, Scott Jiang wrote: 2012/1/4 Sakari Ailus sakari.ai...@iki.fi: Hi Scott, On Wed, Jan 04, 2012 at 01:50:17PM +0800, Scott Jiang wrote: I the case of your bridge, that may not be possible, but that's the only one I've heard of so I think it's definitely a special case. In that case the sensor driver can't be allowed to change the blanking periods while streaming is ongoing. I agree, it's just a matter of adding proper logic at the sensor driver. However it might be a bit tricky, the bridge would have to validate blanking values before actually enabling streaming. Yes, this value doesn't affect the result image. The hardware only raises a error interrupt to signify that a horizontal tracking overflow has occurred, that means the programmed number of samples did not match up with the actual number of samples counted between assertions of HSYNC(I can only set active samples now). Is there no way to disable this tracking, and just rely on hsync as everyone else does? Sounds like the hardware tries to do something it shouldn't... If I disable this interrupt, other errors like fifo underflow are ignored. Perhaps I can add a parameter in platform data to let user decide to register this interrupt or not. I think a more generic solution would be preferrable. If that causes ignoring real errors, that's of course bad. I wonder if there would be a way around that. Is there a publicly available datasheet for the bridge that I could take a look at? -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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: More adapters on v4l
2012/1/3 Gianluca Gennari gennar...@gmail.com: Il 03/01/2012 17:09, Josu Lazkano ha scritto: Hello, I am trying to compile the v4l drivers, I make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb git clone git://linuxtv.org/media_build.git cd media_build ./build I got this message on the end: ** * Compilation finished. Use 'make install' to install them ** But before the make I want to add more adapters changing the v4l/scripts/make_kconfig.pl file to this: .config:CONFIG_DVB_MAX_ADAPTERS=16 When I execute the ./build it compile and I can not change the source. On the s2-liplianin branch I had no problem because I change it before the make this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://mercurial.intuxication.org/hg/s2-liplianin/archive/tip.zip unzip s2-liplianin-0b7d3cc65161.zip cd s2-liplianin-0b7d3cc65161 ##change the adapter number### make make install Is possible to do the same with the v4l source? Thanks and best regards. Hi Josu, you can do this way: git clone git://linuxtv.org/media_build.git cd media_build ./build ## you can ctrl-C as soon as it starts compiling the drivers, or wait until the end ## make menuconfig ## change all the options you like and save ## cd linux make cd .. make install Best regards, Gianluca Gennari Thanks! I comment the make line on the build script. Best regards. -- Josu Lazkano -- 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: v4l: how to get blanking clock count?
If I disable this interrupt, other errors like fifo underflow are ignored. Perhaps I can add a parameter in platform data to let user decide to register this interrupt or not. I think a more generic solution would be preferrable. If that causes ignoring real errors, that's of course bad. I wonder if there would be a way around that. Is there a publicly available datasheet for the bridge that I could take a look at? Yes, http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html. There is a hardware reference manual for bf54x, bridge is eppi. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Resolution change support in video codecs in v4l2
Hi Sakari, From: 'Sakari Ailus' [mailto:sakari.ai...@iki.fi] Sent: 01 January 2012 23:29 decs in v4l2 Hi Kamil, Apologies for my later reply. On Mon, Dec 12, 2011 at 11:17:06AM +0100, Kamil Debski wrote: -Original Message- From: 'Sakari Ailus' [mailto:sakari.ai...@iki.fi] Sent: 09 December 2011 20:55 To: Kamil Debski Cc: 'Mauro Carvalho Chehab'; linux-media@vger.kernel.org; 'Laurent Pinchart'; 'Sebastian Dröge'; Sylwester Nawrocki; Marek Szyprowski Subject: Re: [RFC] Resolution change support in video codecs in v4l2 Hi Kamil, On Tue, Dec 06, 2011 at 04:03:33PM +0100, Kamil Debski wrote: ... The user space still wants to be able to show these buffers, so a new flag would likely be required --- V4L2_BUF_FLAG_READ_ONLY, for example. Huh? Assuming a capture device, when kernel makes a buffer available to userspace, kernel should not touch on it anymore (not even for read - although reading from it probably won't cause any issues, as video applications in general don't write into those buffers). The opposite is true for output devices: once userspace fills it, and queues, it should not touch that buffer again. This is part of the queue/dequeue logic. I can't see any need for an extra flag to explicitly say that. There is a reason to do so. An example of this is below. The memory-to-memory device has two queues, output can capture. A video decoder memory-to-memory device's output queue handles compressed video and the capture queue provides the application decoded frames. Certain frames in the stream are key frames, meaning that the decoding of the following non-key frames requires access to the key frame. The number of non-key frame can be relatively large, say 16, depending on the codec. If the user should wait for all the frames to be decoded before the key frame can be shown, then either the key frame is to be skipped or delayed. Both of the options are highly undesirable. I don't think that such a delay is worrisome. This is only initial delay. The hw will process these N buffers and after that it works exactly the same as it would without the delay in terms of processing time. Well, yes, but consider that the decoder also processes key frames when the decoding is in progress. The dequeueing of the key frames (and any further frames as long as the key frame is needed by the decoder) will be delayed until the key frame is no longer required. You need extra buffers to cope with such a situation, and in the worst case, or when the decoder is just as fast as you want to show the frames on the display, you need double the amount of buffers compared to what you'd really need for decoding. To make matters worse, this tends to happen at largest resolutions. I think we'd like to avoid this. I really, really, dont see why you say that we would need double the number of buffers? Let's suppose that the stream may reference 2 previous frames. Frame number: 123456789ABCDEF Returned frame: 123456789ABCDEF Buffers returned: 123123123123... (in case we have only 3 buffers) See? After we decode frame number 3 we can return frame number 3. Thus we need minimum of 3 buffers. If we want to have 4 for simultaneous the use of application we allocate 7. The current codec handling system has been build on the following assumptions: - the buffers should be dequeued in order - the buffers should be only dequeued when they are no longer is use What does in use mean to you? Both read and write, or just read? In use means both read and write in this context. Assume frame 1 is required to decode frames 2 and 3. If we delay dequeueing of te first of the above three frames since the codec accesses it for reading, we will also delay dequeueing of any subsequent frames until the first frame is decoded. If this is repeated, and assuming the speed of the decoder is the same as playback of those frames, the player will require a minimum of six frames to cope with the uneven time interval the decoder will be able to give those frames to the player. Otherwise, only three frames would be enough. Why six frames? Why the uneven time interval the decoder will be able to give those frames to the player? If you look again here Frame number: 123456789ABCDEF Returned frame: 123456789ABCDEF Buffers returned: 123123123123... (in case we have only 3 buffers) You can see that with 3 buffers you get a constant delay of 2 frames. In most cases (and I am just dropping the cases when you feed the coded with compressed slices and not whole frames) you queue one source stream frame and you get one decoded frame. Simple as that. This takes care of the delay related
Re: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver
Hello. On 04-01-2012 11:17, Manjunath Hadli wrote: remove unnecessary inclusion of machine specific header files mach/dm646x.h, mach/hardware.h from vpif.h and aslo mach/dm646x.h from vpif_display.c driver which comes in the way of platform code consolidation. Add linux/i2c.h header file in vpif_types.h which is required for building. This last modification should be in a separate patch. Don;t mix changes having the different purpose. Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Cc: Mauro Carvalho Chehabmche...@infradead.org Cc: LMMLlinux-media@vger.kernel.org WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sylwester, On Sun, Jan 01, 2012 at 05:49:11PM +0100, Sylwester Nawrocki wrote: On 12/31/2011 01:00 PM, Sakari Ailus wrote: Hi Sylwester, Apologies for my late answer. No problem, thanks for your comments! On Sat, Dec 10, 2011 at 03:42:41PM +0100, Sylwester Nawrocki wrote: Hi Sakari, On 12/10/2011 11:33 AM, Sakari Ailus wrote: On Sun, Dec 04, 2011 at 04:16:12PM +0100, Sylwester Nawrocki wrote: Change the V4L2_CID_FOCUS_AUTO control type from boolean to a menu type. In case of boolean control we had values 0 and 1 corresponding to manual and automatic focus respectively. The V4L2_CID_FOCUS_AUTO menu control has currently following items: 0 - V4L2_FOCUS_MANUAL, 1 - V4L2_FOCUS_AUTO, 2 - V4L2_FOCUS_AUTO_MACRO, 3 - V4L2_FOCUS_AUTO_CONTINUOUS. I would put the macro mode to a separate menu since it's configuration for how the regular AF works rather than really different mode. Yes, makes sense. Most likely there could be also continuous macro auto focus.. I don't have yet an idea what could be a name for that new menu though. V4L2_CID_FOCUS_AUTO_DISTANCE? It could then have choices FULL or MACRO. How about V4L2_CID_FOCUS_AUTO_SCAN_RANGE ? Which would then have choices: NORMAL, MACRO, INFINITY ? What does INFINITY signify? That lens is permanently positioned there? The name of the control sounds good to me, but I might change the order of FOCUS and AUTO in it. Many Samsung devices have also something like guided auto focus, where the application can specify location in the frame for focusing on. IIRC this could be also single-shot or continuous. So it could make sense to group MACRO and guided auto focus in one menu, what do you think ? I think it could be a separate menu. It's not connected to the distance OK, let me summarize * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY New menu control to choose behaviour of auto focus (either single-shot or continuous): * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. interface which could be used to control it all. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg25647.html -- Regards, Sylwester -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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 -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
On Tue, Jan 03, 2012 at 12:55:39PM -0800, Greg KH wrote: Ok, can someone please send me the accepted version of this patch for inclusion in the 2.6.32-stable tree? Sorry for that. Holidays and all. I'll send a patch tomorrow. regards, dan carpenter signature.asc Description: Digital signature
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sylwester, On Mon, Jan 02, 2012 at 09:55:31PM +0100, Sylwester Nawrocki wrote: Hi Laurent, On 01/02/2012 12:16 PM, Laurent Pinchart wrote: * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be consistent with the other proposed controls ? Yes, you're right, I'll change them to make consistent with others. I've noticed that too, but a little bit too late:) * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY ... * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API Soudns good to me. parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. For the OMAP3 ISP we need multiple statistics windows. AEWB can use more than 32 windows. Having separate controls for that wouldn't be practical. OK, so the control API in current form doesn't seem capable of setting up the statistics windows. There is also little space in struct v4l2_ext_control for any major extensions. We might need to define dedicated set of selection targets in the selection API for handling multiple windows. Yet, to avoid forcing applications to use the selection API where rectangles aren't needed - only single spot coordinates, how about defining following two controls ? * AF spot coordinates when focus mode is set to V4L2_AUTO_FOCUS_MODE_SPOT - V4L2_CID_AUTO_FOCUS_POSITION_X - horizontal position in pixels relative to the left of frame - V4L2_CID_AUTO_FOCUS_POSITION_Y - vertical position in pixels relative to the top of frame What's a spot focus mode? Any AF statistics from a single pixel have no meaning, so there has to be more. It sounds like a small rectangle to me. :-) But being able to provide more windows would be rather important. You don't need to look at too special cameras before you can have seven or so focus windows. The selection API could be used for this, as proposed already. We could have a new V4L2_(SUBDEV_)SELECTION_STAT_AF target to configure windows. We could add an id field to define the window ID to struct v4l2_(subdev_)selection. One control would be required to tell how many statistics windows do you have. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
I2C and SPI subdevs unregistration
Hi Hans, Do you know why I2C and SPI devices are unregistered in v4l2_device_unregister() but not in v4l2_device_unregister_subdev() ? If I call the later manually before calling v4l2_device_unregister(), the I2C and SPI devices won't be unregistered. Is that expected ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 1/2] davinci: vpif: remove machine specific header file inclusion from the driver
Sergei, On Wed, Jan 04, 2012 at 18:29:13, Sergei Shtylyov wrote: Hello. On 04-01-2012 11:17, Manjunath Hadli wrote: remove unnecessary inclusion of machine specific header files mach/dm646x.h, mach/hardware.h from vpif.h and aslo mach/dm646x.h from vpif_display.c driver which comes in the way of platform code consolidation. Add linux/i2c.h header file in vpif_types.h which is required for building. This last modification should be in a separate patch. Don;t mix changes having the different purpose. It is part of the same modification of removing the machine specific header. When the header file was removed, it needed the i2c to be included due to a dependency and hence the inclusion. Thx, -Manju Signed-off-by: Manjunath Hadlimanjunath.ha...@ti.com Cc: Mauro Carvalho Chehabmche...@infradead.org Cc: LMMLlinux-media@vger.kernel.org WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] v4l: Add V4L2_CID_FLASH_HW_STROBE_MODE control
Hi Sylwester, On Wed, Dec 28, 2011 at 05:06:55PM +0100, Sylwester Nawrocki wrote: On 12/14/2011 10:51 PM, Sakari Ailus wrote: On Sat, Dec 10, 2011 at 02:55:19PM +0100, Sylwester Nawrocki wrote: On 12/05/2011 11:41 PM, Sakari Ailus wrote: On Mon, Dec 05, 2011 at 08:56:46PM +0100, Sylwester Nawrocki wrote: The V4L2_CID_FLASH_HW_STROBE_MODE mode control is intended for devices that are source of an external flash strobe for flash devices. This part seems to be missing in current Flash control class, i.e. a means for configuring devices that are not camera flash drivers but involve a flash related functionality. The V4L2_CID_FLASH_HW_STROBE_MODE control enables the user to determine the flash control behavior, for instance, at an image sensor device. The control has effect only when V4L2_CID_FLASH_STROBE_SOURCE control is set to V4L2_FLASH_STROBE_SOURCE_EXTERNAL at a flash subdev, if a flash subdev is present in the system. Signed-off-by: Sylwester Nawrocki snj...@gmail.com --- Hi Sakari, My apologies for not bringing this earlier when you were designing the Flash control API. It seems like a use case were a sensor controller drives a strobe signal for a Flash and the sensor side requires some set up doesn't quite fit in the Flash Control API. Or is there already a control allowing to set Flash strobe mode at the sensor to: OFF, ON (per each exposed frame), AUTO ? Thank you for the in-depth opinion (and sorry for the delayed response). You're welcome! Thanks for bringing up the topic! :-) The flash API defines the API for the flash, not for the sensor which might be controlling the flash through the hardware strobe pin. I left that out deliberately before I could see what kind of controls would be needed for that. If I understand you correctly, this control is intended to configure the flash strobe per-frame? That may be somewhat hardware-dependent. Yes, per captured frame. Actually the controls I proposed were meant to select specific flash strobe algorithm. What refinements could be relevant for those algorithms may be a different question. Something like the proposed controls is really almost all that is offered by many of hardware we use. Some hardware is able to strobe the flash for the next possible frame or for the first frame when the streaming is started. In either of the cases, the frames before and after the one exposed with the flash typically are ruined because the flash has exposed only a part of them. You typically want to discard such frames. Is this the case for Xenon flash as well, or LED only ? Both xenon and LED. I think the fact that we're using video capture like interface for still capture adds complexity in such cases. It also adds flexibility. You can expose one frame with xenon flash w/o stopping streaming. Yes, but only if you're able to control an image sensor and ISP at very low level. For ISP I don't see it would matter, but for sensor, yes. In general most don't provide a way to expose frames in a stream with flash --- instead the stream has to be stopped first. I think this is what users would expect to do in regular cases. If flash exposure isn't possible while streaming, the sensor can always tell the strobe control is busy. Do you think that would work for you? flash: LED flash typically remains on for the whole duration of the frame exposure, whereas on xenon flash the full frame must be being exposed when the flash is being fired. Indeed, I should have separated the LED and Xenon case in the first place. Do you think we could start with separate menu controls for LED and Xenon flash strobe, e.g. V4L2_FLASH_LED_STROBE_MODE, V4L2_FLASH_XENON_STROBE_MODE and then think of what controls would be needed for each particular mode under these menus ? Do we need to separate them? I don't think they're very different, with the Perhaps we don't need to separate them this much. But the differences are significant IHMO. However it could be enough if we pass information about the flash type in sensor's platform data. (I wrote this before I've seen your smiapp driver patches;)). Yeah; that might make sense. Smart sensors might even require information on the flash type etc. to be able to control it properly. possible exception of intensity control. For xenon flashes the intensity is at least sometimes controlled by the strobe pulse length. Still, flash strobe start timing and length control are the same. But strobe control signal characteristics may be different for Xenon lamp, due to pre-flash strobes for example ? Does pre-flash really apply to LED flashes as well ? Yes; we do that on the Nokia N9 and, I think, on the N900 as well. I think that from the sensor's point of view the low level controls are still the same, as well as the high level ones. I have to admit I
[PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch
Mauro, I've been adding support to the CX23885 and CX25840 drivers for the Hauppauge HVR1850 card. These patches enable the use of raw video, audio and/or the mpeg encoder, via all video and audio inputs. Support for the HVR1850 is now in pretty good shape. The card uses the CX23888 PCIe bridge which brings its own complexities and additional code to the CX25840. I've tested these patches against the HVR1700, HVR1800 and HVR1850, everything appears to be working correctly. These also fix a small regression in the HVR1800 driver related to the work done during October 2010 on the subdev conversion. Given that nobody has noticed in the last 12 months it's not too important. Tree is at git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch. Patch series viewable at: http://git.kernellabs.com/?p=stoth/cx23885-hvr1850.git;a=shortlog;h=refs/heads/media-master [media] cx25840: Added g_std support to the video decoder driver [media] cx25840: Hauppauge HVR1850 Analog driver support (patch#4) [media] cx25840: Add a flag to enable the CX23888 DIF to be enabled or not. [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#3) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#2) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#1) [media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation [media] cx23885: Control cleanup on the MPEG Encoder [media] cx23885: Configure the MPEG encoder early to avoid jerky video [media] cx23885: Ensure the MPEG encoder height is configured from the norm [media] cx23885: Cleanup MPEG encoder GPIO handling [media] cx25840 / cx23885: Fixing audio/volume regression b/drivers/media/video/cx23885/cx23885-417.c |4 b/drivers/media/video/cx23885/cx23885-cards.c | 28 b/drivers/media/video/cx23885/cx23885-core.c | 24 b/drivers/media/video/cx23885/cx23885-dvb.c | 14 b/drivers/media/video/cx23885/cx23885-video.c | 153 + b/drivers/media/video/cx23885/cx23885.h | 12 b/drivers/media/video/cx25840/cx25840-audio.c | 10 b/drivers/media/video/cx25840/cx25840-core.c | 36 b/include/media/cx25840.h |1 drivers/media/video/cx23885/cx23885-417.c | 137 - drivers/media/video/cx23885/cx23885-video.c | 10 drivers/media/video/cx25840/cx25840-core.c| 3188 +- 12 files changed, 3487 insertions(+), 130 deletions(-) Thanks, -- Steven Toth - 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
[PATCH 1/2 v3] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v2:
- Do not grab mm-mmap_sem.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 71 +--
1 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..e621db6 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/io.h
#include linux/module.h
#include linux/mm.h
#include linux/sched.h
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,37 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ if (vb2_get_contig_userptr(vaddr, size, res_vma, physp))
+ goto fail_pages_array_alloc;
+ buf-vma = res_vma;
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+vaddr PAGE_MASK, buf-n_pages,
+write, 1, /* force */
+buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +139,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
+ iounmap(buf-vaddr);
}
- kfree(buf-pages);
kfree(buf);
}
--
1.7.0.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
Re: [PATCH] v4l2: v4l2-fh: v4l2_fh_is_singular should use list head to test
Hi Scott, Thanks for the patch. On Wed, Dec 21, 2011 at 10:30:54AM -0500, Scott Jiang wrote: list_is_singular accepts a list head to test whether a list has just one entry. fh-list is the entry, fh-vdev-fh_list is the list head. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/media/video/v4l2-fh.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c index 9e3fc04..8292c4a 100644 --- a/drivers/media/video/v4l2-fh.c +++ b/drivers/media/video/v4l2-fh.c @@ -113,7 +113,7 @@ int v4l2_fh_is_singular(struct v4l2_fh *fh) if (fh == NULL || fh-vdev == NULL) return 0; spin_lock_irqsave(fh-vdev-fh_lock, flags); - is_singular = list_is_singular(fh-list); + is_singular = list_is_singular(fh-vdev-fh_list); spin_unlock_irqrestore(fh-vdev-fh_lock, flags); return is_singular; } Is there an issue that this patch resolves, or am I missing something? As far as I can see, the list_is_singular() test returns the same result whether you are testing a list item which is part of the list, or its head in struct video_device. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] media: vb2: support userptr for PFN mappings.
Hi Javier,
Thanks for the patch.
On Wednesday 04 January 2012 16:46:51 Javier Martin wrote:
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v2:
- Do not grab mm-mmap_sem.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 71
+-- 1 files changed, 48 insertions(+), 23
deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c index 03aa62f..e621db6 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/io.h
#include linux/module.h
#include linux/mm.h
#include linux/sched.h
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,37 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ if (vb2_get_contig_userptr(vaddr, size, res_vma, physp))
One small comment here. You don't use the vma variable from this point on, so
maybe you could remove res_vma and use vma instead.
+ goto fail_pages_array_alloc;
+ buf-vma = res_vma;
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+ GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+ vaddr PAGE_MASK, buf-n_pages,
+ write, 1, /* force */
+ buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +139,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
+ iounmap(buf-vaddr);
}
- kfree(buf-pages);
kfree(buf);
}
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
Hi Guennadi.
Thanks for your help.
On 3 January 2012 16:05, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Hi Javier
On Tue, 3 Jan 2012, javier Martin wrote:
Guennadi,
probably you could answer me some question:
as we agreed I'm trying to implement ENUM_INPUT support to soc-camera
through pads.
No, you probably mean in the subdev driver, not in soc-camera core.
This means I must be able to pass the tvp5150 decoder
some platform_data in order to configure what inputs are really routed
in my board.
For that purpose I do the following in my board specific code:
static struct tvp5150_platform_data visstrim_tvp5150_data = {
.inputs = 55,
};
static struct i2c_board_info visstrim_i2c_camera = {
.type = tvp5150,
.addr = 0x5d,
.platform_data = visstrim_tvp5150_data,
};
static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0, /* Must match with the camera ID */
.board_info = visstrim_i2c_camera,
.i2c_adapter_id = 0,
.power = visstrim_camera_power,
.reset = visstrim_camera_reset,
};
static struct platform_device visstrim_tvp5150_soc = {
.name = soc-camera-pdrv,
.id = 0,
.dev = {
.platform_data = iclink_tvp5150,
},
};
However, it seems soc-camera ignores board_info.platform_data field
and assigns a value of its own:
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/soc_camera.c#L1006
How am I suppose to pass that information to the tvp5150 then?
Have a look at some examples, e.g., arch/sh/boards/mach-migor/setup.c:
static struct soc_camera_link ov7725_link = {
.power = ov7725_power,
.board_info = migor_i2c_camera[0],
.i2c_adapter_id = 0,
.priv = ov7725_info,
};
I.e., soc-camera expects you to use the struct soc_camera_link::priv field
for subdevice private platform data.
For ov7725 it is a natural thing to do since it was originally
developed for soc-camera and it can easily do the following to access
platform data:
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
pdata = icl-priv;
However, tvp5150 is not aware about soc_camera. I should be able to
tell whether it's being used with soc-camera or not. If soc camera was
used I would do the previous method to retrieve platform data.
But if soc-camera was not used I would do the classic method:
struct tvp5150_platform_data *pdata = client-dev.platform_data;
The problem is how to distinguish in tvp5150 whether I am using
soc_camera or not.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: RFC: dvbzap application based on DVBv5 API
Hi Akihiro, On 30-12-2011 04:46, Akihiro TSUKADA wrote: [channel name] property = value ... property = value Currently, at least gstreamer's dvbbasebin and mplayer assumue that the channel configuration file has the format of one line per channel. So when I personally patched them to use v5 parameters, I chose the one-line-per-channel format of channel name:propname=val|...|propname=val:service id, for example, NHKBS1:DTV_DELIVERY_SYSTEM=SYS_ISDBS|DTV_VOLTAGE=1|DTV_FREQUENCY=1318000|DTV_ISDBS_TS_ID=0x40f2:103 , to minimize modification (hopefully). I understand that it is not that difficult nor complicated to adapt applications to use the ini file style format, but the old one line style format seems slightly easier. It is not that harder to parse a multiple lines file, but using something like above makes harder for humans to read. Also, the format I've proposed is already handled by several existing tools. So, there are several parsers for it already written. and I wish that the channel configuration can allow nicknames/aliases, as the canonical channel name can be long to type in or difficult to remember correctly. If I remember right, MythTV has its own database, and it would be convenient if we could share the database, because applications currently have their own channel configuration separately, and the configuration change like new service or parameter changes must be propagated manually. Yes, this is an interesting feature. Some carriers broadcast nicks/aliases via the emphasis encoding. It shouldn't be hard to add support for it. Btw, I finished writing a dvbv5-scan application. It reads (currently) the legacy channels/transponders format found on dvb-apps, and outputs channel scans on the new format. I decided to write the scan tool from scratch, instead of importing the code from w_scan or dvb-apps/scan, as it allowed me to avoid importing DVBv3 legacy stuff on it, and to separate the scan code into a few function calls. Due to that, only a subset of the features found on the other scan tools are there (the ones that are needed for ISDB-T - and - likely DVB-T). I'm currently without DVB-C signal, but, as soon as I return back to my hometown, I'll add the missing bits for it. I also wrote a small utility to convert from the legacy zap and channels.conf formats into the new one. It is at: http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils Of course, patches, help, etc are welcome! Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v4] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v3:
- Remove vma_res variable.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 70 +--
1 files changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..f9ff15f 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include linux/io.h
#include linux/module.h
#include linux/mm.h
#include linux/sched.h
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +84,37 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_PFNMAP) (vma-vm_pgoff)) {
+ if (vb2_get_contig_userptr(vaddr, size, vma, physp))
+ goto fail_pages_array_alloc;
+ buf-vma = vma;
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+vaddr PAGE_MASK, buf-n_pages,
+write, 1, /* force */
+buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +138,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+ if (buf-vma)
+ vb2_put_vma(buf-vma);
+ iounmap(buf-vaddr);
}
- kfree(buf-pages);
kfree(buf);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l: how to get blanking clock count?
On Wed, Jan 04, 2012 at 05:59:45PM +0800, Scott Jiang wrote: If I disable this interrupt, other errors like fifo underflow are ignored. Perhaps I can add a parameter in platform data to let user decide to register this interrupt or not. I think a more generic solution would be preferrable. If that causes ignoring real errors, that's of course bad. I wonder if there would be a way around that. Is there a publicly available datasheet for the bridge that I could take a look at? Yes, http://www.analog.com/en/processors-dsp/blackfin/adsp-bf548/processors/technical-documentation/index.html. There is a hardware reference manual for bf54x, bridge is eppi. It's really an interesting design choice --- it also likely makes detecting all too common errors easier. But it also makes it impossible to dynamically change blanking periods... Well, I think the solution could be that the host would set these sensor controls read-only (or just make them return -EBUSY when written to); this isn't yet supported in the control framework. Also the idea is rather new, but I think it would have many more uses than this. Hans? -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On Wed, 4 Jan 2012, javier Martin wrote: [snip] For ov7725 it is a natural thing to do since it was originally developed for soc-camera and it can easily do the following to access platform data: struct soc_camera_link*icl = soc_camera_i2c_to_link(client); pdata = icl-priv; However, tvp5150 is not aware about soc_camera. I should be able to tell whether it's being used with soc-camera or not. If soc camera was used I would do the previous method to retrieve platform data. But if soc-camera was not used I would do the classic method: struct tvp5150_platform_data *pdata = client-dev.platform_data; The problem is how to distinguish in tvp5150 whether I am using soc_camera or not. Right, that _is_ the problem now. And we've known about it since the very first time we started to think about re-using the subdev drivers. The only solution I see so far is to introduce a standard platform data struct for all subdevices, similar to soc_camera_link. We could use it as a basis, of course, use a generic name, maybe reconsider fields - rename / remove / add, but the principle would be the same: a standard platform data struct with an optional private field. Alternatively - would it be possible to find all tvp5150 users and port them to use struct soc_camera_link too? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
Hi Guennadi, On Wednesday 04 January 2012 17:35:27 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, javier Martin wrote: [snip] For ov7725 it is a natural thing to do since it was originally developed for soc-camera and it can easily do the following to access platform data: struct soc_camera_link *icl = soc_camera_i2c_to_link(client); pdata = icl-priv; However, tvp5150 is not aware about soc_camera. I should be able to tell whether it's being used with soc-camera or not. If soc camera was used I would do the previous method to retrieve platform data. But if soc-camera was not used I would do the classic method: struct tvp5150_platform_data *pdata = client-dev.platform_data; The problem is how to distinguish in tvp5150 whether I am using soc_camera or not. Right, that _is_ the problem now. And we've known about it since the very first time we started to think about re-using the subdev drivers. The only solution I see so far is to introduce a standard platform data struct for all subdevices, similar to soc_camera_link. We could use it as a basis, of course, use a generic name, maybe reconsider fields - rename / remove / add, but the principle would be the same: a standard platform data struct with an optional private field. Why is that needed ? Why can't a tvp5150-specific platform data structure do ? Alternatively - would it be possible to find all tvp5150 users and port them to use struct soc_camera_link too? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On Wed, 4 Jan 2012, Laurent Pinchart wrote: Hi Guennadi, On Wednesday 04 January 2012 17:35:27 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, javier Martin wrote: [snip] For ov7725 it is a natural thing to do since it was originally developed for soc-camera and it can easily do the following to access platform data: struct soc_camera_link*icl = soc_camera_i2c_to_link(client); pdata = icl-priv; However, tvp5150 is not aware about soc_camera. I should be able to tell whether it's being used with soc-camera or not. If soc camera was used I would do the previous method to retrieve platform data. But if soc-camera was not used I would do the classic method: struct tvp5150_platform_data *pdata = client-dev.platform_data; The problem is how to distinguish in tvp5150 whether I am using soc_camera or not. Right, that _is_ the problem now. And we've known about it since the very first time we started to think about re-using the subdev drivers. The only solution I see so far is to introduce a standard platform data struct for all subdevices, similar to soc_camera_link. We could use it as a basis, of course, use a generic name, maybe reconsider fields - rename / remove / add, but the principle would be the same: a standard platform data struct with an optional private field. Why is that needed ? Why can't a tvp5150-specific platform data structure do ? Javier has actually explained this already. Ok, again: he wants to use tvp5150 with an soc-camera host driver, i.e., with the soc-camera subsystem. And the soc-camera core sets board_info-platform_data itself to a pointer to the struct soc_camera_link instance. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drxk: Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor'
Fix regression introduced by commit '[media] Remove Annex A/C selection via roll-off factor' As a result of this commit, DVB-T tuning did not work anymore. Signed-off-by: Oliver Endriss o.endr...@gmx.de diff --git a/drivers/media/dvb/frontends/drxk_hard.c b/drivers/media/dvb/frontends/drxk_hard.c index 36e1c82..13f22a1 100644 --- a/drivers/media/dvb/frontends/drxk_hard.c +++ b/drivers/media/dvb/frontends/drxk_hard.c @@ -6235,6 +6235,8 @@ static int drxk_set_parameters(struct dvb_frontend *fe) case SYS_DVBC_ANNEX_C: state-m_itut_annex_c = true; break; + case SYS_DVBT: + break; default: return -EINVAL; } -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Jan 4 19:00:20 CET 2012 git hash:1e73fa5d56333230854ae9460579eb2fcee8af02 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK 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: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-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: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 16/47] [media] tuner-xc2028: use DVBv5 parameters on set_params()
On 02-01-2012 17:32, Gianluca Gennari wrote:
Il 24/12/2011 16:50, Mauro Carvalho Chehab ha scritto:
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 83
1 files changed, 36 insertions(+), 47 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index e531267..8c0dc6a1 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1087,65 +1087,26 @@ static int xc2028_set_analog_freq(struct
dvb_frontend *fe,
static int xc2028_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
+struct dtv_frontend_properties *c = fe-dtv_property_cache;
+u32 delsys = c-delivery_system;
+u32 bw = c-bandwidth_hz;
struct xc2028_data *priv = fe-tuner_priv;
unsigned int type=0;
-fe_bandwidth_t bw = BANDWIDTH_8_MHZ;
u16demod = 0;
tuner_dbg(%s called\n, __func__);
-switch(fe-ops.info.type) {
-case FE_OFDM:
-bw = p-u.ofdm.bandwidth;
+switch (delsys) {
+case SYS_DVBT:
+case SYS_DVBT2:
/*
* The only countries with 6MHz seem to be Taiwan/Uruguay.
* Both seem to require QAM firmware for OFDM decoding
* Tested in Taiwan by Terry Wu terrywu2...@gmail.com
*/
-if (bw == BANDWIDTH_6_MHZ)
+if (bw = 600)
type |= QAM;
-break;
-case FE_ATSC:
-bw = BANDWIDTH_6_MHZ;
-/* The only ATSC firmware (at least on v2.7) is D2633 */
-type |= ATSC | D2633;
-break;
-/* DVB-S and pure QAM (FE_QAM) are not supported */
-default:
-return -EINVAL;
-}
-
-switch (bw) {
-case BANDWIDTH_8_MHZ:
-if (p-frequency 47000)
-priv-ctrl.vhfbw7 = 0;
-else
-priv-ctrl.uhfbw8 = 1;
-type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
-type |= F8MHZ;
-break;
-case BANDWIDTH_7_MHZ:
-if (p-frequency 47000)
-priv-ctrl.vhfbw7 = 1;
-else
-priv-ctrl.uhfbw8 = 0;
-type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
-type |= F8MHZ;
-break;
-case BANDWIDTH_6_MHZ:
-type |= DTV6;
-priv-ctrl.vhfbw7 = 0;
-priv-ctrl.uhfbw8 = 0;
-break;
-default:
-tuner_err(error: bandwidth not supported.\n);
-};
-/*
- Selects between D2633 or D2620 firmware.
- It doesn't make sense for ATSC, since it should be D2633 on all cases
- */
-if (fe-ops.info.type != FE_ATSC) {
switch (priv-ctrl.type) {
case XC2028_D2633:
type |= D2633;
@@ -1161,6 +1122,34 @@ static int xc2028_set_params(struct dvb_frontend *fe,
else
type |= D2620;
}
+break;
+case SYS_ATSC:
+/* The only ATSC firmware (at least on v2.7) is D2633 */
+type |= ATSC | D2633;
+break;
+/* DVB-S and pure QAM (FE_QAM) are not supported */
+default:
+return -EINVAL;
+}
+
+if (bw = 600) {
+type |= DTV6;
+priv-ctrl.vhfbw7 = 0;
+priv-ctrl.uhfbw8 = 0;
+} else if (bw = 700) {
+if (c-frequency 47000)
+priv-ctrl.vhfbw7 = 1;
+else
+priv-ctrl.uhfbw8 = 0;
+type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
+type |= F8MHZ;
+} else {
+if (c-frequency 47000)
+priv-ctrl.vhfbw7 = 0;
+else
+priv-ctrl.uhfbw8 = 1;
+type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
+type |= F8MHZ;
}
/* All S-code tables need a 200kHz shift */
@@ -1185,7 +1174,7 @@ static int xc2028_set_params(struct dvb_frontend *fe,
*/
}
-return generic_set_freq(fe, p-frequency,
+return generic_set_freq(fe, c-frequency,
V4L2_TUNER_DIGITAL_TV, type, 0, demod);
}
Hi Mauro,
I've tested the new media_build tree with the DVBv5 modifications on my
Terratec Cinergy Hybrid T USB XS (0ccd:0042).
The card works fine, but there is small issue: with the old code the
BASE firmware was loaded only 1 time, now it seems to be loaded each
time a new frequency is tuned (forcing reload of the other firmwares too).
This is a log of
Re: [PATCH v4 16/47] [media] tuner-xc2028: use DVBv5 parameters on set_params()
Il 04/01/2012 19:50, Mauro Carvalho Chehab ha scritto:
On 02-01-2012 17:32, Gianluca Gennari wrote:
Il 24/12/2011 16:50, Mauro Carvalho Chehab ha scritto:
Instead of using DVBv3 parameters, rely on DVBv5 parameters to
set the tuner.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/tuner-xc2028.c | 83
1 files changed, 36 insertions(+), 47 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index e531267..8c0dc6a1 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1087,65 +1087,26 @@ static int xc2028_set_analog_freq(struct
dvb_frontend *fe,
static int xc2028_set_params(struct dvb_frontend *fe,
struct dvb_frontend_parameters *p)
{
+ struct dtv_frontend_properties *c = fe-dtv_property_cache;
+ u32 delsys = c-delivery_system;
+ u32 bw = c-bandwidth_hz;
struct xc2028_data *priv = fe-tuner_priv;
unsigned int type=0;
- fe_bandwidth_t bw = BANDWIDTH_8_MHZ;
u16demod = 0;
tuner_dbg(%s called\n, __func__);
- switch(fe-ops.info.type) {
- case FE_OFDM:
- bw = p-u.ofdm.bandwidth;
+ switch (delsys) {
+ case SYS_DVBT:
+ case SYS_DVBT2:
/*
* The only countries with 6MHz seem to be Taiwan/Uruguay.
* Both seem to require QAM firmware for OFDM decoding
* Tested in Taiwan by Terry Wu terrywu2...@gmail.com
*/
- if (bw == BANDWIDTH_6_MHZ)
+ if (bw = 600)
type |= QAM;
- break;
- case FE_ATSC:
- bw = BANDWIDTH_6_MHZ;
- /* The only ATSC firmware (at least on v2.7) is D2633 */
- type |= ATSC | D2633;
- break;
- /* DVB-S and pure QAM (FE_QAM) are not supported */
- default:
- return -EINVAL;
- }
-
- switch (bw) {
- case BANDWIDTH_8_MHZ:
- if (p-frequency 47000)
- priv-ctrl.vhfbw7 = 0;
- else
- priv-ctrl.uhfbw8 = 1;
- type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
- type |= F8MHZ;
- break;
- case BANDWIDTH_7_MHZ:
- if (p-frequency 47000)
- priv-ctrl.vhfbw7 = 1;
- else
- priv-ctrl.uhfbw8 = 0;
- type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
- type |= F8MHZ;
- break;
- case BANDWIDTH_6_MHZ:
- type |= DTV6;
- priv-ctrl.vhfbw7 = 0;
- priv-ctrl.uhfbw8 = 0;
- break;
- default:
- tuner_err(error: bandwidth not supported.\n);
- };
- /*
- Selects between D2633 or D2620 firmware.
- It doesn't make sense for ATSC, since it should be D2633 on all cases
-*/
- if (fe-ops.info.type != FE_ATSC) {
switch (priv-ctrl.type) {
case XC2028_D2633:
type |= D2633;
@@ -1161,6 +1122,34 @@ static int xc2028_set_params(struct dvb_frontend *fe,
else
type |= D2620;
}
+ break;
+ case SYS_ATSC:
+ /* The only ATSC firmware (at least on v2.7) is D2633 */
+ type |= ATSC | D2633;
+ break;
+ /* DVB-S and pure QAM (FE_QAM) are not supported */
+ default:
+ return -EINVAL;
+ }
+
+ if (bw = 600) {
+ type |= DTV6;
+ priv-ctrl.vhfbw7 = 0;
+ priv-ctrl.uhfbw8 = 0;
+ } else if (bw = 700) {
+ if (c-frequency 47000)
+ priv-ctrl.vhfbw7 = 1;
+ else
+ priv-ctrl.uhfbw8 = 0;
+ type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV7;
+ type |= F8MHZ;
+ } else {
+ if (c-frequency 47000)
+ priv-ctrl.vhfbw7 = 0;
+ else
+ priv-ctrl.uhfbw8 = 1;
+ type |= (priv-ctrl.vhfbw7 priv-ctrl.uhfbw8) ? DTV78 : DTV8;
+ type |= F8MHZ;
}
/* All S-code tables need a 200kHz shift */
@@ -1185,7 +1174,7 @@ static int xc2028_set_params(struct dvb_frontend *fe,
*/
}
- return generic_set_freq(fe, p-frequency,
+ return generic_set_freq(fe, c-frequency,
V4L2_TUNER_DIGITAL_TV, type, 0, demod);
}
Hi Mauro,
I've tested the new media_build tree with the DVBv5 modifications on my
Terratec Cinergy Hybrid T USB XS (0ccd:0042).
The card works fine, but there is small issue: with the old code the
BASE firmware was loaded only 1 time, now it seems to be loaded each
time a new frequency is tuned (forcing reload of the other firmwares too).
This is a log of the firmware loads after some channel surfing:
OLD
[PATCH v3] xc3028: fix center frequency calculation for DTV78 firmware
Hi all, this v3 version has been sent through git send-email to avoid line-wrapping problems. This patch replaces the previous one proposed in the thread xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator. The problem is that the firmware DTV78 works fine in UHF band (8 MHz bandwidth) but is not working at all in VHF band (7 MHz bandwidth). Reading the comments inside the code, I figured out that the real problem could be connected to the formula used to calculate the center frequency offset in VHF band. In fact, removing this adjustment fixes the problem: if ((priv-cur_fw.type DTV78) freq 47000) offset -= 50; This is coherent to what was implemented for the DTV7 firmware by an Australian user: if (priv-cur_fw.type DTV7) offset += 50; In the end, now the center frequency is the same for all firmwares (DTV7, DTV8, DTV78) and doesn't depend on channel bandwidth. The final code looks clean and simple, and there is no need for any magic adjustment: if (priv-cur_fw.type DTV6) offset = 175; else/* DTV7 or DTV8 or DTV78 */ offset = 275; Signed-off-by: Gianluca Gennari gennar...@gmail.com --- drivers/media/common/tuners/tuner-xc2028.c | 26 -- 1 files changed, 16 insertions(+), 10 deletions(-) diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index bdcbfd7..2755599 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -962,14 +962,24 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, * For DTV 7/8, the firmware uses BW = 8000, so it needs a * further adjustment to get the frequency center on VHF */ + + /* +* The firmware DTV78 used to work fine in UHF band (8 MHz +* bandwidth) but not at all in VHF band (7 MHz bandwidth). +* The real problem was connected to the formula used to +* calculate the center frequency offset in VHF band. +* In fact, removing the 500KHz adjustment fixed the problem. +* This is coherent to what was implemented for the DTV7 +* firmware. +* In the end, now the center frequency is the same for all 3 +* firmwares (DTV7, DTV8, DTV78) and doesn't depend on channel +* bandwidth. +*/ + if (priv-cur_fw.type DTV6) offset = 175; - else if (priv-cur_fw.type DTV7) - offset = 225; - else/* DTV8 or DTV78 */ + else/* DTV7 or DTV8 or DTV78 */ offset = 275; - if ((priv-cur_fw.type DTV78) freq 47000) - offset -= 50; /* * xc3028 additional magic @@ -979,17 +989,13 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 freq /* in HZ */, * newer firmwares */ -#if 1 /* * The proper adjustment would be to do it at s-code table. * However, this didn't work, as reported by * Robert Lowery rglow...@exemail.com.au */ - if (priv-cur_fw.type DTV7) - offset += 50; - -#else +#if 0 /* * Still need tests for XC3028L (firmware 3.2 or upper) * So, for now, let's just comment the per-firmware -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] V4L: mt9m111: clean up and fix .s_crop() / .s_fmt()
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Hi all While working on a context-switching test, I've cleaned up the mt9m111 driver a bit and fixed its cropping and scaling functions. These are planned for 3.3. Hi Guennadi, I've been on holidays ... so I've not dived into your changes. From a quick glance, it looks good. Did you test your changes on real hardware (I'm thinking of the suspend power cut part) ? Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi Sylwester,
On Sun, Jan 01, 2012 at 04:38:21PM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 09:41 PM, Sakari Ailus wrote:
On Fri, Dec 30, 2011 at 11:14:39AM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 12:34 AM, Sakari Ailus wrote:
On Wed, Dec 28, 2011 at 02:51:38PM +0100, Laurent Pinchart wrote:
On Wednesday 28 December 2011 14:35:00 Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is
provided as menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently and
noticed they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
Indoor (Incandescant Lighting) Mode,
Outdoor (Sunlight) Mode,
Indoor (Fluorescent Lighting) Mode,
Manual Mode,
Auto Mode,
NULL
};
static const struct v4l2_ctrl_config pwc_auto_white_balance_cfg = {
.ops= pwc_ctrl_ops,
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type = V4L2_CTRL_TYPE_MENU,
.max= awb_auto,
.qmenu = pwc_auto_whitebal_qmenu,
};
...
cfg = pwc_auto_white_balance_cfg;
cfg.name = v4l2_ctrl_get_name(cfg.id);
cfg.def = def;
pdev-auto_white_balance = v4l2_ctrl_new_custom(hdl, cfg,
NULL);
So this driver re-defines V4L2_CID_AUTO_WHITE_BALANCE as a menu control
with custom entries. That's interesting... However it works in practice
and applications have access to what's provided by hardware.
Perhaps V4L2_CID_AUTO_WHITE_BALANCE_TEMPERATURE would be a better fit
for
that :)
Nevertheless, redefining standard controls in particular drivers sounds
a little dubious. I wonder if this is a generally agreed approach ?
No agreed with me at least :-)
Then, how does your V4L2_CID_PRESET_WHITE_BALANCE control interact with
V4L2_CID_AUTO_WHITE_BALANCE control ? Does V4L2_CID_AUTO_WHITE_BALANCE
need
to be set to false for V4L2_CID_PRESET_WHITE_BALANCE to be effective ?
Is the preset a fixed white balance setting, or is it an auto white
balance
with the algorithm tuned for a particular configuration ? In the first
case,
does it correspond to a fixed white balance temperature value ?
While I'm waiting for a final answer to this, I guess it's the second.
There
are three things involved here:
- V4L2_CID_WHITE_BALANCE_TEMPERATURE: relatively low level control telling
the colour temperature of the light source. Setting a value for this
essentially means using manual white balance.
- V4L2_CID_AUTO_WHITE_BALANCE: automatic white balance enabled or
disabled.
Was the third thing the V4L2_CID_DO_WHITE_BALANCE control that you wanted
to
say ? It's also quite essential functionality, to be able to fix white
balance
after pointing camera to a white object. And I would expect
V4L2_CID_WHITE_BALANCE_PRESET control's documentation to state how an
interaction with V4L2_CID_DO_WHITE_BALANCE looks like.
I expected the new control to be the third thing as configuration for the
awb algorithm, which it turned out not to be.
I don't quite understand the purpose of the do_white_balance; the automatic
white balance algorithm is operational until it's disabled, and after
disabling it the white balance shouldn't change. What is the extra
functionality that the do_white_balance control implements?
Maybe DO_WHITE_BALANCE was inspired by some hardware's behaviour, I don't
know. I have nothing against this control. It allows you to perform one-shot
white balance in a given moment in time. Simple and clear.
Well, yes, if you have an automatic white balance algorithm which supports
one-shot mode. Typically it's rather a feedback loop. I guess this means
just run one iteration.
Something like this should possibly be used to get the white balance correct
by pointing the camera to an object of known colour (white typically, I
think). But this isn't it, at least based on the description in the spec.
If we agree white_balance_preset works at the same level as
white_balance_temerature control, this becomes more simple. I guess no
driver should implement both.
Yes, AFAIU those presets are just WB temperature, with names instead
of numbers. Thus it doesn't make much sense to expose both at the driver.
But in manual white balance mode camera could be switched to new WB value,
with component gain/balance controls, DO_WHITE_BALANCE or whatever, rendering
the preset setting invalid. Should we then have an invalid/unknown item in
the presets menu ? This would be only allowed to set by driver, i.e.
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On Wednesday 04 January 2012 18:13:58 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, Laurent Pinchart wrote: On Wednesday 04 January 2012 17:35:27 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, javier Martin wrote: [snip] For ov7725 it is a natural thing to do since it was originally developed for soc-camera and it can easily do the following to access platform data: struct soc_camera_link *icl = soc_camera_i2c_to_link(client); pdata = icl-priv; However, tvp5150 is not aware about soc_camera. I should be able to tell whether it's being used with soc-camera or not. If soc camera was used I would do the previous method to retrieve platform data. But if soc-camera was not used I would do the classic method: struct tvp5150_platform_data *pdata = client-dev.platform_data; The problem is how to distinguish in tvp5150 whether I am using soc_camera or not. Right, that _is_ the problem now. And we've known about it since the very first time we started to think about re-using the subdev drivers. The only solution I see so far is to introduce a standard platform data struct for all subdevices, similar to soc_camera_link. We could use it as a basis, of course, use a generic name, maybe reconsider fields - rename / remove / add, but the principle would be the same: a standard platform data struct with an optional private field. Why is that needed ? Why can't a tvp5150-specific platform data structure do ? Javier has actually explained this already. Sorry for not having followed. Ok, again: he wants to use tvp5150 with an soc-camera host driver, i.e., with the soc-camera subsystem. And the soc-camera core sets board_info- platform_data itself to a pointer to the struct soc_camera_link instance. That looks to me like it's the part to be changed... -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi Sakari,
On Wednesday 04 January 2012 21:39:34 Sakari Ailus wrote:
On Sun, Jan 01, 2012 at 04:38:21PM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 09:41 PM, Sakari Ailus wrote:
On Fri, Dec 30, 2011 at 11:14:39AM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 12:34 AM, Sakari Ailus wrote:
On Wed, Dec 28, 2011 at 02:51:38PM +0100, Laurent Pinchart wrote:
On Wednesday 28 December 2011 14:35:00 Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is
provided as menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently
and noticed they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
Indoor (Incandescant Lighting) Mode,
Outdoor (Sunlight) Mode,
Indoor (Fluorescent Lighting) Mode,
Manual Mode,
Auto Mode,
NULL
};
static const struct v4l2_ctrl_config pwc_auto_white_balance_cfg = {
.ops= pwc_ctrl_ops,
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type = V4L2_CTRL_TYPE_MENU,
.max= awb_auto,
.qmenu = pwc_auto_whitebal_qmenu,
};
...
cfg = pwc_auto_white_balance_cfg;
cfg.name = v4l2_ctrl_get_name(cfg.id);
cfg.def = def;
pdev-auto_white_balance = v4l2_ctrl_new_custom(hdl, cfg,
NULL);
So this driver re-defines V4L2_CID_AUTO_WHITE_BALANCE as a menu
control with custom entries. That's interesting... However it
works in practice and applications have access to what's provided
by hardware. Perhaps V4L2_CID_AUTO_WHITE_BALANCE_TEMPERATURE would
be a better fit for that :)
Nevertheless, redefining standard controls in particular drivers
sounds a little dubious. I wonder if this is a generally agreed
approach ?
No agreed with me at least :-)
Then, how does your V4L2_CID_PRESET_WHITE_BALANCE control interact
with V4L2_CID_AUTO_WHITE_BALANCE control ? Does
V4L2_CID_AUTO_WHITE_BALANCE need to be set to false for
V4L2_CID_PRESET_WHITE_BALANCE to be effective ?
Is the preset a fixed white balance setting, or is it an auto white
balance with the algorithm tuned for a particular configuration ?
In the first case, does it correspond to a fixed white balance
temperature value ?
While I'm waiting for a final answer to this, I guess it's the
second. There are three things involved here:
- V4L2_CID_WHITE_BALANCE_TEMPERATURE: relatively low level control
telling
the colour temperature of the light source. Setting a value for
this essentially means using manual white balance.
- V4L2_CID_AUTO_WHITE_BALANCE: automatic white balance enabled or
disabled.
Was the third thing the V4L2_CID_DO_WHITE_BALANCE control that you
wanted to say ? It's also quite essential functionality, to be able
to fix white balance after pointing camera to a white object. And I
would expect
V4L2_CID_WHITE_BALANCE_PRESET control's documentation to state how an
interaction with V4L2_CID_DO_WHITE_BALANCE looks like.
I expected the new control to be the third thing as configuration for
the awb algorithm, which it turned out not to be.
I don't quite understand the purpose of the do_white_balance; the
automatic white balance algorithm is operational until it's disabled,
and after disabling it the white balance shouldn't change. What is the
extra functionality that the do_white_balance control implements?
Maybe DO_WHITE_BALANCE was inspired by some hardware's behaviour, I don't
know. I have nothing against this control. It allows you to perform
one-shot white balance in a given moment in time. Simple and clear.
Well, yes, if you have an automatic white balance algorithm which supports
one-shot mode. Typically it's rather a feedback loop. I guess this means
just run one iteration.
Something like this should possibly be used to get the white balance
correct by pointing the camera to an object of known colour (white
typically, I think). But this isn't it, at least based on the description
in the spec.
Then either the spec is incorrect, or I'm mistaken. My understanding of the
DO_WHITE_BALANCE control is exactly what you described.
If we agree white_balance_preset works at the same level as
white_balance_temerature control, this becomes more simple. I guess no
driver should implement both.
Yes, AFAIU those presets are just WB temperature, with names instead
of numbers. Thus it doesn't make much sense to expose both at the driver.
But in
Re: [RFC PATCH 0/4] Add some new camera controls
Hi Sylwester, On Fri, Dec 30, 2011 at 12:18:40PM +0100, Sylwester Nawrocki wrote: On 12/28/2011 03:01 PM, Laurent Pinchart wrote: On Wednesday 28 December 2011 07:23:44 HeungJun, Kim wrote: This RFC patch series include new 4 controls ID for digital camera. I about to suggest these controls by the necessity enabling the M-5MOLS sensor's function, and I hope to discuss this in here. Thanks for the patches. The new controls introduced by these patches are very high level. Should they be put in their own class ? I also think we should specify how those high- level controls interact with low-level controls, otherwise applications will likely get very confused. I agree we may need a separate control class for those high-level controls. They are mostly applicable to software ISP algorithms, run either on digital signal processor embedded in the sensor or on a processor being part of an SoC. Thus we would three levels of controls for camera, 1) image source class (lowest possible level), dealing mostly with hardware registers; I intended the image source class for controls which only deal with the a/d conversion itself. Other controls would be elsewhere. There hasn't been a final decision on this yet, but an alternative which has been also discussed is just to call this a low level control class. 2) normal camera controls (V4L2_CID_CAMERA_CLASS) [2]; 3) high level camera controls (for camera software algorithms) Almost all the automatic anything algorithms are impelemented in software. But when software is involved, the possibilities are mostly limitless; it's a matter of imagination what kind of interesting white balance algorithms plus some camera controls are in the user controls class. I'm not sure why there are camera controls in the user control class, perhaps there was no camera class yet at the time V4L2_CID_EXPOSURE or V4L2_CID_BACKLIGHT_COMPENSATION were added. I might be missing something else. The camera control class is relatively new, so that's likely what happened. Speaking of the classes --- I could resend my patch which allows changing controls in different classes in the same s_ext_ctrls call --- I looked at it some time ago and no driver had any limitations on this; it's just the documentation and the control framework which do. I'm afraid a little it might be hard to distinguish if some control should belong to 2) or 3), as sensors' logic complexity and advancement varies. I can see two main use cases: 1. V4L2 / V4L2 subdev / MC as the low level API for camera control and 2. Regular V4L2 applications. For most controls it's clear which of the two classes they belong to. Although I can see an advantage of logically separating controls which have influence on one or more other (lower level) controls. And separate control class would be helpful in that. The candidates to such control class might be: * V4L2_CID_METERING_MODE, * V4L2_CID_EXPOSURE_BIAS, * V4L2_CID_ISO, * V4L2_CID_WHITE_BALANCE_PRESET, * V4L2_CID_SCENEMODE, * V4L2_CID_WDR, * V4L2_CID_ANTISHAKE, The list looks good to me. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi Laurent,
Laurent Pinchart wrote:
Hi Sakari,
On Wednesday 04 January 2012 21:39:34 Sakari Ailus wrote:
On Sun, Jan 01, 2012 at 04:38:21PM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 09:41 PM, Sakari Ailus wrote:
On Fri, Dec 30, 2011 at 11:14:39AM +0100, Sylwester Nawrocki wrote:
On 12/30/2011 12:34 AM, Sakari Ailus wrote:
On Wed, Dec 28, 2011 at 02:51:38PM +0100, Laurent Pinchart wrote:
On Wednesday 28 December 2011 14:35:00 Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is
provided as menu type using the following items:
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently
and noticed they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
Indoor (Incandescant Lighting) Mode,
Outdoor (Sunlight) Mode,
Indoor (Fluorescent Lighting) Mode,
Manual Mode,
Auto Mode,
NULL
};
static const struct v4l2_ctrl_config pwc_auto_white_balance_cfg = {
.ops=pwc_ctrl_ops,
.id = V4L2_CID_AUTO_WHITE_BALANCE,
.type = V4L2_CTRL_TYPE_MENU,
.max= awb_auto,
.qmenu = pwc_auto_whitebal_qmenu,
};
...
cfg = pwc_auto_white_balance_cfg;
cfg.name = v4l2_ctrl_get_name(cfg.id);
cfg.def = def;
pdev-auto_white_balance = v4l2_ctrl_new_custom(hdl,cfg, NULL);
So this driver re-defines V4L2_CID_AUTO_WHITE_BALANCE as a menu
control with custom entries. That's interesting... However it
works in practice and applications have access to what's provided
by hardware. Perhaps V4L2_CID_AUTO_WHITE_BALANCE_TEMPERATURE would
be a better fit for that :)
Nevertheless, redefining standard controls in particular drivers
sounds a little dubious. I wonder if this is a generally agreed
approach ?
No agreed with me at least :-)
Then, how does your V4L2_CID_PRESET_WHITE_BALANCE control interact
with V4L2_CID_AUTO_WHITE_BALANCE control ? Does
V4L2_CID_AUTO_WHITE_BALANCE need to be set to false for
V4L2_CID_PRESET_WHITE_BALANCE to be effective ?
Is the preset a fixed white balance setting, or is it an auto white
balance with the algorithm tuned for a particular configuration ?
In the first case, does it correspond to a fixed white balance
temperature value ?
While I'm waiting for a final answer to this, I guess it's the
second. There are three things involved here:
- V4L2_CID_WHITE_BALANCE_TEMPERATURE: relatively low level control
telling
the colour temperature of the light source. Setting a value for
this essentially means using manual white balance.
- V4L2_CID_AUTO_WHITE_BALANCE: automatic white balance enabled or
disabled.
Was the third thing the V4L2_CID_DO_WHITE_BALANCE control that you
wanted to say ? It's also quite essential functionality, to be able
to fix white balance after pointing camera to a white object. And I
would expect
V4L2_CID_WHITE_BALANCE_PRESET control's documentation to state how an
interaction with V4L2_CID_DO_WHITE_BALANCE looks like.
I expected the new control to be the third thing as configuration for
the awb algorithm, which it turned out not to be.
I don't quite understand the purpose of the do_white_balance; the
automatic white balance algorithm is operational until it's disabled,
and after disabling it the white balance shouldn't change. What is the
extra functionality that the do_white_balance control implements?
Maybe DO_WHITE_BALANCE was inspired by some hardware's behaviour, I don't
know. I have nothing against this control. It allows you to perform
one-shot white balance in a given moment in time. Simple and clear.
Well, yes, if you have an automatic white balance algorithm which supports
one-shot mode. Typically it's rather a feedback loop. I guess this means
just run one iteration.
Something like this should possibly be used to get the white balance
correct by pointing the camera to an object of known colour (white
typically, I think). But this isn't it, at least based on the description
in the spec.
Then either the spec is incorrect, or I'm mistaken. My understanding of the
DO_WHITE_BALANCE control is exactly what you described.
This is what the spec says:
This is an action control. When set (the value is ignored), the device
will do a white balance and then hold the current setting. Contrast this
with the boolean V4L2_CID_AUTO_WHITE_BALANCE, which, when activated,
keeps adjusting the white balance.
I wonder if that should be then changed --- or is it just me who got a
different idea from the above description?
My understanding is that the operation for getting the white balance
information from a white object is by far simpler than getting the white
balance
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On Wed, 4 Jan 2012, Laurent Pinchart wrote: On Wednesday 04 January 2012 18:13:58 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, Laurent Pinchart wrote: On Wednesday 04 January 2012 17:35:27 Guennadi Liakhovetski wrote: On Wed, 4 Jan 2012, javier Martin wrote: [snip] For ov7725 it is a natural thing to do since it was originally developed for soc-camera and it can easily do the following to access platform data: struct soc_camera_link*icl = soc_camera_i2c_to_link(client); pdata = icl-priv; However, tvp5150 is not aware about soc_camera. I should be able to tell whether it's being used with soc-camera or not. If soc camera was used I would do the previous method to retrieve platform data. But if soc-camera was not used I would do the classic method: struct tvp5150_platform_data *pdata = client-dev.platform_data; The problem is how to distinguish in tvp5150 whether I am using soc_camera or not. Right, that _is_ the problem now. And we've known about it since the very first time we started to think about re-using the subdev drivers. The only solution I see so far is to introduce a standard platform data struct for all subdevices, similar to soc_camera_link. We could use it as a basis, of course, use a generic name, maybe reconsider fields - rename / remove / add, but the principle would be the same: a standard platform data struct with an optional private field. Why is that needed ? Why can't a tvp5150-specific platform data structure do ? Javier has actually explained this already. Sorry for not having followed. Ok, again: he wants to use tvp5150 with an soc-camera host driver, i.e., with the soc-camera subsystem. And the soc-camera core sets board_info- platform_data itself to a pointer to the struct soc_camera_link instance. That looks to me like it's the part to be changed... Well, we could do this, but this would require changing a few soc-camera subdev drivers and respective platforms and (slightly) the core itself. The soc-camera core needs access to the struct soc_camera_link instance, supplied by the platform. It is passed in .platform_data of the soc-camera client platform device, there's no need to change that. struct soc_camera_link::board_info points to struct i2c_board_info, this is also ok. Basically, that's all the soc-camera core needs - access to these two structs. Next, subdevice drivers also need access to struct soc_camera_link and to their private data. If we let platforms pass subdevice driver private data in i2c_board_info::platform_data, then each driver will need to invent its own way how to also get to struct soc_camera_link. They would either have to point at it from their private data or embed it therein. So, yes, it is doable. AFAICS currently these subdevice drivers soc_camera_platform rj54n1cb0c tw9910 mt9t112 ov772x and these platforms sh/ecovec24 sh/kfr2r09 sh/migor sh/ap325rxa arm/mackerel are affected and have to be modified. After which the core can be fixed too. I could do that, but not sure when I find the time. Javier, if you like, feel free to give it a try. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Hi Sakari,
On 01/04/2012 01:21 PM, Sakari Ailus wrote:
On Sun, Jan 01, 2012 at 07:56:03PM +0100, Sylwester Nawrocki wrote:
On 12/31/2011 02:16 PM, Sakari Ailus wrote:
Something else that should probably belong there is information on the
frame
format: contrary to what I've previously thought, the sensor metadata is
often sent as part of the same CSI-2 channel. There also can be other
types
of data, such as dummy data and data for black level calibration. I
wouldn't
want to export all this to the user space --- it shouldn't probably need
to
care about it.
The transmitter of the data (sensor) has this information and the CSI-2
receiver needs it. Same for the framesamples, as far as I understand.
We could try to design some standard data structure for frame metadata -
that's how I understood the meaning of struct v4l2_mbus_framedesc.
But I doubt such attempts will be sucessful. And how can we distinguish
which data is valid and applicable when there is lots of weird stuff in one
data structure ? Using media bus pixel code only ?
I think the media bus pixel code which is exported to the user space should
not be involved with the metadata.
Then we need to find some method to distinguish streams with metadata on the
media bus, to be able to discard it before sending to user space.
I assume this is where struct v4l2_mbus_framedesc and related ops would help
?
I'd think so.
Maybe we could create v4l2_mbus_framedesc with length (framesamples) member
in it and additionally 994 reserved bytes for future extensions ;-), e.g.
struct v4l2_mbus_framedesc {
unsigned int length;
unsigned int rserved[994];
};
Do we need to export this to the user space? In the first phase I'd like to
No, that wasn't my intention. The reserved field was supposed to be a joke,
we of course don't need any reserved members in the kernel space.
keep that static (i.e. only get op would be supported) and only visible in
the kernel. That would leave much more room for changes later on, if needed.
I'd prefer it to be R/W, i.e. having both get and set ops available. Maybe
not for all fields though.
struct v4l2_subdev_pad_ops {
int get_framedesc(int pad, struct v4l2_framedesc *fdesc);
int set_framedesc(int pad, struct v4l2_framedesc fdesc);
};
This would ensure same media bus format code regardless of frame meta data
presence.
In case metadata is sent in same CSI channel, the required buffer length
might be greater than what would width/height and pixel code suggest.
Partly for this reason we have g_skip_top_lines() op in sensor ops. It
instructs the receiver to discard the metadata, and possibly other data
which isn't as interesting --- could be just dummy.
I see.
Some CSI-2 receivers are able to write this to a different memory location;
we could expose this as a different video node. I'm proposing a different
video node since this is a separate queue: the format (in-memory pixel
format and dimensions) is different, and it is beneficial to have access to
this data as soon as possible. There is a caveat, though, if we also wish to
support metadata which is appended to the frame, rather than prependeded.
I think it is recurring topic in our discussions, I guess nobody really needs
it since it haven't been implemented yet. ;)
Multi-planar buffers were meant also for handling meta data, only variable
number of planes support would need to be added. For instance the driver could
pass only the buffer with meta data plane if required.
The metadata is something that the user is likely interested only in the
form it is in the system memory. It won't be processed in any way before
it gets written to memory. The chosen mbus code may affect the format of the
metadata, but that's something the sensor driver knows -- and I've yet to
see a case where the user could choose the desired metadata format.
Alternatively we could make the metadata path a separate path from the image
data. I wonder how feasible that approach would be --- the subdevs would
still be the same.
I was also considering metadata as sensor specific data structure retrieved
by the host after a frame has been captured and appending that data to a user
buffer. For such buffers a separate fourcc would be needed.
Why after?
Because there is no way to retrieve it before ? :)
There are benefits in getting this to the user space without extra delays?
It doesn't matter that much because image data is already post-processed.
And the case I was mentioning was about still capture, asisted in the sensor
(SoC).
Pixelrate is also used to figure out whether a pipeline can do streaming
or
not; the pixel rate originating from the sensor could be higher than the
maximum of the ISP. For this reason, as well as for providing timing
information, access to pixelrate is reequired in the user space.
Configuring the framesamples could be done on the sensor using a control
if
Re: [PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch
On 04-01-2012 20:44, Mauro Carvalho Chehab wrote: On 04-01-2012 13:28, Steven Toth wrote: Mauro, I've been adding support to the CX23885 and CX25840 drivers for the Hauppauge HVR1850 card. These patches enable the use of raw video, audio and/or the mpeg encoder, via all video and audio inputs. Support for the HVR1850 is now in pretty good shape. The card uses the CX23888 PCIe bridge which brings its own complexities and additional code to the CX25840. I've tested these patches against the HVR1700, HVR1800 and HVR1850, everything appears to be working correctly. These also fix a small regression in the HVR1800 driver related to the work done during October 2010 on the subdev conversion. Given that nobody has noticed in the last 12 months it's not too important. Tree is at git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch. Steve, Please, always use git request-pull to generate pull requests, otherwise patchwork won't catch and I may miss it. Thanks, Mauro Patch series viewable at: http://git.kernellabs.com/?p=stoth/cx23885-hvr1850.git;a=shortlog;h=refs/heads/media-master [media] cx25840: Added g_std support to the video decoder driver [media] cx25840: Hauppauge HVR1850 Analog driver support (patch#4) [media] cx25840: Add a flag to enable the CX23888 DIF to be enabled or not. [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#3) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#2) [media] cx23885: Hauppauge HVR1850 Analog driver support (patch#1) [media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation Not applied the above patches, due to a compilation breakage on the next patch that are before them. [media] cx23885: Control cleanup on the MPEG Encoder There's something wrong on this patch. It breaks compilation: drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_s_std’: drivers/media/video/cx23885/cx23885-417.c:1240:2: error: implicit declaration of function ‘cx23885_set_tvnorm’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_enum_input’: drivers/media/video/cx23885/cx23885-417.c:1251:2: error: implicit declaration of function ‘cx23885_enum_input’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_g_input’: drivers/media/video/cx23885/cx23885-417.c:1256:2: error: implicit declaration of function ‘cx23885_get_input’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_s_input’: drivers/media/video/cx23885/cx23885-417.c:1261:2: error: implicit declaration of function ‘cx23885_set_input’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_s_frequency’: drivers/media/video/cx23885/cx23885-417.c:1316:2: error: implicit declaration of function ‘cx23885_set_frequency’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_g_ctrl’: drivers/media/video/cx23885/cx23885-417.c:1324:2: error: implicit declaration of function ‘cx23885_get_control’ [-Werror=implicit-function-declaration] drivers/media/video/cx23885/cx23885-417.c: In function ‘vidioc_s_ctrl’: drivers/media/video/cx23885/cx23885-417.c:1332:2: error: implicit declaration of function ‘cx23885_set_control’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Please fix it. No patch should break compilation, or it would affect git bisect handling with is bad not only for media developers, but for everybody else working with Kernel development. [media] cx23885: Configure the MPEG encoder early to avoid jerky video This one also breaks compilation: drivers/media/video/cx23885/cx23885-417.c:1351:2: error: too few arguments to function ‘cx23885_initialize_codec’ In this specific case, the fix is trivial, so, I've applied it, and added a reviewer note about the breakage fix. [media] cx23885: Ensure the MPEG encoder height is configured from the norm [media] cx23885: Cleanup MPEG encoder GPIO handling [media] cx25840 / cx23885: Fixing audio/volume regression Those were also applied. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix Leadtek DTV2000H radio tuner
On 16-12-2011 22:39, Miroslav Slugeň wrote: Leadtek DTV2000H J revision has FMD1216MEX, no older FMD1216ME. But there is still another unknown issue with radio, because some stations are just not working or are very noisy. Miroslav, Please sign your patches with: Signed-off-by: your name your@email As described at: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches For the patches you've already send, you should reply to each of them with your Signed-off-by. Patchwork will catch your signature. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix Leadtek DTV2000H radio tuner
Resending signed version...
Signed-off-by: Miroslav Slugen thunder@gmail.com
From dadfa45664f765297e03e73a907ac04bd55e9b25 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen thunder@gmail.com
Date: Tue, 13 Dec 2011 19:36:15 +0100
Subject: [PATCH] Leadtek DTV2000H J has Philips FMD1216MEX tuner, this patch fixed not working
radio part, but some stations are still not visible.
---
drivers/media/video/cx88/cx88-cards.c |3 ++-
drivers/media/video/cx88/cx88-dvb.c | 12 +++-
drivers/media/video/tuner-core.c |1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
index dca369d..cbd5d11 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -1306,7 +1306,7 @@ static const struct cx88_board cx88_boards[] = {
},
[CX88_BOARD_WINFAST_DTV2000H_J] = {
.name = WinFast DTV2000 H rev. J,
- .tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+ .tuner_type = TUNER_PHILIPS_FMD1216MEX_MK3,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
@@ -3321,6 +3321,7 @@ static void cx88_card_setup_pre_i2c(struct cx88_core *core)
cx_set(MO_GP0_IO, 0x1010);
break;
+ case CX88_BOARD_WINFAST_DTV2000H_J:
case CX88_BOARD_HAUPPAUGE_HVR3000:
case CX88_BOARD_HAUPPAUGE_HVR4000:
/* Init GPIO */
diff --git a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
index cf3d33a..592f3aa 100644
--- a/drivers/media/video/cx88/cx88-dvb.c
+++ b/drivers/media/video/cx88/cx88-dvb.c
@@ -999,7 +999,6 @@ static int dvb_register(struct cx8802_dev *dev)
}
break;
case CX88_BOARD_WINFAST_DTV2000H:
- case CX88_BOARD_WINFAST_DTV2000H_J:
case CX88_BOARD_HAUPPAUGE_HVR1100:
case CX88_BOARD_HAUPPAUGE_HVR1100LP:
case CX88_BOARD_HAUPPAUGE_HVR1300:
@@ -1013,6 +1012,17 @@ static int dvb_register(struct cx8802_dev *dev)
goto frontend_detach;
}
break;
+ case CX88_BOARD_WINFAST_DTV2000H_J:
+ fe0-dvb.frontend = dvb_attach(cx22702_attach,
+ hauppauge_hvr_config,
+ core-i2c_adap);
+ if (fe0-dvb.frontend != NULL) {
+ if (!dvb_attach(simple_tuner_attach, fe0-dvb.frontend,
+ core-i2c_adap, 0x61,
+ TUNER_PHILIPS_FMD1216MEX_MK3))
+goto frontend_detach;
+ }
+ break;
case CX88_BOARD_HAUPPAUGE_HVR3000:
/* MFE frontend 1 */
mfe_shared = 1;
diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
index 8e7e769..bbfc04f 100644
--- a/drivers/media/video/tuner-core.c
+++ b/drivers/media/video/tuner-core.c
@@ -326,6 +326,7 @@ static void set_type(struct i2c_client *c, unsigned int type,
new_mode_mask = T_RADIO;
break;
case TUNER_PHILIPS_FMD1216ME_MK3:
+ case TUNER_PHILIPS_FMD1216MEX_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
--
1.7.2.3
Re: Fix Leadtek DTV2000H radio tuner
On 04-01-2012 21:54, Miroslav Slugeň wrote: Resending signed version... You need to do the same for the other patches you've sent ;) Thanks Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.3] [media] cx25840 / cx23885: Fixing audio/volume regression
Mauro,
My mistake, I've corrected the issue:
The following changes since commit 9c9c3d078b0dd81a74e5f531aa1efa30add5b419:
[media] cx23885: Configure the MPEG encoder early to avoid jerky
video (2012-01-04 20:51:18 -0200)
are available in the git repository at:
git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3
Steven Toth (6):
[media] cx25840: Add a flag to enable the CX23888 DIF to be
enabled or not.
[media] cx23885: Hauppauge HVR1850 Analog driver support
[media] cx23885: Control cleanup on the MPEG Encoder
[media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation
[media] cx25840: Hauppauge HVR1850 Analog driver support (patch2)
[media] cx25840: Added g_std support to the video decoder driver
drivers/media/video/cx23885/cx23885-417.c | 105 +-
drivers/media/video/cx23885/cx23885-cards.c | 28 +-
drivers/media/video/cx23885/cx23885-core.c | 24 +-
drivers/media/video/cx23885/cx23885-dvb.c | 14 +
drivers/media/video/cx23885/cx23885-video.c | 157 ++-
drivers/media/video/cx23885/cx23885.h | 12 +
drivers/media/video/cx25840/cx25840-core.c | 3224 ++-
include/media/cx25840.h |1 +
8 files changed, 3454 insertions(+), 111 deletions(-)
Thanks,
- Steve
On Wed, Jan 4, 2012 at 5:47 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] cx25840 / cx23885: Fixing audio/volume regression
Author: Steven Toth st...@kernellabs.com
Date: Wed Jan 4 10:47:57 2012 -0300
Since the conversion to subdev in Oct 2010 the audio controls have
not functioned correctly in the cx23885 driver. Passing values of
0-3f did not translate into meaningfull register writes. I've
converted the cx23885 driver to match the cx25840 volume control
definition and now audio is working reliably again.
Signed-off-by: Steven Toth st...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/video/cx23885/cx23885-video.c | 6 +++---
drivers/media/video/cx25840/cx25840-audio.c | 10 +-
2 files changed, 4 insertions(+), 12 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=4c3764d15050f91a76cede6f24402cd2701e73ef
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 7415524..7f3b973 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -253,9 +253,9 @@ static struct cx23885_ctrl cx23885_ctls[] = {
.id = V4L2_CID_AUDIO_VOLUME,
.name = Volume,
.minimum = 0,
- .maximum = 0x3f,
- .step = 1,
- .default_value = 0x3f,
+ .maximum = 65535,
+ .step = 65535 / 100,
+ .default_value = 65535,
.type = V4L2_CTRL_TYPE_INTEGER,
},
.reg = PATH1_VOL_CTL,
diff --git a/drivers/media/video/cx25840/cx25840-audio.c
b/drivers/media/video/cx25840/cx25840-audio.c
index 005f110..34b96c7 100644
--- a/drivers/media/video/cx25840/cx25840-audio.c
+++ b/drivers/media/video/cx25840/cx25840-audio.c
@@ -480,7 +480,6 @@ void cx25840_audio_set_path(struct i2c_client *client)
static void set_volume(struct i2c_client *client, int volume)
{
- struct cx25840_state *state = to_state(i2c_get_clientdata(client));
int vol;
/* Convert the volume to msp3400 values (0-127) */
@@ -496,14 +495,7 @@ static void set_volume(struct i2c_client *client, int
volume)
}
/* PATH1_VOLUME */
- if (is_cx2388x(state)) {
- /* for cx23885 volume doesn't work,
- * the calculation always results in
- * e4 regardless.
- */
- cx25840_write(client, 0x8d4, volume);
- } else
- cx25840_write(client, 0x8d4, 228 - (vol * 2));
+ cx25840_write(client, 0x8d4, 228 - (vol * 2));
}
static void set_balance(struct i2c_client *client, int balance)
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
+1.646.355.8490
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] git://git.kernellabs.com/stoth/cx23885-hvr1850.git media-master branch
There's something wrong on this patch. It breaks compilation: Mauro, My mistake, I've corrected the issue: The following changes since commit 9c9c3d078b0dd81a74e5f531aa1efa30add5b419: [media] cx23885: Configure the MPEG encoder early to avoid jerky video (2012-01-04 20:51:18 -0200) are available in the git repository at: git://git.kernellabs.com/stoth/cx23885-hvr1850-fixups.git staging/for_v3.3 Steven Toth (6): [media] cx25840: Add a flag to enable the CX23888 DIF to be enabled or not. [media] cx23885: Hauppauge HVR1850 Analog driver support [media] cx23885: Control cleanup on the MPEG Encoder [media] cx23885: Bugfix /sys/class/video4linux/videoX/name truncation [media] cx25840: Hauppauge HVR1850 Analog driver support (patch2) [media] cx25840: Added g_std support to the video decoder driver drivers/media/video/cx23885/cx23885-417.c | 105 +- drivers/media/video/cx23885/cx23885-cards.c | 28 +- drivers/media/video/cx23885/cx23885-core.c | 24 +- drivers/media/video/cx23885/cx23885-dvb.c | 14 + drivers/media/video/cx23885/cx23885-video.c | 157 ++- drivers/media/video/cx23885/cx23885.h | 12 + drivers/media/video/cx25840/cx25840-core.c | 3224 ++- include/media/cx25840.h |1 + 8 files changed, 3454 insertions(+), 111 deletions(-) Thanks, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com +1.646.355.8490 -- 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
subdev support for querying struct v4l2_input *
Hans, In the cx23885 driver as part of vidioc_enum_input call, I have a need to return V4L2_IN_ST_NO_SIGNAL in the status field as part of struct v4l2_input. Thus, when no signal is detected by the video decoder it can be signalled to the calling application. I looks like subdev_core_ops doesn't currently support this, or have I miss-understood something? The patch below is a snippet from a larger patch I have which: 1. Adds this support to struct v4l2_subdev_core_ops 2. Adds support to the cx25840 and cx23885 drivers and makes the feature available. Do you have any comments or thoughts on the subdev_ops patch below? Regards, - Steve Index: v4l-dvb/include/media/v4l2-subdev.h === --- v4l-dvb.orig/include/media/v4l2-subdev.h2012-01-03 17:44:24.337826817 -0500 +++ v4l-dvb/include/media/v4l2-subdev.h 2012-01-03 17:44:54.729826263 -0500 @@ -172,6 +172,7 @@ struct v4l2_event_subscription *sub); int (*unsubscribe_event)(struct v4l2_subdev *sd, struct v4l2_fh *fh, struct v4l2_event_subscription *sub); + int (*enum_input)(struct v4l2_subdev *sd, struct v4l2_input *i); }; -- Steven Toth - 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
[PATCH 05/47] [media] mt2063: Fix the driver to make it compile
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c |1 -
drivers/media/common/tuners/mt2063.h | 25 +
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 1d36e51..cd3b206 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -4,7 +4,6 @@
#include linux/module.h
#include linux/string.h
-#include drxk_type.h
#include mt2063.h
/* Version of this module */
diff --git a/drivers/media/common/tuners/mt2063.h
b/drivers/media/common/tuners/mt2063.h
index 8fa4411..80af9af 100644
--- a/drivers/media/common/tuners/mt2063.h
+++ b/drivers/media/common/tuners/mt2063.h
@@ -1,9 +1,19 @@
#ifndef __MT2063_H__
#define __MT2063_H__
-#include linux/dvb/frontend.h
#include dvb_frontend.h
+enum Bool_t {
+ FALSE = 0,
+ TRUE
+};
+
+typedef unsigned long u32_t;
+
+#define DVBFE_TUNER_OPEN 99
+#define DVBFE_TUNER_SOFTWARE_SHUTDOWN 100
+#define DVBFE_TUNER_CLEAR_POWER_MASKBITS 101
+
#define MT2063_ERROR (1 31)
#define MT2063_USER_ERROR (1 30)
@@ -618,17 +628,16 @@ struct mt2063_state {
u32 reference;
};
-#if defined(CONFIG_DVB_MT2063) || (defined(CONFIG_DVB_MT2063_MODULE)
defined(MODULE))
-
-extern struct dvb_frontend *mt2063_attach(struct dvb_frontend *fe,
- struct mt2063_config *config,
- struct i2c_adapter *i2c);
+#if defined(CONFIG_MEDIA_TUNER_MT2063) ||
(defined(CONFIG_MEDIA_TUNER_MT2063_MODULE) defined(MODULE))
+struct dvb_frontend *mt2063_attach(struct dvb_frontend *fe,
+ struct mt2063_config *config,
+ struct i2c_adapter *i2c);
#else
static inline struct dvb_frontend *mt2063_attach(struct dvb_frontend *fe,
-struct mt2063_config *config,
-struct i2c_adapter *i2c)
+ struct mt2063_config *config,
+ struct i2c_adapter *i2c)
{
printk(KERN_WARNING %s: Driver disabled by Kconfig\n, __func__);
return NULL;
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/47] [media] mt2063: Fix some Coding styles at mt2063.h
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.h | 271 +++---
1 files changed, 119 insertions(+), 152 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.h
b/drivers/media/common/tuners/mt2063.h
index 4912f89..8fa4411 100644
--- a/drivers/media/common/tuners/mt2063.h
+++ b/drivers/media/common/tuners/mt2063.h
@@ -4,19 +4,6 @@
#include linux/dvb/frontend.h
#include dvb_frontend.h
-//context of mt2063_errordef.h Henry ==
-//#
-//=
-
-/*
-** Note to users: DO NOT EDIT THIS FILE
-**
-** If you wish to rename any of the user defined bits,
-** it should be done in the user file that includes this
-** source file (e.g. mt_userdef.h)
-**
-*/
-
#define MT2063_ERROR (1 31)
#define MT2063_USER_ERROR (1 30)
@@ -88,37 +75,28 @@
/* Info: Downconverter frequency is out of range (may be reason for
MT_DPC_UNLOCK) */
#define MT2063_DNC_RANGE(0x0800)
-//end of mt2063_errordef.h
-//=
-//#
-//=
-
-//context of mt2063_userdef.h Henry ==
-//#
-//=
/*
-** Data Types
-*/
+ * Data Types
+ */
#define MT2060_CNT 10
typedef unsigned char U8Data; /* type corresponds to 8 bits */
typedef unsigned int UData_t; /* type must be at least 32 bits */
typedef int SData_t; /* type must be at least 32 bits */
typedef void *Handle_t;/* memory pointer type */
-//typedef double FData_t;/* floating point data type
*/
#define MAX_UDATA (4294967295) /* max value storable in UData_t */
/*
-** Define an MT_CNT macro for each type of tuner that will be built
-** into your application (e.g., MT2121, MT2060). MT_TUNER_CNT
-** must be set to the SUM of all of the MT_CNT macros.
-**
-** #define MT2050_CNT (1)
-** #define MT2060_CNT (1)
-** #define MT2111_CNT (1)
-** #define MT2121_CNT (3)
-*/
+ * Define an MT_CNT macro for each type of tuner that will be built
+ * into your application (e.g., MT2121, MT2060). MT_TUNER_CNT
+ * must be set to the SUM of all of the MT_CNT macros.
+ *
+ * #define MT2050_CNT (1)
+ * #define MT2060_CNT (1)
+ * #define MT2111_CNT (1)
+ * #define MT2121_CNT (3)
+ */
#define MT2063_CNT (1)
@@ -142,22 +120,15 @@ void MT2063_Sleep(Handle_t hUserData, UData_t
nMinDelayTime);
UData_t MT2060_TunerGain(Handle_t hUserData, SData_t * pMeas);
#endif
#endif
-//end of mt2063_userdef.h
-//=
-//#
-//=
-
-//context of mt2063_spruavoid.h Henry ==
-//#
-//=
+
/*
-** Constant defining the version of the following structure
-** and therefore the API for this code.
-**
-** When compiling the tuner driver, the preprocessor will
-** check against this version number to make sure that
-** it matches the version that the tuner driver knows about.
-*/
+ * Constant defining the version of the following structure
+ * and therefore the API for this code.
+ *
+ * When compiling the tuner driver, the preprocessor will
+ * check against this version number to make sure that
+ * it matches the version that the tuner driver knows about.
+ */
/* Version 010201 = 1.21 */
#define MT2063_AVOID_SPURS_INFO_VERSION 010201
@@ -171,10 +142,10 @@ UData_t MT2060_TunerGain(Handle_t hUserData, SData_t *
pMeas);
#define MT2063_EXCLUDE_EURO_DECT_FREQUENCIES(s) (((s)
MT2063_DECT_AVOID_EURO_FREQS) != 0)
enum MT2063_DECT_Avoid_Type {
- MT2063_NO_DECT_AVOIDANCE = 0, /* Do not create DECT exclusion zones.
*/
+ MT2063_NO_DECT_AVOIDANCE = 0, /* Do not
create DECT exclusion zones. */
MT2063_AVOID_US_DECT = MT2063_DECT_AVOID_US_FREQS, /* Avoid US
DECT frequencies. */
MT2063_AVOID_EURO_DECT = MT2063_DECT_AVOID_EURO_FREQS, /* Avoid
European DECT frequencies.*/
- MT2063_AVOID_BOTH /* Avoid both regions. Not typically used. */
+ MT2063_AVOID_BOTH /* Avoid both
regions. Not typically used. */
};
#define MT2063_MAX_ZONES 48
@@ -188,8 +159,8 @@ struct MT2063_ExclZone_t {
};
/*
-**
[PATCH 04/47] [media] mt2063: Move code from mt2063_cfg.h
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 129 ++
drivers/media/common/tuners/mt2063_cfg.h | 122
2 files changed, 129 insertions(+), 122 deletions(-)
delete mode 100644 drivers/media/common/tuners/mt2063_cfg.h
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 0d64eb8..1d36e51 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -13,6 +13,135 @@
static unsigned int verbose;
module_param(verbose, int, 0644);
+
+/*/
+/* From drivers/media/common/tuners/mt2063_cfg.h */
+
+static unsigned int mt2063_setTune(struct dvb_frontend *fe, UData_t f_in,
+ UData_t bw_in,
+ enum MTTune_atv_standard tv_type)
+{
+ //return (int)MT_Tune_atv(h, f_in, bw_in, tv_type);
+
+ struct dvb_frontend_ops *frontend_ops = NULL;
+ struct dvb_tuner_ops *tuner_ops = NULL;
+ struct tuner_state t_state;
+ struct mt2063_state *mt2063State = fe-tuner_priv;
+ int err = 0;
+
+ t_state.frequency = f_in;
+ t_state.bandwidth = bw_in;
+ mt2063State-tv_type = tv_type;
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-set_state) {
+ if ((err =
+tuner_ops-set_state(fe, DVBFE_TUNER_FREQUENCY,
+ t_state)) 0) {
+ printk(%s: Invalid parameter\n, __func__);
+ return err;
+ }
+ }
+
+ return err;
+}
+
+static unsigned int mt2063_lockStatus(struct dvb_frontend *fe)
+{
+ struct dvb_frontend_ops *frontend_ops = fe-ops;
+ struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
+ struct tuner_state t_state;
+ int err = 0;
+
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-get_state) {
+ if ((err =
+tuner_ops-get_state(fe, DVBFE_TUNER_REFCLOCK,
+ t_state)) 0) {
+ printk(%s: Invalid parameter\n, __func__);
+ return err;
+ }
+ }
+ return err;
+}
+
+static unsigned int tuner_MT2063_Open(struct dvb_frontend *fe)
+{
+ struct dvb_frontend_ops *frontend_ops = fe-ops;
+ struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
+ struct tuner_state t_state;
+ int err = 0;
+
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-set_state) {
+ if ((err =
+tuner_ops-set_state(fe, DVBFE_TUNER_OPEN,
+ t_state)) 0) {
+ printk(%s: Invalid parameter\n, __func__);
+ return err;
+ }
+ }
+
+ return err;
+}
+
+static unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe)
+{
+ struct dvb_frontend_ops *frontend_ops = fe-ops;
+ struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
+ struct tuner_state t_state;
+ int err = 0;
+
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-set_state) {
+ if ((err =
+tuner_ops-set_state(fe, DVBFE_TUNER_SOFTWARE_SHUTDOWN,
+ t_state)) 0) {
+ printk(%s: Invalid parameter\n, __func__);
+ return err;
+ }
+ }
+
+ return err;
+}
+
+static unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe)
+{
+ struct dvb_frontend_ops *frontend_ops = fe-ops;
+ struct dvb_tuner_ops *tuner_ops = frontend_ops-tuner_ops;
+ struct tuner_state t_state;
+ int err = 0;
+
+ if (fe-ops)
+ frontend_ops = fe-ops;
+ if (frontend_ops-tuner_ops)
+ tuner_ops = frontend_ops-tuner_ops;
+ if (tuner_ops-set_state) {
+ if ((err =
+tuner_ops-set_state(fe, DVBFE_TUNER_CLEAR_POWER_MASKBITS,
+ t_state)) 0) {
+ printk(%s: Invalid parameter\n, __func__);
+ return err;
+ }
+ }
+
+ return err;
+}
+
+/*/
+
+
//i2c operation
static int mt2063_writeregs(struct mt2063_state *state, u8 reg1,
u8 * data, int len)
diff --git a/drivers/media/common/tuners/mt2063_cfg.h
[PATCH 07/47] [media] mt2063: Remove most of the #if's
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 89 ++
drivers/media/common/tuners/mt2063.h |8 ---
2 files changed, 4 insertions(+), 93 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index c8f0bfa..63d964a 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -247,16 +247,12 @@ u32 MT2063_WriteSub(void *hUserData,
*/
/* return status; */
-//#if !TUNER_CONTROL_BY_DRXK_DRIVER
fe-ops.i2c_gate_ctrl(fe, 1); //I2C bypass drxk3926 close i2c bridge
-//#endif
if (mt2063_writeregs(state, subAddress, pData, cnt) 0) {
status = MT2063_ERROR;
}
-//#if !TUNER_CONTROL_BY_DRXK_DRIVER
fe-ops.i2c_gate_ctrl(fe, 0); //I2C bypass drxk3926 close i2c bridge
-//#endif
return (status);
}
@@ -314,9 +310,7 @@ u32 MT2063_ReadSub(void *hUserData,
struct dvb_frontend *fe = hUserData;
struct mt2063_state *state = fe-tuner_priv;
u32 i = 0;
-//#if !TUNER_CONTROL_BY_DRXK_DRIVER
fe-ops.i2c_gate_ctrl(fe, 1); //I2C bypass drxk3926 close i2c bridge
-//#endif
for (i = 0; i cnt; i++) {
if (mt2063_read_regs(state, subAddress + i, pData + i, 1) 0) {
@@ -325,9 +319,7 @@ u32 MT2063_ReadSub(void *hUserData,
}
}
-//#if !TUNER_CONTROL_BY_DRXK_DRIVER
fe-ops.i2c_gate_ctrl(fe, 0); //I2C bypass drxk3926 close i2c bridge
-//#endif
return (status);
}
@@ -364,8 +356,6 @@ void MT2063_Sleep(void *hUserData, u32 nMinDelayTime)
msleep(nMinDelayTime);
}
-#if defined(MT2060_CNT)
-#if MT2060_CNT 0
/*
**
** Name: MT_TunerGain (MT2060 only)
@@ -407,8 +397,6 @@ u32 MT2060_TunerGain(void *hUserData, s32 * pMeas)
return (status);
}
-#endif
-#endif
//end of mt2063_userdef.c
//=
//#
@@ -458,14 +446,6 @@ u32 MT2060_TunerGain(void *hUserData, s32 * pMeas)
**
*/
-#if !defined(MT2063_TUNER_CNT)
-#error MT2063_TUNER_CNT is not defined (see mt_userdef.h)
-#endif
-
-#if MT2063_TUNER_CNT == 0
-#error MT2063_TUNER_CNT must be updated in mt_userdef.h
-#endif
-
/* Version of this module */
#define MT2063_SPUR_VERSION 10201 /* Version 01.21 */
@@ -1437,17 +1417,6 @@ u32 MT2063_AvoidSpursVersion(void)
** If the version is different, an updated file is needed from Microtune
*/
/* Expecting version 1.21 of the Spur Avoidance API */
-#define EXPECTED_MT2063_AVOID_SPURS_INFO_VERSION 010201
-
-#if MT2063_AVOID_SPURS_INFO_VERSION EXPECTED_MT2063_AVOID_SPURS_INFO_VERSION
-#error Contact Microtune for a newer version of MT_SpurAvoid.c
-#elif MT2063_AVOID_SPURS_INFO_VERSION
EXPECTED_MT2063_AVOID_SPURS_INFO_VERSION
-#error Contact Microtune for a newer version of mt2063.c
-#endif
-
-#ifndef MT2063_CNT
-#error You must define MT2063_CNT in the mt_userdef.h file
-#endif
typedef enum {
MT2063_SET_ATTEN,
@@ -1493,9 +1462,9 @@ static const u32 MT2063_Num_Registers =
MT2063_REG_END_REGS;
#define USE_GLOBAL_TUNER 0
-static u32 nMT2063MaxTuners = MT2063_CNT;
-static struct MT2063_Info_t MT2063_Info[MT2063_CNT];
-static struct MT2063_Info_t *MT2063_Avail[MT2063_CNT];
+static u32 nMT2063MaxTuners = 1;
+static struct MT2063_Info_t MT2063_Info[1];
+static struct MT2063_Info_t *MT2063_Avail[1];
static u32 nMT2063OpenTuners = 0;
/*
@@ -1591,51 +1560,6 @@ u32 MT2063_Open(u32 MT2063_Addr, void ** hMT2063, void
*hUserData)
/* Default tuner handle to NULL. If successful, it will be reassigned
*/
-#if USE_GLOBAL_TUNER
- *hMT2063 = NULL;
-
- /*
-** If this is our first tuner, initialize the address fields and
-** the list of available control blocks.
-*/
- if (nMT2063OpenTuners == 0) {
- for (i = MT2063_CNT - 1; i = 0; i--) {
- MT2063_Info[i].handle = NULL;
- MT2063_Info[i].address = MAX_UDATA;
- MT2063_Info[i].rcvr_mode = MT2063_CABLE_QAM;
- MT2063_Info[i].hUserData = NULL;
- MT2063_Avail[i] = MT2063_Info[i];
- }
- }
-
- /*
-** Look for an existing MT2063_State_t entry with this address.
-*/
- for (i = MT2063_CNT - 1; i = 0; i--) {
- /*
-** If an open'ed handle provided, we'll re-initialize that
structure.
-**
-** We recognize an open tuner because the address and
hUserData are
-** the same as one that has already been opened
-
[PATCH 27/47] [media] mt2063: Remove setParm/getParm abstraction layer
This layer just increases the code size for no good reason,
and makes harder to debug.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 1130 +-
drivers/media/common/tuners/mt2063.h |2 +-
2 files changed, 172 insertions(+), 960 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 0bf6292..f9ebe24 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -110,74 +110,6 @@ enum MT2063_Mask_Bits {
};
/*
- * Parameter for function MT2063_GetParam MT2063_SetParam that
- * specifies the tuning algorithm parameter to be read/written.
- */
-enum MT2063_Param {
- /* min tuning step size(default: 5 Hz)
*/
- MT2063_STEPSIZE,
-
- /* input center frequency set by MT2063_Tune()
*/
- MT2063_INPUT_FREQ,
-
- /* LO1 Frequency set by MT2063_Tune()
*/
- MT2063_LO1_FREQ,
-
- /* LO2 Frequency set by MT2063_Tune()
*/
- MT2063_LO2_FREQ,
-
- /* output center frequencyset by MT2063_Tune()
*/
- MT2063_OUTPUT_FREQ,
-
- /* output bandwidth set by MT2063_Tune()
*/
- MT2063_OUTPUT_BW,
-
- /* Receiver Mode for some parameters. 1 is DVB-T
*/
- MT2063_RCVR_MODE,
-
- /* directly set LNA attenuation, parameter is value to set
*/
- MT2063_ACLNA,
-
- /* maximum LNA attenuation, parameter is value to set
*/
- MT2063_ACLNA_MAX,
-
- /* directly set ATN attenuation. Paremeter is value to set.
*/
- MT2063_ACRF,
-
- /* maxium ATN attenuation. Paremeter is value to set.
*/
- MT2063_ACRF_MAX,
-
- /* directly set FIF attenuation. Paremeter is value to set.
*/
- MT2063_ACFIF,
-
- /* maxium FIF attenuation. Paremeter is value to set.
*/
- MT2063_ACFIF_MAX,
-
- /* LNA Rin
*/
- MT2063_LNA_RIN,
-
- /* Power Detector LNA level target
*/
- MT2063_LNA_TGT,
-
- /* Power Detector 1 level
*/
- MT2063_PD1,
-
- /* Power Detector 1 level target
*/
- MT2063_PD1_TGT,
-
- /* Power Detector 2 level
*/
- MT2063_PD2,
-
- /* Power Detector 2 level target
*/
- MT2063_PD2_TGT,
-
- /* Selects, which DNC is activ
*/
- MT2063_DNC_OUTPUT_ENABLE,
-
- MT2063_EOP /* last entry in enumerated list */
-};
-
-/*
* Parameter for selecting tuner mode
*/
enum MT2063_RCVR_MODES {
@@ -311,11 +243,7 @@ struct mt2063_state {
/* Prototypes */
static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
u32 f_min, u32 f_max);
-static u32 MT2063_GetReg(struct mt2063_state *state, u8 reg, u8 * val);
-static u32 MT2063_GetParam(struct mt2063_state *state, enum MT2063_Param
param, u32 * pValue);
static u32 MT2063_SetReg(struct mt2063_state *state, u8 reg, u8 val);
-static u32 MT2063_SetParam(struct mt2063_state *state, enum MT2063_Param param,
- enum MT2063_DNC_Output_Enable nValue);
static u32 MT2063_SoftwareShutdown(struct mt2063_state *state, u8 Shutdown);
static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state, enum
MT2063_Mask_Bits Bits);
@@ -1156,371 +1084,152 @@ unsigned int mt2063_lockStatus(struct mt2063_state
*state)
}
EXPORT_SYMBOL_GPL(mt2063_lockStatus);
-/
-**
-** Name: MT2063_GetParam
-**
-** Description:Gets a tuning algorithm parameter.
-**
-** This function provides access to the internals of the
-** tuning algorithm - mostly for testing purposes.
-**
-** Parameters: h - Tuner handle (returned by MT2063_Open)
-** param - Tuning algorithm parameter
-**(see enum MT2063_Param)
-** pValue - ptr to returned value
-**
-** param Description
-** --
-** MT2063_IC_ADDRSerial Bus address of this tuner
-** MT2063_SRO_FREQ crystal frequency
-** MT2063_STEPSIZE minimum tuning step size
-** MT2063_INPUT_FREQ input center
[PATCH 47/47] [media] drxk: Add support for parallel mode and prints mpeg mode
While the driver has support for both serial and parallel mode,
There's was way to select serial mode via configuration. Add
a config option for that, while keeping the default in serial mode.
Also, at debug mode, it will now print a message when mpeg is
enabled/disabled, and showing if parallel or serial mode were
selected, helping developers to double-check if the DRX-K is at
the right mode.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk.h |3 +++
drivers/media/dvb/frontends/drxk_hard.c | 14 --
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk.h
b/drivers/media/dvb/frontends/drxk.h
index e6d42e2..870432f 100644
--- a/drivers/media/dvb/frontends/drxk.h
+++ b/drivers/media/dvb/frontends/drxk.h
@@ -8,6 +8,8 @@
* struct drxk_config - Configure the initial parameters for DRX-K
*
* adr:I2C Address of the DRX-K
+ * parallel_ts:true means that the device uses parallel TS,
+ * Serial otherwise.
* single_master: Device is on the single master mode
* no_i2c_bridge: Don't switch the I2C bridge to talk with tuner
* antenna_gpio: GPIO bit used to control the antenna
@@ -22,6 +24,7 @@ struct drxk_config {
u8 adr;
boolsingle_master;
boolno_i2c_bridge;
+ boolparallel_ts;
boolantenna_dvbt;
u16 antenna_gpio;
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 817d3ec..c8213f6 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -660,7 +660,6 @@ static int init_state(struct drxk_state *state)
/* io_pad_cfg_mode output mode is drive always */
/* io_pad_cfg_drive is set to power 2 (23 mA) */
u32 ulGPIOCfg = 0x0113;
- u32 ulSerialMode = 1;
u32 ulInvertTSClock = 0;
u32 ulTSDataStrength = DRXK_MPEG_SERIAL_OUTPUT_PIN_DRIVE_STRENGTH;
u32 ulTSClockkStrength = DRXK_MPEG_OUTPUT_CLK_DRIVE_STRENGTH;
@@ -811,8 +810,6 @@ static int init_state(struct drxk_state *state)
/* MPEG output configuration */
state-m_enableMPEGOutput = true; /* If TRUE; enable MPEG ouput */
state-m_insertRSByte = false; /* If TRUE; insert RS byte */
- state-m_enableParallel = true; /* If TRUE;
- parallel out otherwise serial */
state-m_invertDATA = false;/* If TRUE; invert DATA signals */
state-m_invertERR = false; /* If TRUE; invert ERR signal */
state-m_invertSTR = false; /* If TRUE; invert STR signals */
@@ -857,8 +854,6 @@ static int init_state(struct drxk_state *state)
state-m_bPowerDown = false;
state-m_currentPowerMode = DRX_POWER_DOWN;
- state-m_enableParallel = (ulSerialMode == 0);
-
state-m_rfmirror = (ulRfMirror == 0);
state-m_IfAgcPol = false;
return 0;
@@ -1195,7 +1190,9 @@ static int MPEGTSConfigurePins(struct drxk_state *state,
bool mpegEnable)
u16 sioPdrMclkCfg = 0;
u16 sioPdrMdxCfg = 0;
- dprintk(1, \n);
+ dprintk(1, : mpeg %s, %s mode\n,
+ mpegEnable ? enable : disable,
+ state-m_enableParallel ? parallel : serial);
/* stop lock indicator process */
status = write16(state, SCU_RAM_GPIO__A,
SCU_RAM_GPIO_HW_LOCK_IND_DISABLE);
@@ -6432,6 +6429,11 @@ struct dvb_frontend *drxk_attach(const struct
drxk_config *config,
state-antenna_dvbt = config-antenna_dvbt;
state-m_ChunkSize = config-chunk_size;
+ if (config-parallel_ts)
+ state-m_enableParallel = true;
+ else
+ state-m_enableParallel = false;
+
/* NOTE: as more UIO bits will be used, add them to the mask */
state-UIO_mask = config-antenna_gpio;
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 32/47] [media] mt2063: Fix comments
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 959 +-
1 files changed, 370 insertions(+), 589 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 4f634ad..181deac 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -1,3 +1,22 @@
+/*
+ * Driver for mt2063 Micronas tuner
+ *
+ * Copyright (c) 2011 Mauro Carvalho Chehab mche...@redhat.com
+ *
+ * This driver came from a driver originally written by Henry, made available
+ * by Terratec, at:
+ *
http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz
+ *
+ * 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 under version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
#include linux/init.h
#include linux/kernel.h
#include linux/module.h
@@ -89,8 +108,8 @@ struct MT2063_AvoidSpursData_t {
};
/*
- * Parameter for function MT2063_SetPowerMask that specifies the power down
- * of various sections of the MT2063.
+ * Parameter for function MT2063_SetPowerMask that specifies the power down
+ * of various sections of the MT2063.
*/
enum MT2063_Mask_Bits {
MT2063_REG_SD = 0x0040, /* Shutdown regulator */
@@ -134,9 +153,9 @@ enum MT2063_DNC_Output_Enable {
};
/*
-** Two-wire serial bus subaddresses of the tuner registers.
-** Also known as the tuner's register addresses.
-*/
+ * Two-wire serial bus subaddresses of the tuner registers.
+ * Also known as the tuner's register addresses.
+ */
enum MT2063_Register_Offsets {
MT2063_REG_PART_REV = 0,/* 0x00: Part/Rev Code */
MT2063_REG_LO1CQ_1, /* 0x01: LO1C Queued Byte 1*/
@@ -320,8 +339,7 @@ static u32 mt2063_read(struct mt2063_state *state,
static int MT2063_Sleep(struct dvb_frontend *fe)
{
/*
-** ToDo: Add code here to implement a OS blocking
-** for a period of nMinDelayTime milliseconds.
+* ToDo: Add code here to implement a OS blocking
*/
msleep(10);
@@ -391,23 +409,14 @@ static struct MT2063_ExclZone_t *RemoveNode(struct
MT2063_AvoidSpursData_t
return pNext;
}
-/*
-**
-** Name: MT_AddExclZone
-**
-** Description:Add (and merge) an exclusion zone into the list.
-** If the range (f_min, f_max) is totally outside the
-** 1st IF BW, ignore the entry.
-** If the range (f_min, f_max) is negative, ignore the entry.
-**
-** Revision History:
-**
-** SCR Date Author Description
-** -
-** 103 01-31-2005DADVer 1.14: In MT_AddExclZone(), if the range
-** (f_min, f_max) 0, ignore the entry.
-**
-*/
+/*
+ * MT_AddExclZone()
+ *
+ * Add (and merge) an exclusion zone into the list.
+ * If the range (f_min, f_max) is totally outside the
+ * 1st IF BW, ignore the entry.
+ * If the range (f_min, f_max) is negative, ignore the entry.
+ */
static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
u32 f_min, u32 f_max)
{
@@ -420,11 +429,11 @@ static void MT2063_AddExclZone(struct
MT2063_AvoidSpursData_t *pAS_Info,
(f_min (pAS_Info-f_if1_Center + (pAS_Info-f_if1_bw / 2)))
(f_min f_max)) {
/*
-**1 2 34 5
6
-**
-** New entry: |---||--||--| |-|
|---| |--|
-** or oror or
or
-** Existing: |--| |--| |--||---| |-|
|--|
+*12 3 4 56
+*
+* New entry: |---||--| |--||-||---||--|
+*or oror or or
+* Existing: |--| |--| |--||---| |-| |--|
*/
/* Check for our place in the list */
@@ -450,18 +459,16 @@ static void MT2063_AddExclZone(struct
MT2063_AvoidSpursData_t *pAS_Info,
while ((pNext != NULL) (pNext-min_ pNode-max_)) {
if (pNext-max_ pNode-max_)
[PATCH 46/47] [media] drxk: Improve a few debug messages
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/dvb/frontends/drxk_hard.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/frontends/drxk_hard.c
b/drivers/media/dvb/frontends/drxk_hard.c
index 67a1e39..817d3ec 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -368,10 +368,10 @@ static int i2c_read(struct i2c_adapter *adap,
}
if (debug 2) {
int i;
- dprintk(2, : read from );
+ dprintk(2, : read from);
for (i = 0; i len; i++)
printk(KERN_CONT %02x, msg[i]);
- printk(KERN_CONT Value = );
+ printk(KERN_CONT , value = );
for (i = 0; i alen; i++)
printk(KERN_CONT %02x, answ[i]);
printk(KERN_CONT \n);
@@ -947,6 +947,9 @@ static int GetDeviceCapabilities(struct drxk_state *state)
status = read32(state, SIO_TOP_JTAGID_LO__A, sioTopJtagidLo);
if (status 0)
goto error;
+
+printk(KERN_ERR drxk: status = 0x%08x\n, sioTopJtagidLo);
+
/* driver 0.9.0 */
switch ((sioTopJtagidLo 29) 0xF) {
case 0:
@@ -964,7 +967,8 @@ static int GetDeviceCapabilities(struct drxk_state *state)
default:
state-m_deviceSpin = DRXK_SPIN_UNKNOWN;
status = -EINVAL;
- printk(KERN_ERR drxk: Spin unknown\n);
+ printk(KERN_ERR drxk: Spin %d unknown\n,
+ (sioTopJtagidLo 29) 0xF);
goto error2;
}
switch ((sioTopJtagidLo 12) 0xFF) {
@@ -6452,6 +6456,8 @@ struct dvb_frontend *drxk_attach(const struct drxk_config
*config,
goto error;
*fe_t = state-t_frontend;
+ printk(KERN_INFO drxk: frontend initialized.\n);
+
return state-c_frontend;
error:
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 44/47] [media] mt2063: Add support for get_if_frequency()
get_if_frequency() is needed, in order to work with DRX-K.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 6f14ee3..98020a9 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -2190,7 +2190,7 @@ static int mt2063_set_params(struct dvb_frontend *fe)
return 0;
}
-static int mt2063_get_frequency(struct dvb_frontend *fe, u32 *freq)
+static int mt2063_get_if_frequency(struct dvb_frontend *fe, u32 *freq)
{
struct mt2063_state *state = fe-tuner_priv;
@@ -2199,9 +2199,9 @@ static int mt2063_get_frequency(struct dvb_frontend *fe,
u32 *freq)
if (!state-init)
return -ENODEV;
- *freq = state-frequency;
+ *freq = state-reference * 1000;
- dprintk(1, frequency: %d\n, *freq);
+ dprintk(1, IF frequency: %d\n, *freq);
return 0;
}
@@ -2235,7 +2235,7 @@ static struct dvb_tuner_ops mt2063_ops = {
.get_status = mt2063_get_status,
.set_analog_params = mt2063_set_analog_params,
.set_params= mt2063_set_params,
- .get_frequency = mt2063_get_frequency,
+ .get_if_frequency = mt2063_get_if_frequency,
.get_bandwidth = mt2063_get_bandwidth,
.release = mt2063_release,
};
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 43/47] [media] mt2063: add some useful info for the dvb callback calls
The per-delivery system tables are confusing.
Add an extra table that explains them, and some
dprintk calls, that allows to check if mt2063 driver
is working as expected.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 68 +++--
1 files changed, 47 insertions(+), 21 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index de45c9d..6f14ee3 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -1008,29 +1008,38 @@ static unsigned int mt2063_lockStatus(struct
mt2063_state *state)
*/
enum mt2063_delivery_sys {
- MT2063_CABLE_QAM = 0, /* Digital cable */
- MT2063_CABLE_ANALOG,/* Analog cable */
- MT2063_OFFAIR_COFDM,/* Digital offair */
- MT2063_OFFAIR_COFDM_SAWLESS,/* Digital offair without SAW */
- MT2063_OFFAIR_ANALOG, /* Analog offair */
- MT2063_OFFAIR_8VSB, /* Analog offair */
+ MT2063_CABLE_QAM = 0,
+ MT2063_CABLE_ANALOG,
+ MT2063_OFFAIR_COFDM,
+ MT2063_OFFAIR_COFDM_SAWLESS,
+ MT2063_OFFAIR_ANALOG,
+ MT2063_OFFAIR_8VSB,
MT2063_NUM_RCVR_MODES
};
-static const u8 RFAGCEN[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 LNARIN[] = { 0, 0, 3, 3, 3, 3 };
-static const u8 FIFFQEN[] = { 1, 1, 1, 1, 1, 1 };
-static const u8 FIFFQ[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 DNC1GC[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 DNC2GC[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACLNAMAX[] = { 31, 31, 31, 31, 31, 31 };
-static const u8 LNATGT[] = { 44, 43, 43, 43, 43, 43 };
-static const u8 RFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACRFMAX[] = { 31, 31, 31, 31, 31, 31 };
-static const u8 PD1TGT[] = { 36, 36, 38, 38, 36, 38 };
-static const u8 FIFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACFIFMAX[] = { 29, 29, 29, 29, 29, 29 };
-static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
+static const char *mt2063_mode_name[] = {
+ [MT2063_CABLE_QAM] = digital cable,
+ [MT2063_CABLE_ANALOG] = analog cable,
+ [MT2063_OFFAIR_COFDM] = digital offair,
+ [MT2063_OFFAIR_COFDM_SAWLESS] = digital offair without SAW,
+ [MT2063_OFFAIR_ANALOG] = analog offair,
+ [MT2063_OFFAIR_8VSB]= analog offair 8vsb,
+};
+
+static const u8 RFAGCEN[] = { 0, 0, 0, 0, 0, 0 };
+static const u8 LNARIN[] = { 0, 0, 3, 3, 3, 3 };
+static const u8 FIFFQEN[] = { 1, 1, 1, 1, 1, 1 };
+static const u8 FIFFQ[]= { 0, 0, 0, 0, 0, 0 };
+static const u8 DNC1GC[] = { 0, 0, 0, 0, 0, 0 };
+static const u8 DNC2GC[] = { 0, 0, 0, 0, 0, 0 };
+static const u8 ACLNAMAX[] = { 31, 31, 31, 31, 31, 31 };
+static const u8 LNATGT[] = { 44, 43, 43, 43, 43, 43 };
+static const u8 RFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
+static const u8 ACRFMAX[] = { 31, 31, 31, 31, 31, 31 };
+static const u8 PD1TGT[] = { 36, 36, 38, 38, 36, 38 };
+static const u8 FIFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
+static const u8 ACFIFMAX[] = { 29, 29, 29, 29, 29, 29 };
+static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
/*
* mt2063_set_dnc_output_enable()
@@ -1315,8 +1324,11 @@ static u32 MT2063_SetReceiverMode(struct mt2063_state
*state,
status |= mt2063_setreg(state, MT2063_REG_PD1_TGT, val);
}
- if (status = 0)
+ if (status = 0) {
state-rcvr_mode = Mode;
+ dprintk(1, mt2063 mode changed to %s\n,
+ mt2063_mode_name[state-rcvr_mode]);
+ }
return status;
}
@@ -2023,6 +2035,8 @@ static int mt2063_get_status(struct dvb_frontend *fe, u32
*tuner_status)
if (status)
*tuner_status = TUNER_STATUS_LOCKED;
+ dprintk(1, Tuner status: %d, *tuner_status);
+
return 0;
}
@@ -2092,6 +2106,9 @@ static int mt2063_set_analog_params(struct dvb_frontend
*fe,
if (status 0)
return status;
+ dprintk(1, Tuning to frequency: %d, bandwidth %d, foffset %d\n,
+ params-frequency, ch_bw, pict2chanb_vsb);
+
status = MT2063_Tune(state, (params-frequency + (pict2chanb_vsb +
(ch_bw / 2;
if (status 0)
return status;
@@ -2161,6 +2178,9 @@ static int mt2063_set_params(struct dvb_frontend *fe)
if (status 0)
return status;
+ dprintk(1, Tuning to frequency: %d, bandwidth %d, foffset %d\n,
+ c-frequency, ch_bw, pict2chanb_vsb);
+
status = MT2063_Tune(state, (c-frequency + (pict2chanb_vsb + (ch_bw /
2;
if (status 0)
@@ -2180,6 +2200,9 @@ static int mt2063_get_frequency(struct dvb_frontend *fe,
u32 *freq)
return
[PATCH 41/47] [media] mt2063: Fix i2c read message
While here, improve a few debug messages that helped to track the
issue and may be useful in the future.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index fdf6050..599f864 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -305,35 +305,40 @@ static u32 mt2063_read(struct mt2063_state *state,
struct dvb_frontend *fe = state-frontend;
u32 i = 0;
- dprintk(2, \n);
+ dprintk(2, addr 0x%02x, cnt %d\n, subAddress, cnt);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
for (i = 0; i cnt; i++) {
- int ret;
u8 b0[] = { subAddress + i };
struct i2c_msg msg[] = {
{
.addr = state-config-tuner_address,
- .flags = I2C_M_RD,
+ .flags = 0,
.buf = b0,
.len = 1
}, {
.addr = state-config-tuner_address,
.flags = I2C_M_RD,
- .buf = pData + 1,
+ .buf = pData + i,
.len = 1
}
};
- ret = i2c_transfer(state-i2c, msg, 2);
- if (ret 0)
+ status = i2c_transfer(state-i2c, msg, 2);
+ dprintk(2, addr 0x%02x, ret = %d, val = 0x%02x\n,
+ subAddress + i, status, *(pData + i));
+ if (status 0)
break;
}
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
+ if (status 0)
+ printk(KERN_ERR Can't read from address 0x%02x,\n,
+ subAddress + i);
+
return status;
}
@@ -1801,7 +1806,8 @@ static int mt2063_init(struct dvb_frontend *fe)
state-rcvr_mode = MT2063_CABLE_QAM;
/* Read the Part/Rev code from the tuner */
- status = mt2063_read(state, MT2063_REG_PART_REV, state-reg, 1);
+ status = mt2063_read(state, MT2063_REG_PART_REV,
+state-reg[MT2063_REG_PART_REV], 1);
if (status 0) {
printk(KERN_ERR Can't read mt2063 part ID\n);
return status;
@@ -1833,7 +1839,9 @@ static int mt2063_init(struct dvb_frontend *fe)
/* b7 != 0 == NOT MT2063 */
if (status 0 || ((state-reg[MT2063_REG_RSVD_3B] 0x80) != 0x00)) {
- printk(KERN_ERR mt2063: Unknown 2nd part ID\n);
+ printk(KERN_ERR mt2063: Unknown part ID (0x%02x%02x)\n,
+ state-reg[MT2063_REG_PART_REV],
+ state-reg[MT2063_REG_RSVD_3B]);
return -ENODEV; /* Wrong tuner Part/Rev code */
}
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 42/47] [media] mt2063: print the detected version
Instead of printing it just for debug purposes, outputs the detected version at the logs. This may be useful if someone wants to report a problem. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/mt2063.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/media/common/tuners/mt2063.c b/drivers/media/common/tuners/mt2063.c index 599f864..de45c9d 100644 --- a/drivers/media/common/tuners/mt2063.c +++ b/drivers/media/common/tuners/mt2063.c @@ -1845,8 +1845,7 @@ static int mt2063_init(struct dvb_frontend *fe) return -ENODEV; /* Wrong tuner Part/Rev code */ } - dprintk(1, Discovered a mt2063 %s (2nd part number 0x%02x)\n, - step, state-reg[MT2063_REG_RSVD_3B]); + printk(KERN_INFO mt2063: detected a mt2063 %s\n, step); /* Reset the tuner */ status = mt2063_write(state, MT2063_REG_LO2CQ_3, all_resets, 1); -- 1.7.7.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 36/47] [media] mt2063: Add some debug printk's
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 76 ++
1 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 75cb1d2..cd67417 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -27,8 +27,15 @@
#include mt2063.h
-static unsigned int verbose;
-module_param(verbose, int, 0644);
+static unsigned int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Set Verbosity level);
+
+#define dprintk(level, fmt, arg...) do { \
+if (debug = level)\
+ printk(KERN_DEBUG mt2063 %s: fmt, __func__, ## arg); \
+} while (0)
+
/* positive error codes used internally */
@@ -248,6 +255,8 @@ static u32 mt2063_write(struct mt2063_state *state, u8 reg,
u8 *data, u32 len)
.len = len + 1
};
+ dprintk(2, \n);
+
msg.buf[0] = reg;
memcpy(msg.buf + 1, data, len);
@@ -270,6 +279,8 @@ static u32 mt2063_setreg(struct mt2063_state *state, u8
reg, u8 val)
{
u32 status;
+ dprintk(2, \n);
+
if (reg = MT2063_REG_END_REGS)
return -ERANGE;
@@ -292,6 +303,8 @@ static u32 mt2063_read(struct mt2063_state *state,
struct dvb_frontend *fe = state-frontend;
u32 i = 0;
+ dprintk(2, \n);
+
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
@@ -353,6 +366,9 @@ static struct MT2063_ExclZone_t *InsertNode(struct
MT2063_AvoidSpursData_t
struct MT2063_ExclZone_t *pPrevNode)
{
struct MT2063_ExclZone_t *pNode;
+
+ dprintk(2, \n);
+
/* Check for a node in the free list */
if (pAS_Info-freeZones != NULL) {
/* Use one from the free list */
@@ -384,6 +400,8 @@ static struct MT2063_ExclZone_t *RemoveNode(struct
MT2063_AvoidSpursData_t
{
struct MT2063_ExclZone_t *pNext = pNodeToRemove-next_;
+ dprintk(2, \n);
+
/* Make previous node point to the subsequent node */
if (pPrevNode != NULL)
pPrevNode-next_ = pNext;
@@ -413,6 +431,8 @@ static void MT2063_AddExclZone(struct
MT2063_AvoidSpursData_t *pAS_Info,
struct MT2063_ExclZone_t *pPrev = NULL;
struct MT2063_ExclZone_t *pNext = NULL;
+ dprintk(2, \n);
+
/* Check to see if this overlaps the 1st IF filter */
if ((f_max (pAS_Info-f_if1_Center - (pAS_Info-f_if1_bw / 2)))
(f_min (pAS_Info-f_if1_Center + (pAS_Info-f_if1_bw / 2)))
@@ -462,6 +482,8 @@ static void MT2063_ResetExclZones(struct
MT2063_AvoidSpursData_t *pAS_Info)
{
u32 center;
+ dprintk(2, \n);
+
pAS_Info-nZones = 0; /* this clears the used list */
pAS_Info-usedZones = NULL; /* reset ptr */
pAS_Info-freeZones = NULL; /* reset ptr */
@@ -547,7 +569,6 @@ static u32 MT2063_ChooseFirstIF(struct
MT2063_AvoidSpursData_t *pAS_Info)
pAS_Info-f_LO2_Step) ? pAS_Info-f_LO1_Step : pAS_Info-
f_LO2_Step;
u32 f_Center;
-
s32 i;
s32 j = 0;
u32 bDesiredExcluded = 0;
@@ -557,6 +578,8 @@ static u32 MT2063_ChooseFirstIF(struct
MT2063_AvoidSpursData_t *pAS_Info)
struct MT2063_ExclZone_t *pNode = pAS_Info-usedZones;
struct MT2063_FIFZone_t zones[MT2063_MAX_ZONES];
+ dprintk(2, \n);
+
if (pAS_Info-nZones == 0)
return f_Desired;
@@ -692,6 +715,9 @@ static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t
*pAS_Info,
s32 f_Spur;
u32 ma, mb, mc, md, me, mf;
u32 lo_gcd, gd_Scale, gc_Scale, gf_Scale, hgds, hgfs, hgcs;
+
+ dprintk(2, \n);
+
*fm = 0;
/*
@@ -788,6 +814,8 @@ static u32 MT2063_AvoidSpurs(struct MT2063_AvoidSpursData_t
*pAS_Info)
pAS_Info-bSpurAvoided = 0;
pAS_Info-nSpursFound = 0;
+ dprintk(2, \n);
+
if (pAS_Info-maxH1 == 0)
return 0;
@@ -910,6 +938,8 @@ static unsigned int mt2063_lockStatus(struct mt2063_state
*state)
u32 status;
u32 nDelays = 0;
+ dprintk(2, \n);
+
/* LO2 Lock bit was in a different place for B0 version */
if (state-tuner_id == MT2063_B0)
LO2LK = 0x40;
@@ -1001,6 +1031,8 @@ static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
static u32 mt2063_get_dnc_output_enable(struct mt2063_state *state,
enum MT2063_DNC_Output_Enable *pValue)
{
+ dprintk(2, \n);
+
if ((state-reg[MT2063_REG_DNC_GAIN] 0x03) == 0x03) { /* if DNC1 is
off */
if ((state-reg[MT2063_REG_VGA_GAIN] 0x03) == 0x03) /* if
DNC2 is off */
*pValue = MT2063_DNC_NONE;
@@ -1024,6
[PATCH 31/47] [media] mt2063: Fix analog/digital set params logic
The driver were using a hacky way of setting analog and digital
frequencies. Remove the hack and properly add the tuner logic for
each supported type of standard.
I was tempted to add more standards there, like SECAM and to fix
radio (as stepping seems broken), but I opted to keep it as-is,
as tests would be needed to add additional standards.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 390 +-
drivers/media/common/tuners/mt2063.h |1 -
2 files changed, 190 insertions(+), 201 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 5154b9d..4f634ad 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -2,6 +2,7 @@
#include linux/kernel.h
#include linux/module.h
#include linux/string.h
+#include linux/videodev2.h
#include mt2063.h
@@ -201,21 +202,6 @@ enum MT2063_Register_Offsets {
MT2063_REG_END_REGS
};
-enum MTTune_atv_standard {
- MTTUNEA_UNKNOWN = 0,
- MTTUNEA_PAL_B,
- MTTUNEA_PAL_G,
- MTTUNEA_PAL_I,
- MTTUNEA_PAL_L,
- MTTUNEA_PAL_MN,
- MTTUNEA_PAL_DK,
- MTTUNEA_DIGITAL,
- MTTUNEA_FMRADIO,
- MTTUNEA_DVBC,
- MTTUNEA_DVBT
-};
-
-
struct mt2063_state {
struct i2c_adapter *i2c;
@@ -224,7 +210,6 @@ struct mt2063_state {
struct dvb_frontend *frontend;
struct tuner_state status;
- enum MTTune_atv_standard tv_type;
u32 frequency;
u32 srate;
u32 bandwidth;
@@ -258,9 +243,11 @@ static u32 mt2063_write(struct mt2063_state *state, u8
reg, u8 *data, u32 len)
msg.buf[0] = reg;
memcpy(msg.buf + 1, data, len);
- fe-ops.i2c_gate_ctrl(fe, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
ret = i2c_transfer(state-i2c, msg, 1);
- fe-ops.i2c_gate_ctrl(fe, 0);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
if (ret 0)
printk(KERN_ERR %s error ret=%d\n, __func__, ret);
@@ -297,7 +284,8 @@ static u32 mt2063_read(struct mt2063_state *state,
struct dvb_frontend *fe = state-frontend;
u32 i = 0;
- fe-ops.i2c_gate_ctrl(fe, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
for (i = 0; i cnt; i++) {
int ret;
@@ -320,7 +308,9 @@ static u32 mt2063_read(struct mt2063_state *state,
if (ret 0)
break;
}
- fe-ops.i2c_gate_ctrl(fe, 0);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+
return status;
}
@@ -997,7 +987,7 @@ static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
*
* This function returns 0, if no lock, 1 if locked and a value 1 if error
*/
-unsigned int mt2063_lockStatus(struct mt2063_state *state)
+static unsigned int mt2063_lockStatus(struct mt2063_state *state)
{
const u32 nMaxWait = 100; /* wait a maximum of 100 msec */
const u32 nPollRate = 2;/* poll status bits every 2 ms */
@@ -1030,7 +1020,6 @@ unsigned int mt2063_lockStatus(struct mt2063_state *state)
*/
return 0;
}
-EXPORT_SYMBOL_GPL(mt2063_lockStatus);
/*
* mt2063_set_dnc_output_enable()
@@ -1922,132 +1911,6 @@ static u32 MT2063_Tune(struct mt2063_state *state, u32
f_in)
return status;
}
-int mt2063_setTune(struct dvb_frontend *fe, u32 f_in, u32 bw_in,
- enum MTTune_atv_standard tv_type)
-{
- struct mt2063_state *state = fe-tuner_priv;
- u32 status = 0;
- s32 pict_car = 0;
- s32 pict2chanb_vsb = 0;
- s32 pict2chanb_snd = 0;
- s32 pict2snd1 = 0;
- s32 pict2snd2 = 0;
- s32 ch_bw = 0;
- s32 if_mid = 0;
- s32 rcvr_mode = 0;
-
- switch (tv_type) {
- case MTTUNEA_PAL_B:{
- pict_car = 3890;
- ch_bw = 800;
- pict2chanb_vsb = -125;
- pict2snd1 = 550;
- pict2snd2 = 5742000;
- rcvr_mode = 1;
- break;
- }
- case MTTUNEA_PAL_G:{
- pict_car = 3890;
- ch_bw = 700;
- pict2chanb_vsb = -125;
- pict2snd1 = 550;
- pict2snd2 = 0;
- rcvr_mode = 1;
- break;
- }
- case MTTUNEA_PAL_I:{
- pict_car = 3890;
- ch_bw = 800;
- pict2chanb_vsb = -125;
- pict2snd1 = 600;
- pict2snd2 = 0;
- rcvr_mode = 1;
- break;
- }
- case MTTUNEA_PAL_L:{
-
[PATCH 39/47] [media] mt2063: don't crash if device is not initialized
Instead of crash, return -ENODEV, if the device is not poperly
initialized.
Also, give a second chance for it to initialize, at set_params
calls.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 92653a9..db347d9 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -220,6 +220,8 @@ enum MT2063_Register_Offsets {
struct mt2063_state {
struct i2c_adapter *i2c;
+ bool init;
+
const struct mt2063_config *config;
struct dvb_tuner_ops ops;
struct dvb_frontend *frontend;
@@ -1974,6 +1976,8 @@ static int mt2063_init(struct dvb_frontend *fe)
if (status 0)
return status;
+ state-init = true;
+
return 0;
}
@@ -1984,6 +1988,9 @@ static int mt2063_get_status(struct dvb_frontend *fe, u32
*tuner_status)
dprintk(2, \n);
+ if (!state-init)
+ return -ENODEV;
+
*tuner_status = 0;
status = mt2063_lockStatus(state);
if (status 0)
@@ -2019,6 +2026,12 @@ static int mt2063_set_analog_params(struct dvb_frontend
*fe,
dprintk(2, \n);
+ if (!state-init) {
+ status = mt2063_init(fe);
+ if (status 0)
+ return status;
+ }
+
switch (params-mode) {
case V4L2_TUNER_RADIO:
pict_car = 3890;
@@ -2082,6 +2095,12 @@ static int mt2063_set_params(struct dvb_frontend *fe)
s32 if_mid;
s32 rcvr_mode;
+ if (!state-init) {
+ status = mt2063_init(fe);
+ if (status 0)
+ return status;
+ }
+
dprintk(2, \n);
if (c-bandwidth_hz == 0)
@@ -2132,6 +2151,9 @@ static int mt2063_get_frequency(struct dvb_frontend *fe,
u32 *freq)
dprintk(2, \n);
+ if (!state-init)
+ return -ENODEV;
+
*freq = state-frequency;
return 0;
}
@@ -2142,6 +2164,9 @@ static int mt2063_get_bandwidth(struct dvb_frontend *fe,
u32 *bw)
dprintk(2, \n);
+ if (!state-init)
+ return -ENODEV;
+
*bw = state-AS_Data.f_out_bw - 75;
return 0;
}
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/47] [media] mt2063: Re-define functions as static
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 84 ++
drivers/media/common/tuners/mt2063.h | 74 --
2 files changed, 44 insertions(+), 114 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 63d964a..85980cc 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -13,6 +13,16 @@ static unsigned int verbose;
module_param(verbose, int, 0644);
+/* Prototypes */
+static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
+u32 f_min, u32 f_max);
+static u32 MT2063_ReInit(void *h);
+static u32 MT2063_Close(void *hMT2063);
+static u32 MT2063_GetReg(void *h, u8 reg, u8 * val);
+static u32 MT2063_GetParam(void *h, enum MT2063_Param param, u32 * pValue);
+static u32 MT2063_SetReg(void *h, u8 reg, u8 val);
+static u32 MT2063_SetParam(void *h, enum MT2063_Param param, u32 nValue);
+
/*/
/* From drivers/media/common/tuners/mt2063_cfg.h */
@@ -233,7 +243,7 @@ static int mt2063_read_regs(struct mt2063_state *state, u8
reg1, u8 * b, u8 len)
** N/A 03-25-2004DADOriginal
**
*/
-u32 MT2063_WriteSub(void *hUserData,
+static u32 MT2063_WriteSub(void *hUserData,
u32 addr,
u8 subAddress, u8 * pData, u32 cnt)
{
@@ -296,7 +306,7 @@ u32 MT2063_WriteSub(void *hUserData,
** N/A 03-25-2004DADOriginal
**
*/
-u32 MT2063_ReadSub(void *hUserData,
+static u32 MT2063_ReadSub(void *hUserData,
u32 addr,
u8 subAddress, u8 * pData, u32 cnt)
{
@@ -347,7 +357,7 @@ u32 MT2063_ReadSub(void *hUserData,
** N/A 03-25-2004DADOriginal
**
*/
-void MT2063_Sleep(void *hUserData, u32 nMinDelayTime)
+static void MT2063_Sleep(void *hUserData, u32 nMinDelayTime)
{
/*
** ToDo: Add code here to implement a OS blocking
@@ -386,7 +396,7 @@ void MT2063_Sleep(void *hUserData, u32 nMinDelayTime)
** better describes what this function does.
**
*/
-u32 MT2060_TunerGain(void *hUserData, s32 * pMeas)
+static u32 MT2060_TunerGain(void *hUserData, s32 * pMeas)
{
u32 status = MT2063_OK; /* Status to be returned*/
@@ -465,7 +475,7 @@ static struct MT2063_AvoidSpursData_t
*TunerList[MT2063_TUNER_CNT];
static u32 TunerCount = 0;
#endif
-u32 MT2063_RegisterTuner(struct MT2063_AvoidSpursData_t *pAS_Info)
+static u32 MT2063_RegisterTuner(struct MT2063_AvoidSpursData_t *pAS_Info)
{
#if MT2063_TUNER_CNT == 1
pAS_Info-nAS_Algorithm = 1;
@@ -496,7 +506,7 @@ u32 MT2063_RegisterTuner(struct MT2063_AvoidSpursData_t
*pAS_Info)
#endif
}
-void MT2063_UnRegisterTuner(struct MT2063_AvoidSpursData_t *pAS_Info)
+static void MT2063_UnRegisterTuner(struct MT2063_AvoidSpursData_t *pAS_Info)
{
#if MT2063_TUNER_CNT == 1
pAS_Info;
@@ -519,7 +529,7 @@ void MT2063_UnRegisterTuner(struct MT2063_AvoidSpursData_t
*pAS_Info)
** N/A I 06-17-2008RSKVer 1.19: Refactoring avoidance of DECT
** frequencies into MT_ResetExclZones().
*/
-void MT2063_ResetExclZones(struct MT2063_AvoidSpursData_t *pAS_Info)
+static void MT2063_ResetExclZones(struct MT2063_AvoidSpursData_t *pAS_Info)
{
u32 center;
#if MT2063_TUNER_CNT 1
@@ -685,7 +695,7 @@ static struct MT2063_ExclZone_t *RemoveNode(struct
MT2063_AvoidSpursData_t
** (f_min, f_max) 0, ignore the entry.
**
*/
-void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
+static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
u32 f_min, u32 f_max)
{
struct MT2063_ExclZone_t *pNode = pAS_Info-usedZones;
@@ -751,7 +761,7 @@ void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t
*pAS_Info,
** Added logic to force f_Center within 1/2
f_Step.
**
*/
-u32 MT2063_ChooseFirstIF(struct MT2063_AvoidSpursData_t *pAS_Info)
+static u32 MT2063_ChooseFirstIF(struct MT2063_AvoidSpursData_t *pAS_Info)
{
/*
** Update f_Desired to be the nearest combinational-multiple of
f_LO1_Step.
@@ -1318,7 +1328,7 @@ static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t
*pAS_Info,
** 096 04-06-2005DADVer 1.11: Fix divide by 0 error if maxH==0.
**
*/
-u32
[PATCH 45/47] [media] mt2063: Add it to the building system
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/Kconfig |7 +++ drivers/media/common/tuners/Makefile |1 + 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/common/tuners/Kconfig b/drivers/media/common/tuners/Kconfig index 996302a..ab8856d 100644 --- a/drivers/media/common/tuners/Kconfig +++ b/drivers/media/common/tuners/Kconfig @@ -116,6 +116,13 @@ config MEDIA_TUNER_MT2060 help A driver for the silicon IF tuner MT2060 from Microtune. +config MEDIA_TUNER_MT2063 + tristate Microtune MT2063 silicon IF tuner + depends on VIDEO_MEDIA I2C + default m if MEDIA_TUNER_CUSTOMISE + help + A driver for the silicon IF tuner MT2063 from Microtune. + config MEDIA_TUNER_MT2266 tristate Microtune MT2266 silicon tuner depends on VIDEO_MEDIA I2C diff --git a/drivers/media/common/tuners/Makefile b/drivers/media/common/tuners/Makefile index 196c12a..8295854 100644 --- a/drivers/media/common/tuners/Makefile +++ b/drivers/media/common/tuners/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_MEDIA_TUNER_TDA18271) += tda18271.o obj-$(CONFIG_MEDIA_TUNER_XC5000) += xc5000.o obj-$(CONFIG_MEDIA_TUNER_XC4000) += xc4000.o obj-$(CONFIG_MEDIA_TUNER_MT2060) += mt2060.o +obj-$(CONFIG_MEDIA_TUNER_MT2063) += mt2063.o obj-$(CONFIG_MEDIA_TUNER_MT2266) += mt2266.o obj-$(CONFIG_MEDIA_TUNER_QT1010) += qt1010.o obj-$(CONFIG_MEDIA_TUNER_MT2131) += mt2131.o -- 1.7.7.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 40/47] [media] mt2063: Print a message about the detected mt2063 type
This also helps to identify when a device is not initialized,
if the bridge doesn't return an error for a I2C failed transfer.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index db347d9..fdf6050 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -1790,6 +1790,7 @@ static int mt2063_init(struct dvb_frontend *fe)
struct mt2063_state *state = fe-tuner_priv;
u8 all_resets = 0xF0; /* reset/load bits */
const u8 *def = NULL;
+ char *step;
u32 FCRUN;
s32 maxReads;
u32 fcu_osc;
@@ -1807,10 +1808,24 @@ static int mt2063_init(struct dvb_frontend *fe)
}
/* Check the part/rev code */
- if (((state-reg[MT2063_REG_PART_REV] != MT2063_B0) /* MT2063 B0
*/
-(state-reg[MT2063_REG_PART_REV] != MT2063_B1) /* MT2063 B1
*/
-(state-reg[MT2063_REG_PART_REV] != MT2063_B3))) /* MT2063 B3
*/
+ switch (state-reg[MT2063_REG_PART_REV]) {
+ case MT2063_B0:
+ step = B0;
+ break;
+ case MT2063_B1:
+ step = B1;
+ break;
+ case MT2063_B2:
+ step = B2;
+ break;
+ case MT2063_B3:
+ step = B3;
+ break;
+ default:
+ printk(KERN_ERR mt2063: Unknown mt2063 device ID (0x%02x)\n,
+ state-reg[MT2063_REG_PART_REV]);
return -ENODEV; /* Wrong tuner Part/Rev code */
+ }
/* Check the 2nd byte of the Part/Rev code from the tuner */
status = mt2063_read(state, MT2063_REG_RSVD_3B,
@@ -1818,10 +1833,13 @@ static int mt2063_init(struct dvb_frontend *fe)
/* b7 != 0 == NOT MT2063 */
if (status 0 || ((state-reg[MT2063_REG_RSVD_3B] 0x80) != 0x00)) {
- printk(KERN_ERR Can't read mt2063 2nd part ID\n);
+ printk(KERN_ERR mt2063: Unknown 2nd part ID\n);
return -ENODEV; /* Wrong tuner Part/Rev code */
}
+ dprintk(1, Discovered a mt2063 %s (2nd part number 0x%02x)\n,
+ step, state-reg[MT2063_REG_RSVD_3B]);
+
/* Reset the tuner */
status = mt2063_write(state, MT2063_REG_LO2CQ_3, all_resets, 1);
if (status 0)
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 33/47] [media] mt2063: Rearrange the delivery system functions
No functional changes on this patch. Better organize the delivery
system information and data types, putting everything together,
to improve readability.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 143 --
1 files changed, 66 insertions(+), 77 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 181deac..5e9655a 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -130,19 +130,6 @@ enum MT2063_Mask_Bits {
};
/*
- * Parameter for selecting tuner mode
- */
-enum MT2063_RCVR_MODES {
- MT2063_CABLE_QAM = 0, /* Digital cable */
- MT2063_CABLE_ANALOG,/* Analog cable */
- MT2063_OFFAIR_COFDM,/* Digital offair */
- MT2063_OFFAIR_COFDM_SAWLESS,/* Digital offair without SAW */
- MT2063_OFFAIR_ANALOG, /* Analog offair */
- MT2063_OFFAIR_8VSB, /* Analog offair */
- MT2063_NUM_RCVR_MODES
-};
-
-/*
* Possible values for MT2063_DNC_OUTPUT
*/
enum MT2063_DNC_Output_Enable {
@@ -904,37 +891,6 @@ static u32 MT2063_AvoidSpurs(struct
MT2063_AvoidSpursData_t *pAS_Info)
#define MT2063_B2 (0x9D)
#define MT2063_B3 (0x9E)
-/*
- * Constants for setting receiver modes.
- * (6 modes defined at this time, enumerated by MT2063_RCVR_MODES)
- * (DNC1GC DNC2GC are the values, which are used, when the specific
- * DNC Output is selected, the other is always off)
- *
- *enum MT2063_RCVR_MODES
- * -+--
- * Mode 0 : | MT2063_CABLE_QAM
- * Mode 1 : | MT2063_CABLE_ANALOG
- * Mode 2 : | MT2063_OFFAIR_COFDM
- * Mode 3 : | MT2063_OFFAIR_COFDM_SAWLESS
- * Mode 4 : | MT2063_OFFAIR_ANALOG
- * Mode 5 : | MT2063_OFFAIR_8VSB
- * --+--
- */
-static const u8 RFAGCEN[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 LNARIN[] = { 0, 0, 3, 3, 3, 3 };
-static const u8 FIFFQEN[] = { 1, 1, 1, 1, 1, 1 };
-static const u8 FIFFQ[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 DNC1GC[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 DNC2GC[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACLNAMAX[] = { 31, 31, 31, 31, 31, 31 };
-static const u8 LNATGT[] = { 44, 43, 43, 43, 43, 43 };
-static const u8 RFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACRFMAX[] = { 31, 31, 31, 31, 31, 31 };
-static const u8 PD1TGT[] = { 36, 36, 38, 38, 36, 38 };
-static const u8 FIFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
-static const u8 ACFIFMAX[] = { 29, 29, 29, 29, 29, 29 };
-static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
-
/**
* mt2063_lockStatus - Checks to see if LO1 and LO2 are locked
*
@@ -977,6 +933,67 @@ static unsigned int mt2063_lockStatus(struct mt2063_state
*state)
}
/*
+ * Constants for setting receiver modes.
+ * (6 modes defined at this time, enumerated by mt2063_delivery_sys)
+ * (DNC1GC DNC2GC are the values, which are used, when the specific
+ * DNC Output is selected, the other is always off)
+ *
+ *enum mt2063_delivery_sys
+ * -+--
+ * Mode 0 : | MT2063_CABLE_QAM
+ * Mode 1 : | MT2063_CABLE_ANALOG
+ * Mode 2 : | MT2063_OFFAIR_COFDM
+ * Mode 3 : | MT2063_OFFAIR_COFDM_SAWLESS
+ * Mode 4 : | MT2063_OFFAIR_ANALOG
+ * Mode 5 : | MT2063_OFFAIR_8VSB
+ * --+--
+ *
+ *|-- Mode --|
+ *Reg Field | 0 | 1 | 2 | 3 | 4 | 5 |
+ *+-+-+-+-+-+-+
+ *RFAGCen | OFF | OFF | OFF | OFF | OFF | OFF
+ *LNARin | 0 | 0 | 3 | 3 | 3 | 3
+ *FIFFQen | 1 | 1 | 1 | 1 | 1 | 1
+ *FIFFq | 0 | 0 | 0 | 0 | 0 | 0
+ *DNC1gc | 0 | 0 | 0 | 0 | 0 | 0
+ *DNC2gc | 0 | 0 | 0 | 0 | 0 | 0
+ *GCU Auto| 1 | 1 | 1 | 1 | 1 | 1
+ *LNA max Atn | 31 | 31 | 31 | 31 | 31 | 31
+ *LNA Target | 44 | 43 | 43 | 43 | 43 | 43
+ *ign RF Ovl | 0 | 0 | 0 | 0 | 0 | 0
+ *RF max Atn | 31 | 31 | 31 | 31 | 31 | 31
+ *PD1 Target | 36 | 36 | 38 | 38 | 36 | 38
+ *ign FIF Ovl | 0 | 0 | 0 | 0 | 0 | 0
+ *FIF max Atn | 5 | 5 | 5 | 5 | 5 | 5
+ *PD2 Target | 40 | 33 | 42 | 42 | 33 | 42
+ */
+
+enum mt2063_delivery_sys {
+ MT2063_CABLE_QAM = 0, /* Digital cable */
+ MT2063_CABLE_ANALOG,/* Analog cable */
+ MT2063_OFFAIR_COFDM,/* Digital offair */
+ MT2063_OFFAIR_COFDM_SAWLESS,/* Digital offair without SAW */
+ MT2063_OFFAIR_ANALOG, /* Analog offair */
+
[PATCH 28/47] [media] mt2063: Reorder the code to avoid function prototypes
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 331 +++---
1 files changed, 150 insertions(+), 181 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index f9ebe24..0f4bf96 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -240,48 +240,10 @@ struct mt2063_state {
u8 reg[MT2063_REG_END_REGS];
};
-/* Prototypes */
-static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
-u32 f_min, u32 f_max);
-static u32 MT2063_SetReg(struct mt2063_state *state, u8 reg, u8 val);
-static u32 MT2063_SoftwareShutdown(struct mt2063_state *state, u8 Shutdown);
-static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state, enum
MT2063_Mask_Bits Bits);
-
-
-/*
- * Ancillary routines visible outside mt2063
- */
-unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe)
-{
- struct mt2063_state *state = fe-tuner_priv;
- int err = 0;
-
- err = MT2063_SoftwareShutdown(state, 1);
- if (err 0)
- printk(KERN_ERR %s: Couldn't shutdown\n, __func__);
-
- return err;
-}
-EXPORT_SYMBOL_GPL(tuner_MT2063_SoftwareShutdown);
-
-unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe)
-{
- struct mt2063_state *state = fe-tuner_priv;
- int err = 0;
-
- err = MT2063_ClearPowerMaskBits(state, MT2063_ALL_SD);
- if (err 0)
- printk(KERN_ERR %s: Invalid parameter\n, __func__);
-
- return err;
-}
-EXPORT_SYMBOL_GPL(tuner_MT2063_ClearPowerMaskBits);
-
/*
* mt2063_write - Write data into the I2C bus
*/
-static u32 mt2063_write(struct mt2063_state *state,
- u8 reg, u8 *data, u32 len)
+static u32 mt2063_write(struct mt2063_state *state, u8 reg, u8 *data, u32 len)
{
struct dvb_frontend *fe = state-frontend;
int ret;
@@ -307,6 +269,26 @@ static u32 mt2063_write(struct mt2063_state *state,
}
/*
+ * mt2063_write - Write register data into the I2C bus, caching the value
+ */
+static u32 mt2063_setreg(struct mt2063_state *state, u8 reg, u8 val)
+{
+ u32 status;
+
+ if (reg = MT2063_REG_END_REGS)
+ return -ERANGE;
+
+ status = mt2063_write(state, reg, val, 1);
+ if (status 0)
+ return status;
+
+ state-reg[reg] = val;
+
+ return 0;
+}
+
+
+/*
* mt2063_read - Read data from the I2C bus
*/
static u32 mt2063_read(struct mt2063_state *state,
@@ -370,76 +352,6 @@ struct MT2063_FIFZone_t {
s32 max_;
};
-/*
-** Reset all exclusion zones.
-** Add zones to protect the PLL FracN regions near zero
-**
-** N/A I 06-17-2008RSKVer 1.19: Refactoring avoidance of DECT
-** frequencies into MT_ResetExclZones().
-*/
-static void MT2063_ResetExclZones(struct MT2063_AvoidSpursData_t *pAS_Info)
-{
- u32 center;
-
- pAS_Info-nZones = 0; /* this clears the used list */
- pAS_Info-usedZones = NULL; /* reset ptr */
- pAS_Info-freeZones = NULL; /* reset ptr */
-
- center =
- pAS_Info-f_ref *
- ((pAS_Info-f_if1_Center - pAS_Info-f_if1_bw / 2 +
- pAS_Info-f_in) / pAS_Info-f_ref) - pAS_Info-f_in;
- while (center
- pAS_Info-f_if1_Center + pAS_Info-f_if1_bw / 2 +
- pAS_Info-f_LO1_FracN_Avoid) {
- /* Exclude LO1 FracN */
- MT2063_AddExclZone(pAS_Info,
- center - pAS_Info-f_LO1_FracN_Avoid,
- center - 1);
- MT2063_AddExclZone(pAS_Info, center + 1,
- center + pAS_Info-f_LO1_FracN_Avoid);
- center += pAS_Info-f_ref;
- }
-
- center =
- pAS_Info-f_ref *
- ((pAS_Info-f_if1_Center - pAS_Info-f_if1_bw / 2 -
- pAS_Info-f_out) / pAS_Info-f_ref) + pAS_Info-f_out;
- while (center
- pAS_Info-f_if1_Center + pAS_Info-f_if1_bw / 2 +
- pAS_Info-f_LO2_FracN_Avoid) {
- /* Exclude LO2 FracN */
- MT2063_AddExclZone(pAS_Info,
- center - pAS_Info-f_LO2_FracN_Avoid,
- center - 1);
- MT2063_AddExclZone(pAS_Info, center + 1,
- center + pAS_Info-f_LO2_FracN_Avoid);
- center += pAS_Info-f_ref;
- }
-
- if (MT2063_EXCLUDE_US_DECT_FREQUENCIES(pAS_Info-avoidDECT)) {
- /* Exclude LO1 values that conflict with DECT channels */
- MT2063_AddExclZone(pAS_Info, 1920836000 - pAS_Info-f_in,
1922236000 - pAS_Info-f_in); /* Ctr = 1921.536 */
- MT2063_AddExclZone(pAS_Info, 1922564000 - pAS_Info-f_in,
1923964000 - pAS_Info-f_in); /* Ctr = 1923.264
[PATCH 38/47] [media] mt2063: Remove two unused temporary vars
mt2063.c:1531:12: warning: variable 'ofout' set but not used [-Wunused-but-set-variable] mt2063.c:1531:6: warning: variable 'ofin' set but not used [-Wunused-but-set-variable] Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/mt2063.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/media/common/tuners/mt2063.c b/drivers/media/common/tuners/mt2063.c index b72105d..92653a9 100644 --- a/drivers/media/common/tuners/mt2063.c +++ b/drivers/media/common/tuners/mt2063.c @@ -1528,7 +1528,6 @@ static u32 MT2063_Tune(struct mt2063_state *state, u32 f_in) u32 LO2;/* 2nd LO register value */ u32 Num2; /* Numerator for LO2 reg. value*/ u32 ofLO1, ofLO2; /* last time's LO frequencies */ - u32 ofin, ofout;/* last time's I/O frequencies */ u8 fiffc = 0x80;/* FIFF center freq from tuner */ u32 fiffof; /* Offset from FIFF center freq*/ const u8 LO1LK = 0x80; /* Mask for LO1 Lock bit */ @@ -1549,9 +1548,7 @@ static u32 MT2063_Tune(struct mt2063_state *state, u32 f_in) * Save original LO1 and LO2 register values */ ofLO1 = state-AS_Data.f_LO1; - ofLO2 = state-AS_Data.f_LO2; - ofin = state-AS_Data.f_in; - ofout = state-AS_Data.f_out; + ofLO2 = state-AS_Data.f_LO2; /* * Find and set RF Band setting -- 1.7.7.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 37/47] [media] mt2063: Rewrite tuning logic
Several vars at set_parms functions were set, but unused.
Remove them and change the logic to return -EINVAL if the
analog set_param is used for digital mode.
At the analog side, cleans the logic that sets the several
analog standards.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 62 +++--
1 files changed, 13 insertions(+), 49 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index cd67417..b72105d 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -2013,14 +2013,11 @@ static int mt2063_set_analog_params(struct dvb_frontend
*fe,
struct analog_parameters *params)
{
struct mt2063_state *state = fe-tuner_priv;
- s32 pict_car = 0;
- s32 pict2chanb_vsb = 0;
- s32 pict2chanb_snd = 0;
- s32 pict2snd1 = 0;
- s32 pict2snd2 = 0;
- s32 ch_bw = 0;
- s32 if_mid = 0;
- s32 rcvr_mode = 0;
+ s32 pict_car;
+ s32 pict2chanb_vsb;
+ s32 ch_bw;
+ s32 if_mid;
+ s32 rcvr_mode;
int status;
dprintk(2, \n);
@@ -2030,8 +2027,6 @@ static int mt2063_set_analog_params(struct dvb_frontend
*fe,
pict_car = 3890;
ch_bw = 800;
pict2chanb_vsb = -(ch_bw / 2);
- pict2snd1 = 0;
- pict2snd2 = 0;
rcvr_mode = MT2063_OFFAIR_ANALOG;
break;
case V4L2_TUNER_ANALOG_TV:
@@ -2040,42 +2035,19 @@ static int mt2063_set_analog_params(struct dvb_frontend
*fe,
pict_car = 3890;
ch_bw = 600;
pict2chanb_vsb = -125;
- pict2snd1 = 450;
- pict2snd2 = 0;
- } else if (params-std V4L2_STD_PAL_I) {
- pict_car = 3890;
- ch_bw = 800;
- pict2chanb_vsb = -125;
- pict2snd1 = 600;
- pict2snd2 = 0;
- } else if (params-std V4L2_STD_PAL_B) {
- pict_car = 3890;
- ch_bw = 800;
- pict2chanb_vsb = -125;
- pict2snd1 = 550;
- pict2snd2 = 5742000;
} else if (params-std V4L2_STD_PAL_G) {
pict_car = 3890;
ch_bw = 700;
pict2chanb_vsb = -125;
- pict2snd1 = 550;
- pict2snd2 = 0;
- } else if (params-std V4L2_STD_PAL_DK) {
+ } else {/* PAL/SECAM standards */
pict_car = 3890;
ch_bw = 800;
pict2chanb_vsb = -125;
- pict2snd1 = 650;
- pict2snd2 = 0;
- } else {/* PAL-L */
- pict_car = 3890;
- ch_bw = 800;
- pict2chanb_vsb = -125;
- pict2snd1 = 650;
- pict2snd2 = 0;
}
break;
+ default:
+ return -EINVAL;
}
- pict2chanb_snd = pict2chanb_vsb - ch_bw;
if_mid = pict_car - (pict2chanb_vsb + (ch_bw / 2));
state-AS_Data.f_LO2_Step = 125000; /* FIXME: probably 5000 for FM
*/
@@ -2107,14 +2079,11 @@ static int mt2063_set_params(struct dvb_frontend *fe)
struct dtv_frontend_properties *c = fe-dtv_property_cache;
struct mt2063_state *state = fe-tuner_priv;
int status;
- s32 pict_car = 0;
- s32 pict2chanb_vsb = 0;
- s32 pict2chanb_snd = 0;
- s32 pict2snd1 = 0;
- s32 pict2snd2 = 0;
- s32 ch_bw = 0;
- s32 if_mid = 0;
- s32 rcvr_mode = 0;
+ s32 pict_car;
+ s32 pict2chanb_vsb;
+ s32 ch_bw;
+ s32 if_mid;
+ s32 rcvr_mode;
dprintk(2, \n);
@@ -2132,21 +2101,16 @@ static int mt2063_set_params(struct dvb_frontend *fe)
rcvr_mode = MT2063_OFFAIR_COFDM;
pict_car = 36125000;
pict2chanb_vsb = -(ch_bw / 2);
- pict2snd1 = 0;
- pict2snd2 = 0;
break;
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_C:
rcvr_mode = MT2063_CABLE_QAM;
pict_car = 36125000;
- pict2snd1 = 0;
- pict2snd2 = 0;
pict2chanb_vsb = -(ch_bw / 2);
break;
default:
return -EINVAL;
}
- pict2chanb_snd = pict2chanb_vsb - ch_bw;
if_mid = pict_car - (pict2chanb_vsb + (ch_bw / 2));
state-AS_Data.f_LO2_Step =
[PATCH 34/47] [media] mt2063: Properly document the author of the original driver
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/mt2063.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/common/tuners/mt2063.c b/drivers/media/common/tuners/mt2063.c index 5e9655a..b2678a4 100644 --- a/drivers/media/common/tuners/mt2063.c +++ b/drivers/media/common/tuners/mt2063.c @@ -3,9 +3,11 @@ * * Copyright (c) 2011 Mauro Carvalho Chehab mche...@redhat.com * - * This driver came from a driver originally written by Henry, made available - * by Terratec, at: + * This driver came from a driver originally written by: + * Henry Wang henry.w...@azurewave.com + * Made publicly available by Terratec, at: * http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz + * The original driver's license is GPL, as declared with MODULE_LICENSE() * * 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 -- 1.7.7.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 30/47] [media] mt2063: make checkpatch.pl happy
Fix everything but 80 columns and two msleep warnings
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 129 +-
1 files changed, 48 insertions(+), 81 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index d13b78b..5154b9d 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -263,7 +263,7 @@ static u32 mt2063_write(struct mt2063_state *state, u8 reg,
u8 *data, u32 len)
fe-ops.i2c_gate_ctrl(fe, 0);
if (ret 0)
- printk(mt2063_writeregs error ret=%d\n, ret);
+ printk(KERN_ERR %s error ret=%d\n, __func__, ret);
return ret;
}
@@ -287,7 +287,6 @@ static u32 mt2063_setreg(struct mt2063_state *state, u8
reg, u8 val)
return 0;
}
-
/*
* mt2063_read - Read data from the I2C bus
*/
@@ -322,7 +321,7 @@ static u32 mt2063_read(struct mt2063_state *state,
break;
}
fe-ops.i2c_gate_ctrl(fe, 0);
- return (status);
+ return status;
}
/*
@@ -600,10 +599,6 @@ static u32 MT2063_ChooseFirstIF(struct
MT2063_AvoidSpursData_t *pAS_Info)
((f_Desired - pAS_Info-f_if1_Center +
f_Step / 2) / f_Step);
- //assert;
- //if (!abs((s32) f_Center - (s32) pAS_Info-f_if1_Center) = (s32)
(f_Step/2))
- // return 0;
-
/* Take MT_ExclZones, center around f_Center and change the resolution
to f_Step */
while (pNode != NULL) {
/* floor function */
@@ -625,10 +620,6 @@ static u32 MT2063_ChooseFirstIF(struct
MT2063_AvoidSpursData_t *pAS_Info)
zones[j - 1].max_ = tmpMax;
else {
/* Add new zone */
- //assert(jMT2063_MAX_ZONES);
- //if (j=MT2063_MAX_ZONES)
- //break;
-
zones[j].min_ = tmpMin;
zones[j].max_ = tmpMax;
j++;
@@ -903,15 +894,13 @@ static u32 MT2063_AvoidSpurs(struct
MT2063_AvoidSpursData_t *pAS_Info)
delta_IF1 = zfIF1 - pAS_Info-f_if1_Center;
else
delta_IF1 = pAS_Info-f_if1_Center - zfIF1;
- }
+
+ pAS_Info-bSpurPresent = IsSpurInBand(pAS_Info, fm,
fp);
/*
** Continue while the new 1st IF is still within the 1st IF
bandwidth
** and there is a spur in the band (again)
*/
- while ((2 * delta_IF1 + pAS_Info-f_out_bw =
- pAS_Info-f_if1_bw)
- (pAS_Info-bSpurPresent =
- IsSpurInBand(pAS_Info, fm, fp)));
+ } while ((2 * delta_IF1 + pAS_Info-f_out_bw =
pAS_Info-f_if1_bw) pAS_Info-bSpurPresent);
/*
** Use the LO-spur free values found. If the search went all
the way to
@@ -930,19 +919,9 @@ static u32 MT2063_AvoidSpurs(struct
MT2063_AvoidSpursData_t *pAS_Info)
((pAS_Info-
nSpursFound MT2063_SPUR_SHIFT) MT2063_SPUR_CNT_MASK);
- return (status);
+ return status;
}
-/*
-** The expected version of MT_AvoidSpursData_t
-** If the version is different, an updated file is needed from Microtune
-*/
-
-typedef enum {
- MT2063_SET_ATTEN,
- MT2063_INCR_ATTEN,
- MT2063_DECR_ATTEN
-} MT2063_ATTEN_CNTL_MODE;
/*
* Constants used by the tuning algorithm
@@ -1044,8 +1023,7 @@ unsigned int mt2063_lockStatus(struct mt2063_state *state)
return TUNER_STATUS_LOCKED | TUNER_STATUS_STEREO;
}
msleep(nPollRate); /* Wait between retries */
- }
- while (++nDelays nMaxLoops);
+ } while (++nDelays nMaxLoops);
/*
* Got no lock or partial lock
@@ -1058,7 +1036,7 @@ EXPORT_SYMBOL_GPL(mt2063_lockStatus);
* mt2063_set_dnc_output_enable()
*/
static u32 mt2063_get_dnc_output_enable(struct mt2063_state *state,
- enum MT2063_DNC_Output_Enable *pValue)
+ enum MT2063_DNC_Output_Enable *pValue)
{
if ((state-reg[MT2063_REG_DNC_GAIN] 0x03) == 0x03) { /* if DNC1 is
off */
if ((state-reg[MT2063_REG_VGA_GAIN] 0x03) == 0x03) /* if
DNC2 is off */
@@ -1078,7 +1056,7 @@ static u32 mt2063_get_dnc_output_enable(struct
mt2063_state *state,
* mt2063_set_dnc_output_enable()
*/
static u32 mt2063_set_dnc_output_enable(struct mt2063_state *state,
- enum MT2063_DNC_Output_Enable nValue)
+ enum MT2063_DNC_Output_Enable nValue)
{
u32 status = 0; /* Status to be returned*/
u8 val = 0;
@@
[PATCH 22/47] [media] mt2063: Use linux default max function
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 34 +++---
1 files changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 6c73bfd..8662007 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -953,34 +953,6 @@ static u32 MT2063_gcd(u32 u, u32 v)
/
**
-** Name: umax
-**
-** Description:Implements a simple maximum function for unsigned numbers.
-** Implemented as a function rather than a macro to avoid
-** multiple evaluation of the calling parameters.
-**
-** Parameters: a, b - Values to be compared
-**
-** Global: None
-**
-** Returns:larger of the input values.
-**
-** Dependencies: None.
-**
-** Revision History:
-**
-** SCR Date Author Description
-** -
-** N/A 06-02-2004JWSOriginal
-**
-/
-static u32 MT2063_umax(u32 a, u32 b)
-{
- return (a = b) ? a : b;
-}
-
-/
-**
** Name: IsSpurInBand
**
** Description:Checks to see if a spur will be present within the IF's
@@ -1037,11 +1009,11 @@ static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t
*pAS_Info,
** gcd-based scale factor or f_Scale.
*/
lo_gcd = MT2063_gcd(f_LO1, f_LO2);
- gd_Scale = MT2063_umax((u32) MT2063_gcd(lo_gcd, d), f_Scale);
+ gd_Scale = max((u32) MT2063_gcd(lo_gcd, d), f_Scale);
hgds = gd_Scale / 2;
- gc_Scale = MT2063_umax((u32) MT2063_gcd(lo_gcd, c), f_Scale);
+ gc_Scale = max((u32) MT2063_gcd(lo_gcd, c), f_Scale);
hgcs = gc_Scale / 2;
- gf_Scale = MT2063_umax((u32) MT2063_gcd(lo_gcd, f), f_Scale);
+ gf_Scale = max((u32) MT2063_gcd(lo_gcd, f), f_Scale);
hgfs = gf_Scale / 2;
n0 = DIV_ROUND_UP(f_LO2 - d, f_LO1 - f_LO2);
--
1.7.7.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/47] [media] mt2063: Cleanup some function prototypes
No functional changes here.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/common/tuners/mt2063.c | 44 -
1 files changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 0f4bf96..d13b78b 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -420,7 +420,7 @@ static struct MT2063_ExclZone_t *RemoveNode(struct
MT2063_AvoidSpursData_t
**
*/
static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
- u32 f_min, u32 f_max)
+ u32 f_min, u32 f_max)
{
struct MT2063_ExclZone_t *pNode = pAS_Info-usedZones;
struct MT2063_ExclZone_t *pPrev = NULL;
@@ -734,7 +734,7 @@ static u32 MT2063_gcd(u32 u, u32 v)
**
/
static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t *pAS_Info,
- u32 * fm, u32 * fp)
+ u32 *fm, u32 * fp)
{
/*
** Calculate LO frequency settings.
@@ -849,7 +849,7 @@ static u32 IsSpurInBand(struct MT2063_AvoidSpursData_t
*pAS_Info,
** 096 04-06-2005DADVer 1.11: Fix divide by 0 error if maxH==0.
**
*/
-static u32 MT2063_AvoidSpurs(void *h, struct MT2063_AvoidSpursData_t *
pAS_Info)
+static u32 MT2063_AvoidSpurs(struct MT2063_AvoidSpursData_t *pAS_Info)
{
u32 status = 0;
u32 fm, fp; /* restricted range on LO's*/
@@ -1011,18 +1011,6 @@ static const u8 FIFOVDIS[] = { 0, 0, 0, 0, 0, 0 };
static const u8 ACFIFMAX[] = { 29, 29, 29, 29, 29, 29 };
static const u8 PD2TGT[] = { 40, 33, 38, 42, 30, 38 };
-/*
-** Local Function Prototypes - not available for external access.
-*/
-
-/* Forward declaration(s): */
-static u32 MT2063_CalcLO1Mult(u32 * Div, u32 * FracN, u32 f_LO,
- u32 f_LO_Step, u32 f_Ref);
-static u32 MT2063_CalcLO2Mult(u32 * Div, u32 * FracN, u32 f_LO,
- u32 f_LO_Step, u32 f_Ref);
-static u32 MT2063_fLO_FractionalTerm(u32 f_ref, u32 num,
-u32 denom);
-
/**
* mt2063_lockStatus - Checks to see if LO1 and LO2 are locked
*
@@ -1300,7 +1288,7 @@ static u32 mt2063_set_dnc_output_enable(struct
mt2063_state *state,
**
**/
static u32 MT2063_SetReceiverMode(struct mt2063_state *state,
- enum MT2063_RCVR_MODES Mode)
+ enum MT2063_RCVR_MODES Mode)
{
u32 status = 0; /* Status to be returned*/
u8 val;
@@ -1464,7 +1452,8 @@ static u32 MT2063_SetReceiverMode(struct mt2063_state
*state,
** 138 06-19-2007DADVer 1.00: Initial, derived from mt2067_b.
**
/
-static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state, enum
MT2063_Mask_Bits Bits)
+static u32 MT2063_ClearPowerMaskBits(struct mt2063_state *state,
+enum MT2063_Mask_Bits Bits)
{
u32 status = 0; /* Status to be returned*/
@@ -1584,8 +1573,7 @@ static u32 MT2063_Round_fLO(u32 f_LO, u32 f_LO_Step, u32
f_ref)
** 138 06-19-2007DADVer 1.00: Initial, derived from mt2067_b.
**
/
-static u32 MT2063_fLO_FractionalTerm(u32 f_ref,
-u32 num, u32 denom)
+static u32 MT2063_fLO_FractionalTerm(u32 f_ref, u32 num, u32 denom)
{
u32 t1 = (f_ref 14) * num;
u32 term1 = t1 / denom;
@@ -1623,9 +1611,9 @@ static u32 MT2063_fLO_FractionalTerm(u32 f_ref,
**
/
static u32 MT2063_CalcLO1Mult(u32 * Div,
- u32 * FracN,
- u32 f_LO,
- u32 f_LO_Step, u32 f_Ref)
+ u32 * FracN,
+ u32 f_LO,
+ u32 f_LO_Step, u32 f_Ref)
{
/* Calculate the whole number portion of the divider */
*Div = f_LO / f_Ref;
@@ -1666,9 +1654,9 @@ static u32 MT2063_CalcLO1Mult(u32 * Div,
**
/
static u32 MT2063_CalcLO2Mult(u32 * Div,
- u32 * FracN,
- u32 f_LO,
- u32 f_LO_Step, u32 f_Ref)
+ u32 * FracN,
+ u32 f_LO,
+
