While the xin32k clk was implemented in rk3399_cru as a fixed rate
clock, migrate it to rk805 as we will also need the 2nd clock
'rtc_clko_wifi' for SDIO and BT.
Both clocks remain fixed rate, and while the 1st one is always on
(though that is not expressed in the clk framework), the 2nd one
we can toggle on/off.
Details
- Reviewers
mmel manu - Commits
- rGf0a5e81af436: arm64: rockchip, implement the two rk805/808 clocks
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/arm64/rockchip/rk805.c | ||
---|---|---|
643 | You should be able to subclass the first clock def no ? | |
666 | No need for this comment. | |
669 | RK808 datasheet name this clock clk32kout1 | |
669 | clock-output-names could have only one clock, we should always use the name if provided. | |
681 | RK808 datasheet name this clock clk32kout2 | |
866 | Looking at the rk805 datasheet it seems that it have the same clocks, we should always export them unconditionally. | |
869 | We should fail here, if the xin32k clock isn't exported not a lot of thing would work (and we would panic later when we finish the clock domains I think anyway). |
sys/arm64/rockchip/rk805.c | ||
---|---|---|
669 | Can we always rely on the DTS to get this one right. Is we don't have an "xin32k" more things get cranky. That's the reason I did in the end not name it clk32kout1. We never did in rk3399_cru.c either; so there is some inconsistency somewhere? |
sys/arm64/rockchip/rk805.c | ||
---|---|---|
669 | Yes we should rely on it. |
We should. I am happy to update it the next days or if you want let me know and feel free to and just update this review.
Replace the rk808 by rk805 for anything related to clocks.
Remove (void) to document that we are ignoring function resulats.
Use the decided clock name in printf.
Suggested-by: mnau
Not tested yet but needs at least : https://github.com/evadot/freebsd/commit/a067e396aaec9e93d6294f530da695f53b2851e8
This is now tested, the 32khz clock is correctly output on the pin when enabling the clock.
Thanks for updating and testing! I am currently trying to get my rk3399s stable again as recent U-Boot + FreeBSD make them entirely unhappy. I believe it's LPDDR3 related as only nanopi4 derived ones (and a chromebook seem to use this kind of memory; and they updated the chips between 2018 and 2019 designs). I found vendor pre-compiled Android to be stable while on FreeBSD I get a lot of data corruption.
I'll update the change later today and then commit; or you could just go ahead and commit given you have the final version.