[...] >> > What if Sleep_Notification will take several seconds? >> >> Yes, that horrible! You should tell your colleagues designing FTLs to make sure >> that _never_ happens. > > Agree, but we need to consider and take care of all such cases in the driver side. > Device might be busy with its internal garbage collection, and as spec allows, it > will complete it in a great manner after host sends PON command. > Okay, so to me, I think the SLEEP notification needs to be sent as a part of the system PM suspend phase. And more exactly from the bus_ops->suspend() callback. In addition to that, we should be able improve the situation by also sending the SLEEP notification as part of an "idle operation". With "idle operation" I mean the mmc block layer hasn’t received any new request for a while (the framework for this is already implemented by using runtime PM). So if the SLEEP notification was sent during the "idle operation" and no new request was needed during the system PM suspend phase we wouldn't have to wake up the card again using HPI, but instead just leave it "sleeping" and send CMD5. Still, there would be no guarantees that "idle operations" is executed before a system PM suspend phase starts. So there are no way we can improve the worst case scenario. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
