Re: mmc: Driver Strength Device Property
From: Arend van Spriel
Date: Mon Feb 16 2015 - 18:02:37 EST
On 02/16/15 22:47, Adrian Hunter wrote:
On 16/02/2015 7:47 p.m., Philip Rakity wrote:
On Feb 16, 2015, at 5:39 PM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote:
On 02/16/15 15:25, Adrian Hunter wrote:
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".
Hi Adrian,
I am not sure if it makes sense to have a 'card-driver-strength'
specification for the host controller. I have been under the
impression that the proper value for this is strongly depending
on the card used in the slot. For this reason and the fact that
it is programmed in our device we added brcm,drive-strength
property in our device-tree bindings [1].
So brcm,drive-strength is "drive strength used for SDIO pins on device
in mA
(default = 6)" and it is written to a brcm register rather than the SDIO
CCCR Driver Strength register. So it is not in conflict, but an example of
a hardware-specific way of doing things.
I agree when you have a brcm value to write to a brcm register, it makes
sense to bind it to the brcm device.
Glad to hear. I guess I was wondering how the card-driver-strength
property would be used and by what entity, but that is not directly
relevant for having a definition for it in ACPI/devicetree.
Regards,
Arend
One problem with having the standard property bind to the card is that
removable cards are not usually represented.
Regards,
Arend
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
Adrian, Arend,
My experience is that the value also depends very much on the board
design as well as the eMMC/sdio chip being used. eMMC chips have
some variation. A DT entry does make sense for eMMC and other wired in
devices but in this case the value is a property of the hardware
and "burnt in" as a property of the board design.
So it sounds like binding to the host controller would be OK.
regards,
Philip
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
linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/