Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Rafael J. Wysocki]

On Wednesday, January 17, 2018 10:14:23 AM CET Geert Uytterhoeven wrote:
> Hi Rafael,
> 
> On Mon, Jan 15, 2018 at 5:17 PM, Rafael J. Wysocki  wrote:
> > On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson  wrote:
> >> On 15 January 2018 at 14:22, Geert Uytterhoeven  
> >> wrote:
> >
> > [cut]
> >
> >>>
> >>> I did miss a small difference in topology: in pm/linux-next, H3 has DMA
> >>> enabled for SCIF2, while M3 hasn't (yet).
> >>> With DMA enabled on M3, it fails in the same way.
> >>>
> >>> As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
> >>> rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
> >>> are no longer reinitialized after system resume, breaking the serial port.
> >>
> >> In drivers/dma/sh/rcar-dmac.c, I would try to replace the below line:
> >> SET_SYSTEM_SLEEP_PM_OPS(rcar_dmac_sleep_suspend, rcar_dmac_sleep_resume)
> >>
> >> with:
> >> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
> >
> > Yes, that probably is the least intrusive thing that can be done to
> > address the issue.
> >
> >> in case that may be too early to suspend the dma device (which is
> >> rather common for dma devices) then try;
> >>
> >> SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, 
> >> pm_runtime_force_resume)
> >
> > Good suggestion, and I would go straight for it anyway.
> >
> > Geert, can you try if this works, please?
> 
> Works. Both using SET_SYSTEM_SLEEP_PM_OPS() and
> SET_LATE_SYSTEM_SLEEP_PM_OPS(). But given this is a DMA engine
> driver, I'd settle for the latter.
> 
> And I did verify doing so doesn't break the system without the patch
> in $subject.
> 
> Thanks!
> 
> Will send a patch...

Thank you!

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Mon, Jan 15, 2018 at 5:17 PM, Rafael J. Wysocki  wrote:
> On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson  wrote:
>> On 15 January 2018 at 14:22, Geert Uytterhoeven  wrote:
>
> [cut]
>
>>>
>>> I did miss a small difference in topology: in pm/linux-next, H3 has DMA
>>> enabled for SCIF2, while M3 hasn't (yet).
>>> With DMA enabled on M3, it fails in the same way.
>>>
>>> As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
>>> rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
>>> are no longer reinitialized after system resume, breaking the serial port.
>>
>> In drivers/dma/sh/rcar-dmac.c, I would try to replace the below line:
>> SET_SYSTEM_SLEEP_PM_OPS(rcar_dmac_sleep_suspend, rcar_dmac_sleep_resume)
>>
>> with:
>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
>
> Yes, that probably is the least intrusive thing that can be done to
> address the issue.
>
>> in case that may be too early to suspend the dma device (which is
>> rather common for dma devices) then try;
>>
>> SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, 
>> pm_runtime_force_resume)
>
> Good suggestion, and I would go straight for it anyway.
>
> Geert, can you try if this works, please?

Works. Both using SET_SYSTEM_SLEEP_PM_OPS() and
SET_LATE_SYSTEM_SLEEP_PM_OPS(). But given this is a DMA engine
driver, I'd settle for the latter.

And I did verify doing so doesn't break the system without the patch
in $subject.

Thanks!

Will send a patch...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Rafael J. Wysocki]

On Mon, Jan 15, 2018 at 3:26 PM, Ulf Hansson  wrote:
> On 15 January 2018 at 14:22, Geert Uytterhoeven  wrote:

[cut]

>>
>> I did miss a small difference in topology: in pm/linux-next, H3 has DMA
>> enabled for SCIF2, while M3 hasn't (yet).
>> With DMA enabled on M3, it fails in the same way.
>>
>> As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
>> rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
>> are no longer reinitialized after system resume, breaking the serial port.
>
> In drivers/dma/sh/rcar-dmac.c, I would try to replace the below line:
> SET_SYSTEM_SLEEP_PM_OPS(rcar_dmac_sleep_suspend, rcar_dmac_sleep_resume)
>
> with:
> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)

Yes, that probably is the least intrusive thing that can be done to
address the issue.

> in case that may be too early to suspend the dma device (which is
> rather common for dma devices) then try;
>
> SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, 
> pm_runtime_force_resume)

