sdhci: Refactor the generic FDT driver

[bnovkov]

Summary

This patch refactors the 'sdhci_fdt.c' driver by moving all vendor
specific routines into separate files and making the base 'sdhci_fdt'
driver subclassable. The goal is to make adding new FDT-based drivers
easier and more maintainable. No functional change intended.

Test Plan

The refactored module builds for the armv7 and riscv64 targets.
I tested the changes on a Milk-V Duo S board and found no issues.

[manu]

sys/arm/mv/files.arm7

19 ↗

(On Diff #149562)

Mhm, isn't sdhci_fdt.c also needed ?

sys/dev/sdhci/sdhci_fdt_rockchip.c

5

Thomas likely did the xilinx part, but not the rockchip one.

113

This is xilinx and not rockchip.

[manu]

sys/dev/sdhci/sdhci_fdt_rockchip.c

6

Also mav@ likely didn't do the rockchip part, I think that rockchip code was me, ganbold@ and probably some others.

[imp]

Generally, this is good, though I +1 the comments that manu@ made

sys/dev/sdhci/sdhci_fdt.c

77–78

why do these remain?
Also, these tables should all have the FDT PNP decoration so we can dynamically load this in the future, here and elsewhere.
Not a new bug, per se, but something to take care of perhaps in a separate revirew.

374

This also defers setting certain attributes to attach.
This is a good change in my view, and is unlikely to have any reasonable observable effect.

[manu]

sys/dev/sdhci/sdhci_fdt.c

77–78

I think that's ok to have compatible that do not require custom clock/blah/whatever methods in the main driver, but we should probably move the quirks that they have in the ofw_compat_data (this can be done in a later commit).

[bnovkov]

Address @manu 's comments:

• Correct copyright lines
• Add missing sdhci_fdt.c to build

[bnovkov]

sys/arm/mv/files.arm7

19 ↗

(On Diff #149562)

Right, added it back in.

sys/dev/sdhci/sdhci_fdt.c

77–78

yeah, that was I was thinking as well, if a device doesn't need custom methods it stays here.

sys/dev/sdhci/sdhci_fdt_rockchip.c

6

I've added you and ganbold@ here, please let me know if the dates are okay.

113

Right, however I kept this here because I wanted avoid splitting out duplicated code since this device shares most of its init code in the attach method with rk3399.
Those init methods seem to specific to be split out into sdhci_fdt.c, and copying them into a sdhci_fdt_xilinx.c felt redundant.
What do you think is the best move here?

[manu]

sys/arm/mv/files.arm7

19 ↗

(On Diff #149562)

Didn't realized that it was mv/files.arm7, sdhci_fdt_rockchip.c should be added in sys/arm/rockchip/files.rk32xx

sys/dev/sdhci/sdhci_fdt_rockchip.c

6

Looking at some git blame it seems that @ganbold aded rk3399 support in b24594e544c20 @sos added support for rk3568 in e00774a917503 and I added support for zynqmp in b426119a45d09.
You can also remove the All right reserved.

113

I think that a few routines should still lives in sdhci_fdt.c :
sdhci_clock_ofw_map
sdhci_export_clocks
sdhci_init_clocks
sdhci_init_phy
sdhci_get_syscon

Those are really generic method for any properly supported hardware, and for now only rockchip and zynqmp are properly supported (in term of fdt bindings).

[bnovkov]

Address @manu 's comments:

• Correct authorship info
• Split out xilinx-specific code into a separate file
• Move several generic reoutines into sdhci_fdt.c

[manu]

sys/arm/xilinx/files.zynq7

17 ↗

(On Diff #149961)

xlnx,zy7_sdhci is the one for armv7 xilinx and it's in the sdhci_fdt.c file so no need for this file on armv7.
However it should be added in files.arm64 for ZynqMP

[bnovkov]

Add the sdhci_fdt_xilinx.c to the aarch64 build files.

[bnovkov]

sys/arm/xilinx/files.zynq7

17 ↗

(On Diff #149961)

thanks, I've moved it to files.arm64.

[manu]

One last thing I haven't spotted before, we need the _rockhip.c file in files.arm64 too, it should depend on SOC_ROCKCHIP.
Then we will be good to have this commited :)

[bnovkov]

Address @manu 's comments - include sdhci_fdt_rockchip.c in files.arm64.

[manu]

sys/conf/files.arm64

440

This should be 'optional sdhci fdt soc_rockchip' so it will be included for all rockchip SoCs

[bnovkov]

Address @manu 's comments.