Problem with media_build install

[Jose Alberto Reguero]

#make install
make -C /usr/src/media_build/v4l install
make[1]: Entering directory '/usr/src/media_build/v4l'
make[1]: *** No rule to make target 'mm-install' needed by 'install'. Alto.
make[1]: Leaving directory '/usr/src/media_build/v4l'
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 2

Jose Alberto

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Jose Alberto Reguero]

I have the problem with a avermedia twinstart.
07ca:0825
With first hardware revision the read works, but second hardware revision read 
don’t work.

Jose Alberto

El 09/04/2016 19:38, Alessandro Radicati  escribió:
>
> On Sat, Apr 9, 2016 at 7:07 PM, Antti Palosaari  wrote: 
> > 
> > 
> > On 04/09/2016 07:11 PM, Alessandro Radicati wrote: 
> >> 
> >> On Sat, Apr 9, 2016 at 4:25 PM, Antti Palosaari  wrote: 
> >>> 
> >>> On 04/09/2016 11:13 AM, Alessandro Radicati wrote: 
>  
>  
>  On Sat, Apr 9, 2016 at 4:17 AM, Antti Palosaari  wrote: 
> > 
> > 
> > On 04/09/2016 04:52 AM, Alessandro Radicati wrote: 
> >> 
> >> 
> >> 
> >> On Sat, Apr 9, 2016 at 3:22 AM, Antti Palosaari  wrote: 
> >>> 
> >>> 
> >>> 
> >>> Here is patches to test: 
> >>> http://git.linuxtv.org/anttip/media_tree.git/log/?h=af9035 
> >>> 
> >> 
> >> I've done this already in my testing, and it works for getting a 
> >> correct chip_id response, but only because it's avoiding the issue 
> >> with the write/read case in the af9035 driver.  Don't have an 
> >> af9015... perhaps there's a similar issue with that code or we are 
> >> dealing with two separate issues since af9035 never does a repeated 
> >> start? 
> > 
> > 
> > 
> > 
> > I am pretty sure mxl5007t requires stop between read and write. Usually 
> > chips are not caring too much if it is repeated start or not, whilst 
> > datasheets are often register read is S Wr S Rw P. 
> > 
> > Even af9035 i2c adapter implementation implements repeated start wrong, 
> > I 
>  
>  
>  
>  Where does the assumption that CMD_I2C_RD should issue a repeated 
>  start sequence come from?  From the datasheet?  Maybe it was never 
>  intended as repeated start.  Perhaps if there is another stick  with 
>  mxl5007t and a chip that does repeated start, we can put this to bed. 
> >>> 
> >>> 
> >>> 
> >>> Assumption was coming from it just does it as a single USB transaction. 
> >>> Datasheet says there is no repeated start. And kernel I2C API says all 
> >>> messages send using single i2c_transfer() should be send with repeated 
> >>> start, so now it is violating it, but that's not the biggest problem... 
> >>> 
> >> 
> >> Unfortunately there is no way around that problem, but at least it 
> >> means that you can reduce the whole function to just read and write 
> >> since at the I2C level nothing changes. 
> >> 
> > would not like to add anymore hacks there. It is currently ugly and 
> > complex 
>  
>  
>  
>  Bugfix != hack.  Don't see how putting the register address in the 
>  address fields is a hack (perhaps semantics around the fact that 0xFB 
>  is not really part of the address?); this is the only and intended way 
>  to use that command for write/read. 
> >>> 
> >>> 
> >>> 
> >>> I did bunch of testing and find it is really wrong. Dumped out registers 
> >>> from some tuner chips and those seems to be mostly off by one. 
> >>> 
> >>> I think that skeleton is correct way (and it ends about same you did) 
> >>> if (msg[0].len == 0) // probe message, payload 0 
> >>>    buf[0] = msg[0].len; 
> >>>    buf[1] = msg[0].addr << 1; 
> >>>    buf[2] = 0x00; /* reg addr len */ 
> >>>    buf[3] = 0x00; /* reg addr MSB */ 
> >>>    buf[4] = 0x00; /* reg addr LSB */ 
> >>> else if (msg[0].len == 1) 
> >>>    buf[0] = msg[0].len; 
> >>>    buf[1] = msg[0].addr << 1; 
> >>>    buf[2] = 1; /* reg addr len */ 
> >>>    buf[3] = 0x00; /* reg addr MSB */ 
> >>>    buf[4] = msg[0].buf[0]; /* reg addr LSB */ 
> >>> else if (msg[0].len == 2) 
> >>>    buf[0] = msg[0].len; 
> >>>    buf[1] = msg[0].addr << 1; 
> >>>    buf[2] = 2; /* reg addr len */ 
> >>>    buf[3] = msg[0].buf[0]; /* reg addr MSB */ 
> >>>    buf[4] = msg[0].buf[1]; /* reg addr LSB */ 
> >>> else 
> >>>    buf[0] = msg[0].len; 
> >>>    buf[1] = msg[0].addr << 1; 
> >>>    buf[2] = 2; /* reg addr len */ 
> >>>    buf[3] = msg[0].buf[0]; /* reg addr MSB */ 
> >>>    buf[4] = msg[0].buf[1]; /* reg addr LSB */ 
> >>>    memcpy([5], msg[2].buf, msg[0].len - 2); 
> >>> 
> >> 
> >> Yes, this is the same, except I kept the original behavior when write 
> >> len > 2.  Hence with my patch the I2C bus would only see a read 
> >> transaction.  With the above, you would write the first two bytes and 
> >> ignore the rest, then read.  This may be worse than just doing a read 
> >> because if a future tuner reg read setup/address is > 2 then you may 
> >> get into a strange situation.  If that case needs to be addressed, 
> >> then might as well get rid of the single write/read usb transaction 
> >> and just support write or read. 
> > 
> > 
> > Last else branch should do it - but no idea if it works at all and none of 
> > tuners are using it and it is very unlikely there will never be. 

Re: AVerMedia HD Volar (A867) AF9035 + MXL5007T driver issues

[Jose Alberto Reguero]

I made a patch long time ago, but it was not accepted.

https://patchwork.linuxtv.org/patch/16242/

Jose Alberto

El 06/04/2016 01:00, Alessandro Radicati  escribió:
>
> On Wed, Apr 6, 2016 at 12:33 AM, Antti Palosaari  wrote: 
> > I found one stick having AF9035 + MXL5007T. It is HP branded A867, so it 
> > should be similar. It seems to work all three 12.13.15.0 6.20.15.0 
> > firmwares: 
> > http://palosaari.fi/linux/v4l-dvb/firmware/af9035/ 
> > 
> > mxl5007t 5-0060: creating new instance 
> > mxl5007t_get_chip_id: unknown rev (3f) 
> > mxl5007t_get_chip_id: MxL5007T detected @ 5-0060 
> > 
> > That is what AF9035 reports (with debug) as a chip version: 
> > dvb_usb_af9035: prechip_version=00 chip_version=03 chip_type=3802 
> > 
> > 
> > Do you have different chip version? 
> > 
>
> I have a Sky Italy DVB stick with the same chip version.  I see that 
> you get the 0x3f response as well... that should be fixed by the I2C 
> patch I proposed.  However, your stick seems to handle the read 
> properly and process subsequent I2C commands - something that doesn't 
> happen with mine.  The vendor drivers in linux and windows never seem 
> issue the USB I2C commands to read from the tuner.  I'll test with 
> other firmware versions to see if something changes. 
>
> Regards, 
> Alessandro 
> -- 
> 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: dvb_usb_af9015: command failed=1 _ kernel = 4.1.x

[Jose Alberto Reguero]

I made the patch for the af9035. I have not a af9015 whith mxl5007 and dual 
channel. Revert it, if it cause regresions.

Jose Alberto
¡
Enviado desde mi ASUS Pad

poma pomidorabelis...@gmail.com wrote:

On 26.05.2015 14:24, poma wrote:
 
 If it is not taken into account the already known problem of unreliable 
 operation of the first tuner of the two,
 the device works reliably within kernel 4.0.4 with mxl5007t.ko reverted to
 http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/drivers/media/tuners/mxl5007t.c?id=ccae7af
 that is in the same state as is in the longterm kernel - 3.18.14,
 which is in correspondence with the aforementioned results.
 
 

http://git.linuxtv.org/cgit.cgi/media_tree.git/log/drivers/media/tuners/mxl5007t.c


5. 2014-11-11   [media] [PATH,2/2] mxl5007 move loop_thru to attach
   02f9cf9  Jose Alberto Reguero
   
4. 2014-11-11   [media] [PATH,1/2] mxl5007 move reset to attach
   fe4860a  Jose Alberto Reguero

3. 2013-02-08   Revert [media] [PATH,1/2] mxl5007 move reset to attach
   db5c05b  Mauro Carvalho Chehab

2. 2013-02-08   [media] [PATH,1/2] mxl5007 move reset to attach
   0a32377  Jose Alberto Reguero

1. 2012-08-14   [media] common: move media/common/tuners to media/tuners
   ccae7af  Mauro Carvalho Chehab


This is the conclusion after extensive testing,
commitas 5. 4. and 2. produce:

mxl5007t_soft_reset: 521: failed!
mxl5007t_attach: error -121 on line 907

causing the device completely unusable - AF9015 DVB-T USB2.0 stick


Do you need a patch to revert to commita 3. or 1. - again for the third time,
or you have a better solution?

[PATCH] dvbv5-zap fix option lnb UNIVERSAL

[Jose Alberto Reguero]

This patch fix the option lnb UNIVERSAL for dvbv5-zap. Without the patch, the 
option don't work.

Signed-off-by: Jose Alberto Reguero jose.alberto.regu...@gmail.com

diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 14e8fd9..085bbf2 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -773,7 +773,7 @@ int main(int argc, char **argv)
parms = dvb_fe_open(args.adapter, args.frontend, args.verbose, 
args.force_dvbv3);
if (!parms)
goto err;
-   if (lnb)
+   if (lnb = 0)
parms-lnb = dvb_sat_get_lnb(lnb);
if (args.sat_number  0)
parms-sat_number = args.sat_number % 3;

--
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

Problem with dvbv5-zap

[Jose Alberto Reguero]

I am trying to use dvbv5-zap but give me an error and exit:

$ dvbv5-zap -a 2 -c Astra-19.2E  -l ENHANCED -I DVBV5 -v  ZDF
Using LNBf ENHANCED
Astra
10700 to 11700 MHz
Single LO, IF = 9750 MHz
using demux '/dev/dvb/adapter2/demux0'
reading channels from file 'Astra-19.2E'
Device STB0899 Multistandard (/dev/dvb/adapter2/frontend0) capabilities:
 CAN_2G_MODULATION
 CAN_FEC_AUTO
 CAN_INVERSION_AUTO
 CAN_QPSK
DVB API Version 5.10, Current v5 delivery system: DVBS
Supported delivery systems: 
[DVBS]
 DVBS2
 DSS
tuning to 11953 Hz
DiSEqC VOLTAGE: 18
DiSEqC TONE: OFF
ERRORFE_SET_PROPERTY: Invalid argument
FREQUENCY = 11953
INVERSION = AUTO
SYMBOL_RATE = 27500
INNER_FEC = 3/4
POLARIZATION = HORIZONTAL
DELIVERY_SYSTEM = DVBS
ERROR: dvb_fe_set_parms failed (Invalid argument)
DiSEqC VOLTAGE: OFF

I try with two cards and the two give me the same error.

Jose alberto
--
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] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

On Domingo, 24 de marzo de 2013 20:39:15 Jose Alberto Reguero escribió:
 On Domingo, 17 de marzo de 2013 23:46:06 Antti Palosaari escribió:
  On 03/17/2013 08:49 PM, Jose Alberto Reguero wrote:
   On Martes, 12 de marzo de 2013 00:11:38 Antti Palosaari escribió:
   On 03/11/2013 10:02 PM, Jose Alberto Reguero wrote:
   On Lunes, 11 de marzo de 2013 14:57:37 Antti Palosaari escribió:
   On 03/11/2013 01:51 PM, Jose Alberto Reguero wrote:
   On Lunes, 11 de febrero de 2013 14:48:18 Jose Alberto Reguero
 
 escribió:
   On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari 
escribió:
   On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
   This patch block the i2c tuner reads for Avermedia Twinstar. If
   it's
   needed other pids can be added.
   
   Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
   
   diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.c ---
   linux/drivers/media/usb/dvb-usb-v2/af9035.c2013-01-07
   05:45:57.0 +0100 +++
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.c2013-02-08
   22:55:08.304089054 +0100 @@ -232,7 +232,11 @@ static int
   af9035_i2c_master_xfer(struct
   
  buf[3] = 0x00; /* reg addr MSB */
  buf[4] = 0x00; /* reg addr LSB */
  memcpy(buf[5], msg[0].buf, msg[0].len);
   
   -  ret = af9035_ctrl_msg(d, req);
   +  if (state-block_read) {
   +  msg[1].buf[0] = 0x3f;
   +  ret = 0;
   +  } else
   +  ret = af9035_ctrl_msg(d, req);
   
  }
  
  } else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
  
  if (msg[0].len  40) {
   
   @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
   
  for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
  
  state-af9033_config[i].clock = clock_lut[tmp];
   
   +  state-block_read = false;
   +
   +  if (le16_to_cpu(d-udev-descriptor.idVendor) ==
   USB_VID_AVERMEDIA
   
   +  le16_to_cpu(d-udev-descriptor.idProduct) ==
   +  USB_PID_AVERMEDIA_TWINSTAR) {
   +  dev_dbg(d-udev-dev,
   +  %s: AverMedia Twinstar: block i2c read 
   from tuner\n,
   +  __func__);
   +  state-block_read = true;
   +  }
   +
   
  return 0;

err:
   diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.h ---
   linux/drivers/media/usb/dvb-usb-v2/af9035.h2013-01-07
   05:45:57.0 +0100 +++
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.h2013-02-08
   22:52:42.293842710 +0100 @@ -54,6 +54,7 @@ struct usb_req {
   
struct state {

  u8 seq; /* packet sequence number */
  bool dual_mode;
   
   +  bool block_read;
   
  struct af9033_config af9033_config[2];

};
   
   Could you test if faking tuner ID during attach() is enough?
   
   Also, I would like to know what is returned error code from
   firmware
   when it fails. Enable debugs to see it. It should print something
   like
   that: af9035_ctrl_msg: command=03 failed fw error=2
   
   
   diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
   b/drivers/media/usb/dvb-usb-v2/af9035.c
   index a1e953a..5a4f28d 100644
   --- a/drivers/media/usb/dvb-usb-v2/af9035.c
   +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
   @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
   dvb_usb_adapter *adap)
   
   tuner_addr = 0x60 | 0x80; /* I2C bus
   hack
   */
   
   }
   
   +   // fake used tuner for demod firmware / i2c
   adapter
   +   if (adap-id == 0)
   +   ret = af9035_wr_reg(d, 0x00f641,
   AF9033_TUNER_FC0011);
   +   else
   +   ret = af9035_wr_reg(d, 0x10f641,
   AF9033_TUNER_FC0011);
   +
   
   /* attach tuner */
   fe = dvb_attach(mxl5007t_attach, adap-fe[0],
   d-i2c_adap,
   
   tuner_addr,
   
   af9035_mxl5007t_config[adap-id]);
   +
   +   // return correct tuner
   +   if (adap-id == 0)
   +   ret = af9035_wr_reg(d, 0x00f641,
   AF9033_TUNER_MXL5007T);
   +   else
   +   ret = af9035_wr_reg(d, 0x10f641,
   AF9033_TUNER_MXL5007T);
   +
   
   break;
   
   case AF9033_TUNER_TDA18218:
   /* attach tuner */
   
   regards
   Antti
   
   I will try with fake tuner, but I can't test unil

Re: [PATCH] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

On Domingo, 17 de marzo de 2013 23:46:06 Antti Palosaari escribió:
 On 03/17/2013 08:49 PM, Jose Alberto Reguero wrote:
  On Martes, 12 de marzo de 2013 00:11:38 Antti Palosaari escribió:
  On 03/11/2013 10:02 PM, Jose Alberto Reguero wrote:
  On Lunes, 11 de marzo de 2013 14:57:37 Antti Palosaari escribió:
  On 03/11/2013 01:51 PM, Jose Alberto Reguero wrote:
  On Lunes, 11 de febrero de 2013 14:48:18 Jose Alberto Reguero 
escribió:
  On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari escribió:
  On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
  This patch block the i2c tuner reads for Avermedia Twinstar. If
  it's
  needed other pids can be added.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.c  2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c  2013-02-08
  22:55:08.304089054 +0100 @@ -232,7 +232,11 @@ static int
  af9035_i2c_master_xfer(struct
  
   buf[3] = 0x00; /* reg addr MSB */
   buf[4] = 0x00; /* reg addr LSB */
   memcpy(buf[5], msg[0].buf, msg[0].len);
  
  -ret = af9035_ctrl_msg(d, req);
  +if (state-block_read) {
  +msg[1].buf[0] = 0x3f;
  +ret = 0;
  +} else
  +ret = af9035_ctrl_msg(d, req);
  
   }
   
   } else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
   
   if (msg[0].len  40) {
  
  @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
  
   for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
   
   state-af9033_config[i].clock = clock_lut[tmp];
  
  +state-block_read = false;
  +
  +if (le16_to_cpu(d-udev-descriptor.idVendor) ==
  USB_VID_AVERMEDIA
  
  +le16_to_cpu(d-udev-descriptor.idProduct) ==
  +USB_PID_AVERMEDIA_TWINSTAR) {
  +dev_dbg(d-udev-dev,
  +%s: AverMedia Twinstar: block i2c read 
  from tuner\n,
  +__func__);
  +state-block_read = true;
  +}
  +
  
   return 0;
   
   err:
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.h  2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h  2013-02-08
  22:52:42.293842710 +0100 @@ -54,6 +54,7 @@ struct usb_req {
  
   struct state {
   
   u8 seq; /* packet sequence number */
   bool dual_mode;
  
  +bool block_read;
  
   struct af9033_config af9033_config[2];
   
   };
  
  Could you test if faking tuner ID during attach() is enough?
  
  Also, I would like to know what is returned error code from firmware
  when it fails. Enable debugs to see it. It should print something
  like
  that: af9035_ctrl_msg: command=03 failed fw error=2
  
  
  diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
  b/drivers/media/usb/dvb-usb-v2/af9035.c
  index a1e953a..5a4f28d 100644
  --- a/drivers/media/usb/dvb-usb-v2/af9035.c
  +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
  @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
  dvb_usb_adapter *adap)
  
  tuner_addr = 0x60 | 0x80; /* I2C bus
  hack
  */
  
  }
  
  +   // fake used tuner for demod firmware / i2c adapter
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_FC0011);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_FC0011);
  +
  
  /* attach tuner */
  fe = dvb_attach(mxl5007t_attach, adap-fe[0],
  d-i2c_adap,
  
  tuner_addr,
  
  af9035_mxl5007t_config[adap-id]);
  +
  +   // return correct tuner
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_MXL5007T);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_MXL5007T);
  +
  
  break;
  
  case AF9033_TUNER_TDA18218:
  /* attach tuner */
  
  regards
  Antti
  
  I will try with fake tuner, but I can't test unil next weekend.
  If I remember, the read operation is performed, and return good
  value,
  but after that, all the i2c transfers fail. Seee:
  
  http://www.mail

Re: [PATCH] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

On Martes, 12 de marzo de 2013 00:11:38 Antti Palosaari escribió:
 On 03/11/2013 10:02 PM, Jose Alberto Reguero wrote:
  On Lunes, 11 de marzo de 2013 14:57:37 Antti Palosaari escribió:
  On 03/11/2013 01:51 PM, Jose Alberto Reguero wrote:
  On Lunes, 11 de febrero de 2013 14:48:18 Jose Alberto Reguero escribió:
  On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari escribió:
  On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
  This patch block the i2c tuner reads for Avermedia Twinstar. If it's
  needed other pids can be added.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.c2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c2013-02-08
  22:55:08.304089054 +0100 @@ -232,7 +232,11 @@ static int
  af9035_i2c_master_xfer(struct
  
 buf[3] = 0x00; /* reg addr MSB */
 buf[4] = 0x00; /* reg addr LSB */
 memcpy(buf[5], msg[0].buf, msg[0].len);
  
  -  ret = af9035_ctrl_msg(d, req);
  +  if (state-block_read) {
  +  msg[1].buf[0] = 0x3f;
  +  ret = 0;
  +  } else
  +  ret = af9035_ctrl_msg(d, req);
  
 }
 
 } else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
 
 if (msg[0].len  40) {
  
  @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
  
 for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
 
 state-af9033_config[i].clock = clock_lut[tmp];
  
  +  state-block_read = false;
  +
  +  if (le16_to_cpu(d-udev-descriptor.idVendor) == 
  USB_VID_AVERMEDIA
  
  +  le16_to_cpu(d-udev-descriptor.idProduct) ==
  +  USB_PID_AVERMEDIA_TWINSTAR) {
  +  dev_dbg(d-udev-dev,
  +  %s: AverMedia Twinstar: block i2c read 
  from tuner\n,
  +  __func__);
  +  state-block_read = true;
  +  }
  +
  
 return 0;
  
  err:
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.h2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h2013-02-08
  22:52:42.293842710 +0100 @@ -54,6 +54,7 @@ struct usb_req {
  
  struct state {
  
 u8 seq; /* packet sequence number */
 bool dual_mode;
  
  +  bool block_read;
  
 struct af9033_config af9033_config[2];
  
  };
  
  Could you test if faking tuner ID during attach() is enough?
  
  Also, I would like to know what is returned error code from firmware
  when it fails. Enable debugs to see it. It should print something like
  that: af9035_ctrl_msg: command=03 failed fw error=2
  
  
  diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
  b/drivers/media/usb/dvb-usb-v2/af9035.c
  index a1e953a..5a4f28d 100644
  --- a/drivers/media/usb/dvb-usb-v2/af9035.c
  +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
  @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
  dvb_usb_adapter *adap)
  
 tuner_addr = 0x60 | 0x80; /* I2C bus hack
 */
 
 }
  
  +   // fake used tuner for demod firmware / i2c adapter
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_FC0011);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_FC0011);
  +
  
 /* attach tuner */
 fe = dvb_attach(mxl5007t_attach, adap-fe[0],
 d-i2c_adap,
 
 tuner_addr,
  
  af9035_mxl5007t_config[adap-id]);
  +
  +   // return correct tuner
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_MXL5007T);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_MXL5007T);
  +
  
 break;
 
 case AF9033_TUNER_TDA18218:
 /* attach tuner */
  
  regards
  Antti
  
  I will try with fake tuner, but I can't test unil next weekend.
  If I remember, the read operation is performed, and return good value,
  but after that, all the i2c transfers fail. Seee:
  
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg56346.html
  
  Jose Alberto
  
  I tried with fake tuner without success:
  
  [ 1346.707405] DVB: registering new adapter (AVerMedia Twinstar (A825))
  [ 1346.959043] i2c i2c-1: af9033

Re: [PATCH] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

On Lunes, 11 de febrero de 2013 14:48:18 Jose Alberto Reguero escribió:
 On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari escribió:
  On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
   This patch block the i2c tuner reads for Avermedia Twinstar. If it's
   needed other pids can be added.
   
   Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
   
   diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.c ---
   linux/drivers/media/usb/dvb-usb-v2/af9035.c   2013-01-07
   05:45:57.0 +0100 +++
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.c   2013-02-08
   22:55:08.304089054 +0100 @@ -232,7 +232,11 @@ static int
   af9035_i2c_master_xfer(struct
   
 buf[3] = 0x00; /* reg addr MSB */
 buf[4] = 0x00; /* reg addr LSB */
 memcpy(buf[5], msg[0].buf, msg[0].len);
   
   - ret = af9035_ctrl_msg(d, req);
   + if (state-block_read) {
   + msg[1].buf[0] = 0x3f;
   + ret = 0;
   + } else
   + ret = af9035_ctrl_msg(d, req);
   
 }
 
 } else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
 
 if (msg[0].len  40) {
   
   @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
   
 for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
 
 state-af9033_config[i].clock = clock_lut[tmp];
   
   + state-block_read = false;
   +
   + if (le16_to_cpu(d-udev-descriptor.idVendor) == USB_VID_AVERMEDIA 
   + le16_to_cpu(d-udev-descriptor.idProduct) ==
   + USB_PID_AVERMEDIA_TWINSTAR) {
   + dev_dbg(d-udev-dev,
   + %s: AverMedia Twinstar: block i2c read from 
   tuner\n,
   + __func__);
   + state-block_read = true;
   + }
   +
   
 return 0;
 
 err:
   diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.h ---
   linux/drivers/media/usb/dvb-usb-v2/af9035.h   2013-01-07
   05:45:57.0 +0100 +++
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.h   2013-02-08
   22:52:42.293842710 +0100 @@ -54,6 +54,7 @@ struct usb_req {
   
 struct state {
 
 u8 seq; /* packet sequence number */
 bool dual_mode;
   
   + bool block_read;
   
 struct af9033_config af9033_config[2];
 
 };
  
  Could you test if faking tuner ID during attach() is enough?
  
  Also, I would like to know what is returned error code from firmware
  when it fails. Enable debugs to see it. It should print something like
  that: af9035_ctrl_msg: command=03 failed fw error=2
  
  
  diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
  b/drivers/media/usb/dvb-usb-v2/af9035.c
  index a1e953a..5a4f28d 100644
  --- a/drivers/media/usb/dvb-usb-v2/af9035.c
  +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
  @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
  dvb_usb_adapter *adap)
  
   tuner_addr = 0x60 | 0x80; /* I2C bus hack */
   
   }
  
  +   // fake used tuner for demod firmware / i2c adapter
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_FC0011);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_FC0011);
  +
  
   /* attach tuner */
   fe = dvb_attach(mxl5007t_attach, adap-fe[0],
   d-i2c_adap,
   
   tuner_addr,
  
  af9035_mxl5007t_config[adap-id]);
  +
  +   // return correct tuner
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_MXL5007T);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_MXL5007T);
  +
  
   break;
   
   case AF9033_TUNER_TDA18218:
   /* attach tuner */
  
  regards
  Antti
 
 I will try with fake tuner, but I can't test unil next weekend.
 If I remember, the read operation is performed, and return good value,
 but after that, all the i2c transfers fail. Seee:
 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg56346.html
 
 Jose Alberto
 


I tried with fake tuner without success:

