| Message ID | 20230303145138.29233-1-jagan@amarulasolutions.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Add Samsung MIPI DSIM bridge | expand |
Hi Jagan, On 03.03.2023 15:51, Jagan Teki wrote: > This series supports common bridge support for Samsung MIPI DSIM > which is used in Exynos and i.MX8MM SoC's. > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > Inki Dae: please note that this series added on top of exynos-drm-next > since few exynos dsi changes are not been part of drm-misc-next. > Request you to pick these via exynos-drm-next, or let me know if you > have any comments? I gave it a try on Exynos TM2e and unfortunately it nukes again: exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) Unable to handle kernel paging request at virtual address 003d454d414e5675 ... [003d454d414e5675] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 Hardware name: Samsung TM2E board (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_connector_list_iter_next+0x58/0x100 lr : drm_connector_list_iter_next+0x2c/0x100 sp : ffff80000bbab910 ... Call trace: drm_connector_list_iter_next+0x58/0x100 drm_mode_config_reset+0xfc/0x144 exynos_drm_bind+0x160/0x1b8 try_to_bring_up_aggregate_device+0x168/0x1d4 __component_add+0xa8/0x170 component_add+0x14/0x20 hdmi_probe+0x3fc/0x6d4 platform_probe+0x68/0xd8 really_probe+0x148/0x2b4 __driver_probe_device+0x78/0xe0 driver_probe_device+0xd8/0x160 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x84/0xe0 __device_attach+0xa8/0x1b0 device_initial_probe+0x14/0x20 bus_probe_device+0xb0/0xb4 deferred_probe_work_func+0x8c/0xc8 process_one_work+0x288/0x6c8 worker_thread+0x24c/0x450 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: 54000580 d1008061 f90006c1 9100c064 (b9403061) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x460002,0e3c0400,0000421b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]--- The debugging saga strikes again. I will try to analyze this on Monday... > Patch 0001 - 0002: find child DSI bridge and panel > > Patch 0003 - 0004: optional PHY, PMS_P offset > > Patch 0005 : introduce hw_type > > Patch 0006 : fixing host init > > Patch 0007 : atomic_check > > Patch 0008 : input_bus_flags > > Patch 0009 : atomic_get_input_bus_fmts > > Patch 0010 - 0011: component vs bridge > > Patch 0012 : DSIM bridge > > Patch 0013 - 0014: i.MX8M Mini/Nano > > Patch 0015 - 0016: i.MX8M Plus > > Changes for v15: > - drop drm_of helpers > - re-added find DSI bridge/Panel helper in dsim > - collect RB from Marek V > - fixed leading underscore in function names > - commit messages updated > - rebased on exynos-drm-next > > Changes for v13: > - remove devm call for DSI panel or bridge finding > - rebased on drm-misc-next > > Changes for v12: > - collect RB from Marek V > - add te_irq_handler hook > - fix comments from Marek V > - update atomic_get_input_bus_fmts logic > > Changes for v11: > - collect RB from Frieder Schrempf > - collect ACK from Rob > - collect ACK from Robert > - fix BIT macro replacements > - fix checkpatch --strict warnings > - fix unneeded commit text > - drop extra lines > > Changes for v10: > - rebase on drm-misc-next > - add drm_of_dsi_find_panel_or_bridge > - add devm_drm_of_dsi_get_bridge > - fix host initialization (Thanks to Marek Szyprowski) > - rearrange the tiny patches for easy to review > - update simple names for enum hw_type > - add is_hw_exynos macro > - rework on commit messages > > Changes for v9: > - rebase on drm-misc-next > - drop drm bridge attach fix for Exynos > - added prepare_prev_first flag > - added pre_enable_prev_first flag > - fix bridge chain order for exynos > - added fix for Exynos host init for first DSI transfer > - added MEDIA_BUS_FMT_FIXED > - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt > list is unsupported. > - added MEDIA_BUS_FMT_YUYV10_1X20 > - added MEDIA_BUS_FMT_YUYV12_1X24 > > Changes for v8: > * fixed comment lines > * fixed commit messages > * fixed video mode bits > * collect Marek Ack > * fixed video mode bit names > * update input formats logic > * added imx8mplus support > > Changes for v7: > * fix the drm bridge attach chain for exynos drm dsi driver > * fix the hw_type checking logic > > Changes for v6: > * handle previous bridge for exynos dsi while attaching bridge > > Changes for v5: > * bridge changes to support multi-arch > * updated and clear commit messages > * add hw_type via plat data > * removed unneeded quirk > * rebased on linux-next > > Changes for v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > * update init handling to ensure host init done on first cmd transfer > > Changes for v3: > * fix the mult-arch build > * fix dsi host init > * updated commit messages > > Changes for v2: > * fix bridge handling > * fix dsi host init > * correct the commit messages > > Tested in Engicam i.Core MX8M Mini SoM. > > Repo: > https://protect2.fireeye.com/v1/url?k=43fc0c46-2281e43e-43fd8709-74fe485fffb1-f84e6959aef8bb31&q=1&e=008cbb56-9344-43e4-903f-5547c72a3ade&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm-dsi-v15 > > v13: > https://lore.kernel.org/all/20230227113925.875425-1-jagan@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (14): > drm: exynos: dsi: Drop explicit call to bridge detach > drm: exynos: dsi: Lookup OF-graph or Child node devices > drm: exynos: dsi: Mark PHY as optional > drm: exynos: dsi: Add platform PLL_P (PMS_P) offset > drm: exynos: dsi: Introduce hw_type platform data > drm: exynos: dsi: Add atomic check > drm: exynos: dsi: Add input_bus_flags > drm: exynos: dsi: Add atomic_get_input_bus_fmts > drm: exynos: dsi: Consolidate component and bridge > drm: exynos: dsi: Add host helper for te_irq_handler > drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge > dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support > drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support > dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support > > Marek Szyprowski (1): > drm: exynos: dsi: Handle proper host initialization > > Marek Vasut (1): > drm: bridge: samsung-dsim: Add i.MX8M Plus support > > .../bindings/display/exynos/exynos_dsim.txt | 2 + > MAINTAINERS | 9 + > drivers/gpu/drm/bridge/Kconfig | 12 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 1965 +++++++++++++++++ > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1817 +-------------- > include/drm/bridge/samsung-dsim.h | 115 + > 8 files changed, 2190 insertions(+), 1732 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c > create mode 100644 include/drm/bridge/samsung-dsim.h > Best regards
Hi Marek, On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi Jagan, > > On 03.03.2023 15:51, Jagan Teki wrote: > > This series supports common bridge support for Samsung MIPI DSIM > > which is used in Exynos and i.MX8MM SoC's. > > > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > > > Inki Dae: please note that this series added on top of exynos-drm-next > > since few exynos dsi changes are not been part of drm-misc-next. > > Request you to pick these via exynos-drm-next, or let me know if you > > have any comments? > > I gave it a try on Exynos TM2e and unfortunately it nukes again: > > exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) > Unable to handle kernel paging request at virtual address 003d454d414e5675 > ... > [003d454d414e5675] address between user and kernel address ranges > Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP > Modules linked in: > CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 > Hardware name: Samsung TM2E board (DT) > Workqueue: events_unbound deferred_probe_work_func > pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : drm_connector_list_iter_next+0x58/0x100 > lr : drm_connector_list_iter_next+0x2c/0x100 > sp : ffff80000bbab910 > ... > Call trace: > drm_connector_list_iter_next+0x58/0x100 > drm_mode_config_reset+0xfc/0x144 > exynos_drm_bind+0x160/0x1b8 > try_to_bring_up_aggregate_device+0x168/0x1d4 > __component_add+0xa8/0x170 > component_add+0x14/0x20 > hdmi_probe+0x3fc/0x6d4 > platform_probe+0x68/0xd8 > really_probe+0x148/0x2b4 > __driver_probe_device+0x78/0xe0 > driver_probe_device+0xd8/0x160 > __device_attach_driver+0xb8/0x138 > bus_for_each_drv+0x84/0xe0 > __device_attach+0xa8/0x1b0 > device_initial_probe+0x14/0x20 > bus_probe_device+0xb0/0xb4 > deferred_probe_work_func+0x8c/0xc8 > process_one_work+0x288/0x6c8 > worker_thread+0x24c/0x450 > kthread+0x118/0x11c > ret_from_fork+0x10/0x20 This looks not related to dsi to me since there is no exynos_drm_dsi call in the trace. look hdmi related. Moreover, I think the exynos dsi worked well on v10 and I couldn't find any potential differences in terms of call flow change. https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 Please let me know, thanks! Jagan.
Hi Jagan, > -----Original Message----- > From: Jagan Teki <jagan@amarulasolutions.com> > Sent: Friday, March 3, 2023 11:51 PM > To: Andrzej Hajda <andrzej.hajda@intel.com>; Inki Dae <inki.dae@samsung.com>; > Marek Szyprowski <m.szyprowski@samsung.com>; Neil Armstrong > <neil.armstrong@linaro.org>; Marek Vasut <marex@denx.de>; Maxime Ripard > <mripard@kernel.org> > Cc: Seung-Woo Kim <sw0312.kim@samsung.com>; Kyungmin Park > <kyungmin.park@samsung.com>; Frieder Schrempf <frieder.schrempf@kontron.de>; > Tim Harvey <tharvey@gateworks.com>; Adam Ford <aford173@gmail.com>; Matteo > Lisi <matteo.lisi@engicam.com>; dri-devel@lists.freedesktop.org; linux- > samsung-soc@vger.kernel.org; linux-amarula <linux- > amarula@amarulasolutions.com>; Jagan Teki <jagan@amarulasolutions.com> > Subject: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge > > This series supports common bridge support for Samsung MIPI DSIM > which is used in Exynos and i.MX8MM SoC's. > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > Inki Dae: please note that this series added on top of exynos-drm-next > since few exynos dsi changes are not been part of drm-misc-next. > Request you to pick these via exynos-drm-next, or let me know if you > have any comments? Seems some issue Marek found on testing. If fixed then I will try to pick this patch series up. To Andrzej, Neil, Robert and Laurent. Could you give me any comment to below patch, [drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge] : https://www.spinics.net/lists/dri-devel/msg385731.html If you could kindly provide me with an Acked-by or Signed-off-by after review, it would greatly assist me in picking up this patch series for upstream. Thanks, Inki Dae > > Patch 0001 - 0002: find child DSI bridge and panel > > Patch 0003 - 0004: optional PHY, PMS_P offset > > Patch 0005 : introduce hw_type > > Patch 0006 : fixing host init > > Patch 0007 : atomic_check > > Patch 0008 : input_bus_flags > > Patch 0009 : atomic_get_input_bus_fmts > > Patch 0010 - 0011: component vs bridge > > Patch 0012 : DSIM bridge > > Patch 0013 - 0014: i.MX8M Mini/Nano > > Patch 0015 - 0016: i.MX8M Plus > > Changes for v15: > - drop drm_of helpers > - re-added find DSI bridge/Panel helper in dsim > - collect RB from Marek V > - fixed leading underscore in function names > - commit messages updated > - rebased on exynos-drm-next > > Changes for v13: > - remove devm call for DSI panel or bridge finding > - rebased on drm-misc-next > > Changes for v12: > - collect RB from Marek V > - add te_irq_handler hook > - fix comments from Marek V > - update atomic_get_input_bus_fmts logic > > Changes for v11: > - collect RB from Frieder Schrempf > - collect ACK from Rob > - collect ACK from Robert > - fix BIT macro replacements > - fix checkpatch --strict warnings > - fix unneeded commit text > - drop extra lines > > Changes for v10: > - rebase on drm-misc-next > - add drm_of_dsi_find_panel_or_bridge > - add devm_drm_of_dsi_get_bridge > - fix host initialization (Thanks to Marek Szyprowski) > - rearrange the tiny patches for easy to review > - update simple names for enum hw_type > - add is_hw_exynos macro > - rework on commit messages > > Changes for v9: > - rebase on drm-misc-next > - drop drm bridge attach fix for Exynos > - added prepare_prev_first flag > - added pre_enable_prev_first flag > - fix bridge chain order for exynos > - added fix for Exynos host init for first DSI transfer > - added MEDIA_BUS_FMT_FIXED > - return MEDIA_BUS_FMT_RGB888_1X24 output_fmt if supported output_fmt > list is unsupported. > - added MEDIA_BUS_FMT_YUYV10_1X20 > - added MEDIA_BUS_FMT_YUYV12_1X24 > > Changes for v8: > * fixed comment lines > * fixed commit messages > * fixed video mode bits > * collect Marek Ack > * fixed video mode bit names > * update input formats logic > * added imx8mplus support > > Changes for v7: > * fix the drm bridge attach chain for exynos drm dsi driver > * fix the hw_type checking logic > > Changes for v6: > * handle previous bridge for exynos dsi while attaching bridge > > Changes for v5: > * bridge changes to support multi-arch > * updated and clear commit messages > * add hw_type via plat data > * removed unneeded quirk > * rebased on linux-next > > Changes for v4: > * include Inki Dae in MAINTAINERS > * remove dsi_driver probe in exynos_drm_drv to support multi-arch build > * update init handling to ensure host init done on first cmd transfer > > Changes for v3: > * fix the mult-arch build > * fix dsi host init > * updated commit messages > > Changes for v2: > * fix bridge handling > * fix dsi host init > * correct the commit messages > > Tested in Engicam i.Core MX8M Mini SoM. > > Repo: > https://protect2.fireeye.com/v1/url?k=ba7a5cbf-dbf1498c-ba7bd7f0-000babff9bb7- > 64eb01b9825d1cad&q=1&e=55e2423e-1b57-4c22-a4a8- > 3dfcebdd3d9d&u=https%3A%2F%2Fgithub.com%2Fopenedev%2Fkernel%2Ftree%2Fimx8mm- > dsi-v15 > > v13: > https://lore.kernel.org/all/20230227113925.875425-1- > jagan@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (14): > drm: exynos: dsi: Drop explicit call to bridge detach > drm: exynos: dsi: Lookup OF-graph or Child node devices > drm: exynos: dsi: Mark PHY as optional > drm: exynos: dsi: Add platform PLL_P (PMS_P) offset > drm: exynos: dsi: Introduce hw_type platform data > drm: exynos: dsi: Add atomic check > drm: exynos: dsi: Add input_bus_flags > drm: exynos: dsi: Add atomic_get_input_bus_fmts > drm: exynos: dsi: Consolidate component and bridge > drm: exynos: dsi: Add host helper for te_irq_handler > drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge > dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support > drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support > dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support > > Marek Szyprowski (1): > drm: exynos: dsi: Handle proper host initialization > > Marek Vasut (1): > drm: bridge: samsung-dsim: Add i.MX8M Plus support > > .../bindings/display/exynos/exynos_dsim.txt | 2 + > MAINTAINERS | 9 + > drivers/gpu/drm/bridge/Kconfig | 12 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/samsung-dsim.c | 1965 +++++++++++++++++ > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1817 +-------------- > include/drm/bridge/samsung-dsim.h | 115 + > 8 files changed, 2190 insertions(+), 1732 deletions(-) > create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c > create mode 100644 include/drm/bridge/samsung-dsim.h > > -- > 2.25.1
Hi Inki Dae, On Mon, Mar 6, 2023 at 10:54 AM 대인기/Tizen Platform Lab(SR)/삼성전자 <inki.dae@samsung.com> wrote: > > Hi Jagan, > > > -----Original Message----- > > From: Jagan Teki <jagan@amarulasolutions.com> > > Sent: Friday, March 3, 2023 11:51 PM > > To: Andrzej Hajda <andrzej.hajda@intel.com>; Inki Dae <inki.dae@samsung.com>; > > Marek Szyprowski <m.szyprowski@samsung.com>; Neil Armstrong > > <neil.armstrong@linaro.org>; Marek Vasut <marex@denx.de>; Maxime Ripard > > <mripard@kernel.org> > > Cc: Seung-Woo Kim <sw0312.kim@samsung.com>; Kyungmin Park > > <kyungmin.park@samsung.com>; Frieder Schrempf <frieder.schrempf@kontron.de>; > > Tim Harvey <tharvey@gateworks.com>; Adam Ford <aford173@gmail.com>; Matteo > > Lisi <matteo.lisi@engicam.com>; dri-devel@lists.freedesktop.org; linux- > > samsung-soc@vger.kernel.org; linux-amarula <linux- > > amarula@amarulasolutions.com>; Jagan Teki <jagan@amarulasolutions.com> > > Subject: [PATCH v15 00/16] drm: Add Samsung MIPI DSIM bridge > > > > This series supports common bridge support for Samsung MIPI DSIM > > which is used in Exynos and i.MX8MM SoC's. > > > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > > > Inki Dae: please note that this series added on top of exynos-drm-next > > since few exynos dsi changes are not been part of drm-misc-next. > > Request you to pick these via exynos-drm-next, or let me know if you > > have any comments? > > Seems some issue Marek found on testing. If fixed then I will try to pick this > patch series up. Okay, I have a few comments from Maxime and Marek V pointed out. I will send v16 now if you are okay with it? Thanks, Jagan.
Hi Jagan, On 04.03.2023 19:59, Jagan Teki wrote: > On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> On 03.03.2023 15:51, Jagan Teki wrote: >>> This series supports common bridge support for Samsung MIPI DSIM >>> which is used in Exynos and i.MX8MM SoC's. >>> >>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. >>> >>> Inki Dae: please note that this series added on top of exynos-drm-next >>> since few exynos dsi changes are not been part of drm-misc-next. >>> Request you to pick these via exynos-drm-next, or let me know if you >>> have any comments? >> I gave it a try on Exynos TM2e and unfortunately it nukes again: >> >> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) >> Unable to handle kernel paging request at virtual address 003d454d414e5675 >> ... >> [003d454d414e5675] address between user and kernel address ranges >> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP >> Modules linked in: >> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 >> Hardware name: Samsung TM2E board (DT) >> Workqueue: events_unbound deferred_probe_work_func >> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) >> pc : drm_connector_list_iter_next+0x58/0x100 >> lr : drm_connector_list_iter_next+0x2c/0x100 >> sp : ffff80000bbab910 >> ... >> Call trace: >> drm_connector_list_iter_next+0x58/0x100 >> drm_mode_config_reset+0xfc/0x144 >> exynos_drm_bind+0x160/0x1b8 >> try_to_bring_up_aggregate_device+0x168/0x1d4 >> __component_add+0xa8/0x170 >> component_add+0x14/0x20 >> hdmi_probe+0x3fc/0x6d4 >> platform_probe+0x68/0xd8 >> really_probe+0x148/0x2b4 >> __driver_probe_device+0x78/0xe0 >> driver_probe_device+0xd8/0x160 >> __device_attach_driver+0xb8/0x138 >> bus_for_each_drv+0x84/0xe0 >> __device_attach+0xa8/0x1b0 >> device_initial_probe+0x14/0x20 >> bus_probe_device+0xb0/0xb4 >> deferred_probe_work_func+0x8c/0xc8 >> process_one_work+0x288/0x6c8 >> worker_thread+0x24c/0x450 >> kthread+0x118/0x11c >> ret_from_fork+0x10/0x20 > This looks not related to dsi to me since there is no exynos_drm_dsi > call in the trace. look hdmi related. Moreover, I think the exynos dsi > worked well on v10 and I couldn't find any potential differences in > terms of call flow change. > https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 Well, the issue is definitely related to this patchset. On Friday, due to other kernel messages, I missed the most important part of the log: [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 device exynos-dsi 13900000.dsi: request interrupt failed with -22 panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) It looks that the are at least 2 issues. The first one related to TE interrupt registration, the second is broken error path, which should free allocated resources and stop DRM from binding/initialization. This patch fixes the issue (TE gpio/interrupt is optional!): diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c index b4a5348b763c..ed83495fe105 100644 --- a/drivers/gpu/drm/bridge/samsung-dsim.c +++ b/drivers/gpu/drm/bridge/samsung-dsim.c @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct samsung_dsim *dsi, struct device int ret; dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); - if (IS_ERR(dsi->te_gpio)) + if (!dsi->te_gpio) + return 0; + else if (IS_ERR(dsi->te_gpio)) return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), "failed to get te GPIO\n"); te_gpio_irq = gpiod_to_irq(dsi->te_gpio); The error path in samsung_dsim_host_attach() after samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up the allocated resources (removing the bridge, detaing the dsi device). Best regards
Hi Marek, On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Hi Jagan, > > On 04.03.2023 19:59, Jagan Teki wrote: > > On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski > > <m.szyprowski@samsung.com> wrote: > >> On 03.03.2023 15:51, Jagan Teki wrote: > >>> This series supports common bridge support for Samsung MIPI DSIM > >>> which is used in Exynos and i.MX8MM SoC's. > >>> > >>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > >>> > >>> Inki Dae: please note that this series added on top of exynos-drm-next > >>> since few exynos dsi changes are not been part of drm-misc-next. > >>> Request you to pick these via exynos-drm-next, or let me know if you > >>> have any comments? > >> I gave it a try on Exynos TM2e and unfortunately it nukes again: > >> > >> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) > >> Unable to handle kernel paging request at virtual address 003d454d414e5675 > >> ... > >> [003d454d414e5675] address between user and kernel address ranges > >> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP > >> Modules linked in: > >> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 > >> Hardware name: Samsung TM2E board (DT) > >> Workqueue: events_unbound deferred_probe_work_func > >> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > >> pc : drm_connector_list_iter_next+0x58/0x100 > >> lr : drm_connector_list_iter_next+0x2c/0x100 > >> sp : ffff80000bbab910 > >> ... > >> Call trace: > >> drm_connector_list_iter_next+0x58/0x100 > >> drm_mode_config_reset+0xfc/0x144 > >> exynos_drm_bind+0x160/0x1b8 > >> try_to_bring_up_aggregate_device+0x168/0x1d4 > >> __component_add+0xa8/0x170 > >> component_add+0x14/0x20 > >> hdmi_probe+0x3fc/0x6d4 > >> platform_probe+0x68/0xd8 > >> really_probe+0x148/0x2b4 > >> __driver_probe_device+0x78/0xe0 > >> driver_probe_device+0xd8/0x160 > >> __device_attach_driver+0xb8/0x138 > >> bus_for_each_drv+0x84/0xe0 > >> __device_attach+0xa8/0x1b0 > >> device_initial_probe+0x14/0x20 > >> bus_probe_device+0xb0/0xb4 > >> deferred_probe_work_func+0x8c/0xc8 > >> process_one_work+0x288/0x6c8 > >> worker_thread+0x24c/0x450 > >> kthread+0x118/0x11c > >> ret_from_fork+0x10/0x20 > > This looks not related to dsi to me since there is no exynos_drm_dsi > > call in the trace. look hdmi related. Moreover, I think the exynos dsi > > worked well on v10 and I couldn't find any potential differences in > > terms of call flow change. > > https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 > > Well, the issue is definitely related to this patchset. On Friday, due > to other kernel messages, I missed the most important part of the log: > > [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations > exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) > exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) > exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 > device > exynos-dsi 13900000.dsi: request interrupt failed with -22 > panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 > exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) > exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) > > It looks that the are at least 2 issues. The first one related to TE > interrupt registration, the second is broken error path, which should > free allocated resources and stop DRM from binding/initialization. > > This patch fixes the issue (TE gpio/interrupt is optional!): > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > b/drivers/gpu/drm/bridge/samsung-dsim.c > index b4a5348b763c..ed83495fe105 100644 > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct > samsung_dsim *dsi, struct device > int ret; > > dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); > - if (IS_ERR(dsi->te_gpio)) > + if (!dsi->te_gpio) > + return 0; > + else if (IS_ERR(dsi->te_gpio)) I think I missed this change from v10 where Marek V commented to move this in dsim instead of in Exynos. anyway, I will correct this. > return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), > "failed to get te GPIO\n"); > > te_gpio_irq = gpiod_to_irq(dsi->te_gpio); > > > The error path in samsung_dsim_host_attach() after > samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up > the allocated resources (removing the bridge, detaing the dsi device). This is because of the same discussion of moving TE GPIO in dsim instead exynos. How about register TE GPIO before calling host attach like this, --- a/drivers/gpu/drm/bridge/samsung-dsim.c +++ b/drivers/gpu/drm/bridge/samsung-dsim.c @@ -1598,9 +1598,6 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host, drm_bridge_add(&dsi->bridge); - if (pdata->host_ops && pdata->host_ops->attach) - pdata->host_ops->attach(dsi, device); - /* * This is a temporary solution and should be made by more generic way. * @@ -1613,6 +1610,9 @@ static int samsung_dsim_host_attach(struct mipi_dsi_host *host, return ret; } + if (pdata->host_ops && pdata->host_ops->attach) + pdata->host_ops->attach(dsi, device); + dsi->lanes = device->lanes; dsi->format = device->format; dsi->mode_flags = device->mode_flags; Would you please check this? Thanks, Jagan.
Dear Jagan, On 06.03.2023 18:24, Jagan Teki wrote: > On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> On 04.03.2023 19:59, Jagan Teki wrote: >>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski >>> <m.szyprowski@samsung.com> wrote: >>>> On 03.03.2023 15:51, Jagan Teki wrote: >>>>> This series supports common bridge support for Samsung MIPI DSIM >>>>> which is used in Exynos and i.MX8MM SoC's. >>>>> >>>>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. >>>>> >>>>> Inki Dae: please note that this series added on top of exynos-drm-next >>>>> since few exynos dsi changes are not been part of drm-misc-next. >>>>> Request you to pick these via exynos-drm-next, or let me know if you >>>>> have any comments? >>>> I gave it a try on Exynos TM2e and unfortunately it nukes again: >>>> >>>> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) >>>> Unable to handle kernel paging request at virtual address 003d454d414e5675 >>>> ... >>>> [003d454d414e5675] address between user and kernel address ranges >>>> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP >>>> Modules linked in: >>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 >>>> Hardware name: Samsung TM2E board (DT) >>>> Workqueue: events_unbound deferred_probe_work_func >>>> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) >>>> pc : drm_connector_list_iter_next+0x58/0x100 >>>> lr : drm_connector_list_iter_next+0x2c/0x100 >>>> sp : ffff80000bbab910 >>>> ... >>>> Call trace: >>>> drm_connector_list_iter_next+0x58/0x100 >>>> drm_mode_config_reset+0xfc/0x144 >>>> exynos_drm_bind+0x160/0x1b8 >>>> try_to_bring_up_aggregate_device+0x168/0x1d4 >>>> __component_add+0xa8/0x170 >>>> component_add+0x14/0x20 >>>> hdmi_probe+0x3fc/0x6d4 >>>> platform_probe+0x68/0xd8 >>>> really_probe+0x148/0x2b4 >>>> __driver_probe_device+0x78/0xe0 >>>> driver_probe_device+0xd8/0x160 >>>> __device_attach_driver+0xb8/0x138 >>>> bus_for_each_drv+0x84/0xe0 >>>> __device_attach+0xa8/0x1b0 >>>> device_initial_probe+0x14/0x20 >>>> bus_probe_device+0xb0/0xb4 >>>> deferred_probe_work_func+0x8c/0xc8 >>>> process_one_work+0x288/0x6c8 >>>> worker_thread+0x24c/0x450 >>>> kthread+0x118/0x11c >>>> ret_from_fork+0x10/0x20 >>> This looks not related to dsi to me since there is no exynos_drm_dsi >>> call in the trace. look hdmi related. Moreover, I think the exynos dsi >>> worked well on v10 and I couldn't find any potential differences in >>> terms of call flow change. >>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 >> Well, the issue is definitely related to this patchset. On Friday, due >> to other kernel messages, I missed the most important part of the log: >> >> [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations >> exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) >> exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) >> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 >> device >> exynos-dsi 13900000.dsi: request interrupt failed with -22 >> panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 >> exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) >> exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) >> >> It looks that the are at least 2 issues. The first one related to TE >> interrupt registration, the second is broken error path, which should >> free allocated resources and stop DRM from binding/initialization. >> >> This patch fixes the issue (TE gpio/interrupt is optional!): >> >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c >> b/drivers/gpu/drm/bridge/samsung-dsim.c >> index b4a5348b763c..ed83495fe105 100644 >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c >> @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct >> samsung_dsim *dsi, struct device >> int ret; >> >> dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); >> - if (IS_ERR(dsi->te_gpio)) >> + if (!dsi->te_gpio) >> + return 0; >> + else if (IS_ERR(dsi->te_gpio)) > I think I missed this change from v10 where Marek V commented to move > this in dsim instead of in Exynos. anyway, I will correct this. > >> return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), >> "failed to get te GPIO\n"); >> >> te_gpio_irq = gpiod_to_irq(dsi->te_gpio); >> >> >> The error path in samsung_dsim_host_attach() after >> samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up >> the allocated resources (removing the bridge, detaing the dsi device). > This is because of the same discussion of moving TE GPIO in dsim instead exynos. Well, I'm not very happy about adding more and more features/changes to this single patch. I think that once we got the first version that was working on both Exynos and IMX, all other changes should be done incrementally to avoid this kind of issues... > How about register TE GPIO before calling host attach like this, > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1598,9 +1598,6 @@ static int samsung_dsim_host_attach(struct > mipi_dsi_host *host, > > drm_bridge_add(&dsi->bridge); > > - if (pdata->host_ops && pdata->host_ops->attach) > - pdata->host_ops->attach(dsi, device); > - > /* > * This is a temporary solution and should be made by more generic way. > * > @@ -1613,6 +1610,9 @@ static int samsung_dsim_host_attach(struct > mipi_dsi_host *host, > return ret; > } > > + if (pdata->host_ops && pdata->host_ops->attach) > + pdata->host_ops->attach(dsi, device); > + > dsi->lanes = device->lanes; > dsi->format = device->format; > dsi->mode_flags = device->mode_flags; > > Would you please check this? Yes. This fixes the error path. Best regards
Hi Marek, On Tue, Mar 7, 2023 at 4:11 AM Marek Szyprowski <m.szyprowski@samsung.com> wrote: > > Dear Jagan, > > On 06.03.2023 18:24, Jagan Teki wrote: > > On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski > > <m.szyprowski@samsung.com> wrote: > >> On 04.03.2023 19:59, Jagan Teki wrote: > >>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski > >>> <m.szyprowski@samsung.com> wrote: > >>>> On 03.03.2023 15:51, Jagan Teki wrote: > >>>>> This series supports common bridge support for Samsung MIPI DSIM > >>>>> which is used in Exynos and i.MX8MM SoC's. > >>>>> > >>>>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > >>>>> > >>>>> Inki Dae: please note that this series added on top of exynos-drm-next > >>>>> since few exynos dsi changes are not been part of drm-misc-next. > >>>>> Request you to pick these via exynos-drm-next, or let me know if you > >>>>> have any comments? > >>>> I gave it a try on Exynos TM2e and unfortunately it nukes again: > >>>> > >>>> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) > >>>> Unable to handle kernel paging request at virtual address 003d454d414e5675 > >>>> ... > >>>> [003d454d414e5675] address between user and kernel address ranges > >>>> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP > >>>> Modules linked in: > >>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 > >>>> Hardware name: Samsung TM2E board (DT) > >>>> Workqueue: events_unbound deferred_probe_work_func > >>>> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > >>>> pc : drm_connector_list_iter_next+0x58/0x100 > >>>> lr : drm_connector_list_iter_next+0x2c/0x100 > >>>> sp : ffff80000bbab910 > >>>> ... > >>>> Call trace: > >>>> drm_connector_list_iter_next+0x58/0x100 > >>>> drm_mode_config_reset+0xfc/0x144 > >>>> exynos_drm_bind+0x160/0x1b8 > >>>> try_to_bring_up_aggregate_device+0x168/0x1d4 > >>>> __component_add+0xa8/0x170 > >>>> component_add+0x14/0x20 > >>>> hdmi_probe+0x3fc/0x6d4 > >>>> platform_probe+0x68/0xd8 > >>>> really_probe+0x148/0x2b4 > >>>> __driver_probe_device+0x78/0xe0 > >>>> driver_probe_device+0xd8/0x160 > >>>> __device_attach_driver+0xb8/0x138 > >>>> bus_for_each_drv+0x84/0xe0 > >>>> __device_attach+0xa8/0x1b0 > >>>> device_initial_probe+0x14/0x20 > >>>> bus_probe_device+0xb0/0xb4 > >>>> deferred_probe_work_func+0x8c/0xc8 > >>>> process_one_work+0x288/0x6c8 > >>>> worker_thread+0x24c/0x450 > >>>> kthread+0x118/0x11c > >>>> ret_from_fork+0x10/0x20 > >>> This looks not related to dsi to me since there is no exynos_drm_dsi > >>> call in the trace. look hdmi related. Moreover, I think the exynos dsi > >>> worked well on v10 and I couldn't find any potential differences in > >>> terms of call flow change. > >>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 > >> Well, the issue is definitely related to this patchset. On Friday, due > >> to other kernel messages, I missed the most important part of the log: > >> > >> [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations > >> exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) > >> exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) > >> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 > >> device > >> exynos-dsi 13900000.dsi: request interrupt failed with -22 > >> panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 > >> exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) > >> exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) > >> > >> It looks that the are at least 2 issues. The first one related to TE > >> interrupt registration, the second is broken error path, which should > >> free allocated resources and stop DRM from binding/initialization. > >> > >> This patch fixes the issue (TE gpio/interrupt is optional!): > >> > >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > >> b/drivers/gpu/drm/bridge/samsung-dsim.c > >> index b4a5348b763c..ed83495fe105 100644 > >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c > >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > >> @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct > >> samsung_dsim *dsi, struct device > >> int ret; > >> > >> dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); > >> - if (IS_ERR(dsi->te_gpio)) > >> + if (!dsi->te_gpio) > >> + return 0; > >> + else if (IS_ERR(dsi->te_gpio)) > > I think I missed this change from v10 where Marek V commented to move > > this in dsim instead of in Exynos. anyway, I will correct this. > > > >> return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), > >> "failed to get te GPIO\n"); > >> > >> te_gpio_irq = gpiod_to_irq(dsi->te_gpio); > >> > >> > >> The error path in samsung_dsim_host_attach() after > >> samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up > >> the allocated resources (removing the bridge, detaing the dsi device). > > This is because of the same discussion of moving TE GPIO in dsim instead exynos. > > Well, I'm not very happy about adding more and more features/changes to > this single patch. I think that once we got the first version that was > working on both Exynos and IMX, all other changes should be done > incrementally to avoid this kind of issues... This is what I thought too, v10 was that ready to merge patchset. Since it was delayed it is obvious to have more comments from other developers in the community. This is what happened with the TE GPIO change. > > > > How about register TE GPIO before calling host attach like this, > > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > @@ -1598,9 +1598,6 @@ static int samsung_dsim_host_attach(struct > > mipi_dsi_host *host, > > > > drm_bridge_add(&dsi->bridge); > > > > - if (pdata->host_ops && pdata->host_ops->attach) > > - pdata->host_ops->attach(dsi, device); > > - > > /* > > * This is a temporary solution and should be made by more generic way. > > * > > @@ -1613,6 +1610,9 @@ static int samsung_dsim_host_attach(struct > > mipi_dsi_host *host, > > return ret; > > } > > > > + if (pdata->host_ops && pdata->host_ops->attach) > > + pdata->host_ops->attach(dsi, device); > > + > > dsi->lanes = device->lanes; > > dsi->format = device->format; > > dsi->mode_flags = device->mode_flags; > > > > Would you please check this? > > Yes. This fixes the error path. Okay. I'm sending v16 with the above two changes. Thanks, Jagan.
Hi Marek, On Tue, Mar 7, 2023 at 1:25 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > Hi Marek, > > On Tue, Mar 7, 2023 at 4:11 AM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > > > Dear Jagan, > > > > On 06.03.2023 18:24, Jagan Teki wrote: > > > On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski > > > <m.szyprowski@samsung.com> wrote: > > >> On 04.03.2023 19:59, Jagan Teki wrote: > > >>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski > > >>> <m.szyprowski@samsung.com> wrote: > > >>>> On 03.03.2023 15:51, Jagan Teki wrote: > > >>>>> This series supports common bridge support for Samsung MIPI DSIM > > >>>>> which is used in Exynos and i.MX8MM SoC's. > > >>>>> > > >>>>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > >>>>> > > >>>>> Inki Dae: please note that this series added on top of exynos-drm-next > > >>>>> since few exynos dsi changes are not been part of drm-misc-next. > > >>>>> Request you to pick these via exynos-drm-next, or let me know if you > > >>>>> have any comments? > > >>>> I gave it a try on Exynos TM2e and unfortunately it nukes again: > > >>>> > > >>>> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) > > >>>> Unable to handle kernel paging request at virtual address 003d454d414e5675 > > >>>> ... > > >>>> [003d454d414e5675] address between user and kernel address ranges > > >>>> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP > > >>>> Modules linked in: > > >>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 > > >>>> Hardware name: Samsung TM2E board (DT) > > >>>> Workqueue: events_unbound deferred_probe_work_func > > >>>> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > > >>>> pc : drm_connector_list_iter_next+0x58/0x100 > > >>>> lr : drm_connector_list_iter_next+0x2c/0x100 > > >>>> sp : ffff80000bbab910 > > >>>> ... > > >>>> Call trace: > > >>>> drm_connector_list_iter_next+0x58/0x100 > > >>>> drm_mode_config_reset+0xfc/0x144 > > >>>> exynos_drm_bind+0x160/0x1b8 > > >>>> try_to_bring_up_aggregate_device+0x168/0x1d4 > > >>>> __component_add+0xa8/0x170 > > >>>> component_add+0x14/0x20 > > >>>> hdmi_probe+0x3fc/0x6d4 > > >>>> platform_probe+0x68/0xd8 > > >>>> really_probe+0x148/0x2b4 > > >>>> __driver_probe_device+0x78/0xe0 > > >>>> driver_probe_device+0xd8/0x160 > > >>>> __device_attach_driver+0xb8/0x138 > > >>>> bus_for_each_drv+0x84/0xe0 > > >>>> __device_attach+0xa8/0x1b0 > > >>>> device_initial_probe+0x14/0x20 > > >>>> bus_probe_device+0xb0/0xb4 > > >>>> deferred_probe_work_func+0x8c/0xc8 > > >>>> process_one_work+0x288/0x6c8 > > >>>> worker_thread+0x24c/0x450 > > >>>> kthread+0x118/0x11c > > >>>> ret_from_fork+0x10/0x20 > > >>> This looks not related to dsi to me since there is no exynos_drm_dsi > > >>> call in the trace. look hdmi related. Moreover, I think the exynos dsi > > >>> worked well on v10 and I couldn't find any potential differences in > > >>> terms of call flow change. > > >>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 > > >> Well, the issue is definitely related to this patchset. On Friday, due > > >> to other kernel messages, I missed the most important part of the log: > > >> > > >> [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations > > >> exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) > > >> exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) > > >> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 > > >> device > > >> exynos-dsi 13900000.dsi: request interrupt failed with -22 > > >> panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 > > >> exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) > > >> exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) > > >> > > >> It looks that the are at least 2 issues. The first one related to TE > > >> interrupt registration, the second is broken error path, which should > > >> free allocated resources and stop DRM from binding/initialization. > > >> > > >> This patch fixes the issue (TE gpio/interrupt is optional!): > > >> > > >> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > > >> b/drivers/gpu/drm/bridge/samsung-dsim.c > > >> index b4a5348b763c..ed83495fe105 100644 > > >> --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > >> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > >> @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct > > >> samsung_dsim *dsi, struct device > > >> int ret; > > >> > > >> dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); > > >> - if (IS_ERR(dsi->te_gpio)) > > >> + if (!dsi->te_gpio) > > >> + return 0; > > >> + else if (IS_ERR(dsi->te_gpio)) > > > I think I missed this change from v10 where Marek V commented to move > > > this in dsim instead of in Exynos. anyway, I will correct this. > > > > > >> return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), > > >> "failed to get te GPIO\n"); > > >> > > >> te_gpio_irq = gpiod_to_irq(dsi->te_gpio); > > >> > > >> > > >> The error path in samsung_dsim_host_attach() after > > >> samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up > > >> the allocated resources (removing the bridge, detaing the dsi device). > > > This is because of the same discussion of moving TE GPIO in dsim instead exynos. > > > > Well, I'm not very happy about adding more and more features/changes to > > this single patch. I think that once we got the first version that was > > working on both Exynos and IMX, all other changes should be done > > incrementally to avoid this kind of issues... > > This is what I thought too, v10 was that ready to merge patchset. > Since it was delayed it is obvious to have more comments from other > developers in the community. This is what happened with the TE GPIO > change. > > > > > > > > How about register TE GPIO before calling host attach like this, > > > > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > > @@ -1598,9 +1598,6 @@ static int samsung_dsim_host_attach(struct > > > mipi_dsi_host *host, > > > > > > drm_bridge_add(&dsi->bridge); > > > > > > - if (pdata->host_ops && pdata->host_ops->attach) > > > - pdata->host_ops->attach(dsi, device); > > > - > > > /* > > > * This is a temporary solution and should be made by more generic way. > > > * > > > @@ -1613,6 +1610,9 @@ static int samsung_dsim_host_attach(struct > > > mipi_dsi_host *host, > > > return ret; > > > } > > > > > > + if (pdata->host_ops && pdata->host_ops->attach) > > > + pdata->host_ops->attach(dsi, device); > > > + > > > dsi->lanes = device->lanes; > > > dsi->format = device->format; > > > dsi->mode_flags = device->mode_flags; > > > > > > Would you please check this? > > > > Yes. This fixes the error path. > > Okay. I'm sending v16 with the above two changes. Would you please test this v16 for confirmation before sending it to the mailing list? https://github.com/openedev/kernel/commits/imx8mm-dsi-v16 Thanks, Jagan.
Hello, On 07.03.2023 10:22, Jagan Teki wrote: > On Tue, Mar 7, 2023 at 1:25 PM Jagan Teki <jagan@amarulasolutions.com> wrote: >> On Tue, Mar 7, 2023 at 4:11 AM Marek Szyprowski >> <m.szyprowski@samsung.com> wrote: >>> On 06.03.2023 18:24, Jagan Teki wrote: >>>> On Mon, Mar 6, 2023 at 4:32 PM Marek Szyprowski >>>> <m.szyprowski@samsung.com> wrote: >>>>> On 04.03.2023 19:59, Jagan Teki wrote: >>>>>> On Sat, Mar 4, 2023 at 3:56 AM Marek Szyprowski >>>>>> <m.szyprowski@samsung.com> wrote: >>>>>>> On 03.03.2023 15:51, Jagan Teki wrote: >>>>>>>> This series supports common bridge support for Samsung MIPI DSIM >>>>>>>> which is used in Exynos and i.MX8MM SoC's. >>>>>>>> >>>>>>>> The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. >>>>>>>> >>>>>>>> Inki Dae: please note that this series added on top of exynos-drm-next >>>>>>>> since few exynos dsi changes are not been part of drm-misc-next. >>>>>>>> Request you to pick these via exynos-drm-next, or let me know if you >>>>>>>> have any comments? >>>>>>> I gave it a try on Exynos TM2e and unfortunately it nukes again: >>>>>>> >>>>>>> exynos-drm exynos-drm: bound 13970000.hdmi (ops hdmi_component_ops) >>>>>>> Unable to handle kernel paging request at virtual address 003d454d414e5675 >>>>>>> ... >>>>>>> [003d454d414e5675] address between user and kernel address ranges >>>>>>> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP >>>>>>> Modules linked in: >>>>>>> CPU: 4 PID: 9 Comm: kworker/u16:0 Not tainted 6.2.0-next-20230303+ #13341 >>>>>>> Hardware name: Samsung TM2E board (DT) >>>>>>> Workqueue: events_unbound deferred_probe_work_func >>>>>>> pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) >>>>>>> pc : drm_connector_list_iter_next+0x58/0x100 >>>>>>> lr : drm_connector_list_iter_next+0x2c/0x100 >>>>>>> sp : ffff80000bbab910 >>>>>>> ... >>>>>>> Call trace: >>>>>>> drm_connector_list_iter_next+0x58/0x100 >>>>>>> drm_mode_config_reset+0xfc/0x144 >>>>>>> exynos_drm_bind+0x160/0x1b8 >>>>>>> try_to_bring_up_aggregate_device+0x168/0x1d4 >>>>>>> __component_add+0xa8/0x170 >>>>>>> component_add+0x14/0x20 >>>>>>> hdmi_probe+0x3fc/0x6d4 >>>>>>> platform_probe+0x68/0xd8 >>>>>>> really_probe+0x148/0x2b4 >>>>>>> __driver_probe_device+0x78/0xe0 >>>>>>> driver_probe_device+0xd8/0x160 >>>>>>> __device_attach_driver+0xb8/0x138 >>>>>>> bus_for_each_drv+0x84/0xe0 >>>>>>> __device_attach+0xa8/0x1b0 >>>>>>> device_initial_probe+0x14/0x20 >>>>>>> bus_probe_device+0xb0/0xb4 >>>>>>> deferred_probe_work_func+0x8c/0xc8 >>>>>>> process_one_work+0x288/0x6c8 >>>>>>> worker_thread+0x24c/0x450 >>>>>>> kthread+0x118/0x11c >>>>>>> ret_from_fork+0x10/0x20 >>>>>> This looks not related to dsi to me since there is no exynos_drm_dsi >>>>>> call in the trace. look hdmi related. Moreover, I think the exynos dsi >>>>>> worked well on v10 and I couldn't find any potential differences in >>>>>> terms of call flow change. >>>>>> https://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 >>>>> Well, the issue is definitely related to this patchset. On Friday, due >>>>> to other kernel messages, I missed the most important part of the log: >>>>> >>>>> [drm] Exynos DRM: using 13800000.decon device for DMA mapping operations >>>>> exynos-drm exynos-drm: bound 13800000.decon (ops decon_component_ops) >>>>> exynos-drm exynos-drm: bound 13880000.decon (ops decon_component_ops) >>>>> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached s6e3hf2 >>>>> device >>>>> exynos-dsi 13900000.dsi: request interrupt failed with -22 >>>>> panel-samsung-s6e3ha2: probe of 13900000.dsi.0 failed with error -22 >>>>> exynos-drm exynos-drm: bound 13900000.dsi (ops exynos_dsi_component_ops) >>>>> exynos-drm exynos-drm: bound 13930000.mic (ops exynos_mic_component_ops) >>>>> >>>>> It looks that the are at least 2 issues. The first one related to TE >>>>> interrupt registration, the second is broken error path, which should >>>>> free allocated resources and stop DRM from binding/initialization. >>>>> >>>>> This patch fixes the issue (TE gpio/interrupt is optional!): >>>>> >>>>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c >>>>> b/drivers/gpu/drm/bridge/samsung-dsim.c >>>>> index b4a5348b763c..ed83495fe105 100644 >>>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c >>>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c >>>>> @@ -1518,7 +1518,9 @@ static int samsung_dsim_register_te_irq(struct >>>>> samsung_dsim *dsi, struct device >>>>> int ret; >>>>> >>>>> dsi->te_gpio = devm_gpiod_get_optional(dev, "te", GPIOD_IN); >>>>> - if (IS_ERR(dsi->te_gpio)) >>>>> + if (!dsi->te_gpio) >>>>> + return 0; >>>>> + else if (IS_ERR(dsi->te_gpio)) >>>> I think I missed this change from v10 where Marek V commented to move >>>> this in dsim instead of in Exynos. anyway, I will correct this. >>>> >>>>> return dev_err_probe(dev, PTR_ERR(dsi->te_gpio), >>>>> "failed to get te GPIO\n"); >>>>> >>>>> te_gpio_irq = gpiod_to_irq(dsi->te_gpio); >>>>> >>>>> >>>>> The error path in samsung_dsim_host_attach() after >>>>> samsung_dsim_register_te_irq() failure is wrong. It lacks cleaning up >>>>> the allocated resources (removing the bridge, detaing the dsi device). >>>> This is because of the same discussion of moving TE GPIO in dsim instead exynos. >>> Well, I'm not very happy about adding more and more features/changes to >>> this single patch. I think that once we got the first version that was >>> working on both Exynos and IMX, all other changes should be done >>> incrementally to avoid this kind of issues... >> This is what I thought too, v10 was that ready to merge patchset. >> Since it was delayed it is obvious to have more comments from other >> developers in the community. This is what happened with the TE GPIO >> change. >> >>> >>>> How about register TE GPIO before calling host attach like this, >>>> >>>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c >>>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c >>>> @@ -1598,9 +1598,6 @@ static int samsung_dsim_host_attach(struct >>>> mipi_dsi_host *host, >>>> >>>> drm_bridge_add(&dsi->bridge); >>>> >>>> - if (pdata->host_ops && pdata->host_ops->attach) >>>> - pdata->host_ops->attach(dsi, device); >>>> - >>>> /* >>>> * This is a temporary solution and should be made by more generic way. >>>> * >>>> @@ -1613,6 +1610,9 @@ static int samsung_dsim_host_attach(struct >>>> mipi_dsi_host *host, >>>> return ret; >>>> } >>>> >>>> + if (pdata->host_ops && pdata->host_ops->attach) >>>> + pdata->host_ops->attach(dsi, device); >>>> + >>>> dsi->lanes = device->lanes; >>>> dsi->format = device->format; >>>> dsi->mode_flags = device->mode_flags; >>>> >>>> Would you please check this? >>> Yes. This fixes the error path. >> Okay. I'm sending v16 with the above two changes. > Would you please test this v16 for confirmation before sending it to > the mailing list? v16 works fine here. Feel free to add: Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> to the Exynos related patches (if there is still no such tag yet). Best regards
Hi Inki, On Mon, Mar 6, 2023 at 2:24 AM 대인기/Tizen Platform Lab(SR)/삼성전자 <inki.dae@samsung.com> wrote: > Seems some issue Marek found on testing. If fixed then I will try to pick this > patch series up. Marek has successfully tested v16. Could you please apply v16? Thanks
Hi Fabio Estevam, 2023년 3월 14일 (화) 오전 9:31, Fabio Estevam <festevam@gmail.com>님이 작성: > Hi Inki, > > On Mon, Mar 6, 2023 at 2:24 AM 대인기/Tizen Platform Lab(SR)/삼성전자 > <inki.dae@samsung.com> wrote: > > > Seems some issue Marek found on testing. If fixed then I will try to > pick this > > patch series up. > > Marek has successfully tested v16. > > Could you please apply v16? > I am planning to merge this patch series soon, but I will be proceeding with the pull-request next week. As the DSIM driver is being moved to the bridge folder, I would like to wait for acknowledgment from the bridge maintainers. However, if there are no further comments until next week, I will proceed with the pull-request. Thanks, Inki Dae > Thanks >
Hi Inki, On Mon, Mar 13, 2023 at 9:51 PM Inki Dae <daeinki@gmail.com> wrote: >> Could you please apply v16? > > > I am planning to merge this patch series soon, but I will be proceeding with the pull-request next week. As the DSIM driver is being moved to the bridge folder, I would like to wait for acknowledgment from the bridge maintainers. However, if there are no further comments until next week, I will proceed with the pull-request. A friendly reminder: do you think you can proceed with the pull-request now? Thanks
On 23/03/2023 16:34, Fabio Estevam wrote: > Hi Inki, > > On Mon, Mar 13, 2023 at 9:51 PM Inki Dae <daeinki@gmail.com> wrote: > >>> Could you please apply v16? >> >> >> I am planning to merge this patch series soon, but I will be proceeding with the pull-request next week. As the DSIM driver is being moved to the bridge folder, I would like to wait for acknowledgment from the bridge maintainers. However, if there are no further comments until next week, I will proceed with the pull-request. > > A friendly reminder: do you think you can proceed with the pull-request now? I can apply the entire patchset to drm-misc-needed if needed. Inki, is it ok for you or you still want to take it in the exynos tree ? Neil > > Thanks
Hi, 2023년 3월 27일 (월) 오후 11:08, Neil Armstrong <neil.armstrong@linaro.org>님이 작성: > On 23/03/2023 16:34, Fabio Estevam wrote: > > Hi Inki, > > > > On Mon, Mar 13, 2023 at 9:51 PM Inki Dae <daeinki@gmail.com> wrote: > > > >>> Could you please apply v16? > >> > >> > >> I am planning to merge this patch series soon, but I will be proceeding > with the pull-request next week. As the DSIM driver is being moved to the > bridge folder, I would like to wait for acknowledgment from the bridge > maintainers. However, if there are no further comments until next week, I > will proceed with the pull-request. > > > > A friendly reminder: do you think you can proceed with the pull-request > now? > > I can apply the entire patchset to drm-misc-needed if needed. > > Inki, is it ok for you or you still want to take it in the exynos tree ? > Sorry for late. I will proceed with pull-request today. BTW, now is rc4 so we have more time for pull-request. Is there any reason you hurry up? Thanks, Inki Dae > Neil > > > > > Thanks > >
On 28/03/2023 02:03, Inki Dae wrote: > Hi, > > 2023년 3월 27일 (월) 오후 11:08, Neil Armstrong <neil.armstrong@linaro.org <mailto:neil.armstrong@linaro.org>>님이 작성: > > On 23/03/2023 16:34, Fabio Estevam wrote: > > Hi Inki, > > > > On Mon, Mar 13, 2023 at 9:51 PM Inki Dae <daeinki@gmail.com <mailto:daeinki@gmail.com>> wrote: > > > >>> Could you please apply v16? > >> > >> > >> I am planning to merge this patch series soon, but I will be proceeding with the pull-request next week. As the DSIM driver is being moved to the bridge folder, I would like to wait for acknowledgment from the bridge maintainers. However, if there are no further comments until next week, I will proceed with the pull-request. > > > > A friendly reminder: do you think you can proceed with the pull-request now? > > I can apply the entire patchset to drm-misc-needed if needed. > > Inki, is it ok for you or you still want to take it in the exynos tree ? > > > Sorry for late. I will proceed with pull-request today. No problem. ping me if I can help on the bridge side. > > BTW, now is rc4 so we have more time for pull-request. Is there any reason you hurry up? As Fabio explains, it's v16 and was fully reviewed for a few weeks now, so it's time to LGTM ! Neil > > Thanks, > Inki Dae > > > Neil > > > > > Thanks >