All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <briannorris@chromium.org>
To: "Ondřej Jirman" <megi@xff.cz>, "Jon Lin" <jon.lin@rock-chips.com>,
	broonie@kernel.org, heiko@sntech.de, linux-spi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"shengfei Xu" <xsf@rock-chips.com>
Subject: Re: [PATCH v3 5/6] spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops
Date: Fri, 23 Aug 2024 14:28:40 -0700	[thread overview]
Message-ID: <Zsj_CJR56TcahXBO@google.com> (raw)
In-Reply-To: <20220621154218.sau54jeij4bunf56@core>

On Tue, Jun 21, 2022 at 05:42:18PM +0200, Ondřej Jirman wrote:
> On Wed, Feb 16, 2022 at 09:40:27AM +0800, Jon Lin wrote:
> > From: shengfei Xu <xsf@rock-chips.com>
> > 
> > the wakeup interrupt handler which is guaranteed not to run while
> > @resume noirq() is being executed. the patch can help to avoid the
> > wakeup source try to access spi when the spi is in suspend mode.
> 
> This patch causes oops on suspend every single time, because it tries to disable
> already disabled clocks (one disable in runtime PM suspend, and other one in
> system suspend). It also fails to properly handle errors from clk_prepare_enable
> in rockchip_spi_resume, potentially causing even more clock enable/disable
> imballance issues.
> 
> Please send a revert and figure out a better fix for the original issue.

Did anyone ever resolve this? I still see this issue on 6.10.6.

IIUC, we can actually do a partial revert -- we *should* be using
pm_runtime_force_{suspend,resume}() (so that we coordinate clk-disable,
etc. with the runtime PM state), but we also want to run in the noirq
phase.

If I don't see anyone else's solution or input, I'll plan on submitting
a partial revert, which seems to test out OK for me.

Brian

P.S. One can work around this problem by disabling runtime PM for the
controllers:

for i in /sys/bus/platform/drivers/rockchip-spi/*/power/control; do
  echo on >$i
done

But obviously that's not ideal.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: "Ondřej Jirman" <megi@xff.cz>, "Jon Lin" <jon.lin@rock-chips.com>,
	broonie@kernel.org, heiko@sntech.de, linux-spi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"shengfei Xu" <xsf@rock-chips.com>
Subject: Re: [PATCH v3 5/6] spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops
Date: Fri, 23 Aug 2024 14:28:40 -0700	[thread overview]
Message-ID: <Zsj_CJR56TcahXBO@google.com> (raw)
In-Reply-To: <20220621154218.sau54jeij4bunf56@core>

On Tue, Jun 21, 2022 at 05:42:18PM +0200, Ondřej Jirman wrote:
> On Wed, Feb 16, 2022 at 09:40:27AM +0800, Jon Lin wrote:
> > From: shengfei Xu <xsf@rock-chips.com>
> > 
> > the wakeup interrupt handler which is guaranteed not to run while
> > @resume noirq() is being executed. the patch can help to avoid the
> > wakeup source try to access spi when the spi is in suspend mode.
> 
> This patch causes oops on suspend every single time, because it tries to disable
> already disabled clocks (one disable in runtime PM suspend, and other one in
> system suspend). It also fails to properly handle errors from clk_prepare_enable
> in rockchip_spi_resume, potentially causing even more clock enable/disable
> imballance issues.
> 
> Please send a revert and figure out a better fix for the original issue.

Did anyone ever resolve this? I still see this issue on 6.10.6.

IIUC, we can actually do a partial revert -- we *should* be using
pm_runtime_force_{suspend,resume}() (so that we coordinate clk-disable,
etc. with the runtime PM state), but we also want to run in the noirq
phase.

If I don't see anyone else's solution or input, I'll plan on submitting
a partial revert, which seems to test out OK for me.

Brian

P.S. One can work around this problem by disabling runtime PM for the
controllers:

for i in /sys/bus/platform/drivers/rockchip-spi/*/power/control; do
  echo on >$i
done

But obviously that's not ideal.

  reply	other threads:[~2024-08-23 21:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-16  1:40 [PATCH v3 0/6] New support and problem adjustment of SPI rockchip Jon Lin
2022-02-16  1:40 ` Jon Lin
2022-02-16  1:40 ` Jon Lin
2022-02-16  1:40 ` [PATCH v3 1/6] spi: rockchip: Fix error in getting num-cs property Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40 ` [PATCH v3 2/6] spi: rockchip: terminate dma transmission when slave abort Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40 ` [PATCH v3 3/6] spi: rockchip: Stop spi slave dma receiver when cs inactive Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40 ` [PATCH v3 4/6] spi: rockchip: Preset cs-high and clk polarity in setup progress Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40 ` [PATCH v3 5/6] spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-06-21 15:42   ` Ondřej Jirman
2022-06-21 15:42     ` Ondřej Jirman
2022-06-21 15:42     ` Ondřej Jirman
2024-08-23 21:28     ` Brian Norris [this message]
2024-08-23 21:28       ` Brian Norris
     [not found]       ` <f836c6fe-3edc-4e6b-aa83-b50d9edcb816@rock-chips.com>
2024-08-26 18:30         ` Brian Norris
2024-08-26 18:30           ` Brian Norris
2022-02-16  1:40 ` [PATCH v3 6/6] spi: rockchip: clear interrupt status in error handler Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-16  1:40   ` Jon Lin
2022-02-17 16:22 ` (subset) [PATCH v3 0/6] New support and problem adjustment of SPI rockchip Mark Brown
2022-02-17 16:22   ` Mark Brown
2022-02-17 16:22   ` Mark Brown
2022-02-17 18:32 ` Mark Brown
2022-02-17 18:32   ` Mark Brown
2022-02-17 18:32   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zsj_CJR56TcahXBO@google.com \
    --to=briannorris@chromium.org \
    --cc=broonie@kernel.org \
    --cc=heiko@sntech.de \
    --cc=jon.lin@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=megi@xff.cz \
    --cc=xsf@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.