Hi Daniel, On Thu, May 14, 2020 at 07:25:10AM +0200, Daniel Vetter wrote: > On Thu, May 14, 2020 at 1:33 AM Chun-Kuang Hu <chunkuang.hu@xxxxxxxxxx> wrote: > > Daniel Vetter <daniel@xxxxxxxx> 於 2020年5月14日 週四 上午3:45寫道： > > > On Thu, May 14, 2020 at 12:16:59AM +0800, Chun-Kuang Hu wrote: > > > > Hi, Dave & Daniel: > > > > > > > > This include dpi pin mode swap, config mipi_tx current and impedance, > > > > convert mtk-dpi to drm_bridge API, and some fixup. > > > > > > > > The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: > > > > Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) > > > > are available in the Git repository at: > > > > ssh://git@xxxxxxxxxxxxxxxxxxx/pub/scm/linux/kernel/git/chunkuang.hu/linux.git > > > > tags/mediatek-drm-next-5.8 > > > > > > Your pull request is badly line wrapped, and I don't have an ssh account > > > on that machine ... Maybe airlied has, not sure. http:// or git:// would > > > be a bunch easier, and then signed that. Plus if your pull isn't > > > linewrapped we can stuff it directly into scripts. > > > > This is my first time to request-pull on that server, I would try to > > make things easier and resend request. > > > > > All I quickly wanted to quickly check is your new bridge driver. > > > - was that reviewed/acked by bridge maintainers? There's a lot of rework > > > going on right now, need to make sure we're not adding new bridge > > > drivers that use old style > > > > > > - why is this bridge driver not in drm/bridge/ directory? > > > > I does not notice that drm bridge has maintainer, I would drop bridge > > series first, and wait for ack of bridge maintainer. > > mtk-dpi is also a drm encoder, and I grep 'drm_bridge_add' and find > > many out side of bridge folder, so maybe we need to discuss more about > > this. > > Hm indeed. Maybe we need to extend the MAINTAINERS entry for bridges > so that it matches bridge drivers outside of drm/bridge. Sounds like > we have tons of those already. There are four categories of bridges: - Standalone chips. Those are in drivers/gpu/drm/bridge/ and don't cause any issue. An example is the adv7511 driver. - Third-party IP cores (Synopsys, Cadence, ...) shared by multiple SoCs, with SoC-specific glue layers. The main driver is in drivers/gpu/drm/bridge/, with glue layers typically stored in SoC-specific directories in drivers/gpu/drm/. An example is dw-hdmi. I'm toying with the idea of moving those glue layers to drivers/gpu/drm/bridge/, as many of them are entangled with the rest of the corresponding display driver (I've just had a look at the meson dw-hdmi glue recently to try and rework the dw-hdmi core, and the .mode_valid() check there calls in the main meson display driver, making things quite difficult to handle). I'm not sure if full isolation would always be possible though, I may not have enough visibility on corner cases. - SoC-specific IP cores. Those bridge drivers are stored in SoC-specific directories. Examples are rcar-lvds or omapdrm hdmi. There's a wide variety of cases here actually, with some drivers (mostly) standalone, such as the rcar-lvds. There are corner cases though, as those IP cores are designed for a particular display controller, and can thus be tightly integrated with it. In the rcar-lvds case for instance, on some of the R-Car Gen3 SoCs, the LVDS bridge provides the main clock to the display controller (I kid you not). The rcar-lvds driver exports a few functions to support that. Other bridges in this category are not even compiled as separate modules but are tightly integrated with the display controller driver. That's the case of omapdrm hdmi. It may be possible to rework that, but that wouldn't be easy, and certainly not be done overnight. It would thus be more difficult to move these drivers to drivers/gpu/drm/bridge/, and I don't believe that would be desirable. Usage of drm_bridge here isn't about reusability of the components, but about benefitting from all the bridge-related helpers instead of reinventing the wheel. > Andrzej, Neil, Laurent, Sam, any thoughts? > > I guess meanwhile this should be ok. > > > > > for you to fetch changes up to 23b29ff9f13a8fb5a12be9fedb8b614b9dede46a: > > > > drm/mediatek: Eliminate the magic number in array size (2020-05-10 > > > > 09:08:30 +0800) > > > > ---------------------------------------------------------------- > > > > Mediatek DRM Next for Linux 5.8 > > > > ---------------------------------------------------------------- > > > > Anand K Mistry (1): > > > > drm/mediatek: Stop iterating dma addresses when sg_dma_len() == 0 > > > > Bernard Zhao (2): > > > > drm/mediatek: Cleanup coding style in mediatek a bit > > > > drm/mediatek: Eliminate the magic number in array size > > > > Chun-Kuang Hu (1): > > > > Merge tag 'v5.7-next-drm-stable' of ssh://gitolite.kernel.org/.../matthias.bgg/linux into mediatek-drm-next > > > > Enric Balletbo i Serra (7): > > > > dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller > > > > soc / drm: mediatek: Move routing control to mmsys device > > > > soc / drm: mediatek: Fix mediatek-drm device probing > > > > drm/mediatek: Remove debug messages for function calls > > > > drm/mediatek: mtk_dpi: Rename bridge to next_bridge > > > > drm/mediatek: mtk_dpi: Convert to bridge driver > > > > drm/mediatek: mtk_dpi: Use simple encoder > > > > Hsin-Yi Wang (1): > > > > drm/mediatek: Fix device passed to cmdq > > > > Jitao Shi (6): > > > > dt-bindings: display: mediatek: control dpi pins mode to avoid leakage > > > > drm/mediatek: set dpi pin mode to gpio low to avoid leakage current > > > > dt-bindings: display: mediatek: add property to control mipi tx drive current > > > > dt-bindings: display: mediatek: get mipitx calibration data from nvmem > > > > drm/mediatek: add the mipitx driving control > > > > drm/mediatek: config mipitx impedance with calibration data > > > > Matthias Brugger (2): > > > > drm/mediatek: Omit warning on probe defers > > > > clk / soc: mediatek: Move mt8173 MMSYS to platform driver > > > > YueHaibing (1): > > > > drm/mediatek: Fix Kconfig warning > > > > Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- > > > > Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt | 6 + > > > > Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 10 ++ > > > > drivers/clk/mediatek/Kconfig | 7 + > > > > drivers/clk/mediatek/Makefile | 1 + > > > > drivers/clk/mediatek/clk-mt8173-mm.c | 146 +++++++++++++++++++ > > > > drivers/clk/mediatek/clk-mt8173.c | 104 -------------- > > > > drivers/gpu/drm/mediatek/Kconfig | 1 + > > > > drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- > > > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- > > > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- > > > > drivers/gpu/drm/mediatek/mtk_dpi.c | 127 ++++++++++------- > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 27 ++-- > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 259 +--------------------------------- > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 - > > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 50 +++---- > > > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +- > > > > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 3 + > > > > drivers/gpu/drm/mediatek/mtk_dsi.c | 8 +- > > > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 22 ++- > > > > drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 54 +++++++ > > > > drivers/gpu/drm/mediatek/mtk_mipi_tx.h | 4 + > > > > drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 28 ++++ > > > > drivers/soc/mediatek/Kconfig | 8 ++ > > > > drivers/soc/mediatek/Makefile | 1 + > > > > drivers/soc/mediatek/mtk-mmsys.c | 337 ++++++++++++++++++++++++++++++++++++++++++++ > > > > include/linux/soc/mediatek/mtk-mmsys.h | 20 +++ > > > > 27 files changed, 778 insertions(+), 476 deletions(-) > > > > create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c > > > > create mode 100644 drivers/soc/mediatek/mtk-mmsys.c > > > > create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
