Re: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 06/27/2012 07:21 AM, Thomas Mair wrote:
 On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It 
 is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
 again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is 
 probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas


 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?

 regards,
 poma

 Hi all,
 
 I will try to solve the issue as soon as I have some spare time. In the 
 meantime I 
 asked Realtek if they knew of any problems with the hardware, and I got a GPIO
 list which might help me to solve the problem.
 
 Regrads
 Thomas
 

This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
https://gist.github.com/2171926#120
David, can you help with this tuner issue?
http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

Cheers,
poma

--
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: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread David Basden
On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote:
 On 06/27/2012 07:21 AM, Thomas Mair wrote:
  On 26.06.2012 19:17, poma wrote:
  On 05/28/2012 04:48 PM, Thomas Mair wrote:
  On 28.05.2012 08:58, Thomas Mair wrote:
  On 26.05.2012 04:47, poma wrote:
  On 05/20/2012 11:12 PM, Thomas Mair wrote:
  On 20.05.2012 22:08, Antti Palosaari wrote:
  On 20.05.2012 20:04, poma wrote:
  After hard/cold boot:
 
  DVB: register adapter0/net0 @ minor: 2 (0x02)
  rtl2832u_frontend_attach:
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  rtl28xxu_ctrl_msg: failed=-32
  No compatible tuner found
 
  These errors are coming from tuner probe. As it still goes to probing 
  and did not jump out earlier when gate is opened it means that demod 
  is answering commands but tuner are not.
 
  My guess is that tuner is still on the reset or not powered at all. 
  It is almost 100% sure error is wrong tuner GPIO.
 
  There is an issue with GPIO, as FC0012 tuner callback will set 
  the value of one of the GPIO outputs. However fixing that, will
  not resolve the issue. So I need to debug the problem further.
 
  True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
  even more.
  Precisely, what breaks a tuner on next soft [re]boot are apps/utils
  which engage tzap/scan[dvb].
 
 
  To reproduce the bug it is not necessary to reboot the machine. Simply 
  unload and load of the dvb_usb_rtl28xxu module will lead to the same 
  situation.
 
  I suspect, that when power is turned off, the tuner power is not 
  switched on correctly. The mistake is not related to the OUTPUT_VAL
  registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.
 
  What makes me wonder is if no tuning operation is performed before
  reboot, the driver does work correctly after that, as poma already
  noticed.
 
  I have some spare time today and will investigate the problem further.
 
 
  I tried a few things regarding the problem today and could find out a 
  few more details, but could not resolve the issue.
 
  The GPIO pin configuration for the devices with the fc0012 (and probably
  also with the fc0013) tuner is the following:
 
  GPIO0: demod power
  GPIO3: tuner power? (the realtek driver puts this to 1 and never touches 
  it again)
  GPIO4: tuner power? (maybe antenna power?)
  GPIO5: tuner reset
  GPIO6: UHF/VHF band selection
 
  All of these GPIOs are configured as output. When the device is plugged in
  the tuner is powered up correctly, but I am not able to power it up when
  a reboot is performed. What I tried was the following:
 
  - on rtl28xxu_power_ctrl off:
- GPIO4 = 1 (off)
- GPIO5 = 0 
- GPIO6 = 0 (default state)
 
  - on rtl28xxu_power_ctrl on:
- GPIO3 = 1
- GPIO4 = 0 (on)
- GPIO5 = 0 
- GPIO6 = 0 (default state)
 
  - on rtl2832_frontend_attach:
- GPIO5 = 1 
- GPIO5 = 0 
 
  This sequence should ensure that the tuner is powered on when the frontend
  is attached, and a tuner reset is being performed before the tuner is 
  probed.
  However this sequence fails the same way as it did before. I tried to add
  timeouts to be sure that the tuner is not probed while it is reset but 
  that
  did not help either.
 
  Right now I really don't know where I should look for the solution of
  the problem. It seems that the tuner reset does not have any effect on 
  the 
  tuner whatsoever.
 
  Is there anybody who could look at the code, or maybe knows what could be
  the cause of the problem? I suspect I am just too blind to see my own 
  mistakes.
 
  Regards
  Thomas
 
 
  Cheers Thomas, Hans-Frieder, Antti, Mauro!
  Hans-Frieder, are you having the same issue with fc0011af9035?
  Antti, no tricks up your sleeve?
  Senhor Mauro, is rtl2832 demod going to be merged?
 
  regards,
  poma
 
  Hi all,
  
  I will try to solve the issue as soon as I have some spare time. In the 
  meantime I 
  asked Realtek if they knew of any problems with the hardware, and I got a 
  GPIO
  list which might help me to solve the problem.
  
  Regrads
  Thomas
  
 
 This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
 https://gist.github.com/2171926#120
 David, can you help with this tuner issue?
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898
 
 Cheers,
 poma

It sounds like you're definately on the right track with the GPIO pins for
tuner power and reset lines, especially if it's not making it through the
tuner probe.

The gist you linked to above has since been merged into the rtl-sdr tree,
and the version in there is likely to be a much better reference than the
old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr
It reliably brings the rtl and the tuner 

Re: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread David Basden
  Right now I really don't know where I should look for the solution of
  the problem. It seems that the tuner reset does not have any effect on 
  the 
  tuner whatsoever.

Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it
doesn't, GPIO5 on the RTL isn't setup correctly somehow.

At the same time, I was rereading code from:

http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

and at no point is GPIO5 actually set to an output or enabled that I can find.
rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running
into this problem while trying to use some DVB driver code as an example of
how to setup the RTL to talk to the FC0012)

Try giving the patch below a go. Sorry, I don't have a build environment to
hand, so there might be a typo I haven't picked up, but the upshot is that 
I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the
tuner and then trying to probe for the FC0012.

Please let me know if this helps :)

David

--- a/rtl28xxu.c2012-07-30 22:31:53.789638678 +1000
+++ b/rtl28xxu.c2012-07-30 22:48:35.774607232 +1000
@@ -550,15 +550,6 @@
 
priv-tuner = TUNER_NONE;
 
-   /* check FC0012 ID register; reg=00 val=a1 */
-   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
-   if (ret == 0  buf[0] == 0xa1) {
-   priv-tuner = TUNER_RTL2832_FC0012;
-   rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
-   info(%s: FC0012 tuner found, __func__);
-   goto found;
-   }
-
/* check FC0013 ID register; reg=00 val=a3 */
ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013);
if (ret == 0  buf[0] == 0xa3) {
@@ -640,6 +631,71 @@
goto unsupported;
}
 
+   /* If it's a FC0012, we need to bring GPIO5/RESET
+  out of floating or it's not going to show up.
+  We set GPIO5 to an output, enable the output, then
+  reset the tuner by bringing GPIO5 high then low again.
+
+  We're testing this last so that we don't accidentally
+  mess with other hardware that wouldn't like us messing
+  with whatever is connected to the rtl2832's GPIO5
+   */
+
+   /* close demod I2C gate */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
+   if (ret)
+   goto err;
+
+   /* Set GPIO5 to be an output */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val);
+   if (ret)
+   goto err;
+
+   val = 0xdf;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val);
+   if (ret)
+   goto err;
+
+   /* enable as output GPIO5 */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+   if (ret)
+   goto err;
+
+   val |= 0x20;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
+   if (ret)
+   goto err;
+
+   /* set GPIO5 high to reset fc0012 (if it exists) */
+   ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   val |= 0x20; 
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   /* bring GPIO5 low again after reset */
+   val = 0xdf;
+   ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
+   if (ret)
+   goto err;
+
+   /* re-open demod I2C gate */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open);
+   if (ret)
+   goto err;
+
+   /* check FC0012 ID register; reg=00 val=a1 */
+   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
+   if (ret == 0  buf[0] == 0xa1) {
+   priv-tuner = TUNER_RTL2832_FC0012;
+   rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
+   info(%s: FC0012 tuner found, __func__);
+   goto found;
+   }
+
 unsupported:
/* close demod I2C gate */
ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
--
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: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 07/30/2012 12:17 PM, David Basden wrote:
 On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote:
 On 06/27/2012 07:21 AM, Thomas Mair wrote:
 On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod 
 is answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. 
 It is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches 
 it again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is 
 probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but 
 that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on 
 the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas


 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?

 regards,
 poma

 Hi all,

 I will try to solve the issue as soon as I have some spare time. In the 
 meantime I 
 asked Realtek if they knew of any problems with the hardware, and I got a 
 GPIO
 list which might help me to solve the problem.

 Regrads
 Thomas


 This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs
 https://gist.github.com/2171926#120
 David, can you help with this tuner issue?
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898

 Cheers,
 poma
 
 It sounds like you're definately on the right track with the GPIO pins for
 tuner power and reset lines, especially if it's not making it through the
 tuner probe.
 
 The gist you linked to above has since been merged into the rtl-sdr tree,
 and the version in there is likely to be a much better reference than the
 old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr
 It reliably brings the rtl and the tuner up from cold, after reboots, and
 multiple times without rebooting. Given 

Re: rtl28xxu - rtl2832 frontend attach

2012-07-30 Thread poma
On 07/30/2012 02:56 PM, David Basden wrote:
 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on 
 the 
 tuner whatsoever.
 
 Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it
 doesn't, GPIO5 on the RTL isn't setup correctly somehow.
 
 At the same time, I was rereading code from:
 
 http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898
 
 and at no point is GPIO5 actually set to an output or enabled that I can find.
 rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running
 into this problem while trying to use some DVB driver code as an example of
 how to setup the RTL to talk to the FC0012)
 
 Try giving the patch below a go. Sorry, I don't have a build environment to
 hand, so there might be a typo I haven't picked up, but the upshot is that 
 I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the
 tuner and then trying to probe for the FC0012.
 
 Please let me know if this helps :)
 
 David
 
 --- a/rtl28xxu.c  2012-07-30 22:31:53.789638678 +1000
 +++ b/rtl28xxu.c  2012-07-30 22:48:35.774607232 +1000
 @@ -550,15 +550,6 @@
  
   priv-tuner = TUNER_NONE;
  
 - /* check FC0012 ID register; reg=00 val=a1 */
 - ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
 - if (ret == 0  buf[0] == 0xa1) {
 - priv-tuner = TUNER_RTL2832_FC0012;
 - rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
 - info(%s: FC0012 tuner found, __func__);
 - goto found;
 - }
 -
   /* check FC0013 ID register; reg=00 val=a3 */
   ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013);
   if (ret == 0  buf[0] == 0xa3) {
 @@ -640,6 +631,71 @@
   goto unsupported;
   }
  
 + /* If it's a FC0012, we need to bring GPIO5/RESET
 +out of floating or it's not going to show up.
 +We set GPIO5 to an output, enable the output, then
 +reset the tuner by bringing GPIO5 high then low again.
 +
 +We're testing this last so that we don't accidentally
 +mess with other hardware that wouldn't like us messing
 +with whatever is connected to the rtl2832's GPIO5
 + */
 +
 + /* close demod I2C gate */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
 + if (ret)
 + goto err;
 +
 + /* Set GPIO5 to be an output */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val);
 + if (ret)
 + goto err;
 +
 + val = 0xdf;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val);
 + if (ret)
 + goto err;
 +
 + /* enable as output GPIO5 */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val);
 + if (ret)
 + goto err;
 +
 + val |= 0x20;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val);
 + if (ret)
 + goto err;
 +
 + /* set GPIO5 high to reset fc0012 (if it exists) */
 + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + val |= 0x20; 
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + /* bring GPIO5 low again after reset */
 + val = 0xdf;
 + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val);
 + if (ret)
 + goto err;
 +
 + /* re-open demod I2C gate */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open);
 + if (ret)
 + goto err;
 +
 + /* check FC0012 ID register; reg=00 val=a1 */
 + ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012);
 + if (ret == 0  buf[0] == 0xa1) {
 + priv-tuner = TUNER_RTL2832_FC0012;
 + rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
 + info(%s: FC0012 tuner found, __func__);
 + goto found;
 + }
 +
  unsupported:
   /* close demod I2C gate */
   ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close);
 

…sorry for the delay,
After applied patch no luck - in attach is dmesg for working original
Realtek driver(dvb_usb_rtl2832), and second one(dvb-usb-rtl28xxu)
rtl2832 part by Thomas with tuner issue, still not working.
Most intriguing is tuner get stucked by tuning(t-zapping)!

Cheers,
poma

ps.
Thank you so far, really thorough explanation!




dvb-usb-rtl28xxu-dmesg.txt
…
rtl28xxu_module_init:
rtl28xxu_probe: interface=0
check for warm bda 2831
check for warm 14aa 160
check for warm 14aa 161
something went very wrong, device was not found in current device list - let's 
see what comes next.
check for warm ccd a9
check for warm 1f4d b803
dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in warm state.
power control: 1
rtl2832u_power_ctrl: onoff=1
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
all in all I will use 24576 bytes for streaming
allocating buffer 0
buffer 

Re: rtl28xxu - rtl2832 frontend attach

2012-06-27 Thread poma
On 06/27/2012 07:21 AM, Thomas Mair wrote:
 On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It 
 is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
 again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is 
 probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas


 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?

 regards,
 poma

 Hi all,
 
 I will try to solve the issue as soon as I have some spare time. In the 
 meantime I 
 asked Realtek if they knew of any problems with the hardware, and I got a GPIO
 list which might help me to solve the problem.
 
 Regrads
 Thomas
 

