On 02/23/2012 06:05 PM, Adrian Hunter wrote: > On 23/02/12 04:21, Jaehoon Chung wrote: >> On 02/22/2012 11:11 PM, Adrian Hunter wrote: >> >>> On 20/01/12 08:48, Jaehoon Chung wrote: >>>> Enable eMMC background operations (BKOPS) feature. >>>> >>>> If URGENT_BKOPS is set after a response, note that BKOPS >>>> are required. After all I/O requests are finished, run >>>> BKOPS if required. Should read/write operations be requested >>>> during BKOPS, first issue HPI to interrupt the ongoing BKOPS >>>> and then service the request. >>> >>> You are leaving bkops running and releasing the host. Won't >>> that cause problems for other entry points to mmc services >>> e.g. system suspend (cache control, sleep etc), ioctl, sysfs, >>> etc >> >> I see. i will complement for your review. > > Please cc me. Sure.. > >> Didn't you have the other comment? > > Well, yes. I also suggest: > - don't use host->lock spin lock at all > - claim the host in the caller not in > mmc_start_bkops() > > But the main issues are design issues not implementation. > i.e. > - always run bkops at level 3 before doing any > other requests - that requirement should probably > be implemented in core rather than the block driver In core..it's reasonable..i will try that. > - do not release the host while bkops are running Right..don't release the host. i will consider. > > And a new one: > - how do you know that trim/discard/sanitize will not > result in a need for bkops? Well, i didn't consider that case. but i think that need to control them. Thanks for comments. Best Regards, Jaehoon Chung > > -- > 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
