Hi! > > > 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. > > I believe that the patch properly checks for R1_URGENT_BKOPS, > > which seems correct..? > Right, it checks the R1_URGENT_BKOPS, I mean it called every user > request is finished. Aha, are you referring to the mmc_start_bkops() called from mmc_queue_thread()? If so, I should point to the check for whether BKOPS are _really_ needed, mmc_card_need_bkops(), at the beginning of mmc_start_bkops(). That flag is only set if R1_URGET_BKOPS is asserted by the eMMC device. So even if mmc_start_bkops() is called after every user request that function would just do an early return. One could argue that the call to mmc_card_need_bkops() should be in queue.c, before the call to mmc_start_bkops(). Maybe that is preferable and would have improved readability..? > > > 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? > I refers the JDEDC v4.41 and v4.5 draft version. Ok, then I'm not sure I understand what you are getting at. I tried to look through the chapters for BKOPS but I'm not seeing any descriptive list of solutions concerning HPI & BKOPS? (BTW, it seems as if 4.5 draft is now final -- http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdf) > Actually there's no big issue without HPI. but some case (as above) > has read latency problem esp. when play movie at foreground, but > some background heavy write case. Ok, so what you are looking for is to have BKOPS and HPI in separate patches along with measurements to backup that the HPI really _does_ improve request latency when HPI is used? / Sebastian ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
