Hi Fabio,
Thus wrote Fabio Estevam (feste...@gmail.com):
> I am not able to reproduce this problem on a imx25 pdk running 4.14.11
> or linux-next.
this is no surprise. The problem shows up only if the AWAKE bit in UART
Status Register 1 is set before we go into suspend. My understanding is
that
Hi Fabio,
Thus wrote Fabio Estevam (feste...@gmail.com):
> I am not able to reproduce this problem on a imx25 pdk running 4.14.11
> or linux-next.
this is no surprise. The problem shows up only if the AWAKE bit in UART
Status Register 1 is set before we go into suspend. My understanding is
that
Hi Martin,
On Tue, Jan 2, 2018 at 2:15 PM, Martin Kaiser wrote:
> I tested on an imx258.
I am not able to reproduce this problem on a imx25 pdk running 4.14.11
or linux-next.
Is it 100% reproducible on your board?
Care to share its dts? Do you use multiple UART ports? Do
Hi Martin,
On Tue, Jan 2, 2018 at 2:15 PM, Martin Kaiser wrote:
> I tested on an imx258.
I am not able to reproduce this problem on a imx25 pdk running 4.14.11
or linux-next.
Is it 100% reproducible on your board?
Care to share its dts? Do you use multiple UART ports? Do any of them
use
Hi Martin,
On Tue, Jan 2, 2018 at 2:15 PM, Martin Kaiser wrote:
> Fabio, could you post the output of
>
> cat /sys/kernel/debug/suspend_stats
>
> after supend failed, to confirm that we're failing below
> device_suspend_noirq()?
Here it goes:
# cat
Hi Martin,
On Tue, Jan 2, 2018 at 2:15 PM, Martin Kaiser wrote:
> Fabio, could you post the output of
>
> cat /sys/kernel/debug/suspend_stats
>
> after supend failed, to confirm that we're failing below
> device_suspend_noirq()?
Here it goes:
# cat /sys/kernel/debug/suspend_stats
success: 0
Hi Fabio,
thanks for testing my patch. Sorry for breaking suspend on your board.
Thus wrote Fabio Estevam (feste...@gmail.com):
> Which i.MX SoC did you use to test this patch?
I tested on an imx258.
> On a imx6q-cuboxi I am no longer able to enter in suspend with this
> path applied:
> #
Hi Fabio,
thanks for testing my patch. Sorry for breaking suspend on your board.
Thus wrote Fabio Estevam (feste...@gmail.com):
> Which i.MX SoC did you use to test this patch?
I tested on an imx258.
> On a imx6q-cuboxi I am no longer able to enter in suspend with this
> path applied:
> #
Hi Martin,
On Wed, Dec 27, 2017 at 3:27 PM, Martin Kaiser wrote:
> Before we go into suspend mode, we enable the imx uart's interrupt for
> the awake bit in the UART Status Register 1. If, for some reason, the
> awake bit is already set before we enter suspend mode, we get an
>
Hi Martin,
On Wed, Dec 27, 2017 at 3:27 PM, Martin Kaiser wrote:
> Before we go into suspend mode, we enable the imx uart's interrupt for
> the awake bit in the UART Status Register 1. If, for some reason, the
> awake bit is already set before we enter suspend mode, we get an
> interrupt
Before we go into suspend mode, we enable the imx uart's interrupt for
the awake bit in the UART Status Register 1. If, for some reason, the
awake bit is already set before we enter suspend mode, we get an
interrupt immediately when we enable interrupts for awake. The uart's
clk_ipg is already
Before we go into suspend mode, we enable the imx uart's interrupt for
the awake bit in the UART Status Register 1. If, for some reason, the
awake bit is already set before we enter suspend mode, we get an
interrupt immediately when we enable interrupts for awake. The uart's
clk_ipg is already
12 matches
Mail list logo