Message-ID: <0b3a257a-f1e5-ad86-4c69-93e038a33ce9@yoseli.org>
Date:   Wed, 10 May 2023 18:12:19 +0200
From:   Jean-Michel Hautbois <jeanmichel.hautbois@...eli.org>
To:     linux-gpio@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, brgl@...ev.pl,
        linus.walleij@...aro.org
Subject: pca953x issue when driving a DSI bridge

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.096512] ------------[ cut here ]------------
[   11.102443] WARNING: CPU: 0 PID: 212 at 
../../../../../work-shared/lcx-imx8mm-1gw-r1-hpp/kernel-source/drivers/gpio/gpiolib.c:3131 
gpiod_set_value+0x5c/0xcc
[   11.116454] Modules linked in: ti_sn65dsi86(+) caamalg_desc 
crypto_engine ecdh_generic ecc brcmutil rng_core smsc authenc libdes 
cp210x smsc95xx cfg80211 drm_dp_aux_bus rfkill drm_display_helper 
phy_fsl_imx8m_p
cie rtc_rv3028 spi_imx caam hantro_vpu error v4l2_vp9 v4l2_h264 
v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
governor_userspace rtc_snvs videobuf2_common videodev imx_sdma 
imx8m_ddrc fsl_imx8_
ddr_perf imx8mm_thermal pwm_imx27 mc etnaviv gpu_sched crct10dif_ce 
imx_cpufreq_dt display_connector drm_kms_helper drm fuse ipv6 overlay
[   11.165624] CPU: 0 PID: 212 Comm: systemd-udevd Not tainted 
6.1.22-hpp-1gw #1
[   11.172763] Hardware name: Onegateway motherboard i.MX8MM (w/ slice 
test) (DT)
[   11.179983] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS 
BTYPE=--)
[   11.186944] pc : gpiod_set_value+0x5c/0xcc
[   11.191046] lr : ti_sn65dsi86_resume+0x4c/0x94 [ti_sn65dsi86]
[   11.196807] sp : ffff80000add35c0
[   11.200119] x29: ffff80000add35c0 x28: 0000000000000000 x27: 
0000000000000000
[   11.207258] x26: ffff0000c08b6148 x25: 0000000000000001 x24: 
ffff80000815ce60
[   11.214398] x23: 0000000000000000 x22: ffff0000c08b6104 x21: 
0000000000000000
[   11.221538] x20: 0000000000000001 x19: ffff0000c08b8c00 x18: 
ffffffffffffffff
[   11.228678] x17: 2e726f74616c7567 x16: ffff800008665b04 x15: 
00000000000004fb
[   11.235820] x14: 0000000000000000 x13: 0000000000000001 x12: 
0000000000000000
[   11.242959] x11: 0000000000000003 x10: 0000000000000b40 x9 : 
ffff80000add3470
[   11.250101] x8 : ffff0000c1339b60 x7 : ffff0000c0f54a00 x6 : 
0000000000000000
[   11.257242] x5 : 00000000410fd030 x4 : 0000000000c0000e x3 : 
0000000000000000
[   11.264380] x2 : 0000000000000000 x1 : ffff0000c08b8100 x0 : 
0000000000000001
[   11.271523] Call trace:
[   11.273968]  gpiod_set_value+0x5c/0xcc
[   11.277722]  ti_sn65dsi86_resume+0x4c/0x94 [ti_sn65dsi86]
[   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
[   11.337466]  __driver_probe_device+0x7c/0x190
[   11.341822]  driver_probe_device+0x3c/0x110
[   11.346006]  __driver_attach+0xf4/0x200
[   11.349842]  bus_for_each_dev+0x70/0xd0
[   11.353678]  driver_attach+0x24/0x30
[   11.357254]  bus_add_driver+0x17c/0x240
[   11.361088]  driver_register+0x78/0x130
[   11.364927]  i2c_register_driver+0x48/0xf0
[   11.369022]  ti_sn65dsi86_init+0x34/0x1000 [ti_sn65dsi86]
[   11.374432]  do_one_initcall+0x50/0x1d0
[   11.378271]  do_init_module+0x48/0x1d0
[   11.382022]  load_module+0x18d8/0x1df0
[   11.385772]  __do_sys_finit_module+0xac/0x130
[   11.390129]  __arm64_sys_finit_module+0x20/0x30
[   11.394660]  invoke_syscall+0x48/0x114
[   11.398410]  el0_svc_common.constprop.0+0xd4/0xfc
[   11.403117]  do_el0_svc+0x30/0xd0
[   11.406432]  el0_svc+0x2c/0x84
[   11.409491]  el0t_64_sync_handler+0xbc/0x140
[   11.413762]  el0t_64_sync+0x18c/0x190
[   11.417426] ---[ end trace 0000000000000000 ]---

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.

I don't know how to address this issue nicely and any thoughts is 
appreciated !

Thanks in advance !
JM

Powered by blists - more mailing lists