[PATCH v2 0/2] firmware: exynos-acpm: allow use during system shutdown

[PATCH v2 0/2] firmware: exynos-acpm: allow use during system shutdown

[André Draszik]

One user of this ACPM driver is a PMIC driver that needs to communicate
with the PMIC during late system shutdown [1] and at that time we are
not allowed to sleep anymore.

This series address this by switching the code to using udelay() in the
specific case of system shutdown. This approach was inspired by I2C's
i2c_in_atomic_xfer_mode(), which has to deal with a similar corner
case.

Link: https://lore.kernel.org/all/20250323-s2mpg10-v1-29-d08943702707@linaro.org/ [1]

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
Changes in v2:
- add missing ktime.h include
- switch to ktime_before() instead of !ktime_after()
- add link to user requiring this change to cover letter
- collect Tudor's Rb
- Link to v1: https://lore.kernel.org/r/20250321-acpm-atomic-v1-0-fb887bde7e61@linaro.org

---
André Draszik (2):
      firmware: exynos-acpm: use ktime APIs for timeout detection
      firmware: exynos-acpm: allow use during system shutdown

 drivers/firmware/samsung/exynos-acpm.c | 35 +++++++++++++++++++++++++---------
 1 file changed, 26 insertions(+), 9 deletions(-)
---
base-commit: 9388ec571cb1adba59d1cded2300eeb11827679c
change-id: 20250321-acpm-atomic-033775b051ef

Best regards,
-- 
André Draszik <andre.draszik@linaro.org>

[PATCH v2 1/2] firmware: exynos-acpm: use ktime APIs for timeout detection

[André Draszik]

acpm_dequeue_by_polling() uses a loop counter and assumes that each
iteration of the loop takes 20us. It may take longer, though, because
usleep_range() may sleep a different amount.

Switch to using ktime_get() / ktime_before() to detect the timeout
condition more reliably.

This change also makes the code easier to follow and it allows us to
adjust the sleep without having to adjust the loop counter exit
condition. This will come in useful in a follow-up patch that changes
the delays.

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>

---
v2:
* add missing ktime.h
* ktime_before() instead of !ktime_after() (Tudor)
---
 drivers/firmware/samsung/exynos-acpm.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index a85b2dbdd9f0d7b1f327f54a0a283e4f32587a98..542eaff03f9e39422a8c5345ca75e05c1710a9ee 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -15,6 +15,7 @@
 #include <linux/firmware/samsung/exynos-acpm-protocol.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
+#include <linux/ktime.h>
 #include <linux/mailbox/exynos-message.h>
 #include <linux/mailbox_client.h>
 #include <linux/module.h>
@@ -32,8 +33,7 @@
 
 #define ACPM_PROTOCOL_SEQNUM		GENMASK(21, 16)
 
-/* The unit of counter is 20 us. 5000 * 20 = 100 ms */
-#define ACPM_POLL_TIMEOUT		5000
+#define ACPM_POLL_TIMEOUT_US		(100 * USEC_PER_MSEC)
 #define ACPM_TX_TIMEOUT_US		500000
 
 #define ACPM_GS101_INITDATA_BASE	0xa000
@@ -284,12 +284,13 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
 				   const struct acpm_xfer *xfer)
 {
 	struct device *dev = achan->acpm->dev;
-	unsigned int cnt_20us = 0;
+	ktime_t timeout;
 	u32 seqnum;
 	int ret;
 
 	seqnum = FIELD_GET(ACPM_PROTOCOL_SEQNUM, xfer->txd[0]);
 
+	timeout = ktime_add_us(ktime_get(), ACPM_POLL_TIMEOUT_US);
 	do {
 		ret = acpm_get_rx(achan, xfer);
 		if (ret)
@@ -300,11 +301,10 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
 
 		/* Determined experimentally. */
 		usleep_range(20, 30);
-		cnt_20us++;
-	} while (cnt_20us < ACPM_POLL_TIMEOUT);
+	} while (ktime_before(ktime_get(), timeout));
 
-	dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx, cnt_20us = %d.\n",
-		achan->id, seqnum, achan->bitmap_seqnum[0], cnt_20us);
+	dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n",
+		achan->id, seqnum, achan->bitmap_seqnum[0]);
 
 	return -ETIME;
 }

