Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <0b3a257a-f1e5-ad86-4c69-93e038a33ce9@yoseli.org>
 <ZFvTi3tQGUq2OCHi@surfacebook> <32ecb9f3-1443-210c-0fc9-40891629e25a@yoseli.org>
In-Reply-To: <32ecb9f3-1443-210c-0fc9-40891629e25a@yoseli.org>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Thu, 11 May 2023 10:49:53 +0300
Message-ID: <CAHp75Vcsieiab8ks7yLwJvhjHTPv2qeCBJYjMOVYBJXmNhbTYQ@mail.gmail.com>
Subject: Re: pca953x issue when driving a DSI bridge
To:     Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
Cc:     linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        brgl@bgdev.pl, linus.walleij@linaro.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, May 10, 2023 at 11:18=E2=80=AFPM Jean-Michel Hautbois
<jeanmichel.hautbois@yoseli.org> wrote:
> On 10/05/2023 19:25, andy.shevchenko@gmail.com wrote:
> > Wed, May 10, 2023 at 06:12:19PM +0200, Jean-Michel Hautbois kirjoitti:

...

> >> [   11.273968]  gpiod_set_value+0x5c/0xcc
> >> [   11.277722]  ti_sn65dsi86_resume+0x4c/0x94 [ti_sn65dsi86]
> >
> > Your problem even worse, i.e. ->resume() might sleep.
>
> Indeed it is worse ;-).
>
> >> [   11.283131]  __rpm_callback+0x48/0x19c
> >> [   11.286885]  rpm_callback+0x6c/0x80
> >> [   11.290375]  rpm_resume+0x3b0/0x660
> >> [   11.293864]  __pm_runtime_resume+0x4c/0x90
> >> [   11.297960]  __device_attach+0x90/0x1e4
> >> [   11.301797]  device_initial_probe+0x14/0x20
> >> [   11.305980]  bus_probe_device+0x9c/0xa4
> >> [   11.309817]  device_add+0x3d8/0x820
> >> [   11.313308]  __auxiliary_device_add+0x40/0xa0
> >> [   11.317668]  ti_sn65dsi86_add_aux_device.isra.0+0xb0/0xe0 [ti_sn65d=
si86]
> >> [   11.324381]  ti_sn65dsi86_probe+0x20c/0x2ec [ti_sn65dsi86]
> >> [   11.329876]  i2c_device_probe+0x3b8/0x3f0
> >> [   11.333889]  really_probe+0xc0/0x3dc

...

> >> I suppose this is not a corner case and we may have other drivers and =
other
> >> boards connecting a GPIO which can sleep in a context where it should =
not ?
> >>
> >> I would like to add one thing: on this board, the expander is routed i=
n a
> >> way that makes it impossible to "sleep" as the reset is forced pulled-=
up and
> >> the power regulators are fixed and can't be stopped.
> >
> > Can you elaborate why you think there is a problem?
>
> I didn't know if it could be an issue or not, so I mentioned it but
> sounds like a nonsense :-).

Maybe not. I don't know that hardware, schematics and more information
is needed to understand. But I leave it to you.

> >> I don't know how to address this issue nicely and any thoughts is
> >> appreciated !
> >
> > As a workaround you can consider the code around i2c_in_atomic_xfer_mod=
e()
> > but since I have heard about i.MX8 so many negative remarks which makes=
 me
> > think that hardware is a train wreck and shouldn't be used at all.

> Not sure to get the workaround proposal right...

There are possibilities to have atomic I2C transfers, but as comment
says (on top of the above mentioned function) that is only for PMIC
communications at the system shutdown.

In your case I would try the easiest way (taking into account that
hardware connection is not preventing us from sleeping context), i.e.
check if the function that has GPIO call may sleep on its own and
simply replace gpiod_set_value() by gpiod_set_value_cansleep().

> I won't argue about i.MX8 ;-).


--=20
With Best Regards,
Andy Shevchenko