I am in the process of adding an ACPI Device Property to specify the driver strength (aka drive strength, driver type) for use with eMMC/SD/SDIO cards, however the ACPI Specification Workgroup requires that Device Properties be sufficiently generic. This raises several questions as to what is sufficiently generic. That is covered in a Questions section below and is followed by a draft ACPI Device Property Definition. Any comments would be greatly appreciated. First some background: What are ACPI Device Properties and how do they relate to Device Tree --------------------------------------------------------------------- ACPI Device Properties are key / value pairs that can be recorded in the ACPI DSDT using a _DSD object with a specific UUID. Refer: The ACPI specification and http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf http://www.uefi.org/sites/default/files/resources/web-page-v2.pdf Linux provides a common API to read ACPI Device Properties and Device Tree properties. Refer: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c http://marc.info/?l=linux-kernel&m=141354745011569&w=4 Obviously, the common API only works when the same property name is not defined differently for the same device or class of devices. What is Driver Strength ----------------------- Both the JEDEC eMMC Specification and the SD Association Physical Layer Specification define Driver Strength. The specifications also use the terms Drive Strength and Driver Type for the same thing. While the specifications deal with cards, the Host Controller can also have a Driver Strength value, for example as specified in the SD Host Controller Specification. For eMMC, Driver Strength is an optional setting for the HS200 and HS400 transfer modes. Currently JEDEC defines: Value Nominal Impedance Approx. capability relative to type 0 0 50 ohm x1 1 33 ohm x1.5 2 66 ohm x0.75 3 100 ohm x0.5 4 40 ohm x1.2 For SD/SDIO, Driver Strength is an optional setting for the UHS-I transfer modes. The SD Association defines: Driver Value Nominal Impedance Approx. capability Type relative to type 0 A 1 33 ohm x1.5 B 0 50 ohm x1 C 2 66 ohm x0.75 D 3 100 ohm x0.5 So the values are the same with the exception that eMMCs have the additional value 4 (40 ohm). It is assumed that the values will anyway not conflict because eMMC is not removable. The specifications state that support for Driver Strength 0 (Driver Type B) is both mandatory and the default value. In addition, cards supply a mask of supported Driver Strength values. Therefore the Driver Strength value is validated against the supported values. Questions --------- Question 1. Should there be separate Driver Strength values for cards and host controllers? There is no indication from the specifications that cards and host controllers need have the same value for Driver Strength. That suggests that separate properties for the card and host controller should be provided for. Originally, I was just proposing "driver-strength" for the Driver Strength of the card, but now will separate this into "card-driver-strength" and "host-driver-strength". Question 2. To what devices should the Driver Strength properties bind? A Driver Strength property for the host controller obviously binds to the host controller device. Additionally it can be assumed that Driver Strength is a property of the board (e.g. a stronger Driver Strength needed because the eMMC is located further from the host controller), consequently even the Driver Strength property for the card should bind against the host controller. Question 3. Should there be separate Driver Strength values for different transfer modes? Different transfer modes can have different timing requirements which implies that there can be different Driver Strength values for each transfer mode. To support that, there would need to be either separate properties for each mode, or more simply two properties that list associated transfer modes and Driver Strengths. Transfer modes are not codified but have standard names that could be used e.g. "HS400" or "SDR104" Question 4. Should there be separate Driver Strength values for different frequencies? To be generic, another property would be needed to specify the frequency from which the Driver Strength is needed. Question 5. Should there be separate Driver Strength values for different voltages? UHS-I modes all have the same signal voltage (1.8V) however HS200 and HS400 support both 1.2V and 1.8V. That could be handled by having having different mode strings for the variants. i.e. "HS200", "HS200-1.2V", "HS200-1.8V", "HS400", "HS400-1.2V", 'HS400-1.8V" Question 6. Should there be separate Driver Strength values for different slots? In order to support multiple slots, the slot number can be appended to the property names to define a separate set of properties for each slot. Question 7. Should the possibility of multiple cards in the same slot be supported? Linux does not support having multiple cards in the same slot. Presumably, the Driver Strength for each card would bind to the card device, which would require defining how card devices are identified. That might be possible, but it is out of scope. ACPI Device Property definitions: --------------------------------- Based on my answers to the questions, the ACPI Device Property definitions would look like this: The following Device Properties are for general use with any eMMC, SD card, or SDIO host controller. --------------------------------------------------------------------------- Property: card-driver-strength-0 Value: Package of Integers Description: If present, defines a list of the driver strength values for a card in slot 0. The driver strength is an optional setting defined by the JEDEC eMMC specification or the SD Association Physical Layer specification, for use with HS200/HS400 or UHS-I transfer modes. In absence of this property, the default value of 0 is used. Example values: Value Nominal Impedance Approx. capability relative to type 0 0 50 ohm x1 1 33 ohm x1.5 2 66 ohm x0.75 3 100 ohm x0.5 4 40 ohm x1.2 The driver strength values associate one-to-one with the values of properties card-driver-strength-mode-0 and card-driver-strength-freq-0. Transfer modes or frequencies not specified will have the default driver strength of 0. Neither card-driver-strength-mode-0 nor card-driver-strength-freq-0 need be present in which case there must be only one driver strength value which will be used with all relevant transfer modes and frequencies. For host controllers that define multiple slots, the value applies to the first slot (slot 0), and each subsequent slot requires another property of the form card-driver-strength-n when n is the slot number (e.g. for the 2nd slot card-driver-strength-1) Example for a single slot host controller with a single value: Package (2) { "card-driver-strength-0", Package (1) { 1 } } Example for a multiple slot host controller with 3 slots all with a single value: Package (2) { "card-driver-strength-0", Package (1) { 1 } } Package (2) { "card-driver-strength-1", Package (1) { 3 } } Package (2) { "card-driver-strength-2", Package (1) { 0 } } --------------------------------------------------------------------------- Property: card-driver-strength-mode-0 Value: Package of Strings Description: If present, defines the transfer modes to which the values of card-driver-strength-0 apply. The transfer modes are identified by name and where necessary voltage. i.e. eMMC transfer modes: "HS200", "HS200-1.2V", "HS200-1.8V", "HS400", "HS400-1.2V", "HS400-1.8V", UHS-I transfer modes: "SDR12", "SDR25", "SDR50", "SDR104", "DDR50", The empty string ("") can be used to mean all modes not otherwise specified. The names of new modes should be inferred from the relevant specifications. Example for a single slot host controller with a single value for HS400 mode: Package (2) { "card-driver-strength-0", Package (1) { 1 } } Package (2) { "card-driver-strength-mode-0", Package (1) { "HS400" } } --------------------------------------------------------------------------- Property: card-driver-strength-freq-0 Value: Package of Integers Description: If present, defines the starting frequencies to which the values of card-driver-strength-0 apply. The frequency is in Hz. Example for a single slot host controller with Driver Strength 4 for HS400 starting at 50MHz changing to Driver Strength 1 at 100MHz. Package (2) { "card-driver-strength-0", Package (1) { 4, 1 } } Package (2) { "card-driver-strength-mode-0", Package (1) { "HS400", "HS400" } } Package (2) { "card-driver-strength-freq-0", Package (1) { 50000000, 100000000 } } --------------------------------------------------------------------------- Property: host-driver-strength-0 Value: Package of Integers Description: Same as card-driver-strength-0 but values are used for the host controller not the card. --------------------------------------------------------------------------- Property: host-driver-strength-mode-0 Value: Package of Strings Description: Same as card-driver-strength-mode-0 but values are used for the host controller not the card. --------------------------------------------------------------------------- Property: host-driver-strength-freq-0 Value: Package of Integers Same as card-driver-strength-freq-0 but values are used for the host controller not the card. Regards Adrian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
