[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39410a95-0eb9-d266-7210-920fa5198a23@pengutronix.de>
Date: Fri, 17 May 2019 19:18:43 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Joakim Zhang <qiangqing.zhang@....com>,
"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>
Cc: dl-linux-imx <linux-imx@....com>,
"wg@...ndegger.com" <wg@...ndegger.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Aisheng Dong <aisheng.dong@....com>
Subject: Re: [PATCH] can: flexcan: fix deadlock when using self wakeup
On 5/17/19 4:39 AM, Joakim Zhang wrote:
> As reproted by Sean Nyekjaer bellow:
> When suspending, when there is still can traffic on the
> interfaces the flexcan immediately wakes the platform again.
> As it should :-)
> But it throws this error msg:
> [ 3169.378661] PM: noirq suspend of devices failed
>
> On the way down to suspend the interface that throws the error
> message does call flexcan_suspend but fails to call
> flexcan_noirq_suspend.
> That means the flexcan_enter_stop_mode is called, but on the way
> out of suspend the driver only calls flexcan_resume and skips
> flexcan_noirq_resume, thus it doesn't call flexcan_exit_stop_mode.
> This leaves the flexcan in stop mode, and with the current driver
> it can't recover from this even with a soft reboot, it requires a
> hard reboot.
>
> Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
>
> This patch intends to fix the issue, and also add comment to explain the
> wakeup flow.
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@....com>
The existing self wakeup support:
| de3578c198c6 ("can: flexcan: add self wakeup support")
looks broken to me.
According to the data sheet:
> To enter stop mode, the CPU should manually assert a global Stop Mode
> request (see the CAN1_STOP_REQ and CAN2_STOP_REQ bit in the register
> IOMUXC_GPR4) and check the acknowledgement asserted by the FlexCAN
> (see the CAN1_STOP_ACK and CAN2_STOP_ACK in the register
> IOMUXC_GPR4). The CPU must only consider the FlexCAN in Stop Mode
> when both request and acknowledgement conditions are satisfied.
you have to poll for the acknowledgement, which is not done in the
driver. Please fix that first.
As far as I understand the documentation the suspend() and resume
functions should be symmetric. If they are, you shouldn't need the
in_stop_mode hack.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists