On 06/27/2016 01:18 PM, Nicolas Boichat wrote:
Hi all,
This is a follow up to the 2 patches to add support for ANX7688 sent here:
https://patchwork.kernel.org/patch/9187809/, thanks Archit and Philipp for
the comments.
I also added 2 patches to add support for a simple display MUX, as I'm facing
similar issues while trying to implement it, i.e. the current DRM core does not
seem to support this kind of simple pass-thru bridge very well: it is not very
clear where connectors should be defined and attached. In this case, not
defining any connectors in the 2 bridges (and reusing the connector in MTK
HDMI driver) seem to work best, but makes little logical sense as the physical
connectors are actually attached to the bridges.
Bridges aren't really drm objects in themselves, they can just be
thought of as entities that attach to an encoder. From a drm
perspective, the connector is only linked to an encoder. It
doesn't see any bridges. Therefore, it doesn't matter much
if the bridge driver doesn't create connectors. The DT bindings,
however, should be close to the physical connections.
In any case, the board has the following layout:
- MT8173 HDMI bridge
- HDMI mux with 2 ports
1. ANX7688 for HDMI->DP over USB-C conversion
2. Native HDMI
So, the MTK SoC's HDMI output (TMDS lines) can be routed to the
connector on the board directly (native mode), or via the ANX7688
bridge using the gpio mux. Did I get this part right?
Is there only one connector at the end of both the output paths?
The mux is controlled by hardware, looking at the HPD signals from both ANX7688
and native HDMI, with a priority on the native HDMI output.
I didn't understand this. I can see that ANX7688 could generate a HPD
signal on behalf of the connected monitor, but why would the native MTK
HDMI controller generate a HPD signal? I would expect it to receive HPD
and trigger a CPU interrupt.
Could you also give an idea about why the hardware switches between the
two paths? It it based on what kind of device plugs into the connector?
Thanks,
Archit
The whole setup works fairly well without any Linux kernel drivers, except the
2 following cases:
1. When ANX7688 is active, DP bandwidth may be limited, so we need to filter
resolutions that would exceed the available bandwidth.
2. When both outputs HPD signals are active, the kernel does not receive an
HPD pulse when the HDMI input is unplugged.
ANX7688 driver fixes issue 1. The mux driver fixes 2 by forcing the kernel to
re-read the EDID on mux output change, and also issue 1 by filtering only when
ANX7688 is active.
I understand this patch series might not be acceptable as-is, but I hope this
sort of setup can be taken into account when better support for connector
drivers is introduced.
Thanks!
Best,
Nicolas
Nicolas Boichat (4):
drm: bridge: anx7688: Add anx7688 bridge driver support.
devicetree: Add ANX7688 transmitter binding
drm: bridge: Generic GPIO mux driver
devicetree: Add GPIO display mux binding
.../devicetree/bindings/drm/bridge/anx7688.txt | 32 ++
.../devicetree/bindings/drm/bridge/gpio-mux.txt | 59 ++++
drivers/gpu/drm/bridge/Kconfig | 20 ++
drivers/gpu/drm/bridge/Makefile | 2 +
drivers/gpu/drm/bridge/analogix-anx7688.c | 233 ++++++++++++++
drivers/gpu/drm/bridge/generic-gpio-mux.c | 347 +++++++++++++++++++++
6 files changed, 693 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/anx7688.txt
create mode 100644 Documentation/devicetree/bindings/drm/bridge/gpio-mux.txt
create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
