Post suspend I2C registers have power on reset values. Before any
transfer initialize I2C registers to prevent I2C transfer timeout
and implement suspend and resume callbacks needed. Fix below errors
post suspend:
1) Tegra I2C transfer timeout during jetson tx2 resume:
[ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1
[ 27.633623] tegra-i2c 3160000.i2c: i2c transfer timed out
[ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
[ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
[ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
[ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs
[ 27.666194] PM: Device 1-0074 failed to resume: error -110
2) Tegra I2C transfer timeout error on jetson Xavier post resume.
Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_*
(suspended-resumed) help ensure i2c core calls from client are not
executed before i2c-tegra resume.
Signed-off-by: Bitan Biswas <[email protected]>
---
drivers/i2c/busses/i2c-tegra.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index ebaa78d..1dbba39 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1687,7 +1687,31 @@ static int tegra_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
+static int tegra_i2c_suspend(struct device *dev)
+{
+ struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
+
+ i2c_mark_adapter_suspended(&i2c_dev->adapter);
+
+ return 0;
+}
+
+static int tegra_i2c_resume(struct device *dev)
+{
+ struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
+ int err;
+
+ err = tegra_i2c_init(i2c_dev, false);
+ if (err)
+ return err;
+
+ i2c_mark_adapter_resumed(&i2c_dev->adapter);
+
+ return 0;
+}
+
static const struct dev_pm_ops tegra_i2c_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(tegra_i2c_suspend, tegra_i2c_resume)
SET_RUNTIME_PM_OPS(tegra_i2c_runtime_suspend, tegra_i2c_runtime_resume,
NULL)
};
--
2.7.4
07.06.2019 8:37, Bitan Biswas пишет:
> Post suspend I2C registers have power on reset values. Before any
> transfer initialize I2C registers to prevent I2C transfer timeout
> and implement suspend and resume callbacks needed. Fix below errors
> post suspend:
>
> 1) Tegra I2C transfer timeout during jetson tx2 resume:
>
> [ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1
> [ 27.633623] tegra-i2c 3160000.i2c: i2c transfer timed out
> [ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
> [ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
> [ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
> [ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs
> [ 27.666194] PM: Device 1-0074 failed to resume: error -110
>
> 2) Tegra I2C transfer timeout error on jetson Xavier post resume.
>
> Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_*
> (suspended-resumed) help ensure i2c core calls from client are not
> executed before i2c-tegra resume.
>
> Signed-off-by: Bitan Biswas <[email protected]>
> ---
> drivers/i2c/busses/i2c-tegra.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index ebaa78d..1dbba39 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -1687,7 +1687,31 @@ static int tegra_i2c_remove(struct platform_device *pdev)
> }
>
> #ifdef CONFIG_PM_SLEEP
> +static int tegra_i2c_suspend(struct device *dev)
> +{
> + struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
> +
> + i2c_mark_adapter_suspended(&i2c_dev->adapter);
> +
> + return 0;
> +}
> +
> +static int tegra_i2c_resume(struct device *dev)
> +{
> + struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
> + int err;
> +
> + err = tegra_i2c_init(i2c_dev, false);
> + if (err)
> + return err;
> +
> + i2c_mark_adapter_resumed(&i2c_dev->adapter);
> +
> + return 0;
> +}
> +
> static const struct dev_pm_ops tegra_i2c_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(tegra_i2c_suspend, tegra_i2c_resume)
> SET_RUNTIME_PM_OPS(tegra_i2c_runtime_suspend, tegra_i2c_runtime_resume,
> NULL)
> };
>
Thanks!
Reviewed-by: Dmitry Osipenko <[email protected]>
--
Dmitry
On 6/6/19 11:27 PM, Dmitry Osipenko wrote:
> 07.06.2019 8:37, Bitan Biswas пишет:
>> Post suspend I2C registers have power on reset values. Before any
>> transfer initialize I2C registers to prevent I2C transfer timeout
>> and implement suspend and resume callbacks needed. Fix below errors
>> post suspend:
>>
>> 1) Tegra I2C transfer timeout during jetson tx2 resume:
>>
>> [ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1
>> [ 27.633623] tegra-i2c 3160000.i2c: i2c transfer timed out
>> [ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
>> [ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
>> [ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
>> [ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs
>> [ 27.666194] PM: Device 1-0074 failed to resume: error -110
>>
>> 2) Tegra I2C transfer timeout error on jetson Xavier post resume.
>>
>> Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_*
>> (suspended-resumed) help ensure i2c core calls from client are not
>> executed before i2c-tegra resume.
>>
>> Signed-off-by: Bitan Biswas <[email protected]>
>> ---
>> drivers/i2c/busses/i2c-tegra.c | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index ebaa78d..1dbba39 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -1687,7 +1687,31 @@ static int tegra_i2c_remove(struct platform_device *pdev)
>> }
>>
>> #ifdef CONFIG_PM_SLEEP
>> +static int tegra_i2c_suspend(struct device *dev)
>> +{
>> + struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
>> +
>> + i2c_mark_adapter_suspended(&i2c_dev->adapter);
>> +
>> + return 0;
>> +}
>> +
>> +static int tegra_i2c_resume(struct device *dev)
>> +{
>> + struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
>> + int err;
>> +
>> + err = tegra_i2c_init(i2c_dev, false);
>> + if (err)
>> + return err;
>> +
>> + i2c_mark_adapter_resumed(&i2c_dev->adapter);
>> +
>> + return 0;
>> +}
>> +
>> static const struct dev_pm_ops tegra_i2c_pm = {
>> + SET_SYSTEM_SLEEP_PM_OPS(tegra_i2c_suspend, tegra_i2c_resume)
>> SET_RUNTIME_PM_OPS(tegra_i2c_runtime_suspend, tegra_i2c_runtime_resume,
>> NULL)
>> };
>>
>
> Thanks!
>
> Reviewed-by: Dmitry Osipenko <[email protected]>
>
Please get back if there is/are any further review comment(s) for below
patch.
http://patchwork.ozlabs.org/patch/1111570/
-Thanks,
Bitan
On Thu, Jun 06, 2019 at 10:37:47PM -0700, Bitan Biswas wrote:
> Post suspend I2C registers have power on reset values. Before any
> transfer initialize I2C registers to prevent I2C transfer timeout
> and implement suspend and resume callbacks needed. Fix below errors
> post suspend:
>
> 1) Tegra I2C transfer timeout during jetson tx2 resume:
>
> [ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1
> [ 27.633623] tegra-i2c 3160000.i2c: i2c transfer timed out
> [ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
> [ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
> [ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
> [ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs
> [ 27.666194] PM: Device 1-0074 failed to resume: error -110
>
> 2) Tegra I2C transfer timeout error on jetson Xavier post resume.
>
> Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_*
> (suspended-resumed) help ensure i2c core calls from client are not
> executed before i2c-tegra resume.
>
> Signed-off-by: Bitan Biswas <[email protected]>
Applied to for-next, thanks!
Without a maintainer ack, this is an exception this time. Should we add
Dmitry as another maintainer or reviewer at least?
On 6/14/19 2:11 PM, Wolfram Sang wrote:
> On Thu, Jun 06, 2019 at 10:37:47PM -0700, Bitan Biswas wrote:
>> Post suspend I2C registers have power on reset values. Before any
>> transfer initialize I2C registers to prevent I2C transfer timeout
>> and implement suspend and resume callbacks needed. Fix below errors
>> post suspend:
>>
>> 1) Tegra I2C transfer timeout during jetson tx2 resume:
>>
>> [ 27.520613] pca953x 1-0074: calling pca953x_resume+0x0/0x1b0 @ 2939, parent: i2c-1
>> [ 27.633623] tegra-i2c 3160000.i2c: i2c transfer timed out
>> [ 27.639162] pca953x 1-0074: Unable to sync registers 0x3-0x5. -110
>> [ 27.645336] pca953x 1-0074: Failed to sync GPIO dir registers: -110
>> [ 27.651596] PM: dpm_run_callback(): pca953x_resume+0x0/0x1b0 returns -110
>> [ 27.658375] pca953x 1-0074: pca953x_resume+0x0/0x1b0 returned -110 after 127152 usecs
>> [ 27.666194] PM: Device 1-0074 failed to resume: error -110
>>
>> 2) Tegra I2C transfer timeout error on jetson Xavier post resume.
>>
>> Remove i2c bus lock-unlock calls in resume callback as i2c_mark_adapter_*
>> (suspended-resumed) help ensure i2c core calls from client are not
>> executed before i2c-tegra resume.
>>
>> Signed-off-by: Bitan Biswas <[email protected]>
>
> Applied to for-next, thanks!
>
> Without a maintainer ack, this is an exception this time. Should we add
> Dmitry as another maintainer or reviewer at least?
>
I shall followup with Maintainer for ACK in future I2C tegra patches.
Probably maintainers or reviewers should comment here.
> > Without a maintainer ack, this is an exception this time. Should we add
> > Dmitry as another maintainer or reviewer at least?
> >
> I shall followup with Maintainer for ACK in future I2C tegra patches.
This comment was not directed at you, sorry if that was not clear. It
was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
interested).
15.06.2019 7:54, Wolfram Sang пишет:
>
>>> Without a maintainer ack, this is an exception this time. Should we add
>>> Dmitry as another maintainer or reviewer at least?
>>>
>> I shall followup with Maintainer for ACK in future I2C tegra patches.
>
> This comment was not directed at you, sorry if that was not clear. It
> was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
> interested).
>
I don't mind at all to review and test patches for the driver and can propose myself
as a reviewer if that helps and if there are no objections from the Tegra maintainers.
My primary interest is to have my devices working after next kernel update, but I also
like to review patches in general if they are touching area that I'm familiar with.
On Sun, Jun 16, 2019 at 04:56:06PM +0300, Dmitry Osipenko wrote:
> 15.06.2019 7:54, Wolfram Sang пишет:
> >
> >>> Without a maintainer ack, this is an exception this time. Should we add
> >>> Dmitry as another maintainer or reviewer at least?
> >>>
> >> I shall followup with Maintainer for ACK in future I2C tegra patches.
> >
> > This comment was not directed at you, sorry if that was not clear. It
> > was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
> > interested).
> >
>
> I don't mind at all to review and test patches for the driver and can propose myself
> as a reviewer if that helps and if there are no objections from the Tegra maintainers.
> My primary interest is to have my devices working after next kernel update, but I also
> like to review patches in general if they are touching area that I'm familiar with.
No objection from me.
Thierry
On Sat, Jun 15, 2019 at 06:54:05AM +0200, Wolfram Sang wrote:
>
> > > Without a maintainer ack, this is an exception this time. Should we add
> > > Dmitry as another maintainer or reviewer at least?
> > >
> > I shall followup with Maintainer for ACK in future I2C tegra patches.
>
> This comment was not directed at you, sorry if that was not clear. It
> was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
> interested).
I thought I had already acked this. I've certainly been testing this
since I carry it in a local tree. So for what it's worth:
Tested-by: Thierry Reding <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Bitan, I don't mind getting the patches to the corporate email address,
but please make sure to also always include the gmail address when
sending patches to the public mailing lists. My workflow is somewhat
quirky that way because I work remotely and for historical reasons.
Thierry
17.06.2019 10:02, Thierry Reding пишет:
> On Sun, Jun 16, 2019 at 04:56:06PM +0300, Dmitry Osipenko wrote:
>> 15.06.2019 7:54, Wolfram Sang пишет:
>>>
>>>>> Without a maintainer ack, this is an exception this time. Should we add
>>>>> Dmitry as another maintainer or reviewer at least?
>>>>>
>>>> I shall followup with Maintainer for ACK in future I2C tegra patches.
>>>
>>> This comment was not directed at you, sorry if that was not clear. It
>>> was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
>>> interested).
>>>
>>
>> I don't mind at all to review and test patches for the driver and can propose myself
>> as a reviewer if that helps and if there are no objections from the Tegra maintainers.
>> My primary interest is to have my devices working after next kernel update, but I also
>> like to review patches in general if they are touching area that I'm familiar with.
>
> No objection from me.
Thanks! I guess the same from Laxman and Jon?
I'll prepare the patch to add myself as a reviewer.
On 6/17/19 12:09 AM, Thierry Reding wrote:
> On Sat, Jun 15, 2019 at 06:54:05AM +0200, Wolfram Sang wrote:
>>
>>>> Without a maintainer ack, this is an exception this time. Should we add
>>>> Dmitry as another maintainer or reviewer at least?
>>>>
>>> I shall followup with Maintainer for ACK in future I2C tegra patches.
>>
>> This comment was not directed at you, sorry if that was not clear. It
>> was more for Laxman, Thierry, Jonathan, and Dmitry (if he is
>> interested).
>
> I thought I had already acked this. I've certainly been testing this
> since I carry it in a local tree. So for what it's worth:
>
> Tested-by: Thierry Reding <[email protected]>
> Acked-by: Thierry Reding <[email protected]>
>
> Bitan, I don't mind getting the patches to the corporate email address,
> but please make sure to also always include the gmail address when
> sending patches to the public mailing lists. My workflow is somewhat
> quirky that way because I work remotely and for historical reasons.
I shall put both email addresses going forward.
-regards,
Bitan