Hi Andy,
On 10/05/2023 19:25, andy.shevchenko@xxxxxxxxx wrote:
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.
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_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 didn't know if it could be an issue or not, so I mentioned it but
sounds like a nonsense :-).
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.
Not sure to get the workaround proposal right...
I won't argue about i.MX8 ;-).
Thanks,
JM
