All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Basden <davidb-git@rcpt.to>
To: poma <pomidorabelisima@gmail.com>
Cc: davidb-git@rcpt.to, Thomas Mair <thomas.mair86@googlemail.com>,
	Hans-Frieder Vogt <hfvogt@gmx.net>,
	Antti Palosaari <crope@iki.fi>,
	mchehab@redhat.com, linux-media@vger.kernel.org
Subject: Re: rtl28xxu - rtl2832 frontend attach
Date: Mon, 30 Jul 2012 20:17:06 +1000	[thread overview]
Message-ID: <20120730101706.GH9047@faith.oztechninja.com> (raw)
In-Reply-To: <5016328E.3040909@gmail.com>

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 fc0011&af9035?
> >> 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 others have improved it since last
time I looked at the tree, it would be a good place to look for at least
bringing up the tuner.  Given it's not trying to do DVB though, be careful
with any assumptions that the setup of the RTL or tuner past then are going
to be what you're trying to do though; (It's not using the deframing stuff at
all, AGC is likely switched off, and the LNA gain is just set to a fixed
value and left there)

That said, these dongles are really done on a budget, and the hardware
itself can be dodgy in ways that look like software problems. Although
it's not that likely given the way you're able to reproduce, just check:

 - dmesg to make sure the USB device is coming up in hispeed rather fullspeed,
   and that there aren't any problems attaching before it hits the dongle driver
 - It's not hooked up through an unpowered USB extension. Some of them barely
   up regardless
 - The antenna is connected. One of the dongles I have will reliably kill the
   power on my netbook if I plug it in without an antenna connected. The 
   implications are rather scary.

all of which can lead to fail when in the middle of bringing up the dongle,
and can look like errors in the tuner init code.

(If you weren't already able to get it working before resetting the dongle
I'd also have suggested checking the tuner onboard your dongle is the one 
you think it is; There is much reuse of USB ids with different hardware)

As for bring up the tuner, you'll want to:

 - Setup the RTL etc. and power on the demodulator and tuner

 - Check that it's anything but an FC0012 if you're doing tuner probing
   rather than messing with GPIOs that won't be hooked up that way

 - Explicitly disable the I2C repeater/bridge so the rtl is listening NOT the tuner.

 - Make sure GPIO5 and GPIO6 are both enabled, set to be outputs, and have
   an output value set. i.e.

    o Read the value from GPD, clear bits 0x30, and write the result to GPO
    o Read the value from GPOE, set bits 0x30, and write the result back to GPOE

   GPIO5 is really important, as it's the RESET line, and if it's not setup properly
   it will float, and leave the tuner likely in a bad state 

 - Reset the tuner by setting GPIO5 to 1 then 0:

    o Read the value from GPO, set bit 0x20, and write the result back to GPO
    o Read the value from GPO, clear bit 0x20, and write the result back to GPO

 - Enable the I2C repeater to talk to the tuner

 - Probe to check the FC0012 indeed exists (reading from 0xc6,0x00 should give you 0xa1)
   and go on to setup the tuner

Hopefully that will help some.  If it doesn't help enough, let me know, or drop
into ##rtl-sdr on freenode where people are banging their heads against walls daily
seeing how hard they can push rtl2832 dongles to do SDR.

Cheers,

David

  reply	other threads:[~2012-07-30 10:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-20 17:04 rtl28xxu - rtl2832 frontend attach poma
2012-05-20 20:08 ` Antti Palosaari
2012-05-20 21:12   ` Thomas Mair
2012-05-26  2:47     ` poma
2012-05-28  6:58       ` Thomas Mair
2012-05-28 14:48         ` Thomas Mair
2012-06-26 17:17           ` poma
2012-06-27  5:21             ` Thomas Mair
2012-06-27 12:22               ` poma
2012-07-30  7:06               ` poma
2012-07-30 10:17                 ` David Basden [this message]
2012-07-30 15:58                   ` poma
2012-07-30 12:56                 ` David Basden
2012-07-30 17:07                   ` poma
2012-07-31 11:42                     ` poma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120730101706.GH9047@faith.oztechninja.com \
    --to=davidb-git@rcpt.to \
    --cc=crope@iki.fi \
    --cc=hfvogt@gmx.net \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=pomidorabelisima@gmail.com \
    --cc=thomas.mair86@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.