patch for sdhci_fdt.c so emmc works on rk356x boards

[titus_edc.ro]

Summary

mostly changed some constants and added uhs timing function (from linux)

Test Plan

tested on orange pi 3b
dts needs disable-wp otherwise the emmc is reported readonly

[manu]

sys/dev/sdhci/sdhci_fdt.c

539

Extra blank line.

687

This will need to go in a separate function like we did for rk3399

728

Extra blank line.

744

Extra blank line.

[manu]

Please upload later diff with full context (git diff -U999 or git-format-patch -U999)

[titus_edc.ro]

fixed extra lines
moved rk35688 clock initialization to separate function

[manu]

Mhm, I'm starting to think that we might want to subclass sdhci_fdt.
Like all IP which are re-used a lot in different SoC there is always some difference between the implementation (mostly clocks/resets for sometimes more).
UHS are likely to be different for each variant of this driver.
I don't want to have a mess in this driver (it's already a bit of a mess).

sys/dev/sdhci/sdhci_fdt.c

582

Extra blank line.

583

What are those magic values ?

587

Extra blank line.

669

Extra blank line.

737–742

Those register likely don't exists on other variant (or at least might not exist), that should be gated based on the compatible.

[titus_edc.ro]

fixed some extra blank lines, added compat guard for vendor specific regs
I cant find the vendor specific regs bits doc again (0x05xx) but im sure ive seen then in some pdf

in linux the vendor register offset is read from yet another register, ours is hardwired to 0x500 so i wanted to check the doc and found them somewhere
it was a bit painful to make it work everything seemed ok but write ops still failed
in the end i dumped all the registers with devmem2 in linux and freebsd and compared them and then i found the diffs in defines etc

[titus_edc.ro]

fixed stupid bug in sdhci_init_rk3568

if(err) {
        device_printf(dev, "cannot enable core clock\n");
        return (err);
}

was missing {}
result was clocks not being enabled

[manu]

Thanks for the update but I still thinks that we should split the driver into multiple file (or per vendor).