[ 1346.707405] DVB: registering new adapter (AVerMedia Twinstar (A825))
[ 1346.959043] i2c i2c-1: af9033: firmware version: LINK=11.5.9.0 
OFDM=5.17.9.1
[ 1346.962920] usb 1-2: DVB: registering adapter 0 frontend 0 (Afatech AF9033 
(DVB-T))...
[ 1347.439354] mxl5007t 1-0060: creating new instance
[ 1347.440644] mxl5007t_get_chip_id: unknown rev (3f)
[ 1347.440652] mxl5007t_get_chip_id: MxL5007T

Re: [PATCH] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

On Lunes, 11 de marzo de 2013 14:57:37 Antti Palosaari escribió:
 On 03/11/2013 01:51 PM, Jose Alberto Reguero wrote:
  On Lunes, 11 de febrero de 2013 14:48:18 Jose Alberto Reguero escribió:
  On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari escribió:
  On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
  This patch block the i2c tuner reads for Avermedia Twinstar. If it's
  needed other pids can be added.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.c  2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c  2013-02-08
  22:55:08.304089054 +0100 @@ -232,7 +232,11 @@ static int
  af9035_i2c_master_xfer(struct
  
   buf[3] = 0x00; /* reg addr MSB */
   buf[4] = 0x00; /* reg addr LSB */
   memcpy(buf[5], msg[0].buf, msg[0].len);
  
  -ret = af9035_ctrl_msg(d, req);
  +if (state-block_read) {
  +msg[1].buf[0] = 0x3f;
  +ret = 0;
  +} else
  +ret = af9035_ctrl_msg(d, req);
  
   }
   
   } else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
   
   if (msg[0].len  40) {
  
  @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
  
   for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
   
   state-af9033_config[i].clock = clock_lut[tmp];
  
  +state-block_read = false;
  +
  +if (le16_to_cpu(d-udev-descriptor.idVendor) == 
  USB_VID_AVERMEDIA 
  +le16_to_cpu(d-udev-descriptor.idProduct) ==
  +USB_PID_AVERMEDIA_TWINSTAR) {
  +dev_dbg(d-udev-dev,
  +%s: AverMedia Twinstar: block i2c read 
  from tuner\n,
  +__func__);
  +state-block_read = true;
  +}
  +
  
   return 0;
 
 err:
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h ---
  linux/drivers/media/usb/dvb-usb-v2/af9035.h  2013-01-07
  05:45:57.0 +0100 +++
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.h  2013-02-08
  22:52:42.293842710 +0100 @@ -54,6 +54,7 @@ struct usb_req {
  
 struct state {
 
   u8 seq; /* packet sequence number */
   bool dual_mode;
  
  +bool block_read;
  
   struct af9033_config af9033_config[2];
 
 };
  
  Could you test if faking tuner ID during attach() is enough?
  
  Also, I would like to know what is returned error code from firmware
  when it fails. Enable debugs to see it. It should print something like
  that: af9035_ctrl_msg: command=03 failed fw error=2
  
  
  diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
  b/drivers/media/usb/dvb-usb-v2/af9035.c
  index a1e953a..5a4f28d 100644
  --- a/drivers/media/usb/dvb-usb-v2/af9035.c
  +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
  @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
  dvb_usb_adapter *adap)
  
tuner_addr = 0x60 | 0x80; /* I2C bus hack */

}
  
  +   // fake used tuner for demod firmware / i2c adapter
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_FC0011);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_FC0011);
  +
  
/* attach tuner */
fe = dvb_attach(mxl5007t_attach, adap-fe[0],
d-i2c_adap,

tuner_addr,
  
  af9035_mxl5007t_config[adap-id]);
  +
  +   // return correct tuner
  +   if (adap-id == 0)
  +   ret = af9035_wr_reg(d, 0x00f641,
  AF9033_TUNER_MXL5007T);
  +   else
  +   ret = af9035_wr_reg(d, 0x10f641,
  AF9033_TUNER_MXL5007T);
  +
  
break;

case AF9033_TUNER_TDA18218:
/* attach tuner */
  
  regards
  Antti
  
  I will try with fake tuner, but I can't test unil next weekend.
  If I remember, the read operation is performed, and return good value,
  but after that, all the i2c transfers fail. Seee:
  
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg56346.html
  
  Jose Alberto
  
  I tried with fake tuner without success:
  
  [ 1346.707405] DVB: registering new adapter (AVerMedia Twinstar (A825))
  [ 1346.959043] i2c i2c-1: af9033: firmware version: LINK=11.5.9.0
  OFDM=5.17.9.1
  [ 1346.962920] usb 1-2: DVB: registering adapter 0 frontend 0

[PATH] enable dual tuner to Avermedia Twinstar in af9035 driver

[Jose Alberto Reguero]

This patch enable dual tuner for Avermedia Twinstar.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0 
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-02-10 
20:27:26.880926695 +0100
@@ -602,6 +602,7 @@ static int af9035_read_config(struct dvb
if (i == 1)
switch (tmp) {
case AF9033_TUNER_FC0012:
+   case AF9033_TUNER_MXL5007T:
break;
default:
state-dual_mode = false;
 
--
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] block i2c tuner reads for Avermedia Twinstar in the af9035 driver

[Jose Alberto Reguero]

This patch block the i2c tuner reads for Avermedia Twinstar. If it's
needed other pids can be added.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0 
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-02-08 
22:55:08.304089054 +0100
@@ -232,7 +232,11 @@ static int af9035_i2c_master_xfer(struct
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
memcpy(buf[5], msg[0].buf, msg[0].len);
-   ret = af9035_ctrl_msg(d, req);
+   if (state-block_read) {
+   msg[1].buf[0] = 0x3f;
+   ret = 0;
+   } else
+   ret = af9035_ctrl_msg(d, req);
}
} else if (num == 1  !(msg[0].flags  I2C_M_RD)) {
if (msg[0].len  40) {
@@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
for (i = 0; i  ARRAY_SIZE(state-af9033_config); i++)
state-af9033_config[i].clock = clock_lut[tmp];
 
+   state-block_read = false;
+
+   if (le16_to_cpu(d-udev-descriptor.idVendor) == USB_VID_AVERMEDIA 
+   le16_to_cpu(d-udev-descriptor.idProduct) ==
+   USB_PID_AVERMEDIA_TWINSTAR) {
+   dev_dbg(d-udev-dev,
+   %s: AverMedia Twinstar: block i2c read from 
tuner\n,
+   __func__);
+   state-block_read = true;
+   }
+
return 0;
 
 err:
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.h
--- linux/drivers/media/usb/dvb-usb-v2/af9035.h 2013-01-07 05:45:57.0 
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.h 2013-02-08 
22:52:42.293842710 +0100
@@ -54,6 +54,7 @@ struct usb_req {
 struct state {
u8 seq; /* packet sequence number */
bool dual_mode;
+   bool block_read;
struct af9033_config af9033_config[2];
 };
 


--
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: af9035 test needed!

[Jose Alberto Reguero]

On Sábado, 2 de febrero de 2013 23:00:45 Michael Krufky escribió:
 On Fri, Jan 11, 2013 at 6:45 PM, Jose Alberto Reguero
 
 jaregu...@telefonica.net wrote:
  On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
  Hello Jose and Gianluca
  
  Could you test that (tda18218  mxl5007t):
  http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
  une r
  
  I wonder if ADC config logic still works for superheterodyne tuners
  (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
  That makes me wonder it possible breaks tuners having IF, as ADC was
  clocked just over 20MHz and if it is half then it is 10MHz. For BB that
  is enough, but I think that having IF, which is 4MHz at least for 8MHz
  BW it is too less.
  
  F*ck I hate to maintain driver without a hardware! Any idea where I can
  get AF9035 device having tda18218 or mxl5007t?
  
  regards
  Antti
  
  Still pending the changes for  mxl5007t. Attached is a patch for that.
  
  Changes to make work Avermedia Twinstar with the af9035 driver.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  Jose Alberto
  
  diff -upr linux/drivers/media/tuners/mxl5007t.c
  linux.new/drivers/media/tuners/mxl5007t.c
  --- linux/drivers/media/tuners/mxl5007t.c   2012-08-14
  05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c  
  2013-01-10 19:23:09.247556275 +0100
  @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
  
  mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
  mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
  
  -   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
  
  set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 
  3);
  set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
 
 This is a configurable option - it should not be removed, just
 configure your glue code to not use that option if you dont want
 it unless there's some other reason why you're removing this?


I just move the code to a mxl5007t_attach because with dual tuner until the 
code is executed, the other tuner don't work. It can be left here also.

  @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
  
  struct reg_pair_t *init_regs;
  int ret;
  
  -   ret = mxl5007t_soft_reset(state);
  -   if (mxl_fail(ret))
  +   if (!state-config-no_reset) {
  +   ret = mxl5007t_soft_reset(state);
  +   if (mxl_fail(ret))
  
  goto fail;
  
  +   }
  +
 
 this seems wrong to me.  why would you want to prevent the driver from
 doing a soft reset?


That is because with my hardware and dual tuner, when one tuner do reset, the 
other one is perturbed, and the stream has errors.

  /* calculate initialization reg array */
  init_regs = mxl5007t_calc_init_regs(state, mode);
  
  @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 1);
  
  -   ret = mxl5007t_get_chip_id(state);
  +   if (!state-config-no_probe)
  +   ret = mxl5007t_get_chip_id(state);
  +
  +   ret = mxl5007t_write_reg(state, 0x04,
  +   state-config-loop_thru_enable);
  +
 
 Can you explain why this change was made?  ^^


mxl5007t_get_chip_id has a read, and with the hardware I have, after the read 
operation is made, communication with the chip don't work.
 
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 0);
  
  diff -upr linux/drivers/media/tuners/mxl5007t.h
  linux.new/drivers/media/tuners/mxl5007t.h
  --- linux/drivers/media/tuners/mxl5007t.h   2012-08-14
  05:45:22.0 +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h  
  2013-01-10 19:19:11.204379581 +0100
  @@ -73,8 +73,10 @@ struct mxl5007t_config {
  
  enum mxl5007t_xtal_freq xtal_freq_hz;
  enum mxl5007t_if_freq if_freq_hz;
  unsigned int invert_if:1;
  
  -   unsigned int loop_thru_enable:1;
  +   unsigned int loop_thru_enable:3;
 
 Why widen this boolean to three bits?


I just use the value 3 for this option(taken from windows driver) and it works 
well.
 

Thanks for review the code.

Jose Alberto

  unsigned int clk_out_enable:1;
  
  +   unsigned int no_probe:1;
  +   unsigned int no_reset:1;
  
   };
   
   #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
  
  (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
  --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
  05:45:57.0 +0100
  +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
  00:30:57.557310465 +0100
  @@ -886,13 +886,17 @@ static struct

[PATH 1/2] mxl5007 move reset to attach

[Jose Alberto Reguero]

This patch move the soft reset to the attach function because with dual
tuners, when one tuner do reset, the other one is perturbed, and the 
stream has errors.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

diff -upr linux/drivers/media/tuners/mxl5007t.c 
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c   2013-02-03 23:03:03.784525410 
+0100
@@ -531,10 +531,6 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
 
-   ret = mxl5007t_soft_reset(state);
-   if (mxl_fail(ret))
-   goto fail;
-
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
 
@@ -900,7 +896,20 @@ struct dvb_frontend *mxl5007t_attach(str
/* existing tuner instance */
break;
}
+
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 1);
+
+   ret = mxl5007t_soft_reset(state);
+
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 0);
+
+   if (mxl_fail(ret))
+   goto fail;
+
fe-tuner_priv = state;
+
mutex_unlock(mxl5007t_list_mutex);
 
memcpy(fe-ops.tuner_ops, mxl5007t_tuner_ops,

--
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

[PATH 2/2] mxl5007 move loop_thru to attach

[Jose Alberto Reguero]

This patch move the loop_thru configuration to the attach function,
because with dual tuners until loop_tru configuration the other tuner
don't work.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

diff -upr linux/drivers/media/tuners/mxl5007t.c 
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c   2013-02-03 23:16:08.031628907 
+0100
+++ linux.new/drivers/media/tuners/mxl5007t.c   2013-02-03 23:14:12.196089297 
+0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
 
-   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
 
@@ -908,6 +907,18 @@ struct dvb_frontend *mxl5007t_attach(str
if (mxl_fail(ret))
goto fail;
 
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 1);
+
+   ret = mxl5007t_write_reg(state, 0x04,
+   state-config-loop_thru_enable);
+
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 0);
+
+   if (mxl_fail(ret))
+   goto fail;
+
fe-tuner_priv = state;
 
mutex_unlock(mxl5007t_list_mutex);

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add lock to af9035 driver for dual mode

[Jose Alberto Reguero]

On Jueves, 24 de enero de 2013 00:36:25 Antti Palosaari escribió:
 On 01/24/2013 12:34 AM, Jose Alberto Reguero wrote:
  Add lock to af9035 driver for dual mode.
 
 May I ask why you do that?
 
 regards
 Antti


Just to avoid interference between the two demods.

Jose Alberto

  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
  --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
  05:45:57.0 +0100
  +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-23
  23:18:18.544788327 +0100
  @@ -824,6 +824,104 @@ static int af9035_get_adapter_count(stru
  
  return state-dual_mode + 1;

}
  
  +static int af9035_lock_set_frontend(struct dvb_frontend* fe)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].set_frontend(fe);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_get_frontend(struct dvb_frontend* fe)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].get_frontend(fe);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_read_status(struct dvb_frontend* fe, fe_status_t*
  status)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].read_status(fe, status);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_read_ber(struct dvb_frontend* fe, u32* ber)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].read_ber(fe, ber);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_read_signal_strength(struct dvb_frontend* fe, u16*
  strength)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].read_signal_strength(fe,
  strength); +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_read_snr(struct dvb_frontend* fe, u16* snr)
  +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].read_snr(fe, snr);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  +static int af9035_lock_read_ucblocks(struct dvb_frontend* fe, u32*
  ucblocks) +{
  +   int result;
  +   struct dvb_usb_adapter *adap = fe_to_adap(fe);
  +   struct state *state = adap_to_priv(adap);
  +
  +   if (mutex_lock_interruptible(state-fe_mutex))
  +   return -EAGAIN;
  +
  +   result = state-fe_ops[adap-id].read_ucblocks(fe, ucblocks);
  +   mutex_unlock(state-fe_mutex);
  +   return result;
  +}
  +
  
static int af9035_frontend_attach(struct dvb_usb_adapter *adap)
{

  struct state *state = adap_to_priv(adap);
  
  @@ -862,6 +960,22 @@ static int af9035_frontend_attach(struct
  
  adap-fe[0]-ops.i2c_gate_ctrl = NULL;
  adap-fe[0]-callback = af9035_frontend_callback;
  
  +   memcpy(state-fe_ops[adap-id], adap-fe[0]-ops, sizeof(struct
  dvb_frontend_ops));
  +   if (adap-fe[0]-ops.set_frontend)
  +   adap-fe[0]-ops.set_frontend = af9035_lock_set_frontend;
  +   if (adap-fe[0]-ops.get_frontend)
  +   adap-fe[0]-ops.get_frontend = af9035_lock_get_frontend;
  +   if (adap-fe[0]-ops.read_status)
  +   adap-fe[0]-ops.read_status = af9035_lock_read_status;
  +   if (adap-fe[0]-ops.read_ber)
  +   adap-fe[0]-ops.read_ber = af9035_lock_read_ber;
  +   if (adap-fe[0]-ops.read_signal_strength)
  +   adap-fe[0]-ops.read_signal_strength =
  af9035_lock_read_signal_strength;
  +   if (adap-fe[0]-ops.read_snr)
  +   adap-fe[0]-ops.read_snr = af9035_lock_read_snr;
  +   if (adap-fe

Re: af9035 test needed!

[Jose Alberto Reguero]

On Sábado, 12 de enero de 2013 22:14:07 Jose Alberto Reguero escribió:
 On Sábado, 12 de enero de 2013 01:49:21 Antti Palosaari escribió:
  On 01/12/2013 01:45 AM, Jose Alberto Reguero wrote:
   On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
   Hello Jose and Gianluca
   
   Could you test that (tda18218  mxl5007t):
   http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
   une r
   
   I wonder if ADC config logic still works for superheterodyne tuners
   (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
   That makes me wonder it possible breaks tuners having IF, as ADC was
   clocked just over 20MHz and if it is half then it is 10MHz. For BB that
   is enough, but I think that having IF, which is 4MHz at least for 8MHz
   BW it is too less.
   
   F*ck I hate to maintain driver without a hardware! Any idea where I can
   get AF9035 device having tda18218 or mxl5007t?
   
   regards
   Antti
   
   Still pending the changes for  mxl5007t. Attached is a patch for that.
   
   Changes to make work Avermedia Twinstar with the af9035 driver.
   
   Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  I cannot do much about this as it changes mxl5007t driver which is not
  maintained by me. :)
  
  regards
  Antti
 
 
 Adding CC to Michael Krufky because it is the maintainer of mxl5007t driver. 
 Michael, any chance to get this patch merged?
 
 Jose Alberto
   
   Jose Alberto
   
   diff -upr linux/drivers/media/tuners/mxl5007t.c
   linux.new/drivers/media/tuners/mxl5007t.c
   --- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
   +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c   2013-01-10
   19:23:09.247556275 +0100
   @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
   
 mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, 
   cfg-invert_if);
 mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
   
   - set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
   
 set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 
3);
 set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
   
   @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
   
 struct reg_pair_t *init_regs;
 int ret;
   
   - ret = mxl5007t_soft_reset(state);
   - if (mxl_fail(ret))
   + if (!state-config-no_reset) {
   + ret = mxl5007t_soft_reset(state);
   + if (mxl_fail(ret))
   
 goto fail;
   
   + }
   +
   
 /* calculate initialization reg array */
 init_regs = mxl5007t_calc_init_regs(state, mode);
   
   @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
   
 if (fe-ops.i2c_gate_ctrl)
 
 fe-ops.i2c_gate_ctrl(fe, 1);
   
   - ret = mxl5007t_get_chip_id(state);
   + if (!state-config-no_probe)
   + ret = mxl5007t_get_chip_id(state);
   +
   + ret = mxl5007t_write_reg(state, 0x04,
   + state-config-loop_thru_enable);
   +
   
 if (fe-ops.i2c_gate_ctrl)
 
 fe-ops.i2c_gate_ctrl(fe, 0);
   
   diff -upr linux/drivers/media/tuners/mxl5007t.h
   linux.new/drivers/media/tuners/mxl5007t.h
   --- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
   +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h   2013-01-10
   19:19:11.204379581 +0100
   @@ -73,8 +73,10 @@ struct mxl5007t_config {
   
 enum mxl5007t_xtal_freq xtal_freq_hz;
 enum mxl5007t_if_freq if_freq_hz;
 unsigned int invert_if:1;
   
   - unsigned int loop_thru_enable:1;
   + unsigned int loop_thru_enable:3;
   
 unsigned int clk_out_enable:1;
   
   + unsigned int no_probe:1;
   + unsigned int no_reset:1;
   
 };
 
 #if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
   
   (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
   diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
   linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
   --- linux/drivers/media/usb/dvb-usb-v2/af9035.c   2013-01-07
   05:45:57.0 +0100
   +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c   2013-01-12
   00:30:57.557310465 +0100
   @@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
   
 .loop_thru_enable = 0,
 .clk_out_enable = 0,
 .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
   
   + .no_probe = 1,
   + .no_reset = 1,
   
 }, {
 
 .xtal_freq_hz = MxL_XTAL_24_MHZ,
 .if_freq_hz = MxL_IF_4_57_MHZ,
 .invert_if = 0,
   
   - .loop_thru_enable = 1,
   + .loop_thru_enable = 3,
   
 .clk_out_enable = 1,
 .clk_out_amp

Re: af9035 test needed!

[Jose Alberto Reguero]

On Sábado, 12 de enero de 2013 01:49:21 Antti Palosaari escribió:
 On 01/12/2013 01:45 AM, Jose Alberto Reguero wrote:
  On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
  Hello Jose and Gianluca
  
  Could you test that (tda18218  mxl5007t):
  http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_t
  une r
  
  I wonder if ADC config logic still works for superheterodyne tuners
  (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
  That makes me wonder it possible breaks tuners having IF, as ADC was
  clocked just over 20MHz and if it is half then it is 10MHz. For BB that
  is enough, but I think that having IF, which is 4MHz at least for 8MHz
  BW it is too less.
  
  F*ck I hate to maintain driver without a hardware! Any idea where I can
  get AF9035 device having tda18218 or mxl5007t?
  
  regards
  Antti
  
  Still pending the changes for  mxl5007t. Attached is a patch for that.
  
  Changes to make work Avermedia Twinstar with the af9035 driver.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
 
 I cannot do much about this as it changes mxl5007t driver which is not
 maintained by me. :)
 
 regards
 Antti


Adding CC to Michael Krufky because it is the maintainer of mxl5007t driver. 
Michael, any chance to get this patch merged?

Jose Alberto
  
  Jose Alberto
  
  diff -upr linux/drivers/media/tuners/mxl5007t.c
  linux.new/drivers/media/tuners/mxl5007t.c
  --- linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0
  +0200 +++ linux.new/drivers/media/tuners/mxl5007t.c 2013-01-10
  19:23:09.247556275 +0100
  @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
  
  mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
  mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
  
  -   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
  
  set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
  set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
  
  @@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
  
  struct reg_pair_t *init_regs;
  int ret;
  
  -   ret = mxl5007t_soft_reset(state);
  -   if (mxl_fail(ret))
  +   if (!state-config-no_reset) {
  +   ret = mxl5007t_soft_reset(state);
  +   if (mxl_fail(ret))
  
  goto fail;
  
  +   }
  +
  
  /* calculate initialization reg array */
  init_regs = mxl5007t_calc_init_regs(state, mode);
  
  @@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 1);
  
  -   ret = mxl5007t_get_chip_id(state);
  +   if (!state-config-no_probe)
  +   ret = mxl5007t_get_chip_id(state);
  +
  +   ret = mxl5007t_write_reg(state, 0x04,
  +   state-config-loop_thru_enable);
  +
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 0);
  
  diff -upr linux/drivers/media/tuners/mxl5007t.h
  linux.new/drivers/media/tuners/mxl5007t.h
  --- linux/drivers/media/tuners/mxl5007t.h   2012-08-14 05:45:22.0
  +0200 +++ linux.new/drivers/media/tuners/mxl5007t.h 2013-01-10
  19:19:11.204379581 +0100
  @@ -73,8 +73,10 @@ struct mxl5007t_config {
  
  enum mxl5007t_xtal_freq xtal_freq_hz;
  enum mxl5007t_if_freq if_freq_hz;
  unsigned int invert_if:1;
  
  -   unsigned int loop_thru_enable:1;
  +   unsigned int loop_thru_enable:3;
  
  unsigned int clk_out_enable:1;
  
  +   unsigned int no_probe:1;
  +   unsigned int no_reset:1;
  
};

#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
  
  (defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
  diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
  linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
  --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
  05:45:57.0 +0100
  +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12
  00:30:57.557310465 +0100
  @@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
  
  .loop_thru_enable = 0,
  .clk_out_enable = 0,
  .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
  
  +   .no_probe = 1,
  +   .no_reset = 1,
  
  }, {
  
  .xtal_freq_hz = MxL_XTAL_24_MHZ,
  .if_freq_hz = MxL_IF_4_57_MHZ,
  .invert_if = 0,
  
  -   .loop_thru_enable = 1,
  +   .loop_thru_enable = 3,
  
  .clk_out_enable = 1,
  .clk_out_amp = MxL_CLKOUT_AMP_0_94V,
  
  +   .no_probe = 1,
  +   .no_reset = 1,
  
  }

};
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: af9035 test needed!

[Jose Alberto Reguero]

On Viernes, 11 de enero de 2013 20:38:01 Antti Palosaari escribió:
 Hello Jose and Gianluca
 
 Could you test that (tda18218  mxl5007t):
 http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/it9135_tune
 r
 
 I wonder if ADC config logic still works for superheterodyne tuners
 (tuner having IF). I changed it to adc / 2 always due to IT9135 tuner.
 That makes me wonder it possible breaks tuners having IF, as ADC was
 clocked just over 20MHz and if it is half then it is 10MHz. For BB that
 is enough, but I think that having IF, which is 4MHz at least for 8MHz
 BW it is too less.
 
 F*ck I hate to maintain driver without a hardware! Any idea where I can
 get AF9035 device having tda18218 or mxl5007t?
 
 regards
 Antti

Still pending the changes for  mxl5007t. Attached is a patch for that.

Changes to make work Avermedia Twinstar with the af9035 driver.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

diff -upr linux/drivers/media/tuners/mxl5007t.c 
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c   2013-01-10 19:23:09.247556275 
+0100
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
 
-   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
 
@@ -531,9 +530,12 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
 
-   ret = mxl5007t_soft_reset(state);
-   if (mxl_fail(ret))
+   if (!state-config-no_reset) {
+   ret = mxl5007t_soft_reset(state);
+   if (mxl_fail(ret))
goto fail;
+   }
+
 
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +889,12 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
 
-   ret = mxl5007t_get_chip_id(state);
+   if (!state-config-no_probe)
+   ret = mxl5007t_get_chip_id(state);
+
+   ret = mxl5007t_write_reg(state, 0x04,
+   state-config-loop_thru_enable);
+
 
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h 
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h   2013-01-10 19:19:11.204379581 
+0100
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
-   unsigned int loop_thru_enable:1;
+   unsigned int loop_thru_enable:3;
unsigned int clk_out_enable:1;
+   unsigned int no_probe:1;
+   unsigned int no_reset:1;
 };
 
 #if defined(CONFIG_MEDIA_TUNER_MXL5007T) || 
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07 05:45:57.0 
+0100
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-12 
00:30:57.557310465 +0100
@@ -886,13 +886,17 @@ static struct mxl5007t_config af9035_mxl
.loop_thru_enable = 0,
.clk_out_enable = 0,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+   .no_probe = 1,
+   .no_reset = 1,
}, {
.xtal_freq_hz = MxL_XTAL_24_MHZ,
.if_freq_hz = MxL_IF_4_57_MHZ,
.invert_if = 0,
-   .loop_thru_enable = 1,
+   .loop_thru_enable = 3,
.clk_out_enable = 1,
.clk_out_amp = MxL_CLKOUT_AMP_0_94V,
+   .no_probe = 1,
+   .no_reset = 1,
}
 };
 

 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v3 Add support to Avermedia Twinstar double tuner in af9035

[Jose Alberto Reguero]

On Martes, 1 de enero de 2013 16:51:21 Antti Palosaari escribió:
 Hello
 The origin of these errors is AF9035 I2C adapter (seems to be firmware
 based) could not perform all I2C operations mxl5007t driver does.
 mxl5007t_soft_reset() just writes single byte 0xff to the device = I
 assume AF9035 I2C adapter wants two bytes.
 
 Unfortunately mxl5007t driver does not report error code coming from the
 I2C adapter. I suspect it is EIO. You can see these errors reported by
 adapter just enabling AF9035 debugs.
 
 Without the hardware I cannot do much. It is up to someone with the hw
 to find out proper solution.
 
 Latest AF9035 tree, which contains dual tuner support is here
 http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/af9035
 I will pull request it very soon.
 
 regards
 Antti
 

