Hi Rafael, On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: >> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >>> On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote: >>>> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >>>> > This comes from the recent discussion/testing effort that ensued after my >>>> > pm_runtime_force_suspend|resume() changes proposal: >>>> > >>>> > https://marc.info/?t=151497772000004&r=1&w=2 >>>> > >>>> > Patch [1/2] basically is https://patchwork.kernel.org/patch/10152873/ rebased >>>> > on top of the current linux-next branch of the linux-pm.git tree (the relevant >>>> > part should be there in the linux-next tree proper ATM). It applies on top >>>> > of https://patchwork.kernel.org/patch/10156077/ which should apply to the Linus' >>>> > tree cleanly. >>>> > >>>> > Patch [2/2] is a resend of https://patchwork.kernel.org/patch/10142047/ with >>>> > a very minor changelog modification and the R-b tag from Ulf. >>>> > >>>> > Geert, if possible, please test this on the Renesas systems that had the >>>> > problem with https://patchwork.kernel.org/patch/10142047/ previously and let >>>> > me know if you still see issues. >>>> >>>> I've tested this on two very similar systems: Salvator-XS with R-Car H3 ES2.0, >>>> and Salvator-X with R-Car M3-W ES1.0. >>>> >>>> On the M3-based system, everything seems to work fine. >>> >>> Good. >>> >>>> On the H3-based system, the serial console (the /dev/ttySC0 device, not kernel >>>> serial output) is dead after resume from s2ram, with and without >>>> no_console_suspend. >>>> >>>> With no_console_suspend, I see: >>>> >>>> ttySC ttySC0: 1 input overrun(s) >>>> >>>> after typing on the serial console, so it looks like an interrupt problem. >>>> >>>> This issue seems to be caused by patch [1/2]. But I have no idea what's >>>> really happening, and why the two systems behave differently. >> >> Could be a firmware issue, too. >> While the kernel images are identical, the ARM trusted firmware configs aren't >> (same version, though). >> >> I'll do some more investigation... > > OK, thanks! > > It also would be good to know the topology of the device hierarchy and > how that maps to the domains on the failing system (and which UART > clocks are operated by genpd). The topology is the same on both systems. The UART's module clock is operated by genpd, on both systems. >>> Well, that's not dramatic. >>> >>> Let's make a deal that we'll fix this on top of [1/2]. >> >> ;-) >> >>> Which driver is this BTW? sh-sci? That one doesn't even support runtime >>> PM, confusingly enough. >> >> Yes, sh-sci. It does make pm_runtime_*() calls. > > Hmm. I overlooked that part. > > This is sort of unusual, because the driver doesn't provide any > runtime PM callbacks, but still it does provided system suspend ones. > It looks like the idea is to never put it into runtime suspend if any > ports are enabled and always put it into runtime suspend otherwise. > > Which one is the case in your testing? Is the port disabled or > enabled during system-wide suspend? It's enabled on both systems, as a getty is running. >> And of course there's uart_ops.pm, which is driven from serial_core... > > What does this point to for that particular device? sci_pm(), on both systems. See, there's no difference in topology on both systems, so I'll have to look a bit deeper first... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
