All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bitan Biswas <bbiswas@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	Thierry Reding <treding@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-i2c@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Shardar Mohammed <smohammed@nvidia.com>,
	Sowjanya Komatineni <skomatineni@nvidia.com>,
	Mantravadi Karthik <mkarthik@nvidia.com>
Subject: Re: [PATCH V1] i2c: busses: tegra: Add suspend-resume support
Date: Thu, 6 Jun 2019 06:55:44 -0700	[thread overview]
Message-ID: <c88b736e-47e0-43ca-b859-900936f94715@nvidia.com> (raw)
In-Reply-To: <d5803f1d-0895-08b8-4851-cd8afad830c6@gmail.com>



On 6/6/19 4:52 AM, Dmitry Osipenko wrote:
> 06.06.2019 8:43, Bitan Biswas пишет:
>>
>>
>> On 5/31/19 5:43 AM, Dmitry Osipenko wrote:
>>> 31.05.2019 11:50, Bitan Biswas пишет:
>>>>
>>>>
>>>> On 5/30/19 4:27 AM, Dmitry Osipenko wrote:
>>>>> 30.05.2019 8:55, 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.
>>>>>>
>>>>>> Signed-off-by: Bitan Biswas <bbiswas@nvidia.com>
>>>>>> ---
>>>>>>     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..f6a377f 100644
>>>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>>>> @@ -1687,9 +1687,33 @@ 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 ret;
>>>>>> +
>>>>>> +    i2c_lock_bus(&i2c_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
>>>>>> +    ret = tegra_i2c_init(i2c_dev, false);
>>>>>> +    i2c_unlock_bus(&i2c_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
>>>>>
>>>>> Why the locking is needed here?
>>>>
>>>> async resume could result in stress test issues if some client accesses
>>>> the i2c instance. This ensures the i2c instance is locked till the
>>>> initialization is complete.
>>>
>>> 1) This doesn't make much sense.. if client could access I2C during of
>>> tegra_i2c_init execution, then what stops it to perform the access
>>> before the lock is taken?
>> Client resumes will start after I2C instance resume because of driver
>> dependency. Since lock is the first call in i2c-tegra I believe I2C
>> calls of client will not start.
> 
> You're incorrectly assuming that client can start resuming in the middle
> of the controller's resume process. I2C client's resume won't start
> until tegra_i2c_resume() is finished completely. That is because child
> drivers are resumed only after theirs parent is ready and this is
> guaranteed by the drivers core.
> 
Agreed.

-regards,
  Bitan

WARNING: multiple messages have this Message-ID (diff)
From: Bitan Biswas <bbiswas@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	Thierry Reding <treding@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	<linux-i2c@vger.kernel.org>, <linux-tegra@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: Shardar Mohammed <smohammed@nvidia.com>,
	Sowjanya Komatineni <skomatineni@nvidia.com>,
	Mantravadi Karthik <mkarthik@nvidia.com>
Subject: Re: [PATCH V1] i2c: busses: tegra: Add suspend-resume support
Date: Thu, 6 Jun 2019 06:55:44 -0700	[thread overview]
Message-ID: <c88b736e-47e0-43ca-b859-900936f94715@nvidia.com> (raw)
In-Reply-To: <d5803f1d-0895-08b8-4851-cd8afad830c6@gmail.com>



On 6/6/19 4:52 AM, Dmitry Osipenko wrote:
> 06.06.2019 8:43, Bitan Biswas пишет:
>>
>>
>> On 5/31/19 5:43 AM, Dmitry Osipenko wrote:
>>> 31.05.2019 11:50, Bitan Biswas пишет:
>>>>
>>>>
>>>> On 5/30/19 4:27 AM, Dmitry Osipenko wrote:
>>>>> 30.05.2019 8:55, 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.
>>>>>>
>>>>>> Signed-off-by: Bitan Biswas <bbiswas@nvidia.com>
>>>>>> ---
>>>>>>     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..f6a377f 100644
>>>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>>>> @@ -1687,9 +1687,33 @@ 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 ret;
>>>>>> +
>>>>>> +    i2c_lock_bus(&i2c_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
>>>>>> +    ret = tegra_i2c_init(i2c_dev, false);
>>>>>> +    i2c_unlock_bus(&i2c_dev->adapter, I2C_LOCK_ROOT_ADAPTER);
>>>>>
>>>>> Why the locking is needed here?
>>>>
>>>> async resume could result in stress test issues if some client accesses
>>>> the i2c instance. This ensures the i2c instance is locked till the
>>>> initialization is complete.
>>>
>>> 1) This doesn't make much sense.. if client could access I2C during of
>>> tegra_i2c_init execution, then what stops it to perform the access
>>> before the lock is taken?
>> Client resumes will start after I2C instance resume because of driver
>> dependency. Since lock is the first call in i2c-tegra I believe I2C
>> calls of client will not start.
> 
> You're incorrectly assuming that client can start resuming in the middle
> of the controller's resume process. I2C client's resume won't start
> until tegra_i2c_resume() is finished completely. That is because child
> drivers are resumed only after theirs parent is ready and this is
> guaranteed by the drivers core.
> 
Agreed.

-regards,
  Bitan

  reply	other threads:[~2019-06-06 13:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30  5:55 [PATCH V1] i2c: busses: tegra: Add suspend-resume support Bitan Biswas
2019-05-30  5:55 ` Bitan Biswas
2019-05-30 11:27 ` Dmitry Osipenko
2019-05-31  8:50   ` Bitan Biswas
2019-05-31  8:50     ` Bitan Biswas
2019-05-31 12:43     ` Dmitry Osipenko
2019-06-06  5:43       ` Bitan Biswas
2019-06-06  5:43         ` Bitan Biswas
2019-06-06 11:52         ` Dmitry Osipenko
2019-06-06 13:55           ` Bitan Biswas [this message]
2019-06-06 13:55             ` Bitan Biswas

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=c88b736e-47e0-43ca-b859-900936f94715@nvidia.com \
    --to=bbiswas@nvidia.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mkarthik@nvidia.com \
    --cc=skomatineni@nvidia.com \
    --cc=smohammed@nvidia.com \
    --cc=treding@nvidia.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.