The I2C errors begin after a I2C read in the mxl5007t probe. It is the only 
one I2C read of the mxl5007t driver. Without the read the drive works well. I 
will send again the patch with the no_probe option when the dual tuner code is 
accepted.

Jose Alberto
  
 On 12/18/2012 11:32 PM, Eddi De Pieri wrote:
  Hi Antti and Jose
  
  I'd like to advise you that I tested this path since it solve issue on
  other af9035 devices like avermedia a835 and avermedia a867.
  
  I mean:
  mxl5007t_soft_reset: 522: failed!
  mxl5007t_tuner_init: error -140 on line 535
  mxl5007t_set_params: error -140 on line 666
  mxl5007t_soft_reset: 522: failed!
  mxl5007t_tuner_init: error -140 on line 535
  mxl5007t_set_params: error -140 on line 666
  mxl5007t_soft_reset: 522: failed!
  mxl5007t_tuner_init: error -140 on line 535
  mxl5007t_set_params: error -140 on line 666
  mxl5007t_soft_reset: 522: failed!
  mxl5007t_tuner_init: error -140 on line 535
  mxl5007t_set_params: error -140 on line 666
  
  It seems that no_reset and no_probe configuration parameter added by
  jose is needed for mxl5007t initialization.
  
  I suppose that the initialization is already done by the af9035 firmware.
  
  Regards
  
  Eddi De Pieri
  
  On Sun, Sep 23, 2012 at 6:29 PM, Antti Palosaari cr...@iki.fi wrote:
  Hello Jose,
  Could you try to split and resent?
  
  I will get af9035 + fc0012 dual tuner next week and add support for it. I
  wish to use your patch for dual mode, but I as there is that unresolved
  MXL5007t dependency I cannot user it currently.
  
  regards
  Antti
  
  On 09/15/2012 08:45 PM, Antti Palosaari wrote:
  Hello
  Could you split that patch to 2?
  1) mxl5007t changes
  2) af9035/af9033 dual mode
  3) af9035/af9033 changes needed for mxl5007t
  
  I cannot say much about tuner changes, but I still wonder are those
  really needed as this device is already supported. Is it broken
  currently?
  What happens when no_probe = 0 ?
  What happens when no_reset = 0 ?
  
  Soft reset means usually resetting chip state machine. It is something
  like start operating command. First program registers then issue soft
  reset in order to restart state machine.
  
  regards
  Antti
  
  On 08/30/2012 02:02 AM, Jose Alberto Reguero wrote:
  This patch add support to the Avermedia Twinstar double tuner in the
  af9035
  driver. Version 3 of the patch.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  Jose Alberto
  
  diff -upr linux/drivers/media/dvb-frontends/af9033.c
  linux.new/drivers/media/dvb-frontends/af9033.c
  --- linux/drivers/media/dvb-frontends/af9033.c2012-08-14
  05:45:22.0 +0200
  +++ linux.new/drivers/media/dvb-frontends/af9033.c2012-08-29
  16:00:52.020523899 +0200
  @@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
  
 goto err;
 
 }
  
  +if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
  +ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
  +if (ret  0)
  +goto err;
  +ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
  +if (ret  0)
  +goto err;
  +ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
  +if (ret  0)
  +goto err;
  +}
  +
  
 state-bandwidth_hz = 0; /* force to program all parameters */
 
 return 0;
  
  diff -upr linux/drivers/media/tuners/mxl5007t.c
  linux.new/drivers/media/tuners/mxl5007t.c
  --- linux/drivers/media/tuners/mxl5007t.c2012-08-14
  05:45:22.0 +0200
  +++ linux.new/drivers/media/tuners/mxl5007t.c2012-08-29
  13:07:57.299884405 +0200
  @@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
  
 mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz,
 cfg-invert_if);
 mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
  
  -set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
  
 set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 
  
  3);
  
 set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
  
  @@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
  
 struct reg_pair_t

[PATCH] v4 Add support to Avermedia Twinstar double tuner in af9035

[Jose Alberto Reguero]

This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 4 of the patch. I split the patch as suggested by Antti. I send
the changes to mxl5007 driver in another patch.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

diff -upr linux/drivers/media/dvb-frontends/af9033.c 
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c  2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c  2012-09-13 
22:22:29.012301231 +0200
@@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
goto err;
}
 
+   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+   ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   }
+
state-bandwidth_hz = 0; /* force to program all parameters */
 
return 0;
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0 
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-09-23 
21:32:10.313657063 +0200
@@ -209,10 +209,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len  40 || msg[1].len  40) {
/* TODO: correct limits  40 */
ret = -EOPNOTSUPP;
-   } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+   } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+  (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0]  16 | msg[0].buf[1]  8 |
msg[0].buf[2];
+   if (state-af9033_config[1].i2c_addr 
+  (msg[0].addr == state-af9033_config[1].i2c_addr))
+   reg |= 0x10;
ret = af9035_rd_regs(d, reg, msg[1].buf[0],
msg[1].len);
} else {
@@ -220,8 +224,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
buf, msg[1].len, msg[1].buf };
+   req.mbox |= ((msg[0].addr  0x80)3);
buf[0] = msg[1].len;
-   buf[1] = msg[0].addr  1;
+   buf[1] = (u8)(msg[0].addr  1);
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
@@ -232,10 +237,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len  40) {
/* TODO: correct limits  40 */
ret = -EOPNOTSUPP;
-   } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+   } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+  (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0]  16 | msg[0].buf[1]  8 |
msg[0].buf[2];
+   if (state-af9033_config[1].i2c_addr 
+  (msg[0].addr == state-af9033_config[1].i2c_addr))
+   reg |= 0x10;
ret = af9035_wr_regs(d, reg, msg[0].buf[3],
msg[0].len - 3);
} else {
@@ -243,8 +252,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
0, NULL };
+   req.mbox |= ((msg[0].addr  0x80)3);
buf[0] = msg[0].len;
-   buf[1] = msg[0].addr  1;
+   buf[1] = (u8)(msg[0].addr  1);
buf[2] = 0x00; /* reg addr len */
buf[3] = 0x00; /* reg addr MSB */
buf[4] = 0x00; /* reg addr LSB */
@@ -283,9 +293,30 @@ static int af9035_identify_state(struct 
int ret;
u8 wbuf[1] = { 1 };
u8 rbuf[4];
+   u8 tmp;
struct usb_req req = { CMD_FW_QUERYINFO, 0, sizeof(wbuf), wbuf,
sizeof(rbuf), rbuf };
 
+   /* check if there is dual tuners

[PATCH] Add toggle to the tt3650_rc_query function of the ttusb2 driver

[Jose Alberto Reguero]

This patch add the toggle bit to the tt3650_rc_query function of the ttusb2
driver.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Albertodiff -upr linux/drivers/media/usb/dvb-usb/ttusb2.c linux.new/drivers/media/usb/dvb-usb/ttusb2.c
--- linux/drivers/media/usb/dvb-usb/ttusb2.c	2012-08-14 05:45:22.0 +0200
+++ linux.new/drivers/media/usb/dvb-usb/ttusb2.c	2012-08-23 18:33:33.459191850 +0200
@@ -440,7 +440,7 @@ static int tt3650_rc_query(struct dvb_us
 		/* got a press event */
 		st-last_rc_key = (rx[3]  8) | rx[2];
 		deb_info(%s: cmd=0x%02x sys=0x%02x\n, __func__, rx[2], rx[3]);
-		rc_keydown(d-rc_dev, st-last_rc_key, 0);
+		rc_keydown(d-rc_dev, st-last_rc_key, rx[1]);
 	} else if (st-last_rc_key) {
 		rc_keyup(d-rc_dev);
 		st-last_rc_key = 0;

[PATCH] v3 Add support to Avermedia Twinstar double tuner in af9035

[Jose Alberto Reguero]

This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 3 of the patch.  

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

diff -upr linux/drivers/media/dvb-frontends/af9033.c 
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c  2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c  2012-08-29 
16:00:52.020523899 +0200
@@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
goto err;
}
 
+   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+   ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   }
+
state-bandwidth_hz = 0; /* force to program all parameters */
 
return 0;
diff -upr linux/drivers/media/tuners/mxl5007t.c 
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c   2012-08-29 13:07:57.299884405 
+0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
 
-   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
 
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
 
-   ret = mxl5007t_soft_reset(state);
-   if (mxl_fail(ret))
-   goto fail;
+   if (!state-config-no_reset) {
+   ret = mxl5007t_soft_reset(state);
+   if (mxl_fail(ret))
+   goto fail;
+   }
 
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,11 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
 
-   ret = mxl5007t_get_chip_id(state);
+   if (!state-config-no_probe)
+   ret = mxl5007t_get_chip_id(state);
+
+   ret = mxl5007t_write_reg(state, 0x04,
+   state-config-loop_thru_enable);
 
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h 
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h   2012-08-25 19:38:19.990920623 
+0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
-   unsigned int loop_thru_enable:1;
+   unsigned int loop_thru_enable:2;
unsigned int clk_out_enable:1;
+   unsigned int no_probe:1;
+   unsigned int no_reset:1;
 };
 
 #if defined(CONFIG_MEDIA_TUNER_MXL5007T) || 
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0 
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-29 
19:20:00.862523903 +0200
@@ -209,10 +209,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len  40 || msg[1].len  40) {
/* TODO: correct limits  40 */
ret = -EOPNOTSUPP;
-   } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+   } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+  (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0]  16 | msg[0].buf[1]  8 |
msg[0].buf[2];
+   if (state-af9033_config[1].i2c_addr 
+  (msg[0].addr == state-af9033_config[1].i2c_addr))
+   reg |= 0x10;
ret = af9035_rd_regs(d, reg, msg[1].buf[0],
msg[1].len);
} else {
@@ -220,8 +224,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf

Re: [PATCH] v2 Add support to Avermedia Twinstar double tuner in af9035

[Jose Alberto Reguero]

On Martes, 28 de agosto de 2012 04:19:07 Antti Palosaari escribió:
 Hello
 this is not final review, as there was more things to check I was first
 thinking. I have to look it tomorrow too. But few comments still.
 
 On 08/27/2012 01:25 AM, Jose Alberto Reguero wrote:
  This patch add support to the Avermedia Twinstar double tuner in the
  af9035
  driver. Version 2 of the patch with suggestions of Antti.
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  Jose Alberto
  
  diff -upr linux/drivers/media/dvb-frontends/af9033.c
  linux.new/drivers/media/dvb-frontends/af9033.c ---
  linux/drivers/media/dvb-frontends/af9033.c  2012-08-14 05:45:22.0
  +0200 +++ linux.new/drivers/media/dvb-frontends/af9033.c2012-08-26
  23:38:10.527070150 +0200 @@ -51,6 +51,8 @@ static int
  af9033_wr_regs(struct af9033_
  
  };
  
  buf[0] = (reg  16)  0xff;
  
  +   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
  +   buf[0] |= 0x10;
  
  buf[1] = (reg   8)  0xff;
  buf[2] = (reg   0)  0xff;
  memcpy(buf[3], val, len);
  
  @@ -87,6 +89,9 @@ static int af9033_rd_regs(struct af9033_
  
  }
  
  };
  
  +   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
  +   buf[0] |= 0x10;
  +
 
 I don't like that if TS mode serial then tweak address bytes.
 
 I looked those from the sniff and it looks like that bit is used as a
 mail box pointing out if chip is on secondary bus. Imagine it as a
 situation there is two I2C bus, 1st demod is on bus#0 and 2nd demod is
 on bus#1. Such kind of info does not belong here - correct place is
 I2C-adapter or even register multiple adapters.
 

If I understand correctly, the logic must be made in af9035_i2c_master_xfer.


  ret = i2c_transfer(state-i2c, msg, 2);
  if (ret == 2) {
  
  ret = 0;
  
  @@ -325,6 +330,18 @@ static int af9033_init(struct dvb_fronte
  
  if (ret  0)
  
  goto err;
  
  }
  
  +
  +   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
  +   ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
  +   if (ret  0)
  +   goto err;
  +   ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
  +   if (ret  0)
  +   goto err;
  +   ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
  +   if (ret  0)
  +   goto err;
  +   }
 
 Haven't looked these yet.

These are in the old driver, and without that the second tuner don't 
work.

 
  state-bandwidth_hz = 0; /* force to program all parameters */
  
  diff -upr linux/drivers/media/tuners/mxl5007t.c
  linux.new/drivers/media/tuners/mxl5007t.c ---
  linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0 
  +0200
  +++ linux.new/drivers/media/tuners/mxl5007t.c   2012-08-25
  19:36:44.689924518 +0200 @@ -374,7 +374,6 @@ static struct reg_pair_t
  *mxl5007t_calc_
  
  mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
  mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
  
  -   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
  
  set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
  set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
  
  @@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
  
  struct reg_pair_t *init_regs;
  int ret;
  
  -   ret = mxl5007t_soft_reset(state);
  -   if (mxl_fail(ret))
  -   goto fail;
  +   if (!state-config-no_reset) {
  +   ret = mxl5007t_soft_reset(state);
  +   if (mxl_fail(ret))
  +   goto fail;
  +   }
 
 What happens if you do soft reset as normally?
 
 I would like to mention that AF9035/AF9033/MXL5007T was supported even
 earlier that given patch in question and I can guess it has been
 working. So why you are changing it now ?
 
 If you do these changes because what you see is different compared to
 windows sniff then you are on wrong way. Windows and Linux drivers are
 not needed to do 100% similar USB commands.
 

These are not because the windows driver. With the hardware I have, when one 
tuner do reset, the other tuner has errors in the image. I was using this 
logic with the old driver also.
Other solution was to do the reset in the mxl5007t_init only, not with every 
tuning.
The tuner works well without the reset.


  /* calculate initialization reg array */
  init_regs = mxl5007t_calc_init_regs(state, mode);
  
  @@ -887,7 +888,10 @@ struct dvb_frontend *mxl5007t_attach(str
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 1);
  
  -   ret = mxl5007t_get_chip_id(state);
  +   if (!state-config-no_probe)
  +   ret = mxl5007t_get_chip_id(state);
 
 Same here. AF9015 firmware does not support reading for MXL5007T. Due to
 that, it outputs something like unknown chip revision

[PATCH] v2 Add support to Avermedia Twinstar double tuner in af9035

[Jose Alberto Reguero]

This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 2 of the patch with suggestions of Antti.  

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

diff -upr linux/drivers/media/dvb-frontends/af9033.c 
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c  2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c  2012-08-26 
23:38:10.527070150 +0200
@@ -51,6 +51,8 @@ static int af9033_wr_regs(struct af9033_
};
 
buf[0] = (reg  16)  0xff;
+   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+   buf[0] |= 0x10;
buf[1] = (reg   8)  0xff;
buf[2] = (reg   0)  0xff;
memcpy(buf[3], val, len);
@@ -87,6 +89,9 @@ static int af9033_rd_regs(struct af9033_
}
};
 
+   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL)
+   buf[0] |= 0x10;
+
ret = i2c_transfer(state-i2c, msg, 2);
if (ret == 2) {
ret = 0;
@@ -325,6 +330,18 @@ static int af9033_init(struct dvb_fronte
if (ret  0)
goto err;
}
+
+   if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+   ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+   if (ret  0)
+   goto err;
+   }
 
state-bandwidth_hz = 0; /* force to program all parameters */
 
diff -upr linux/drivers/media/tuners/mxl5007t.c 
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c   2012-08-25 19:36:44.689924518 
+0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
 
-   set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable  3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
 
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
 
-   ret = mxl5007t_soft_reset(state);
-   if (mxl_fail(ret))
-   goto fail;
+   if (!state-config-no_reset) {
+   ret = mxl5007t_soft_reset(state);
+   if (mxl_fail(ret))
+   goto fail;
+   }
 
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,10 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
 
-   ret = mxl5007t_get_chip_id(state);
+   if (!state-config-no_probe)
+   ret = mxl5007t_get_chip_id(state);
+
+   ret = mxl5007t_write_reg(state, 0x04, 
state-config-loop_thru_enable);
 
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h 
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h   2012-08-14 05:45:22.0 
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h   2012-08-25 19:38:19.990920623 
+0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
-   unsigned int loop_thru_enable:1;
+   unsigned int loop_thru_enable:2;
unsigned int clk_out_enable:1;
+   unsigned int no_probe:1;
+   unsigned int no_reset:1;
 };
 
 #if defined(CONFIG_MEDIA_TUNER_MXL5007T) || 
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE)  defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c 
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0 
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-26 
23:46:10.702070148 +0200
@@ -209,7 +209,8 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len  40 || msg[1].len  40) {
/* TODO: correct limits  40 */
ret = -EOPNOTSUPP;
-   } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+   } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+  (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0]  16 | msg[0].buf[1]  8

Re: common DVB USB issues we has currently

[Jose Alberto Reguero]

On Jueves, 3 de mayo de 2012 10:48:43 Devin Heitmueller escribió:
 Hi Antti,
 
 On Thu, May 3, 2012 at 10:18 AM, Antti Palosaari
 
  1)
  Current static structure is too limited as devices are more dynamics
  nowadays. Driver should be able to probe/read from eeprom device
  configuration.
  
  Fixing all of those means rather much work - I think new version of DVB
  USB
  is needed.
  
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg44996.html
 
 What does this link above have to do with problem #1?  Did you perhaps
 cut/paste the wrong link?
 
  2)
  Suspend/resume is not supported and crashes Kernel. I have no idea what is
  wrong here and what is needed. But as it has been long term known problem
  I
  suspect it is not trivial.
  
  http://www.spinics.net/lists/linux-media/msg10293.html
 
 I doubt this is a dvb-usb problem, but rather something specific to
 the realtek parts (suspend/resume does work with other devices that
 rely on dvb-usb).
 
 Cheers,
 
 Devin

I have the resume problem with the terratec H7.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg45590.html

Jose Alberto
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CI support to az6007 driver

[Jose Alberto Reguero]

On Miércoles, 14 de marzo de 2012 18:45:24 Roger Mårtensson escribió:
 Hello!
 
 Sorry for the top post but this is just to check with you if you have
 experienced the same problem that I have. See below with some additional
 comments.
 
 Roger Mårtensson skrev 2012-03-07 20:21:
  Jose Alberto Reguero skrev 2012-03-06 00:23:
  On Lunes, 5 de marzo de 2012 21:42:48 Roger Mårtensson escribió:
  
  No. I tested the patch with DVB-T an watch encrypted channels with
  vdr without
  problems. I don't know why you can't. I don't know gnutv. Try with
  other
  software if you want.
  
  I have done some more testing and it works.. Sort of. :-)
  
  First let me walk through the dmesg.
  
  First I reinsert the CAM-card:
  
  Mar  7 20:12:36 tvpc kernel: [  959.717666] dvb_ca adapter 2: DVB CAM
  detected and initialised successfully
  
  The next lines are when I start Kaffeine. Kaffeine gets a lock on the
  encrypted channel and starts viewing it.
  
  Mar  7 20:13:02 tvpc kernel: [  986.359195] mt2063: detected a mt2063 B3
  Mar  7 20:13:03 tvpc kernel: [  987.368964] drxk: SCU_RESULT_INVPAR
  while sending cmd 0x0203 with params:
  Mar  7 20:13:03 tvpc kernel: [  987.368974] drxk: 02 00 00 00 10 00 05
  00 03 02..
  Mar  7 20:13:06 tvpc kernel: [  990.286628] dvb_ca adapter 2: DVB CAM
  detected and initialised successfully
  
  And now my sort of-comment. When I change the to another encrypted
  channel in kaffeine I get nothing. To be able to view this channel I
  need to restart kaffeine.
  
  The only thing that seems different in the logs are that when
  restarting kaffeine I get the CAM detected and initialised but when
  changing channels I do not get that line.
  
  Maybe there should be another reinit of the CAM somewhere? (just a
  guess)
 
 I turned on debugging and I see when changing channels from one
 encrypted to another I get lots of:
 40 from 0x1read cam data = 0 from 0x1read cam data = 80 from 0x1read
 cam data = 
 
 So the drivers is doing something except I don't get anything in
 kaffeine until I restart the application.
 Now and then I even have to restart kaffeine twice. Same as above.. I
 see it reading but nothing happens.
 
 I seem to find some EPG data since it can tell me what programs should
 be shown.

No, I don't have this problem. The only problem I have is when the reception 
is not very good, the cam don't work.
Perhaps is a kaffeine problem, or a cam specific problem.

Jose Alberto
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add CI support to az6007 driver

[Jose Alberto Reguero]

On Lunes, 5 de marzo de 2012 21:42:48 Roger Mårtensson escribió:
 Jose Alberto Reguero skrev 2012-03-05 00:22:
  This patch add CI support to az6007 driver.
  
  Signed-off-by: Jose Alberto Reguerojaregu...@telefonica.net
 
 Since I have this device and have access to a CAM-card and program card
 to access the encrypted channels(DVB-C) I thought I should try this
 patch and report my findings. First I have to say that I'm just a user
 and no developer.
 
 After managing to include the patch in media_build I do get this in
 dmesg when inserting the CAM.
 
 [  395.561886] dvb_ca adapter 2: DVB CAM detected and initialised
 successfully
 
 When scanning I can find my channels.
 I can watch unencrypted channels without problem even with the CAM inserted.
 
 When trying a encrypted channel with gnutv I get this:
 
 $ gnutv -adapter 2 -channels my-channels-v4.conf -out file t.mpg
 -timeout 30 TV3
 Using frontend DRXK DVB-C DVB-T, type DVB-C
 status SCVYL | signal 02c7 | snr 00be | ber  | unc 0704 |
 FE_HAS_LOCK
 en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE
 from module on slot 00
 
 en50221_stdcam_llci_poll: Error reported by stack:-7
 
 CAM Application type: 01
 CAM Application manufacturer: cafe
 CAM Manufacturer code: babe
 CAM Menu string: Conax Conditional Access
 CAM supports the following ca system ids:
0x0b00
 Received new PMT - sending to CAM...
 
 And the resulting mpeg file is not watchable with mplayer.
 
 Do you want me to test anything?
 --

No. I tested the patch with DVB-T an watch encrypted channels with vdr without 
problems. I don't know why you can't. I don't know gnutv. Try with other 
software if you want.

Jose Alberto

--
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] Add CI support to az6007 driver

[Jose Alberto Reguero]

This patch add CI support to az6007 driver.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.netdiff -urN linux/drivers/media/dvb/dvb-usb/az6007.c linux.new/drivers/media/dvb/dvb-usb/az6007.c
--- linux/drivers/media/dvb/dvb-usb/az6007.c	2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/az6007.c	2012-02-11 00:32:35.534490502 +0100
@@ -54,6 +54,7 @@
 
 struct az6007_device_state {
 	struct mutex		mutex;
+	struct mutex		ca_mutex;
 	struct dvb_ca_en50221	ca;
 	unsigned		warm:1;
 	int			(*gate_ctrl) (struct dvb_frontend *, int);
@@ -218,6 +219,371 @@
 	return 0;
 }
 
+static int az6007_ci_read_attribute_mem(struct dvb_ca_en50221 *ca,
+	int slot,
+	int address)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct az6007_device_state *state = (struct az6007_device_state *)d-priv;
+
+	int ret;
+	u8 req;
+	u16 value;
+	u16 index;
+	int blen;
+	u8 *b;
+
+	if (slot != 0)
+		return -EINVAL;
+
+	b = kmalloc(12, GFP_KERNEL);
+	if (!b)
+		return -ENOMEM;
+
+	mutex_lock(state-ca_mutex);
+
+	req = 0xC1;
+	value = address;
+	index = 0;
+	blen = 1;
+
+	ret = az6007_read(d, req, value, index, b, blen);
+	if (ret  0) {
+		warn(usb in operation failed. (%d), ret);
+		ret = -EINVAL;
+	} else {
+		ret = b[0];
+	}
+
+	mutex_unlock(state-ca_mutex);
+	kfree(b);
+	return ret;
+}
+
+static int az6007_ci_write_attribute_mem(struct dvb_ca_en50221 *ca,
+	 int slot,
+	 int address,
+	 u8 value)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct az6007_device_state *state = (struct az6007_device_state *)d-priv;
+
+	int ret;
+	u8 req;
+	u16 value1;
+	u16 index;
+	int blen;
+
+	deb_info(%s %d, __func__, slot);
+	if (slot != 0)
+		return -EINVAL;
+
+	mutex_lock(state-ca_mutex);
+	req = 0xC2;
+	value1 = address;
+	index = value;
+	blen = 0;
+
+	ret = az6007_write(d, req, value1, index, NULL, blen);
+	if (ret != 0)
+		warn(usb out operation failed. (%d), ret);
+
+	mutex_unlock(state-ca_mutex);
+	return ret;
+}
+
+static int az6007_ci_read_cam_control(struct dvb_ca_en50221 *ca,
+  int slot,
+  u8 address)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct az6007_device_state *state = (struct az6007_device_state *)d-priv;
+
+	int ret;
+	u8 req;
+	u16 value;
+	u16 index;
+	int blen;
+	u8 *b;
+
+	if (slot != 0)
+		return -EINVAL;
+
+	b = kmalloc(12, GFP_KERNEL);
+	if (!b)
+		return -ENOMEM;
+
+	mutex_lock(state-ca_mutex);
+
+	req = 0xC3;
+	value = address;
+	index = 0;
+	blen = 2;
+
+	ret = az6007_read(d, req, value, index, b, blen);
+	if (ret  0) {
+		warn(usb in operation failed. (%d), ret);
+		ret = -EINVAL;
+	} else {
+		if (b[0] == 0)
+			warn(Read CI IO error);
+
+		ret = b[1];
+		deb_info(read cam data = %x from 0x%x, b[1], value);
+	}
+
+	mutex_unlock(state-ca_mutex);
+	kfree(b);
+	return ret;
+}
+
+static int az6007_ci_write_cam_control(struct dvb_ca_en50221 *ca,
+   int slot,
+   u8 address,
+   u8 value)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct az6007_device_state *state = (struct az6007_device_state *)d-priv;
+
+	int ret;
+	u8 req;
+	u16 value1;
+	u16 index;
+	int blen;
+
+	if (slot != 0)
+		return -EINVAL;
+
+	mutex_lock(state-ca_mutex);
+	req = 0xC4;
+	value1 = address;
+	index = value;
+	blen = 0;
+
+	ret = az6007_write(d, req, value1, index, NULL, blen);
+	if (ret != 0) {
+		warn(usb out operation failed. (%d), ret);
+		goto failed;
+	}
+
+failed:
+	mutex_unlock(state-ca_mutex);
+	return ret;
+}
+
+static int CI_CamReady(struct dvb_ca_en50221 *ca, int slot)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+
+	int ret;
+	u8 req;
+	u16 value;
+	u16 index;
+	int blen;
+	u8 *b;
+
+	b = kmalloc(12, GFP_KERNEL);
+	if (!b)
+		return -ENOMEM;
+
+	req = 0xC8;
+	value = 0;
+	index = 0;
+	blen = 1;
+
+	ret = az6007_read(d, req, value, index, b, blen);
+	if (ret  0) {
+		warn(usb in operation failed. (%d), ret);
+		ret = -EIO;
+	} else{
+		ret = b[0];
+	}
+	kfree(b);
+	return ret;
+}
+
+static int az6007_ci_slot_reset(struct dvb_ca_en50221 *ca, int slot)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct az6007_device_state *state = (struct az6007_device_state *)d-priv;
+
+	int ret, i;
+	u8 req;
+	u16 value;
+	u16 index;
+	int blen;
+
+	mutex_lock(state-ca_mutex);
+
+	req = 0xC6;
+	value = 1;
+	index = 0;
+	blen = 0;
+
+	ret = az6007_write(d, req, value, index, NULL, blen);
+	if (ret != 0) {
+		warn(usb out operation failed. (%d), ret);
+		goto failed;
+	}
+
+	msleep(500);
+	req = 0xC6;
+	value = 0;
+	index = 0;
+	blen = 0;
+
+	ret = az6007_write(d, req, value, index, NULL, blen);
+	if (ret != 0) {
+		warn(usb out operation failed. (%d), ret);
+		goto failed;
+	}
+
+	for (i = 0; i  15; i++) {
+		msleep(100);
+
+		if (CI_CamReady(ca, slot)) {
+			deb_info(CAM Ready);
+			break;
+		}
+	}
+	msleep(5000);
+
+failed:
+	mutex_unlock(state-ca_mutex);
+	return ret;
+}
+
+static int az6007_ci_slot_shutdown(struct

[PATCH] Fix drxk get_tune_settings for DVB-T

[Jose Alberto Reguero]

DVB-T also use step_size=0.

Jose Alberto
diff -ur linux/drivers/media/dvb/frontends/drxk_hard.c linux.new/drivers/media/dvb/frontends/drxk_hard.c
--- linux/drivers/media/dvb/frontends/drxk_hard.c	2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/frontends/drxk_hard.c	2012-01-23 21:18:12.909138061 +0100
@@ -6317,15 +6317,12 @@
 	switch (p-delivery_system) {
 	case SYS_DVBC_ANNEX_A:
 	case SYS_DVBC_ANNEX_C:
+	case SYS_DVBT:
 		sets-min_delay_ms = 3000;
 		sets-max_drift = 0;
 		sets-step_size = 0;
 		return 0;
 	default:
-		/*
-		 * For DVB-T, let it use the default DVB core way, that is:
-		 *	fepriv-step_size = fe-ops.info.frequency_stepsize * 2
-		 */
 		return -EINVAL;
 	}
 }

