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