ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
macromorgan has quit [Read error: Connection reset by peer]
iivanov has joined #armlinux
apritzel has joined #armlinux
mcoquelin has joined #armlinux
chipxxx has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 246 seconds]
chipxxx has joined #armlinux
viorel_suman has joined #armlinux
chipxxx has quit [Remote host closed the connection]
chip_x has joined #armlinux
sszy has joined #armlinux
headless has joined #armlinux
matthias_bgg has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #armlinux
cbeznea has quit [Remote host closed the connection]
cbeznea has joined #armlinux
amitk has quit [Ping timeout: 246 seconds]
Norkle has quit [Remote host closed the connection]
amitk has joined #armlinux
sakman has joined #armlinux
apritzel has joined #armlinux
sakman has quit [Remote host closed the connection]
Norkle has joined #armlinux
amitk_ has joined #armlinux
monstr has joined #armlinux
apritzel has quit [Ping timeout: 250 seconds]
headless has quit [Ping timeout: 246 seconds]
headless has joined #armlinux
prabhakarlad has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<mriesch>
is there a way to shutdown a system but leave certain voltages on (that may be required for circuits that power on the system again)?
<robmur01>
FWIW I'd expect that to be a responsibility of the PMIC/regulator drivers, in how they handle shutdown
matthias_bgg has quit [Ping timeout: 276 seconds]
<mriesch>
robmur01: so there could be a way to tell a regulator that it should not be shut down?
<mriesch>
i have seen that there is something for suspend along those lines
<robmur01>
there's probably an argument to be had around what "always on" means WRT shutdown...
<javierm>
mriesch: I guess you could do it by having a custom restart handler that has the highest priority
<javierm>
but I don't know if would be the proper approach...
<mriesch>
javierm: i haven't dealt with restart handlers yet, what could the custom handler do?
<javierm>
mriesch: enable your regulator before reset if you want that to be enabled for the system to boot
<mvaittin>
mriesch: I may be wrong but I am not aware of any "generic way". Some PMICs implemented vendor specific DT properties like "rohm,dvs-snvs-voltage"
<mriesch>
javierm: is the reset handler the handler that is stored in pm_power_off?
<javierm>
mriesch: no, the ones that are registered with register_restart_handler()
<javierm>
mriesch: sorry, I've to leave now for a medical appointment. I may be online again in a couple of hours
<mriesch>
javierm: thanks a lot!
<mriesch>
mvaittin: thanks, i'll check that out!
matthias_bgg has joined #armlinux
<mvaittin>
mriesch: The one I pointed is only working for ROHM BD71815 (as far as I remember). Point was that I am not aware of generic mechanism but if you target to a board with a specific PMIC, then there might be support you're looking for.
amitk_ has quit [Ping timeout: 276 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
balrog has quit [Quit: Bye]
sakman has joined #armlinux
balrog has joined #armlinux
alpernebbi has quit [Ping timeout: 276 seconds]
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 255 seconds]
macromorgan has joined #armlinux
<mriesch>
robmur01: coming back to your last statement: the regulator-always-on; cannot be used i'd say, as this affects the running system
torez has quit [Quit: torez]
<mriesch>
but maybe there could be another set such as regulator-state-off that defines what should happen at shutdown/poweroff
torez has joined #armlinux
<robmur01>
oh, I see - I guess I was imagining that a supply which was critical for turning the system on would also be needed to keep it turned on :)
alpernebbi has joined #armlinux
<ardb>
arnd: are you still considering combined v5/v6 multiplatform support for ARM?
<mriesch>
robmur01: good point, i guess this can be inferred. opposite direction might not be true, though.
cbeznea has quit [Ping timeout: 264 seconds]
headless has joined #armlinux
headless has quit [Client Quit]
guillaume_g has quit [Quit: Konversation terminated!]
cbeznea has joined #armlinux
amitk_ has joined #armlinux
cbeznea has quit [Ping timeout: 255 seconds]
marshmallow has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
hanetzer has quit [Ping timeout: 264 seconds]
viorel_suman has quit [Quit: WeeChat 3.6]
hanetzer has joined #armlinux
frieder has quit [Remote host closed the connection]
hanetzer has quit [Ping timeout: 276 seconds]
headless has joined #armlinux
hanetzer has joined #armlinux
jeeeun0 has joined #armlinux
jeeeun has quit [Ping timeout: 268 seconds]
jeeeun0 is now known as jeeeun
Nact has joined #armlinux
apritzel has joined #armlinux
cbeznea has quit [Quit: Leaving.]
amitk_ has quit [Ping timeout: 246 seconds]
cbeznea has joined #armlinux
amitk has quit [Ping timeout: 248 seconds]
<arnd>
ardb: yes, at least I'm still build-testing with the patch I created a while ago. I have actually tried booting it even in qemu, and it's likely that I missed something that can't work in the current version
marshmallow has quit [Quit: ZNC 1.9.x-git-170-9be0cae1 - https://znc.in]
apritzel has quit [Ping timeout: 248 seconds]
cbeznea has quit [Ping timeout: 255 seconds]
matthias_bgg has quit [Ping timeout: 255 seconds]
headless has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #armlinux
torez has quit [Quit: torez]
<broonie>
mriesch: In general there's no interface for controlling supplies on shutdown, the PMIC is generally responsible for both the initial power up and coming out of a power down.
<broonie>
If the supply is that essential I'd expect it to be always on and therefore there to be no way to turn it off so I'm not sure I'd see an issue there.
iivanov has quit [Ping timeout: 255 seconds]
<broonie>
I would wonder if the consumer that's turning things off needs to be doing any broader preparation for shutdown if there's issues here.
<broonie>
Could you be more specific about the hardware here - what are the regulators involved, and does the PMIC understand that the system is in a power off state (what does powering down actually look like?)?
prabhakarlad has quit [Quit: Client closed]
<ardb>
arnd: we'll need to fix the CPU_FEROCEON hack in the VFP code in that case
<ardb>
it's probably already broken on multi_v5 but I guess VFP was quite rare then