[PATCH] Increase mt2063 frequency_max

[Jose Alberto Reguero]

Increase mt2063 frequency_max to tune to channel 69(858Mhz).

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/common/tuners/mt2063.c linux.new/drivers/media/common/tuners/mt2063.c
--- linux/drivers/media/common/tuners/mt2063.c	2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/common/tuners/mt2063.c	2012-01-27 23:36:23.273848131 +0100
@@ -2226,7 +2226,7 @@
 	.info = {
 		 .name = MT2063 Silicon Tuner,
 		 .frequency_min = 4500,
-		 .frequency_max = 85000,
+		 .frequency_max = 86500,
 		 .frequency_step = 0,
 		 },
 

Re: [PATCH] Fix drxk get_tune_settings for DVB-T

[Jose Alberto Reguero]

On Viernes, 27 de Enero de 2012 23:34:49 Jose Alberto Reguero escribió:
 DVB-T also use step_size=0.
 
 Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

--
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] add another Terratec H7 usb id to az6007

[Jose Alberto Reguero]

This patch add another Terratec H7 usb id to az6007 driver.

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/dvb/dvb-usb/az6007.c linux.new/drivers/media/dvb/dvb-usb/az6007.c
--- linux/drivers/media/dvb/dvb-usb/az6007.c	2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/az6007.c	2012-01-23 00:17:57.859087470 +0100
@@ -481,6 +481,7 @@
 static struct usb_device_id az6007_usb_table[] = {
 	{USB_DEVICE(USB_VID_AZUREWAVE, USB_PID_AZUREWAVE_6007)},
 	{USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_H7)},
+	{USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_H7_2)},
 	{0},
 };
 
@@ -534,7 +535,7 @@
 		  .warm_ids = { NULL },
 		},
 		{ .name = TerraTec DTV StarBox DVB-T/C USB2.0 (az6007),
-		  .cold_ids = { az6007_usb_table[1], NULL },
+		  .cold_ids = { az6007_usb_table[1], az6007_usb_table[2], NULL },
 		  .warm_ids = { NULL },
 		},
 		{ NULL },
diff -ur linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h linux.new/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h	2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/dvb-usb-ids.h	2012-01-23 00:16:49.993324303 +0100
@@ -228,6 +228,7 @@
 #define USB_PID_TERRATEC_CINERGY_T_XXS			0x0078
 #define USB_PID_TERRATEC_CINERGY_T_XXS_2		0x00ab
 #define USB_PID_TERRATEC_H70x10b4
+#define USB_PID_TERRATEC_H7_20x10a3
 #define USB_PID_TERRATEC_T30x10a0
 #define USB_PID_TERRATEC_T50x10a1
 #define USB_PID_PINNACLE_EXPRESSCARD_320CX		0x022e

[PATCH] Add brightness to OmniVision 5621 sensor

[Jose Alberto Reguero]

This patch add brightness control to OmniVision 5621 sensor.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
diff -ur linux/drivers/media/video/gspca/ov534_9.c linux.new/drivers/media/video/gspca/ov534_9.c
--- linux/drivers/media/video/gspca/ov534_9.c	2012-01-07 05:45:50.0 +0100
+++ linux.new/drivers/media/video/gspca/ov534_9.c	2012-01-13 14:38:49.600419671 +0100
@@ -1107,16 +1107,34 @@
 {
 	struct sd *sd = (struct sd *) gspca_dev;
 	u8 val;
+	s8 sval;
 
 	if (gspca_dev-ctrl_dis  (1  BRIGHTNESS))
 		return;
-	val = sd-ctrls[BRIGHTNESS].val;
-	if (val  8)
-		val = 15 - val;		/* f .. 8 */
-	else
-		val = val - 8;		/* 0 .. 7 */
-	sccb_write(gspca_dev, 0x55,	/* brtn - brightness adjustment */
-			0x0f | (val  4));
+	if (sd-sensor == SENSOR_OV562x) {
+		sval = sd-ctrls[BRIGHTNESS].val;
+		val = 0x76;
+		val += sval;
+		sccb_write(gspca_dev, 0x24, val);
+		val = 0x6a;
+		val += sval;
+		sccb_write(gspca_dev, 0x25, val);
+		if (sval  -40)
+			val = 0x71;
+		else if (sval  20)
+			val = 0x94;
+		else
+			val = 0xe6;
+		sccb_write(gspca_dev, 0x26, val);
+	} else {
+		val = sd-ctrls[BRIGHTNESS].val;
+		if (val  8)
+			val = 15 - val;		/* f .. 8 */
+		else
+			val = val - 8;		/* 0 .. 7 */
+		sccb_write(gspca_dev, 0x55,	/* brtn - brightness adjustment */
+0x0f | (val  4));
+	}
 }
 
 static void setcontrast(struct gspca_dev *gspca_dev)
@@ -1339,7 +1357,16 @@
 			reg_w(gspca_dev, 0x56, 0x17);
 	} else if ((sensor_id  0xfff0) == 0x5620) {
 		sd-sensor = SENSOR_OV562x;
-
+		gspca_dev-ctrl_dis = (1  CONTRAST) |
+	(1  AUTOGAIN) |
+	(1  EXPOSURE) |
+	(1  SHARPNESS) |
+	(1  SATUR) |
+	(1  LIGHTFREQ);
+
+		sd-ctrls[BRIGHTNESS].min = -90;
+		sd-ctrls[BRIGHTNESS].max = 90;
+		sd-ctrls[BRIGHTNESS].def = 0;
 		gspca_dev-cam.cam_mode = ov562x_mode;
 		gspca_dev-cam.nmodes = ARRAY_SIZE(ov562x_mode);
 
@@ -1360,8 +1387,12 @@
 {
 	struct sd *sd = (struct sd *) gspca_dev;
 
-	if (sd-sensor == SENSOR_OV971x || sd-sensor == SENSOR_OV562x)
+	if (sd-sensor == SENSOR_OV971x)
 		return gspca_dev-usb_err;
+	else if (sd-sensor == SENSOR_OV562x) {
+		setbrightness(gspca_dev);
+		return gspca_dev-usb_err;
+	}
 	switch (gspca_dev-curr_mode) {
 	case QVGA_MODE:			/* 320x240 */
 		sccb_w_array(gspca_dev, ov965x_start_1_vga,

[PATCH] Add support to OmniVision Technologies, Inc. VEHO Filmscanner (omnivision 550)

[Jose Alberto Reguero]

This path add support to OmniVision Technologies, Inc. VEHO Filmscanner.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
  
diff -ur linux/drivers/media/video/gspca/ov534_9.c linux.new/drivers/media/video/gspca/ov534_9.c
--- linux/drivers/media/video/gspca/ov534_9.c	2011-09-18 05:45:49.0 +0200
+++ linux.new/drivers/media/video/gspca/ov534_9.c	2011-12-15 19:18:14.26459 +0100
@@ -71,6 +71,7 @@
 enum sensors {
 	SENSOR_OV965x,		/* ov9657 */
 	SENSOR_OV971x,		/* ov9712 */
+	SENSOR_OV562x,		/* ov5621 */
 	NSENSORS
 };
 
@@ -207,6 +208,14 @@
 	}
 };
 
+static const struct v4l2_pix_format ov562x_mode[] = {
+	{2592, 1680, V4L2_PIX_FMT_SBGGR8, V4L2_FIELD_NONE,
+		.bytesperline = 2592,
+		.sizeimage = 2592 * 1680,
+		.colorspace = V4L2_COLORSPACE_SRGB
+	}
+};
+
 static const u8 bridge_init[][2] = {
 	{0x88, 0xf8},
 	{0x89, 0xff},
@@ -830,6 +839,124 @@
 	{0xa3, 0x41},	/* bd60 */
 };
 
+static const u8 ov562x_init[][2] = {
+	{0x88, 0x20},
+	{0x89, 0x0a},
+	{0x8a, 0x90},
+	{0x8b, 0x06},
+	{0x8c, 0x01},
+	{0x8d, 0x10},
+	{0x1c, 0x00},
+	{0x1d, 0x48},
+	{0x1d, 0x00},
+	{0x1d, 0xff},
+	{0x1c, 0x0a},
+	{0x1d, 0x2e},
+	{0x1d, 0x1e},
+};
+
+static const u8 ov562x_init_2[][2] = {
+	{0x12, 0x80},
+	{0x11, 0x41},
+	{0x13, 0x00},
+	{0x10, 0x1e},
+	{0x3b, 0x07},
+	{0x5b, 0x40},
+	{0x39, 0x07},
+	{0x53, 0x02},
+	{0x54, 0x60},
+	{0x04, 0x20},
+	{0x27, 0x04},
+	{0x3d, 0x40},
+	{0x36, 0x00},
+	{0xc5, 0x04},
+	{0x4e, 0x00},
+	{0x4f, 0x93},
+	{0x50, 0x7b},
+	{0xca, 0x0c},
+	{0xcb, 0x0f},
+	{0x39, 0x07},
+	{0x4a, 0x10},
+	{0x3e, 0x0a},
+	{0x3d, 0x00},
+	{0x0c, 0x38},
+	{0x38, 0x90},
+	{0x46, 0x30},
+	{0x4f, 0x93},
+	{0x50, 0x7b},
+	{0xab, 0x00},
+	{0xca, 0x0c},
+	{0xcb, 0x0f},
+	{0x37, 0x02},
+	{0x44, 0x48},
+	{0x8d, 0x44},
+	{0x2a, 0x00},
+	{0x2b, 0x00},
+	{0x32, 0x00},
+	{0x38, 0x90},
+	{0x53, 0x02},
+	{0x54, 0x60},
+	{0x12, 0x00},
+	{0x17, 0x12},
+	{0x18, 0xb4},
+	{0x19, 0x0c},
+	{0x1a, 0xf4},
+	{0x03, 0x4a},
+	{0x89, 0x20},
+	{0x83, 0x80},
+	{0xb7, 0x9d},
+	{0xb6, 0x11},
+	{0xb5, 0x55},
+	{0xb4, 0x00},
+	{0xa9, 0xf0},
+	{0xa8, 0x0a},
+	{0xb8, 0xf0},
+	{0xb9, 0xf0},
+	{0xba, 0xf0},
+	{0x81, 0x07},
+	{0x63, 0x44},
+	{0x13, 0xc7},
+	{0x14, 0x60},
+	{0x33, 0x75},
+	{0x2c, 0x00},
+	{0x09, 0x00},
+	{0x35, 0x30},
+	{0x27, 0x04},
+	{0x3c, 0x07},
+	{0x3a, 0x0a},
+	{0x3b, 0x07},
+	{0x01, 0x40},
+	{0x02, 0x40},
+	{0x16, 0x40},
+	{0x52, 0xb0},
+	{0x51, 0x83},
+	{0x21, 0xbb},
+	{0x22, 0x10},
+	{0x23, 0x03},
+	{0x35, 0x38},
+	{0x20, 0x90},
+	{0x28, 0x30},
+	{0x73, 0xe1},
+	{0x6c, 0x00},
+	{0x6d, 0x80},
+	{0x6e, 0x00},
+	{0x70, 0x04},
+	{0x71, 0x00},
+	{0x8d, 0x04},
+	{0x64, 0x00},
+	{0x65, 0x00},
+	{0x66, 0x00},
+	{0x67, 0x00},
+	{0x68, 0x00},
+	{0x69, 0x00},
+	{0x6a, 0x00},
+	{0x6b, 0x00},
+	{0x71, 0x94},
+	{0x74, 0x20},
+	{0x80, 0x09},
+	{0x85, 0xc0},
+};
+
 static void reg_w_i(struct gspca_dev *gspca_dev, u16 reg, u8 val)
 {
 	struct usb_device *udev = gspca_dev-dev;
@@ -1210,6 +1337,17 @@
 			reg_w(gspca_dev, 0x56, 0x1f);
 		else
 			reg_w(gspca_dev, 0x56, 0x17);
+	} else if ((sensor_id  0xfff0) == 0x5620) {
+		sd-sensor = SENSOR_OV562x;
+
+		gspca_dev-cam.cam_mode = ov562x_mode;
+		gspca_dev-cam.nmodes = ARRAY_SIZE(ov562x_mode);
+
+		reg_w_array(gspca_dev, ov562x_init,
+ARRAY_SIZE(ov562x_init));
+		sccb_w_array(gspca_dev, ov562x_init_2,
+ARRAY_SIZE(ov562x_init_2));
+		reg_w(gspca_dev, 0xe0, 0x00);
 	} else {
 		err(Unknown sensor %04x, sensor_id);
 		return -EINVAL;
@@ -1222,7 +1360,7 @@
 {
 	struct sd *sd = (struct sd *) gspca_dev;
 
-	if (sd-sensor == SENSOR_OV971x)
+	if (sd-sensor == SENSOR_OV971x || sd-sensor == SENSOR_OV562x)
 		return gspca_dev-usb_err;
 	switch (gspca_dev-curr_mode) {
 	case QVGA_MODE:			/* 320x240 */
@@ -1409,6 +1547,7 @@
 static const struct usb_device_id device_table[] = {
 	{USB_DEVICE(0x05a9, 0x8065)},
 	{USB_DEVICE(0x06f8, 0x3003)},
+	{USB_DEVICE(0x05a9, 0x1550)},
 	{}
 };
 

[PATCH] TT CT-3650 i2c fix

[Jose Alberto Reguero]

This patch fix a bug in the i2c code of ttusb2 driver.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-09-24 05:45:14.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-10-01 19:42:46.715723308 +0200
@@ -384,7 +384,7 @@
 
 		memcpy(obuf[3], msg[i].buf, msg[i].len);
 
-		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3)  0) {
+		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, obuf[1]+3, ibuf, obuf[2] + 3)  0) {
 			err(i2c transfer failed.);
 			break;
 		}

Re: [PATCH] TT CT-3650 CI support

[Jose Alberto Reguero]

On Jueves, 1 de Septiembre de 2011 01:47:32 Jose Alberto Reguero escribió:
 From:
 
 http://www.spinics.net/lists/linux-media/msg20440.html
 
 This patch add support for the CI of the TT CT-3650.
 
 Jose Alberto
 
 Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Second version with changes suggested by Mauro in:

http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20811

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-28 05:45:24.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-09-18 02:06:00.211411451 +0200
@@ -33,16 +33,40 @@
 #include tda10048.h
 #include tda827x.h
 #include lnbp21.h
+/* CA */
+#include dvb_ca_en50221.h
 
 /* debug */
 static int dvb_usb_ttusb2_debug;
 #define deb_info(args...)   dprintk(dvb_usb_ttusb2_debug,0x01,args)
 module_param_named(debug,dvb_usb_ttusb2_debug, int, 0644);
 MODULE_PARM_DESC(debug, set debugging level (1=info (or-able)). DVB_USB_DEBUG_STATUS);
+static int dvb_usb_ttusb2_debug_ci;
+module_param_named(debug_ci,dvb_usb_ttusb2_debug_ci, int, 0644);
+MODULE_PARM_DESC(debug_ci, set debugging ci. DVB_USB_DEBUG_STATUS);
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
+#define ci_dbg(format, arg...)\
+do {  \
+	if (dvb_usb_ttusb2_debug_ci)\
+		printk(KERN_DEBUG DVB_USB_LOG_PREFIX \
+			: %s  format \n , __func__, ## arg);   \
+} while (0)
+
+enum {
+	TT3650_CMD_CI_TEST = 0x40,
+	TT3650_CMD_CI_RD_CTRL,
+	TT3650_CMD_CI_WR_CTRL,
+	TT3650_CMD_CI_RD_ATTR,
+	TT3650_CMD_CI_WR_ATTR,
+	TT3650_CMD_CI_RESET,
+	TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
 struct ttusb2_state {
+	struct dvb_ca_en50221 ca;
+	struct mutex ca_mutex;
 	u8 id;
 	u16 last_rc_key;
 };
@@ -79,6 +103,255 @@
 	return 0;
 }
 
+/* ci */
+static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+	int ret;
+	u8 rx[60];/* (64 -4) */
+	ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+	if (!ret)
+		memcpy(data, rx, read_len);
+	return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+	struct dvb_usb_device *d = ca-data;
+	struct ttusb2_state *state = d-priv;
+	int ret;
+
+	mutex_lock(state-ca_mutex);
+	ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+	mutex_unlock(state-ca_mutex);
+
+	return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
+{
+	u8 buf[3];
+	int ret = 0;
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = (address  8)  0x0F;
+	buf[1] = address;
+
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_ATTR, buf, 2, 3);
+
+	ci_dbg(%04x - %d 0x%02x, address, ret, buf[2]);
+
+	if (ret  0)
+		return ret;
+
+	return buf[2];
+}
+
+static int tt3650_ci_write_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address, u8 value)
+{
+	u8 buf[3];
+
+	ci_dbg(%d 0x%04x 0x%02x, slot, address, value);
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = (address  8)  0x0F;
+	buf[1] = address;
+	buf[2] = value;
+
+	return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_ATTR, buf, 3, 3);
+}
+
+static int tt3650_ci_read_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address)
+{
+	u8 buf[2];
+	int ret;
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = address  3;
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_CTRL, buf, 1, 2);
+
+	ci_dbg(0x%02x - %d 0x%02x, address, ret, buf[1]);
+
+	if (ret  0)
+		return ret;
+
+	return buf[1];
+}
+
+static int tt3650_ci_write_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address, u8 value)
+{
+	u8 buf[2];
+
+	ci_dbg(%d 0x%02x 0x%02x, slot, address, value);
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = address;
+	buf[1] = value;
+
+	return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_CTRL, buf, 2, 2);
+}
+
+static int tt3650_ci_set_video_port(struct dvb_ca_en50221 *ca, int slot, int enable)
+{
+	u8 buf[1];
+	int ret;
+
+	ci_dbg(%d %d, slot, enable);
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = enable;
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_SET_VIDEO_PORT, buf, 1, 1);
+	if (ret  0)
+		return ret;
+
+	if (enable != buf[0]) {
+		err(CI not %sabled., enable ? en : dis);
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int tt3650_ci_slot_shutdown(struct dvb_ca_en50221 *ca, int slot)
+{
+	return tt3650_ci_set_video_port(ca, slot, 0);
+}
+
+static int tt3650_ci_slot_ts_enable(struct dvb_ca_en50221 *ca, int slot)
+{
+	return tt3650_ci_set_video_port(ca, slot, 1);
+}
+
+static int tt3650_ci_slot_reset(struct dvb_ca_en50221 *ca, int slot)
+{
+	struct dvb_usb_device *d = ca-data;
+	struct ttusb2_state *state = d-priv;
+	u8 buf[1];
+	int ret;
+
+	ci_dbg(%d, slot);
+
+	if (slot)
+		return -EINVAL;
+
+	buf[0] = 0;
+
+	mutex_lock(state-ca_mutex);
+
+	ret = tt3650_ci_msg(d

[PATCH] TT CT-3650 CI support

[Jose Alberto Reguero]

From:

http://www.spinics.net/lists/linux-media/msg20440.html

This patch add support for the CI of the TT CT-3650.

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-28 05:45:24.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-09-01 01:13:45.348101193 +0200
@@ -33,6 +33,8 @@
 #include tda10048.h
 #include tda827x.h
 #include lnbp21.h
+/* CA */
+#include dvb_ca_en50221.h
 
 /* debug */
 static int dvb_usb_ttusb2_debug;
@@ -42,7 +44,26 @@
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
+#define ci_dbg(format, arg...)\
+do {  \
+	if (0)\
+		printk(KERN_DEBUG DVB_USB_LOG_PREFIX \
+			:  format \n , ## arg);   \
+} while (0)
+
+enum {
+	TT3650_CMD_CI_TEST = 0x40,
+	TT3650_CMD_CI_RD_CTRL,
+	TT3650_CMD_CI_WR_CTRL,
+	TT3650_CMD_CI_RD_ATTR,
+	TT3650_CMD_CI_WR_ATTR,
+	TT3650_CMD_CI_RESET,
+	TT3650_CMD_CI_SET_VIDEO_PORT
+};
+
 struct ttusb2_state {
+	struct dvb_ca_en50221 ca;
+	struct mutex ca_mutex;
 	u8 id;
 	u16 last_rc_key;
 };
@@ -79,6 +100,261 @@
 	return 0;
 }
 
+/* ci */
+static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+	int ret;
+	u8 rx[60];/* (64 -4) */
+	ret = ttusb2_msg(d, cmd, data, write_len, rx, read_len);
+	if (ret == 0)
+		memcpy(data, rx, read_len);
+	return ret;
+}
+
+static int tt3650_ci_msg_locked(struct dvb_ca_en50221 *ca, u8 cmd, u8 *data, unsigned int write_len, unsigned int read_len)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct ttusb2_state *state = (struct ttusb2_state *)d-priv;
+	int ret;
+
+	mutex_lock(state-ca_mutex);
+	ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
+	mutex_unlock(state-ca_mutex);
+
+	return ret;
+}
+
+static int tt3650_ci_read_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address)
+{
+	u8 buf[3];
+	int ret = 0;
+
+	if (0 != slot)
+		return -EINVAL;
+
+	buf[0] = (address  8)  0x0F;
+	buf[1] = address;
+
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_ATTR, buf, 2, 3);
+
+	ci_dbg(%s %04x - %d 0x%02x,
+		__func__, address, ret, buf[2]);
+
+	if (ret  0)
+		return ret;
+
+	return buf[2];
+}
+
+static int tt3650_ci_write_attribute_mem(struct dvb_ca_en50221 *ca, int slot, int address, u8 value)
+{
+	u8 buf[3];
+
+	ci_dbg(%s %d 0x%04x 0x%02x,
+		__func__, slot, address, value);
+
+	if (0 != slot)
+		return -EINVAL;
+
+	buf[0] = (address  8)  0x0F;
+	buf[1] = address;
+	buf[2] = value;
+
+	return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_ATTR, buf, 3, 3);
+}
+
+static int tt3650_ci_read_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address)
+{
+	u8 buf[2];
+	int ret;
+
+	if (0 != slot)
+		return -EINVAL;
+
+	buf[0] = address  3;
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_RD_CTRL, buf, 1, 2);
+
+	ci_dbg(%s 0x%02x - %d 0x%02x,
+		__func__, address, ret, buf[1]);
+
+	if (ret  0)
+		return ret;
+
+	return buf[1];
+}
+
+static int tt3650_ci_write_cam_control(struct dvb_ca_en50221 *ca, int slot, u8 address, u8 value)
+{
+	u8 buf[2];
+
+	ci_dbg(%s %d 0x%02x 0x%02x,
+		__func__, slot, address, value);
+
+	if (0 != slot)
+		return -EINVAL;
+
+	buf[0] = address;
+	buf[1] = value;
+
+	return tt3650_ci_msg_locked(ca, TT3650_CMD_CI_WR_CTRL, buf, 2, 2);
+}
+
+static int tt3650_ci_set_video_port(struct dvb_ca_en50221 *ca, int slot, int enable)
+{
+	u8 buf[1];
+	int ret;
+
+	ci_dbg(%s %d %d, __func__, slot, enable);
+
+	if (0 != slot)
+		return -EINVAL;
+
+	enable = !!enable;
+	buf[0] = enable;
+
+	ret = tt3650_ci_msg_locked(ca, TT3650_CMD_CI_SET_VIDEO_PORT, buf, 1, 1);
+	if (ret  0)
+		return ret;
+
+	if (enable != buf[0]) {
+		err(CI not %sabled., enable ? en : dis);
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int tt3650_ci_slot_shutdown(struct dvb_ca_en50221 *ca, int slot)
+{
+	return tt3650_ci_set_video_port(ca, slot, /* enable */ 0);
+}
+
+static int tt3650_ci_slot_ts_enable(struct dvb_ca_en50221 *ca, int slot)
+{
+	return tt3650_ci_set_video_port(ca, slot, /* enable */ 1);
+}
+
+static int tt3650_ci_slot_reset(struct dvb_ca_en50221 *ca, int slot)
+{
+	struct dvb_usb_device *d = (struct dvb_usb_device *)ca-data;
+	struct ttusb2_state *state = (struct ttusb2_state *)d-priv;
+	u8 buf[1];
+	int ret;
+
+	ci_dbg(%s %d, __func__, slot);
+
+	if (0 != slot)
+		return -EINVAL;
+
+	buf[0] = 0;
+
+	mutex_lock(state-ca_mutex);
+
+	ret = tt3650_ci_msg(d, TT3650_CMD_CI_RESET, buf, 1, 1);
+	if (0 != ret)
+		goto failed;
+
+	msleep(500);
+
+	buf[0] = 1;
+
+	ret = tt3650_ci_msg(d, TT3650_CMD_CI_RESET, buf, 1, 1);
+	if (0 != ret)
+		goto failed;
+
+	msleep(500);
+
+	buf[0] = 0; /* FTA */
+
+	ret = tt3650_ci_msg(d, TT3650_CMD_CI_SET_VIDEO_PORT, buf, 1, 1);
+
+	msleep(1100);
+
+ failed:
+	mutex_unlock(state-ca_mutex);
+
+	return ret;
+}
+
+static int tt3650_ci_poll_slot_status(struct

Re: Afatech AF9013

[Jose Alberto Reguero]

On Martes, 16 de Agosto de 2011 18:37:49 Josu Lazkano escribió:
 Thanks again, I edit /etc/modprobe.d/options.conf
 
 options dvb_usb_af9015 adapter_nr=4,5
 options dvb-usb disable_rc_polling=1
 options dvb-usb force_pid_filter_usage=1
 
 I change the signal timeout and tuning timeout and now it works perfect!
 
 I can watch two HD channels, thanks for your help.
 
 I really don't understand what force_pid_filter_usage do on the
 module, is there any documentation?
 
 Thanks and best regards.
 

For usb devices with usb 2.0 when tunned to a channel there is enought usb 
bandwith to deliver the whole transponder. With pid filters they only deliver 
the pids needed for the channel. The only limit is that the pid filters is 
limited normaly to 32 pids.

Jose Alberto

 2011/8/16 Jose Alberto Reguero jaregu...@telefonica.net:
  On Martes, 16 de Agosto de 2011 00:22:05 Josu Lazkano escribió:
  2011/8/16 Jose Alberto Reguero jaregu...@telefonica.net:
   I have problems with a dual usb tuner. I limit the bandwith using pid
   filters and the problem was gone.
   
   Jose alberto
   
   On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió:
   Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick
   (DVB-T 399U):
   http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_
   (DV B- T_399U)
   
   I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual
   device, sometimes the second adapter works great, but sometimes has a
   pixeled images. The first adapter always has pixeled images, I don't
   know how to describe the pixeled images, so here is a mobile record:
   http://dl.dropbox.com/u/1541853/kworld.3gp
   
   I have this firmware:
   http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9
   015 .fw
   
   I read on the linuxtv wiki and there are some problems with dual
   mode, there is some links for how to patch the similar driver
   (Afatech/ITE IT9135), but I am not good enough to understand the
   code.
   
   I check the kernel messages:
   
   Aug 15 13:53:58 htpc kernel: [ 516.285369] af9013: I2C read failed
   reg:d2e6 Aug 15 13:54:29 htpc kernel: [  547.407504] af9013: I2C read
   failed reg:d330 Aug 15 13:54:44 htpc kernel: [  561.902710] af9013:
   I2C read failed reg:d2e6
   
   It looks I2C problem, but I don't know how to debug it deeper.
   
   I don't know if this is important, but I compile the s2-liplianin for
   other devices this way:
   
   apt-get install linux-headers-`uname -r` build-essential
   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
   make CONFIG_DVB_FIREDTV:=n
   make install
   
   Can you help with this? This hardware is a very cheap and works well
   for HD channels but, I don't know why sometimes has pixeled images.
   
   Thanks for your help, best regards.
  
  Thanks Jose Alberto, I search on google for pid filters but I don't
  find any interesting info.
  
  How can I limit bandwidth on dvb?
  
  Thanks for your help, I have two dual devices waiting for this fix on my
  HTPC.
  
  Best regards.
  
  If  the driver has pid filters you can enable it with the parameter
  force_pid_filter_usage=1 of dvb-usb.
  
  Jose Alberto
--
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: Afatech AF9013

[Jose Alberto Reguero]

On Martes, 16 de Agosto de 2011 22:57:24 Antti Palosaari escribió:
 On 08/16/2011 11:27 PM, Jose Alberto Reguero wrote:
  options dvb-usb force_pid_filter_usage=1
  
  I change the signal timeout and tuning timeout and now it works perfect!
  
  I can watch two HD channels, thanks for your help.
  
  I really don't understand what force_pid_filter_usage do on the
  module, is there any documentation?
  
  Thanks and best regards.
  
  For usb devices with usb 2.0 when tunned to a channel there is enought
  usb bandwith to deliver the whole transponder. With pid filters they
  only deliver the pids needed for the channel. The only limit is that the
  pid filters is limited normaly to 32 pids.
 
 May I ask how wide DVB-T streams you have? Here in Finland it is about
 22 Mbit/sec and I think two such streams should be too much for one USB
 bus. I suspect there is some other bug in back of this.
 
 regards
 Antti

Here the transport stream is like yours. About 4 Mbit/sec by channel, and 
about 5 channels by transport stream. The problem I have is that when I have 
the two tuners working I have a few packets lost, and I have some TS 
discontinuitys. With pid filters the stream is perfect. Perhaps Josu have 
another problem.

Jose Alberto
--
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: Afatech AF9013

[Jose Alberto Reguero]

I have problems with a dual usb tuner. I limit the bandwith using pid filters 
and the problem was gone.

Jose alberto

On Lunes, 15 de Agosto de 2011 15:34:20 Josu Lazkano escribió:
 Hello, I have a problem with the KWorld USB Dual DVB-T TV Stick (DVB-T
 399U):
 http://www.linuxtv.org/wiki/index.php/KWorld_USB_Dual_DVB-T_TV_Stick_(DVB-
 T_399U)
 
 I am using it on MythTV with Debian Squeeze (2.6.32). It is a dual
 device, sometimes the second adapter works great, but sometimes has a
 pixeled images. The first adapter always has pixeled images, I don't
 know how to describe the pixeled images, so here is a mobile record:
 http://dl.dropbox.com/u/1541853/kworld.3gp
 
 I have this firmware:
 http://palosaari.fi/linux/v4l-dvb/firmware/af9015/5.1.0.0/dvb-usb-af9015.fw
 
 I read on the linuxtv wiki and there are some problems with dual mode,
 there is some links for how to patch the similar driver (Afatech/ITE
 IT9135), but I am not good enough to understand the code.
 
 I check the kernel messages:
 
 Aug 15 13:53:58 htpc kernel: [  516.285369] af9013: I2C read failed
 reg:d2e6 Aug 15 13:54:29 htpc kernel: [  547.407504] af9013: I2C read
 failed reg:d330 Aug 15 13:54:44 htpc kernel: [  561.902710] af9013: I2C
 read failed reg:d2e6
 
 It looks I2C problem, but I don't know how to debug it deeper.
 
 I don't know if this is important, but I compile the s2-liplianin for
 other devices this way:
 
 apt-get install linux-headers-`uname -r` build-essential
 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
 make CONFIG_DVB_FIREDTV:=n
 make install
 
 Can you help with this? This hardware is a very cheap and works well
 for HD channels but, I don't know why sometimes has pixeled images.
 
 Thanks for your help, best regards.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Lunes, 8 de Agosto de 2011 23:44:43 Antti Palosaari escribió:
 Reviewed-by: Antti Palosaari cr...@iki.fi
 
 It looks just fine.
 
 regards
 Antti

 
Forgot the Signed-off-by

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

 On 08/08/2011 01:35 PM, Jose Alberto Reguero wrote:
  On Martes, 2 de Agosto de 2011 21:21:13 Jose Alberto Reguero escribió:
  On Jueves, 28 de Julio de 2011 21:25:01 Jose Alberto Reguero escribió:
  On Miércoles, 27 de Julio de 2011 21:22:26 Antti Palosaari escribió:
  On 07/24/2011 12:45 AM, Jose Alberto Reguero wrote:
  Read without write work as with write. Attached updated patch.
  
  ttusb2-6.diff
  
  -   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   read = msg[i].flags  I2C_M_RD;
  
  ttusb2 I2C-adapter seems to be fine for my eyes now. No more writing
  any random bytes in case of single read. Good!
  
  +   .dtv6_if_freq_khz = TDA10048_IF_4000,
  +   .dtv7_if_freq_khz = TDA10048_IF_4500,
  +   .dtv8_if_freq_khz = TDA10048_IF_5000,
  +   .clk_freq_khz = TDA10048_CLK_16000,
  
  
  +static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
  
  cosmetic issue rename to ttusb2_ct3650_i2c_gate_ctrl
  
  { TDA10048_CLK_16000, TDA10048_IF_4000,  10, 3, 0 },
  
  +   { TDA10048_CLK_16000, TDA10048_IF_4500,   5, 3, 0 },
  +   { TDA10048_CLK_16000, TDA10048_IF_5000,   5, 3, 0 },
  
  +   /* Set the  pll registers */
  +   tda10048_writereg(state, TDA10048_CONF_PLL1, 0x0f);
  +   tda10048_writereg(state, TDA10048_CONF_PLL2, (u8)(state-
  
  pll_mfactor));
  
  +   tda10048_writereg(state, TDA10048_CONF_PLL3,
  tda10048_readreg(state, TDA10048_CONF_PLL3) |
  ((u8)(state-pll_nfactor) | 0x40));
  
  This if only issue can have effect to functionality and I want double
  check. I see few things.
  
  1) clock (and PLL) settings should be done generally only once at
  .init() and probably .sleep() in case of needed for sleep. Something
  like start clock in init, stop clock in sleep. It is usually very
  first thing to set before other. Now it is in wrong place -
  .set_frontend().
  
  2) Those clock settings seem somehow weird. As you set different PLL M
  divider for 6 MHz bandwidth than others. Have you looked those are
  really correct? I suspect there could be some other Xtal than 16MHz
  and thus those are wrong. Which Xtals there is inside device used?
  There is most likely 3 Xtals, one for each chip. It is metal box
  nearest to chip.
  
  I left 6MHz like it was before in the driver. I try to do other way,
  allowing to put different PLL in config that the default ones of the
  driver and initialize it in init.
  
  Jose Alberto
  
  Attached new version of the patch. Adding tda827x lna and doing tda10048
  pll in other way.
  
  Jose Alberto
  
  Another version, without tda827x lna. It don't improve anything.
  
  Jose Alberto
  
  Ran checkpatch.pl also to find out style issues before send patch.
  
  I have send new version, hopefully final, of MFE. It changes array
  name from adap-mfe to adap-fe. You should also update that.
  
  
  regards
  Antti
  
  --
  To unsubscribe from this list: send the line unsubscribe linux-media
  in the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Martes, 2 de Agosto de 2011 21:21:13 Jose Alberto Reguero escribió:
 On Jueves, 28 de Julio de 2011 21:25:01 Jose Alberto Reguero escribió:
  On Miércoles, 27 de Julio de 2011 21:22:26 Antti Palosaari escribió:
   On 07/24/2011 12:45 AM, Jose Alberto Reguero wrote:
