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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
