Add driver for Rockchip RK3399 eMMC PHY.
Tested on NanoPC-T4 board.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 25365
Event Timeline
Comment Actions
Updated, once clock is enabled in sdhci_fdt, rk_emmcphy_init(void) can be called again to get the clock, etc.
| sys/arm64/rockchip/rk3399_emmcphy.c | ||
|---|---|---|
| 215 | This should be the phy_init method, then sdhci can just call phy_init(sc->phy); | |
| sys/arm64/rockchip/rk3399_emmcphy.c | ||
|---|---|---|
| 120 | This doesn't need to be a global variable now. | |
| 144 | You should validate that the phy id is correct by using phynode_get_id | |
| 146 | This is not correct, this function is suppose to disable the phy by writing to the registers. | |
| 236 | Can you do a smaller delay value and use a loop for the timeout ? | |
Comment Actions
Global variable is removed.
Phy id is validated after getting id by phynode_get_id().
When enable var is false it will disable the phy.
Looked both NetBSD and linux sources for delay value:
https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/rockchip/rk_emmcphy.c#L207
https://elixir.bootlin.com/linux/v5.2-rc7/source/drivers/phy/rockchip/phy-rockchip-emmc.c#L204
Rockchip RK3399 TRM V1.3 Part2.pdf says in page 698:
After the DLL control loop reaches steady state a DLL ready signal is generated by the DLL circuits ‘phyctrl_dllrdy’. The time from ‘phyctrl_endll’ to DLL ready signal ‘phyctrl_dllrdy’ varies with the clock frequency. At 200MHz clock frequency the DLL ready delay is 2.56us, at 100MHz clock frequency the DLL ready delay is 5.112us and at 50 MHz clock frequency the DLL ready delay is 10.231us.
Comment Actions
Correct the class name when creating phynode, otherwise rk_emmcphy_enable() is never called.
| sys/arm64/rockchip/rk3399_emmcphy.c | ||
|---|---|---|
| 236 | Why not waiting the correct amount of time based on the frequency ? | |
Comment Actions
Tried with smaller wait values per frequency respectively.
However it is not working. So added more comments in the code
describing why more safer value would work in any case.