From: Nicolas Boichat <drinkcat@chromium.org>
To: dri-devel@lists.freedesktop.org
Cc: Archit Taneja <architt@codeaurora.org>,
Thierry Reding <treding@nvidia.com>,
Nicolas Boichat <drinkcat@chromium.org>,
Russell King <rmk+kernel@arm.linux.org.uk>,
linux-kernel@vger.kernel.org, p.zabel@pengutronix.de,
marcheu@chromium.org
Subject: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers
Date: Mon, 27 Jun 2016 15:48:43 +0800 [thread overview]
Message-ID: <1467013727-11482-1-git-send-email-drinkcat@chromium.org> (raw)
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.
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
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.
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
--
2.8.0.rc3.226.g39d4020
next reply other threads:[~2016-06-27 7:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-27 7:48 Nicolas Boichat [this message]
2016-06-27 7:48 ` [RFC PATCHv2 1/4] FROMLIST: drm: bridge: anx7688: Add anx7688 bridge driver support Nicolas Boichat
2016-06-27 7:48 ` [RFC PATCH 2/4] devicetree: Add ANX7688 transmitter binding Nicolas Boichat
2016-06-27 7:48 ` [RFC PATCH 3/4] CHROMIUM: drm: bridge: Generic GPIO mux driver Nicolas Boichat
2016-06-28 8:52 ` Archit Taneja
2016-06-27 7:48 ` [RFC PATCH 4/4] CHROMIUM: devicetree: Add GPIO display mux binding Nicolas Boichat
2016-06-28 8:28 ` [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers Archit Taneja
2016-07-06 1:58 ` Nicolas Boichat
2016-07-12 4:59 ` Archit Taneja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1467013727-11482-1-git-send-email-drinkcat@chromium.org \
--to=drinkcat@chromium.org \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=p.zabel@pengutronix.de \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®