<dsimic>
as visible above, the infrastructure for having TF-A perform GPIO-based resets is already in place, so I'll investigate it further, to see would that be the right place to (ab)use the TSADC for restarting
<dsimic>
I'm also writing a response to Kever on the U-Boot ML
<qschulz>
dsimic: we discussed that already with paulk a few days ago
<qschulz>
dsimic: this feels very much like a hack
<qschulz>
also, no data is actually passed to TF-A by default for all RK3399 boards (except Puma)
<qschulz>
but TF-A needs the information of which GPIO to use
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
except that if you want users to be able to use Rockchip's blob, you need to NOT pass any info to it
<qschulz>
also, whatever you'll be doing for RK3399 wouldn't work on any other SoC
<dsimic>
ah, thanks, I remember that discussion now... back then I only glanced over it
<dsimic>
yes, TF-A has no clue about that GPIO, for example
<qschulz>
but maybe that's less of a hack than trying to get the tsadc to act as a reset controller
<qschulz>
TF-A won't know by itself, it needs to be provided with that information
<dsimic>
I'm thinking the same, which one is less hacky
<qschulz>
also
<qschulz>
this means you won't be able to use this reset GPIO for resetting the whole system before TF-A has been loaded
<qschulz>
which means essentially once you reach proper
<dsimic>
what's the deal with the blob and passing anything to it?
<qschulz>
TF-A <v2.3 has a nasty bug that results in crashing depending on some factors
<qschulz>
and guess which version is used by Rockchip
<qschulz>
e6fa0dcc6f3fc44b1bc08fd5d921c5ad95163a69 for the commit with explanations
<qschulz>
actually <v2.4
<dsimic>
ah, sure, (ab)using the TSADC/OTP in TF-A would be for the use with kernel only, and for manual resets in the U-Boot proper, meaning that sysreset-gpio would still be needed for early resets in U-Boot
<qschulz>
This applies to ALL Rockchip SoCs, not only RK3399 BTW since they use the same ancient version for all SoCs
<qschulz>
dsimic: we don't do anything with the sysreset-gpio outside of this TPL reset on warm boots
<qschulz>
meaning calling `reset` will enter this logic on next boot
<qschulz>
instead of doing it cleanly directly
<qschulz>
which is fine, just not optimal :)
<dsimic>
huh, so we basically can't pass anything to TF-A, because that would break the blobs :/
<dsimic>
sure, sysreset-gpio is to be used for what I referred to as early resets in U-Boot, i.e. what's happening in arch/arm/mach-rockchip/rk3399/rk3399.c
<dsimic>
hmm, I'll think more about it, but so far it seems that the reset-controller is actually a viable hack :)
<naoki>
current rock-5a.dts is very different to schematic...
<naoki>
"arm64: dts: rockchip: refine dts for Radxa ROCK 5A" is, in short, "sync with rock-5c.dts"
<mmind00>
naoki: please don't do patches that address multiple things ... "refine X" is way to broad, and looking at the change in the patch, this definitly needs to be split
System_Error has joined #linux-rockchip
<naoki>
many many things need to be fixed :(
<mmind00>
naoki: yes, but in separate patches please
<naoki>
I cannot imagine how many commits are required for them
<naoki>
I see...
<mmind00>
naoki: (1) Match regulator structure and names to schematics
<mmind00>
(3) Fix gmac1 clock and supply
<mmind00>
(2) Match node names
<mmind00>
(5) add RTC
<mmind00>
(4) move eeprom to correct i2c controller
<mmind00>
at least ... from a cursory glance
<mmind00>
same for the "fix dts for rock5c" ... I see regulators, pcie, gmac, usbdp lane-mux ... in there
<naoki>
mmind00: yeah... I'll try to fix them
<mmind00>
also why the switch from rgmii-id back to rgmii? ... rgmii-id is the preferred form if it works
<naoki>
hmm
<naoki>
that is something I was worried about too
<naoki>
this time I refer vendor kernel, but rgmii-id may be better... I'll check both 5a and 5c
<naoki>
(btw basically rock 5c is modified version of rock 5a)
<naoki>
btw I'm thinking rk3588-rock-5.dtsi for 5B and brothers (maybe 5 ITX too?)