Support for EMMC 4.5 and UFS
Discuss support for EMM4.5 specification
Etherpad @ http://
Blueprint information
- Status:
- Started
- Approver:
- Deepak Saxena
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Venkatraman S
- Definition:
- Approved
- Series goal:
- Accepted for kernel-merge-window
- Implementation:
-
Blocked
- Milestone target:
-
backlog
- Started by
- Venkatraman S
- Completed by
Whiteboard
Meta:
Headline: eMMC4.5 compliant cards work with Linux Kernel and exploit the card specific features. UFS storage devices are functional
Acceptance: Test that each feature listed below is exercised correctly, if it is supported by the storage device
Roadmap id: CARD-143
[jakub-pavelek 2012-10-17] Turned the dependecies around, now should show proper graph. This is understood as a meta-blueprint and thus will be finished when all dependencies are implemented. This is marked as BLOCKED because we do not have anyone working on child blueprints.
[jakub-pavelek 2012-11-09] Unblocking, children scheduled for 12.11
[jakub-pavelek 2013-01-02] Blocked, no developer. Can go deferred if not resolved
[jakub-pavelek 2013-02-26] Backlogged
=======
Information:-
eMMC4.5 features upstream status
1. eMMC HPI send command: Jaehoon Chung: 3.2
2. Power Class selection feature: Girish KS: 3.2
3. Power Off Notify: Girish KS: 3.2
4. Sanitize: Kyungmin Park: 3.2
5. Discard: Kyungming Park: 3.2
6. Cache Control: Seungwon Jeon: 3.2
7. eMMC Data Tag feature: Saugata Das: 3.3
=======
Support for eMMC4.5 discussion agenda for Q4 2011 Linaro Connect
HS200
Packed CMD
Discard
Sanitize
Power-off Notification
HPI
Cache
Background operation
Data Tag
Context ID
Real Time Clock information
=======
Work yet to be done (as of 1st April 2012)
1. Power Off Notify improvements :
If card is powered down in other situations (idle, system suspend), need to use POWER_OFF_SHORT, else POWER_OFF_LONG can be used.
Need to rework what is actually upstream. Patch posted to mmc mailing list.
http://
u-boot requirements / Enabling of boot partition
eMMC Feature: Jedec section 6.3.3 / 6.3.4
Boot operation:-
If the CMD line is held low by the host for >74 clock cycles after power cycling the device, the device will directly start sending out the contents of the 'boot' partition, without the host requiring to send any read command.
Alternate Boot operation:-
If the CMD line is held low by the host for >74 clock cycles, AND sends a CMD0 with 0xFFFFFFFA as argument, the boot mode is in operation and the device will directly start sending out the contents of the 'boot' partition, without the host requiring to send any command
Implementation needs:-
1:- The minimal boot loader (SPL) is modified to reset the eMMC device at power on and set the device to 'boot' mode, receive the data (in this case, the Kernel image) to RAM and jump to the start address. u-boot will not be needed
2:- Kernel needs to be updated to handle special cases (update the Boot partition for replacing the OS) [OTA upgrade for phones ?]
Discuss:-
Potential use cases for this feature. This is mostly SoC dependant. For example, OMAP4 does not support eMMC boot mode. (It is still possible to implement option 1 above)
HS200:-5.4.1
Its High Speed Mode (200MHz) and is a controller capability. Tuning feature is interesting and needs hardware support. Best left to SoC maintainers.
Data Tag:- 6.6.25
Basic MMC feature is completed and merged into 3.4-rc1
Note: ext4 file system does not set the REQ_META flag. Patch has been posted in March 2012 to
ext4 mailing list to set the flag. (Saugata Das)
==Already upstream
Cache:-6.6.28
Acts like a typical CPU cache. Transparent to the driver software (cache is not addressable), but has typical coherency implications.
Need to flush the cache explicitly, if reliability is required.
1) Periodically
2) On REQ_FLUSH
3) On suspend and idle path
Data Tag:-
Basic support is already upstream.
Real time Clock:-6.6.31
This feature requires to send periodic elapsed time or absolute time information to be sent to the card, as FYI. This needs to be sent periodically, a period determined by the host.
Context-ID:6.6.24
Context-ID is like a session identifier to be passed to the device. This lets the device to optimize. A context ID can be set as read only / write only / read-write. The default context '0' is read-write.
In order to effectively use this feature, some implementation details from device manufacturers on how the context-ID helps to improve speed/reliability is needed.
The patch mentioned above uses the PID of the process associated with the CFQ-queue as a context id. Since the CID in CMD23 is only 4 bits, the mapping might not make sense.
The option for setting 'large context' is to be discussed along with packed CMD feature - see below.
Packed CMD:-6.6.26
Packed command is grouping of a set of Reads or Writes. For example, if 10 write requests are to be executed, send a 'pack' command containing the header information of all the 10 requests in one command (just the metadata), then send a write command to slurp all the data.
Patches are in review in mmc mailing list.
http://
HPI:-6.6.23
See https:/
=======
General Notes:-
Several patches have already been posted for some of the low-hanging features.
Need to bring in all the maintenance commands (BKOPS, SANITIZE, RTC, CACHE_FLUSH) into a common framework. Currently, all the maintenance commands are invoked in the hot path. A better approach would be to run a 'mmc_maintenance' timer after processing transactions. After the expiry of timer, invoke the above said commands in order.
Packed-CMD and large-context writes require a better interface to elevator, to look at multiple requests at a time.
=======
Work Items
Work items for 12.08:
[svenkatr] Track the MMC upstream status (see below): INPROGRESS
[svenkatr] Carve out separate BP for UFS and list down the validation requirements: TODO
[svenkatr] Study the blk-tag feature and check if this can be used for Context-ID: DONE
[svenkatr] Review and Test packed CMD patches: INPROGRESS
[svenkatr] Validate packedCMD feature with 4.5 card, under various workloads: INPROGRESS
[svenkatr] Study if cache usage in eMMC can lead to data loss, if not flushed periodically (need HW that supports this commend): TODO
[svenkatr] Update features progress as of 3.4-rc1: DONE
Work items for 12.09:
[svenkatr] Review upstream submission of BKOPS patch and test in OMAP: DONE
[svenkatr] Review UFS patches which split PCI and non PCI code: DONE
Work items for 12.10:
[svenkatr] Review upstream submission of idle mode BKOPS and test on vendor boards: DONE
[svenkatr] Check if vendors were able to do performance profiling for foreground HPI https:/
[svenkatr] : Follow up and consolidate UFS PCI/non PCI split patches from V.H for 3.8: DONE
Work items for 13.01:
[ulf-hansson] Submit /integrate patches for fixing Power Off Notify issues (Jan 8): DONE
Work items for backlog:
[svenkatr] Review packed command submissions (requires card which implement this feature properly): TODO
[dsaxena-linaro] Assignee to be found for https:/
[svenkatr] Develop RTC information support when card vendor support is available for such feature: TODO
[svenkatr] Resubmit ext4 patches for updating REQ_META flag for Data Tag: TODO
[svenkatr] : Review async request improvement patches from codeaurora: INPROGRESS
[svenkatr] : UFS bug fixes / compile warning fixes as flagged in lkml: INPROGRESS
Dependency tree
* Blueprints in grey have been implemented.
