> >I'm not sure that BKOPS with runtime-pm associates.
> >Do you think it's helpful for power management?
> >How about hibernation scheme for runtime-pm?
> >I'm testing and I can introduce soon.
>
>Well, I am thinking on following approach when we introduce
>power management.
>
>ufshcd_runtime_suspend() {
> if (bkops_status >= NON_CRITICAL) { /* 0x1 */
> ufshcd_enable_auto_bkops();
> hibernate(); /* only the link and the device
> should be able to cary out bkops */
> } else {
> hibernate(); /* Link and the device for more savings */
> }
>}
>
>Let me know if this is okay.
I still consider whether BKOPS is proper behavior with runtime-pm or not.
The BKOPS is something that host allows the card to carry out
when the host knows it is idle and not expecting back to back requests.
Runtime PM idle is the only way to know whether the device is
idle (unless we want to reinvent the wheel to detect the idleness of
host and trigger bkops). There was a discussion on this in MMC mailing
list as well, and folks have agreed to move idle time bkops to runtime
PM (http://thread.gmane.org/gmane.linux.kernel.mmc/19444/)
How about this scenario? It seems more simple.
If we concern a response latency of transfer requests, BKOPS can be disabled by default.
And then BKOPS can be enabled whenever device requests in some exception.
If you have any idea, let me know.
Exceptions are raised only when the device is in critical need for
bkops. Also the spec. recommends, host should ensure that the device
doesn't go into such states.
With your suggestion, when we disable bkops, the exception is raised and
we enable bkops after which there is no way to disable it again?
--
Regards,
Sujit
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
