[PATCH v7 0/2] i2c: i2c-qcom-geni: serve transfers during early resume

[PATCH v7 0/2] i2c: i2c-qcom-geni: serve transfers during early resume

[Mukesh Kumar Savaliya]

I2C transfers issued during the resume_noirq phase can fail on systems
using GENI I2C controllers with GPI DMA.

Some devices require I2C communication before their resume sequence can
complete. One example is a USB Ethernet device attached through PCIe,
where device configuration must be restored over I2C before PCIe link
initialization can proceed. Since such accesses may occur from
resume_noirq(), the I2C controller and its DMA backend must be capable
of servicing transfers at that stage.

GENI I2C transfers depend on interrupt-driven completion. During system
resume, both the GENI controller interrupt and the GPI DMA interrupt may
remain unavailable until the normal interrupt resume phase, preventing
transfer completion during early resume. Additionally, runtime PM may
still be disabled when the I2C transfer path is entered, causing
pm_runtime_get_sync() to return -EACCES and preventing controller
resources from being enabled.

Address these issues by:
  - Allowing the GPI DMA interrupt to resume early and remain active
    across system suspend/resume transitions.
  - Allowing the GENI I2C interrupt to operate during early resume and
    restoring runtime PM when necessary from resume_noirq().

With these changes, GENI I2C transfers can complete successfully during
the resume_noirq phase, allowing dependent devices to finish their
resume sequence without waiting for the regular interrupt resume stage.

Co-developed-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Acked-by: Aniket Randive <aniketrandive@oss.qualcomm.com>
----
v6->v7 :
- Separated gpi.c file change into separate patch due to dma engine subsystem.
- Added cover letter as patches increased to two from one.
- Added acked-by tag recieved in V6 patch.
Link to V6: https://lore.kernel.org/all/b7404cdb-7c67-40b0-8124-d4977a8ed3cf@oss.qualcomm.com/

---
v5->v6 :
- Modified commit log to start with problem description as suggested by Bjorn.
- Moved to new implementation of the logic while earlier replied to comments on
  older design and considers latest fix added recently.
- Made change generic to I2C including GPI mode transfer, this was not done earlier.
- Changed email address to oss.qualcomm.com domain.
Link to V5: https://lore.kernel.org/lkml/20241227130236.755794-1-quic_msavaliy@quicinc.com/

---
v4->v5:
- Commit log enhanced considering Bjorn's comments by explaining PCIe usecase.
- Enhanced comment with reason when using pm_runtime_force_resume().
- Corrected IS_ENABLED(CONFIG_PM) condition inside geni_i2c_xfer().
- Improved debug log as per Bjorn's suggestions during suspend, resume.
- Reverted back comment before devm_request_irq().
Link to V4: https://lore.kernel.org/lkml/bd699719-4958-445a-a685-4b5f6a8ad81f@quicinc.com/

---
v3->v4 :
 - Enhanced commit log by explaining client usecase scenario during early resume.
 - Covered 'usage_count' of 'struct dev_pm_info' under CONFIG_PM to compile non PM CONFIG.
Link to V3: https://lore.kernel.org/all/20241119143031.3331753-1-quic_msavaliy@quicinc.com/T/

---
v2 -> v3:
 - Updated exact usecase and scenario in the commit log description.
 - Removed bulleted points from technical description, added details in free flow.
 - Used pm_runtime_force_resume/suspend() instead customized local implementation.
 - Added debug log after pm_runtime_force_suspend().
Link to V2: https://lore.kernel.org/lkml/202410132233.P25W2vKq-lkp@intel.com/T/

---
v1 -> v2:
 - Changed gi2c->se.dev to dev during dev_dbg() calls.
 - Addressed review comments from Andi and Bjorn.
 - Returned 0 instead garbage inside geni_i2c_force_resume().
 - Added comments explaining forced resume transfer when runtime PM
   remains disabled.
Link to V1: https://patches.linaro.org/project/linux-i2c/patch/20240328123743.1713696-1-quic_msavaliy@quicinc.com/