-- 
2.49.0.395.g12beb8f557-goog

[PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[André Draszik]

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().

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: André Draszik <andre.draszik@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 542eaff03f9e39422a8c5345ca75e05c1710a9ee..4f65f7ef39b5fdbf5bb10f6ee9ffb78c5e34d8b2 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/ktime.h>
 #include <linux/mailbox/exynos-message.h>
 #include <linux/mailbox_client.h>
@@ -25,6 +27,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>
 
@@ -273,6 +276,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.
@@ -300,7 +314,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_before(ktime_get(), timeout));
 
 	dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n",

-- 
2.49.0.395.g12beb8f557-goog

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[Krzysztof Kozlowski]

On 24/03/2025 16:34, André Draszik wrote:
> +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.
> @@ -300,7 +314,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

... and what do you do if IRQs get disabled exactly in this moment? This
is just racy. You cannot check for a condition and assume it will be
valid for whatever time you want it to be valid.

What happens if system_state is changed to shutdown in this particular
moment? How did you prevent this from happening?

> +			usleep_range(20, 30);
>  	} while (ktime_before(ktime_get(), timeout));
>  
>  	dev_err(dev, "Timeout! ch:%u s:%u bitmap:%lx.\n",
> 


Best regards,
Krzysztof

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[André Draszik]

Hi Krzysztof,

On Tue, 2025-03-25 at 08:57 +0100, Krzysztof Kozlowski wrote:
> On 24/03/2025 16:34, André Draszik wrote:
> > +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.
> > @@ -300,7 +314,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
> 
> ... and what do you do if IRQs get disabled exactly in this moment? This
> is just racy. You cannot check for a condition and assume it will be
> valid for whatever time you want it to be valid.
> 
> What happens if system_state is changed to shutdown in this particular
> moment? How did you prevent this from happening?

Yes, and that's also what the I2C subsystem is doing, AFAICS, see
i2c_in_atomic_xfer_mode() and its use. This is to make a very
specific corner case work, similar to I2C which has to deal with
the same issue during shutdown.

Would you have a better suggestion?


Cheers,
Andre'

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[Krzysztof Kozlowski]

On 25/03/2025 09:01, André Draszik wrote:
> Hi Krzysztof,
> 
> On Tue, 2025-03-25 at 08:57 +0100, Krzysztof Kozlowski wrote:
>> On 24/03/2025 16:34, André Draszik wrote:
>>> +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.
>>> @@ -300,7 +314,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
>>
>> ... and what do you do if IRQs get disabled exactly in this moment? This
>> is just racy. You cannot check for a condition and assume it will be
>> valid for whatever time you want it to be valid.
>>
>> What happens if system_state is changed to shutdown in this particular
>> moment? How did you prevent this from happening?
> 
> Yes, and that's also what the I2C subsystem is doing, AFAICS, see
> i2c_in_atomic_xfer_mode() and its use. This is to make a very
> specific corner case work, similar to I2C which has to deal with
> the same issue during shutdown.

But they don't have a choice so they try to do the best to avoid
sleeping. And it is a subsystem, not a driver, which means their
patterns are sometimes special. Drivers should not replicate subsystem
workarounds.

> 
> Would you have a better suggestion?

Yes, you have a choice, you can always use udelay. Driver code is
supposed to be always correct.

Best regards,
Krzysztof

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[Tudor Ambarus]

On 3/25/25 8:07 AM, Krzysztof Kozlowski wrote:
> On 25/03/2025 09:01, André Draszik wrote:
>> Hi Krzysztof,
>>
>> On Tue, 2025-03-25 at 08:57 +0100, Krzysztof Kozlowski wrote:
>>> On 24/03/2025 16:34, André Draszik wrote:
>>>> +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.
>>>> @@ -300,7 +314,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
>>>
>>> ... and what do you do if IRQs get disabled exactly in this moment? This
>>> is just racy. You cannot check for a condition and assume it will be
>>> valid for whatever time you want it to be valid.
>>>
>>> What happens if system_state is changed to shutdown in this particular
>>> moment? How did you prevent this from happening?
>>
>> Yes, and that's also what the I2C subsystem is doing, AFAICS, see
>> i2c_in_atomic_xfer_mode() and its use. This is to make a very
>> specific corner case work, similar to I2C which has to deal with
>> the same issue during shutdown.
> 
> But they don't have a choice so they try to do the best to avoid
> sleeping. And it is a subsystem, not a driver, which means their
> patterns are sometimes special. Drivers should not replicate subsystem
> workarounds.
> 
>>
>> Would you have a better suggestion?
> 
> Yes, you have a choice, you can always use udelay. Driver code is
> supposed to be always correct.

Using udelay() is good enough for now. I see that downstream uses a
usleep_range(50, 100) and I'm concerned that we're going to waste lots
of cpu cyles once more and more clients get added.

If there's no concurrency on the ACPM queue mutexes at late system
shutdown, would it work to pass the don't sleep requirement from the
client to ACPM and use udelay only then?

Cheers,
ta

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[Krzysztof Kozlowski]

On 26/03/2025 08:24, Tudor Ambarus wrote:
>>>>
>>>> What happens if system_state is changed to shutdown in this particular
>>>> moment? How did you prevent this from happening?
>>>
>>> Yes, and that's also what the I2C subsystem is doing, AFAICS, see
>>> i2c_in_atomic_xfer_mode() and its use. This is to make a very
>>> specific corner case work, similar to I2C which has to deal with
>>> the same issue during shutdown.
>>
>> But they don't have a choice so they try to do the best to avoid
>> sleeping. And it is a subsystem, not a driver, which means their
>> patterns are sometimes special. Drivers should not replicate subsystem
>> workarounds.
>>
>>>
>>> Would you have a better suggestion?
>>
>> Yes, you have a choice, you can always use udelay. Driver code is
>> supposed to be always correct.
> 
> Using udelay() is good enough for now. I see that downstream uses a
> usleep_range(50, 100) and I'm concerned that we're going to waste lots
> of cpu cyles once more and more clients get added.


If this is going to be the case, then we can revisit it with some
numbers. Especially if this ACPM turns out to be a bus driver.

> 
> If there's no concurrency on the ACPM queue mutexes at late system
> shutdown, would it work to pass the don't sleep requirement from the
> client to ACPM and use udelay only then?


You mean the client will choose what sort of delay it expects (sleeping
or not)? That would work, but can you actually control it from the
client side?


Best regards,
Krzysztof

Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

[André Draszik]

On Wed, 2025-03-26 at 08:36 +0100, Krzysztof Kozlowski wrote:
> On 26/03/2025 08:24, Tudor Ambarus wrote:
> > > > > 
> > > > > What happens if system_state is changed to shutdown in this particular
> > > > > moment? How did you prevent this from happening?
> > > > 
> > > > Yes, and that's also what the I2C subsystem is doing, AFAICS, see
> > > > i2c_in_atomic_xfer_mode() and its use. This is to make a very
> > > > specific corner case work, similar to I2C which has to deal with
> > > > the same issue during shutdown.
> > > 
> > > But they don't have a choice so they try to do the best to avoid
> > > sleeping. And it is a subsystem, not a driver, which means their
> > > patterns are sometimes special. Drivers should not replicate subsystem
> > > workarounds.
> > > 
> > > > 
> > > > Would you have a better suggestion?
> > > 
> > > Yes, you have a choice, you can always use udelay. Driver code is
> > > supposed to be always correct.
> > 
> > Using udelay() is good enough for now. I see that downstream uses a
> > usleep_range(50, 100) and I'm concerned that we're going to waste lots
> > of cpu cyles once more and more clients get added.
> 
> 
> If this is going to be the case, then we can revisit it with some
> numbers. Especially if this ACPM turns out to be a bus driver.
> 
> > 
> > If there's no concurrency on the ACPM queue mutexes at late system
> > shutdown, would it work to pass the don't sleep requirement from the
> > client to ACPM and use udelay only then?
> 
> 
> You mean the client will choose what sort of delay it expects (sleeping
> or not)? That would work, but can you actually control it from the
> client side?

I can know this requirement from the RTC driver indeed
https://lore.kernel.org/all/20250323-s2mpg10-v1-29-d08943702707@linaro.org/
but a) I'm not sure how to do that with regmap, I'll have to have a look and
b) if the concern is that system_state is changed to shutdown while one
of the (other) drivers is using the ACPM (as per your earlier email), then
having a different API wouldn't help I believe.

Cheers,
Andre'