On 07/06/2016 07:28 AM, Nicolas Boichat wrote:
Hi Archit,
Sorry got swamped by other things and forgot to reply.
On Tue, Jun 28, 2016 at 4:28 PM, Archit Taneja <architt@xxxxxxxxxxxxxx> wrote:
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?
Yes.
Is there only one connector at the end of both the output paths?
Err, there are:
- 2 physical connectors (HDMI, USB-C)
- 1 DT connector in the device tree (native HDMI), I don't bother
adding a connector to anx7688, but in theory I could.
- 1 DRM connector object (defined in the mtk hdmi driver)
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?
The mux is controlled in hardware, by looking at both HPD lines:
- USB-C (HPD controlled by ANX7688, depending if there is a DP over
USB-C device connected)
- native HDMI (HPD controlled by monitor on remote side)
Note that, like the other HDMI lines, HPD is "muxed" (depending on the
logic above), and wired up to MTK SoC HDMI/CEC module, which generates
the interrupts.
Priority is set to native HDMI port, so if both HPD signals are
active, the output will stay on the HDMI port.
Thanks for the clarification.
It's a strange setup. It would be ideal to have 2 connectors visible to
userspace, with only one of them being 'DRM_MODE_CONNECTED' at a time.
There would be a bit of an overkill whenever userspace gets a hotplug
event, resulting in tearing down and setting up crtcs, encoders even
though nothing really changes much upstream.
I think the mux bridge part looks fine, but I don't know what's the best
way how to describe the connectors here :) (one drm_connector
representing both the physical connectors, or 2 separate drm_connector
entities which both can't be connected at the same time). Maybe someone
else from the list could help us out here.
Archit
Best,
Nicolas
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
--
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