----
Mukesh Kumar Savaliya (2):
  i2c: qcom-geni: Handle runtime PM disabled state during early resume
  dmaengine: qcom-gpi: Keep GPI interrupt active during system resume

 drivers/dma/qcom/gpi.c             |  3 ++-
 drivers/i2c/busses/i2c-qcom-geni.c | 12 +++++++++++-
 2 files changed, 13 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH v7 1/2] i2c: qcom-geni: Handle runtime PM disabled state during early resume

[Mukesh Kumar Savaliya]

During the noirq resume phase, the GENI I2C controller may receive
transfer requests before runtime PM has been fully restored. In this
window pm_runtime_get_sync() can return -EACCES, causing transfers to
fail even though the controller is in the process of resuming.

Treat -EACCES as a transient condition and allow the transfer path to
proceed while preserving existing error handling for other runtime PM
failures.

Also enable runtime PM in the resume_noirq callback when it remains
disabled and allow the controller interrupt to remain active across
system suspend/resume transitions by requesting it with
IRQF_NO_SUSPEND and IRQF_EARLY_RESUME.

These changes prevent spurious transfer failures during early resume
and allow the adapter to become operational before the normal resume
phase completes.

Co-developed-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Acked-by: Aniket Randive <aniketrandive@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-qcom-geni.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 96dbf04138be..4bc00922cd97 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -917,6 +917,10 @@ static int geni_i2c_xfer(struct i2c_adapter *adap,
 	gi2c->err = 0;
 	reinit_completion(&gi2c->done);
 	ret = pm_runtime_get_sync(gi2c->se.dev);
+	if (ret == -EACCES) {
+		dev_warn(gi2c->se.dev, "Runtime PM is disabled:%d\n", ret);
+		ret = 0;
+	}
 	if (ret < 0) {
 		dev_err(gi2c->se.dev, "error turning SE resources:%d\n", ret);
 		pm_runtime_put_noidle(gi2c->se.dev);
@@ -1115,7 +1119,8 @@ static int geni_i2c_probe(struct platform_device *pdev)
 		return ret;
 
 	/* Keep interrupts disabled initially to allow for low-power modes */
-	ret = devm_request_irq(dev, gi2c->irq, geni_i2c_irq, IRQF_NO_AUTOEN,
+	ret = devm_request_irq(dev, gi2c->irq, geni_i2c_irq,
+			       IRQF_NO_AUTOEN | IRQF_NO_SUSPEND | IRQF_EARLY_RESUME,
 			       dev_name(dev), gi2c);
 	if (ret)
 		return dev_err_probe(dev, ret,
@@ -1223,7 +1228,12 @@ static int __maybe_unused geni_i2c_resume_noirq(struct device *dev)
 	if (ret)
 		return ret;
 
+	/* Enforced disable_depth = 0 to actually enable runtime PM during noirq phase */
+	if (!pm_runtime_enabled(dev))
+		pm_runtime_enable(dev);
+
 	i2c_mark_adapter_resumed(&gi2c->adap);
+
 	return 0;
 }
 
-- 
2.43.0

Re: [PATCH v7 1/2] i2c: qcom-geni: Handle runtime PM disabled state during early resume

[Praveen Talari]

Hi

On 23-07-2026 17:14, Mukesh Savaliya wrote:
>
>
> On 7/23/2026 4:24 PM, Praveen Talari wrote:
>> Hi mukesh
>>
>> On 23-07-2026 15:47, Mukesh Savaliya wrote:
>>> Hi Praveen,
>>>
>>> On 7/23/2026 3:32 PM, Praveen Talari wrote:
>>>> Hi Mukesh
>>>>
>>> [...]
>>>
>>>>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/ 
>>>>> busses/i2c-qcom-geni.c
>>>>> index 96dbf04138be..4bc00922cd97 100644
>>>>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>>>>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>>>>> @@ -917,6 +917,10 @@ static int geni_i2c_xfer(struct i2c_adapter 
>>>>> *adap,
>>>>>       gi2c->err = 0;
>>>>>       reinit_completion(&gi2c->done);
>>>>>       ret = pm_runtime_get_sync(gi2c->se.dev);
>>>>> +    if (ret == -EACCES) {
>>>>> +        dev_warn(gi2c->se.dev, "Runtime PM is disabled:%d\n", ret);
>>>>> +        ret = 0;
>>>>
>>>> Here it is clear that pm_runtime_get_sync() is returning -EACCES 
>>>> from the runtime PM framework,
>>>>
>>>> which indicates that the request was rejected before the runtime 
>>>> resume path could enable any resources.
>>>>
>>>>  From the rpm_resume() implementation:
>>>>
>>>> static int rpm_resume(struct device *dev, int rpmflags) 
>>>> __releases(&dev-  >power.lock) __acquires(&dev->power.lock) { [...] 
>>>> repeat: if (dev-  >power.runtime_error) { retval = -EINVAL; } else 
>>>> if (dev-  >power.disable_depth > 0) { [...] else retval = -EACCES; 
>>>> } if (retval) goto out; [...] out: if (parent && 
>>>> !dev->power.irq_safe) { spin_unlock_irq(&dev->power.lock); 
>>>> pm_runtime_put(parent); spin_lock_irq(&dev->power.lock); } 
>>>> trace_rpm_return_int(dev, _THIS_IP_, retval); return retval; }
>>>>
>>>> The -EACCES error is returned when runtime PM is disabled 
>>>> (disable_depth  > 0),
>>>>
>>>> causing the function to exit without invoking the device's runtime 
>>>> resume callback.
>>>>
>>>> As a result, no resource enablement is performed by the PM framework.
>>>>
>>>>
>>>> In your change, the error is effectively converted to ret = 0 and 
>>>> execution continues.
>>>>
>>>> How can we guarantee that the required resources have been enabled 
>>>> in this scenario?
>>>>
>>>> More importantly, where are those resources expected to be enabled 
>>>> if the runtime PM resume path was never executed?
>>>>
>>>
>>> This was answered in V6 already on 7/3 exactly at same place.
>>> Pasting below.
>>>
>>> ==
>>> > Why we are checking specific error code here? Why can't we use the 
>>> below error check directly?
>>> > if get sync itself is failed with pm runtime disabled then why we 
>>> are going ahead by making ret = 0 here? How you will make sure 
>>> resources are enabled?
>>>
>>> This reason is also mentioned in the commit log. we surely get - 
>>> EACCESS as runtime PM is disabled during no_irq resume phase. We 
>>> still need to serve the transfer, hence we need to override it.
>>
>> We should not get it and not go further since you are already enabled 
>> in system_resume_no_irq().
>>
>> I just need to understand why we need to proceed when we get -EACCESS 
>> as runtime PM .
>>
>
> ret = 0 was added because during early system resume, -EACCES from 
> pm_runtime_get_sync() indicates runtime PM is disabled, not that the 
> controller is unusable; treating it as an error would incorrectly 
> reject valid I2C transfers occurring during resume.


What is the purpose of enabling runtime PM during system resume? It is 
not clear how this helps, given that -EACCES can still be returned.


>
> Other than early PM time, we are not going to get -EACESS. So i don't 
> see any case where this will be a problem.
>>>
>>> Review geni_i2c_resume_noirq() to know what all we do to enable 
>>> resources. That's guaranteed and tested with system suspend/resume 
>>> test back to back and PCIe could do i2c transfer successfully.
>>> ==
>>>>
>>>> Thanks,
>>>>
>>>> Praveen Talari
>>>>
>>> Do not keep this thanks/regards here. only leave the comments.
>>>
>>>>> +    }
>>> [...]
>

Re: [PATCH v7 1/2] i2c: qcom-geni: Handle runtime PM disabled state during early resume

[Mukesh Savaliya]

On 7/24/2026 10:12 AM, Praveen Talari wrote:
> Hi
> 
> On 23-07-2026 17:14, Mukesh Savaliya wrote:
>>
>>
>> On 7/23/2026 4:24 PM, Praveen Talari wrote:
>>> Hi mukesh
>>>
>>> On 23-07-2026 15:47, Mukesh Savaliya wrote:
>>>> Hi Praveen,
>>>>
>>>> On 7/23/2026 3:32 PM, Praveen Talari wrote:
>>>>> Hi Mukesh
>>>>>
>>>> [...]
>>>>
>>>>>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/ 
>>>>>> busses/i2c-qcom-geni.c
>>>>>> index 96dbf04138be..4bc00922cd97 100644
>>>>>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>>>>>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>>>>>> @@ -917,6 +917,10 @@ static int geni_i2c_xfer(struct i2c_adapter 
>>>>>> *adap,
>>>>>>       gi2c->err = 0;
>>>>>>       reinit_completion(&gi2c->done);
>>>>>>       ret = pm_runtime_get_sync(gi2c->se.dev);
>>>>>> +    if (ret == -EACCES) {
>>>>>> +        dev_warn(gi2c->se.dev, "Runtime PM is disabled:%d\n", ret);
>>>>>> +        ret = 0;
>>>>>
>>>>> Here it is clear that pm_runtime_get_sync() is returning -EACCES 
>>>>> from the runtime PM framework,
>>>>>
>>>>> which indicates that the request was rejected before the runtime 
>>>>> resume path could enable any resources.
>>>>>
>>>>>  From the rpm_resume() implementation:
>>>>>
>>>>> static int rpm_resume(struct device *dev, int rpmflags) 
>>>>> __releases(&dev-  >power.lock) __acquires(&dev->power.lock) { [...] 
>>>>> repeat: if (dev-  >power.runtime_error) { retval = -EINVAL; } else 
>>>>> if (dev-  >power.disable_depth > 0) { [...] else retval = - 
>>>>> EACCES; } if (retval) goto out; [...] out: if (parent && !dev- 
>>>>> >power.irq_safe) { spin_unlock_irq(&dev->power.lock); 
>>>>> pm_runtime_put(parent); spin_lock_irq(&dev->power.lock); } 
>>>>> trace_rpm_return_int(dev, _THIS_IP_, retval); return retval; }
>>>>>
>>>>> The -EACCES error is returned when runtime PM is disabled 
>>>>> (disable_depth  > 0),
>>>>>
>>>>> causing the function to exit without invoking the device's runtime 
>>>>> resume callback.
>>>>>
>>>>> As a result, no resource enablement is performed by the PM framework.
>>>>>
>>>>>
>>>>> In your change, the error is effectively converted to ret = 0 and 
>>>>> execution continues.
>>>>>
>>>>> How can we guarantee that the required resources have been enabled 
>>>>> in this scenario?
>>>>>
>>>>> More importantly, where are those resources expected to be enabled 
>>>>> if the runtime PM resume path was never executed?
>>>>>
>>>>
>>>> This was answered in V6 already on 7/3 exactly at same place.
>>>> Pasting below.
>>>>
>>>> ==
>>>> > Why we are checking specific error code here? Why can't we use the 
>>>> below error check directly?
>>>> > if get sync itself is failed with pm runtime disabled then why we 
>>>> are going ahead by making ret = 0 here? How you will make sure 
>>>> resources are enabled?
>>>>
>>>> This reason is also mentioned in the commit log. we surely get - 
>>>> EACCESS as runtime PM is disabled during no_irq resume phase. We 
>>>> still need to serve the transfer, hence we need to override it.
>>>
>>> We should not get it and not go further since you are already enabled 
>>> in system_resume_no_irq().
>>>
>>> I just need to understand why we need to proceed when we get -EACCESS 
>>> as runtime PM .
>>>
>>
>> ret = 0 was added because during early system resume, -EACCES from 
>> pm_runtime_get_sync() indicates runtime PM is disabled, not that the 
>> controller is unusable; treating it as an error would incorrectly 
>> reject valid I2C transfers occurring during resume.
> 
> 
> What is the purpose of enabling runtime PM during system resume? It is 
> not clear how this helps, given that -EACCES can still be returned.
> 

I think you didn't get noirq_resume() change. if you review code, we do 
force_resume(), but that doesn't invoke transfer time runtime_resume() 
via pm_*_get_sync() call because device has runtime PM disabled.

Hence we need to call pm_runtime_enable(). In my testing, have seen that 
driver returning with -EACCESS if not overridden with ret = 0. That's 
the whole point. We need force resume and transfer to serve early resume 
transfer. Usecase demands this transfer without failure.

> 
>>
>> Other than early PM time, we are not going to get -EACESS. So i don't 
>> see any case where this will be a problem.
>>>>
>>>> Review geni_i2c_resume_noirq() to know what all we do to enable 
>>>> resources. That's guaranteed and tested with system suspend/resume 
>>>> test back to back and PCIe could do i2c transfer successfully.
>>>> ==
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Praveen Talari
>>>>>
>>>> Do not keep this thanks/regards here. only leave the comments.
>>>>
>>>>>> +    }
>>>> [...]
>>

Re: [PATCH v7 1/2] i2c: qcom-geni: Handle runtime PM disabled state during early resume

[Praveen Talari]

Hi Mukesh

On 24-07-2026 12:05, Mukesh Savaliya wrote:
>
>
> On 7/24/2026 10:12 AM, Praveen Talari wrote:
>> Hi
>>
>> On 23-07-2026 17:14, Mukesh Savaliya wrote:
>>>
>>>
>>> On 7/23/2026 4:24 PM, Praveen Talari wrote:
>>>> Hi mukesh
>>>>
>>>> On 23-07-2026 15:47, Mukesh Savaliya wrote:
>>>>> Hi Praveen,
>>>>>
>>>>> On 7/23/2026 3:32 PM, Praveen Talari wrote:
>>>>>> Hi Mukesh
>>>>>>
>>>>> [...]
>>>>>
>>>>>>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/ 
>>>>>>> busses/i2c-qcom-geni.c
>>>>>>> index 96dbf04138be..4bc00922cd97 100644
>>>>>>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>>>>>>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>>>>>>> @@ -917,6 +917,10 @@ static int geni_i2c_xfer(struct i2c_adapter 
>>>>>>> *adap,
>>>>>>>       gi2c->err = 0;
>>>>>>>       reinit_completion(&gi2c->done);
>>>>>>>       ret = pm_runtime_get_sync(gi2c->se.dev);
>>>>>>> +    if (ret == -EACCES) {
>>>>>>> +        dev_warn(gi2c->se.dev, "Runtime PM is disabled:%d\n", 
>>>>>>> ret);
>>>>>>> +        ret = 0;
>>>>>>
>>>>>> Here it is clear that pm_runtime_get_sync() is returning -EACCES 
>>>>>> from the runtime PM framework,
>>>>>>
>>>>>> which indicates that the request was rejected before the runtime 
>>>>>> resume path could enable any resources.
>>>>>>
>>>>>>  From the rpm_resume() implementation:
>>>>>>
>>>>>> static int rpm_resume(struct device *dev, int rpmflags) 
>>>>>> __releases(&dev-  >power.lock) __acquires(&dev->power.lock) { 
>>>>>> [...] repeat: if (dev-  >power.runtime_error) { retval = -EINVAL; 
>>>>>> } else if (dev-  >power.disable_depth > 0) { [...] else retval = 
>>>>>> - EACCES; } if (retval) goto out; [...] out: if (parent && !dev- 
>>>>>> >power.irq_safe) { spin_unlock_irq(&dev->power.lock); 
>>>>>> pm_runtime_put(parent); spin_lock_irq(&dev->power.lock); } 
>>>>>> trace_rpm_return_int(dev, _THIS_IP_, retval); return retval; }
>>>>>>
>>>>>> The -EACCES error is returned when runtime PM is disabled 
>>>>>> (disable_depth  > 0),
>>>>>>
>>>>>> causing the function to exit without invoking the device's 
>>>>>> runtime resume callback.
>>>>>>
>>>>>> As a result, no resource enablement is performed by the PM 
>>>>>> framework.
>>>>>>
>>>>>>
>>>>>> In your change, the error is effectively converted to ret = 0 and 
>>>>>> execution continues.
>>>>>>
>>>>>> How can we guarantee that the required resources have been 
>>>>>> enabled in this scenario?
>>>>>>
>>>>>> More importantly, where are those resources expected to be 
>>>>>> enabled if the runtime PM resume path was never executed?
>>>>>>
>>>>>
>>>>> This was answered in V6 already on 7/3 exactly at same place.
>>>>> Pasting below.
>>>>>
>>>>> ==
>>>>> > Why we are checking specific error code here? Why can't we use 
>>>>> the below error check directly?
>>>>> > if get sync itself is failed with pm runtime disabled then why 
>>>>> we are going ahead by making ret = 0 here? How you will make sure 
>>>>> resources are enabled?
>>>>>
>>>>> This reason is also mentioned in the commit log. we surely get - 
>>>>> EACCESS as runtime PM is disabled during no_irq resume phase. We 
>>>>> still need to serve the transfer, hence we need to override it.
>>>>
>>>> We should not get it and not go further since you are already 
>>>> enabled in system_resume_no_irq().
>>>>
>>>> I just need to understand why we need to proceed when we 
>>>> get -EACCESS as runtime PM .
>>>>
>>>
>>> ret = 0 was added because during early system resume, -EACCES from 
>>> pm_runtime_get_sync() indicates runtime PM is disabled, not that the 
>>> controller is unusable; treating it as an error would incorrectly 
>>> reject valid I2C transfers occurring during resume.
>>
>>
>> What is the purpose of enabling runtime PM during system resume? It 
>> is not clear how this helps, given that -EACCES can still be returned.
>>
>
> I think you didn't get noirq_resume() change. if you review code, we 
> do force_resume(), but that doesn't invoke transfer time 
> runtime_resume() via pm_*_get_sync() call because device has runtime 
> PM disabled.
>
> Hence we need to call pm_runtime_enable(). In my testing, have seen 
> that driver returning with -EACCESS if not overridden with ret = 0. 
> That's the whole point. We need force resume and transfer to serve 
> early resume transfer. Usecase demands this transfer without failure.
I have gone through  noirq_resume() change.

force_resume will be executed only if force_suspend executed otherwise 
it won't execute.

IMO, If PM runtime enabled for device, it won't return -EACCESS.

What is the purpose of enabling runtime PM in the system resume 
callback? We still appear to encounter -EACCES despite runtime PM being 
enabled there.

>
>>
>>>
>>> Other than early PM time, we are not going to get -EACESS. So i 
>>> don't see any case where this will be a problem.
>>>>>
>>>>> Review geni_i2c_resume_noirq() to know what all we do to enable 
>>>>> resources. That's guaranteed and tested with system suspend/resume 
>>>>> test back to back and PCIe could do i2c transfer successfully.
>>>>> ==
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Praveen Talari
>>>>>>
>>>>> Do not keep this thanks/regards here. only leave the comments.
>>>>>
>>>>>>> +    }
>>>>> [...]
>>>
>

Re: [PATCH v7 1/2] i2c: qcom-geni: Handle runtime PM disabled state during early resume

[Andi Shyti]

Hi Mukesh,

...

> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index 96dbf04138be..4bc00922cd97 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -917,6 +917,10 @@ static int geni_i2c_xfer(struct i2c_adapter *adap,
>  	gi2c->err = 0;
>  	reinit_completion(&gi2c->done);
>  	ret = pm_runtime_get_sync(gi2c->se.dev);
> +	if (ret == -EACCES) {
> +		dev_warn(gi2c->se.dev, "Runtime PM is disabled:%d\n", ret);
> +		ret = 0;
> +	}

I have to agree with Praveen here. Ignoring -EACCES is not safe:
geni_i2c_runtime_resume() is not guaranteed to have run in that
case.

Also, pm_runtime_force_resume() already re-enables runtime PM
before returning, so the additional pm_runtime_enable() is
unnecessary.

>  	if (ret < 0) {
>  		dev_err(gi2c->se.dev, "error turning SE resources:%d\n", ret);
>  		pm_runtime_put_noidle(gi2c->se.dev);
> @@ -1115,7 +1119,8 @@ static int geni_i2c_probe(struct platform_device *pdev)
>  		return ret;
>  
>  	/* Keep interrupts disabled initially to allow for low-power modes */
> -	ret = devm_request_irq(dev, gi2c->irq, geni_i2c_irq, IRQF_NO_AUTOEN,
> +	ret = devm_request_irq(dev, gi2c->irq, geni_i2c_irq,
> +			       IRQF_NO_AUTOEN | IRQF_NO_SUSPEND | IRQF_EARLY_RESUME,
>  			       dev_name(dev), gi2c);

IRQF_EARLY_RESUME and IRQF_NO_SUSPEND are reundant. Perhaps for
this use case we should leave only IRQF_EARLY_RESUME?

Thanks,
Andi

>  	if (ret)
>  		return dev_err_probe(dev, ret,

[PATCH v7 2/2] dmaengine: qcom-gpi: Keep GPI interrupt active during system resume

[Mukesh Kumar Savaliya]

GPI DMA clients may initiate transfers during the early stages of
system resume before the normal IRQ resume phase has completed.
However, the GPI interrupt is currently suspended during system
sleep, preventing transfer completion notifications from being
delivered until later in the resume sequence.

Request the GPI interrupt with IRQF_NO_SUSPEND and IRQF_EARLY_RESUME
to keep it available across suspend/resume transitions and allow
interrupt handling to resume during the noirq phase.

This ensures DMA completion events can be delivered to clients that
become operational before the normal resume phase completes

Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
Acked-by: Aniket Randive <aniketrandive@oss.qualcomm.com>
---
 drivers/dma/qcom/gpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
index a5055a6273af..29872b6cb2c7 100644
--- a/drivers/dma/qcom/gpi.c
+++ b/drivers/dma/qcom/gpi.c
@@ -615,7 +615,8 @@ static int gpi_config_interrupts(struct gpii *gpii, enum gpii_irq_settings setti
 
 	if (!gpii->configured_irq) {
 		ret = devm_request_irq(gpii->gpi_dev->dev, gpii->irq,
-				       gpi_handle_irq, IRQF_TRIGGER_HIGH,
+				       gpi_handle_irq,
+				       IRQF_TRIGGER_HIGH | IRQF_NO_SUSPEND | IRQF_EARLY_RESUME,
 				       "gpi-dma", gpii);
 		if (ret < 0) {
 			dev_err(gpii->gpi_dev->dev, "error request irq:%d ret:%d\n",
-- 
2.43.0

Re: [PATCH v7 2/2] dmaengine: qcom-gpi: Keep GPI interrupt active during system resume

[Andi Shyti]

Hi Mukesh,

On Thu, Jul 09, 2026 at 07:16:23PM +0530, Mukesh Kumar Savaliya wrote:
> GPI DMA clients may initiate transfers during the early stages of
> system resume before the normal IRQ resume phase has completed.
> However, the GPI interrupt is currently suspended during system
> sleep, preventing transfer completion notifications from being
> delivered until later in the resume sequence.
> 
> Request the GPI interrupt with IRQF_NO_SUSPEND and IRQF_EARLY_RESUME
> to keep it available across suspend/resume transitions and allow
> interrupt handling to resume during the noirq phase.
> 
> This ensures DMA completion events can be delivered to clients that
> become operational before the normal resume phase completes
> 
> Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>
> Acked-by: Aniket Randive <aniketrandive@oss.qualcomm.com>

shouldn't this patch come before patch 1?

Andi