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
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].
Regards,
Arend
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Feb 16, 2015, at 5:39 PM, Arend van Spriel <[email protected]> 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].
>
> 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.
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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
On 16/02/2015 7:47 p.m., Philip Rakity wrote:
>
> On Feb 16, 2015, at 5:39 PM, Arend van Spriel <[email protected]> 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.
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 [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
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 <[email protected]> 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 [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>