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