Nice to know ;)

Cheers,
poma
--
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: rtl28xxu - rtl2832 frontend attach

2012-06-26 Thread poma
On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing and 
 did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It is 
 almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.

 
 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.
 
 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:
 
 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
 again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection
 
 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:
 
 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)
 
 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)
 
 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 
 
 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but that
 did not help either.
 
 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on the 
 tuner whatsoever.
 
 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.
 
 Regards
 Thomas
 

Cheers Thomas, Hans-Frieder, Antti, Mauro!
Hans-Frieder, are you having the same issue with fc0011af9035?
Antti, no tricks up your sleeve?
Senhor Mauro, is rtl2832 demod going to be merged?

regards,
poma
--
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: rtl28xxu - rtl2832 frontend attach

2012-06-26 Thread Thomas Mair
On 26.06.2012 19:17, poma wrote:
 On 05/28/2012 04:48 PM, Thomas Mair wrote:
 On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing 
 and did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It 
 is almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].


 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.

 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.

 I have some spare time today and will investigate the problem further.


 I tried a few things regarding the problem today and could find out a 
 few more details, but could not resolve the issue.

 The GPIO pin configuration for the devices with the fc0012 (and probably
 also with the fc0013) tuner is the following:

 GPIO0: demod power
 GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
 again)
 GPIO4: tuner power? (maybe antenna power?)
 GPIO5: tuner reset
 GPIO6: UHF/VHF band selection

 All of these GPIOs are configured as output. When the device is plugged in
 the tuner is powered up correctly, but I am not able to power it up when
 a reboot is performed. What I tried was the following:

 - on rtl28xxu_power_ctrl off:
   - GPIO4 = 1 (off)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl28xxu_power_ctrl on:
   - GPIO3 = 1
   - GPIO4 = 0 (on)
   - GPIO5 = 0 
   - GPIO6 = 0 (default state)

 - on rtl2832_frontend_attach:
   - GPIO5 = 1 
   - GPIO5 = 0 

 This sequence should ensure that the tuner is powered on when the frontend
 is attached, and a tuner reset is being performed before the tuner is probed.
 However this sequence fails the same way as it did before. I tried to add
 timeouts to be sure that the tuner is not probed while it is reset but that
 did not help either.

 Right now I really don't know where I should look for the solution of
 the problem. It seems that the tuner reset does not have any effect on the 
 tuner whatsoever.

 Is there anybody who could look at the code, or maybe knows what could be
 the cause of the problem? I suspect I am just too blind to see my own 
 mistakes.

 Regards
 Thomas

 
 Cheers Thomas, Hans-Frieder, Antti, Mauro!
 Hans-Frieder, are you having the same issue with fc0011af9035?
 Antti, no tricks up your sleeve?
 Senhor Mauro, is rtl2832 demod going to be merged?
 
 regards,
 poma
 
Hi all,

I will try to solve the issue as soon as I have some spare time. In the 
meantime I 
asked Realtek if they knew of any problems with the hardware, and I got a GPIO
list which might help me to solve the problem.

Regrads
Thomas

--
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: rtl28xxu - rtl2832 frontend attach

2012-05-28 Thread Thomas Mair
On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing and 
 did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It is 
 almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].
 

To reproduce the bug it is not necessary to reboot the machine. Simply 
unload and load of the dvb_usb_rtl28xxu module will lead to the same 
situation.

I suspect, that when power is turned off, the tuner power is not 
switched on correctly. The mistake is not related to the OUTPUT_VAL
registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.

What makes me wonder is if no tuning operation is performed before
reboot, the driver does work correctly after that, as poma already
noticed.

I have some spare time today and will investigate the problem further.

Regards 
Thomas


--
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: rtl28xxu - rtl2832 frontend attach

2012-05-28 Thread Thomas Mair
On 28.05.2012 08:58, Thomas Mair wrote:
 On 26.05.2012 04:47, poma wrote:
 On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing and 
 did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It is 
 almost 100% sure error is wrong tuner GPIO.

 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.

 True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
 even more.
 Precisely, what breaks a tuner on next soft [re]boot are apps/utils
 which engage tzap/scan[dvb].

 
 To reproduce the bug it is not necessary to reboot the machine. Simply 
 unload and load of the dvb_usb_rtl28xxu module will lead to the same 
 situation.
 
 I suspect, that when power is turned off, the tuner power is not 
 switched on correctly. The mistake is not related to the OUTPUT_VAL
 registers but probably to the OUTPUT_DIR or OUTPUT_EN registers.
 
 What makes me wonder is if no tuning operation is performed before
 reboot, the driver does work correctly after that, as poma already
 noticed.
 
 I have some spare time today and will investigate the problem further.
 

