<qschulz>
I really am not reading stuff properly today
<qschulz>
so yeah, all correct dsimic
<qschulz>
sorry for the noise
<dsimic>
you're referring to the D18 in the schematic?
<qschulz>
ROC-3399-PC schematics yes
<qschulz>
but it's fine now :)
<dsimic>
ah, good :)
<dsimic>
so, there's no magic or mystery :)
<dsimic>
it's all the abuse of the OTP
<dsimic>
well, (ab)use
<qschulz>
yup
<dsimic>
and I'm afraid there's no better way than to follow that abuse further
<dsimic>
with my earlier plan
<qschulz>
so **technically** GPIOs can be shared between drivers
<dsimic>
I wouldn't mess with the actual OTP used by the thermal subsystem that way
<qschulz>
no I mean, the drivers can request shared GPIOs
<qschulz>
the pinctrl would be the issue I assume
<qschulz>
ah well, it's not a GPIO for the TSADC
<dsimic>
yup, otp_out
<qschulz>
so your plan is to make the TSADC driver register a restart callback/routine/whatever it's called so the kernel calls it when rebooting?
<qschulz>
and drive that pin as a GPIO?
<dsimic>
pretty much something like that, except the GPIO part... well, maybe it could be seen as a quasi-GPIO
<dsimic>
basically, the thermal subsystem will be enhanced to work additionally as a reset-controller
<qschulz>
ok
<dsimic>
and it will just trigger OTP protection when a reset is requested the usual way
<dsimic>
which is like pressing the reset button
<qschulz>
by driving the pin
<dsimic>
yes, just as it resets the PMIC/system in case of OTP
<qschulz>
okay
<qschulz>
trying to wrap my head around what this implies for U-Boot though
<dsimic>
and it will also record something-something into the PMIC scratchpad, so U-Boto knows it isn't a true OTP
<dsimic>
nothing, except the wrong power-on cause
<qschulz>
because pulling in THERMAL (is there even a subsystem for that?) + RESET + ...
<qschulz>
in TPL
<qschulz>
pfew
<dsimic>
hmm
<dsimic>
luckily, the sysreset-gpio code shold never be reached with my reset-controller :)
<dsimic>
s/shold/should/
<qschulz>
I don't think that's a good idea
<qschulz>
you'd be relying on the kernel for the bootloader to work
<dsimic>
huh, why? it should never be reached in U-Boot only because it won't be needed
<qschulz>
enter U-Boot
<qschulz>
type reset
<dsimic>
it should remain in U-Boot, though
<dsimic>
ah, I see
<qschulz>
it won't do a cold boot next boot
<dsimic>
I'm not saying that the U-Boot code shold be dropped
<qschulz>
have users/distros use ancient kernels, the problem would still be there
<dsimic>
s/shold/should/
<qschulz>
sure
<qschulz>
I'm telling you you probably want a sysreset-gpio as well
<qschulz>
in addition to what you'll do in the kernel
<dsimic>
of course, I'm just saying that the code won't be reached in the ideal conditions
<qschulz>
ideally yes :)
<qschulz>
a normal reboot scenario
<dsimic>
I agree about sysreset-gpio, and I'll add it for the RockPro64 and the Pinebook Pro as well
<qschulz>
or from a dead/no battery
<qschulz>
meh, I don't like sysreset-gpio anymore :D
<qschulz>
this means I cannot really upstream it
<qschulz>
to the kernel DTB I mean
<dsimic>
yeah, it's imposible :/
<qschulz>
also, it relies on the pin being properly muxed
<dsimic>
yeah, in a, well, a bit wrong way
<qschulz>
as I cannot associate a pinctrl with a simple /config property
<dsimic>
could you, please, remind me why using the tsadc node in U-Boot isn't an option?
<dsimic>
to get the GPIO you need?
<qschulz>
how do I get it?
<dsimic>
go through the pinctrl
<dsimic>
which would be hacky, but at least you'd need no additional node
<qschulz>
I prefer the hackish explicit way over the hackish implicit way :)
<dsimic>
makes sense to me :)
<qschulz>
I'm wondering if we shouldn't model this another way
Stat_headcrabbed has joined #linux-rockchip
<qschulz>
have a reset node within the tsadc node
<qschulz>
random thought, no particular idea in mind
<dsimic>
hmm
<qschulz>
this would allow to get rid of this rockchip,hw-tshut-mode and rockchip,hw-tshut-polarity non-sense
<qschulz>
well, maybe I'm a bit quick calling this non-sense, I haven't read the driver :)
<qschulz>
but basically, you would have a reset node that is either cru-based or gpio-based
<qschulz>
you enable the one you want in your board
<qschulz>
and the gpio-reset is a simple gpio-reset
<qschulz>
there probably is one
<dsimic>
huh, those parameters must remain
<qschulz>
why?
<dsimic>
because some boards may use CRU for OTP resets
<qschulz>
in the driver sure, for backward compatibility
<qschulz>
yes, you would have a cru-reset node
<qschulz>
this is all Friday evening theory though
<qschulz>
so if I'm confusing you, you can simply ignore
<qschulz>
i'm not sure it makes a lot of sense
<dsimic>
let's keep in mind that it isn't a GPIO line when used by the TSADC driver
<dsimic>
and the TSADC IP itself gets oonfugured to use that line
<dsimic>
configured *
<dsimic>
IOW, it's a "special" line, so to speak
<dsimic>
so taking it out as gpio-restart would be simply wrong
<dsimic>
because it isn't some separate GPIO line made to reset something, it's part of the OTP system
<qschulz>
i have given up on gpio-restart
<dsimic>
well, you should, franlkly :)
<dsimic>
frankly *
<qschulz>
this whole theory wasn't about gpio-restart
<dsimic>
simply because it isn't what gpio-restart models
<qschulz>
it was about having a reset-controller as a subnode of tsadc
<qschulz>
and then have u-boot use that reset-controoller
<dsimic>
the reset-controller will be just a flag
<dsimic>
just like power-controller
<dsimic>
the specifics are left to the driver :/
<qschulz>
yeah I just don't see anyone writing a tsadc driver in U-Boot just to get a reset-controller :)
<dsimic>
hmmmm
<qschulz>
but maybe I'm wrong :)
<dsimic>
actually, we'd need OTP in U-Boot :/
<qschulz>
what for
<dsimic>
see, people use USB gadget mode for e.g. PPP (PinePhone Pro)
<qschulz>
compared to /config/sysreset-gpio I mean
<dsimic>
which, in theory, may cause the SoC to overheat, e.g. by using the USB gadget mode to dump the 128 GB eMMC, and tossing the PPP under some blanket
<dsimic>
so, we'd need OTP support in U-Boot, to prevent thermal runaways in U-Boot
<qschulz>
the Cortex-A cores are running at 600Mhz, I think it should be fine?
<dsimic>
IDK, I'd rather not think :)
<qschulz>
you're paid to think dsimic :D
<dsimic>
I'd rather be sure, if possible :)
<dsimic>
FTR, I'm not paid at all
<dsimic>
all I work is for free
<dsimic>
s/work/do/
<qschulz>
you're paid in clout then ;)
<qschulz>
hehe
<dsimic>
maybe, IDK :)
<dsimic>
anyway, I'd really like to see thermal runaways prevented in U-Boot :)
<qschulz>
so the OTP thingy, this needs to be configured but then there's nothing to do right?
<qschulz>
like the whole temperature monitoring + overtemp triggering is done by the IP
<dsimic>
as always, it depends :)
<qschulz>
I don't need the thermal subsystem to query the info to trigger it "manually" ?
<dsimic>
it should work that way, but I'm not 100% sure that all TSADC versions work that way
<dsimic>
(there are three versions)
<qschulz>
if you need something in the background, we have CYCLIC now in U-Boot
<dsimic>
perhaps I could have all that verified rather soon, and let you know my findings?
<dsimic>
e.g. I've got some TSADC cleanups pending, so I'll need to go through everything (once) again
<dsimic>
I could verify everything while doing all that
<dsimic>
CYCLIC ic nice :)
<dsimic>
s/ic/is/
<qschulz>
oooooh this is giving me nasty ideas
<dsimic>
yes?
<qschulz>
need to check if there's an OTP thingy on PX30/RK809 as well
<qschulz>
see... we have an issue on our PX30 Ringneck
<qschulz>
because of IO domains
<qschulz>
we cannot use the SoC watchdog because it doesn't trigger a PMIC reset
<qschulz>
BUT, if I could configure the TSADC to be a SW watchdog
<qschulz>
and have it trigger an overtemp event and reset the PMIC in the event of a missed kick...
<dsimic>
RK809 doesn't seem to have all that
<dsimic>
hmm
<dsimic>
I'm really not familiar with the PX30
<qschulz>
OHOH!
<qschulz>
TSADC_SHUT on GPIO0_A6
<dsimic>
yes, it has all tha stuff in px30.dtsi
<qschulz>
the circuitry on Ringneck is such that this should be able to trigger a reset
<qschulz>
it's connected to RESETB
<dsimic>
what PX30 board I could use to check out the schematic?
<qschulz>
the other option I have is developing an i2c watchdog in the two MCU flavors we have
<qschulz>
and a driver for it
<dsimic>
perhaps it's better to use the TSADC
<qschulz>
my FW guy and the product manager probably would agree with you ;)
<dsimic>
:)
<qschulz>
poor TSADC driver, it's gonna do so much piggy-backing
<dsimic>
well, perhaps you could use the upcoming reset-controller on Ricngneck?
<qschulz>
mmind00: ^ you may find this interesting BTW (not this one specifically)
<qschulz>
(using TSADC as watchdog on PX30 Ringneck)
<dsimic>
what do you actually have to watch?
<qschulz>
me? nothing
<qschulz>
we're selling minimal BSP + boards to customers
<dsimic>
I mean, what's the issue with the Ringneck?
<qschulz>
Cannot reboot if booting from SD
<dsimic>
which requires use of a watchdog
<qschulz>
no, nothing requires a watchdog
<qschulz>
except if clients want one
<dsimic>
ah, I see
<qschulz>
which is not a bad idea if you're doing embedded stuff with remote devices
<dsimic>
perhaps the upcomign reset-controller should solve that as well?
<dsimic>
the reboot issue?
<qschulz>
sorry
<qschulz>
didn't mean reboot, meant watchdog reset
<dsimic>
ah, I see
<qschulz>
the reboot works, because the RK809 is registered as a restart/poweroff provider
<qschulz>
and is therefore reset
<qschulz>
when doing a reboot
<dsimic>
ah, it has proper support for resetting in software
<dsimic>
some PMICs have that
<qschulz>
yup
<dsimic>
RK808 also had that initially, AFAIK, but it was deemed buggy and left out of the datasheet
<qschulz>
and the RK806 has a HW watchdog
<qschulz>
BUT NOT THE DARN RK808
<qschulz>
RK809*
<dsimic>
they're all so different
<qschulz>
but I guess I could write a watchdog-reset driver maybe?
<qschulz>
for making use of that reset-controller in tsadc
<qschulz>
mmm wait a sec
<qschulz>
that's a bit stupid
<qschulz>
this would rely on the kernel not crashing
<qschulz>
that would essentially be a pure SW watchdog, just running in the kernel
<qschulz>
but having the kicker and the trigger in the same HW is not good
<qschulz>
so nevermind, watchdog in MCU it is
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
<dsimic>
exactly, it wouldn't be a hardware watchdog
<dsimic>
(from the SoC's perspective, I mean)
<Kwiboo>
qschulz: is your sd-card reboot issue same/similar as the old one for tinker board? i.e. uhs io voltage related? https://patchwork.kernel.org/patch/10817217/ <-- this old patch is still included in LibreELEC and other distros... :/
<qschulz>
Kwiboo: it's not a reboot issue, it's a CPU-only reset (e.g. via CPU watchdog) that triggers the issue
<qschulz>
the BootROM cannot read the SD card
<qschulz>
nothing we can do in SW for that
<qschulz>
except not using the CPU watchdog
<qschulz>
Kwiboo: it works with reboot on PX30 because the RK809 is properly reset when doing a normal reboot
<qschulz>
as part of the driver
<qschulz>
but the RK808 with RK3399 is not capable of doing that
<qschulz>
for Puma, we somehow have a level-shifter forcing the SD signals to 3.3V
<Kwiboo>
ahh, so possible similar issue? something is not reset and missmatch in io-voltage and as a result bootrom cannot read sd-card
<qschulz>
so maybe the controller simply works with 1.8V as input to the power domain if the card is itself powered with 3.3V?
<qschulz>
yeah, I wouldn't be surprised if you have the same issue on RK3399 for example
<qschulz>
for a normal reboot, maybe what dsimic is going to work on will help
<qschulz>
(using TSADC to trigger an overtemp event to the PMIC)
<qschulz>
(when rebooting)
<qschulz>
but it won't help for cases in which only the CPU is reset
<dsimic>
hmm, perhaps it should help with regular reboots
<dsimic>
which currently cannot reach the reset that may be performed in U-Boot, if I'm not wrong
<Kwiboo>
the tinker board (rk3288) and some rk3399 boards had issue reading sd-card after reboot/reset if linux used uhs mode, back when I put that togheter, for happy linux reboot path that patch helped fixed the issue (linux change back to 3v3 before reboot)
<Kwiboo>
guess using tsadc to reset possible also could solve that issue, and I can finnaly remove that old patch/workaround :-)
<qschulz>
it's probably much better
<qschulz>
if dsimic manages to upstream it
<qschulz>
(not doubting the technical skills, maintainers may just disagree with it)
<qschulz>
but resetting the PMIC should really be the target with a normal reboot
<qschulz>
helps getting rid of all the "is this bit in that register sticky?"
<qschulz>
starting from a clean slate every time
<dsimic>
hopefully :)
psydroid has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
linkmauve has left #linux-rockchip [Error from remote client]
linkmauve has joined #linux-rockchip
psydroid has quit [Remote host closed the connection]
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
mripard has quit [Quit: WeeChat 4.4.2]
stikonas has joined #linux-rockchip
naoki has joined #linux-rockchip
jelly has quit [Ping timeout: 252 seconds]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #linux-rockchip
jelly has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]