From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Wolfram Sang <wsa@kernel.org>,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Sam Protsenko <semen.protsenko@linaro.org>,
Rob Herring <robh@kernel.org>, Sven Peter <sven@svenpeter.dev>,
Jan Dabros <jsd@semihalf.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Tyrone Ting <kfting@nuvoton.com>, Arnd Bergmann <arnd@arndb.de>,
Olof Johansson <olof@lixom.net>,
Biju Das <biju.das.jz@bp.renesas.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Linux I2C <linux-i2c@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] i2c: Add Renesas RZ/V2M controller
Date: Fri, 8 Jul 2022 09:31:54 +0200 [thread overview]
Message-ID: <CAMuHMdX5UN61jZXksBjJs1skudt2B8uMLDVASLyqfnfrOWoS3Q@mail.gmail.com> (raw)
In-Reply-To: <TYYPR01MB7086B6281BCBA67BB6626333F5839@TYYPR01MB7086.jpnprd01.prod.outlook.com>
Hi Phil,
On Thu, Jul 7, 2022 at 8:47 PM Phil Edworthy <phil.edworthy@renesas.com> wrote:
> On 07 July 2022 18:46 Geert Uytterhoeven wrote:
> > On Thu, Jul 7, 2022 at 6:37 PM Phil Edworthy wrote:
> > > On 07 July 2022 08:21 Phil Edworthy wrote:
> > > > On 03 July 2022 16:17 Andy Shevchenko wrote:
> > > > > On Sun, Jul 03, 2022 at 10:41:45AM +0200, Geert Uytterhoeven wrote:
> > > > > > On Sat, Jul 2, 2022 at 1:51 PM Andy Shevchenko
> > > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > > On Fri, Jul 01, 2022 at 05:39:16PM +0100, Phil Edworthy wrote:
> > > > > > > > Yet another i2c controller from Renesas that is found on the
> > > > RZ/V2M
> > > > > > > > (r9a09g011) SoC. It can support only 100kHz and 400KHz
> > operation.
> > > > >
> > > > > ...
> > > > All other suggested changes are ok.
> > > >
> > > >
> > > > > > > > + pm_runtime_get_sync(dev);
> > > > > >
> > > > > > pm_runtime_resume_and_get() ;-)
> > > > >
> > > > > This makes sense only if we test for error. Otherwise the put might
> > > > > imbalance
> > > > > counter.
> > > > I added code to check the return value and to my surprise it returned
> > > > -EACCES.
> > > > Some digging later, this only happens when I have an i2c controller
> > > > enabled that doesn't have any children.
> > > >
> > > > rpm_resume() returns -EACCES [1] because runtime_status and
> > last_status
> > > > are set to RPM_SUSPENDED.
> > > >
> > > > The i2c controller that does have a child has runtime_status =
> > RPM_ACTIVE
> > > > as there is a call to pm_runtime_resume_and_get() on it due to the i2c
> > > > controller performing an i2c transfer for the slave device.
> > > >
> > > > I am currently struggling to work out why this is happening...
> > >
> > > First pm_suspend() works it's way down to __pm_runtime_disable():
> > > __pm_runtime_disable+0x134/0x1e0
> > > __device_suspend_late+0x28/0x1c4
> > > dpm_suspend_late+0x158/0x230
> > > suspend_devices_and_enter+0x1c8/0x4b4
> > > pm_suspend+0x210/0x28c
> > > At the end of which, runtime_status and last_status are both
> > RPM_SUSPENDED,
> > > and disable_depth = 1 [1]
> > >
> > > After that rzv2m_i2c_suspend() is called triggering the EACCES error
> > > condition [2]:
> > > rpm_resume+0x338/0x630
> > > __pm_runtime_resume+0x4c/0x80
> > > rzv2m_i2c_suspend+0x24/0xb0
> > > pm_generic_suspend_noirq+0x30/0x50
> > > genpd_finish_suspend+0xb0/0x130
> > > genpd_suspend_noirq+0x14/0x20
> > > __device_suspend_noirq+0x68/0x1d0
> > > dpm_noirq_suspend_devices+0x110/0x1dc
> > > dpm_suspend_noirq+0x24/0xa0
> > > suspend_devices_and_enter+0x2f0/0x4b4
> > > pm_suspend+0x210/0x28c
> > >
> > > I think using runtime PM from within driver suspend/resume is simply not
> > > supported. However I had some difficulty following the runtime PM code,
> > > so I could be wrong.
> >
> > Oh, it's a NOIRQ system sleep op. You indeed cannot use runtime resume
> > from such a callback, as the latter may sleep.
> Thanks for confirming this.
>
> I believe i2c controller driver should use NOIRQ system sleep ops as i2c
> children may need to send I2C messages during suspend, and the noirq
> sleep ops are called after the late sleep ops (used by some i2c children
> drivers).
>
> So should I just use clk_prepare_enable() and clk_prepare_enable()
> within the i2c controller's suspend and resume?
That's one option.
There's also i2c_mark_adapter_suspended().
And if you care about sending messages in atomic/noirq context,
you want to implement i2c_algorithm.master_xfer_atomic().
You may want to have a look at drivers/i2c/busses/i2c-sh_mobile.c,
which is used to control the PMIC on R-Car SoCs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
prev parent reply other threads:[~2022-07-08 7:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-01 16:39 [PATCH v3 0/2] i2c: Add new driver for Renesas RZ/V2M controller Phil Edworthy
2022-07-01 16:39 ` [PATCH v3 1/2] dt-bindings: i2c: Document RZ/V2M I2C controller Phil Edworthy
2022-07-01 16:39 ` [PATCH v3 2/2] i2c: Add Renesas RZ/V2M controller Phil Edworthy
2022-07-02 11:51 ` Andy Shevchenko
2022-07-03 8:41 ` Geert Uytterhoeven
2022-07-03 15:16 ` Andy Shevchenko
2022-07-07 7:21 ` Phil Edworthy
2022-07-07 16:37 ` Phil Edworthy
2022-07-07 17:45 ` Geert Uytterhoeven
2022-07-07 18:47 ` Phil Edworthy
2022-07-08 7:31 ` Geert Uytterhoeven [this message]
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=CAMuHMdX5UN61jZXksBjJs1skudt2B8uMLDVASLyqfnfrOWoS3Q@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=biju.das.jz@bp.renesas.com \
--cc=geert+renesas@glider.be \
--cc=jarkko.nikula@linux.intel.com \
--cc=jsd@semihalf.com \
--cc=kfting@nuvoton.com \
--cc=krzk@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=olof@lixom.net \
--cc=p.zabel@pengutronix.de \
--cc=phil.edworthy@renesas.com \
--cc=robh@kernel.org \
--cc=semen.protsenko@linaro.org \
--cc=sven@svenpeter.dev \
--cc=wsa@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).