I tried a few things regarding the problem today and could find out a 
few more details, but could not resolve the issue.

The GPIO pin configuration for the devices with the fc0012 (and probably
also with the fc0013) tuner is the following:

GPIO0: demod power
GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it 
again)
GPIO4: tuner power? (maybe antenna power?)
GPIO5: tuner reset
GPIO6: UHF/VHF band selection

All of these GPIOs are configured as output. When the device is plugged in
the tuner is powered up correctly, but I am not able to power it up when
a reboot is performed. What I tried was the following:

- on rtl28xxu_power_ctrl off:
  - GPIO4 = 1 (off)
  - GPIO5 = 0 
  - GPIO6 = 0 (default state)

- on rtl28xxu_power_ctrl on:
  - GPIO3 = 1
  - GPIO4 = 0 (on)
  - GPIO5 = 0 
  - GPIO6 = 0 (default state)

- on rtl2832_frontend_attach:
  - GPIO5 = 1 
  - GPIO5 = 0 

This sequence should ensure that the tuner is powered on when the frontend
is attached, and a tuner reset is being performed before the tuner is probed.
However this sequence fails the same way as it did before. I tried to add
timeouts to be sure that the tuner is not probed while it is reset but that
did not help either.

Right now I really don't know where I should look for the solution of
the problem. It seems that the tuner reset does not have any effect on the 
tuner whatsoever.

Is there anybody who could look at the code, or maybe knows what could be
the cause of the problem? I suspect I am just too blind to see my own mistakes.

Regards
Thomas
--
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: rtl28xxu - rtl2832 frontend attach

2012-05-25 Thread poma
On 05/20/2012 11:12 PM, Thomas Mair wrote:
 On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:

 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found

 These errors are coming from tuner probe. As it still goes to probing and 
 did not jump out earlier when gate is opened it means that demod is 
 answering commands but tuner are not.

 My guess is that tuner is still on the reset or not powered at all. It is 
 almost 100% sure error is wrong tuner GPIO.
 
 There is an issue with GPIO, as FC0012 tuner callback will set 
 the value of one of the GPIO outputs. However fixing that, will
 not resolve the issue. So I need to debug the problem further.
 
True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes
even more.
Precisely, what breaks a tuner on next soft [re]boot are apps/utils
which engage tzap/scan[dvb].

· · · — — — · · ·

cheers,
poma
--
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


rtl28xxu - rtl2832 frontend attach

2012-05-20 Thread poma

Heigh ho, heigh ho
To make your troubles go
Just keep on singing
All day long, heigh ho
Heigh ho!

After hard/cold boot:
[…]
usb 1-1: new high-speed USB device number 2 using ehci_hcd
usb 1-1: New USB device found, idVendor=1f4d, idProduct=b803
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: RTL2838UHIDIR
usb 1-1: Manufacturer: Realtek
usb 1-1: SerialNumber: 0041
rtl28xxu_module_init:
rtl28xxu_probe: interface=0
check for warm bda 2831
check for warm 14aa 160
check for warm 14aa 161
something went very wrong, device was not found in current device list -
let's see what comes next.
check for warm ccd a9
check for warm 1f4d b803
dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in
warm state.
power control: 1
rtl2832u_power_ctrl: onoff=1
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
all in all I will use 24576 bytes for streaming
DVB: registering new adapter (G-Tek Electronics Group Lifeview LV5TDLX
DVB-T)
DVB: register adapter0/demux0 @ minor: 0 (0x00)
DVB: register adapter0/dvr0 @ minor: 1 (0x01)
DVB: register adapter0/net0 @ minor: 2 (0x02)
rtl2832u_frontend_attach:
rtl28xxu: rtl2832u_frontend_attach: FC0012 tuner found
dvb_register_frontend
DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
DVB: register adapter0/frontend0 @ minor: 3 (0x03)
dvb_frontend_clear_cache() Clearing cache for delivery system 3
rtl2832u_tuner_attach:
fc0012: Fitipower FC0012 successfully attached.
Registered IR keymap rc-empty
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:02.1/usb1/1-1/rc/rc0/input5
rc0: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:02.1/usb1/1-1/rc/rc0
dvb-usb: schedule remote query interval to 400 msecs.
power control: 0
rtl2832u_power_ctrl: onoff=0
dvb-usb: G-Tek Electronics Group Lifeview LV5TDLX DVB-T successfully
initialized and connected.
rtl28xxu_probe: interface=1
usbcore: registered new interface driver dvb_usb_rtl28xxu
[…]
Seems OK.

