All of lore.kernel.org
 help / color / mirror / Atom feed
From: andy.shevchenko@gmail.com
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
Subject: Re: pca953x issue when driving a DSI bridge
Date: Wed, 10 May 2023 20:25:31 +0300	[thread overview]
Message-ID: <ZFvTi3tQGUq2OCHi@surfacebook> (raw)
In-Reply-To: <0b3a257a-f1e5-ad86-4c69-93e038a33ce9@yoseli.org>

Wed, May 10, 2023 at 06:12:19PM +0200, Jean-Michel Hautbois kirjoitti:
> Hello there !
> 
> I have a custom board, based on a i.MX8mm SoC which has a MIPI-DSI to eDP
> bridge (namely, a TI sn65dsi86). This bridge has a DSI enable pin, which is
> basically its reset pin, connected to my PCA9539 GPIO expander.
> 
> The issue is that this pin can't be sleeping, and it is tested in the
> gpiod_set_value() function.
> 
> Here is where it fails in my dmesg:

...

> [   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.

> [   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_sn65dsi86]
> [   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 in 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 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_mode()
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.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-05-10 17:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10 16:12 pca953x issue when driving a DSI bridge Jean-Michel Hautbois
2023-05-10 17:25 ` andy.shevchenko [this message]
2023-05-10 20:18   ` Jean-Michel Hautbois
2023-05-11  7:49     ` Andy Shevchenko
2023-05-11 16:07       ` Jean-Michel Hautbois
2023-05-11 17:23         ` Andy Shevchenko

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=ZFvTi3tQGUq2OCHi@surfacebook \
    --to=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=jeanmichel.hautbois@yoseli.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.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 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.