Read without write work as with write. Attached updated patch.

ttusb2-6.diff

-   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+   write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+   read = msg[i].flags  I2C_M_RD;
   
   ttusb2 I2C-adapter seems to be fine for my eyes now. No more writing
   any random bytes in case of single read. Good!
   
+   .dtv6_if_freq_khz = TDA10048_IF_4000,
+   .dtv7_if_freq_khz = TDA10048_IF_4500,
+   .dtv8_if_freq_khz = TDA10048_IF_5000,
+   .clk_freq_khz = TDA10048_CLK_16000,


+static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
   
   cosmetic issue rename to ttusb2_ct3650_i2c_gate_ctrl
   
{ TDA10048_CLK_16000, TDA10048_IF_4000,  10, 3, 0 },

+   { TDA10048_CLK_16000, TDA10048_IF_4500,   5, 3, 0 },
+   { TDA10048_CLK_16000, TDA10048_IF_5000,   5, 3, 0 },

+   /* Set the  pll registers */
+   tda10048_writereg(state, TDA10048_CONF_PLL1, 0x0f);
+   tda10048_writereg(state, TDA10048_CONF_PLL2, (u8)(state-
  
  pll_mfactor));
  
+   tda10048_writereg(state, TDA10048_CONF_PLL3,
tda10048_readreg(state, TDA10048_CONF_PLL3) |
((u8)(state-pll_nfactor) | 0x40));
   
   This if only issue can have effect to functionality and I want double
   check. I see few things.
   
   1) clock (and PLL) settings should be done generally only once at
   .init() and probably .sleep() in case of needed for sleep. Something
   like start clock in init, stop clock in sleep. It is usually very first
   thing to set before other. Now it is in wrong place - .set_frontend().
   
   2) Those clock settings seem somehow weird. As you set different PLL M
   divider for 6 MHz bandwidth than others. Have you looked those are
   really correct? I suspect there could be some other Xtal than 16MHz and
   thus those are wrong. Which Xtals there is inside device used? There is
   most likely 3 Xtals, one for each chip. It is metal box nearest to
   chip.
  
  I left 6MHz like it was before in the driver. I try to do other way,
  allowing to put different PLL in config that the default ones of the
  driver and initialize it in init.
  
  Jose Alberto
 
 Attached new version of the patch. Adding tda827x lna and doing tda10048
 pll in other way.
 
 Jose Alberto

Another version, without tda827x lna. It don't improve anything.

Jose Alberto

 
   Ran checkpatch.pl also to find out style issues before send patch.
   
   I have send new version, hopefully final, of MFE. It changes array name
   from adap-mfe to adap-fe. You should also update that.
   
   
   regards
   Antti
  
  --
  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
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-01 05:45:24.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-08 12:22:59.624061045 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -82,7 +83,7 @@
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	static u8 obuf[60], ibuf[60];
-	int i,read;
+	int i, write_read, read;
 
 	if (mutex_lock_interruptible(d-i2c_mutex)  0)
 		return -EAGAIN;
@@ -91,28 +92,35 @@
 		warn(more than 2 i2c messages at a time is not handled yet. TODO.);
 
 	for (i = 0; i  num; i++) {
-		read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read = msg[i].flags  I2C_M_RD;
 
-		obuf[0] = (msg[i].addr  1) | read;
-		obuf[1] = msg[i].len;
+		obuf[0] = (msg[i].addr  1) | (write_read | read);
+		if (read)
+			obuf[1] = 0;
+		else
+			obuf[1] = msg[i].len;
 
 		/* read request */
-		if (read)
+		if (write_read)
 			obuf[2] = msg[i+1].len;
+		else if (read)
+			obuf[2] = msg[i].len;
 		else
 			obuf[2] = 0;
 
-		memcpy(obuf[3],msg[i].buf,msg[i].len);
+		memcpy(obuf[3], msg[i].buf, msg[i].len);
 
 		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3)  0) {
 			err(i2c transfer failed.);
 			break;
 		}
 
-		if (read) {
-			memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
+		if (write_read) {
+			memcpy(msg[i+1].buf, ibuf[3], msg[i+1].len);
 			i++;
-		}
+		} else if (read)
+			memcpy(msg[i].buf, ibuf[3], msg[i].len);
 	}
 
 	mutex_unlock(d-i2c_mutex);
@@ -190,6 +198,25 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Jueves, 28 de Julio de 2011 21:25:01 Jose Alberto Reguero escribió:
 On Miércoles, 27 de Julio de 2011 21:22:26 Antti Palosaari escribió:
  On 07/24/2011 12:45 AM, Jose Alberto Reguero wrote:
   Read without write work as with write. Attached updated patch.
   
   ttusb2-6.diff
   
   - read = i+1  num  (msg[i+1].flags  I2C_M_RD);
   + write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
   + read = msg[i].flags  I2C_M_RD;
  
  ttusb2 I2C-adapter seems to be fine for my eyes now. No more writing any
  random bytes in case of single read. Good!
  
   + .dtv6_if_freq_khz = TDA10048_IF_4000,
   + .dtv7_if_freq_khz = TDA10048_IF_4500,
   + .dtv8_if_freq_khz = TDA10048_IF_5000,
   + .clk_freq_khz = TDA10048_CLK_16000,
   
   
   +static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
  
  cosmetic issue rename to ttusb2_ct3650_i2c_gate_ctrl
  
 { TDA10048_CLK_16000, TDA10048_IF_4000,  10, 3, 0 },
   
   + { TDA10048_CLK_16000, TDA10048_IF_4500,   5, 3, 0 },
   + { TDA10048_CLK_16000, TDA10048_IF_5000,   5, 3, 0 },
   
   + /* Set the  pll registers */
   + tda10048_writereg(state, TDA10048_CONF_PLL1, 0x0f);
   + tda10048_writereg(state, TDA10048_CONF_PLL2, (u8)(state-
 
 pll_mfactor));
 
   + tda10048_writereg(state, TDA10048_CONF_PLL3, tda10048_readreg(state,
   TDA10048_CONF_PLL3) | ((u8)(state-pll_nfactor) | 0x40));
  
  This if only issue can have effect to functionality and I want double
  check. I see few things.
  
  1) clock (and PLL) settings should be done generally only once at
  .init() and probably .sleep() in case of needed for sleep. Something
  like start clock in init, stop clock in sleep. It is usually very first
  thing to set before other. Now it is in wrong place - .set_frontend().
  
  2) Those clock settings seem somehow weird. As you set different PLL M
  divider for 6 MHz bandwidth than others. Have you looked those are
  really correct? I suspect there could be some other Xtal than 16MHz and
  thus those are wrong. Which Xtals there is inside device used? There is
  most likely 3 Xtals, one for each chip. It is metal box nearest to chip.
 
 I left 6MHz like it was before in the driver. I try to do other way,
 allowing to put different PLL in config that the default ones of the
 driver and initialize it in init.
 
 Jose Alberto
 

Attached new version of the patch. Adding tda827x lna and doing tda10048 pll 
in other way.

Jose Alberto

  Ran checkpatch.pl also to find out style issues before send patch.
  
  I have send new version, hopefully final, of MFE. It changes array name
  from adap-mfe to adap-fe. You should also update that.
  
  
  regards
  Antti
 
 --
 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
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-01 05:45:24.0 +0200
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-08-02 21:09:18.363001064 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -82,7 +83,7 @@
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	static u8 obuf[60], ibuf[60];
-	int i,read;
+	int i, write_read, read;
 
 	if (mutex_lock_interruptible(d-i2c_mutex)  0)
 		return -EAGAIN;
@@ -91,28 +92,35 @@
 		warn(more than 2 i2c messages at a time is not handled yet. TODO.);
 
 	for (i = 0; i  num; i++) {
-		read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read = msg[i].flags  I2C_M_RD;
 
-		obuf[0] = (msg[i].addr  1) | read;
-		obuf[1] = msg[i].len;
+		obuf[0] = (msg[i].addr  1) | (write_read | read);
+		if (read)
+			obuf[1] = 0;
+		else
+			obuf[1] = msg[i].len;
 
 		/* read request */
-		if (read)
+		if (write_read)
 			obuf[2] = msg[i+1].len;
+		else if (read)
+			obuf[2] = msg[i].len;
 		else
 			obuf[2] = 0;
 
-		memcpy(obuf[3],msg[i].buf,msg[i].len);
+		memcpy(obuf[3], msg[i].buf, msg[i].len);
 
 		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3)  0) {
 			err(i2c transfer failed.);
 			break;
 		}
 
-		if (read) {
-			memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
+		if (write_read) {
+			memcpy(msg[i+1].buf, ibuf[3], msg[i+1].len);
 			i++;
-		}
+		} else if (read)
+			memcpy(msg[i].buf, ibuf[3], msg[i].len);
 	}
 
 	mutex_unlock(d-i2c_mutex);
@@ -190,6 +198,25 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1,
+	.output_mode  = TDA10048_PARALLEL_OUTPUT,
+	.inversion= TDA10048_INVERSION_ON,
+	.dtv6_if_freq_khz = TDA10048_IF_4000,
+	.dtv7_if_freq_khz = TDA10048_IF_4500,
+	.dtv8_if_freq_khz = TDA10048_IF_5000,
+	.clk_freq_khz = TDA10048_CLK_16000,
+	.no_firmware  = 1,
+	.set_pll  = true

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Miércoles, 27 de Julio de 2011 21:22:26 Antti Palosaari escribió:
 On 07/24/2011 12:45 AM, Jose Alberto Reguero wrote:
  Read without write work as with write. Attached updated patch.
  
  ttusb2-6.diff
  
  -   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   write_read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   read = msg[i].flags  I2C_M_RD;
 
 ttusb2 I2C-adapter seems to be fine for my eyes now. No more writing any
 random bytes in case of single read. Good!
 
  +   .dtv6_if_freq_khz = TDA10048_IF_4000,
  +   .dtv7_if_freq_khz = TDA10048_IF_4500,
  +   .dtv8_if_freq_khz = TDA10048_IF_5000,
  +   .clk_freq_khz = TDA10048_CLK_16000,
  
  
  +static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
 
 cosmetic issue rename to ttusb2_ct3650_i2c_gate_ctrl
 
  { TDA10048_CLK_16000, TDA10048_IF_4000,  10, 3, 0 },
  
  +   { TDA10048_CLK_16000, TDA10048_IF_4500,   5, 3, 0 },
  +   { TDA10048_CLK_16000, TDA10048_IF_5000,   5, 3, 0 },
  
  +   /* Set the  pll registers */
  +   tda10048_writereg(state, TDA10048_CONF_PLL1, 0x0f);
  +   tda10048_writereg(state, TDA10048_CONF_PLL2, (u8)(state-
pll_mfactor));
  +   tda10048_writereg(state, TDA10048_CONF_PLL3, tda10048_readreg(state,
  TDA10048_CONF_PLL3) | ((u8)(state-pll_nfactor) | 0x40));
 
 This if only issue can have effect to functionality and I want double
 check. I see few things.
 
 1) clock (and PLL) settings should be done generally only once at
 .init() and probably .sleep() in case of needed for sleep. Something
 like start clock in init, stop clock in sleep. It is usually very first
 thing to set before other. Now it is in wrong place - .set_frontend().
 
 2) Those clock settings seem somehow weird. As you set different PLL M
 divider for 6 MHz bandwidth than others. Have you looked those are
 really correct? I suspect there could be some other Xtal than 16MHz and
 thus those are wrong. Which Xtals there is inside device used? There is
 most likely 3 Xtals, one for each chip. It is metal box nearest to chip.

I left 6MHz like it was before in the driver. I try to do other way, allowing 
to put different PLL in config that the default ones of the driver and 
initialize it in init.

Jose Alberto

 
 
 Ran checkpatch.pl also to find out style issues before send patch.
 
 I have send new version, hopefully final, of MFE. It changes array name
 from adap-mfe to adap-fe. You should also update that.
 
 
 regards
 Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Sábado, 23 de Julio de 2011 00:23:05 Antti Palosaari escribió:
 On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
  On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
  On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
  On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
  Have you had to time test these?
  
  And about I2C adapter, I don't see why changes are needed. As far
  as I understand it is already working with TDA10023 and you have
  done changes for TDA10048 support. I compared TDA10048 and
  TDA10023 I2C functions and those are ~similar. Both uses most
  typical access, for reg write {u8 REG, u8 VAL} and for reg read
  {u8 REG}/{u8 VAL}.
  
  regards
  Antti
  
  I just finish the testing. The changes to I2C are for the tuner
  tda827x. The MFE fork fine. I need to change the code in tda10048
  and ttusb2. Attached is the patch for CT-3650 with your MFE patch.
  
  You still pass tda10023 fe pointer to tda10048 for I2C-gate control
  which is wrong. Could you send USB sniff I can look what there really
  happens. If you have raw SniffUSB2 logs I wish to check those, other
  logs are welcome too if no raw SniffUSB2 available.
  
  Youre chnage don't work. You need to change the function i2c gate of
  tda1048 for the one of tda1023, but the parameter of this function
  must be the fe pointer of tda1023. If this is a problem, I can
  duplicate tda1023 i2c gate in ttusb2 code and pass it to the
  tda10048. It is done this way in the first patch of this thread.
  
  Yes I now see why it cannot work - since FE is given as a parameter to
  i2c_gate_ctrl it does not see correct priv and used I2C addr is read
  from priv. You must implement own i2c_gate_ctrl in ttusb2 driver.
  Implement own ct3650_i2c_gate_ctrl and override tda10048 i2c_gate_ctrl
  using that. Then call tda10023 i2c_gate_ctrl but instead of tda10048 FE
  use td10023 FE. Something like
  
  static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
  {
  
return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE,
enable);
  
  }
  
  /* tuner is behind TDA10023 I2C-gate */
  adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
  
  
  Could you still send USB logs? I don't see it correct behaviour you
  need to change I2C-adaper when same tuner is used for DVB-T because it
  was already working in DVB-C mode.
  
  regards
  Antti
  
  Thanks, I try to implement that. I attach a processed log. It prints the
  first line of a usb command and the first line of the returned byes. If
  you want the full log I can upload it where you want.
  
  Jose Alberto
  
  New version with Antti's sugestion.
 
 GOOD! As you can see implementing things correctly drops also much lines
 of code! No more ugly hacks in TDA10048 driver.
 
 But now you must fix that I2C-adapter. I looked sniffs and tda827x
 driver. I2C is rather clear. tda827x uses a little bit unusual I2C read.
 Normally reads are done as I2C write+read combination, that tuner, as
 many other NXP tuners, uses only single read and it is starting always
 from reg 0.
 
 It looked for my eyes that it will never do read operation as in read
 there is num = 1, msg[0].flags = I2C_M_RD
 
 ttusb2_i2c_xfer():
   for (i = 0; i  num; i++) {
   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
 
 But in the case it have been working for DVB-C I don't understand why it
 does not work for DVB-T. And thus I really suspect your changes to
 I2C-adapter are not needed. So whats the problem using original I2C
 adapter? What does it print when debugs are enabled. Is there some
 errors in log?
 
 Also looking from sniffs, it seems that this could be wrong:
   (rlen  0  r[3] != rlen)) {
   warn(there might have been an error during control message 
transfer.
 (rlen = %d, was %d),rlen,r[3]);
 
 
 regards
 Antti

The problem is in i2c read in tda827x_probe_version. Without the fix sometimes, 
when changing the code the tuner is detected as  tda827xo instead of tda827xa. 
That is because the variable where i2c read should store the value is 
initialized, and sometimes it works.

Jose Alberto
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
 On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
  On Sábado, 23 de Julio de 2011 00:23:05 Antti Palosaari escribió:
  On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
  On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
  On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
  On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
  Have you had to time test these?
  
  And about I2C adapter, I don't see why changes are needed. As far
  as I understand it is already working with TDA10023 and you have
  done changes for TDA10048 support. I compared TDA10048 and
  TDA10023 I2C functions and those are ~similar. Both uses most
  typical access, for reg write {u8 REG, u8 VAL} and for reg read
  {u8 REG}/{u8 VAL}.
  
  regards
  Antti
  
  I just finish the testing. The changes to I2C are for the tuner
  tda827x. The MFE fork fine. I need to change the code in tda10048
  and ttusb2. Attached is the patch for CT-3650 with your MFE patch.
  
  You still pass tda10023 fe pointer to tda10048 for I2C-gate control
  which is wrong. Could you send USB sniff I can look what there
  really happens. If you have raw SniffUSB2 logs I wish to check
  those, other logs are welcome too if no raw SniffUSB2 available.
  
  Youre chnage don't work. You need to change the function i2c gate of
  tda1048 for the one of tda1023, but the parameter of this function
  must be the fe pointer of tda1023. If this is a problem, I can
  duplicate tda1023 i2c gate in ttusb2 code and pass it to the
  tda10048. It is done this way in the first patch of this thread.
  
  Yes I now see why it cannot work - since FE is given as a parameter
  to i2c_gate_ctrl it does not see correct priv and used I2C addr is
  read from priv. You must implement own i2c_gate_ctrl in ttusb2
  driver. Implement own ct3650_i2c_gate_ctrl and override tda10048
  i2c_gate_ctrl using that. Then call tda10023 i2c_gate_ctrl but
  instead of tda10048 FE use td10023 FE. Something like
  
  static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
  {
  
  return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE,
  enable);
  
  }
  
  /* tuner is behind TDA10023 I2C-gate */
  adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
  
  
  Could you still send USB logs? I don't see it correct behaviour you
  need to change I2C-adaper when same tuner is used for DVB-T because
  it was already working in DVB-C mode.
  
  regards
  Antti
  
  Thanks, I try to implement that. I attach a processed log. It prints
  the first line of a usb command and the first line of the returned
  byes. If you want the full log I can upload it where you want.
  
  Jose Alberto
  
  New version with Antti's sugestion.
  
  GOOD! As you can see implementing things correctly drops also much lines
  of code! No more ugly hacks in TDA10048 driver.
  
  But now you must fix that I2C-adapter. I looked sniffs and tda827x
  driver. I2C is rather clear. tda827x uses a little bit unusual I2C read.
  Normally reads are done as I2C write+read combination, that tuner, as
  many other NXP tuners, uses only single read and it is starting always
  from reg 0.
  
  It looked for my eyes that it will never do read operation as in read
  there is num = 1, msg[0].flags = I2C_M_RD
  
  ttusb2_i2c_xfer():
 for (i = 0; i  num; i++) {
 
 read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  
  But in the case it have been working for DVB-C I don't understand why it
  does not work for DVB-T. And thus I really suspect your changes to
  I2C-adapter are not needed. So whats the problem using original I2C
  adapter? What does it print when debugs are enabled. Is there some
  errors in log?
  
  Also looking from sniffs, it seems that this could be wrong:
 (rlen  0  r[3] != rlen)) {
 warn(there might have been an error during control message
  
  transfer.
  
  (rlen = %d, was %d),rlen,r[3]);
  
  
  regards
  Antti
  
  The problem is in i2c read in tda827x_probe_version. Without the fix
  sometimes, when changing the code the tuner is detected as  tda827xo
  instead of tda827xa. That is because the variable where i2c read should
  store the value is initialized, and sometimes it works.
 
 struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
  .buf = data, .len = 1 };
 
 rc = tuner_transfer(fe, msg, 1);
 
 :-( Could you read what I write. It is a little bit annoying to find out
 
 everything for you. You just answer every time something like it does
 not work and I should always find out what's problem.
 
 As I pointed out read will never work since I2C adapter supports only
 read done in WRITE+READ combination. Driver uses read

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Sábado, 23 de Julio de 2011 12:37:53 Antti Palosaari escribió:
 On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
  On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
  On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
  The problem is in i2c read in tda827x_probe_version. Without the fix
  sometimes, when changing the code the tuner is detected as  tda827xo
  instead of tda827xa. That is because the variable where i2c read should
  store the value is initialized, and sometimes it works.
  
  struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
  
.buf =data, .len = 1 };
  
  rc = tuner_transfer(fe,msg, 1);
  
  :-( Could you read what I write. It is a little bit annoying to find out
  
  everything for you. You just answer every time something like it does
  not work and I should always find out what's problem.
  
  As I pointed out read will never work since I2C adapter supports only
  read done in WRITE+READ combination. Driver uses read which is single
  READ without write.
  
  You should implement new read. You can look example from af9015 or other
  drivers using tda827x
  
  This have been never worked thus I Cc Guy Martin who have added DVB-C
  support for that device.
  
  
  regards
  Antti
  
  I don't understand you. I think that you don' see the fix, but the old
  code. Old code:
  
  read = i+1   num   (msg[i+1].flags   I2C_M_RD);
  
  Fix:
  
  read1 = i+1  num  (msg[i+1].flags  I2C_M_RD); for the tda10023 and
  tda10048 read2 = msg[i].flags  I2C_M_RD; for the tda827x
  
  Jose Alberto
 
 First of all I must apologize of blaming you about that I2C adapter,
 sorry, I should going to shame now. It was me who doesn't read your
 changes as should :/
 
 Your changes are logically OK and implements correctly single reading as
 needed. Some comments still;
 * consider renaming read1 and read2 for example write_read and read
 * obuf[1] contains WRITE len. your code sets that now as READ len.
 Probably it should be 0 always in single write since no bytes written.
 * remove useless checks from end of the if (foo) if (foo);
 if (read1 || read2) {
   if (read1) {
 [...]
   } else if (read2)
 
 If you store some variables at the beginning, olen, ilen, obuf, ibuf,
 you can increase i++ for write+read and rest of the code in function can
 be same (no more if read or write + read). But maybe it is safe to keep
 closer original than change such much.
 
 
 regards
 Antti

There are a second i2c read, but less important.It is in:

tda827xa_set_params


buf[0] = 0xa0;
buf[1] = 0x40;
msg.len = 2;
rc = tuner_transfer(fe, msg, 1);
if (rc  0)
goto err;

msleep(11);
msg.flags = I2C_M_RD;
rc = tuner_transfer(fe, msg, 1);
if (rc  0)
goto err;
msg.flags = 0;

buf[1] = 4;

I supposed that buf[0] is the register to read and they read the value in 
buf[1]. The code now seem to work ok but perhaps is wrong.

Jose Alberto
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Sábado, 23 de Julio de 2011 19:47:27 Antti Palosaari escribió:
 On 07/23/2011 06:41 PM, Jose Alberto Reguero wrote:
  On Sábado, 23 de Julio de 2011 12:37:53 Antti Palosaari escribió:
  On 07/23/2011 01:21 PM, Jose Alberto Reguero wrote:
  On Sábado, 23 de Julio de 2011 11:42:58 Antti Palosaari escribió:
  On 07/23/2011 11:26 AM, Jose Alberto Reguero wrote:
  The problem is in i2c read in tda827x_probe_version. Without the fix
  sometimes, when changing the code the tuner is detected as  tda827xo
  instead of tda827xa. That is because the variable where i2c read
  should store the value is initialized, and sometimes it works.
  
  struct i2c_msg msg = { .addr = priv-i2c_addr, .flags = I2C_M_RD,
  
  .buf =data, .len = 1 };
  
  rc = tuner_transfer(fe,msg, 1);
  
  :-( Could you read what I write. It is a little bit annoying to find
  :out
  
  everything for you. You just answer every time something like it does
  not work and I should always find out what's problem.
  
  As I pointed out read will never work since I2C adapter supports only
  read done in WRITE+READ combination. Driver uses read which is single
  READ without write.
  
  You should implement new read. You can look example from af9015 or
  other drivers using tda827x
  
  This have been never worked thus I Cc Guy Martin who have added DVB-C
  support for that device.
  
  
  regards
  Antti
  
  I don't understand you. I think that you don' see the fix, but the old
  code. Old code:
  
  read = i+1num(msg[i+1].flagsI2C_M_RD);
  
  Fix:
  
  read1 = i+1   num   (msg[i+1].flags   I2C_M_RD); for the tda10023
  and tda10048 read2 = msg[i].flags   I2C_M_RD; for the tda827x
  
  Jose Alberto
  
  First of all I must apologize of blaming you about that I2C adapter,
  sorry, I should going to shame now. It was me who doesn't read your
  changes as should :/
  
  Your changes are logically OK and implements correctly single reading as
  needed. Some comments still;
  * consider renaming read1 and read2 for example write_read and read
  * obuf[1] contains WRITE len. your code sets that now as READ len.
  Probably it should be 0 always in single write since no bytes written.
  * remove useless checks from end of the if (foo) if (foo);
  if (read1 || read2) {
  
 if (read1) {
  
  [...]
  
 } else if (read2)
  
  If you store some variables at the beginning, olen, ilen, obuf, ibuf,
  you can increase i++ for write+read and rest of the code in function can
  be same (no more if read or write + read). But maybe it is safe to keep
  closer original than change such much.
  
  
  regards
  Antti
  
  There are a second i2c read, but less important.It is in:
  
  tda827xa_set_params
  
  
  
   buf[0] = 0xa0;
   buf[1] = 0x40;
   msg.len = 2;
   rc = tuner_transfer(fe,msg, 1);
   if (rc  0)
   
   goto err;
   
   msleep(11);
   msg.flags = I2C_M_RD;
   rc = tuner_transfer(fe,msg, 1);
   if (rc  0)
   
   goto err;
   
   msg.flags = 0;
   
   buf[1]= 4;
  
  
  I supposed that buf[0] is the register to read and they read the value in
  buf[1]. The code now seem to work ok but perhaps is wrong.
 
 This one is as translated to normal C we usually use;
 write_reg(0xa0, 0x40); // write one reg
 read_regs(2); // read 2 regs
 
 example from the sniff
   AA B0 31 05 C2 02 00 A0 40ª°1.Â.. @
   55 B0 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC   U°1.Â..JDq¬ì
   AA B1 31 05 C2 02 00 30 11ª±1.Â..0.
   55 B1 31 03 C2 02 00 4A 44 08 00 00 00 71 AC EC   U±1.Â..JDq¬ì
 
 
 AA USB direction to device
 B1 USB msg seq
 31 USB cmd
 05 USB data len (4+5=9, 4=hdr len, 5=data len, 9=total)
 C2 I2C addr (addr  1)
 02 I2C write len
 00 I2C read len
 30 I2C data [0]
 11 I2C data [1]
 
 So it seems actually to write 30 11 and then read 4a 44 as reply. But if
 you read driver code it does not write 30 11 instead just reads. Maybe
 buggy I2C adap implementation or buggy tuner driver (Linux driver or
 driver where sniff taken). Try to read without write and with write and
 compare if there is any difference.
 
 
 regards
 Antti

Read without write work as with write. Attached updated patch.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-07-23 23:12:29.341385243 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -82,7 +83,7 @@
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	static u8 obuf[60], ibuf[60];
-	int i,read;
+	int i, write_read, read

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
 Have you had to time test these?
 
 And about I2C adapter, I don't see why changes are needed. As far as I
 understand it is already working with TDA10023 and you have done changes
 for TDA10048 support. I compared TDA10048 and TDA10023 I2C functions and
 those are ~similar. Both uses most typical access, for reg write {u8
 REG, u8 VAL} and for reg read {u8 REG}/{u8 VAL}.
 
 regards
 Antti
 
I just finish the testing. The changes to I2C are for the tuner tda827x. The 
MFE fork fine. I need to change the code in tda10048 and ttusb2. Attached is 
the patch for CT-3650 with your MFE patch.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto


 
 On 07/20/2011 02:07 AM, Antti Palosaari wrote:
  On 07/19/2011 11:25 AM, Jose Alberto Reguero wrote:
  On Martes, 19 de Julio de 2011 01:44:54 Antti Palosaari escribió:
  On 07/19/2011 02:00 AM, Jose Alberto Reguero wrote:
  On Lunes, 18 de Julio de 2011 22:28:41 Antti Palosaari escribió:
  
  There are two problems:
  
  First, the two frontends (tda10048 and tda10023) use tda10023 i2c gate
  to talk with the tuner.
  
  Very easy to implement correctly. Attach tda10023 first and after that
  tda10048. Override tda10048 .i2c_gate_ctrl() with tda10023
  .i2c_gate_ctrl() immediately after tda10048 attach inside ttusb2.c. Now
  you have both demods (FEs) .i2c_gate_ctrl() which will control
  physically tda10023 I2C-gate as tuner is behind it.
  
  I try that, but don't work. I get an oops. Because the i2c gate
  function of
  the tda10023 driver use:
  
  struct tda10023_state* state = fe-demodulator_priv;
  
  to get the i2c adress. When called from tda10048, don't work.
  
  Jose Alberto
  
  The second is that with dvb-usb, there is only one frontend, and if
  you wake up the second frontend, the adapter is not wake up. That can
  be avoided the way I do in the patch, or mantaining the adapter
  alwais on.
  
  I think that could be also avoided similarly overriding demod callbacks
  and adding some more logic inside ttusb2.c.
  
  Proper fix that later problem is surely correct MFE support for
  DVB-USB-framework. I am now looking for it, lets see how difficult it
  will be.
  
  Signed-off-by: Antti Palosaari cr...@iki.fi
  
  Test attached patches and try to fix if they are not working. Most
  likely not working since I don't have HW to test... I tested MFE parts
  using Anysee, so it should be working. I changed rather much your ttusb2
  and tda10048 patches, size reduced something like 50% or more. Still
  ttusb2 I2C-adapter changes made looks rather complex. Try to double
  check if those can be done easier. There is many drivers to look example
  from.
  
  DVB USB MFE is something like RFC. I know FE exclusive lock is missing,
  no need to mention that :) But other comments are welcome! I left three
  old unneeded pointers to struct dvb_usb_adapter to reduce changing all
  the drivers.
  
  
  regards
  Antti
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-07-22 14:48:10.526000638 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -82,7 +83,7 @@
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	static u8 obuf[60], ibuf[60];
-	int i,read;
+	int i, read1, read2;
 
 	if (mutex_lock_interruptible(d-i2c_mutex)  0)
 		return -EAGAIN;
@@ -91,27 +92,33 @@
 		warn(more than 2 i2c messages at a time is not handled yet. TODO.);
 
 	for (i = 0; i  num; i++) {
-		read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read1 = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read2 = msg[i].flags  I2C_M_RD;
 
-		obuf[0] = (msg[i].addr  1) | read;
+		obuf[0] = (msg[i].addr  1) | (read1 | read2);
 		obuf[1] = msg[i].len;
 
 		/* read request */
-		if (read)
+		if (read1)
 			obuf[2] = msg[i+1].len;
+		else if (read2)
+			obuf[2] = msg[i].len;
 		else
 			obuf[2] = 0;
 
-		memcpy(obuf[3],msg[i].buf,msg[i].len);
+		memcpy(obuf[3], msg[i].buf, msg[i].len);
 
 		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3)  0) {
 			err(i2c transfer failed.);
 			break;
 		}
 
-		if (read) {
-			memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
-			i++;
+		if (read1 || read2) {
+			if (read1) {
+memcpy(msg[i+1].buf, ibuf[3], msg[i+1].len);
+i++;
+			} else if (read2)
+memcpy(msg[i].buf, ibuf[3], msg[i].len);
 		}
 	}
 
@@ -190,6 +197,21 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1,
+	.output_mode  = TDA10048_PARALLEL_OUTPUT,
+	.inversion= TDA10048_INVERSION_ON,
+	.dtv6_if_freq_khz = TDA10048_IF_4000,
+	.dtv7_if_freq_khz = TDA10048_IF_4500,
+	.dtv8_if_freq_khz = TDA10048_IF_5000,
+	.clk_freq_khz = TDA10048_CLK_16000

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
 On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
  On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
  Have you had to time test these?
  
  And about I2C adapter, I don't see why changes are needed. As far as I
  understand it is already working with TDA10023 and you have done changes
  for TDA10048 support. I compared TDA10048 and TDA10023 I2C functions and
  those are ~similar. Both uses most typical access, for reg write {u8
  REG, u8 VAL} and for reg read {u8 REG}/{u8 VAL}.
  
  regards
  Antti
  
  I just finish the testing. The changes to I2C are for the tuner tda827x.
  The MFE fork fine. I need to change the code in tda10048 and ttusb2.
  Attached is the patch for CT-3650 with your MFE patch.
 
 You still pass tda10023 fe pointer to tda10048 for I2C-gate control
 which is wrong. Could you send USB sniff I can look what there really
 happens. If you have raw SniffUSB2 logs I wish to check those, other
 logs are welcome too if no raw SniffUSB2 available.
 

Youre chnage don't work. You need to change the function i2c gate of tda1048 
for the one of tda1023, but the parameter of this function must be the fe 
pointer of tda1023. If this is a problem, I can duplicate tda1023 i2c gate in 
ttusb2 code and pass it to the tda10048. It is done this way in the first patch 
of this thread.

Jose Alberto
  
 regards
 Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
 On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
  On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
   On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
   On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
   On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
   Have you had to time test these?
   
   And about I2C adapter, I don't see why changes are needed. As far as
   I understand it is already working with TDA10023 and you have done
   changes for TDA10048 support. I compared TDA10048 and TDA10023 I2C
   functions and those are ~similar. Both uses most typical access,
   for reg write {u8 REG, u8 VAL} and for reg read {u8 REG}/{u8 VAL}.
   
   regards
   Antti
   
   I just finish the testing. The changes to I2C are for the tuner
   tda827x. The MFE fork fine. I need to change the code in tda10048 and
   ttusb2. Attached is the patch for CT-3650 with your MFE patch.
   
   You still pass tda10023 fe pointer to tda10048 for I2C-gate control
   which is wrong. Could you send USB sniff I can look what there really
   happens. If you have raw SniffUSB2 logs I wish to check those, other
   logs are welcome too if no raw SniffUSB2 available.
   
   Youre chnage don't work. You need to change the function i2c gate of
   tda1048 for the one of tda1023, but the parameter of this function must
   be the fe pointer of tda1023. If this is a problem, I can duplicate
   tda1023 i2c gate in ttusb2 code and pass it to the tda10048. It is done
   this way in the first patch of this thread.
  
  Yes I now see why it cannot work - since FE is given as a parameter to
  i2c_gate_ctrl it does not see correct priv and used I2C addr is read
  from priv. You must implement own i2c_gate_ctrl in ttusb2 driver.
  Implement own ct3650_i2c_gate_ctrl and override tda10048 i2c_gate_ctrl
  using that. Then call tda10023 i2c_gate_ctrl but instead of tda10048 FE
  use td10023 FE. Something like
  
  static int ct3650_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
  {
  
  return adap-mfe[0]-ops.i2c_gate_ctrl(POINTER_TO_TDA10023_FE, enable);
  
  }
  
  /* tuner is behind TDA10023 I2C-gate */
  adap-mfe[1]-ops.i2c_gate_ctrl = ct3650_i2c_gate_ctrl;
  
  
  Could you still send USB logs? I don't see it correct behaviour you need
  to change I2C-adaper when same tuner is used for DVB-T because it was
  already working in DVB-C mode.
  
  regards
  Antti
 
 Thanks, I try to implement that. I attach a processed log. It prints the
 first line of a usb command and the first line of the returned byes. If
 you want the full log I can upload it where you want.
 
 Jose Alberto

New version with Antti's sugestion.

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-07-22 22:15:20.483271578 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -82,7 +83,7 @@
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	static u8 obuf[60], ibuf[60];
-	int i,read;
+	int i, read1, read2;
 
 	if (mutex_lock_interruptible(d-i2c_mutex)  0)
 		return -EAGAIN;
@@ -91,27 +92,33 @@
 		warn(more than 2 i2c messages at a time is not handled yet. TODO.);
 
 	for (i = 0; i  num; i++) {
-		read = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read1 = i+1  num  (msg[i+1].flags  I2C_M_RD);
+		read2 = msg[i].flags  I2C_M_RD;
 
-		obuf[0] = (msg[i].addr  1) | read;
+		obuf[0] = (msg[i].addr  1) | (read1 | read2);
 		obuf[1] = msg[i].len;
 
 		/* read request */
-		if (read)
+		if (read1)
 			obuf[2] = msg[i+1].len;
+		else if (read2)
+			obuf[2] = msg[i].len;
 		else
 			obuf[2] = 0;
 
-		memcpy(obuf[3],msg[i].buf,msg[i].len);
+		memcpy(obuf[3], msg[i].buf, msg[i].len);
 
 		if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, obuf[2] + 3)  0) {
 			err(i2c transfer failed.);
 			break;
 		}
 
-		if (read) {
-			memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
-			i++;
+		if (read1 || read2) {
+			if (read1) {
+memcpy(msg[i+1].buf, ibuf[3], msg[i+1].len);
+i++;
+			} else if (read2)
+memcpy(msg[i].buf, ibuf[3], msg[i].len);
 		}
 	}
 
@@ -190,6 +197,21 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1,
+	.output_mode  = TDA10048_PARALLEL_OUTPUT,
+	.inversion= TDA10048_INVERSION_ON,
+	.dtv6_if_freq_khz = TDA10048_IF_4000,
+	.dtv7_if_freq_khz = TDA10048_IF_4500,
+	.dtv8_if_freq_khz = TDA10048_IF_5000,
+	.clk_freq_khz = TDA10048_CLK_16000,
+	.no_firmware  = 1,
+};
+
+static struct tda827x_config tda827x_config = {
+	.config = 0,
+};
+
 static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter *adap

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Martes, 19 de Julio de 2011 01:44:54 Antti Palosaari escribió:
 On 07/19/2011 02:00 AM, Jose Alberto Reguero wrote:
  On Lunes, 18 de Julio de 2011 22:28:41 Antti Palosaari escribió:
  Hello
  I did some review for this since I was interested of adding MFE for
  Anysee driver which is rather similar (dvb-usb-framework).
  
  I found this patch have rather major issue(s) which should be fixed
  properly.
  
  * it does not compile
  drivers/media/dvb/dvb-usb/dvb-usb.h:24:21: fatal error: dvb-pll.h: No
  such file or directory
  
  Perhaps you need to add:
  -Idrivers/media/dvb/frontends/
  in:
  drivers/media/dvb/frontends/Makefile
  I compile the driver with:
  git://linuxtv.org/mchehab/new_build.git
  and I not have this problem.
 
 Maybe, I was running latest Git. Not big issue.
 
  * it puts USB-bridge functionality to the frontend driver
  
  * 1st FE, TDA10023, is passed as pointer inside config to 2nd FE
  TDA10048. Much of glue sleep, i2c etc, those calls are wrapped back to
  to 1st FE...
  
  * no exclusive locking between MFEs. What happens if both are accessed
  same time?
  
  
  Almost all those are somehow chained to same issue, few calls to 2nd FE
  are wrapped to 1st FE. Maybe IOCTL override callback could help if those
  are really needed.
  
  There are two problems:
  
  First, the two frontends (tda10048 and tda10023)  use tda10023 i2c gate
  to talk with the tuner.
 
 Very easy to implement correctly. Attach tda10023 first and after that
 tda10048. Override tda10048 .i2c_gate_ctrl() with tda10023
 .i2c_gate_ctrl() immediately after tda10048 attach inside ttusb2.c. Now
 you have both demods (FEs) .i2c_gate_ctrl() which will control
 physically tda10023 I2C-gate as tuner is behind it.
 

I try that, but don't work. I get an oops. Because the i2c gate function of 
the tda10023 driver use:

struct tda10023_state* state = fe-demodulator_priv;

to get the i2c adress. When called from tda10048, don't work.

Jose Alberto
 
  The second is that with dvb-usb, there is only one frontend, and if you
  wake up the second frontend, the adapter is not wake up. That can be
  avoided the way I do in the patch, or mantaining the adapter alwais on.
 
 I think that could be also avoided similarly overriding demod callbacks
 and adding some more logic inside ttusb2.c.
 
 Proper fix that later problem is surely correct MFE support for
 DVB-USB-framework. I am now looking for it, lets see how difficult it
 will be.
 
 
 regards
 Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Lunes, 18 de Julio de 2011 22:28:41 Antti Palosaari escribió:
 Hello
 I did some review for this since I was interested of adding MFE for
 Anysee driver which is rather similar (dvb-usb-framework).
 
 I found this patch have rather major issue(s) which should be fixed
 properly.
 
 * it does not compile
 drivers/media/dvb/dvb-usb/dvb-usb.h:24:21: fatal error: dvb-pll.h: No
 such file or directory

Perhaps you need to add:
-Idrivers/media/dvb/frontends/
in:
drivers/media/dvb/frontends/Makefile
I compile the driver with:
git://linuxtv.org/mchehab/new_build.git
and I not have this problem.

 
 * it puts USB-bridge functionality to the frontend driver
 
 * 1st FE, TDA10023, is passed as pointer inside config to 2nd FE
 TDA10048. Much of glue sleep, i2c etc, those calls are wrapped back to
 to 1st FE...
 
 * no exclusive locking between MFEs. What happens if both are accessed
 same time?
 
 
 Almost all those are somehow chained to same issue, few calls to 2nd FE
 are wrapped to 1st FE. Maybe IOCTL override callback could help if those
 are really needed.

There are two problems:

First, the two frontends (tda10048 and tda10023)  use tda10023 i2c gate to 
talk with the tuner. 

The second is that with dvb-usb, there is only one frontend, and if you wake 
up the second frontend, the adapter is not wake up. That can be avoided the 
way I do in the patch, or mantaining the adapter alwais on. 

Jose Alberto

 
 
 regards
 Antti
 
 On 07/14/2011 11:00 PM, Jose Alberto Reguero wrote:
  The attached patch try to fix the problems mentioned.
  
  Jose Alberto
  
  Signed-off-by: Jose Alberto Reguerojaregu...@telefonica.net
  
  
  
  ttusb2-3.diff
  
  
  diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c
  linux.new/drivers/media/dvb/dvb-usb/ttusb2.c ---
  linux/drivers/media/dvb/dvb-usb/ttusb2.c2011-01-10 16:24:45.0
  +0100 +++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c  2011-07-14
  12:55:36.645944109 +0200 @@ -30,6 +30,7 @@
  
#include tda826x.h
#include tda10086.h
#include tda1002x.h
  
  +#include tda10048.h
  
#include tda827x.h
#include lnbp21.h
  
  @@ -44,6 +45,7 @@
  
struct ttusb2_state {

  u8 id;
  u16 last_rc_key;
  
  +   struct dvb_frontend *fe;
  
};

static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
  
  @@ -82,7 +84,7 @@
  
{

  struct dvb_usb_device *d = i2c_get_adapdata(adap);
  static u8 obuf[60], ibuf[60];
  
  -   int i,read;
  +   int i, read1, read2;
  
  if (mutex_lock_interruptible(d-i2c_mutex)  0)
  
  return -EAGAIN;
  
  @@ -91,27 +93,33 @@
  
  warn(more than 2 i2c messages at a time is not handled yet. 
TODO.);
  
  for (i = 0; i  num; i++) {
  
  -   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   read1 = i+1  num  (msg[i+1].flags  I2C_M_RD);
  +   read2 = msg[i].flags  I2C_M_RD;
  
  -   obuf[0] = (msg[i].addr  1) | read;
  +   obuf[0] = (msg[i].addr  1) | (read1 | read2);
  
  obuf[1] = msg[i].len;
  
  /* read request */
  
  -   if (read)
  +   if (read1)
  
  obuf[2] = msg[i+1].len;
  
  +   else if (read2)
  +   obuf[2] = msg[i].len;
  
  else
  
  obuf[2] = 0;
  
  -   memcpy(obuf[3],msg[i].buf,msg[i].len);
  +   memcpy(obuf[3], msg[i].buf, msg[i].len);
  
  if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, 
obuf[2] +
  3)  0) {
  
  err(i2c transfer failed.);
  break;
  
  }
  
  -   if (read) {
  -   memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
  -   i++;
  +   if (read1 || read2) {
  +   if (read1) {
  +   memcpy(msg[i+1].buf,ibuf[3], msg[i+1].len);
  +   i++;
  +   } else if (read2)
  +   memcpy(msg[i].buf,ibuf[3], msg[i].len);
  
  }
  
  }
  
  @@ -190,6 +198,21 @@
  
  .deltaf = 0xa511,

};
  
  +static struct tda10048_config tda10048_config = {
  +   .demod_address= 0x10  1,
  +   .output_mode  = TDA10048_PARALLEL_OUTPUT,
  +   .inversion= TDA10048_INVERSION_ON,
  +   .dtv6_if_freq_khz = TDA10048_IF_4000,
  +   .dtv7_if_freq_khz = TDA10048_IF_4500,
  +   .dtv8_if_freq_khz = TDA10048_IF_5000,
  +   .clk_freq_khz = TDA10048_CLK_16000,
  +   .no_firmware  = 1,
  +};
  +
  +static struct tda827x_config tda827x_config = {
  +   .config = 0,
  +};
  +
  
static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter
*adap) {

  if (usb_set_interface(adap-dev-udev,0,3)  0)
  
  @@ -205,18 +228,32 @@
  
static int ttusb2_frontend_tda10023_attach(struct dvb_usb_adapter
*adap) {
  
  +
  +   struct ttusb2_state *state

[PATCH] improve recection with limits frecuenies and tda827x

[Jose Alberto Reguero]

On Miércoles, 13 de Julio de 2011 14:41:30 Mauro Carvalho Chehab escribió:
 Em 06-07-2011 19:57, Jose Alberto Reguero escreveu:
  This patch add suport for the dvb-t part of CT-3650.
  
  Jose Alberto
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  patches/lmml_951522_add_support_for_the_dvb_t_part_of_ct_3650_v2.patch
  Content-Type: text/plain; charset=utf-8
  MIME-Version: 1.0
  Content-Transfer-Encoding: 7bit
  Subject: add support for the dvb-t part of CT-3650 v2
  Date: Wed, 06 Jul 2011 22:57:04 -
  From: Jose Alberto Reguero jaregu...@telefonica.net
  X-Patchwork-Id: 951522
  Message-Id: 201107070057.06317.jaregu...@telefonica.net
  To: linux-media@vger.kernel.org
  
  This patch add suport for the dvb-t part of CT-3650.
  
  Jose Alberto
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  
  diff -ur linux/drivers/media/common/tuners/tda827x.c
  linux.new/drivers/media/common/tuners/tda827x.c ---
  linux/drivers/media/common/tuners/tda827x.c 2010-07-03
  23:22:08.0 +0200 +++
  linux.new/drivers/media/common/tuners/tda827x.c 2011-07-04
  12:00:29.931561053 +0200 @@ -135,14 +135,29 @@
  
   static int tuner_transfer(struct dvb_frontend *fe,
   
struct i2c_msg *msg,
  
  - const int size)
  + int size)
  
   {
   
  int rc;
  struct tda827x_priv *priv = fe-tuner_priv;
  
  +   struct i2c_msg msgr[2];
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 1);
  
  -   rc = i2c_transfer(priv-i2c_adap, msg, size);
  +   if (priv-cfg-i2cr  (msg-flags == I2C_M_RD)) {
  +   msgr[0].addr = msg-addr;
  +   msgr[0].flags = 0;
  +   msgr[0].len = msg-len - 1;
  +   msgr[0].buf = msg-buf;
  +   msgr[1].addr = msg-addr;
  +   msgr[1].flags = I2C_M_RD;
  +   msgr[1].len = 1;
  +   msgr[1].buf = msg-buf;
  +   size = 2;
  +   rc = i2c_transfer(priv-i2c_adap, msgr, size);
  +   msg-buf[msg-len - 1] = msgr[1].buf[0];
  +   } else {
  +   rc = i2c_transfer(priv-i2c_adap, msg, size);
  +   }
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 0);
 
 No. You should be applying such fix at the I2C adapter instead. This is the
 code at the ttusb2 driver:
 
 static int ttusb2_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg
 msg[],int num) {
   struct dvb_usb_device *d = i2c_get_adapdata(adap);
   static u8 obuf[60], ibuf[60];
   int i,read;
 
   if (mutex_lock_interruptible(d-i2c_mutex)  0)
   return -EAGAIN;
 
   if (num  2)
   warn(more than 2 i2c messages at a time is not handled yet. 
TODO.);
 
   for (i = 0; i  num; i++) {
   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
 
   obuf[0] = (msg[i].addr  1) | read;
   obuf[1] = msg[i].len;
 
   /* read request */
   if (read)
   obuf[2] = msg[i+1].len;
   else
   obuf[2] = 0;
 
   memcpy(obuf[3],msg[i].buf,msg[i].len);
 
   if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, 
 obuf[2] + 
3) 
 0) { err(i2c transfer failed.);
   break;
   }
 
   if (read) {
   memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
   i++;
   }
   }
 
   mutex_unlock(d-i2c_mutex);
   return i;
 }
 
 Clearly, this routine has issues, as it assumes that all transfers with
 reads will be broken into just two msgs, where the first one is a write,
 and a second one is a read, and that no transfers will be bigger than 2
 messages.
 
 It shouldn't be hard to adapt it to handle transfers on either way, and to
 remove the limit of 2 transfers.
 
  @@ -540,7 +555,7 @@
  
  if_freq = 500;
  break;
  
  }
  
  -   tuner_freq = params-frequency + if_freq;
  +   tuner_freq = params-frequency;
  
  if (fe-ops.info.type == FE_QAM) {
  
  dprintk(%s select tda827xa_dvbc\n, __func__);
  
  @@ -554,6 +569,8 @@
  
  i++;
  
  }
  
  +   tuner_freq += if_freq;
  +
  
  N = ((tuner_freq + 31250) / 62500)  frequency_map[i].spd;
  buf[0] = 0;// subaddress
  buf[1] = N  8;
 
 This seems to be a bug fix, but you're touching only at the DVB-C. If the
 table lookup should not consider if_freq, the same fix is needed on the
 other similar logics at the driver.
 
 Also, please send such patch in separate.


Only tested with tda827xa and DVB-T and two limit frecuencies. 

 Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

  diff -ur linux/drivers/media/common/tuners/tda827x.h
  linux.new/drivers/media/common/tuners/tda827x.h ---
  linux/drivers/media/common/tuners/tda827x.h 2010-07-03
  23:22:08.0 +0200 +++
  linux.new/drivers/media

[PATCH] add support for the dvb-t part of CT-3650 v3

[Jose Alberto Reguero]

On Miércoles, 13 de Julio de 2011 14:41:30 Mauro Carvalho Chehab escribió:
 Em 06-07-2011 19:57, Jose Alberto Reguero escreveu:
  This patch add suport for the dvb-t part of CT-3650.
  
  Jose Alberto
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  patches/lmml_951522_add_support_for_the_dvb_t_part_of_ct_3650_v2.patch
  Content-Type: text/plain; charset=utf-8
  MIME-Version: 1.0
  Content-Transfer-Encoding: 7bit
  Subject: add support for the dvb-t part of CT-3650 v2
  Date: Wed, 06 Jul 2011 22:57:04 -
  From: Jose Alberto Reguero jaregu...@telefonica.net
  X-Patchwork-Id: 951522
  Message-Id: 201107070057.06317.jaregu...@telefonica.net
  To: linux-media@vger.kernel.org
  
  This patch add suport for the dvb-t part of CT-3650.
  
  Jose Alberto
  
  Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
  
  
  diff -ur linux/drivers/media/common/tuners/tda827x.c
  linux.new/drivers/media/common/tuners/tda827x.c ---
  linux/drivers/media/common/tuners/tda827x.c 2010-07-03
  23:22:08.0 +0200 +++
  linux.new/drivers/media/common/tuners/tda827x.c 2011-07-04
  12:00:29.931561053 +0200 @@ -135,14 +135,29 @@
  
   static int tuner_transfer(struct dvb_frontend *fe,
   
struct i2c_msg *msg,
  
  - const int size)
  + int size)
  
   {
   
  int rc;
  struct tda827x_priv *priv = fe-tuner_priv;
  
  +   struct i2c_msg msgr[2];
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 1);
  
  -   rc = i2c_transfer(priv-i2c_adap, msg, size);
  +   if (priv-cfg-i2cr  (msg-flags == I2C_M_RD)) {
  +   msgr[0].addr = msg-addr;
  +   msgr[0].flags = 0;
  +   msgr[0].len = msg-len - 1;
  +   msgr[0].buf = msg-buf;
  +   msgr[1].addr = msg-addr;
  +   msgr[1].flags = I2C_M_RD;
  +   msgr[1].len = 1;
  +   msgr[1].buf = msg-buf;
  +   size = 2;
  +   rc = i2c_transfer(priv-i2c_adap, msgr, size);
  +   msg-buf[msg-len - 1] = msgr[1].buf[0];
  +   } else {
  +   rc = i2c_transfer(priv-i2c_adap, msg, size);
  +   }
  
  if (fe-ops.i2c_gate_ctrl)
  
  fe-ops.i2c_gate_ctrl(fe, 0);
 
 No. You should be applying such fix at the I2C adapter instead. This is the
 code at the ttusb2 driver:
 
 static int ttusb2_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg
 msg[],int num) {
   struct dvb_usb_device *d = i2c_get_adapdata(adap);
   static u8 obuf[60], ibuf[60];
   int i,read;
 
   if (mutex_lock_interruptible(d-i2c_mutex)  0)
   return -EAGAIN;
 
   if (num  2)
   warn(more than 2 i2c messages at a time is not handled yet. 
TODO.);
 
   for (i = 0; i  num; i++) {
   read = i+1  num  (msg[i+1].flags  I2C_M_RD);
 
   obuf[0] = (msg[i].addr  1) | read;
   obuf[1] = msg[i].len;
 
   /* read request */
   if (read)
   obuf[2] = msg[i+1].len;
   else
   obuf[2] = 0;
 
   memcpy(obuf[3],msg[i].buf,msg[i].len);
 
   if (ttusb2_msg(d, CMD_I2C_XFER, obuf, msg[i].len+3, ibuf, 
 obuf[2] + 
3) 
 0) { err(i2c transfer failed.);
   break;
   }
 
   if (read) {
   memcpy(msg[i+1].buf,ibuf[3],msg[i+1].len);
   i++;
   }
   }
 
   mutex_unlock(d-i2c_mutex);
   return i;
 }
 
 Clearly, this routine has issues, as it assumes that all transfers with
 reads will be broken into just two msgs, where the first one is a write,
 and a second one is a read, and that no transfers will be bigger than 2
 messages.
 
 It shouldn't be hard to adapt it to handle transfers on either way, and to
 remove the limit of 2 transfers.

  @@ -540,7 +555,7 @@
  
  if_freq = 500;
  break;
  
  }
  
  -   tuner_freq = params-frequency + if_freq;
  +   tuner_freq = params-frequency;
  
  if (fe-ops.info.type == FE_QAM) {
  
  dprintk(%s select tda827xa_dvbc\n, __func__);
  
  @@ -554,6 +569,8 @@
  
  i++;
  
  }
  
  +   tuner_freq += if_freq;
  +
  
  N = ((tuner_freq + 31250) / 62500)  frequency_map[i].spd;
  buf[0] = 0;// subaddress
  buf[1] = N  8;
 
 This seems to be a bug fix, but you're touching only at the DVB-C. If the
 table lookup should not consider if_freq, the same fix is needed on the
 other similar logics at the driver.
 
 Also, please send such patch in separate.
 
  diff -ur linux/drivers/media/common/tuners/tda827x.h
  linux.new/drivers/media/common/tuners/tda827x.h ---
  linux/drivers/media/common/tuners/tda827x.h 2010-07-03
  23:22:08.0 +0200 +++
  linux.new/drivers/media/common/tuners/tda827x.h 2011-05-21
  22:48:31.484340005 +0200 @@ -38,6 +38,8 @@
  
  int  switch_addr;
  
  void (*agcf

[PATCH] add support for the dvb-t part of CT-3650 v2

[Jose Alberto Reguero]

This patch add suport for the dvb-t part of CT-3650.

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/common/tuners/tda827x.c linux.new/drivers/media/common/tuners/tda827x.c
--- linux/drivers/media/common/tuners/tda827x.c	2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.c	2011-07-04 12:00:29.931561053 +0200
@@ -135,14 +135,29 @@
 
 static int tuner_transfer(struct dvb_frontend *fe,
 			  struct i2c_msg *msg,
-			  const int size)
+			  int size)
 {
 	int rc;
 	struct tda827x_priv *priv = fe-tuner_priv;
+	struct i2c_msg msgr[2];
 
 	if (fe-ops.i2c_gate_ctrl)
 		fe-ops.i2c_gate_ctrl(fe, 1);
-	rc = i2c_transfer(priv-i2c_adap, msg, size);
+	if (priv-cfg-i2cr  (msg-flags == I2C_M_RD)) {
+		msgr[0].addr = msg-addr;
+		msgr[0].flags = 0;
+		msgr[0].len = msg-len - 1;
+		msgr[0].buf = msg-buf;
+		msgr[1].addr = msg-addr;
+		msgr[1].flags = I2C_M_RD;
+		msgr[1].len = 1;
+		msgr[1].buf = msg-buf;
+		size = 2;
+		rc = i2c_transfer(priv-i2c_adap, msgr, size);
+		msg-buf[msg-len - 1] = msgr[1].buf[0];
+	} else {
+		rc = i2c_transfer(priv-i2c_adap, msg, size);
+	}
 	if (fe-ops.i2c_gate_ctrl)
 		fe-ops.i2c_gate_ctrl(fe, 0);
 
@@ -540,7 +555,7 @@
 		if_freq = 500;
 		break;
 	}
-	tuner_freq = params-frequency + if_freq;
+	tuner_freq = params-frequency;
 
 	if (fe-ops.info.type == FE_QAM) {
 		dprintk(%s select tda827xa_dvbc\n, __func__);
@@ -554,6 +569,8 @@
 		i++;
 	}
 
+	tuner_freq += if_freq;
+
 	N = ((tuner_freq + 31250) / 62500)  frequency_map[i].spd;
 	buf[0] = 0;// subaddress
 	buf[1] = N  8;
diff -ur linux/drivers/media/common/tuners/tda827x.h linux.new/drivers/media/common/tuners/tda827x.h
--- linux/drivers/media/common/tuners/tda827x.h	2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.h	2011-05-21 22:48:31.484340005 +0200
@@ -38,6 +38,8 @@
 	int 	 switch_addr;
 
 	void (*agcf)(struct dvb_frontend *fe);
+
+	u8 i2cr;
 };
 
 
diff -ur linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-07-05 12:35:51.842182196 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -44,6 +45,7 @@
 struct ttusb2_state {
 	u8 id;
 	u16 last_rc_key;
+	struct dvb_frontend *fe;
 };
 
 static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
