UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt

78 lines
3.1 KiB
Plaintext
Raw Normal View History

mmc: arasan: Add driver for Arasan SDHCI Add a driver for Arasan's SDHCI controller core. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Rob Herring <rob.herring@calxeda.com> [binding] Acked-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Chris Ball <chris@printf.net>
2013-12-03 02:02:36 +08:00
Device Tree Bindings for the Arasan SDHCI Controller
Documentation: bindings: add description of phy for sdhci-of-arasan This patch adds phys and phy-names for sdhci-of-arasan as required properties for arasan,sdhci-5.1, and details the example as well. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-03-07 23:38:42 +08:00
The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
Only deviations are documented here.
mmc: arasan: Add driver for Arasan SDHCI Add a driver for Arasan's SDHCI controller core. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Rob Herring <rob.herring@calxeda.com> [binding] Acked-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Chris Ball <chris@printf.net>
2013-12-03 02:02:36 +08:00
[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Documentation: bindings: add description of phy for sdhci-of-arasan This patch adds phys and phy-names for sdhci-of-arasan as required properties for arasan,sdhci-5.1, and details the example as well. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-03-07 23:38:42 +08:00
[4] Documentation/devicetree/bindings/phy/phy-bindings.txt
mmc: arasan: Add driver for Arasan SDHCI Add a driver for Arasan's SDHCI controller core. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Rob Herring <rob.herring@calxeda.com> [binding] Acked-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Chris Ball <chris@printf.net>
2013-12-03 02:02:36 +08:00
Required Properties:
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
- compatible: Compatibility string. One of:
- "arasan,sdhci-8.9a": generic Arasan SDHCI 8.9a PHY
- "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY
- "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
- "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY
For this device it is strongly suggested to include arasan,soc-ctl-syscon.
mmc: arasan: Add driver for Arasan SDHCI Add a driver for Arasan's SDHCI controller core. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Rob Herring <rob.herring@calxeda.com> [binding] Acked-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Chris Ball <chris@printf.net>
2013-12-03 02:02:36 +08:00
- reg: From mmc bindings: Register location and length.
- clocks: From clock bindings: Handles to clock inputs.
- clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
- interrupts: Interrupt specifier
Documentation: bindings: add description of phy for sdhci-of-arasan This patch adds phys and phy-names for sdhci-of-arasan as required properties for arasan,sdhci-5.1, and details the example as well. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-03-07 23:38:42 +08:00
Required Properties for "arasan,sdhci-5.1":
- phys: From PHY bindings: Phandle for the Generic PHY for arasan.
- phy-names: MUST be "phy_arasan".
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
Optional Properties:
- arasan,soc-ctl-syscon: A phandle to a syscon device (see ../mfd/syscon.txt)
used to access core corecfg registers. Offsets of registers in this
syscon are determined based on the main compatible string for the device.
Documentation: mmc: sdhci-of-arasan: Add ability to export card clock Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export the SDHCI card clock using a standard device tree mechanism so that the PHY can get access to it and query the card clock frequency. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:49 +08:00
- clock-output-names: If specified, this will be the name of the card clock
which will be exposed by this device. Required if #clock-cells is
specified.
- #clock-cells: If specified this should be the value <0>. With this property
in place we will export a clock representing the Card Clock. This clock
is expected to be consumed by our PHY. You must also specify
dt: sdhci-of-arasan: Add device tree option xlnx, fails-without-test-cd The sdhci controller on xilinx zynq devices will not function unless the CD bit is provided. http://www.xilinx.com/support/answers/61064.html In cases where it is impossible to provide the CD bit in hardware, setting the controller to test mode and then setting inserted to true will get the controller to function without the CD bit. The device property "xlnx,fails-without-test-cd" will let the arasan driver know the controller does not have the CD line wired and that the controller does not function without it. Signed-off-by: Zach Brown <zach.brown@ni.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-09-16 23:01:41 +08:00
- xlnx,fails-without-test-cd: when present, the controller doesn't work when
the CD line is not connected properly, and the line is not connected
properly. Test mode can be used to force the controller to function.
dt-bindings: mmc: broken clock stable indicator on arasan controllers Some controllers immediately report that their internal clock is stable after activating it even when the clock is not stable. When used in conjunction with older/slower cards, this can result in: mmc0: error -84 whilst initialising SD card This flag allows documenting and thus working around such a hardware defect. Signed-off-by: Helmut Grohne <h.grohne@intenta.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-06-20 19:32:51 +08:00
- xlnx,int-clock-stable-broken: when present, the controller always reports
that the internal clock is stable even when it is not.
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
mmc: arasan: Add driver for Arasan SDHCI Add a driver for Arasan's SDHCI controller core. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Rob Herring <rob.herring@calxeda.com> [binding] Acked-by: Michal Simek <monstr@monstr.eu> Signed-off-by: Chris Ball <chris@printf.net>
2013-12-03 02:02:36 +08:00
Example:
sdhci@e0100000 {
compatible = "arasan,sdhci-8.9a";
reg = <0xe0100000 0x1000>;
clock-names = "clk_xin", "clk_ahb";
clocks = <&clkc 21>, <&clkc 32>;
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
} ;
Documentation: bindings: add description of phy for sdhci-of-arasan This patch adds phys and phy-names for sdhci-of-arasan as required properties for arasan,sdhci-5.1, and details the example as well. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-03-07 23:38:42 +08:00
sdhci@e2800000 {
compatible = "arasan,sdhci-5.1";
reg = <0xe2800000 0x1000>;
clock-names = "clk_xin", "clk_ahb";
clocks = <&cru 8>, <&cru 18>;
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
} ;
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
sdhci: sdhci@fe330000 {
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
reg = <0x0 0xfe330000 0x0 0x10000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>;
clock-names = "clk_xin", "clk_ahb";
arasan,soc-ctl-syscon = <&grf>;
assigned-clocks = <&cru SCLK_EMMC>;
assigned-clock-rates = <200000000>;
Documentation: mmc: sdhci-of-arasan: Add ability to export card clock Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export the SDHCI card clock using a standard device tree mechanism so that the PHY can get access to it and query the card clock frequency. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:49 +08:00
clock-output-names = "emmc_cardclock";
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
phys = <&emmc_phy>;
phy-names = "phy_arasan";
Documentation: mmc: sdhci-of-arasan: Add ability to export card clock Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export the SDHCI card clock using a standard device tree mechanism so that the PHY can get access to it and query the card clock frequency. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:49 +08:00
#clock-cells = <0>;
Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-06-21 01:56:46 +08:00
};