linux-kernel - [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Jun 2016 15:48:43 +0800
From:	Nicolas Boichat <drinkcat@...omium.org>
To:	dri-devel@...ts.freedesktop.org
Cc:	Archit Taneja <architt@...eaurora.org>,
	Thierry Reding <treding@...dia.com>,
	Nicolas Boichat <drinkcat@...omium.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	linux-kernel@...r.kernel.org, p.zabel@...gutronix.de,
	marcheu@...omium.org
Subject: [RFC PATCH 0/4] drm: bridge: anx7688 and mux drivers

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