On Fri, Oct 28, 2011 at 8:12 PM, Sebastian Rasmussen <seb...@gmail.com> wrote:
>> Maybe i think that my-patch should be worked only level-2/3..right?
>> Because URGENT_BKOPS bit in the EXCEPTION_EVENTS_STATUS is set whenever is
>> either 2 or 3.
>> In this case, host control with R1-type response.
>
> For 4.41 your patch is fine. For 4.5 I think it starts BKOPS too often.
>
> For 4.5 devices the R1 response indicates that there is an exception
> event which may be have several different causes: PACKED_FAILURE,
> SYSPOOL_EXHAUSTED, DYNCAP_NEEDED or URGENT_BKOPS. But if the R1
> response indicates an exception event it may be becuase of a cause
> which is not URGENT_BKOPS. So for 4.5 you must read
> EXCEPTION_EVENTS_STATUS to determine what the cause was.
>
>> But in level-0/1 case, need to check BKOPS_STATUS periodically.
>> How did you understand that "periodically" means?
>> If host need to get BKOPS_STATUS periodically, maybe send CMD8 periodically.
>> How periodically?
>
> Good question, I don't know yet. Problem this should be done when the
> system is otherwise idling, to not interfere with normal accesses (if
> you do I would expect you to get worse performance).
>
I think there is a need for a 'mmc_maintenance' timer of some sort, which should
run while idle. When it expires, all pending maintenance operations can be
executed.. (Sanitize, Cache flush, BKOPS and RealTime Clock). This
aligns also with
the update frequency requirements for RTC.
This would reduce the need for running such plumbing operations on the hot path.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
