Hello Sergey,
I'm working on the same flow - to reduce read latency hit (as a result
of big aggregated writes). I plan to send all relevant patches to the
mailing list soon and it will be great if you can test them on your system.
There are requirements for this flow is:
- eMMC 4.5 supported by card (this means HPI)
- host controller shoud implement stop request api (that is be able
correctly stop DMA & all internal state and be ready for next read
transaction.
Right now, please look at this patches as reference:
1. [RFC/PATCH 0/2] Handling urgent and new request notifications.
2. [RFC/PATCH 1/2] mmc: Urgent data request flow.
This is old changes, just for the solution overview.
Thanks,
Hi Venkat,
I was looking for some explanations of eMMC behavior in products we are
developing now and found your comments around eMMC here. Our observation
shows
that that eMMC performance vary significantly and depends on volume of
data to
write during time slot and temperature. After a heavy write test was run
for
some time for a good performance eMMC (showing 10-12MB/s of the write
performance on big blocks) its write performance degraded to the 4-5MB/s.
We even observed performance lowest level as 65KB/s!
There are a lot of Write type of operations necessary into dedicated eMMC
partition by requirements.
The side effect is that long write operations block Application UI to
redraw
the views because it requires Read operations.
Visually we see “Blank Dark Screen†for few seconds and even ANRs. So
HMI may
help us.
Question: Did you finish research with HPI to try ? Which type of eMMC
did
you use?
P.S. We use TI BSP for OMAP3630 for Android
--
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
