| Message ID | 1403870714.2767.5.camel@madomr-fc.comexp.ru (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c > index 2b3d514..d1f539c 100644 > --- a/drivers/media/tuners/xc5000.c > +++ b/drivers/media/tuners/xc5000.c > @@ -85,6 +85,7 @@ struct xc5000_priv { > /* Product id */ > #define XC_PRODUCT_ID_FW_NOT_LOADED 0x2000 > #define XC_PRODUCT_ID_FW_LOADED 0x1388 > +#define XC_PRODUCT_ID_FW_LOADED_5000C 0x14b4 > > /* Registers */ > #define XREG_INIT 0x00 > @@ -1344,6 +1345,7 @@ struct dvb_frontend *xc5000_attach(struct dvb_frontend *fe, > > switch (id) { > case XC_PRODUCT_ID_FW_LOADED: > + case XC_PRODUCT_ID_FW_LOADED_5000C: > printk(KERN_INFO > "xc5000: Successfully identified at address 0x%02x\n", > cfg->i2c_address); What is the bridge which interfaces the xc5000? The XC5000C typically returns 0x1388 just like the xc5000. It's much more likely that the I2C bus is broken on the bridge driver (or the chip is in reset at this stage), the I2C request is silently failing and you're getting whatever happens to have been in the buffer. NACK unless you can produce an I2C bus trace showing those bytes coming back over the wire. Devin
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c index 2b3d514..d1f539c 100644 --- a/drivers/media/tuners/xc5000.c +++ b/drivers/media/tuners/xc5000.c @@ -85,6 +85,7 @@ struct xc5000_priv { /* Product id */ #define XC_PRODUCT_ID_FW_NOT_LOADED 0x2000 #define XC_PRODUCT_ID_FW_LOADED 0x1388 +#define XC_PRODUCT_ID_FW_LOADED_5000C 0x14b4 /* Registers */ #define XREG_INIT 0x00 @@ -1344,6 +1345,7 @@ struct dvb_frontend *xc5000_attach(struct dvb_frontend *fe, switch (id) { case XC_PRODUCT_ID_FW_LOADED: + case XC_PRODUCT_ID_FW_LOADED_5000C: printk(KERN_INFO "xc5000: Successfully identified at address 0x%02x\n", cfg->i2c_address);
Signed-off-by: Mikhail Domrachev <mihail.domrychev@comexp.ru> --- drivers/media/tuners/xc5000.c | 2 ++ 1 file changed, 2 insertions(+)