On Wed, Jan 25, 2023 at 10:57 PM Marek Vasut <marex@xxxxxxx> wrote: > > On 1/25/23 18:12, Jagan Teki wrote: > > On Wed, Jan 25, 2023 at 10:16 PM Marek Vasut <marex@xxxxxxx> wrote: > >> > >> On 1/25/23 15:04, Jagan Teki wrote: > >>> On Wed, Jan 25, 2023 at 7:23 PM Marek Vasut <marex@xxxxxxx> wrote: > >>>> > >>>> On 1/25/23 07:54, Jagan Teki wrote: > >>>>> On Wed, Jan 25, 2023 at 2:54 AM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > >>>>>> > >>>>>> On Wed, Jan 25, 2023 at 2:54 AM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > >>>>>>> > >>>>>>> On Wed, Jan 25, 2023 at 2:42 AM Marek Vasut <marex@xxxxxxx> wrote: > >>>>>>>> > >>>>>>>> On 1/24/23 22:01, Jagan Teki wrote: > >>>>>>>>> On Wed, Jan 25, 2023 at 2:18 AM Marek Vasut <marex@xxxxxxx> wrote: > >>>>>>>>>> > >>>>>>>>>> On 1/23/23 16:12, Jagan Teki wrote: > >>>>>>>>>>> Enable and disable of te_gpio's are Exynos platform specific > >>>>>>>>>>> irq handling, so add the exynos based irq operations and hook > >>>>>>>>>>> them for exynos plat_data. > >>>>>>>>>> > >>>>>>>>>> If this is just an optional generic GPIO IRQ, why not keep it in the > >>>>>>>>>> core code ? TE (tearing enable?) should be available on MX8M too. > >>>>>>>>> > >>>>>>>>> So far the discussion (since from initial versions) with Marek > >>>>>>>>> Szyprowski, seems to be available in Exynos. So, I keep it separate > >>>>>>>>> from the DSIM core. > >>>>>>>> > >>>>>>>> Isn't TE a generic GPIO IRQ ? If so, it is available also on i.MX8M . > >>>>>> > >>>>>> I will check this. > >>>>> > >>>>> In order to use TE_GPIO we need te handler implementation, right now > >>>>> Exynos CRTC DRM drivers have implementation for this. That is the main > >>>>> reason to keep the TE_GPIO handling in exynos, maybe if we handle that > >>>>> generically then it is a viable option to move TE_GPIO to the DSIM > >>>>> core. > >>>> > >>>> I think you can do this exactly the same way exynos does it -- check > >>>> whether te_handler() callback is implemented by the glue code (the one > >>>> you already have for various exynos and imx8mm/imx8mm SoCs) and if so, > >>>> call it. If it is not implemented, do not call anything in the TE IRQ > >>>> handler. > >>> > >>> I need to understand how i.MX8MM handles this on TE IRQ in the DSIM > >>> host side, Can I do this in future patch set as it might involve > >>> bindings changes as well if it's part of DSIM? > >> > >> Why not leave an empty te_handler implementation on MX8M for now ? > >> You can fill that implementation in future patchset, but the generic > >> part of the code would be in place . > > > > Look like we have one issue to move regster te_irq into samsung-dsim. > > > > exynos_dsi_register_te_irq is done after the bridge attach is done in > > Exynos, here bridge attach is triggered in the component ops bind > > call, since samsung-dsim is a pure bridge w/o any component ops. > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1527 > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L112 > > > > Any suggestion on how to handle this? > > Why isn't the generic code calling drm_bridge_attach() in > samsung_dsim_host_attach(), like the exynos one ? Exynos drm drivers follow component ops and generic dsim is a pure drm bridge whose downstream bridge will attach in bridge ops attach and the component-based drivers require an initial bridge attach (whose previous is NULL) call in the component bind hook for establishing the bridge chain. Jagan.
