arasan,sdhci.txt "compatibility" DT binding
From: Sebastian Frias <hidden>
Date: 2016-11-28 16:23:26
Also in:
linux-mmc
On 28/11/16 16:44, Mason wrote:
Hello, @Shawn Lin, could you take a look below and tell me exactly which IP core(s) Rockchip is using in its SoCs? Based on the feedback I received, here is an updated list of compatible strings and controller versions dealt with by the drivers/mmc/host/sdhci-of-arasan.c code. Xilinx Zynq: "SD2.0 / SDIO2.0 / MMC3.31 AHB Host Controller" "arasan,sdhci-8.9a" NB: 8.9a is the documentation revision (dated 2011-10-19) subsequent tweaks labeled 9.0a, 9.1a, 9.2a Xilinx ZynqMP: "SD3.0 / SDIO3.0 / eMMC4.51 AHB Host Controller" "arasan,sdhci-8.9a" NB: using the same compatible string as Zynq Sigma SMP87xx "SD3.0 / SDIO3.0 / eMMC4.4 AHB Host Controller" no compatible string yet, platform-specific init required APM: "SD3.0 / SDIO3.0 / eMMC4.41 AHB Host Controller" "arasan,sdhci-4.9a" NB: 4.9a appears to be the documentation revision no functional diff with "arasan,sdhci-8.9a" Rockchip Exact IP unknown, waiting for Shawn's answer "arasan,sdhci-5.1" NB: 5.1 appears to refer to the eMMC standard supported On a final note, there are many variations of the Arasan IP. I've tracked down at least the following: SD_2.0_SDIO_2.0__MMC_3.31_AHB_Host_Controller.pdf SD_3.0_SDIO_3.0_eMMC_4.41_OCP_Host_Controller.pdf SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf SD_3.0_SDIO_3.0_eMMC_4.51_Host_Controller.pdf SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf SD_4.1_SDIO_4.1_eMMC_4.51_Host_Controller.pdf SD_4.1_SDIO_4.1_eMMC_5.1__Host_Controller.pdf It seems to me the compatible string should specify the SD/SDIO version AND the eMMC version, since it seems many combinations are allowed, e.g. eMMC 4.51 has two possible SD versions. What do you think?
I'm trying to picture this. Imagine:
a) SoC XYZ used two versions:
- SD_3.0_SDIO_3.0_eMMC_4.4__AHB_Host_Controller.pdf
- SD_3.0_SDIO_3.0_eMMC_4.5__Host_Controller.pdf
b) That the compatible suffixes were defined as "sd30-emmc44" and
"sd30-emmc45" respectively
c) That the chip-specific init is the same for both.
What would be the recommended way of dealing with that at DT/driver level?
1) XYZ's DT1: compatible = "arasan,sdhci-sd30-emmc44", "XYZ,sdhci"
DT2: compatible = "arasan,sdhci-sd30-emmc45", "XYZ,sdhci"
driver: match "XYZ,sdhci" for chip-specific init, and then leaves
"arasan,sdhci-sd30-emmc44" or arasan,sdhci-sd30-emmc45" for generic part
2) XYZ's DT1: compatible = "XYZ,arasan-sdhci-sd30-emmc44"
DT2: compatible = "XYZ,arasan-sdhci-sd30-emmc45"
driver: match "XYZ,arasan-sdhci-sd30-emmc44" or "XYZ,arasan-sdhci-sd30-emmc45"
for chip-specific init and generic parts
3) XYZ's DT1: compatible = "arasan,sdhci-sd30-emmc44"
DT2: compatible = "arasan,sdhci-sd30-emmc45"
driver: match "arasan,sdhci-sd30-emmc44" or "arasan,sdhci-sd30-emmc45" for
generic part; chip-specific init done somewhere else (bootloader?)
4) something else?
How would those solutions be affected if condition c) was changed to
"chip-specific init is different for both"?
Regards.