2012/2/24 Saugata Das [off-list ref]:

Hi Jaehoon

Since you are planning to rework this patch, can you consider to
implement the periodic BKOPS level check and triggering BKOPS at level
1 when the queue is idle ?

Hi Saugata,

Sure..i'm considering them..
I have implemented and tested the periodic bkops level.
It should be included in patch-v8.

Thank you for comments.

Best Regards,
Jaehoon Chung

On 24 February 2012 14:08, Jaehoon Chung [off-list ref] wrote:

quoted

On 02/23/2012 06:05 PM, Adrian Hunter wrote:

quoted

On 23/02/12 04:21, Jaehoon Chung wrote:

quoted

On 02/22/2012 11:11 PM, Adrian Hunter wrote:

quoted

On 20/01/12 08:48, Jaehoon Chung wrote:

quoted

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..

quoted

quoted

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.

quoted

      - do not release the host while bkops are running

Right..don't release the host. i will consider.

quoted

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

quoted

--
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

--
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

--
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