Good suggestion, and I would go straight for it anyway.

Geert, can you try if this works, please?

Thanks,
Rafael

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Ulf Hansson]

On 15 January 2018 at 14:22, Geert Uytterhoeven  wrote:
> Hi Rafael,
>
> On Mon, Jan 15, 2018 at 9:16 AM, Geert Uytterhoeven
>  wrote:
>> On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki  wrote:
>>> On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
>>>  wrote:
 On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  
 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  
>> wrote:
>> > This comes from the recent discussion/testing effort that ensued after 
>> > my
>> > pm_runtime_force_suspend|resume() changes proposal:
>> >
>> > https://marc.info/?t=15149777204=1=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.
>
> I did miss a small difference in topology: in pm/linux-next, H3 has DMA
> enabled for SCIF2, while M3 hasn't (yet).
> With DMA enabled on M3, it fails in the same way.
>
> As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
> rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
> are no longer reinitialized after system resume, breaking the serial port.

In drivers/dma/sh/rcar-dmac.c, I would try to replace the below line:
SET_SYSTEM_SLEEP_PM_OPS(rcar_dmac_sleep_suspend, rcar_dmac_sleep_resume)

with:
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)

in case that may be too early to suspend the dma device (which is
rather common for dma devices) then try;

SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)

Kind regards
Uffe

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Mon, Jan 15, 2018 at 9:16 AM, Geert Uytterhoeven
 wrote:
> On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki  wrote:
>> On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
>>  wrote:
>>> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  
>>> 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  
> wrote:
> > This comes from the recent discussion/testing effort that ensued after 
> > my
> > pm_runtime_force_suspend|resume() changes proposal:
> >
> > https://marc.info/?t=15149777204=1=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.

I did miss a small difference in topology: in pm/linux-next, H3 has DMA
enabled for SCIF2, while M3 hasn't (yet).
With DMA enabled on M3, it fails in the same way.

As genpd_resume_noirq() no longer calls pm_runtime_force_resume(),
rcar_dmac_runtime_resume() is no longer called, and the DMAC's registers
are no longer reinitialized after system resume, breaking the serial port.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki  wrote:
> On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
>  wrote:
>> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  
>> 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  
 wrote:
 > This comes from the recent discussion/testing effort that ensued after my
 > pm_runtime_force_suspend|resume() changes proposal:
 >
 > https://marc.info/?t=15149777204=1=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 -- ge...@linux-m68k.org

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

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Rafael J. Wysocki]

On Sun, Jan 14, 2018 at 10:48 AM, Geert Uytterhoeven
 wrote:
> Hi Rafael,
>
> On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  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  
>>> wrote:
>>> > This comes from the recent discussion/testing effort that ensued after my
>>> > pm_runtime_force_suspend|resume() changes proposal:
>>> >
>>> > https://marc.info/?t=15149777204=1=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).

>> 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?

> And of course there's uart_ops.pm, which is driven from serial_core...

What does this point to for that particular device?

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Sat, Jan 13, 2018 at 1:38 AM, Rafael J. Wysocki  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  
>> wrote:
>> > This comes from the recent discussion/testing effort that ensued after my
>> > pm_runtime_force_suspend|resume() changes proposal:
>> >
>> > https://marc.info/?t=15149777204=1=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...

> 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.
And of course there's uart_ops.pm, which is driven from serial_core...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Rafael J. Wysocki]

On Friday, January 12, 2018 3:31:09 PM CET Geert Uytterhoeven wrote:
> Hi Rafael,
> 
> On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki  wrote:
> > This comes from the recent discussion/testing effort that ensued after my
> > pm_runtime_force_suspend|resume() changes proposal:
> >
> > https://marc.info/?t=15149777204=1=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.

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.

> Oh well, have a nice weekend!

Thanks, you too!

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

[Geert Uytterhoeven]

Hi Rafael,

On Fri, Jan 12, 2018 at 2:00 PM, Rafael J. Wysocki  wrote:
> This comes from the recent discussion/testing effort that ensued after my
> pm_runtime_force_suspend|resume() changes proposal:
>
> https://marc.info/?t=15149777204=1=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.
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.

Oh well, have a nice weekend!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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