Mailing List Archive: [PATCH v3 0/5] Add generic-display-mux driver and bindings

[PATCH v3 0/5] Add generic-display-mux driver and bindings

Feb 18, 2023, 4:15 AM

Post #1 of 3 (17 views)

This series is developed for and tested on MT8173 board, and the layout is:

/-- anx7688
-- MT8173 HDMI bridge -- GPIO mux
\-- native HDMI

v2: https://lore.kernel.org/all/20230116110820.2615650-1-treapking@chromium.org/
v1: https://patchwork.kernel.org/project/dri-devel/cover/20191211061911.238393-1-hsinyi@chromium.org/

Changes in v3:
- Removed ddc-i2c-bus in the gpio-mux bridge bindings
- Added .get_edid callback in generic-gpio-mux driver
- Removed .get_edid callback in mtk_hdmi.c
- Modified anx7688 driver and binding to add a .get_edid callback

Changes in v2:
- Referenced existing dt-binding schemas from graph.yaml
- Added ddc-i2c-bus into the bindings
- Dropped attach/mode_set/enable/disable callbacks
- Fixed style issues
- Removed the special case for the HDMI connector
- Made the driver only read the GPIO status in IRQ handler
- Rebased to drm-misc-next
- Update the license: "GPL v2" --> "GPL"

Nicolas Boichat (2):
dt-bindings: display: bridge: Add GPIO display mux binding
drm: bridge: Generic GPIO mux driver

Pin-yen Lin (3):
dt-bindings: display: bridge: Add ddc-i2c-bus for anx7688
drm/bridge: Add .get_edid callback for anx7688 driver
drm/mediatek: Remove .get_edid callback

.../bridge/google,cros-ec-anx7688.yaml | 5 +
.../bindings/display/bridge/gpio-mux.yaml | 90 +++++++
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/cros-ec-anx7688.c | 24 ++
drivers/gpu/drm/bridge/generic-gpio-mux.c | 222 ++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 53 +----
7 files changed, 365 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c

--
2.39.2.637.g21b0678d19-goog

Re: [PATCH v3 0/5] Add generic-display-mux driver and bindings [ In reply to ]

jagan at amarulasolutions

Mar 29, 2023, 12:15 PM

Post #2 of 3 (12 views)

Permalink

On Sat, Feb 18, 2023 at 4:47?PM Pin-yen Lin <treapking@chromium.org> wrote:
>
> This series is developed for and tested on MT8173 board, and the layout is:
>
> /-- anx7688
> -- MT8173 HDMI bridge -- GPIO mux
> \-- native HDMI

What is the part number of this GPIO mux? Does mux gpio interrupt
based and able to switch output HDMI and DP. If so, how this gpio
interrupt is different than the HPD in native HDMI? I mean does HPD
have any detection bottlenecks with mux gpio interrupt?

I do have GPIO Mux that input DSI and two outputs DMD/HDMI Input and
HDMI Out. 2x1 with 1x2 mux.

I'm thinking having a generic mux to select the specific out number of
outputs with associated interface outputs can be a viable solution to
address all use cases here.

Thanks,
Jagan.

Re: [PATCH v3 0/5] Add generic-display-mux driver and bindings [ In reply to ]

wenst at chromium

Mar 29, 2023, 10:15 PM

Post #3 of 3 (12 views)

Permalink

On Thu, Mar 30, 2023 at 2:10?AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> On Sat, Feb 18, 2023 at 4:47?PM Pin-yen Lin <treapking@chromium.org> wrote:
> >
> > This series is developed for and tested on MT8173 board, and the layout is:
> >
> > /-- anx7688
> > -- MT8173 HDMI bridge -- GPIO mux
> > \-- native HDMI
>
> What is the part number of this GPIO mux? Does mux gpio interrupt
> based and able to switch output HDMI and DP. If so, how this gpio
> interrupt is different than the HPD in native HDMI? I mean does HPD
> have any detection bottlenecks with mux gpio interrupt?

It's a full blown HDMI 1:2 demultiplexer, so DDC and HPD signals are muxed
as well. The anx7688 handles all the Type-C stuff, and our EC talks to it.
If HDMI output from the SoC needs to be muxed over for DP alt-mode, the EC
will signal the SoC.

> I do have GPIO Mux that input DSI and two outputs DMD/HDMI Input and
> HDMI Out. 2x1 with 1x2 mux.
>
> I'm thinking having a generic mux to select the specific out number of
> outputs with associated interface outputs can be a viable solution to
> address all use cases here.

AFAIK DRM doesn't allow dynamically changing the constitution of a display
pipeline, so it doesn't really work out for us.

If you're just muxing between different outputs with passive/dumb bridges,
it may still work for you.

ChenYu