linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Michael Krufky <mkrufky@linuxtv.org>
Cc: linux-media <linux-media@vger.kernel.org>
Subject: Re: tda18271 driver power consumption
Date: Wed, 25 Jul 2012 03:43:44 +0300	[thread overview]
Message-ID: <500F4140.1000202@iki.fi> (raw)
In-Reply-To: <CAOcJUbzJjBBMcLmeaOCsJRz44KVPqZ_sGctG8+ai=n1W+9P9xA@mail.gmail.com>

On 07/25/2012 03:15 AM, Michael Krufky wrote:
> On Tue, Jul 24, 2012 at 6:17 PM, Michael Krufky <mkrufky@linuxtv.org> wrote:
>> On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari <crope@iki.fi> wrote:
>>> On 07/25/2012 12:55 AM, Michael Krufky wrote:
>>>>
>>>> On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari <crope@iki.fi> wrote:
>>>>>
>>>>> Moi Michael,
>>>>> I just realized tda18271 driver eats 160mA too much current after attach.
>>>>> This means, there is power management bug.
>>>>>
>>>>> When I plug my nanoStick it eats total 240mA, after tda18271 sleep is
>>>>> called
>>>>> it eats only 80mA total which is reasonable. If I use Digital Devices
>>>>> tda18271c2dd driver it is total 110mA after attach, which is also quite
>>>>> OK.
>>>>
>>>>
>>>> Thanks for the report -- I will take a look at it.
>>>>
>>>> ...patches are welcome, of course :-)
>>>
>>>
>>> I suspect it does some tweaking on attach() and chip leaves powered (I saw
>>> demod debugs at calls I2C-gate control quite many times thus this
>>> suspicion). When chip is powered-up it is usually in some sleep state by
>>> default. Also, on attach() there should be no I/O unless very good reason.
>>> For example chip ID is allowed to read and download firmware in case it is
>>> really needed to continue - like for tuner communication.
>>>
>>>
>>> What I found quickly testing few DVB USB sticks there seems to be very much
>>> power management problems... I am now waiting for new multimeter in order to
>>> make better measurements and likely return fixing these issues later.
>>
>> The driver does some calibration during attach, some of which is a
>> one-time initialization to determine a temperature differential for
>> tune calculation later on, which can take some time on slower USB
>> buses.  The "fix" for the power usage issue would just be to make sure
>> to sleep the device before exiting the attach() function.
>>
>> I'm not looking to remove the calibration from the attach -- this was
>> done on purpose.
>>
>
> Antti,
>
> After looking again, I realize that we are purposefully not sleeping
> the device before we exit the attach() function.
>
> The tda18271 is commonly found in multi-chip designs that may or may
> not include an analog demodulator and / or other tda18271 tuners.  In
> such designs, the chips tend to be daisy-chained to each other, using
> the xtal output and loop-thru features of the tda18271.  We set the
> required features in the attach-time configuration structure.
> However, we must keep in mind that this is a hybrid tuner chip, and
> the analog side of the bridge driver may actually come up before the
> digital side.  Since the actual configuration tends to be done in the
> digital bring-up, the analog side is brought up within tuner.ko using
> the most generic one-size-fits all configuration, which gets
> overridden when the digital side initializes.
>
> It is absolutely crucial that if we actually need the xtal output
> feature enabled, that it must *never* be turned off, otherwise the i2c
> bus may get wedged unrecoverably.  So, we make sure to leave this
> feature enabled during the attach function, since we don't yet know at
> that point whether there is another "instance" of this same tuner yet
> to be initialized.  It is not safe to power off that feature until
> after we are sure that the bridge has completely initialized.
>
> In order to rectify this issue from within your driver, you should
> call sleep after you complete the attach.  For instance, this is what
> we do in the cx23885 driver:
>
> if (fe0->dvb.frontend->ops.analog_ops.standby)
>                   fe0->dvb.frontend->ops.analog_ops.standby(fe0->dvb.frontend);
>
>
> ...except you should call into the tuner_ops->sleep() function instead
> of analog_demod_ops->standby()
>
> Does this clear things up for you?

Surely this is possible and it will resolve power drain issue. But it is 
not nice looking and causes more deviation compared to others.

Could you add configuration option "bool do_not_powerdown_on_attach" ?

I have quite many tda18271 devices here and all those are DVB onlỵ (OK, 
PCTV 520e is DVB + analog, but analog is not supported). Having 
configuration parameter sounds like better plan.

regards
Antti

-- 
http://palosaari.fi/

  reply	other threads:[~2012-07-25  0:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-22 19:59 tda18271 driver power consumption Antti Palosaari
2012-07-24 21:55 ` Michael Krufky
2012-07-24 22:12   ` Antti Palosaari
2012-07-24 22:17     ` Michael Krufky
2012-07-25  0:15       ` Michael Krufky
2012-07-25  0:43         ` Antti Palosaari [this message]
2012-07-26  3:18           ` Michael Krufky
2012-07-26 12:48             ` Michael Krufky
2012-08-06 13:30               ` Antti Palosaari
     [not found]               ` <20120927161940.0f673e2e@redhat.com>
2012-09-27 19:59                 ` Antti Palosaari
2012-09-27 21:20                   ` Michael Krufky
2012-09-27 21:38                     ` Antti Palosaari
2012-09-27 21:58                       ` Michael Krufky
2012-09-27 22:26                         ` Antti Palosaari
2012-09-27 22:43                           ` Michael Krufky
2012-09-27 22:46                             ` Antti Palosaari
2012-09-27 22:55                               ` Michael Krufky
2012-09-27 23:05                                 ` Antti Palosaari
     [not found]                         ` <20120928084337.1db94b8c@redhat.com>
2012-09-28 15:04                           ` [PATCH] tda18271-common: hold the I2C adapter during write transfers Mauro Carvalho Chehab
2012-09-28 18:31                             ` Antti Palosaari
2012-09-28 18:56                               ` Michael Krufky
2012-09-29 19:20                                 ` Michael Krufky
2012-10-07 12:42                                   ` Mauro Carvalho Chehab
2012-10-07 13:18                                     ` Michael Krufky
2012-10-01 10:42                               ` Mauro Carvalho Chehab
2012-10-01 11:31                                 ` Antti Palosaari
2012-10-01 12:36                                   ` Mauro Carvalho Chehab
2012-09-28 16:19                           ` tda18271 driver power consumption Antti Palosaari
2012-08-06 18:19       ` Antti Palosaari
2012-08-06 18:35         ` Devin Heitmueller
2012-08-06 18:57           ` Michael Krufky
2012-08-06 19:13             ` Antti Palosaari
2012-08-06 20:19               ` Manu Abraham
2012-09-20 17:47               ` Michael Krufky
2012-09-20 17:49                 ` Michael Krufky
2012-09-22 17:21                   ` Antti Palosaari

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=500F4140.1000202@iki.fi \
    --to=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).