After soft/warm re(boot):
[…]
usb 1-1: new high-speed USB device number 2 using ehci_hcd
usb 1-1: New USB device found, idVendor=1f4d, idProduct=b803
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: RTL2838UHIDIR
usb 1-1: Manufacturer: Realtek
usb 1-1: SerialNumber: 0041
rtl28xxu_module_init:
rtl28xxu_probe: interface=0
check for warm bda 2831
check for warm 14aa 160
check for warm 14aa 161
something went very wrong, device was not found in current device list -
let's see what comes next.
check for warm ccd a9
check for warm 1f4d b803
dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in
warm state.
power control: 1
rtl2832u_power_ctrl: onoff=1
dvb-usb: will pass the complete MPEG2 transport stream to the software
demuxer.
all in all I will use 24576 bytes for streaming
DVB: registering new adapter (G-Tek Electronics Group Lifeview LV5TDLX
DVB-T)
DVB: register adapter0/demux0 @ minor: 0 (0x00)
DVB: register adapter0/dvr0 @ minor: 1 (0x01)
DVB: register adapter0/net0 @ minor: 2 (0x02)
rtl2832u_frontend_attach:
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
No compatible tuner found
dvb-usb: no frontend was attached by 'G-Tek Electronics Group Lifeview
LV5TDLX DVB-T'
Registered IR keymap rc-empty
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:02.1/usb1/1-1/rc/rc0/input5
rc0: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:02.1/usb1/1-1/rc/rc0
dvb-usb: schedule remote query interval to 400 msecs.
power control: 0
rtl2832u_power_ctrl: onoff=0
dvb-usb: G-Tek Electronics Group Lifeview LV5TDLX DVB-T successfully
initialized and connected.
rtl28xxu_probe: interface=1
usbcore: registered new interface driver dvb_usb_rtl28xxu
[…]
D'oh!

Difference - cold vs warm boot:
 rtl28xxu: rtl2832u_frontend_attach: FC0012 tuner found
 dvb_register_frontend
 DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
 DVB: register adapter0/frontend0 @ minor: 3 (0x03)
 dvb_frontend_clear_cache() Clearing cache for delivery system 3
 rtl2832u_tuner_attach:
 fc0012: Fitipower FC0012 successfully attached.
---
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found
 dvb-usb: no frontend was attached by 'G-Tek Electronics Group Lifeview
LV5TDLX DVB-T'

Any tip or trick?

cheers,
poma

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to 

Re: rtl28xxu - rtl2832 frontend attach

2012-05-20 Thread Antti Palosaari

On 20.05.2012 20:04, poma wrote:

After hard/cold boot:



DVB: register adapter0/net0 @ minor: 2 (0x02)
rtl2832u_frontend_attach:
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
rtl28xxu_ctrl_msg: failed=-32
No compatible tuner found


These errors are coming from tuner probe. As it still goes to probing 
and did not jump out earlier when gate is opened it means that demod is 
answering commands but tuner are not.


My guess is that tuner is still on the reset or not powered at all. It 
is almost 100% sure error is wrong tuner GPIO.


regards
Antti
--
http://palosaari.fi/
--
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: rtl28xxu - rtl2832 frontend attach

2012-05-20 Thread Thomas Mair
On 20.05.2012 22:08, Antti Palosaari wrote:
 On 20.05.2012 20:04, poma wrote:
 After hard/cold boot:
 
 DVB: register adapter0/net0 @ minor: 2 (0x02)
 rtl2832u_frontend_attach:
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 rtl28xxu_ctrl_msg: failed=-32
 No compatible tuner found
 
 These errors are coming from tuner probe. As it still goes to probing and did 
 not jump out earlier when gate is opened it means that demod is answering 
 commands but tuner are not.
 
 My guess is that tuner is still on the reset or not powered at all. It is 
 almost 100% sure error is wrong tuner GPIO.

There is an issue with GPIO, as FC0012 tuner callback will set 
the value of one of the GPIO outputs. However fixing that, will
not resolve the issue. So I need to debug the problem further.

Thanks for the bug report.

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