On 10 March 2017 at 14:24, Jan Glauber <[email protected]> wrote:
> Add description of Cavium Octeon and ThunderX SOC device tree bindings.
>
> CC: Ulf Hansson <[email protected]>
> CC: Rob Herring <[email protected]>
> CC: Mark Rutland <[email protected]>
> CC: [email protected]
>
> Signed-off-by: Jan Glauber <[email protected]>
> Signed-off-by: David Daney <[email protected]>
> Signed-off-by: Steven J. Hill <[email protected]>
> Acked-by: Rob Herring <[email protected]>
> ---
> .../devicetree/bindings/mmc/cavium-mmc.txt | 58
> ++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/cavium-mmc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/cavium-mmc.txt
> b/Documentation/devicetree/bindings/mmc/cavium-mmc.txt
> new file mode 100644
> index 0000000..225c2be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/cavium-mmc.txt
> @@ -0,0 +1,58 @@
> +* Cavium Octeon & ThunderX MMC controller
> +
> +The highspeed MMC host controller on Caviums SoCs provides an interface
> +for MMC and SD types of memory cards.
> +
> +Supported maximum speeds are the ones of the eMMC standard 4.41 as well
> +as the speed of SD standard 4.0. Only 3.3 Volt is supported.
> +
> +Required properties:
> + - compatible : should be one of:
> + cavium,octeon-6130-mmc
> + cavium,octeon-6130-mmc-slot
> + cavium,octeon-7890-mmc
> + cavium,octeon-7890-mmc-slot
> + cavium,thunder-8190-mmc
> + cavium,thunder-8190-mmc-slot
> + cavium,thunder-8390-mmc
> + cavium,thunder-8390-mmc-slot
> + - reg : mmc controller base registers
> + - clocks : phandle
> +
> +Optional properties:
> + - for cd, bus-width and additional generic mmc parameters
> + please refer to mmc.txt within this directory
> + - cavium,cmd-clk-skew : number of coprocessor clocks before sampling command
> + - cavium,dat-clk-skew : number of coprocessor clocks before sampling data
> +
> +Deprecated properties:
> +- spi-max-frequency : use max-frequency instead
> +- cavium,bus-max-width : use bus-width instead
> +
> +Examples:
> + mmc_1_4: mmc@1,4 {
> + compatible = "cavium,thunder-8390-mmc";
> + reg = <0x0c00 0 0 0 0>; /* DEVFN = 0x0c (1:4) */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&sclk>;
> +
> + mmc-slot@0 {
> + compatible = "cavium,thunder-8390-mmc-slot";
> + reg = <0>;
Just realized that I forgotten to follow up about the details for I
think we should generally describe slots nodes in DT.
Currently we treat a child node of a host device node, with reg=0 as
being an embedded mmc card [1] (in case it has the "mmc-card"
compatible set).
When reg is 1->7, those are reserved for SDIO function nodes [2] (as
those can be exactly 7, according to the SDIO spec).
Let's take the above into account and consider that a slot node may
also require a its own child node as to describe an embedded mmc card
or SDIO funcs. In this context I don't think it makes sense to use SoC
specific compatibles for slot nodes, instead I suggest we use only
"mmc-slot".
Does that makes sense?
> + vmmc-supply = <&mmc_supply_3v3>;
> + max-frequency = <42000000>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + };
> +
> + mmc-slot@1 {
> + compatible = "cavium,thunder-8390-mmc-slot";
> + reg = <1>;
> + vmmc-supply = <&mmc_supply_3v3>;
> + max-frequency = <42000000>;
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + non-removable;
> + };
> + };
> --
> 2.9.0.rc0.21.g7777322
>
Kind regards
Uffe