@@ -190,6 +190,22 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1,
+	.output_mode  = TDA10048_PARALLEL_OUTPUT,
+	.inversion= TDA10048_INVERSION_ON,
+	.dtv6_if_freq_khz = TDA10048_IF_4000,
+	.dtv7_if_freq_khz = TDA10048_IF_4500,
+	.dtv8_if_freq_khz = TDA10048_IF_5000,
+	.clk_freq_khz = TDA10048_CLK_16000,
+	.no_firmware  = 1,
+};
+
+static struct tda827x_config tda827x_config = {
+	.i2cr = 1,
+	.config = 0,
+};
+
 static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter *adap)
 {
 	if (usb_set_interface(adap-dev-udev,0,3)  0)
@@ -205,18 +221,32 @@
 
 static int ttusb2_frontend_tda10023_attach(struct dvb_usb_adapter *adap)
 {
+
+	struct ttusb2_state *state;
 	if (usb_set_interface(adap-dev-udev, 0, 3)  0)
 		err(set interface to alts=3 failed);
+	state = (struct ttusb2_state *)adap-dev-priv;
 	if ((adap-fe = dvb_attach(tda10023_attach, tda10023_config, adap-dev-i2c_adap, 0x48)) == NULL) {
 		deb_info(TDA10023 attach failed\n);
 		return -ENODEV;
 	}
+	adap-fe-id = 1;
+	tda10048_config.fe = adap-fe;
+	if ((state-fe = dvb_attach(tda10048_attach, tda10048_config, adap-dev-i2c_adap)) == NULL) {
+		deb_info(TDA10048 attach failed\n);
+		return -ENODEV;
+	}
+	dvb_register_frontend(adap-dvb_adap, state-fe);
+	if (dvb_attach(tda827x_attach, state-fe, 0x61, adap-dev-i2c_adap, tda827x_config) == NULL) {
+		printk(KERN_ERR %s: No tda827x found!\n, __func__);
+		return -ENODEV;
+	}
 	return 0;
 }
 
 static int ttusb2_tuner_tda827x_attach(struct dvb_usb_adapter *adap)
 {
-	if (dvb_attach(tda827x_attach, adap-fe, 0x61, adap-dev-i2c_adap, NULL) == NULL) {
+	if (dvb_attach(tda827x_attach, adap-fe, 0x61, adap-dev-i2c_adap, tda827x_config) == NULL) {
 		printk(KERN_ERR %s: No tda827x found!\n, __func__);
 		return -ENODEV;
 	}
@@ -242,6 +272,19 @@
 static struct dvb_usb_device_properties ttusb2_properties_s2400;
 static struct dvb_usb_device_properties ttusb2_properties_ct3650;
 
+static void ttusb2_usb_disconnect (struct usb_interface *intf)
+{
+	struct dvb_usb_device *d = usb_get_intfdata (intf);
+	struct ttusb2_state * state;
+
+	state = (struct ttusb2_state *)d-priv;
+	if (state-fe) {
+		dvb_unregister_frontend(state-fe);
+		dvb_frontend_detach(state-fe);
+	}
+	dvb_usb_device_exit (intf);
+}
+
 static int ttusb2_probe(struct usb_interface *intf,
 		const struct usb_device_id *id)
 {
@@ -422,7 +465,7 @@
 static struct

[PATCH] add support for the dvb-t part of CT-3650

[Jose Alberto Reguero]

This patch add suport for the dvb-t part of CT-3650.

Jose Alberto

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -urN linux/drivers/media/common/tuners/tda827x.c linux.new/drivers/media/common/tuners/tda827x.c
--- linux/drivers/media/common/tuners/tda827x.c	2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.c	2011-06-06 14:45:02.912154000 +0200
@@ -135,14 +135,29 @@
 
 static int tuner_transfer(struct dvb_frontend *fe,
 			  struct i2c_msg *msg,
-			  const int size)
+			  int size)
 {
 	int rc;
 	struct tda827x_priv *priv = fe-tuner_priv;
+	struct i2c_msg msgr[2];
 
 	if (fe-ops.i2c_gate_ctrl)
 		fe-ops.i2c_gate_ctrl(fe, 1);
-	rc = i2c_transfer(priv-i2c_adap, msg, size);
+	if (priv-cfg-i2cr  (msg-flags == I2C_M_RD)) {
+		msgr[0].addr = msg-addr;
+		msgr[0].flags = 0;
+		msgr[0].len = msg-len - 1;
+		msgr[0].buf = msg-buf;
+		msgr[1].addr = msg-addr;
+		msgr[1].flags = I2C_M_RD;
+		msgr[1].len = 1;
+		msgr[1].buf = msg-buf;
+		size = 2;
+		rc = i2c_transfer(priv-i2c_adap, msgr, size);
+		msg-buf[msg-len - 1] = msgr[1].buf[0];
+	} else {
+		rc = i2c_transfer(priv-i2c_adap, msg, size);
+	}
 	if (fe-ops.i2c_gate_ctrl)
 		fe-ops.i2c_gate_ctrl(fe, 0);
 
diff -urN linux/drivers/media/common/tuners/tda827x.h linux.new/drivers/media/common/tuners/tda827x.h
--- linux/drivers/media/common/tuners/tda827x.h	2010-07-03 23:22:08.0 +0200
+++ linux.new/drivers/media/common/tuners/tda827x.h	2011-05-21 22:48:31.484340005 +0200
@@ -38,6 +38,8 @@
 	int 	 switch_addr;
 
 	void (*agcf)(struct dvb_frontend *fe);
+
+	u8 i2cr;
 };
 
 
diff -urN linux/drivers/media/dvb/dvb-usb/ttusb2.c linux.new/drivers/media/dvb/dvb-usb/ttusb2.c
--- linux/drivers/media/dvb/dvb-usb/ttusb2.c	2011-01-10 16:24:45.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/ttusb2.c	2011-06-06 14:35:37.906154000 +0200
@@ -30,6 +30,7 @@
 #include tda826x.h
 #include tda10086.h
 #include tda1002x.h
+#include tda10048.h
 #include tda827x.h
 #include lnbp21.h
 
@@ -44,6 +45,8 @@
 struct ttusb2_state {
 	u8 id;
 	u16 last_rc_key;
+	struct dvb_frontend *fe;
+	u8 initialized;
 };
 
 static int ttusb2_msg(struct dvb_usb_device *d, u8 cmd,
@@ -155,7 +158,6 @@
 	return 0;
 }
 
-
 /* Callbacks for DVB USB */
 static int ttusb2_identify_state (struct usb_device *udev, struct
 		dvb_usb_device_properties *props, struct dvb_usb_device_description **desc,
@@ -167,11 +169,58 @@
 
 static int ttusb2_power_ctrl(struct dvb_usb_device *d, int onoff)
 {
+	struct ttusb2_state *state;
 	u8 b = onoff;
-	ttusb2_msg(d, CMD_POWER, b, 0, NULL, 0);
-	return ttusb2_msg(d, CMD_POWER, b, 1, NULL, 0);
+	if (onoff) {
+		state = (struct ttusb2_state *)d-priv;
+		if (!state-initialized) {
+			ttusb2_msg(d, CMD_POWER, b, 0, NULL, 0);
+			ttusb2_msg(d, CMD_POWER, b, 1, NULL, 0);
+			state-initialized = 1;
+		}
+	}
+	return 0;
+}
+
+//get access to tuner
+static int lock_tuner(struct tda10048_state *state)
+{
+	u8 buf[2] = { 0x0f, 0xc0 };
+	struct i2c_msg msg = {.addr=0x0c, .flags=0, .buf=buf, .len=2};
+
+	if(i2c_transfer(state-i2c, msg, 1) != 1)
+	{
+		printk(tda10048: lock tuner fails\n);
+		return -EREMOTEIO;
+	}
+	return 0;
 }
 
+//release access from tuner
+static int unlock_tuner(struct tda10048_state *state)
+{
+	u8 buf[2] = { 0x0f, 0x40 };
+	struct i2c_msg msg_post={.addr=0x0c, .flags=0, .buf=buf, .len=2};
+
+	if(i2c_transfer(state-i2c, msg_post, 1) != 1)
+	{
+		printk(tda10048: unlock tuner fails\n);
+		return -EREMOTEIO;
+	}
+	return 0;
+}
+
+static int tda10023_i2c_gate_ctrl(struct dvb_frontend* fe, int enable)
+{
+	struct tda10048_state *state = fe-demodulator_priv;
+
+	if (enable) {
+		lock_tuner(state);
+	} else {
+		unlock_tuner(state);
+	}
+	return 0;
+}
 
 static struct tda10086_config tda10086_config = {
 	.demod_address = 0x0e,
@@ -190,6 +239,23 @@
 	.deltaf = 0xa511,
 };
 
+static struct tda10048_config tda10048_config = {
+	.demod_address= 0x10  1,
+	.output_mode  = TDA10048_PARALLEL_OUTPUT,
+	.inversion= TDA10048_INVERSION_ON,
+	.dtv6_if_freq_khz = TDA10048_IF_4000,
+	.dtv7_if_freq_khz = TDA10048_IF_4500,
+	.dtv8_if_freq_khz = TDA10048_IF_5000,
+	.clk_freq_khz = TDA10048_CLK_16000,
+	.no_firmware  = 1,
+	.i2c_gate = tda10023_i2c_gate_ctrl,
+};
+
+static struct tda827x_config tda827x_config = {
+	.i2cr = 1,
+	.config = 0,
+};
+
 static int ttusb2_frontend_tda10086_attach(struct dvb_usb_adapter *adap)
 {
 	if (usb_set_interface(adap-dev-udev,0,3)  0)
@@ -205,18 +271,30 @@
 
 static int ttusb2_frontend_tda10023_attach(struct dvb_usb_adapter *adap)
 {
+	struct ttusb2_state *state;
 	if (usb_set_interface(adap-dev-udev, 0, 3)  0)
 		err(set interface to alts=3 failed);
 	if ((adap-fe = dvb_attach(tda10023_attach, tda10023_config, adap-dev-i2c_adap, 0x48)) == NULL) {
 		deb_info(TDA10023 attach failed\n);
 		return -ENODEV;
 	}
+	adap-fe-id = 1;
+	state = (struct ttusb2_state *)adap-dev-priv;
+	if ((state-fe = dvb_attach(tda10048_attach, tda10048_config, adap-dev-i2c_adap

Re: AF9015 suspend problem

[Jose Alberto Reguero]

El Viernes, 14 de Mayo de 2010, Antti Palosaari escribió:
 On 05/14/2010 03:50 AM, Jose Alberto Reguero wrote:
  El Jueves, 13 de Mayo de 2010, Antti Palosaari escribió:
  Terve!
  
  On 05/02/2010 06:39 PM, Jose Alberto Reguero wrote:
  When I have a af9015 DVB-T stick plugged I can not recover from pc
  suspend. I must unplug the stick to suspend work. Even if I remove the
  modules I cannot recover from suspend.
  Any idea why this happen?
  
  Did you asked this 7 months ago from me?
  I did some tests (http://linuxtv.org/hg/~anttip/suspend/) and looks like
  it is firmware loader problem (fw loader misses something or like
  that...). No one answered when I asked that from ML, but few weeks ago I
  saw some discussion. Look ML archives.
  
  regards
  Antti
  
  I think that is another problem. If I blacklist the af9015 driver and
  have the stick plugged in, the suspend don't finish, and the system
  can't resume. If I unplugg the stick the suspend feature work well.
 
 Look these and check if it is same problem:
 
 DVB USB resume from suspend crash
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg09974.html
 
 Re: tuner XC5000 race condition??
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg18012.html
 
 Bug 15294 -  Oops due to an apparent race between udev and a timeout in
 firmware_class.c
 https://bugzilla.kernel.org/show_bug.cgi?id=15294
 
 I haven't examined those yet, but I think they could be coming from same
 issue.
 
 br,
 Antti

I found my problem. Was a quirk that I have in the kernel parameters:
usbhid.quirks=0x07ca:0xa815:0x04
Without the quirk, the system go to sleep an can wake, although only the first 
time. The second time the system don't sleep. Perhaps I have some wrong in my 
scripts.

Jose Alberto

--
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: AF9015 suspend problem

[Jose Alberto Reguero]

El Jueves, 13 de Mayo de 2010, Antti Palosaari escribió:
 Terve!
 
 On 05/02/2010 06:39 PM, Jose Alberto Reguero wrote:
  When I have a af9015 DVB-T stick plugged I can not recover from pc
  suspend. I must unplug the stick to suspend work. Even if I remove the
  modules I cannot recover from suspend.
  Any idea why this happen?
 
 Did you asked this 7 months ago from me?
 I did some tests (http://linuxtv.org/hg/~anttip/suspend/) and looks like
 it is firmware loader problem (fw loader misses something or like
 that...). No one answered when I asked that from ML, but few weeks ago I
 saw some discussion. Look ML archives.
 
 regards
 Antti

I think that is another problem. If I blacklist the af9015 driver and have the 
stick plugged in, the suspend don't finish, and the system can't resume. If I 
unplugg the stick the suspend feature work well.

Jose Alberto
--
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

AF9015 suspend problem

[Jose Alberto Reguero]

When I have a af9015 DVB-T stick plugged I can not recover from pc suspend. I 
must unplug the stick to suspend work. Even if I remove the modules I cannot 
recover from suspend.
Any idea why this happen?

Jose Alberto
--
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: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Miércoles, 13 de Enero de 2010, Jose Alberto Reguero escribió:
 El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
  El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
   On Mon, 11 Jan 2010 15:49:55 +0100
  
   Jose Alberto Reguero jaregu...@telefonica.net wrote:
I take another image with 640x480 and the bad bottom lines are 8. The
right side look right this time. The good sizes are:
320x240-320x232
640x480-640x472
  
   Hi Jose Alberto and Hans,
  
   Hans, I modified a bit your patch to handle the 2 resolutions (also,
   the problem with pas202b does not exist anymore). May you sign or ack
   it?
  
   Jose Alberto, the attached patch is to be applied to the last version
   of the gspca in my test repository at LinuxTv.org
 http://linuxtv.org/hg/~jfrancois/gspca
   May you try it?
  
   Regards.
 
   The patch works well.
  There is another problem. When autogain is on(default), the image is bad.
   It is possible to put autogain off by default?
 
  Thanks.
  Jose Alberto
 
 Autogain works well again. I can't reproduce the problem. Perhaps the debug
 messages. (Now I have debug off).
 
 Thanks.
 Jose Alberto

I found the problem. Autogain don't work well if brightness is de default 
value(128). if brightness is less(64) autogain work well. There is a problem 
when setting the brightness. It is safe to remove the brightness control?
Patch attached.

Jose Alberto
diff -r d490d84a64ac linux/drivers/media/video/gspca/zc3xx.c
--- a/linux/drivers/media/video/gspca/zc3xx.c	Wed Jan 13 12:11:34 2010 -0200
+++ b/linux/drivers/media/video/gspca/zc3xx.c	Thu Jan 14 17:03:10 2010 +0100
@@ -6028,6 +6041,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		return;
 	}
 /*fixme: is it really write to 011d and 018d for all other sensors? */
@@ -6796,6 +6837,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		gspca_dev-ctrl_dis = (1  BRIGHTNESS_IDX);
 		break;
 	case SENSOR_HV7131B:

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
 El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
  On Mon, 11 Jan 2010 15:49:55 +0100
 
  Jose Alberto Reguero jaregu...@telefonica.net wrote:
   I take another image with 640x480 and the bad bottom lines are 8. The
   right side look right this time. The good sizes are:
   320x240-320x232
   640x480-640x472
 
  Hi Jose Alberto and Hans,
 
  Hans, I modified a bit your patch to handle the 2 resolutions (also, the
  problem with pas202b does not exist anymore). May you sign or ack it?
 
  Jose Alberto, the attached patch is to be applied to the last version
  of the gspca in my test repository at LinuxTv.org
  http://linuxtv.org/hg/~jfrancois/gspca
  May you try it?
 
  Regards.
 
  The patch works well.
 There is another problem. When autogain is on(default), the image is bad.
  It is possible to put autogain off by default?
 
 Thanks.
 Jose Alberto

Autogain works well again. I can't reproduce the problem. Perhaps the debug 
messages. (Now I have debug off).

Thanks.
Jose Alberto
--
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: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
 On Mon, 11 Jan 2010 15:49:55 +0100
 
 Jose Alberto Reguero jaregu...@telefonica.net wrote:
  I take another image with 640x480 and the bad bottom lines are 8. The
  right side look right this time. The good sizes are:
  320x240-320x232
  640x480-640x472
 
 Hi Jose Alberto and Hans,
 
 Hans, I modified a bit your patch to handle the 2 resolutions (also, the
 problem with pas202b does not exist anymore). May you sign or ack it?
 
 Jose Alberto, the attached patch is to be applied to the last version
 of the gspca in my test repository at LinuxTv.org
   http://linuxtv.org/hg/~jfrancois/gspca
 May you try it?
 
 Regards.
 

 The patch works well.
There is another problem. When autogain is on(default), the image is bad. It 
is possible to put autogain off by default?

Thanks.
Jose Alberto
--
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: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Lunes, 11 de Enero de 2010, Jean-Francois Moine escribió:
 On Mon, 11 Jan 2010 09:37:29 +0100
 
 Hans de Goede hdego...@redhat.com wrote:
  This is the infamous zc3xx bottom of the image is missing in 320x240
  problem, with several sensors the register settings we took from the
  windows driver will only give you 320x232 (iirc), we tried changing
  them to get 320x240, but then the camera would not stream. Most
  likely some timing issue between bridge and sensor.
 
  I once had a patch fixing this by actually reporting the broken modes
  as 320x232, but that never got applied as it breaks app which are
  hardcoded to ask for 320x240. libv4l has had the ability to extend
  the 320x232 image to 320x240 for a while now (by adding a few black
  lines at the top + bottom), fixing the hardcoded apps problem.
 
  So I think such a patch can and should be applied now. This will get
  rid of the jpeg decompression errors reported by libv4l and in case
  if yuv mode the ugly green bar with some random noise in it at the
  bottom.
 
  I'm afraid my patch is most likely lost, but I can create a new one
  if you want, I have access to quite a few zc3xx camera's, and more
  over what resolution they are actually streaming at can be deducted
  from the register settings in the driver.
 
 Hi Hans,
 
 As you may see in Jose Alberto's message, the problem occurs with
 640x480 and, yes, the image bottom is lacking, but also the right side.
 
 I did not lose your patch, but I did not apply it because most of the
 time, the webcams work in the best resolution (VGA) and the associated
 problem has not found yet a good resolution...
 
 Regards.
 

I take another image with 640x480 and the bad bottom lines are 8. The right 
side look right this time. The good sizes are:
320x240-320x232  
640x480-640x472

Jose Alberto
attachment: image2.dat

Re: Problem with gspca and zc3xx

[Jose Alberto Reguero]

El Domingo, 10 de Enero de 2010, Jean-Francois Moine escribió:
 On Sat, 9 Jan 2010 00:15:31 +0100
 
 Jose Alberto Reguero jaregu...@telefonica.net wrote:
  When capturing with mplayer I have this erros and the bottom of the
  image is black.
 
  [mjpeg @ 0xd2f300]error y=29 x=0
  [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
 
   [snip]
 
  gspca: main v2.8.0 registered
  gspca: probing 046d:08dd
  zc3xx: Sensor MC501CB
  gspca: video0 created
  gspca: probing 046d:08dd
  gspca: intf != 0
  gspca: probing 046d:08dd
  gspca: intf != 0
  usbcore: registered new interface driver zc3xx
  zc3xx: registered
 
 Hello Jose Alberto,
 
 May you send me a raw image done by my program svv? (look in my web page
 below - run it by 'svv -rg' and send me the generated image.dat)
 
 Regards
 

Jose Alberto
attachment: image.dat

Problem with gspca and zc3xx

[Jose Alberto Reguero]

When capturing with mplayer I have this erros and the bottom of the image is 
black.

[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
[mjpeg @ 0xd2f300]error y=29 x=0   
[mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0)
[mjpeg @ 0xd2f300]error dc 
.

dmesg:

gspca: main v2.8.0 registered
gspca: probing 046d:08dd
zc3xx: Sensor MC501CB
gspca: video0 created
gspca: probing 046d:08dd
gspca: intf != 0
gspca: probing 046d:08dd
gspca: intf != 0
usbcore: registered new interface driver zc3xx
zc3xx: registered

Jose Alberto
--
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: dvb_usb_af9015: Oops on hotplugging with 2.6.31-rc5-git3

[Jose Alberto Reguero]

El Miércoles, 5 de Agosto de 2009, Stefan Lippers-Hollmann escribió:
 Hi

 Connecting my TerraTec Cinergy T USB XE rev. 2 (0x0ccd, 0x0069) to kernel
 2.6.31-rc5-git3, I get following kernel oops (complete dmesg and kernel
 config (amd64) attached) while the firmware[1] is uploaded to the device.

 This is a regression relative to 2.6.30.x, where this device is working
 fine. It also seems to be restricted to dvb_usb_af9015, as firmwares for
 several wlan cards are uploading fine. Would it help to bisect based on
 the changes to drivers/media/dvb/dvb-usb/af9015.c or is a wider scope
 required?

 Regards
   Stefan Lippers-Hollmann

 [1]   http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmwar
e_files/4.95.0/dvb-usb-af9015.fw

 usb 1-2: new high speed USB device using ehci_hcd and address 4
 usb 1-2: New USB device found, idVendor=0ccd, idProduct=0069
 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 usb 1-2: Product: Cinergy T USB XE Ver.2
 usb 1-2: Manufacturer: TerraTec
 usb 1-2: SerialNumber: 10012007
 usb 1-2: configuration #1 chosen from 1 choice
 dvb-usb: found a 'TerraTec Cinergy T USB XE' in cold state, will try to
 load a firmware usb 1-2: firmware: requesting dvb-usb-af9015.fw
 dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw'
 BUG: unable to handle kernel paging request at c9000db5ee17
 IP: [811d173b] memcpy_c+0xb/0x20
 PGD 22fc07067 PUD 22fc14067 PMD 1a091b067 PTE 80020d5fd161
 Oops: 0003 [#1] PREEMPT SMP
 last sysfs file:
 /sys/devices/pci:00/:00:1a.7/usb1/1-2/firmware/1-2/loading CPU 0
 Modules linked in: dvb_usb_af9015(+) dvb_usb dvb_core radeon drm bnep sco
 rfcomm l2cap bluetooth ppdev parport_pc lp parport acpi_cpufreq
 cpufreq_conservative cpufreq_stats cpufreq_ondemand freq_table
 cpufreq_performance cpufreq_powersave kvm_intel kvm ipv6 af_packet bridge
 stp snd_hda_codec_atihdmi rt2800usb snd_hda_codec_realtek zd1211rw
 rt2x00usb snd_hda_intel snd_hda_codec rt2x00lib input_polldev crc_ccitt
 snd_hwdep arc4 ath9k ecb snd_pcm b43 ath snd_seq snd_timer rng_core
 snd_seq_device mac80211 cfg80211 evdev snd rtc_cmos rtc_core soundcore
 rtc_lib pcspkr rfkill snd_page_alloc i2c_i801 processor led_class i2c_core
 button ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_snapshot
 dm_mod sg sr_mod sd_mod cdrom usbhid hid uhci_hcd ahci ssb firewire_ohci
 pcmcia firewire_core libata pcmcia_core crc_itu_t scsi_mod r8169 ehci_hcd
 mii usbcore nls_base intel_agp thermal fan Pid: 18663, comm: modprobe Not
 tainted 2.6.31-rc5-sidux-amd64 #1 EP45-DS3 RIP: 0010:[811d173b] 
 [811d173b] memcpy_c+0xb/0x20 RSP: 0018:880221185b50  EFLAGS:
 00010202
 RAX: c9000db5ee17 RBX: 880221185c18 RCX: 0002
 RDX: 0002 RSI: 880221185b6a RDI: c9000db5ee17
 RBP:  R08: 8800280442a0 R09: 0001
 R10: 8800378010c0 R11: 810284b0 R12: 0008
 R13: 880221185b68 R14: 880221179800 R15: 880221185bb4
 FS:  7f7f1d4286f0() GS:880028034000()
 knlGS: CS:  0010 DS:  ES:  CR0: 8005003b
 CR2: c9000db5ee17 CR3: 0001e21ec000 CR4: 26e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process modprobe (pid: 18663, threadinfo 880221184000, task
 88021f0393e0) Stack:
  a060b2ad a060f220 00ff880221179800 0f002f4b88d0002b
 0 004500088673e9ea 0d13c9141c915e02 06803e010101fb08 0c800cc012007d40
 0 bb800cc01200fa80 01a06480 ff02010202020102 8802260823c0
 Call Trace:
  [a060b2ad] ? af9015_rw_udev+0x24d/0x2d0 [dvb_usb_af9015]
  [a060b91b] ? af9015_download_firmware+0x12b/0x190
 [dvb_usb_af9015] [a0604334] ? dvb_usb_download_firmware+0x94/0xe0
 [dvb_usb] [a0604669] ? dvb_usb_device_init+0x179/0x700 [dvb_usb]
  [a060c3ff] ? af9015_usb_probe+0x12f/0xbf4 [dvb_usb_af9015]
  [a002e0a7] ? usb_probe_interface+0xb7/0x190 [usbcore]
  [8126b5c8] ? driver_probe_device+0x98/0x1b0
  [8126b773] ? __driver_attach+0x93/0xa0
  [8126b6e0] ? __driver_attach+0x0/0xa0
  [8126ad58] ? bus_for_each_dev+0x58/0x80
  [8126a648] ? bus_add_driver+0x268/0x2f0
  [8126ba69] ? driver_register+0x79/0x170
  [a002de09] ? usb_register_driver+0xa9/0x120 [usbcore]
  [a0063000] ? af9015_usb_module_init+0x0/0x37 [dvb_usb_af9015]
  [a006301b] ? af9015_usb_module_init+0x1b/0x37 [dvb_usb_af9015]
  [8100a04b] ? do_one_initcall+0x3b/0x180
  [811cd8b1] ? __up_read+0x21/0xc0
  [81072585] ? __blocking_notifier_call_chain+0x65/0x90
  [81085618] ? sys_init_module+0xe8/0x240
  [81011fc2] ? system_call_fastpath+0x16/0x1b
 Code: 81 ea d8 1f 00 00 48 3b 42 20 73 07 48 8b 50 f9 31 c0 c3 31 d2 48 c7
 c0 f2 ff ff ff c3 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 f3 48 a5 

Re: Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04

[Jose Alberto Reguero]

El Martes, 4 de Agosto de 2009, Cyril Hansen escribió:
 Hi all,

 I am trying to solve a noisy video issue with my new avermedia stick
 (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD
 is annoying, with the occasional video and audio quirk, and HD is
 almost unwatchable.

 The same usb stick with another computer and Vista gives a perfect
 image with absolutely no error from the same antenna.

 Yesterday I tried to update the drivers from the mercurial tree with no
 change.

 I noticed that the firmware available from the Net and Mythbuntu for
 the chip is quite old (2007 ?), so maybe this is the source of my
 problem. I am willing to try to use usbsnoop and the firmware cutter
 from
 
 http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_fi
les/ if nobody has done it with a recent windows driver.


 I haven't found any parameter for the module dvb_usb_af9015 : Are they
 any than can be worth to try to fix my issue ?


 Thank you in advance,

 Cyril Hansen
 --

I have problems with some hardware, and the buffersize when the buffersize is 
not multiple of TS_PACKET_SIZE.

You can try the attached patch.

Jose Alberto

diff -r b15490457d60 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c	Sat Aug 01 01:38:01 2009 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c	Tue Aug 04 13:02:37 2009 +0200
@@ -877,7 +877,7 @@
 			af9015_config.dual_mode = 0;
 		} else {
 			af9015_properties[i].adapter[0].stream.u.bulk.buffersize
-= TS_USB20_MAX_PACKET_SIZE;
+= TS_USB20_FRAME_SIZE;
 		}
 	}
 
@@ -1312,7 +1312,7 @@
 	.u = {
 		.bulk = {
 			.buffersize =
-		TS_USB20_MAX_PACKET_SIZE,
+		TS_USB20_FRAME_SIZE,
 		}
 	}
 },
@@ -1417,7 +1417,7 @@
 	.u = {
 		.bulk = {
 			.buffersize =
-		TS_USB20_MAX_PACKET_SIZE,
+		TS_USB20_FRAME_SIZE,
 		}
 	}
 },
@@ -1523,7 +1523,7 @@
 	.u = {
 		.bulk = {
 			.buffersize =
-		TS_USB20_MAX_PACKET_SIZE,
+		TS_USB20_FRAME_SIZE,
 		}
 	}
 },

Re: Noisy video with Avermedia AVerTV Digi Volar X HD (AF9015) and mythbuntu 9.04

[Jose Alberto Reguero]

Antti, can this patch be integrated in the af015 module?

Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto

El Martes, 4 de Agosto de 2009, Cyril Hansen escribió:
 Thank you very much, your patch has fixed the issue i had using the
 firmware provided by mythbuntu.

 Maybe we should add this info to the LinuxTV wiki.

 Regards,

 Cyril Hansen

 2009/8/4 Jose Alberto Reguero jaregu...@telefonica.net:
  El Martes, 4 de Agosto de 2009, Cyril Hansen escribió:
  Hi all,
 
  I am trying to solve a noisy video issue with my new avermedia stick
  (AF9015). I am receiving french DVB signal, both SD and HD. Viewing SD
  is annoying, with the occasional video and audio quirk, and HD is
  almost unwatchable.
 
  The same usb stick with another computer and Vista gives a perfect
  image with absolutely no error from the same antenna.
 
  Yesterday I tried to update the drivers from the mercurial tree with no
  change.
 
  I noticed that the firmware available from the Net and Mythbuntu for
  the chip is quite old (2007 ?), so maybe this is the source of my
  problem. I am willing to try to use usbsnoop and the firmware cutter
  from
 
  http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware
 _fi les/ if nobody has done it with a recent windows driver.
 
 
  I haven't found any parameter for the module dvb_usb_af9015 : Are they
  any than can be worth to try to fix my issue ?
 
 
  Thank you in advance,
 
  Cyril Hansen
  --
 
  I have problems with some hardware, and the buffersize when the
  buffersize is not multiple of TS_PACKET_SIZE.
 
  You can try the attached patch.
 
  Jose Alberto

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in mxl5005s driver

[Jose Alberto Reguero]

In line 3992:

if (fe-ops.info.type == FE_ATSC) {
switch (params-u.vsb.modulation) {
case VSB_8:
req_mode = MXL_ATSC; break;
default:
case QAM_64:
case QAM_256:
case QAM_AUTO:
req_mode = MXL_QAM; break;
}
} else
req_mode = MXL_DVBT;

req_mode is filled with MXL_ATSC, MXL_QAM, or MXL_DVBT

and in line 4007 req_mode is used like params-u.vsb.modulation

switch (req_mode) {
case VSB_8:
case QAM_64:
case QAM_256:
case QAM_AUTO:
req_bw  = MXL5005S_BANDWIDTH_6MHZ;
break;
default:
/* Assume DVB-T */
switch (params-u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
req_bw  = MXL5005S_BANDWIDTH_6MHZ;
break;
case BANDWIDTH_7_MHZ:
req_bw  = MXL5005S_BANDWIDTH_7MHZ;
break;
case BANDWIDTH_AUTO:
case BANDWIDTH_8_MHZ:


Jose Alberto Reguero


--
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

New remote RM-KS for Avermedia Volar-X (af9015)

[Jose Alberto Reguero]

The new Avermedia Volar-X is shipped with a new remote(RM-KS). The attached 
patch add a new option to the remote parameter of dvb_usb_af9015 for this 
remote.

Signed-off-by: Felipe Morales Moreno felipe.morales.mor...@gmail
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net

Jose Alberto
diff -r 2ed72b192848 linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c	Thu Jan 22 22:20:24 2009 -0600
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c	Fri Jan 23 16:51:52 2009 +0100
@@ -751,6 +751,16 @@
 af9015_config.ir_table_size =
   ARRAY_SIZE(af9015_ir_table_digittrade);
 break;
+			case AF9015_REMOTE_AVERMEDIA_KS:
+af9015_properties[i].rc_key_map =
+  af9015_rc_keys_avermedia;
+af9015_properties[i].rc_key_map_size =
+  ARRAY_SIZE(af9015_rc_keys_avermedia);
+af9015_config.ir_table =
+  af9015_ir_table_avermedia_ks;
+af9015_config.ir_table_size =
+  ARRAY_SIZE(af9015_ir_table_avermedia_ks);
+break;
 			}
 		} else {
 			switch (le16_to_cpu(udev-descriptor.idVendor)) {
diff -r 2ed72b192848 linux/drivers/media/dvb/dvb-usb/af9015.h
--- a/linux/drivers/media/dvb/dvb-usb/af9015.h	Thu Jan 22 22:20:24 2009 -0600
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.h	Fri Jan 23 16:51:52 2009 +0100
@@ -124,6 +124,7 @@
 	AF9015_REMOTE_MSI_DIGIVOX_MINI_II_V3,
 	AF9015_REMOTE_MYGICTV_U718,
 	AF9015_REMOTE_DIGITTRADE_DVB_T,
+	AF9015_REMOTE_AVERMEDIA_KS,
 };
 
 /* Leadtek WinFast DTV Dongle Gold */
@@ -597,6 +598,36 @@
 	0x03, 0xfc, 0x03, 0xfc, 0x0e, 0x05, 0x00,
 };
 
+static u8 af9015_ir_table_avermedia_ks[] = {
+	0x05, 0xfa, 0x01, 0xfe, 0x12, 0x05, 0x00, 
+	0x05, 0xfa, 0x02, 0xfd, 0x0e, 0x05, 0x00,
+	0x05, 0xfa, 0x03, 0xfc, 0x0d, 0x05, 0x00, 
+	0x05, 0xfa, 0x04, 0xfb, 0x2e, 0x05, 0x00, 
+	0x05, 0xfa, 0x05, 0xfa, 0x2d, 0x05, 0x00, 
+	0x05, 0xfa, 0x06, 0xf9, 0x10, 0x05, 0x00, 
+	0x05, 0xfa, 0x07, 0xf8, 0x0f, 0x05, 0x00, 
+	0x05, 0xfa, 0x08, 0xf7, 0x3d, 0x05, 0x00, 
+	0x05, 0xfa, 0x09, 0xf6, 0x1e, 0x05, 0x00, 
+	0x05, 0xfa, 0x0a, 0xf5, 0x1f, 0x05, 0x00, 
+	0x05, 0xfa, 0x0b, 0xf4, 0x20, 0x05, 0x00, 
+	0x05, 0xfa, 0x0c, 0xf3, 0x21, 0x05, 0x00, 
+	0x05, 0xfa, 0x0d, 0xf2, 0x22, 0x05, 0x00, 
+	0x05, 0xfa, 0x0e, 0xf1, 0x23, 0x05, 0x00, 
+	0x05, 0xfa, 0x0f, 0xf0, 0x24, 0x05, 0x00, 
+	0x05, 0xfa, 0x10, 0xef, 0x25, 0x05, 0x00, 
+	0x05, 0xfa, 0x11, 0xee, 0x26, 0x05, 0x00, 
+	0x05, 0xfa, 0x12, 0xed, 0x27, 0x05, 0x00, 
+	0x05, 0xfa, 0x13, 0xec, 0x04, 0x05, 0x00, 
+	0x05, 0xfa, 0x15, 0xea, 0x0a, 0x05, 0x00, 
+	0x05, 0xfa, 0x16, 0xe9, 0x11, 0x05, 0x00, 
+	0x05, 0xfa, 0x17, 0xe8, 0x15, 0x05, 0x00, 
+	0x05, 0xfa, 0x18, 0xe7, 0x16, 0x05, 0x00, 
+	0x05, 0xfa, 0x1c, 0xe3, 0x05, 0x05, 0x00, 
+	0x05, 0xfa, 0x1d, 0xe2, 0x09, 0x05, 0x00, 
+	0x05, 0xfa, 0x4d, 0xb2, 0x3f, 0x05, 0x00, 
+	0x05, 0xfa, 0x56, 0xa9, 0x3e, 0x05, 0x00  
+};
+
 /* Digittrade DVB-T USB Stick */
 static struct dvb_usb_rc_key af9015_rc_keys_digittrade[] = {
 	{ 0x01, 0x0f, KEY_LAST },	/* RETURN */