From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: "André Draszik" <andre.draszik@linaro.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>
Cc: Peter Griffin <peter.griffin@linaro.org>,
Will McVicker <willmcvicker@google.com>,
kernel-team@android.com, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] firmware: exynos-acpm: allow use during system shutdown
Date: Mon, 24 Mar 2025 13:23:00 +0000 [thread overview]
Message-ID: <9b372589-1c52-4f3d-9f5b-8f729489b545@linaro.org> (raw)
In-Reply-To: <20250321-acpm-atomic-v1-2-fb887bde7e61@linaro.org>
On 3/21/25 4:40 PM, André Draszik wrote:
> We need to access the PMIC during late system shutdown and at that time
> we are not allowed to sleep anymore.
>
> To make this case work, detect this condition and use busy waiting via
> udelay() instead of usleep_range() in that situation.
>
> The code isn't switched over to udelay() unconditionally so as to not
> waste resources during normal operation. acpm_may_sleep() was heavily
> inspired by the I2C subsystem's i2c_in_atomic_xfer_mode().
>
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>
> ---
> udelay(10) causes a checkpatch warning (it suggests to use
> usleep_range() instead for usec >= 10), but that's exactly what we can
> not do.
> Reducing the udelay to be smaller will generally cause the loop to be
> iterated more than once, which I wanted to avoid.
> I could reflow the code to hide the actual value from checkpatch, e.g.
> with the help of a local variable if that is preferred to ignoring the
> checkpatch warning.
> ---
> drivers/firmware/samsung/exynos-acpm.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
> index d7ed6b77a957af5db5beba7deecce13ac7b30fd2..33cde6e88e2c0773fdd36c80927c77d3bcb44135 100644
> --- a/drivers/firmware/samsung/exynos-acpm.c
> +++ b/drivers/firmware/samsung/exynos-acpm.c
> @@ -15,6 +15,8 @@
> #include <linux/firmware/samsung/exynos-acpm-protocol.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/irqflags.h>
> +#include <linux/kernel.h>
> #include <linux/mailbox/exynos-message.h>
> #include <linux/mailbox_client.h>
> #include <linux/module.h>
> @@ -24,6 +26,7 @@
> #include <linux/of_address.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/preempt.h>
> #include <linux/slab.h>
> #include <linux/types.h>
>
> @@ -272,6 +275,17 @@ static int acpm_get_rx(struct acpm_chan *achan, const struct acpm_xfer *xfer)
> return 0;
> }
>
> +/*
> + * When ACPM transfers happen very late, e.g. to access a PMIC when powering
> + * down, we can not sleep. We do want to sleep in the normal case, though, to
> + * avoid wasting CPU cycles!
> + */
> +static bool acpm_may_sleep(void)
> +{
> + return system_state <= SYSTEM_RUNNING ||
> + (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? preemptible() : !irqs_disabled());
> +}
> +
> /**
> * acpm_dequeue_by_polling() - RX dequeue by polling.
> * @achan: ACPM channel info.
> @@ -299,7 +313,10 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
> return 0;
>
> /* Determined experimentally. */
> - usleep_range(20, 30);
> + if (!acpm_may_sleep())
> + udelay(10);
> + else
> + usleep_range(20, 30);
> } while (!ktime_after(ktime_get(), timeout));
>
> dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n",
>
prev parent reply other threads:[~2025-03-24 13:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 16:40 [PATCH 0/2] " André Draszik
2025-03-21 16:40 ` [PATCH 1/2] firmware: exynos-acpm: use ktime APIs for timeout detection André Draszik
2025-03-24 12:52 ` Tudor Ambarus
2025-03-21 16:40 ` [PATCH 2/2] firmware: exynos-acpm: allow use during system shutdown André Draszik
2025-03-24 13:23 ` Tudor Ambarus [this message]
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=9b372589-1c52-4f3d-9f5b-8f729489b545@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=kernel-team@android.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=willmcvicker@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®