Re: [PATCH] mmc: support BKOPS feature for eMMC

[Jaehoon Chung <jh80.chung@samsung.com>]

Hi Sebastian.

I have some question..
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.

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? 

Best Regards,
Jaehoon Chung

On 10/28/2011 05:51 AM, Sebastian Rasmussen wrote:

> Hi!
> 
>> This patch only starts BKOPS if it's urgent or critical.
> 
> Almost, it starts BKOPS when it is urgent, which per spec means level
> 2 or 3, i.e. when performance is impacted or when it is critical.
> Better use the specs terminology as far as possible to relieve
> everyone of confusion.
> 
>> I would be preferable to run bkops periodically and only when
>> the card is idle to minimize the risk of reaching URGENT.
> 
> Well, you kind of need both. If the eMMC is kept busy to such an
> extent that the block device is never idling then you would definitely
> require this patch, right? Otherwise you may end up wasting the time
> between the last command sent and when the device has been deemed to
> be idle for long enough.
> 
> So basically the OP's patch fixes the case where, e.g. sustained
> (re-)writing, keeps the block device busy until and after it reaches
> the critical BKOPS level, while your proposal takes care of the other
> case where the block device is not accessed all the time.
> 
>> The specs says:
>> -----
>> Hosts shall still read the full status from the BKOPS_STATUS byte periodically
>> and start background operations as needed.
>> -----
> 
> Sure, if there is idle time to do it, then why not.
> If there is no idle time and URGENT_BKOPS is asserted, then the
> framework can not wait until the next idle period, but should issue
> BKOPS as soon as possible after the current command is finished.
> 
>> I'm thinking of checking BKOPS_STATUS when the card is idle and then run bkops
>> even if level is only 1 (Operations outstanding – non critical). Would this make
>> sense?
> 
> I guess this boils down to how you define idle..? Does it mean
> immediately after the current command has been fully serviced, or does
> it mean some arbitrary time after the last sent command has been fully
> serviced? My assumption is that you are refering to the latter, in
> which case certain access patterns may cause problems. So, how do
> _you_ define idle? :)
> 

>  / Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>