| Message ID | 20221214125907.376148-1-jagan@amarulasolutions.com |
|---|---|
| Headers | show |
| Series | drm: Add Samsung MIPI DSIM bridge | expand |
On 14.12.22 13:58, Jagan Teki wrote: > The same Samsung MIPI DSIM master can also be used in NXP's > i.MX8M Mini/Nano/Plus SoC. > > In i.MX8M Mini/Nano/Plus SoC the DSI Phy requires a MIPI DPHY > bit to reset in order to activate the PHY and that can be done > via upstream i.MX8M blk-ctrl driver. > > So, mark the phy get as optional. > > Reviewed-by: Marek Vasut <marex@denx.de> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
On 15.12.22 09:39, Frieder Schrempf wrote: > On 14.12.22 13:58, Jagan Teki wrote: >> Look like an explicit fixing up of mode_flags is required for DSIM IP >> present in i.MX8M Mini/Nano SoCs. >> >> At least the LCDIF + DSIM needs active low sync polarities in order >> to correlate the correct sync flags of the surrounding components in >> the chain to make sure the whole pipeline can work properly. >> >> On the other hand the i.MX 8M Mini Applications Processor Reference Manual, >> Rev. 3, 11/2020 says. >> "13.6.3.5.2 RGB interface >> Vsync, Hsync, and VDEN are active high signals." >> >> i.MX 8M Mini Applications Processor Reference Manual Rev. 3, 11/2020 >> 3.6.3.5.2 RGB interface >> i.MX 8M Nano Applications Processor Reference Manual Rev. 2, 07/2022 >> 13.6.2.7.2 RGB interface >> both claim "Vsync, Hsync, and VDEN are active high signals.", the >> LCDIF must generate inverted HS/VS/DE signals, i.e. active LOW. >> >> No clear evidence about whether it can be documentation issues or >> something, so added a comment FIXME for this and updated the active low >> sync polarities using SAMSUNG_DSIM_TYPE_IMX8MM hw_type. By the way, the commit message mentions a FIXME comment above. But it's not in the patch. The commit message probably needs an update. >> >> Comments are suggested by Marek Vasut. >> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
On 14.12.22 13:59, Jagan Teki wrote: > Finding the right input bus format throughout the pipeline is hard > so add atomic_get_input_bus_fmts callback and initialize with the > proper input format from list of supported output formats. > > This format can be used in pipeline for negotiating bus format between > the DSI-end of this bridge and the other component closer to pipeline > components. > > List of Pixel formats are taken from, > AN13573 i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022 > 3.7.4 Pixel formats > Table 14. DSI pixel packing formats > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
On 14.12.22 13:59, Jagan Teki wrote: > From: Marek Vasut <marex@denx.de> > > Add extras to support i.MX8M Plus. The main change is the removal of > HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise > the implementation of this IP in i.MX8M Plus is very much compatible > with the i.MX8M Mini/Nano one. > > Signed-off-by: Marek Vasut <marex@denx.de> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
On Thu, 15 Dec 2022 at 10:23, Frieder Schrempf <frieder.schrempf@kontron.de> wrote: > > On 14.12.22 13:59, Jagan Teki wrote: > > From: Marek Vasut <marex@denx.de> > > > > Add extras to support i.MX8M Plus. The main change is the removal of > > HS/VS/DE signal inversion in the LCDIFv3-DSIM glue logic, otherwise > > the implementation of this IP in i.MX8M Plus is very much compatible > > with the i.MX8M Mini/Nano one. > > > > Signed-off-by: Marek Vasut <marex@denx.de> > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Robert Foss <robert.foss@linaro.org>
On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> 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. > > Patch 0001 - 0004: adding devm_drm_of_dsi_get_bridge > > Patch 0005 - 0006: optional PHY, PMS_P offset > > Patch 0007 : introduce hw_type > > Patch 0008 : fixing host init > > Patch 0009 : atomic_check > > Patch 0010 : input_bus_flags > > Patch 0011 : atomic_get_input_bus_fmts > > Patch 0012 - 0013: component vs bridge > > Patch 0014 : DSIM bridge > > Patch 0015 - 0016: i.MX8M Mini/Nano > > Patch 0017 - 0018: i.MX8M Plus > > 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 > > v9: > https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (16): > drm: of: Lookup if child node has DSI panel or bridge > drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper > drm: exynos: dsi: Drop explicit call to bridge detach > drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge > 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 Exynos based host irq hooks > 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 Does anyone have any other comments on this? I would like to send v11 with a few nits on v10. Please let me know. Thanks, Jagan.
On Thu, Jan 5, 2023 at 4:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > On Wed, Dec 14, 2022 at 6:29 PM Jagan Teki <jagan@amarulasolutions.com> 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. > > > > Patch 0001 - 0004: adding devm_drm_of_dsi_get_bridge > > > > Patch 0005 - 0006: optional PHY, PMS_P offset > > > > Patch 0007 : introduce hw_type > > > > Patch 0008 : fixing host init > > > > Patch 0009 : atomic_check > > > > Patch 0010 : input_bus_flags > > > > Patch 0011 : atomic_get_input_bus_fmts > > > > Patch 0012 - 0013: component vs bridge > > > > Patch 0014 : DSIM bridge > > > > Patch 0015 - 0016: i.MX8M Mini/Nano > > > > Patch 0017 - 0018: i.MX8M Plus > > > > 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://gitlab.com/openedev/kernel/-/commits/imx8mm-dsi-v10 > > > > v9: > > https://lore.kernel.org/all/20221209152343.180139-1-jagan@amarulasolutions.com/ > > > > Any inputs? > > Jagan. > > > > Jagan Teki (16): > > drm: of: Lookup if child node has DSI panel or bridge > > drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper > > drm: exynos: dsi: Drop explicit call to bridge detach > > drm: exynos: dsi: Switch to devm_drm_of_dsi_get_bridge > > 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 Exynos based host irq hooks > > 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 > > Does anyone have any other comments on this? I would like to send v11 > with a few nits on v10. Please let me know. I got it working on an LVDS display that I have, but I didn't get it working on the HDMI bridge. Since we have a few tested-by people, it'd be nice to see this integrated so we can work on ading more functionality adam > > Thanks, > Jagan.
On Fri, Jan 6, 2023 at 11:34 AM Adam Ford <aford173@gmail.com> wrote: > I got it working on an LVDS display that I have, but I didn't get it > working on the HDMI bridge. Since we have a few tested-by people, > it'd be nice to see this integrated so we can work on ading more > functionality Agreed. Hopefully, this series can be applied soon so we don't miss another cycle.
Hi Fabio, On Thu, Jan 19, 2023 at 10:57 PM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Jagan, > > On Thu, Jan 5, 2023 at 7:24 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > Does anyone have any other comments on this? I would like to send v11 > > with a few nits on v10. Please let me know. > > What is blocking this series to be applied? There are two patch series prior to this need to apply. https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ Regarding this series, the patch 09/18 commit message has "FIXME" this need to remove. https://patchwork.kernel.org/project/dri-devel/patch/20221214125907.376148-10-jagan@amarulasolutions.com/ I think it is possible to remove it while applying otherwise I will resend this patch alone or in series again. Jagan.
Hi Jagan, On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > There are two patch series prior to this need to apply. > > https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ Would it make sense to re-submit these two patches as part of your series?
Hi Fabio, On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: > > Hi Jagan, > > On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > There are two patch series prior to this need to apply. > > > > https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > > Would it make sense to re-submit these two patches as part of your series? The previous version's comment was to separate them from the DSIM series. Jagan.
On 1/20/23 15:41, Jagan Teki wrote: > Hi Fabio, Hello all, > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: >> >> Hi Jagan, >> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: >> >>> There are two patch series prior to this need to apply. >>> >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ >> >> Would it make sense to re-submit these two patches as part of your series? > > The previous version's comment was to separate them from the DSIM series. Hmmmmm, seems like those first two patches got stuck. I fixed up the malformed Fixes: line (it was split across two lines and had angular brackets around it) and picked the first series via drm-misc-next . Can you send a subsequent patch to convert the DSIM_* macros to BIT() macro , since checkpatch --strict complains about it ? For the second series, you likely want a RB from Maxime Ripard and Dave Stevenson first about the probe order handling.
On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote: > > On 1/20/23 15:41, Jagan Teki wrote: > > Hi Fabio, > > Hello all, > > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: > >> > >> Hi Jagan, > >> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > >> > >>> There are two patch series prior to this need to apply. > >>> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > >> > >> Would it make sense to re-submit these two patches as part of your series? > > > > The previous version's comment was to separate them from the DSIM series. > > Hmmmmm, seems like those first two patches got stuck. I fixed up the > malformed Fixes: line (it was split across two lines and had angular > brackets around it) and picked the first series via drm-misc-next . Thanks. We have another series for Exynos, prior to DSIM https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > > Can you send a subsequent patch to convert the DSIM_* macros to BIT() > macro , since checkpatch --strict complains about it ? Okay. > > For the second series, you likely want a RB from Maxime Ripard and Dave > Stevenson first about the probe order handling. Do you mean for 01/18 and 02/18 patches? Jagan.
Hi Marek & Jagan On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote: > > On 1/20/23 15:41, Jagan Teki wrote: > > Hi Fabio, > > Hello all, > > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: > >> > >> Hi Jagan, > >> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > >> > >>> There are two patch series prior to this need to apply. > >>> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > >> > >> Would it make sense to re-submit these two patches as part of your series? > > > > The previous version's comment was to separate them from the DSIM series. > > Hmmmmm, seems like those first two patches got stuck. I fixed up the > malformed Fixes: line (it was split across two lines and had angular > brackets around it) and picked the first series via drm-misc-next . > > Can you send a subsequent patch to convert the DSIM_* macros to BIT() > macro , since checkpatch --strict complains about it ? > > For the second series, you likely want a RB from Maxime Ripard and Dave > Stevenson first about the probe order handling. Not sure what I can add for "Enable prepare_prev_first flag for samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag" as I have no datasheet for those devices. On the basis that they are wanting the DSI host to be in LP-11 before prepare/pre_enable, then setting the flag is the right thing. More than happy to say Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> to those two (I can't find them quickly in my mail to respond directly). I have just sent a separate response on the third patch. Dave
On 1/20/23 19:54, Jagan Teki wrote: > On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote: >> >> On 1/20/23 15:41, Jagan Teki wrote: >>> Hi Fabio, >> >> Hello all, >> >>> On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: >>>> >>>> Hi Jagan, >>>> >>>> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: >>>> >>>>> There are two patch series prior to this need to apply. >>>>> >>>>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ >>>>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ >>>> >>>> Would it make sense to re-submit these two patches as part of your series? >>> >>> The previous version's comment was to separate them from the DSIM series. >> >> Hmmmmm, seems like those first two patches got stuck. I fixed up the >> malformed Fixes: line (it was split across two lines and had angular >> brackets around it) and picked the first series via drm-misc-next . > > Thanks. > > We have another series for Exynos, prior to DSIM > https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > >> >> Can you send a subsequent patch to convert the DSIM_* macros to BIT() >> macro , since checkpatch --strict complains about it ? > > Okay. > >> >> For the second series, you likely want a RB from Maxime Ripard and Dave >> Stevenson first about the probe order handling. > > Do you mean for 01/18 and 02/18 patches? I mean https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/
On Sat, Jan 21, 2023 at 12:29 AM Dave Stevenson <dave.stevenson@raspberrypi.com> wrote: > > Hi Marek & Jagan > > On Fri, 20 Jan 2023 at 15:06, Marek Vasut <marex@denx.de> wrote: > > > > On 1/20/23 15:41, Jagan Teki wrote: > > > Hi Fabio, > > > > Hello all, > > > > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: > > >> > > >> Hi Jagan, > > >> > > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > >> > > >>> There are two patch series prior to this need to apply. > > >>> > > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > > >> > > >> Would it make sense to re-submit these two patches as part of your series? > > > > > > The previous version's comment was to separate them from the DSIM series. > > > > Hmmmmm, seems like those first two patches got stuck. I fixed up the > > malformed Fixes: line (it was split across two lines and had angular > > brackets around it) and picked the first series via drm-misc-next . > > > > Can you send a subsequent patch to convert the DSIM_* macros to BIT() > > macro , since checkpatch --strict complains about it ? > > > > For the second series, you likely want a RB from Maxime Ripard and Dave > > Stevenson first about the probe order handling. > > Not sure what I can add for "Enable prepare_prev_first flag for > samsung-s6e panels" and "tc358764: Enable pre_enable_prev_first flag" > as I have no datasheet for those devices. > On the basis that they are wanting the DSI host to be in LP-11 before > prepare/pre_enable, then setting the flag is the right thing. More > than happy to say > Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> > to those two (I can't find them quickly in my mail to respond directly). > > I have just sent a separate response on the third patch. Fyi: please check my answers on that thread. Thanks, Jagan.
Hi Marek, On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut <marex@denx.de> wrote: > > On 1/20/23 15:41, Jagan Teki wrote: > > Hi Fabio, > > Hello all, > > > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam <festevam@gmail.com> wrote: > >> > >> Hi Jagan, > >> > >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > >> > >>> There are two patch series prior to this need to apply. > >>> > >>> https://patchwork.kernel.org/project/dri-devel/patch/20221212145745.15387-1-jagan@amarulasolutions.com/ > >>> https://patchwork.kernel.org/project/dri-devel/cover/20221212182923.29155-1-jagan@amarulasolutions.com/ > >> > >> Would it make sense to re-submit these two patches as part of your series? > > > > The previous version's comment was to separate them from the DSIM series. > > Hmmmmm, seems like those first two patches got stuck. I fixed up the > malformed Fixes: line (it was split across two lines and had angular > brackets around it) and picked the first series via drm-misc-next . > > Can you send a subsequent patch to convert the DSIM_* macros to BIT() > macro , since checkpatch --strict complains about it ? Fyi: I sent the v11 series for this with RESEND prefix. Let me know if you have any further comments on this. Thanks, Jagan.