Hi!
> HPI is a feature to handle a higher or urgent request then pre-ongoing
> request and it's only possible when some conditions are met.
Agreed, as I read the spec this would writes, erases and BKOPS
(eMMC spec 4.41 7.6.20 (table 20) and the 3rd paragraph in 7.6.19).
> BKOPS is a feature to give a chance to optimize the internal
> for next operation.
Yes, I believe the main reasons would be when blocks are
either replaced or a ERASE or TRIM operation has been issued.
The BKOPS feature would allow the eMMC device to clean up its
internal state and pre-erase any internal flash devices so
that the next write operation would have better performance.
I believe this to be the intent at least.
> Current implementation is HPI is used for BKOPS but I think
> HPI is used for Write operation to reduce the latency.
True, the focus of HPI is for Write operations, however in
eMMC spec 4.41 chapter 7.6.19 on background operations it
does state that a host may interrupt any ongoing background
operations by using HPI. So to me it seems as if the intent
from Jedec has been that it may be used in case of BKOPS
taking too long and so may be blocking pending requests..?
> 1. I wonder BKOPS is really required to perform frequently?
> Yes I know it's helpful to use but no need to call it frequently.
According to the spec it is advised to start bkops whenever
the eMMC device itself indicates an urgent need for it. In
what way do you think the proposed patch issues bkops too often?
I believe that the patch properly checks for R1_URGENT_BKOPS,
which seems correct..?
> 2. Previous time only one request is handled at mmc block. so it can't
> implement the HPI for user request. but as Per Forlin implement the
> double buffering concept. it can possible to implement the HPI,
> interrupt the current write operation and do urgent read request.
Yes, absolutely. Interrupting ongoing write or erase/trim operations
would be the other use for BKOPS. How do you feel that the addition
of BKOPS (and thus HPI) interferes with this? Is it just a matter
of in what order these two features are integrated into the kernel?
> Related with this, you can find a "HPI background and one of possible
> solutions" in the mmc Spec.
What part of the spec are you referring to?
> 3. real use scenario, realtime class read request has too much
> latency since previous write request, (when merge operation is
> happened eMMC internally)
I'm not sure what you are explaining here. Would you care to
describe it further/differently?
/ Sebastian
PS. Sorry for possibly breaking the mail-thread but I was not
subscribed when the original reply was posted.
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
