06:42 <linusw__> marcan: don't know if it adds anything but on systems I have run usually the UART is on an "armed" pad ring meaning the system will autonomously wake up from sleep when an event occurs on say RX, just from an edge transition, and at that point that pin is handled like "some kind of GPIO".

06:43 <linusw__> then what happens is that autonomous system wakes up the system and the UART driver restores state and ... invariably lose the first character typed on the TTY.

06:43 <linusw__> In all cases I've seen it has been "OK let's lose that first character on the TTY tough luck, work finished".

06:45 <marcan> heh, yeah, doesn't surprise me

06:46 <marcan> not really relevant to us since we don't actually involve wakeups in any of this, it's just about keeping the UART alive when debugging sleep

07:11 <geertu> marcan: Looking at genpd_power_off(), a child device not being runtime-suspended is treated the same as the genpd's power_off() method runnig -EBUSY.

07:11 <geertu> Does it work for you if you return -EBUSY from the serial driver's runtime_suspend callback?

07:11 <marcan> geertu: not a child device, a *child PD* (which makes sense but is not useful here)

07:11 <geertu> Or is that hanlded differently elsewhere

07:12 <geertu> Oh right

07:12 <marcan> runtime_suspend isn't involved here, it's normal suspend. you *can* abort runtime_suspend but if you try to return an error from the suspend callback it aborts the entire suspend

07:13 <geertu> list_for_each_entry() { ... if (...) not_suspended++; } does handle child devices, not child genpds

07:15 <marcan> genpd_power_off is for runtime PM

07:15 <marcan> you want genpd_sync_power_off

07:15 <marcan> that is the one used in the suspend path and does not have that check

07:18 <geertu> Then we probably need a similar check there ;-)

07:18 <marcan> well, that would break for devices that don't support runtime PM but do support sleep

07:18 <marcan> since it'd leave all those power domains on

07:18 <marcan> there needs to be some way for the *device* to choose whether it remains powered in sleep or not, opt-in

07:29 <geertu> I'm not aware of any such method, except what I use in the rmobile-sysc driver

07:29 <javierm> marcan: there are some subsystem specific mechanisms such as the "keep-power-in-suspend" for MMC, but it is indeed surprising that there isn't something generic for this

07:30 <geertu> Apparently most systems have the UART in an always-on genpd

07:31 <geertu> So it's the first person who needs support for it and can't hack it into his genpd driver, who has to make it work in a generic way ;-)

07:32 <marcan> javierm: there basically is, the wakeup_path thing, it's just named way more specifically than it should be :p

07:32 <marcan> I'm using that now and it works

07:33 <geertu> The wakeup_path parts (both genpd and irqchip) were in a similar bad shape some years ago, as apparently no one needed them fully working before

07:38 <geertu> FWIW, the "PC people" don't understand irqchips, serial ports, and memory controllers in a non-always-on genpd ;-)

07:39 <javierm> marcan: right, funny that even some comments are more general than the wakeup use case, i.e:

07:39 <javierm> include/linux/pm_domain.h: * GENPD_FLAG_ALWAYS_ON: Instructs genpd to always keep the PM domain

07:39 <javierm> err, sorry I meant: include/linux/pm_domain.h: * GENPD_FLAG_ACTIVE_WAKEUP: Instructs genpd to keep the PM domain powered

07:40 <marcan> yup

10:31 <geertu> ardb: At first, I had missed the "..." in "[GIT PULL 4/4] ARM: SoC devicetree changes for 6.4

10:31 <geertu> ", and was thus investigating what happened to the other changes...

10:31 <geertu> grr, silly TAB-complete s/ardb/arnd/

10:32 <geertu> arnd: ^

11:17 <arnd> geertu: sorry about that, there were ober 800 commits in that branch, so I had to edit the shortlog to get below 100kb

12:12 <geertu> arnd: I understand :-)