Re: tda18271 driver power consumption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/25/2012 01:17 AM, Michael Krufky wrote:
On Tue, Jul 24, 2012 at 6:12 PM, Antti Palosaari <crope@xxxxxx> wrote:
On 07/25/2012 12:55 AM, Michael Krufky wrote:

On Sun, Jul 22, 2012 at 3:59 PM, Antti Palosaari <crope@xxxxxx> 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.


You should understand from DVB driver model:
* attach() called only once when driver is loaded
* init() called to wake-up device
* sleep() called to sleep device

What I would like to say is that there is very big risk to shoot own leg when doing some initialization on attach(). For example resuming from the suspend could cause device reset and if you rely some settings that are done during attach() you will likely fail as Kernel / USB-host controller has reset your device.

See reset_resume from Kernel documentation:
Documentation/usb/power-management.txt

regards
Antti

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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux