Re: work on rts5139

[edwin_rong <edwin_rong@xxxxxxxxxxxxxx>]

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