Re: work on rts5139
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 05/14/2012 02:28 PM, Jan-Simon Möller wrote:
Hi wwang, Oleksij! Find my notes inline: Am Montag, Mai 14, 2012, 04:50:04 AM schrieb wwang:Hi Oleksij: We will modify the TODO file to manifest our next steps on Realtek card reader drivers. And as to your feature request, we will add it in our new driver stack. Many Thanks! wwang[...]3. the current driver has polling function, it produce 1% CPU load. Even if no card is present. Are there any plans to avoid it in new stack? Or at least increase polling interval to 100 or more instead of currently used 50? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We also notice CPU loading issue recently. Increasing polling interval is the way to solve it. But only increasing it will cause other problem, such as slow card detection. We will give our solution in the next release.This is an important issue power-wise. Just increasing the polling interval is no optimal solution as we're not solving the biggest issue imho - which is polling. Polling keeps the system out of the deepest possible energy saving states regularly - can't the device fire up an irq or can't this be solved without polling at all ? This goes on once the (device) runtime-PM is used in more and more drivers. It will cause more issues in the long run ... Ideas/Comments ?
Hi WWang, Jan-Simon: Maybe "timer mechanism" could help slove the issues.For CPU loading issue, prolonging the interval of timer may decrease CPU loading. Of course, we cannot sacrifice the detect accurancy of card plug/unplug event. We should balance the two factors mentioned above to determine the value of timer interval. For Runtime-PM issue, during working status, just use timer mechanism to implement "polling", which is use to monitor card plug/unplug or some other status as so on. Once the system requires to enter runtime-suspend state, we can wait for timer expiration and not update the time count for the next expiration, or delete timer directly, then driver would not prevent certain subsystem entering power-saving status.
Thanks & BRs Edwin
Best, Jan-Simon _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel