Thread (13 messages) 13 messages, 6 authors, 2016-12-01

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help