[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bba0a93a-8ec4-eda6-97f3-fb2ab0b9b503@gmail.com>
Date: Tue, 21 Apr 2020 18:08:57 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Jon Hunter <jonathanh@...dia.com>,
Thierry Reding <thierry.reding@...il.com>,
Laxman Dewangan <ldewangan@...dia.com>,
Wolfram Sang <wsa@...-dreams.de>,
Manikanta Maddireddy <mmaddireddy@...dia.com>,
Vidya Sagar <vidyas@...dia.com>
Cc: linux-i2c@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] i2c: tegra: Better handle case where CPU0 is busy
for a long time
21.04.2020 17:40, Jon Hunter пишет:
>
> On 21/04/2020 14:25, Dmitry Osipenko wrote:
>> 21.04.2020 12:49, Jon Hunter пишет:
>> ...
>>> I can try the above, but I agree it would be best to avoid messing with
>>> the suspend levels if possible.
>>
>> Will be awesome if you could try it and report back the result.
>>
>
> I gave it a try but suspend still fails.
Perhaps the RPM's -EACCES is returned from here:
https://elixir.free-electrons.com/linux/v5.7-rc2/source/drivers/base/power/runtime.c#L723
Which suggests that I2C is accessed after being suspended. I guess the
PCIe driver suspends after the I2C and somehow my change affected the
suspension order, although not sure how.
Jon, could you please try to enable PM logging and post the log? Please
also post log of the working kernel version, so that we could compare
the PM sequence.
Something like this should enable the logging: "echo 1 >
/sys/power/pm_trace" + there is RPM tracing.
Powered by blists - more mailing lists