* [PATCH RESEND 0/4] drm: bridge: anx7688 and mux drivers
@ 2019-12-11 6:19 ` Hsin-Yi Wang
0 siblings, 0 replies; 51+ messages in thread
From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda,
Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King
This is a resend of [1] with a few modification due to drm core function
changes and use regmap abstraction.
The gpio mux driver is required for MT8173 board layout:
/-- anx7688
-- MT8173 HDMI bridge -- GPIO mux
\-- native HDMI
[1] https://lore.kernel.org/lkml/1467013727-11482-1-git-send-email-drinkcat@chromium.org/
Nicolas Boichat (4):
dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter
binding
drm: bridge: anx7688: Add anx7688 bridge driver support.
dt-bindings: drm/bridge: Add GPIO display mux binding
drm: bridge: Generic GPIO mux driver
.../bindings/display/bridge/anx7688.yaml | 60 ++++
.../bindings/display/bridge/gpio-mux.yaml | 89 +++++
drivers/gpu/drm/bridge/Kconfig | 19 ++
drivers/gpu/drm/bridge/Makefile | 2 +
drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++
drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++
6 files changed, 678 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml
create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c
--
2.24.0.525.g8f36a354ae-goog
^ permalink raw reply [flat|nested] 51+ messages in thread* [PATCH RESEND 0/4] drm: bridge: anx7688 and mux drivers @ 2019-12-11 6:19 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King This is a resend of [1] with a few modification due to drm core function changes and use regmap abstraction. The gpio mux driver is required for MT8173 board layout: /-- anx7688 -- MT8173 HDMI bridge -- GPIO mux \-- native HDMI [1] https://lore.kernel.org/lkml/1467013727-11482-1-git-send-email-drinkcat@chromium.org/ Nicolas Boichat (4): dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding drm: bridge: anx7688: Add anx7688 bridge driver support. dt-bindings: drm/bridge: Add GPIO display mux binding drm: bridge: Generic GPIO mux driver .../bindings/display/bridge/anx7688.yaml | 60 ++++ .../bindings/display/bridge/gpio-mux.yaml | 89 +++++ drivers/gpu/drm/bridge/Kconfig | 19 ++ drivers/gpu/drm/bridge/Makefile | 2 + drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++ drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++ 6 files changed, 678 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c -- 2.24.0.525.g8f36a354ae-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-11 6:19 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King From: Nicolas Boichat <drinkcat@chromium.org> Add support for analogix,anx7688 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- Change from RFC to v1: - txt to yaml --- .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml new file mode 100644 index 000000000000..cf79f7cf8fdf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) + +maintainers: + - Nicolas Boichat <drinkcat@chromium.org> + +description: | + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video + resolution from a smartphone or tablet with full function USB-C. + + This binding only describes the HDMI to DP display bridge. + +properties: + compatible: + const: analogix,anx7688 + + reg: + maxItems: 1 + description: I2C address of the device + + ports: + type: object + + properties: + port@0: + type: object + description: | + Video port for HDMI input + + port@1: + type: object + description: | + Video port for eDP output + + required: + - port@0 + +required: + - compatible + - reg + - ports + +examples: + - | + anx7688: anx7688@2c { + compatible = "analogix,anx7688"; + reg = <0x2c>; + + port { + anx7688_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + }; -- 2.24.0.525.g8f36a354ae-goog ^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding @ 2019-12-11 6:19 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King From: Nicolas Boichat <drinkcat@chromium.org> Add support for analogix,anx7688 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- Change from RFC to v1: - txt to yaml --- .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml new file mode 100644 index 000000000000..cf79f7cf8fdf --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) + +maintainers: + - Nicolas Boichat <drinkcat@chromium.org> + +description: | + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video + resolution from a smartphone or tablet with full function USB-C. + + This binding only describes the HDMI to DP display bridge. + +properties: + compatible: + const: analogix,anx7688 + + reg: + maxItems: 1 + description: I2C address of the device + + ports: + type: object + + properties: + port@0: + type: object + description: | + Video port for HDMI input + + port@1: + type: object + description: | + Video port for eDP output + + required: + - port@0 + +required: + - compatible + - reg + - ports + +examples: + - | + anx7688: anx7688@2c { + compatible = "analogix,anx7688"; + reg = <0x2c>; + + port { + anx7688_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + }; -- 2.24.0.525.g8f36a354ae-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-19 20:45 ` Rob Herring -1 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-19 20:45 UTC (permalink / raw) To: Hsin-Yi Wang Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > Add support for analogix,anx7688 > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > Change from RFC to v1: > - txt to yaml > --- > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > 1 file changed, 60 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > new file mode 100644 > index 000000000000..cf79f7cf8fdf > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > @@ -0,0 +1,60 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > + > +maintainers: > + - Nicolas Boichat <drinkcat@chromium.org> > + > +description: | > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > + resolution from a smartphone or tablet with full function USB-C. > + > + This binding only describes the HDMI to DP display bridge. > + > +properties: > + compatible: > + const: analogix,anx7688 > + > + reg: > + maxItems: 1 > + description: I2C address of the device > + > + ports: > + type: object > + > + properties: > + port@0: > + type: object > + description: | > + Video port for HDMI input > + > + port@1: > + type: object > + description: | > + Video port for eDP output > + > + required: > + - port@0 Sometimes you have no output? > + > +required: > + - compatible > + - reg > + - ports The example will have errors because it is missing 'ports'. Run 'make dt_binding_check'. Add: additionalProperties: false > + > +examples: > + - | > + anx7688: anx7688@2c { > + compatible = "analogix,anx7688"; > + reg = <0x2c>; > + > + port { > + anx7688_in: endpoint { > + remote-endpoint = <&hdmi0_out>; > + }; > + }; > + }; > -- > 2.24.0.525.g8f36a354ae-goog > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding @ 2019-12-19 20:45 ` Rob Herring 0 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-19 20:45 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > Add support for analogix,anx7688 > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > Change from RFC to v1: > - txt to yaml > --- > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > 1 file changed, 60 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > new file mode 100644 > index 000000000000..cf79f7cf8fdf > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > @@ -0,0 +1,60 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > + > +maintainers: > + - Nicolas Boichat <drinkcat@chromium.org> > + > +description: | > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > + resolution from a smartphone or tablet with full function USB-C. > + > + This binding only describes the HDMI to DP display bridge. > + > +properties: > + compatible: > + const: analogix,anx7688 > + > + reg: > + maxItems: 1 > + description: I2C address of the device > + > + ports: > + type: object > + > + properties: > + port@0: > + type: object > + description: | > + Video port for HDMI input > + > + port@1: > + type: object > + description: | > + Video port for eDP output > + > + required: > + - port@0 Sometimes you have no output? > + > +required: > + - compatible > + - reg > + - ports The example will have errors because it is missing 'ports'. Run 'make dt_binding_check'. Add: additionalProperties: false > + > +examples: > + - | > + anx7688: anx7688@2c { > + compatible = "analogix,anx7688"; > + reg = <0x2c>; > + > + port { > + anx7688_in: endpoint { > + remote-endpoint = <&hdmi0_out>; > + }; > + }; > + }; > -- > 2.24.0.525.g8f36a354ae-goog > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding 2019-12-19 20:45 ` Rob Herring @ 2019-12-20 3:20 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:20 UTC (permalink / raw) To: Rob Herring Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Fri, Dec 20, 2019 at 4:45 AM Rob Herring <robh@kernel.org> wrote: > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > Add support for analogix,anx7688 > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > Change from RFC to v1: > > - txt to yaml > > --- > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > 1 file changed, 60 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > new file mode 100644 > > index 000000000000..cf79f7cf8fdf > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > @@ -0,0 +1,60 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > + > > +maintainers: > > + - Nicolas Boichat <drinkcat@chromium.org> > > + > > +description: | > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > + resolution from a smartphone or tablet with full function USB-C. > > + > > + This binding only describes the HDMI to DP display bridge. > > + > > +properties: > > + compatible: > > + const: analogix,anx7688 > > + > > + reg: > > + maxItems: 1 > > + description: I2C address of the device > > + > > + ports: > > + type: object > > + > > + properties: > > + port@0: > > + type: object > > + description: | > > + Video port for HDMI input > > + > > + port@1: > > + type: object > > + description: | > > + Video port for eDP output > > + > > + required: > > + - port@0 > > Sometimes you have no output? Yes, only input is required. > > > + > > +required: > > + - compatible > > + - reg > > + - ports > > The example will have errors because it is missing 'ports'. Run 'make > dt_binding_check'. > > Add: > > additionalProperties: false > Ack, will fix this. Thanks > > + > > +examples: > > + - | > > + anx7688: anx7688@2c { > > + compatible = "analogix,anx7688"; > > + reg = <0x2c>; > > + > > + port { > > + anx7688_in: endpoint { > > + remote-endpoint = <&hdmi0_out>; > > + }; > > + }; > > + }; > > -- > > 2.24.0.525.g8f36a354ae-goog > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding @ 2019-12-20 3:20 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:20 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Fri, Dec 20, 2019 at 4:45 AM Rob Herring <robh@kernel.org> wrote: > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > Add support for analogix,anx7688 > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > Change from RFC to v1: > > - txt to yaml > > --- > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > 1 file changed, 60 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > new file mode 100644 > > index 000000000000..cf79f7cf8fdf > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > @@ -0,0 +1,60 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > + > > +maintainers: > > + - Nicolas Boichat <drinkcat@chromium.org> > > + > > +description: | > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > + resolution from a smartphone or tablet with full function USB-C. > > + > > + This binding only describes the HDMI to DP display bridge. > > + > > +properties: > > + compatible: > > + const: analogix,anx7688 > > + > > + reg: > > + maxItems: 1 > > + description: I2C address of the device > > + > > + ports: > > + type: object > > + > > + properties: > > + port@0: > > + type: object > > + description: | > > + Video port for HDMI input > > + > > + port@1: > > + type: object > > + description: | > > + Video port for eDP output > > + > > + required: > > + - port@0 > > Sometimes you have no output? Yes, only input is required. > > > + > > +required: > > + - compatible > > + - reg > > + - ports > > The example will have errors because it is missing 'ports'. Run 'make > dt_binding_check'. > > Add: > > additionalProperties: false > Ack, will fix this. Thanks > > + > > +examples: > > + - | > > + anx7688: anx7688@2c { > > + compatible = "analogix,anx7688"; > > + reg = <0x2c>; > > + > > + port { > > + anx7688_in: endpoint { > > + remote-endpoint = <&hdmi0_out>; > > + }; > > + }; > > + }; > > -- > > 2.24.0.525.g8f36a354ae-goog > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding 2019-12-20 3:20 ` Hsin-Yi Wang @ 2019-12-20 3:22 ` Laurent Pinchart -1 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-20 3:22 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Rob Herring, dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hi Hsin-Yi, On Fri, Dec 20, 2019 at 11:20:13AM +0800, Hsin-Yi Wang wrote: > On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote: > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Add support for analogix,anx7688 > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > Change from RFC to v1: > > > - txt to yaml > > > --- > > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > > 1 file changed, 60 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > new file mode 100644 > > > index 000000000000..cf79f7cf8fdf > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > @@ -0,0 +1,60 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > > + > > > +maintainers: > > > + - Nicolas Boichat <drinkcat@chromium.org> > > > + > > > +description: | > > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > > + resolution from a smartphone or tablet with full function USB-C. > > > + > > > + This binding only describes the HDMI to DP display bridge. > > > + > > > +properties: > > > + compatible: > > > + const: analogix,anx7688 > > > + > > > + reg: > > > + maxItems: 1 > > > + description: I2C address of the device > > > + > > > + ports: > > > + type: object > > > + > > > + properties: > > > + port@0: > > > + type: object > > > + description: | > > > + Video port for HDMI input > > > + > > > + port@1: > > > + type: object > > > + description: | > > > + Video port for eDP output > > > + > > > + required: > > > + - port@0 > > > > Sometimes you have no output? > > Yes, only input is required. But what happens in that case ? What's the use of a bridge with a non-connected output ? :-) > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - ports > > > > The example will have errors because it is missing 'ports'. Run 'make > > dt_binding_check'. > > > > Add: > > > > additionalProperties: false > > > > Ack, will fix this. Thanks > > > > + > > > +examples: > > > + - | > > > + anx7688: anx7688@2c { > > > + compatible = "analogix,anx7688"; > > > + reg = <0x2c>; > > > + > > > + port { > > > + anx7688_in: endpoint { > > > + remote-endpoint = <&hdmi0_out>; > > > + }; > > > + }; > > > + }; -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding @ 2019-12-20 3:22 ` Laurent Pinchart 0 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-20 3:22 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, Jernej Skrabec, Nicolas Boichat, Devicetree List, David Airlie, Neil Armstrong, lkml, dri-devel, Jonas Karlman, Matthias Brugger, Enric Balletbo i Serra, Russell King Hi Hsin-Yi, On Fri, Dec 20, 2019 at 11:20:13AM +0800, Hsin-Yi Wang wrote: > On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote: > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Add support for analogix,anx7688 > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > Change from RFC to v1: > > > - txt to yaml > > > --- > > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > > 1 file changed, 60 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > new file mode 100644 > > > index 000000000000..cf79f7cf8fdf > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > @@ -0,0 +1,60 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > > + > > > +maintainers: > > > + - Nicolas Boichat <drinkcat@chromium.org> > > > + > > > +description: | > > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > > + resolution from a smartphone or tablet with full function USB-C. > > > + > > > + This binding only describes the HDMI to DP display bridge. > > > + > > > +properties: > > > + compatible: > > > + const: analogix,anx7688 > > > + > > > + reg: > > > + maxItems: 1 > > > + description: I2C address of the device > > > + > > > + ports: > > > + type: object > > > + > > > + properties: > > > + port@0: > > > + type: object > > > + description: | > > > + Video port for HDMI input > > > + > > > + port@1: > > > + type: object > > > + description: | > > > + Video port for eDP output > > > + > > > + required: > > > + - port@0 > > > > Sometimes you have no output? > > Yes, only input is required. But what happens in that case ? What's the use of a bridge with a non-connected output ? :-) > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - ports > > > > The example will have errors because it is missing 'ports'. Run 'make > > dt_binding_check'. > > > > Add: > > > > additionalProperties: false > > > > Ack, will fix this. Thanks > > > > + > > > +examples: > > > + - | > > > + anx7688: anx7688@2c { > > > + compatible = "analogix,anx7688"; > > > + reg = <0x2c>; > > > + > > > + port { > > > + anx7688_in: endpoint { > > > + remote-endpoint = <&hdmi0_out>; > > > + }; > > > + }; > > > + }; -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding 2019-12-20 3:22 ` Laurent Pinchart @ 2019-12-20 3:51 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:51 UTC (permalink / raw) To: Laurent Pinchart Cc: Rob Herring, dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Fri, Dec 20, 2019 at 11:22 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi, > > On Fri, Dec 20, 2019 at 11:20:13AM +0800, Hsin-Yi Wang wrote: > > On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote: > > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Add support for analogix,anx7688 > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > Change from RFC to v1: > > > > - txt to yaml > > > > --- > > > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > > > 1 file changed, 60 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > new file mode 100644 > > > > index 000000000000..cf79f7cf8fdf > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > @@ -0,0 +1,60 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > > > + > > > > +maintainers: > > > > + - Nicolas Boichat <drinkcat@chromium.org> > > > > + > > > > +description: | > > > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > > > + resolution from a smartphone or tablet with full function USB-C. > > > > + > > > > + This binding only describes the HDMI to DP display bridge. > > > > + > > > > +properties: > > > > + compatible: > > > > + const: analogix,anx7688 > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + description: I2C address of the device > > > > + > > > > + ports: > > > > + type: object > > > > + > > > > + properties: > > > > + port@0: > > > > + type: object > > > > + description: | > > > > + Video port for HDMI input > > > > + > > > > + port@1: > > > > + type: object > > > > + description: | > > > > + Video port for eDP output > > > > + > > > > + required: > > > > + - port@0 > > > > > > Sometimes you have no output? > > > > Yes, only input is required. > > But what happens in that case ? What's the use of a bridge with a > non-connected output ? :-) > There's output connected, but doesn't need a driver. For example, in our use case it's connected to a usb-c connector. We don't need to state it in dts. I also checked https://elixir.bootlin.com/linux/v5.5-rc2/source/Documentation/devicetree/bindings/display/bridge/anx6345.yaml and thought that output could be optional. Also https://elixir.bootlin.com/linux/v5.5-rc2/source/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts#L116 Or maybe we can add output in example as anx6345? > > > > + > > > > +required: > > > > + - compatible > > > > + - reg > > > > + - ports > > > > > > The example will have errors because it is missing 'ports'. Run 'make > > > dt_binding_check'. > > > > > > Add: > > > > > > additionalProperties: false > > > > > > > Ack, will fix this. Thanks > > > > > > + > > > > +examples: > > > > + - | > > > > + anx7688: anx7688@2c { > > > > + compatible = "analogix,anx7688"; > > > > + reg = <0x2c>; > > > > + > > > > + port { > > > > + anx7688_in: endpoint { > > > > + remote-endpoint = <&hdmi0_out>; > > > > + }; > > > > + }; > > > > + }; > > -- > Regards, > > Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding @ 2019-12-20 3:51 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:51 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Jernej Skrabec, Nicolas Boichat, Devicetree List, David Airlie, Neil Armstrong, lkml, dri-devel, Jonas Karlman, Matthias Brugger, Enric Balletbo i Serra, Russell King On Fri, Dec 20, 2019 at 11:22 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi, > > On Fri, Dec 20, 2019 at 11:20:13AM +0800, Hsin-Yi Wang wrote: > > On Fri, Dec 20, 2019 at 4:45 AM Rob Herring wrote: > > > On Wed, Dec 11, 2019 at 02:19:08PM +0800, Hsin-Yi Wang wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Add support for analogix,anx7688 > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > Change from RFC to v1: > > > > - txt to yaml > > > > --- > > > > .../bindings/display/bridge/anx7688.yaml | 60 +++++++++++++++++++ > > > > 1 file changed, 60 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > new file mode 100644 > > > > index 000000000000..cf79f7cf8fdf > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml > > > > @@ -0,0 +1,60 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C) > > > > + > > > > +maintainers: > > > > + - Nicolas Boichat <drinkcat@chromium.org> > > > > + > > > > +description: | > > > > + The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per > > > > + second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video > > > > + resolution from a smartphone or tablet with full function USB-C. > > > > + > > > > + This binding only describes the HDMI to DP display bridge. > > > > + > > > > +properties: > > > > + compatible: > > > > + const: analogix,anx7688 > > > > + > > > > + reg: > > > > + maxItems: 1 > > > > + description: I2C address of the device > > > > + > > > > + ports: > > > > + type: object > > > > + > > > > + properties: > > > > + port@0: > > > > + type: object > > > > + description: | > > > > + Video port for HDMI input > > > > + > > > > + port@1: > > > > + type: object > > > > + description: | > > > > + Video port for eDP output > > > > + > > > > + required: > > > > + - port@0 > > > > > > Sometimes you have no output? > > > > Yes, only input is required. > > But what happens in that case ? What's the use of a bridge with a > non-connected output ? :-) > There's output connected, but doesn't need a driver. For example, in our use case it's connected to a usb-c connector. We don't need to state it in dts. I also checked https://elixir.bootlin.com/linux/v5.5-rc2/source/Documentation/devicetree/bindings/display/bridge/anx6345.yaml and thought that output could be optional. Also https://elixir.bootlin.com/linux/v5.5-rc2/source/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts#L116 Or maybe we can add output in example as anx6345? > > > > + > > > > +required: > > > > + - compatible > > > > + - reg > > > > + - ports > > > > > > The example will have errors because it is missing 'ports'. Run 'make > > > dt_binding_check'. > > > > > > Add: > > > > > > additionalProperties: false > > > > > > > Ack, will fix this. Thanks > > > > > > + > > > > +examples: > > > > + - | > > > > + anx7688: anx7688@2c { > > > > + compatible = "analogix,anx7688"; > > > > + reg = <0x2c>; > > > > + > > > > + port { > > > > + anx7688_in: endpoint { > > > > + remote-endpoint = <&hdmi0_out>; > > > > + }; > > > > + }; > > > > + }; > > -- > Regards, > > Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-11 6:19 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King From: Nicolas Boichat <drinkcat@chromium.org> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), that has an internal microcontroller. The only reason a Linux kernel driver is necessary is to reject resolutions that require more bandwidth than what is available on the DP side. DP bandwidth and lane count are reported by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ 3 files changed, 212 insertions(+) create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 34362976cd6f..1f3fc6bec842 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE menu "Display Interface Bridges" depends on DRM && DRM_BRIDGE +config DRM_ANALOGIX_ANX7688 + tristate "Analogix ANX7688 bridge" + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + ANX7688 is a transmitter to support DisplayPort over USB-C for + smartphone and tablets. + This driver only supports the HDMI to DP component of the chip. + config DRM_ANALOGIX_ANX78XX tristate "Analogix ANX78XX bridge" select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 4934fcf5a6f8..7a1e0ec032e6 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c new file mode 100644 index 000000000000..baaed48d6201 --- /dev/null +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c @@ -0,0 +1,202 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ANX7688 HDMI->DP bridge driver + * + * Copyright 2016 Google LLC + */ + +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/regmap.h> +#include <drm/drm_bridge.h> + +/* Register addresses */ +#define VENDOR_ID_REG 0x00 +#define DEVICE_ID_REG 0x02 + +#define FW_VERSION_REG 0x80 + +#define DP_BANDWIDTH_REG 0x85 +#define DP_LANE_COUNT_REG 0x86 + +#define VENDOR_ID 0x1f29 +#define DEVICE_ID 0x7688 + +/* First supported firmware version (0.85) */ +#define MINIMUM_FW_VERSION 0x0085 + +struct anx7688 { + struct drm_bridge bridge; + struct i2c_client *client; + struct regmap *regmap; + + bool filter; +}; + +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) +{ + return container_of(bridge, struct anx7688, bridge); +} + +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); + u8 regs[2]; + u8 dpbw, lanecount; + int totalbw, requiredbw; + int ret; + + if (!anx7688->filter) + return true; + + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); + if (ret < 0) { + dev_err(&anx7688->client->dev, + "Failed to read bandwidth/lane count\n"); + return false; + } + dpbw = regs[0]; + lanecount = regs[1]; + + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ + if (dpbw > 0x19 || lanecount > 2) { + dev_err(&anx7688->client->dev, + "Invalid bandwidth/lane count (%02x/%d)\n", + dpbw, lanecount); + return false; + } + + /* Compute available bandwidth (kHz) */ + totalbw = dpbw * lanecount * 270000 * 8 / 10; + + /* Required bandwidth (8 bpc, kHz) */ + requiredbw = mode->clock * 8 * 3; + + dev_dbg(&anx7688->client->dev, + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", + totalbw, dpbw, lanecount, requiredbw); + + if (totalbw == 0) { + dev_warn(&anx7688->client->dev, + "Bandwidth/lane count are 0, not rejecting modes\n"); + return true; + } + + return totalbw >= requiredbw; +} + +static const struct drm_bridge_funcs anx7688_bridge_funcs = { + .mode_fixup = anx7688_bridge_mode_fixup, +}; + +static const struct regmap_config anx7688_regmap_config = { + .reg_bits = 8, + .val_bits = 8, +}; + +static int anx7688_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct anx7688 *anx7688; + struct device *dev = &client->dev; + int ret; + u8 buffer[4]; + u16 vendor, device, fwversion; + + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); + if (!anx7688) + return -ENOMEM; + +#if IS_ENABLED(CONFIG_OF) + anx7688->bridge.of_node = client->dev.of_node; +#endif + + anx7688->client = client; + i2c_set_clientdata(client, anx7688); + + anx7688->regmap = + devm_regmap_init_i2c(client, &anx7688_regmap_config); + + /* Read both vendor and device id (4 bytes). */ + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); + if (ret) { + dev_err(dev, "Failed to read chip vendor/device id\n"); + return ret; + } + + vendor = (u16)buffer[1] << 8 | buffer[0]; + device = (u16)buffer[3] << 8 | buffer[2]; + if (vendor != VENDOR_ID || device != DEVICE_ID) { + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", + vendor, device); + return -ENODEV; + } + + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); + if (ret) { + dev_err(&client->dev, "Failed to read firmware version\n"); + return ret; + } + + fwversion = (u16)buffer[0] << 8 | buffer[1]; + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", + buffer[0], buffer[1]); + + /* FW version >= 0.85 supports bandwidth/lane count registers */ + if (fwversion >= MINIMUM_FW_VERSION) { + anx7688->filter = true; + } else { + /* Warn, but not fail, for backwards compatibility. */ + dev_warn(dev, + "Old ANX7688 FW version (%02x.%02x), not filtering\n", + buffer[0], buffer[1]); + } + + anx7688->bridge.funcs = &anx7688_bridge_funcs; + drm_bridge_add(&anx7688->bridge); + + return 0; +} + +static int anx7688_i2c_remove(struct i2c_client *client) +{ + struct anx7688 *anx7688 = i2c_get_clientdata(client); + + drm_bridge_remove(&anx7688->bridge); + + return 0; +} + +static const struct i2c_device_id anx7688_id[] = { + { "anx7688", 0 }, + { /* sentinel */ } +}; + +MODULE_DEVICE_TABLE(i2c, anx7688_id); + +#if IS_ENABLED(CONFIG_OF) +static const struct of_device_id anx7688_match_table[] = { + { .compatible = "analogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), + }, + .probe = anx7688_i2c_probe, + .remove = anx7688_i2c_remove, + .id_table = anx7688_id, +}; + +module_i2c_driver(anx7688_driver); + +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.525.g8f36a354ae-goog ^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-11 6:19 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King From: Nicolas Boichat <drinkcat@chromium.org> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), that has an internal microcontroller. The only reason a Linux kernel driver is necessary is to reject resolutions that require more bandwidth than what is available on the DP side. DP bandwidth and lane count are reported by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ 3 files changed, 212 insertions(+) create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 34362976cd6f..1f3fc6bec842 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE menu "Display Interface Bridges" depends on DRM && DRM_BRIDGE +config DRM_ANALOGIX_ANX7688 + tristate "Analogix ANX7688 bridge" + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + ANX7688 is a transmitter to support DisplayPort over USB-C for + smartphone and tablets. + This driver only supports the HDMI to DP component of the chip. + config DRM_ANALOGIX_ANX78XX tristate "Analogix ANX78XX bridge" select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 4934fcf5a6f8..7a1e0ec032e6 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c new file mode 100644 index 000000000000..baaed48d6201 --- /dev/null +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c @@ -0,0 +1,202 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ANX7688 HDMI->DP bridge driver + * + * Copyright 2016 Google LLC + */ + +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/regmap.h> +#include <drm/drm_bridge.h> + +/* Register addresses */ +#define VENDOR_ID_REG 0x00 +#define DEVICE_ID_REG 0x02 + +#define FW_VERSION_REG 0x80 + +#define DP_BANDWIDTH_REG 0x85 +#define DP_LANE_COUNT_REG 0x86 + +#define VENDOR_ID 0x1f29 +#define DEVICE_ID 0x7688 + +/* First supported firmware version (0.85) */ +#define MINIMUM_FW_VERSION 0x0085 + +struct anx7688 { + struct drm_bridge bridge; + struct i2c_client *client; + struct regmap *regmap; + + bool filter; +}; + +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) +{ + return container_of(bridge, struct anx7688, bridge); +} + +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); + u8 regs[2]; + u8 dpbw, lanecount; + int totalbw, requiredbw; + int ret; + + if (!anx7688->filter) + return true; + + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); + if (ret < 0) { + dev_err(&anx7688->client->dev, + "Failed to read bandwidth/lane count\n"); + return false; + } + dpbw = regs[0]; + lanecount = regs[1]; + + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ + if (dpbw > 0x19 || lanecount > 2) { + dev_err(&anx7688->client->dev, + "Invalid bandwidth/lane count (%02x/%d)\n", + dpbw, lanecount); + return false; + } + + /* Compute available bandwidth (kHz) */ + totalbw = dpbw * lanecount * 270000 * 8 / 10; + + /* Required bandwidth (8 bpc, kHz) */ + requiredbw = mode->clock * 8 * 3; + + dev_dbg(&anx7688->client->dev, + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", + totalbw, dpbw, lanecount, requiredbw); + + if (totalbw == 0) { + dev_warn(&anx7688->client->dev, + "Bandwidth/lane count are 0, not rejecting modes\n"); + return true; + } + + return totalbw >= requiredbw; +} + +static const struct drm_bridge_funcs anx7688_bridge_funcs = { + .mode_fixup = anx7688_bridge_mode_fixup, +}; + +static const struct regmap_config anx7688_regmap_config = { + .reg_bits = 8, + .val_bits = 8, +}; + +static int anx7688_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct anx7688 *anx7688; + struct device *dev = &client->dev; + int ret; + u8 buffer[4]; + u16 vendor, device, fwversion; + + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); + if (!anx7688) + return -ENOMEM; + +#if IS_ENABLED(CONFIG_OF) + anx7688->bridge.of_node = client->dev.of_node; +#endif + + anx7688->client = client; + i2c_set_clientdata(client, anx7688); + + anx7688->regmap = + devm_regmap_init_i2c(client, &anx7688_regmap_config); + + /* Read both vendor and device id (4 bytes). */ + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); + if (ret) { + dev_err(dev, "Failed to read chip vendor/device id\n"); + return ret; + } + + vendor = (u16)buffer[1] << 8 | buffer[0]; + device = (u16)buffer[3] << 8 | buffer[2]; + if (vendor != VENDOR_ID || device != DEVICE_ID) { + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", + vendor, device); + return -ENODEV; + } + + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); + if (ret) { + dev_err(&client->dev, "Failed to read firmware version\n"); + return ret; + } + + fwversion = (u16)buffer[0] << 8 | buffer[1]; + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", + buffer[0], buffer[1]); + + /* FW version >= 0.85 supports bandwidth/lane count registers */ + if (fwversion >= MINIMUM_FW_VERSION) { + anx7688->filter = true; + } else { + /* Warn, but not fail, for backwards compatibility. */ + dev_warn(dev, + "Old ANX7688 FW version (%02x.%02x), not filtering\n", + buffer[0], buffer[1]); + } + + anx7688->bridge.funcs = &anx7688_bridge_funcs; + drm_bridge_add(&anx7688->bridge); + + return 0; +} + +static int anx7688_i2c_remove(struct i2c_client *client) +{ + struct anx7688 *anx7688 = i2c_get_clientdata(client); + + drm_bridge_remove(&anx7688->bridge); + + return 0; +} + +static const struct i2c_device_id anx7688_id[] = { + { "anx7688", 0 }, + { /* sentinel */ } +}; + +MODULE_DEVICE_TABLE(i2c, anx7688_id); + +#if IS_ENABLED(CONFIG_OF) +static const struct of_device_id anx7688_match_table[] = { + { .compatible = "analogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), + }, + .probe = anx7688_i2c_probe, + .remove = anx7688_i2c_remove, + .id_table = anx7688_id, +}; + +module_i2c_driver(anx7688_driver); + +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.525.g8f36a354ae-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-12 11:50 ` Enric Balletbo i Serra -1 siblings, 0 replies; 51+ messages in thread From: Enric Balletbo i Serra @ 2019-12-12 11:50 UTC (permalink / raw) To: Hsin-Yi Wang, dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Matthias Brugger, Russell King Hi Hsin-Yi, On 11/12/19 7:19, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > that has an internal microcontroller. > > The only reason a Linux kernel driver is necessary is to reject > resolutions that require more bandwidth than what is available on > the DP side. DP bandwidth and lane count are reported by the bridge > via 2 registers on I2C. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- Although I am not a drm expert I did an initial review of this patch before sending and looks good to me now. Also I just tested with current mainline on my ELM device and I am happy to have display now, so thanks for sending this upstream: Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> > drivers/gpu/drm/bridge/Kconfig | 9 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > 3 files changed, 212 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 34362976cd6f..1f3fc6bec842 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > menu "Display Interface Bridges" > depends on DRM && DRM_BRIDGE > > +config DRM_ANALOGIX_ANX7688 > + tristate "Analogix ANX7688 bridge" > + select DRM_KMS_HELPER > + select REGMAP_I2C > + ---help--- > + ANX7688 is a transmitter to support DisplayPort over USB-C for > + smartphone and tablets. > + This driver only supports the HDMI to DP component of the chip. > + > config DRM_ANALOGIX_ANX78XX > tristate "Analogix ANX78XX bridge" > select DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf5a6f8..7a1e0ec032e6 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > new file mode 100644 > index 000000000000..baaed48d6201 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > @@ -0,0 +1,202 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * ANX7688 HDMI->DP bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > +#include <linux/i2c.h> > +#include <linux/module.h> > +#include <linux/regmap.h> > +#include <drm/drm_bridge.h> > + > +/* Register addresses */ > +#define VENDOR_ID_REG 0x00 > +#define DEVICE_ID_REG 0x02 > + > +#define FW_VERSION_REG 0x80 > + > +#define DP_BANDWIDTH_REG 0x85 > +#define DP_LANE_COUNT_REG 0x86 > + > +#define VENDOR_ID 0x1f29 > +#define DEVICE_ID 0x7688 > + > +/* First supported firmware version (0.85) */ > +#define MINIMUM_FW_VERSION 0x0085 > + > +struct anx7688 { > + struct drm_bridge bridge; > + struct i2c_client *client; > + struct regmap *regmap; > + > + bool filter; > +}; > + > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct anx7688, bridge); > +} > + > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > + u8 regs[2]; > + u8 dpbw, lanecount; > + int totalbw, requiredbw; > + int ret; > + > + if (!anx7688->filter) > + return true; > + > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > + if (ret < 0) { > + dev_err(&anx7688->client->dev, > + "Failed to read bandwidth/lane count\n"); > + return false; > + } > + dpbw = regs[0]; > + lanecount = regs[1]; > + > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > + if (dpbw > 0x19 || lanecount > 2) { > + dev_err(&anx7688->client->dev, > + "Invalid bandwidth/lane count (%02x/%d)\n", > + dpbw, lanecount); > + return false; > + } > + > + /* Compute available bandwidth (kHz) */ > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > + > + /* Required bandwidth (8 bpc, kHz) */ > + requiredbw = mode->clock * 8 * 3; > + > + dev_dbg(&anx7688->client->dev, > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > + totalbw, dpbw, lanecount, requiredbw); > + > + if (totalbw == 0) { > + dev_warn(&anx7688->client->dev, > + "Bandwidth/lane count are 0, not rejecting modes\n"); > + return true; > + } > + > + return totalbw >= requiredbw; > +} > + > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > + .mode_fixup = anx7688_bridge_mode_fixup, > +}; > + > +static const struct regmap_config anx7688_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > +}; > + > +static int anx7688_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct anx7688 *anx7688; > + struct device *dev = &client->dev; > + int ret; > + u8 buffer[4]; > + u16 vendor, device, fwversion; > + > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > + if (!anx7688) > + return -ENOMEM; > + > +#if IS_ENABLED(CONFIG_OF) > + anx7688->bridge.of_node = client->dev.of_node; > +#endif > + > + anx7688->client = client; > + i2c_set_clientdata(client, anx7688); > + > + anx7688->regmap = > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > + > + /* Read both vendor and device id (4 bytes). */ > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > + if (ret) { > + dev_err(dev, "Failed to read chip vendor/device id\n"); > + return ret; > + } > + > + vendor = (u16)buffer[1] << 8 | buffer[0]; > + device = (u16)buffer[3] << 8 | buffer[2]; > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > + vendor, device); > + return -ENODEV; > + } > + > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > + if (ret) { > + dev_err(&client->dev, "Failed to read firmware version\n"); > + return ret; > + } > + > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > + buffer[0], buffer[1]); > + > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > + if (fwversion >= MINIMUM_FW_VERSION) { > + anx7688->filter = true; > + } else { > + /* Warn, but not fail, for backwards compatibility. */ > + dev_warn(dev, > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > + buffer[0], buffer[1]); > + } > + > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > + drm_bridge_add(&anx7688->bridge); > + > + return 0; > +} > + > +static int anx7688_i2c_remove(struct i2c_client *client) > +{ > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > + > + drm_bridge_remove(&anx7688->bridge); > + > + return 0; > +} > + > +static const struct i2c_device_id anx7688_id[] = { > + { "anx7688", 0 }, > + { /* sentinel */ } > +}; > + > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id anx7688_match_table[] = { > + { .compatible = "analogix,anx7688", }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > +#endif > + > +static struct i2c_driver anx7688_driver = { > + .driver = { > + .name = "anx7688", > + .of_match_table = of_match_ptr(anx7688_match_table), > + }, > + .probe = anx7688_i2c_probe, > + .remove = anx7688_i2c_remove, > + .id_table = anx7688_id, > +}; > + > +module_i2c_driver(anx7688_driver); > + > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-12 11:50 ` Enric Balletbo i Serra 0 siblings, 0 replies; 51+ messages in thread From: Enric Balletbo i Serra @ 2019-12-12 11:50 UTC (permalink / raw) To: Hsin-Yi Wang, dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Russell King Hi Hsin-Yi, On 11/12/19 7:19, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > that has an internal microcontroller. > > The only reason a Linux kernel driver is necessary is to reject > resolutions that require more bandwidth than what is available on > the DP side. DP bandwidth and lane count are reported by the bridge > via 2 registers on I2C. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- Although I am not a drm expert I did an initial review of this patch before sending and looks good to me now. Also I just tested with current mainline on my ELM device and I am happy to have display now, so thanks for sending this upstream: Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> > drivers/gpu/drm/bridge/Kconfig | 9 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > 3 files changed, 212 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 34362976cd6f..1f3fc6bec842 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > menu "Display Interface Bridges" > depends on DRM && DRM_BRIDGE > > +config DRM_ANALOGIX_ANX7688 > + tristate "Analogix ANX7688 bridge" > + select DRM_KMS_HELPER > + select REGMAP_I2C > + ---help--- > + ANX7688 is a transmitter to support DisplayPort over USB-C for > + smartphone and tablets. > + This driver only supports the HDMI to DP component of the chip. > + > config DRM_ANALOGIX_ANX78XX > tristate "Analogix ANX78XX bridge" > select DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf5a6f8..7a1e0ec032e6 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > new file mode 100644 > index 000000000000..baaed48d6201 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > @@ -0,0 +1,202 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * ANX7688 HDMI->DP bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > +#include <linux/i2c.h> > +#include <linux/module.h> > +#include <linux/regmap.h> > +#include <drm/drm_bridge.h> > + > +/* Register addresses */ > +#define VENDOR_ID_REG 0x00 > +#define DEVICE_ID_REG 0x02 > + > +#define FW_VERSION_REG 0x80 > + > +#define DP_BANDWIDTH_REG 0x85 > +#define DP_LANE_COUNT_REG 0x86 > + > +#define VENDOR_ID 0x1f29 > +#define DEVICE_ID 0x7688 > + > +/* First supported firmware version (0.85) */ > +#define MINIMUM_FW_VERSION 0x0085 > + > +struct anx7688 { > + struct drm_bridge bridge; > + struct i2c_client *client; > + struct regmap *regmap; > + > + bool filter; > +}; > + > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct anx7688, bridge); > +} > + > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > + u8 regs[2]; > + u8 dpbw, lanecount; > + int totalbw, requiredbw; > + int ret; > + > + if (!anx7688->filter) > + return true; > + > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > + if (ret < 0) { > + dev_err(&anx7688->client->dev, > + "Failed to read bandwidth/lane count\n"); > + return false; > + } > + dpbw = regs[0]; > + lanecount = regs[1]; > + > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > + if (dpbw > 0x19 || lanecount > 2) { > + dev_err(&anx7688->client->dev, > + "Invalid bandwidth/lane count (%02x/%d)\n", > + dpbw, lanecount); > + return false; > + } > + > + /* Compute available bandwidth (kHz) */ > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > + > + /* Required bandwidth (8 bpc, kHz) */ > + requiredbw = mode->clock * 8 * 3; > + > + dev_dbg(&anx7688->client->dev, > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > + totalbw, dpbw, lanecount, requiredbw); > + > + if (totalbw == 0) { > + dev_warn(&anx7688->client->dev, > + "Bandwidth/lane count are 0, not rejecting modes\n"); > + return true; > + } > + > + return totalbw >= requiredbw; > +} > + > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > + .mode_fixup = anx7688_bridge_mode_fixup, > +}; > + > +static const struct regmap_config anx7688_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > +}; > + > +static int anx7688_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct anx7688 *anx7688; > + struct device *dev = &client->dev; > + int ret; > + u8 buffer[4]; > + u16 vendor, device, fwversion; > + > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > + if (!anx7688) > + return -ENOMEM; > + > +#if IS_ENABLED(CONFIG_OF) > + anx7688->bridge.of_node = client->dev.of_node; > +#endif > + > + anx7688->client = client; > + i2c_set_clientdata(client, anx7688); > + > + anx7688->regmap = > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > + > + /* Read both vendor and device id (4 bytes). */ > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > + if (ret) { > + dev_err(dev, "Failed to read chip vendor/device id\n"); > + return ret; > + } > + > + vendor = (u16)buffer[1] << 8 | buffer[0]; > + device = (u16)buffer[3] << 8 | buffer[2]; > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > + vendor, device); > + return -ENODEV; > + } > + > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > + if (ret) { > + dev_err(&client->dev, "Failed to read firmware version\n"); > + return ret; > + } > + > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > + buffer[0], buffer[1]); > + > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > + if (fwversion >= MINIMUM_FW_VERSION) { > + anx7688->filter = true; > + } else { > + /* Warn, but not fail, for backwards compatibility. */ > + dev_warn(dev, > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > + buffer[0], buffer[1]); > + } > + > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > + drm_bridge_add(&anx7688->bridge); > + > + return 0; > +} > + > +static int anx7688_i2c_remove(struct i2c_client *client) > +{ > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > + > + drm_bridge_remove(&anx7688->bridge); > + > + return 0; > +} > + > +static const struct i2c_device_id anx7688_id[] = { > + { "anx7688", 0 }, > + { /* sentinel */ } > +}; > + > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id anx7688_match_table[] = { > + { .compatible = "analogix,anx7688", }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > +#endif > + > +static struct i2c_driver anx7688_driver = { > + .driver = { > + .name = "anx7688", > + .of_match_table = of_match_ptr(anx7688_match_table), > + }, > + .probe = anx7688_i2c_probe, > + .remove = anx7688_i2c_remove, > + .id_table = anx7688_id, > +}; > + > +module_i2c_driver(anx7688_driver); > + > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-13 22:38 ` Laurent Pinchart -1 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-13 22:38 UTC (permalink / raw) To: Hsin-Yi Wang Cc: dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hi Hsin-Yi and Nicolas, Thank you for the patch. On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > that has an internal microcontroller. > > The only reason a Linux kernel driver is necessary is to reject > resolutions that require more bandwidth than what is available on > the DP side. DP bandwidth and lane count are reported by the bridge > via 2 registers on I2C. How about power, doesn't this chip have power supplies that potentially need to be controlled ? > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > drivers/gpu/drm/bridge/Kconfig | 9 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > 3 files changed, 212 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 34362976cd6f..1f3fc6bec842 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > menu "Display Interface Bridges" > depends on DRM && DRM_BRIDGE > > +config DRM_ANALOGIX_ANX7688 > + tristate "Analogix ANX7688 bridge" > + select DRM_KMS_HELPER > + select REGMAP_I2C > + ---help--- > + ANX7688 is a transmitter to support DisplayPort over USB-C for > + smartphone and tablets. > + This driver only supports the HDMI to DP component of the chip. > + > config DRM_ANALOGIX_ANX78XX > tristate "Analogix ANX78XX bridge" > select DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf5a6f8..7a1e0ec032e6 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > new file mode 100644 > index 000000000000..baaed48d6201 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > @@ -0,0 +1,202 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * ANX7688 HDMI->DP bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > +#include <linux/i2c.h> > +#include <linux/module.h> > +#include <linux/regmap.h> > +#include <drm/drm_bridge.h> > + > +/* Register addresses */ > +#define VENDOR_ID_REG 0x00 > +#define DEVICE_ID_REG 0x02 > + > +#define FW_VERSION_REG 0x80 > + > +#define DP_BANDWIDTH_REG 0x85 > +#define DP_LANE_COUNT_REG 0x86 Are these registers defined by the ANX7688 hardware, or by the firmware running on the chip (and, I assume, developed by Google) ? > + > +#define VENDOR_ID 0x1f29 > +#define DEVICE_ID 0x7688 > + > +/* First supported firmware version (0.85) */ > +#define MINIMUM_FW_VERSION 0x0085 > + > +struct anx7688 { > + struct drm_bridge bridge; > + struct i2c_client *client; > + struct regmap *regmap; > + > + bool filter; > +}; > + > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct anx7688, bridge); > +} > + > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > + u8 regs[2]; > + u8 dpbw, lanecount; > + int totalbw, requiredbw; > + int ret; > + > + if (!anx7688->filter) > + return true; > + > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > + if (ret < 0) { > + dev_err(&anx7688->client->dev, > + "Failed to read bandwidth/lane count\n"); > + return false; > + } > + dpbw = regs[0]; > + lanecount = regs[1]; > + > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > + if (dpbw > 0x19 || lanecount > 2) { > + dev_err(&anx7688->client->dev, > + "Invalid bandwidth/lane count (%02x/%d)\n", > + dpbw, lanecount); > + return false; > + } > + > + /* Compute available bandwidth (kHz) */ > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > + > + /* Required bandwidth (8 bpc, kHz) */ > + requiredbw = mode->clock * 8 * 3; > + > + dev_dbg(&anx7688->client->dev, > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > + totalbw, dpbw, lanecount, requiredbw); > + > + if (totalbw == 0) { > + dev_warn(&anx7688->client->dev, > + "Bandwidth/lane count are 0, not rejecting modes\n"); > + return true; > + } > + > + return totalbw >= requiredbw; > +} > + > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > + .mode_fixup = anx7688_bridge_mode_fixup, > +}; > + > +static const struct regmap_config anx7688_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > +}; > + > +static int anx7688_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct anx7688 *anx7688; > + struct device *dev = &client->dev; > + int ret; > + u8 buffer[4]; > + u16 vendor, device, fwversion; > + > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > + if (!anx7688) > + return -ENOMEM; > + > +#if IS_ENABLED(CONFIG_OF) > + anx7688->bridge.of_node = client->dev.of_node; > +#endif > + > + anx7688->client = client; > + i2c_set_clientdata(client, anx7688); > + > + anx7688->regmap = > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > + > + /* Read both vendor and device id (4 bytes). */ > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > + if (ret) { > + dev_err(dev, "Failed to read chip vendor/device id\n"); > + return ret; > + } > + > + vendor = (u16)buffer[1] << 8 | buffer[0]; > + device = (u16)buffer[3] << 8 | buffer[2]; > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > + vendor, device); > + return -ENODEV; > + } > + > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > + if (ret) { > + dev_err(&client->dev, "Failed to read firmware version\n"); > + return ret; > + } > + > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > + buffer[0], buffer[1]); > + > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > + if (fwversion >= MINIMUM_FW_VERSION) { > + anx7688->filter = true; > + } else { > + /* Warn, but not fail, for backwards compatibility. */ > + dev_warn(dev, > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > + buffer[0], buffer[1]); > + } > + > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > + drm_bridge_add(&anx7688->bridge); > + > + return 0; > +} > + > +static int anx7688_i2c_remove(struct i2c_client *client) > +{ > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > + > + drm_bridge_remove(&anx7688->bridge); > + > + return 0; > +} > + > +static const struct i2c_device_id anx7688_id[] = { > + { "anx7688", 0 }, > + { /* sentinel */ } > +}; > + > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id anx7688_match_table[] = { > + { .compatible = "analogix,anx7688", }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > +#endif > + > +static struct i2c_driver anx7688_driver = { > + .driver = { > + .name = "anx7688", > + .of_match_table = of_match_ptr(anx7688_match_table), > + }, > + .probe = anx7688_i2c_probe, > + .remove = anx7688_i2c_remove, > + .id_table = anx7688_id, > +}; > + > +module_i2c_driver(anx7688_driver); > + > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-13 22:38 ` Laurent Pinchart 0 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-13 22:38 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Rob Herring, Matthias Brugger, Enric Balletbo i Serra, Russell King Hi Hsin-Yi and Nicolas, Thank you for the patch. On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > that has an internal microcontroller. > > The only reason a Linux kernel driver is necessary is to reject > resolutions that require more bandwidth than what is available on > the DP side. DP bandwidth and lane count are reported by the bridge > via 2 registers on I2C. How about power, doesn't this chip have power supplies that potentially need to be controlled ? > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > drivers/gpu/drm/bridge/Kconfig | 9 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > 3 files changed, 212 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 34362976cd6f..1f3fc6bec842 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > menu "Display Interface Bridges" > depends on DRM && DRM_BRIDGE > > +config DRM_ANALOGIX_ANX7688 > + tristate "Analogix ANX7688 bridge" > + select DRM_KMS_HELPER > + select REGMAP_I2C > + ---help--- > + ANX7688 is a transmitter to support DisplayPort over USB-C for > + smartphone and tablets. > + This driver only supports the HDMI to DP component of the chip. > + > config DRM_ANALOGIX_ANX78XX > tristate "Analogix ANX78XX bridge" > select DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 4934fcf5a6f8..7a1e0ec032e6 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,4 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > new file mode 100644 > index 000000000000..baaed48d6201 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > @@ -0,0 +1,202 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * ANX7688 HDMI->DP bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > +#include <linux/i2c.h> > +#include <linux/module.h> > +#include <linux/regmap.h> > +#include <drm/drm_bridge.h> > + > +/* Register addresses */ > +#define VENDOR_ID_REG 0x00 > +#define DEVICE_ID_REG 0x02 > + > +#define FW_VERSION_REG 0x80 > + > +#define DP_BANDWIDTH_REG 0x85 > +#define DP_LANE_COUNT_REG 0x86 Are these registers defined by the ANX7688 hardware, or by the firmware running on the chip (and, I assume, developed by Google) ? > + > +#define VENDOR_ID 0x1f29 > +#define DEVICE_ID 0x7688 > + > +/* First supported firmware version (0.85) */ > +#define MINIMUM_FW_VERSION 0x0085 > + > +struct anx7688 { > + struct drm_bridge bridge; > + struct i2c_client *client; > + struct regmap *regmap; > + > + bool filter; > +}; > + > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct anx7688, bridge); > +} > + > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > + u8 regs[2]; > + u8 dpbw, lanecount; > + int totalbw, requiredbw; > + int ret; > + > + if (!anx7688->filter) > + return true; > + > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > + if (ret < 0) { > + dev_err(&anx7688->client->dev, > + "Failed to read bandwidth/lane count\n"); > + return false; > + } > + dpbw = regs[0]; > + lanecount = regs[1]; > + > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > + if (dpbw > 0x19 || lanecount > 2) { > + dev_err(&anx7688->client->dev, > + "Invalid bandwidth/lane count (%02x/%d)\n", > + dpbw, lanecount); > + return false; > + } > + > + /* Compute available bandwidth (kHz) */ > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > + > + /* Required bandwidth (8 bpc, kHz) */ > + requiredbw = mode->clock * 8 * 3; > + > + dev_dbg(&anx7688->client->dev, > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > + totalbw, dpbw, lanecount, requiredbw); > + > + if (totalbw == 0) { > + dev_warn(&anx7688->client->dev, > + "Bandwidth/lane count are 0, not rejecting modes\n"); > + return true; > + } > + > + return totalbw >= requiredbw; > +} > + > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > + .mode_fixup = anx7688_bridge_mode_fixup, > +}; > + > +static const struct regmap_config anx7688_regmap_config = { > + .reg_bits = 8, > + .val_bits = 8, > +}; > + > +static int anx7688_i2c_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct anx7688 *anx7688; > + struct device *dev = &client->dev; > + int ret; > + u8 buffer[4]; > + u16 vendor, device, fwversion; > + > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > + if (!anx7688) > + return -ENOMEM; > + > +#if IS_ENABLED(CONFIG_OF) > + anx7688->bridge.of_node = client->dev.of_node; > +#endif > + > + anx7688->client = client; > + i2c_set_clientdata(client, anx7688); > + > + anx7688->regmap = > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > + > + /* Read both vendor and device id (4 bytes). */ > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > + if (ret) { > + dev_err(dev, "Failed to read chip vendor/device id\n"); > + return ret; > + } > + > + vendor = (u16)buffer[1] << 8 | buffer[0]; > + device = (u16)buffer[3] << 8 | buffer[2]; > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > + vendor, device); > + return -ENODEV; > + } > + > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > + if (ret) { > + dev_err(&client->dev, "Failed to read firmware version\n"); > + return ret; > + } > + > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > + buffer[0], buffer[1]); > + > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > + if (fwversion >= MINIMUM_FW_VERSION) { > + anx7688->filter = true; > + } else { > + /* Warn, but not fail, for backwards compatibility. */ > + dev_warn(dev, > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > + buffer[0], buffer[1]); > + } > + > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > + drm_bridge_add(&anx7688->bridge); > + > + return 0; > +} > + > +static int anx7688_i2c_remove(struct i2c_client *client) > +{ > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > + > + drm_bridge_remove(&anx7688->bridge); > + > + return 0; > +} > + > +static const struct i2c_device_id anx7688_id[] = { > + { "anx7688", 0 }, > + { /* sentinel */ } > +}; > + > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > + > +#if IS_ENABLED(CONFIG_OF) > +static const struct of_device_id anx7688_match_table[] = { > + { .compatible = "analogix,anx7688", }, > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > +#endif > + > +static struct i2c_driver anx7688_driver = { > + .driver = { > + .name = "anx7688", > + .of_match_table = of_match_ptr(anx7688_match_table), > + }, > + .probe = anx7688_i2c_probe, > + .remove = anx7688_i2c_remove, > + .id_table = anx7688_id, > +}; > + > +module_i2c_driver(anx7688_driver); > + > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-13 22:38 ` Laurent Pinchart @ 2019-12-16 8:45 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 8:45 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi and Nicolas, > > Thank you for the patch. > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > that has an internal microcontroller. > > > > The only reason a Linux kernel driver is necessary is to reject > > resolutions that require more bandwidth than what is available on > > the DP side. DP bandwidth and lane count are reported by the bridge > > via 2 registers on I2C. > > How about power, doesn't this chip have power supplies that potentially > need to be controlled ? > Ideally we should add power supplies as well, but the power is supplied by ec in mt8173 oak board. And we only have this board can test this driver. If we add power supplies in driver we can't test it. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > drivers/gpu/drm/bridge/Kconfig | 9 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > 3 files changed, 212 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 34362976cd6f..1f3fc6bec842 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > menu "Display Interface Bridges" > > depends on DRM && DRM_BRIDGE > > > > +config DRM_ANALOGIX_ANX7688 > > + tristate "Analogix ANX7688 bridge" > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + ---help--- > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > + smartphone and tablets. > > + This driver only supports the HDMI to DP component of the chip. > > + > > config DRM_ANALOGIX_ANX78XX > > tristate "Analogix ANX78XX bridge" > > select DRM_KMS_HELPER > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -1,4 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > new file mode 100644 > > index 000000000000..baaed48d6201 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > @@ -0,0 +1,202 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * ANX7688 HDMI->DP bridge driver > > + * > > + * Copyright 2016 Google LLC > > + */ > > + > > +#include <linux/i2c.h> > > +#include <linux/module.h> > > +#include <linux/regmap.h> > > +#include <drm/drm_bridge.h> > > + > > +/* Register addresses */ > > +#define VENDOR_ID_REG 0x00 > > +#define DEVICE_ID_REG 0x02 > > + > > +#define FW_VERSION_REG 0x80 > > + > > +#define DP_BANDWIDTH_REG 0x85 > > +#define DP_LANE_COUNT_REG 0x86 > > Are these registers defined by the ANX7688 hardware, or by the firmware > running on the chip (and, I assume, developed by Google) ? > By firmware developed by ANX provided to Google. > > + > > +#define VENDOR_ID 0x1f29 > > +#define DEVICE_ID 0x7688 > > + > > +/* First supported firmware version (0.85) */ > > +#define MINIMUM_FW_VERSION 0x0085 > > + > > +struct anx7688 { > > + struct drm_bridge bridge; > > + struct i2c_client *client; > > + struct regmap *regmap; > > + > > + bool filter; > > +}; > > + > > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > > +{ > > + return container_of(bridge, struct anx7688, bridge); > > +} > > + > > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > > + u8 regs[2]; > > + u8 dpbw, lanecount; > > + int totalbw, requiredbw; > > + int ret; > > + > > + if (!anx7688->filter) > > + return true; > > + > > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > > + if (ret < 0) { > > + dev_err(&anx7688->client->dev, > > + "Failed to read bandwidth/lane count\n"); > > + return false; > > + } > > + dpbw = regs[0]; > > + lanecount = regs[1]; > > + > > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > > + if (dpbw > 0x19 || lanecount > 2) { > > + dev_err(&anx7688->client->dev, > > + "Invalid bandwidth/lane count (%02x/%d)\n", > > + dpbw, lanecount); > > + return false; > > + } > > + > > + /* Compute available bandwidth (kHz) */ > > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > > + > > + /* Required bandwidth (8 bpc, kHz) */ > > + requiredbw = mode->clock * 8 * 3; > > + > > + dev_dbg(&anx7688->client->dev, > > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > > + totalbw, dpbw, lanecount, requiredbw); > > + > > + if (totalbw == 0) { > > + dev_warn(&anx7688->client->dev, > > + "Bandwidth/lane count are 0, not rejecting modes\n"); > > + return true; > > + } > > + > > + return totalbw >= requiredbw; > > +} > > + > > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > > + .mode_fixup = anx7688_bridge_mode_fixup, > > +}; > > + > > +static const struct regmap_config anx7688_regmap_config = { > > + .reg_bits = 8, > > + .val_bits = 8, > > +}; > > + > > +static int anx7688_i2c_probe(struct i2c_client *client, > > + const struct i2c_device_id *id) > > +{ > > + struct anx7688 *anx7688; > > + struct device *dev = &client->dev; > > + int ret; > > + u8 buffer[4]; > > + u16 vendor, device, fwversion; > > + > > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > > + if (!anx7688) > > + return -ENOMEM; > > + > > +#if IS_ENABLED(CONFIG_OF) > > + anx7688->bridge.of_node = client->dev.of_node; > > +#endif > > + > > + anx7688->client = client; > > + i2c_set_clientdata(client, anx7688); > > + > > + anx7688->regmap = > > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > > + > > + /* Read both vendor and device id (4 bytes). */ > > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > > + if (ret) { > > + dev_err(dev, "Failed to read chip vendor/device id\n"); > > + return ret; > > + } > > + > > + vendor = (u16)buffer[1] << 8 | buffer[0]; > > + device = (u16)buffer[3] << 8 | buffer[2]; > > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > > + vendor, device); > > + return -ENODEV; > > + } > > + > > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > > + if (ret) { > > + dev_err(&client->dev, "Failed to read firmware version\n"); > > + return ret; > > + } > > + > > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > > + buffer[0], buffer[1]); > > + > > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > > + if (fwversion >= MINIMUM_FW_VERSION) { > > + anx7688->filter = true; > > + } else { > > + /* Warn, but not fail, for backwards compatibility. */ > > + dev_warn(dev, > > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > > + buffer[0], buffer[1]); > > + } > > + > > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > > + drm_bridge_add(&anx7688->bridge); > > + > > + return 0; > > +} > > + > > +static int anx7688_i2c_remove(struct i2c_client *client) > > +{ > > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > > + > > + drm_bridge_remove(&anx7688->bridge); > > + > > + return 0; > > +} > > + > > +static const struct i2c_device_id anx7688_id[] = { > > + { "anx7688", 0 }, > > + { /* sentinel */ } > > +}; > > + > > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > > + > > +#if IS_ENABLED(CONFIG_OF) > > +static const struct of_device_id anx7688_match_table[] = { > > + { .compatible = "analogix,anx7688", }, > > + { /* sentinel */ }, > > +}; > > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > > +#endif > > + > > +static struct i2c_driver anx7688_driver = { > > + .driver = { > > + .name = "anx7688", > > + .of_match_table = of_match_ptr(anx7688_match_table), > > + }, > > + .probe = anx7688_i2c_probe, > > + .remove = anx7688_i2c_remove, > > + .id_table = anx7688_id, > > +}; > > + > > +module_i2c_driver(anx7688_driver); > > + > > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > > +MODULE_LICENSE("GPL v2"); > > -- > Regards, > > Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-16 8:45 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 8:45 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Matthias Brugger, Enric Balletbo i Serra, Russell King On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi and Nicolas, > > Thank you for the patch. > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > that has an internal microcontroller. > > > > The only reason a Linux kernel driver is necessary is to reject > > resolutions that require more bandwidth than what is available on > > the DP side. DP bandwidth and lane count are reported by the bridge > > via 2 registers on I2C. > > How about power, doesn't this chip have power supplies that potentially > need to be controlled ? > Ideally we should add power supplies as well, but the power is supplied by ec in mt8173 oak board. And we only have this board can test this driver. If we add power supplies in driver we can't test it. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > drivers/gpu/drm/bridge/Kconfig | 9 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > 3 files changed, 212 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 34362976cd6f..1f3fc6bec842 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > menu "Display Interface Bridges" > > depends on DRM && DRM_BRIDGE > > > > +config DRM_ANALOGIX_ANX7688 > > + tristate "Analogix ANX7688 bridge" > > + select DRM_KMS_HELPER > > + select REGMAP_I2C > > + ---help--- > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > + smartphone and tablets. > > + This driver only supports the HDMI to DP component of the chip. > > + > > config DRM_ANALOGIX_ANX78XX > > tristate "Analogix ANX78XX bridge" > > select DRM_KMS_HELPER > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -1,4 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > new file mode 100644 > > index 000000000000..baaed48d6201 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > @@ -0,0 +1,202 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * ANX7688 HDMI->DP bridge driver > > + * > > + * Copyright 2016 Google LLC > > + */ > > + > > +#include <linux/i2c.h> > > +#include <linux/module.h> > > +#include <linux/regmap.h> > > +#include <drm/drm_bridge.h> > > + > > +/* Register addresses */ > > +#define VENDOR_ID_REG 0x00 > > +#define DEVICE_ID_REG 0x02 > > + > > +#define FW_VERSION_REG 0x80 > > + > > +#define DP_BANDWIDTH_REG 0x85 > > +#define DP_LANE_COUNT_REG 0x86 > > Are these registers defined by the ANX7688 hardware, or by the firmware > running on the chip (and, I assume, developed by Google) ? > By firmware developed by ANX provided to Google. > > + > > +#define VENDOR_ID 0x1f29 > > +#define DEVICE_ID 0x7688 > > + > > +/* First supported firmware version (0.85) */ > > +#define MINIMUM_FW_VERSION 0x0085 > > + > > +struct anx7688 { > > + struct drm_bridge bridge; > > + struct i2c_client *client; > > + struct regmap *regmap; > > + > > + bool filter; > > +}; > > + > > +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) > > +{ > > + return container_of(bridge, struct anx7688, bridge); > > +} > > + > > +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); > > + u8 regs[2]; > > + u8 dpbw, lanecount; > > + int totalbw, requiredbw; > > + int ret; > > + > > + if (!anx7688->filter) > > + return true; > > + > > + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ > > + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); > > + if (ret < 0) { > > + dev_err(&anx7688->client->dev, > > + "Failed to read bandwidth/lane count\n"); > > + return false; > > + } > > + dpbw = regs[0]; > > + lanecount = regs[1]; > > + > > + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ > > + if (dpbw > 0x19 || lanecount > 2) { > > + dev_err(&anx7688->client->dev, > > + "Invalid bandwidth/lane count (%02x/%d)\n", > > + dpbw, lanecount); > > + return false; > > + } > > + > > + /* Compute available bandwidth (kHz) */ > > + totalbw = dpbw * lanecount * 270000 * 8 / 10; > > + > > + /* Required bandwidth (8 bpc, kHz) */ > > + requiredbw = mode->clock * 8 * 3; > > + > > + dev_dbg(&anx7688->client->dev, > > + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", > > + totalbw, dpbw, lanecount, requiredbw); > > + > > + if (totalbw == 0) { > > + dev_warn(&anx7688->client->dev, > > + "Bandwidth/lane count are 0, not rejecting modes\n"); > > + return true; > > + } > > + > > + return totalbw >= requiredbw; > > +} > > + > > +static const struct drm_bridge_funcs anx7688_bridge_funcs = { > > + .mode_fixup = anx7688_bridge_mode_fixup, > > +}; > > + > > +static const struct regmap_config anx7688_regmap_config = { > > + .reg_bits = 8, > > + .val_bits = 8, > > +}; > > + > > +static int anx7688_i2c_probe(struct i2c_client *client, > > + const struct i2c_device_id *id) > > +{ > > + struct anx7688 *anx7688; > > + struct device *dev = &client->dev; > > + int ret; > > + u8 buffer[4]; > > + u16 vendor, device, fwversion; > > + > > + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); > > + if (!anx7688) > > + return -ENOMEM; > > + > > +#if IS_ENABLED(CONFIG_OF) > > + anx7688->bridge.of_node = client->dev.of_node; > > +#endif > > + > > + anx7688->client = client; > > + i2c_set_clientdata(client, anx7688); > > + > > + anx7688->regmap = > > + devm_regmap_init_i2c(client, &anx7688_regmap_config); > > + > > + /* Read both vendor and device id (4 bytes). */ > > + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); > > + if (ret) { > > + dev_err(dev, "Failed to read chip vendor/device id\n"); > > + return ret; > > + } > > + > > + vendor = (u16)buffer[1] << 8 | buffer[0]; > > + device = (u16)buffer[3] << 8 | buffer[2]; > > + if (vendor != VENDOR_ID || device != DEVICE_ID) { > > + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", > > + vendor, device); > > + return -ENODEV; > > + } > > + > > + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); > > + if (ret) { > > + dev_err(&client->dev, "Failed to read firmware version\n"); > > + return ret; > > + } > > + > > + fwversion = (u16)buffer[0] << 8 | buffer[1]; > > + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", > > + buffer[0], buffer[1]); > > + > > + /* FW version >= 0.85 supports bandwidth/lane count registers */ > > + if (fwversion >= MINIMUM_FW_VERSION) { > > + anx7688->filter = true; > > + } else { > > + /* Warn, but not fail, for backwards compatibility. */ > > + dev_warn(dev, > > + "Old ANX7688 FW version (%02x.%02x), not filtering\n", > > + buffer[0], buffer[1]); > > + } > > + > > + anx7688->bridge.funcs = &anx7688_bridge_funcs; > > + drm_bridge_add(&anx7688->bridge); > > + > > + return 0; > > +} > > + > > +static int anx7688_i2c_remove(struct i2c_client *client) > > +{ > > + struct anx7688 *anx7688 = i2c_get_clientdata(client); > > + > > + drm_bridge_remove(&anx7688->bridge); > > + > > + return 0; > > +} > > + > > +static const struct i2c_device_id anx7688_id[] = { > > + { "anx7688", 0 }, > > + { /* sentinel */ } > > +}; > > + > > +MODULE_DEVICE_TABLE(i2c, anx7688_id); > > + > > +#if IS_ENABLED(CONFIG_OF) > > +static const struct of_device_id anx7688_match_table[] = { > > + { .compatible = "analogix,anx7688", }, > > + { /* sentinel */ }, > > +}; > > +MODULE_DEVICE_TABLE(of, anx7688_match_table); > > +#endif > > + > > +static struct i2c_driver anx7688_driver = { > > + .driver = { > > + .name = "anx7688", > > + .of_match_table = of_match_ptr(anx7688_match_table), > > + }, > > + .probe = anx7688_i2c_probe, > > + .remove = anx7688_i2c_remove, > > + .id_table = anx7688_id, > > +}; > > + > > +module_i2c_driver(anx7688_driver); > > + > > +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); > > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > > +MODULE_LICENSE("GPL v2"); > > -- > Regards, > > Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-16 8:45 ` Hsin-Yi Wang @ 2019-12-16 10:19 ` Nicolas Boichat -1 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-16 10:19 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Laurent Pinchart, dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > > > Hi Hsin-Yi and Nicolas, > > > > Thank you for the patch. > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > that has an internal microcontroller. > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > resolutions that require more bandwidth than what is available on > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > via 2 registers on I2C. > > > > How about power, doesn't this chip have power supplies that potentially > > need to be controlled ? > > > Ideally we should add power supplies as well, but the power is > supplied by ec in mt8173 oak board. And we only have this board can > test this driver. If we add power supplies in driver we can't test it. To clarify a bit more, this is because this chip is actually a TCPC+mux+HDMI=>DP converter (https://www.analogix.com/en/products/convertersbridges/anx7688). In Chromebook architecture, TCPC+mux is controlled by the EC (including power and other control pins), and the only reason we need a driver for the HDMI=>DP converter is to get the number of lanes on the DP side and filter out resolutions. Also, the converter is on a different I2C address and it could almost be considered as a separate device. (of course we could write a kernel driver for the TCPC+mux but we'll leave that to others if there's ever a board that is built with the TCPC part connected to the AP) > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > 3 files changed, 212 insertions(+) > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > index 34362976cd6f..1f3fc6bec842 100644 > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > menu "Display Interface Bridges" > > > depends on DRM && DRM_BRIDGE > > > > > > +config DRM_ANALOGIX_ANX7688 > > > + tristate "Analogix ANX7688 bridge" > > > + select DRM_KMS_HELPER > > > + select REGMAP_I2C > > > + ---help--- > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > + smartphone and tablets. > > > + This driver only supports the HDMI to DP component of the chip. > > > + > > > config DRM_ANALOGIX_ANX78XX > > > tristate "Analogix ANX78XX bridge" > > > select DRM_KMS_HELPER > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > --- a/drivers/gpu/drm/bridge/Makefile > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > @@ -1,4 +1,5 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > new file mode 100644 > > > index 000000000000..baaed48d6201 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > @@ -0,0 +1,202 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * ANX7688 HDMI->DP bridge driver > > > + * > > > + * Copyright 2016 Google LLC > > > + */ > > > + > > > +#include <linux/i2c.h> > > > +#include <linux/module.h> > > > +#include <linux/regmap.h> > > > +#include <drm/drm_bridge.h> > > > + > > > +/* Register addresses */ > > > +#define VENDOR_ID_REG 0x00 > > > +#define DEVICE_ID_REG 0x02 > > > + > > > +#define FW_VERSION_REG 0x80 > > > + > > > +#define DP_BANDWIDTH_REG 0x85 > > > +#define DP_LANE_COUNT_REG 0x86 > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > running on the chip (and, I assume, developed by Google) ? > > > By firmware developed by ANX provided to Google. We asked for these registers to be added to ANX FW, and this is the FW that is used by all elm/hana Chromebooks (I have no idea about other ANX customers...). We have facilities to update the ANX FW from coreboot/depthcharge on Chromebooks, but that does not really matter: the factory FW of all MP Chromebooks does provide these registers. Thanks. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-16 10:19 ` Nicolas Boichat 0 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-16 10:19 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > > > Hi Hsin-Yi and Nicolas, > > > > Thank you for the patch. > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > that has an internal microcontroller. > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > resolutions that require more bandwidth than what is available on > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > via 2 registers on I2C. > > > > How about power, doesn't this chip have power supplies that potentially > > need to be controlled ? > > > Ideally we should add power supplies as well, but the power is > supplied by ec in mt8173 oak board. And we only have this board can > test this driver. If we add power supplies in driver we can't test it. To clarify a bit more, this is because this chip is actually a TCPC+mux+HDMI=>DP converter (https://www.analogix.com/en/products/convertersbridges/anx7688). In Chromebook architecture, TCPC+mux is controlled by the EC (including power and other control pins), and the only reason we need a driver for the HDMI=>DP converter is to get the number of lanes on the DP side and filter out resolutions. Also, the converter is on a different I2C address and it could almost be considered as a separate device. (of course we could write a kernel driver for the TCPC+mux but we'll leave that to others if there's ever a board that is built with the TCPC part connected to the AP) > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > 3 files changed, 212 insertions(+) > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > index 34362976cd6f..1f3fc6bec842 100644 > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > menu "Display Interface Bridges" > > > depends on DRM && DRM_BRIDGE > > > > > > +config DRM_ANALOGIX_ANX7688 > > > + tristate "Analogix ANX7688 bridge" > > > + select DRM_KMS_HELPER > > > + select REGMAP_I2C > > > + ---help--- > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > + smartphone and tablets. > > > + This driver only supports the HDMI to DP component of the chip. > > > + > > > config DRM_ANALOGIX_ANX78XX > > > tristate "Analogix ANX78XX bridge" > > > select DRM_KMS_HELPER > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > --- a/drivers/gpu/drm/bridge/Makefile > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > @@ -1,4 +1,5 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > new file mode 100644 > > > index 000000000000..baaed48d6201 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > @@ -0,0 +1,202 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * ANX7688 HDMI->DP bridge driver > > > + * > > > + * Copyright 2016 Google LLC > > > + */ > > > + > > > +#include <linux/i2c.h> > > > +#include <linux/module.h> > > > +#include <linux/regmap.h> > > > +#include <drm/drm_bridge.h> > > > + > > > +/* Register addresses */ > > > +#define VENDOR_ID_REG 0x00 > > > +#define DEVICE_ID_REG 0x02 > > > + > > > +#define FW_VERSION_REG 0x80 > > > + > > > +#define DP_BANDWIDTH_REG 0x85 > > > +#define DP_LANE_COUNT_REG 0x86 > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > running on the chip (and, I assume, developed by Google) ? > > > By firmware developed by ANX provided to Google. We asked for these registers to be added to ANX FW, and this is the FW that is used by all elm/hana Chromebooks (I have no idea about other ANX customers...). We have facilities to update the ANX FW from coreboot/depthcharge on Chromebooks, but that does not really matter: the factory FW of all MP Chromebooks does provide these registers. Thanks. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-16 10:19 ` Nicolas Boichat @ 2019-12-16 16:39 ` Laurent Pinchart -1 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-16 16:39 UTC (permalink / raw) To: Nicolas Boichat Cc: Hsin-Yi Wang, dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hello Nicolas and Hsin-Yi, On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > that has an internal microcontroller. > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > resolutions that require more bandwidth than what is available on > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > via 2 registers on I2C. > > > > > > How about power, doesn't this chip have power supplies that potentially > > > need to be controlled ? > > > > > Ideally we should add power supplies as well, but the power is > > supplied by ec in mt8173 oak board. And we only have this board can > > test this driver. If we add power supplies in driver we can't test it. > > To clarify a bit more, this is because this chip is actually a > TCPC+mux+HDMI=>DP converter > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > Chromebook architecture, TCPC+mux is controlled by the EC (including > power and other control pins), and the only reason we need a driver > for the HDMI=>DP converter is to get the number of lanes on the DP > side and filter out resolutions. Also, the converter is on a different > I2C address and it could almost be considered as a separate device. > > (of course we could write a kernel driver for the TCPC+mux but we'll > leave that to others if there's ever a board that is built with the > TCPC part connected to the AP) Is the mux the one that is handled through a gpio-mux driver in this series, or a different mux ? It would really, really help if you could show a block diagram of the related hardware (including the EC), as this is quite confusing. With every e-mail exchanged there's a bit more information that change my understanding of the issue, I can't really provide guidance without a full overview. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > 3 files changed, 212 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > menu "Display Interface Bridges" > > > > depends on DRM && DRM_BRIDGE > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > + tristate "Analogix ANX7688 bridge" > > > > + select DRM_KMS_HELPER > > > > + select REGMAP_I2C > > > > + ---help--- > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > + smartphone and tablets. > > > > + This driver only supports the HDMI to DP component of the chip. > > > > + > > > > config DRM_ANALOGIX_ANX78XX > > > > tristate "Analogix ANX78XX bridge" > > > > select DRM_KMS_HELPER > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > @@ -1,4 +1,5 @@ > > > > # SPDX-License-Identifier: GPL-2.0 > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > new file mode 100644 > > > > index 000000000000..baaed48d6201 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > @@ -0,0 +1,202 @@ > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > +/* > > > > + * ANX7688 HDMI->DP bridge driver > > > > + * > > > > + * Copyright 2016 Google LLC > > > > + */ > > > > + > > > > +#include <linux/i2c.h> > > > > +#include <linux/module.h> > > > > +#include <linux/regmap.h> > > > > +#include <drm/drm_bridge.h> > > > > + > > > > +/* Register addresses */ > > > > +#define VENDOR_ID_REG 0x00 > > > > +#define DEVICE_ID_REG 0x02 > > > > + > > > > +#define FW_VERSION_REG 0x80 > > > > + > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > running on the chip (and, I assume, developed by Google) ? > > > > > By firmware developed by ANX provided to Google. > > We asked for these registers to be added to ANX FW, and this is the FW > that is used by all elm/hana Chromebooks (I have no idea about other > ANX customers...). We have facilities to update the ANX FW from > coreboot/depthcharge on Chromebooks, but that does not really matter: > the factory FW of all MP Chromebooks does provide these registers. So the driver is specific to Chromebooks, it doesn't support all ANX7688. Sweet :-( -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-16 16:39 ` Laurent Pinchart 0 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-16 16:39 UTC (permalink / raw) To: Nicolas Boichat Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Hsin-Yi Wang, Enric Balletbo i Serra, Russell King Hello Nicolas and Hsin-Yi, On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > that has an internal microcontroller. > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > resolutions that require more bandwidth than what is available on > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > via 2 registers on I2C. > > > > > > How about power, doesn't this chip have power supplies that potentially > > > need to be controlled ? > > > > > Ideally we should add power supplies as well, but the power is > > supplied by ec in mt8173 oak board. And we only have this board can > > test this driver. If we add power supplies in driver we can't test it. > > To clarify a bit more, this is because this chip is actually a > TCPC+mux+HDMI=>DP converter > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > Chromebook architecture, TCPC+mux is controlled by the EC (including > power and other control pins), and the only reason we need a driver > for the HDMI=>DP converter is to get the number of lanes on the DP > side and filter out resolutions. Also, the converter is on a different > I2C address and it could almost be considered as a separate device. > > (of course we could write a kernel driver for the TCPC+mux but we'll > leave that to others if there's ever a board that is built with the > TCPC part connected to the AP) Is the mux the one that is handled through a gpio-mux driver in this series, or a different mux ? It would really, really help if you could show a block diagram of the related hardware (including the EC), as this is quite confusing. With every e-mail exchanged there's a bit more information that change my understanding of the issue, I can't really provide guidance without a full overview. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > 3 files changed, 212 insertions(+) > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > menu "Display Interface Bridges" > > > > depends on DRM && DRM_BRIDGE > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > + tristate "Analogix ANX7688 bridge" > > > > + select DRM_KMS_HELPER > > > > + select REGMAP_I2C > > > > + ---help--- > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > + smartphone and tablets. > > > > + This driver only supports the HDMI to DP component of the chip. > > > > + > > > > config DRM_ANALOGIX_ANX78XX > > > > tristate "Analogix ANX78XX bridge" > > > > select DRM_KMS_HELPER > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > @@ -1,4 +1,5 @@ > > > > # SPDX-License-Identifier: GPL-2.0 > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > new file mode 100644 > > > > index 000000000000..baaed48d6201 > > > > --- /dev/null > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > @@ -0,0 +1,202 @@ > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > +/* > > > > + * ANX7688 HDMI->DP bridge driver > > > > + * > > > > + * Copyright 2016 Google LLC > > > > + */ > > > > + > > > > +#include <linux/i2c.h> > > > > +#include <linux/module.h> > > > > +#include <linux/regmap.h> > > > > +#include <drm/drm_bridge.h> > > > > + > > > > +/* Register addresses */ > > > > +#define VENDOR_ID_REG 0x00 > > > > +#define DEVICE_ID_REG 0x02 > > > > + > > > > +#define FW_VERSION_REG 0x80 > > > > + > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > running on the chip (and, I assume, developed by Google) ? > > > > > By firmware developed by ANX provided to Google. > > We asked for these registers to be added to ANX FW, and this is the FW > that is used by all elm/hana Chromebooks (I have no idea about other > ANX customers...). We have facilities to update the ANX FW from > coreboot/depthcharge on Chromebooks, but that does not really matter: > the factory FW of all MP Chromebooks does provide these registers. So the driver is specific to Chromebooks, it doesn't support all ANX7688. Sweet :-( -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-16 16:39 ` Laurent Pinchart (?) @ 2019-12-17 0:20 ` Nicolas Boichat 2019-12-17 0:40 ` Nicolas Boichat -1 siblings, 1 reply; 51+ messages in thread From: Nicolas Boichat @ 2019-12-17 0:20 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Hsin-Yi Wang, Enric Balletbo i Serra, Russell King [-- Attachment #1.1: Type: text/plain, Size: 7536 bytes --] Hi Laurent, On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart < laurent.pinchart@ideasonboard.com> wrote: > > Hello Nicolas and Hsin-Yi, > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > that has an internal microcontroller. > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > resolutions that require more bandwidth than what is available on > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > via 2 registers on I2C. > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > need to be controlled ? > > > > > > > Ideally we should add power supplies as well, but the power is > > > supplied by ec in mt8173 oak board. And we only have this board can > > > test this driver. If we add power supplies in driver we can't test it. > > > > To clarify a bit more, this is because this chip is actually a > > TCPC+mux+HDMI=>DP converter > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > power and other control pins), and the only reason we need a driver > > for the HDMI=>DP converter is to get the number of lanes on the DP > > side and filter out resolutions. Also, the converter is on a different > > I2C address and it could almost be considered as a separate device. > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > leave that to others if there's ever a board that is built with the > > TCPC part connected to the AP) > > Is the mux the one that is handled through a gpio-mux driver in this > series, or a different mux ? It's a different mux: it's the usual USB-C mux that takes in USB 3.0 and DP (internally converted from HDMI), and decides which 2 lanes to use for each, and flip if necessary. This is all controlled by the EC (like on most other Chromebook), so this is transparent to the kernel, at least on Chromebooks. > It would really, really help if you could > show a block diagram of the related hardware (including the EC), as this > is quite confusing. With every e-mail exchanged there's a bit more > information that change my understanding of the issue, I can't really > provide guidance without a full overview. https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the display part of the problem. You can just add a USB3 connection to the above (there's also I2C interface to the EC of course to control the TCPC/mux aspect of it, but that's on different I2C addresses). +-----------+ +---------+ +------+ /--> | HDMI | | MT8173 | HDMI | -->| --/ | Connector | | HDMI | ------> |--/ | +-----------+ | Encoder | | ->| --\ +-----------+ +-----------+ +---------+ +------+ \--> | ANX7688 | ---> | USB-C | | Bridge | | Connector | USB3--> | + mux | | | +-----------+ +-----------+ ^ The ANX7688 brige could _almost_ work driverless (and it does already), the _only_ thing that the driver is doing is filtering out impossible resolution based on DP (over USB-C) number of lanes and bandwidth. > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > --- > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > 3 files changed, 212 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > menu "Display Interface Bridges" > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > + tristate "Analogix ANX7688 bridge" > > > > > + select DRM_KMS_HELPER > > > > > + select REGMAP_I2C > > > > > + ---help--- > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > + smartphone and tablets. > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > + > > > > > config DRM_ANALOGIX_ANX78XX > > > > > tristate "Analogix ANX78XX bridge" > > > > > select DRM_KMS_HELPER > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > @@ -1,4 +1,5 @@ > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > new file mode 100644 > > > > > index 000000000000..baaed48d6201 > > > > > --- /dev/null > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > @@ -0,0 +1,202 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > +/* > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > + * > > > > > + * Copyright 2016 Google LLC > > > > > + */ > > > > > + > > > > > +#include <linux/i2c.h> > > > > > +#include <linux/module.h> > > > > > +#include <linux/regmap.h> > > > > > +#include <drm/drm_bridge.h> > > > > > + > > > > > +/* Register addresses */ > > > > > +#define VENDOR_ID_REG 0x00 > > > > > +#define DEVICE_ID_REG 0x02 > > > > > + > > > > > +#define FW_VERSION_REG 0x80 > > > > > + > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > By firmware developed by ANX provided to Google. > > > > We asked for these registers to be added to ANX FW, and this is the FW > > that is used by all elm/hana Chromebooks (I have no idea about other > > ANX customers...). We have facilities to update the ANX FW from > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > the factory FW of all MP Chromebooks does provide these registers. > > So the driver is specific to Chromebooks, it doesn't support all > ANX7688. Sweet :-( FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? Also, this driver is only required to implement the mode filtering, which, possibly, is only supported by the Google version of the FW (I have no idea what other customers ANX has for this part). > -- > Regards, > > Laurent Pinchart [-- Attachment #1.2: Type: text/html, Size: 10276 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-17 0:20 ` Nicolas Boichat @ 2019-12-17 0:40 ` Nicolas Boichat 0 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-17 0:40 UTC (permalink / raw) To: Laurent Pinchart Cc: Hsin-Yi Wang, dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King (Brilliant, I managed to accidentally send the email below, and send it as HTML, sorry about that... ASCII art in gmail is hard ,-( Take 2:) Hi Laurent, > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > > > Hello Nicolas and Hsin-Yi, > > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > that has an internal microcontroller. > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > resolutions that require more bandwidth than what is available on > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > via 2 registers on I2C. > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > need to be controlled ? > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > To clarify a bit more, this is because this chip is actually a > > > TCPC+mux+HDMI=>DP converter > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > power and other control pins), and the only reason we need a driver > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > side and filter out resolutions. Also, the converter is on a different > > > I2C address and it could almost be considered as a separate device. > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > leave that to others if there's ever a board that is built with the > > > TCPC part connected to the AP) > > > > Is the mux the one that is handled through a gpio-mux driver in this > > series, or a different mux ? > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 and DP (internally converted from HDMI), and decides which 2 lanes to use for each (4 lanes in total, but DP can only take 2 with this converter), and flip if necessary. This is all controlled by the EC (like on most other Chromebooks), so this is transparent to the kernel on this hardware. > > It would really, really help if you could > > show a block diagram of the related hardware (including the EC), as this > > is quite confusing. With every e-mail exchanged there's a bit more > > information that change my understanding of the issue, I can't really > > provide guidance without a full overview. https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the display part of the problem. You can just add a USB3 connection to the above (there's also I2C interface to the EC of course to control the TCPC/mux aspect of it, but that's on different I2C addresses). Something like this: +-----------+ +---------+ +------+ /--> | HDMI | | MT8173 | HDMI | -->| --/ | Connector | | HDMI | ------> |--/ | +-----------+ | Encoder | | ->| --\ +-----------+ +-----------+ +---------+ +------+ \--> | ANX7688 | ---> | USB-C | | Bridge | | Connector | USB3--> | + mux | | | +-----------+ +-----------+ ^ ^ (I2C) | | (I2C) MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) Power is also fully controlled by the EC. (the product brief has a good diagram of the internals of the ANX7688: https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) The ANX7688 bridge could _almost_ work driverless (and it does already), the _only_ thing that the driver is doing is filtering out impossible resolution based on DP (over USB-C) number of lanes and bandwidth. This is required to support, for example, old monitors that may only do RBR over DP (so we can't drive the full resolution over 2 DP lanes, we'd need 4 lanes, and we need to filter out the higher resolution modes). > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > --- > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > 3 files changed, 212 insertions(+) > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > menu "Display Interface Bridges" > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > + select DRM_KMS_HELPER > > > > > > + select REGMAP_I2C > > > > > > + ---help--- > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > + smartphone and tablets. > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > + > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > select DRM_KMS_HELPER > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > @@ -1,4 +1,5 @@ > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > new file mode 100644 > > > > > > index 000000000000..baaed48d6201 > > > > > > --- /dev/null > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > @@ -0,0 +1,202 @@ > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > +/* > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > + * > > > > > > + * Copyright 2016 Google LLC > > > > > > + */ > > > > > > + > > > > > > +#include <linux/i2c.h> > > > > > > +#include <linux/module.h> > > > > > > +#include <linux/regmap.h> > > > > > > +#include <drm/drm_bridge.h> > > > > > > + > > > > > > +/* Register addresses */ > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > + > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > + > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > ANX customers...). We have facilities to update the ANX FW from > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > the factory FW of all MP Chromebooks does provide these registers. > > > > So the driver is specific to Chromebooks, it doesn't support all > > ANX7688. Sweet :-( > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? Also, this driver is only required to implement the mode filtering, which, possibly, is only supported by the Google version of the FW (I have no idea what other customers ANX has for this part, if they care about this problem, and if so, how they solve it). ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-17 0:40 ` Nicolas Boichat 0 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-17 0:40 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Hsin-Yi Wang, Enric Balletbo i Serra, Russell King (Brilliant, I managed to accidentally send the email below, and send it as HTML, sorry about that... ASCII art in gmail is hard ,-( Take 2:) Hi Laurent, > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > > > Hello Nicolas and Hsin-Yi, > > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > that has an internal microcontroller. > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > resolutions that require more bandwidth than what is available on > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > via 2 registers on I2C. > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > need to be controlled ? > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > To clarify a bit more, this is because this chip is actually a > > > TCPC+mux+HDMI=>DP converter > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > power and other control pins), and the only reason we need a driver > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > side and filter out resolutions. Also, the converter is on a different > > > I2C address and it could almost be considered as a separate device. > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > leave that to others if there's ever a board that is built with the > > > TCPC part connected to the AP) > > > > Is the mux the one that is handled through a gpio-mux driver in this > > series, or a different mux ? > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 and DP (internally converted from HDMI), and decides which 2 lanes to use for each (4 lanes in total, but DP can only take 2 with this converter), and flip if necessary. This is all controlled by the EC (like on most other Chromebooks), so this is transparent to the kernel on this hardware. > > It would really, really help if you could > > show a block diagram of the related hardware (including the EC), as this > > is quite confusing. With every e-mail exchanged there's a bit more > > information that change my understanding of the issue, I can't really > > provide guidance without a full overview. https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the display part of the problem. You can just add a USB3 connection to the above (there's also I2C interface to the EC of course to control the TCPC/mux aspect of it, but that's on different I2C addresses). Something like this: +-----------+ +---------+ +------+ /--> | HDMI | | MT8173 | HDMI | -->| --/ | Connector | | HDMI | ------> |--/ | +-----------+ | Encoder | | ->| --\ +-----------+ +-----------+ +---------+ +------+ \--> | ANX7688 | ---> | USB-C | | Bridge | | Connector | USB3--> | + mux | | | +-----------+ +-----------+ ^ ^ (I2C) | | (I2C) MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) Power is also fully controlled by the EC. (the product brief has a good diagram of the internals of the ANX7688: https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) The ANX7688 bridge could _almost_ work driverless (and it does already), the _only_ thing that the driver is doing is filtering out impossible resolution based on DP (over USB-C) number of lanes and bandwidth. This is required to support, for example, old monitors that may only do RBR over DP (so we can't drive the full resolution over 2 DP lanes, we'd need 4 lanes, and we need to filter out the higher resolution modes). > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > --- > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > 3 files changed, 212 insertions(+) > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > menu "Display Interface Bridges" > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > + select DRM_KMS_HELPER > > > > > > + select REGMAP_I2C > > > > > > + ---help--- > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > + smartphone and tablets. > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > + > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > select DRM_KMS_HELPER > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > @@ -1,4 +1,5 @@ > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > new file mode 100644 > > > > > > index 000000000000..baaed48d6201 > > > > > > --- /dev/null > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > @@ -0,0 +1,202 @@ > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > +/* > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > + * > > > > > > + * Copyright 2016 Google LLC > > > > > > + */ > > > > > > + > > > > > > +#include <linux/i2c.h> > > > > > > +#include <linux/module.h> > > > > > > +#include <linux/regmap.h> > > > > > > +#include <drm/drm_bridge.h> > > > > > > + > > > > > > +/* Register addresses */ > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > + > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > + > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > ANX customers...). We have facilities to update the ANX FW from > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > the factory FW of all MP Chromebooks does provide these registers. > > > > So the driver is specific to Chromebooks, it doesn't support all > > ANX7688. Sweet :-( > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? Also, this driver is only required to implement the mode filtering, which, possibly, is only supported by the Google version of the FW (I have no idea what other customers ANX has for this part, if they care about this problem, and if so, how they solve it). _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-17 0:40 ` Nicolas Boichat @ 2019-12-17 0:52 ` Laurent Pinchart -1 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-17 0:52 UTC (permalink / raw) To: Nicolas Boichat Cc: Hsin-Yi Wang, dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hi Nicolas, On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > (Brilliant, I managed to accidentally send the email below, and send > it as HTML, sorry about that... ASCII art in gmail is hard ,-( No worries. I have been told it's indeed painful. > Take 2:) > > Hi Laurent, > > > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart wrote: > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > > that has an internal microcontroller. > > > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > > resolutions that require more bandwidth than what is available on > > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > > via 2 registers on I2C. > > > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > > need to be controlled ? > > > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > > > To clarify a bit more, this is because this chip is actually a > > > > TCPC+mux+HDMI=>DP converter > > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > > power and other control pins), and the only reason we need a driver > > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > > side and filter out resolutions. Also, the converter is on a different > > > > I2C address and it could almost be considered as a separate device. > > > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > > leave that to others if there's ever a board that is built with the > > > > TCPC part connected to the AP) > > > > > > Is the mux the one that is handled through a gpio-mux driver in this > > > series, or a different mux ? > > > > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 > and DP (internally converted from HDMI), and decides which 2 lanes to > use for each (4 lanes in total, but DP can only take 2 with this > converter), and flip if necessary. This is all controlled by the EC > (like on most other Chromebooks), so this is transparent to the kernel > on this hardware. > > > > It would really, really help if you could > > > show a block diagram of the related hardware (including the EC), as this > > > is quite confusing. With every e-mail exchanged there's a bit more > > > information that change my understanding of the issue, I can't really > > > provide guidance without a full overview. > > https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the > display part of the problem. > > You can just add a USB3 connection to the above (there's also I2C > interface to the EC of course to control the TCPC/mux aspect of it, > but that's on different I2C addresses). Something like this: > > +-----------+ > +---------+ +------+ /--> | HDMI | > | MT8173 | HDMI | -->| --/ | Connector | > | HDMI | ------> |--/ | +-----------+ > | Encoder | | ->| --\ +-----------+ +-----------+ > +---------+ +------+ \--> | ANX7688 | ---> | USB-C | > | Bridge | | Connector | > USB3--> | + mux | | | > +-----------+ +-----------+ > ^ ^ > (I2C) | | (I2C) > MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) > > Power is also fully controlled by the EC. Could I ask you to also explain how the HDMI mux is controlled, and where the HPD-related signals for the HDMI connector and USB-C connector are routed to ? > (the product brief has a good diagram of the internals of the ANX7688: > https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) > > The ANX7688 bridge could _almost_ work driverless (and it does > already), the _only_ thing that the driver is doing is filtering out > impossible resolution based on DP (over USB-C) number of lanes and > bandwidth. This is required to support, for example, old monitors that > may only do RBR over DP (so we can't drive the full resolution over 2 > DP lanes, we'd need 4 lanes, and we need to filter out the higher > resolution modes). > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > > --- > > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > > 3 files changed, 212 insertions(+) > > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > > menu "Display Interface Bridges" > > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > > + select DRM_KMS_HELPER > > > > > > > + select REGMAP_I2C > > > > > > > + ---help--- > > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > > + smartphone and tablets. > > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > > + > > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > > select DRM_KMS_HELPER > > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > > @@ -1,4 +1,5 @@ > > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > new file mode 100644 > > > > > > > index 000000000000..baaed48d6201 > > > > > > > --- /dev/null > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > @@ -0,0 +1,202 @@ > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > +/* > > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > > + * > > > > > > > + * Copyright 2016 Google LLC > > > > > > > + */ > > > > > > > + > > > > > > > +#include <linux/i2c.h> > > > > > > > +#include <linux/module.h> > > > > > > > +#include <linux/regmap.h> > > > > > > > +#include <drm/drm_bridge.h> > > > > > > > + > > > > > > > +/* Register addresses */ > > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > > + > > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > > + > > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > > ANX customers...). We have facilities to update the ANX FW from > > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > > the factory FW of all MP Chromebooks does provide these registers. > > > > > > So the driver is specific to Chromebooks, it doesn't support all > > > ANX7688. Sweet :-( > > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? That's good news :-) > Also, this driver is only required to implement the mode filtering, > which, possibly, is only supported by the Google version of the FW (I > have no idea what other customers ANX has for this part, if they care > about this problem, and if so, how they solve it). -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-17 0:52 ` Laurent Pinchart 0 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-17 0:52 UTC (permalink / raw) To: Nicolas Boichat Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Hsin-Yi Wang, Enric Balletbo i Serra, Russell King Hi Nicolas, On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > (Brilliant, I managed to accidentally send the email below, and send > it as HTML, sorry about that... ASCII art in gmail is hard ,-( No worries. I have been told it's indeed painful. > Take 2:) > > Hi Laurent, > > > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart wrote: > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > > that has an internal microcontroller. > > > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > > resolutions that require more bandwidth than what is available on > > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > > via 2 registers on I2C. > > > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > > need to be controlled ? > > > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > > > To clarify a bit more, this is because this chip is actually a > > > > TCPC+mux+HDMI=>DP converter > > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > > power and other control pins), and the only reason we need a driver > > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > > side and filter out resolutions. Also, the converter is on a different > > > > I2C address and it could almost be considered as a separate device. > > > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > > leave that to others if there's ever a board that is built with the > > > > TCPC part connected to the AP) > > > > > > Is the mux the one that is handled through a gpio-mux driver in this > > > series, or a different mux ? > > > > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 > and DP (internally converted from HDMI), and decides which 2 lanes to > use for each (4 lanes in total, but DP can only take 2 with this > converter), and flip if necessary. This is all controlled by the EC > (like on most other Chromebooks), so this is transparent to the kernel > on this hardware. > > > > It would really, really help if you could > > > show a block diagram of the related hardware (including the EC), as this > > > is quite confusing. With every e-mail exchanged there's a bit more > > > information that change my understanding of the issue, I can't really > > > provide guidance without a full overview. > > https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the > display part of the problem. > > You can just add a USB3 connection to the above (there's also I2C > interface to the EC of course to control the TCPC/mux aspect of it, > but that's on different I2C addresses). Something like this: > > +-----------+ > +---------+ +------+ /--> | HDMI | > | MT8173 | HDMI | -->| --/ | Connector | > | HDMI | ------> |--/ | +-----------+ > | Encoder | | ->| --\ +-----------+ +-----------+ > +---------+ +------+ \--> | ANX7688 | ---> | USB-C | > | Bridge | | Connector | > USB3--> | + mux | | | > +-----------+ +-----------+ > ^ ^ > (I2C) | | (I2C) > MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) > > Power is also fully controlled by the EC. Could I ask you to also explain how the HDMI mux is controlled, and where the HPD-related signals for the HDMI connector and USB-C connector are routed to ? > (the product brief has a good diagram of the internals of the ANX7688: > https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) > > The ANX7688 bridge could _almost_ work driverless (and it does > already), the _only_ thing that the driver is doing is filtering out > impossible resolution based on DP (over USB-C) number of lanes and > bandwidth. This is required to support, for example, old monitors that > may only do RBR over DP (so we can't drive the full resolution over 2 > DP lanes, we'd need 4 lanes, and we need to filter out the higher > resolution modes). > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > > --- > > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > > 3 files changed, 212 insertions(+) > > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > > menu "Display Interface Bridges" > > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > > + select DRM_KMS_HELPER > > > > > > > + select REGMAP_I2C > > > > > > > + ---help--- > > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > > + smartphone and tablets. > > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > > + > > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > > select DRM_KMS_HELPER > > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > > @@ -1,4 +1,5 @@ > > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > new file mode 100644 > > > > > > > index 000000000000..baaed48d6201 > > > > > > > --- /dev/null > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > @@ -0,0 +1,202 @@ > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > +/* > > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > > + * > > > > > > > + * Copyright 2016 Google LLC > > > > > > > + */ > > > > > > > + > > > > > > > +#include <linux/i2c.h> > > > > > > > +#include <linux/module.h> > > > > > > > +#include <linux/regmap.h> > > > > > > > +#include <drm/drm_bridge.h> > > > > > > > + > > > > > > > +/* Register addresses */ > > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > > + > > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > > + > > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > > ANX customers...). We have facilities to update the ANX FW from > > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > > the factory FW of all MP Chromebooks does provide these registers. > > > > > > So the driver is specific to Chromebooks, it doesn't support all > > > ANX7688. Sweet :-( > > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? That's good news :-) > Also, this driver is only required to implement the mode filtering, > which, possibly, is only supported by the Google version of the FW (I > have no idea what other customers ANX has for this part, if they care > about this problem, and if so, how they solve it). -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-17 0:52 ` Laurent Pinchart @ 2019-12-17 6:04 ` Nicolas Boichat -1 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-17 6:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Hsin-Yi Wang, dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hi, On Tue, Dec 17, 2019 at 8:52 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Nicolas, > > On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > > (Brilliant, I managed to accidentally send the email below, and send > > it as HTML, sorry about that... ASCII art in gmail is hard ,-( > > No worries. I have been told it's indeed painful. > > > Take 2:) > > > > Hi Laurent, > > > > > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart wrote: > > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > > > that has an internal microcontroller. > > > > > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > > > resolutions that require more bandwidth than what is available on > > > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > > > via 2 registers on I2C. > > > > > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > > > need to be controlled ? > > > > > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > > > > > To clarify a bit more, this is because this chip is actually a > > > > > TCPC+mux+HDMI=>DP converter > > > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > > > power and other control pins), and the only reason we need a driver > > > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > > > side and filter out resolutions. Also, the converter is on a different > > > > > I2C address and it could almost be considered as a separate device. > > > > > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > > > leave that to others if there's ever a board that is built with the > > > > > TCPC part connected to the AP) > > > > > > > > Is the mux the one that is handled through a gpio-mux driver in this > > > > series, or a different mux ? > > > > > > > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 > > and DP (internally converted from HDMI), and decides which 2 lanes to > > use for each (4 lanes in total, but DP can only take 2 with this > > converter), and flip if necessary. This is all controlled by the EC > > (like on most other Chromebooks), so this is transparent to the kernel > > on this hardware. > > > > > > It would really, really help if you could > > > > show a block diagram of the related hardware (including the EC), as this > > > > is quite confusing. With every e-mail exchanged there's a bit more > > > > information that change my understanding of the issue, I can't really > > > > provide guidance without a full overview. > > > > https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the > > display part of the problem. > > > > You can just add a USB3 connection to the above (there's also I2C > > interface to the EC of course to control the TCPC/mux aspect of it, > > but that's on different I2C addresses). Something like this: > > > > +-----------+ > > +---------+ +------+ /--> | HDMI | > > | MT8173 | HDMI | -->| --/ | Connector | > > | HDMI | ------> |--/ | +-----------+ > > | Encoder | | ->| --\ +-----------+ +-----------+ > > +---------+ +------+ \--> | ANX7688 | ---> | USB-C | > > | Bridge | | Connector | > > USB3--> | + mux | | | > > +-----------+ +-----------+ > > ^ ^ > > (I2C) | | (I2C) > > MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) > > > > Power is also fully controlled by the EC. > > Could I ask you to also explain how the HDMI mux is controlled, Priority to HDMI. If the HDMI is connected (looking at its HPD signal), then the HDMI signals are routed to HDMI connector. Else HDMI is routed to ANX7688/USB-C. > and > where the HPD-related signals for the HDMI connector and USB-C connector > are routed to ? HPD is also muxed by the mux, between the 2 inputs. (http://www.ti.com/lit/ds/symlink/ts3dv642.pdf, if you are curious, 9.2.3 is basically how things are wired, with one of the HPD_A/B connected to SEL2) My memory is fading away now, but I think at some point we considered having hardware send an HPD pulse when the input changes, but decided against it (for cost/complexity reasons). So that means that if both HDMI and USB-C monitors are plugged, and you unplug HDMI, the mux would switch but you would not get an HPD pulse. That's one of the reason we need to react to edges on the mux SEL signal to ask the kernel to re-read the EDID (that's in the other driver that Hsin-Yi is trying (again) to upstream in this series). (IIRC, that's also why HDMI HPD pulse work if both connectors are plugged, we get the edge on the SEL signal an re-read the EDID). Thanks. > > (the product brief has a good diagram of the internals of the ANX7688: > > https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) > > > > The ANX7688 bridge could _almost_ work driverless (and it does > > already), the _only_ thing that the driver is doing is filtering out > > impossible resolution based on DP (over USB-C) number of lanes and > > bandwidth. This is required to support, for example, old monitors that > > may only do RBR over DP (so we can't drive the full resolution over 2 > > DP lanes, we'd need 4 lanes, and we need to filter out the higher > > resolution modes). > > > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > > > --- > > > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > > > 3 files changed, 212 insertions(+) > > > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > > > menu "Display Interface Bridges" > > > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > > > + select DRM_KMS_HELPER > > > > > > > > + select REGMAP_I2C > > > > > > > > + ---help--- > > > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > > > + smartphone and tablets. > > > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > > > + > > > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > > > select DRM_KMS_HELPER > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > > > @@ -1,4 +1,5 @@ > > > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > new file mode 100644 > > > > > > > > index 000000000000..baaed48d6201 > > > > > > > > --- /dev/null > > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > @@ -0,0 +1,202 @@ > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > > +/* > > > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > > > + * > > > > > > > > + * Copyright 2016 Google LLC > > > > > > > > + */ > > > > > > > > + > > > > > > > > +#include <linux/i2c.h> > > > > > > > > +#include <linux/module.h> > > > > > > > > +#include <linux/regmap.h> > > > > > > > > +#include <drm/drm_bridge.h> > > > > > > > > + > > > > > > > > +/* Register addresses */ > > > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > > > + > > > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > > > + > > > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > > > ANX customers...). We have facilities to update the ANX FW from > > > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > > > the factory FW of all MP Chromebooks does provide these registers. > > > > > > > > So the driver is specific to Chromebooks, it doesn't support all > > > > ANX7688. Sweet :-( > > > > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? > > That's good news :-) > > > Also, this driver is only required to implement the mode filtering, > > which, possibly, is only supported by the Google version of the FW (I > > have no idea what other customers ANX has for this part, if they care > > about this problem, and if so, how they solve it). > > -- > Regards, > > Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-17 6:04 ` Nicolas Boichat 0 siblings, 0 replies; 51+ messages in thread From: Nicolas Boichat @ 2019-12-17 6:04 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Matthias Brugger, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Hsin-Yi Wang, Enric Balletbo i Serra, Russell King Hi, On Tue, Dec 17, 2019 at 8:52 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Nicolas, > > On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > > (Brilliant, I managed to accidentally send the email below, and send > > it as HTML, sorry about that... ASCII art in gmail is hard ,-( > > No worries. I have been told it's indeed painful. > > > Take 2:) > > > > Hi Laurent, > > > > > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart wrote: > > > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > > > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > > > > On Sat, Dec 14, 2019 at 6:38 AM Laurent Pinchart wrote: > > > > > > > On Wed, Dec 11, 2019 at 02:19:09PM +0800, Hsin-Yi Wang wrote: > > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > > > > > > > > > ANX7688 is a HDMI to DP converter (as well as USB-C port controller), > > > > > > > > that has an internal microcontroller. > > > > > > > > > > > > > > > > The only reason a Linux kernel driver is necessary is to reject > > > > > > > > resolutions that require more bandwidth than what is available on > > > > > > > > the DP side. DP bandwidth and lane count are reported by the bridge > > > > > > > > via 2 registers on I2C. > > > > > > > > > > > > > > How about power, doesn't this chip have power supplies that potentially > > > > > > > need to be controlled ? > > > > > > > > > > > > > Ideally we should add power supplies as well, but the power is > > > > > > supplied by ec in mt8173 oak board. And we only have this board can > > > > > > test this driver. If we add power supplies in driver we can't test it. > > > > > > > > > > To clarify a bit more, this is because this chip is actually a > > > > > TCPC+mux+HDMI=>DP converter > > > > > (https://www.analogix.com/en/products/convertersbridges/anx7688). In > > > > > Chromebook architecture, TCPC+mux is controlled by the EC (including > > > > > power and other control pins), and the only reason we need a driver > > > > > for the HDMI=>DP converter is to get the number of lanes on the DP > > > > > side and filter out resolutions. Also, the converter is on a different > > > > > I2C address and it could almost be considered as a separate device. > > > > > > > > > > (of course we could write a kernel driver for the TCPC+mux but we'll > > > > > leave that to others if there's ever a board that is built with the > > > > > TCPC part connected to the AP) > > > > > > > > Is the mux the one that is handled through a gpio-mux driver in this > > > > series, or a different mux ? > > > > > > > It's a different mux: it's the usual USB-C mux that takes in USB 3.0 > > and DP (internally converted from HDMI), and decides which 2 lanes to > > use for each (4 lanes in total, but DP can only take 2 with this > > converter), and flip if necessary. This is all controlled by the EC > > (like on most other Chromebooks), so this is transparent to the kernel > > on this hardware. > > > > > > It would really, really help if you could > > > > show a block diagram of the related hardware (including the EC), as this > > > > is quite confusing. With every e-mail exchanged there's a bit more > > > > information that change my understanding of the issue, I can't really > > > > provide guidance without a full overview. > > > > https://lkml.org/lkml/2019/12/9/548 that you drew is accurate for the > > display part of the problem. > > > > You can just add a USB3 connection to the above (there's also I2C > > interface to the EC of course to control the TCPC/mux aspect of it, > > but that's on different I2C addresses). Something like this: > > > > +-----------+ > > +---------+ +------+ /--> | HDMI | > > | MT8173 | HDMI | -->| --/ | Connector | > > | HDMI | ------> |--/ | +-----------+ > > | Encoder | | ->| --\ +-----------+ +-----------+ > > +---------+ +------+ \--> | ANX7688 | ---> | USB-C | > > | Bridge | | Connector | > > USB3--> | + mux | | | > > +-----------+ +-----------+ > > ^ ^ > > (I2C) | | (I2C) > > MT8173 (DP lane count/bw readback) -- + + -- EC (TCPC+mux control) > > > > Power is also fully controlled by the EC. > > Could I ask you to also explain how the HDMI mux is controlled, Priority to HDMI. If the HDMI is connected (looking at its HPD signal), then the HDMI signals are routed to HDMI connector. Else HDMI is routed to ANX7688/USB-C. > and > where the HPD-related signals for the HDMI connector and USB-C connector > are routed to ? HPD is also muxed by the mux, between the 2 inputs. (http://www.ti.com/lit/ds/symlink/ts3dv642.pdf, if you are curious, 9.2.3 is basically how things are wired, with one of the HPD_A/B connected to SEL2) My memory is fading away now, but I think at some point we considered having hardware send an HPD pulse when the input changes, but decided against it (for cost/complexity reasons). So that means that if both HDMI and USB-C monitors are plugged, and you unplug HDMI, the mux would switch but you would not get an HPD pulse. That's one of the reason we need to react to edges on the mux SEL signal to ask the kernel to re-read the EDID (that's in the other driver that Hsin-Yi is trying (again) to upstream in this series). (IIRC, that's also why HDMI HPD pulse work if both connectors are plugged, we get the edge on the SEL signal an re-read the EDID). Thanks. > > (the product brief has a good diagram of the internals of the ANX7688: > > https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf) > > > > The ANX7688 bridge could _almost_ work driverless (and it does > > already), the _only_ thing that the driver is doing is filtering out > > impossible resolution based on DP (over USB-C) number of lanes and > > bandwidth. This is required to support, for example, old monitors that > > may only do RBR over DP (so we can't drive the full resolution over 2 > > DP lanes, we'd need 4 lanes, and we need to filter out the higher > > resolution modes). > > > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > > > > > --- > > > > > > > > drivers/gpu/drm/bridge/Kconfig | 9 + > > > > > > > > drivers/gpu/drm/bridge/Makefile | 1 + > > > > > > > > drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++++++++++++++++++++++ > > > > > > > > 3 files changed, 212 insertions(+) > > > > > > > > create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > > > > > > > index 34362976cd6f..1f3fc6bec842 100644 > > > > > > > > --- a/drivers/gpu/drm/bridge/Kconfig > > > > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig > > > > > > > > @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE > > > > > > > > menu "Display Interface Bridges" > > > > > > > > depends on DRM && DRM_BRIDGE > > > > > > > > > > > > > > > > +config DRM_ANALOGIX_ANX7688 > > > > > > > > + tristate "Analogix ANX7688 bridge" > > > > > > > > + select DRM_KMS_HELPER > > > > > > > > + select REGMAP_I2C > > > > > > > > + ---help--- > > > > > > > > + ANX7688 is a transmitter to support DisplayPort over USB-C for > > > > > > > > + smartphone and tablets. > > > > > > > > + This driver only supports the HDMI to DP component of the chip. > > > > > > > > + > > > > > > > > config DRM_ANALOGIX_ANX78XX > > > > > > > > tristate "Analogix ANX78XX bridge" > > > > > > > > select DRM_KMS_HELPER > > > > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > > > > > > > index 4934fcf5a6f8..7a1e0ec032e6 100644 > > > > > > > > --- a/drivers/gpu/drm/bridge/Makefile > > > > > > > > +++ b/drivers/gpu/drm/bridge/Makefile > > > > > > > > @@ -1,4 +1,5 @@ > > > > > > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > > > +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > > > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > > > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > > > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > new file mode 100644 > > > > > > > > index 000000000000..baaed48d6201 > > > > > > > > --- /dev/null > > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c > > > > > > > > @@ -0,0 +1,202 @@ > > > > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > > > > +/* > > > > > > > > + * ANX7688 HDMI->DP bridge driver > > > > > > > > + * > > > > > > > > + * Copyright 2016 Google LLC > > > > > > > > + */ > > > > > > > > + > > > > > > > > +#include <linux/i2c.h> > > > > > > > > +#include <linux/module.h> > > > > > > > > +#include <linux/regmap.h> > > > > > > > > +#include <drm/drm_bridge.h> > > > > > > > > + > > > > > > > > +/* Register addresses */ > > > > > > > > +#define VENDOR_ID_REG 0x00 > > > > > > > > +#define DEVICE_ID_REG 0x02 > > > > > > > > + > > > > > > > > +#define FW_VERSION_REG 0x80 > > > > > > > > + > > > > > > > > +#define DP_BANDWIDTH_REG 0x85 > > > > > > > > +#define DP_LANE_COUNT_REG 0x86 > > > > > > > > > > > > > > Are these registers defined by the ANX7688 hardware, or by the firmware > > > > > > > running on the chip (and, I assume, developed by Google) ? > > > > > > > > > > > > > By firmware developed by ANX provided to Google. > > > > > > > > > > We asked for these registers to be added to ANX FW, and this is the FW > > > > > that is used by all elm/hana Chromebooks (I have no idea about other > > > > > ANX customers...). We have facilities to update the ANX FW from > > > > > coreboot/depthcharge on Chromebooks, but that does not really matter: > > > > > the factory FW of all MP Chromebooks does provide these registers. > > > > > > > > So the driver is specific to Chromebooks, it doesn't support all > > > > ANX7688. Sweet :-( > > > > FWIW, this is a 3+ year old part, so it appears that nobody else cares anyway? > > That's good news :-) > > > Also, this driver is only required to implement the mode filtering, > > which, possibly, is only supported by the Google version of the FW (I > > have no idea what other customers ANX has for this part, if they care > > about this problem, and if so, how they solve it). > > -- > Regards, > > Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-11 6:19 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King From: Nicolas Boichat <drinkcat@chromium.org> Add bindings for Generic GPIO mux driver. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- Change from RFC to v1: - txt to yaml --- .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml new file mode 100644 index 000000000000..cef098749066 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic display mux (1 input, 2 outputs) + +maintainers: + - Nicolas Boichat <drinkcat@chromium.org> + +description: | + This bindings describes a simple display (e.g. HDMI) mux, that has 1 + input, and 2 outputs. The mux status is controlled by hardware, and + its status is read back using a GPIO. + +properties: + compatible: + const: gpio-display-mux + + detect-gpios: + maxItems: 1 + description: GPIO that indicates the active output + + ports: + type: object + + properties: + port@0: + type: object + description: | + Video port for input. + + port@1: + type: object + description: | + 2 video ports for output. + The reg value in the endpoints matches the GPIO status: when + GPIO is asserted, endpoint with reg value <1> is selected. + + required: + - port@0 + - port@1 + +required: + - compatible + - detect-gpios + - ports + +examples: + - | + hdmi_mux: hdmi_mux { + compatible = "gpio-display-mux"; + status = "okay"; + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_mux_pins>; + ddc-i2c-bus = <&hdmiddc0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { /* input */ + reg = <0>; + + hdmi_mux_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + + port@1 { /* output */ + reg = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + hdmi_mux_out_anx: endpoint@0 { + reg = <0>; + remote-endpoint = <&anx7688_in>; + }; + + hdmi_mux_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; -- 2.24.0.525.g8f36a354ae-goog ^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding @ 2019-12-11 6:19 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King From: Nicolas Boichat <drinkcat@chromium.org> Add bindings for Generic GPIO mux driver. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- Change from RFC to v1: - txt to yaml --- .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml new file mode 100644 index 000000000000..cef098749066 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic display mux (1 input, 2 outputs) + +maintainers: + - Nicolas Boichat <drinkcat@chromium.org> + +description: | + This bindings describes a simple display (e.g. HDMI) mux, that has 1 + input, and 2 outputs. The mux status is controlled by hardware, and + its status is read back using a GPIO. + +properties: + compatible: + const: gpio-display-mux + + detect-gpios: + maxItems: 1 + description: GPIO that indicates the active output + + ports: + type: object + + properties: + port@0: + type: object + description: | + Video port for input. + + port@1: + type: object + description: | + 2 video ports for output. + The reg value in the endpoints matches the GPIO status: when + GPIO is asserted, endpoint with reg value <1> is selected. + + required: + - port@0 + - port@1 + +required: + - compatible + - detect-gpios + - ports + +examples: + - | + hdmi_mux: hdmi_mux { + compatible = "gpio-display-mux"; + status = "okay"; + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_mux_pins>; + ddc-i2c-bus = <&hdmiddc0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { /* input */ + reg = <0>; + + hdmi_mux_in: endpoint { + remote-endpoint = <&hdmi0_out>; + }; + }; + + port@1 { /* output */ + reg = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + hdmi_mux_out_anx: endpoint@0 { + reg = <0>; + remote-endpoint = <&anx7688_in>; + }; + + hdmi_mux_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; -- 2.24.0.525.g8f36a354ae-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-13 13:53 ` Rob Herring -1 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-13 13:53 UTC (permalink / raw) To: Hsin-Yi Wang Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > Add bindings for Generic GPIO mux driver. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > Change from RFC to v1: > - txt to yaml > --- > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > 1 file changed, 89 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > new file mode 100644 > index 000000000000..cef098749066 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > @@ -0,0 +1,89 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic display mux (1 input, 2 outputs) What makes it generic? Doesn't the mux chip have power supply, possibly a reset line or not, etc.? What about a mux where the GPIO controls the mux? Generally, we avoid 'generic' bindings because h/w is rarely generic. You can have a generic driver which works on multiple devices. > + > +maintainers: > + - Nicolas Boichat <drinkcat@chromium.org> > + > +description: | > + This bindings describes a simple display (e.g. HDMI) mux, that has 1 > + input, and 2 outputs. The mux status is controlled by hardware, and > + its status is read back using a GPIO. > + > +properties: > + compatible: > + const: gpio-display-mux > + > + detect-gpios: > + maxItems: 1 > + description: GPIO that indicates the active output > + > + ports: > + type: object > + > + properties: > + port@0: > + type: object > + description: | > + Video port for input. > + > + port@1: > + type: object > + description: | > + 2 video ports for output. > + The reg value in the endpoints matches the GPIO status: when > + GPIO is asserted, endpoint with reg value <1> is selected. You should describe 'endpoint@0' and 'endpoint@1' here too. > + > + required: > + - port@0 > + - port@1 > + > +required: > + - compatible > + - detect-gpios > + - ports > + > +examples: > + - | > + hdmi_mux: hdmi_mux { > + compatible = "gpio-display-mux"; > + status = "okay"; Don't show status in examples. > + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hdmi_mux_pins>; > + ddc-i2c-bus = <&hdmiddc0>; Not documented. Is the i2c bus muxed too? If not, then this is in the wrong place. > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { /* input */ > + reg = <0>; > + > + hdmi_mux_in: endpoint { > + remote-endpoint = <&hdmi0_out>; > + }; > + }; > + > + port@1 { /* output */ > + reg = <1>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + hdmi_mux_out_anx: endpoint@0 { > + reg = <0>; > + remote-endpoint = <&anx7688_in>; > + }; > + > + hdmi_mux_out_hdmi: endpoint@1 { > + reg = <1>; > + remote-endpoint = <&hdmi_connector_in>; > + }; > + }; > + }; > + }; > -- > 2.24.0.525.g8f36a354ae-goog > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding @ 2019-12-13 13:53 ` Rob Herring 0 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-13 13:53 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > Add bindings for Generic GPIO mux driver. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > Change from RFC to v1: > - txt to yaml > --- > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > 1 file changed, 89 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > new file mode 100644 > index 000000000000..cef098749066 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > @@ -0,0 +1,89 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic display mux (1 input, 2 outputs) What makes it generic? Doesn't the mux chip have power supply, possibly a reset line or not, etc.? What about a mux where the GPIO controls the mux? Generally, we avoid 'generic' bindings because h/w is rarely generic. You can have a generic driver which works on multiple devices. > + > +maintainers: > + - Nicolas Boichat <drinkcat@chromium.org> > + > +description: | > + This bindings describes a simple display (e.g. HDMI) mux, that has 1 > + input, and 2 outputs. The mux status is controlled by hardware, and > + its status is read back using a GPIO. > + > +properties: > + compatible: > + const: gpio-display-mux > + > + detect-gpios: > + maxItems: 1 > + description: GPIO that indicates the active output > + > + ports: > + type: object > + > + properties: > + port@0: > + type: object > + description: | > + Video port for input. > + > + port@1: > + type: object > + description: | > + 2 video ports for output. > + The reg value in the endpoints matches the GPIO status: when > + GPIO is asserted, endpoint with reg value <1> is selected. You should describe 'endpoint@0' and 'endpoint@1' here too. > + > + required: > + - port@0 > + - port@1 > + > +required: > + - compatible > + - detect-gpios > + - ports > + > +examples: > + - | > + hdmi_mux: hdmi_mux { > + compatible = "gpio-display-mux"; > + status = "okay"; Don't show status in examples. > + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hdmi_mux_pins>; > + ddc-i2c-bus = <&hdmiddc0>; Not documented. Is the i2c bus muxed too? If not, then this is in the wrong place. > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { /* input */ > + reg = <0>; > + > + hdmi_mux_in: endpoint { > + remote-endpoint = <&hdmi0_out>; > + }; > + }; > + > + port@1 { /* output */ > + reg = <1>; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + hdmi_mux_out_anx: endpoint@0 { > + reg = <0>; > + remote-endpoint = <&anx7688_in>; > + }; > + > + hdmi_mux_out_hdmi: endpoint@1 { > + reg = <1>; > + remote-endpoint = <&hdmi_connector_in>; > + }; > + }; > + }; > + }; > -- > 2.24.0.525.g8f36a354ae-goog > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding 2019-12-13 13:53 ` Rob Herring @ 2019-12-16 7:16 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 7:16 UTC (permalink / raw) To: Rob Herring Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > Add bindings for Generic GPIO mux driver. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > Change from RFC to v1: > > - txt to yaml > > --- > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > 1 file changed, 89 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > new file mode 100644 > > index 000000000000..cef098749066 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > @@ -0,0 +1,89 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Generic display mux (1 input, 2 outputs) > > What makes it generic? Doesn't the mux chip have power supply, > possibly a reset line or not, etc.? What about a mux where the GPIO > controls the mux? > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > You can have a generic driver which works on multiple devices. > Then how about making it mt8173-oak-gpio-mux? Since this is currently only used in this board. > > + > > +maintainers: > > + - Nicolas Boichat <drinkcat@chromium.org> > > + > > +description: | > > + This bindings describes a simple display (e.g. HDMI) mux, that has 1 > > + input, and 2 outputs. The mux status is controlled by hardware, and > > + its status is read back using a GPIO. > > + > > +properties: > > + compatible: > > + const: gpio-display-mux > > + > > + detect-gpios: > > + maxItems: 1 > > + description: GPIO that indicates the active output > > + > > + ports: > > + type: object > > + > > + properties: > > + port@0: > > + type: object > > + description: | > > + Video port for input. > > + > > + port@1: > > + type: object > > + description: | > > + 2 video ports for output. > > + The reg value in the endpoints matches the GPIO status: when > > + GPIO is asserted, endpoint with reg value <1> is selected. > > You should describe 'endpoint@0' and 'endpoint@1' here too. Will add in next version, thanks > > > + > > + required: > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - detect-gpios > > + - ports > > + > > +examples: > > + - | > > + hdmi_mux: hdmi_mux { > > + compatible = "gpio-display-mux"; > > + status = "okay"; > > Don't show status in examples. > > > + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&hdmi_mux_pins>; > > + ddc-i2c-bus = <&hdmiddc0>; > > Not documented. Is the i2c bus muxed too? If not, then this is in the > wrong place. > It's muxed, but this is required because of [1], so it should be removed in this example. [1]https://elixir.bootlin.com/linux/v5.5-rc2/source/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt#L24 > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { /* input */ > > + reg = <0>; > > + > > + hdmi_mux_in: endpoint { > > + remote-endpoint = <&hdmi0_out>; > > + }; > > + }; > > + > > + port@1 { /* output */ > > + reg = <1>; > > + > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + hdmi_mux_out_anx: endpoint@0 { > > + reg = <0>; > > + remote-endpoint = <&anx7688_in>; > > + }; > > + > > + hdmi_mux_out_hdmi: endpoint@1 { > > + reg = <1>; > > + remote-endpoint = <&hdmi_connector_in>; > > + }; > > + }; > > + }; > > + }; > > -- > > 2.24.0.525.g8f36a354ae-goog > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding @ 2019-12-16 7:16 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 7:16 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > Add bindings for Generic GPIO mux driver. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > Change from RFC to v1: > > - txt to yaml > > --- > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > 1 file changed, 89 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > new file mode 100644 > > index 000000000000..cef098749066 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > @@ -0,0 +1,89 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Generic display mux (1 input, 2 outputs) > > What makes it generic? Doesn't the mux chip have power supply, > possibly a reset line or not, etc.? What about a mux where the GPIO > controls the mux? > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > You can have a generic driver which works on multiple devices. > Then how about making it mt8173-oak-gpio-mux? Since this is currently only used in this board. > > + > > +maintainers: > > + - Nicolas Boichat <drinkcat@chromium.org> > > + > > +description: | > > + This bindings describes a simple display (e.g. HDMI) mux, that has 1 > > + input, and 2 outputs. The mux status is controlled by hardware, and > > + its status is read back using a GPIO. > > + > > +properties: > > + compatible: > > + const: gpio-display-mux > > + > > + detect-gpios: > > + maxItems: 1 > > + description: GPIO that indicates the active output > > + > > + ports: > > + type: object > > + > > + properties: > > + port@0: > > + type: object > > + description: | > > + Video port for input. > > + > > + port@1: > > + type: object > > + description: | > > + 2 video ports for output. > > + The reg value in the endpoints matches the GPIO status: when > > + GPIO is asserted, endpoint with reg value <1> is selected. > > You should describe 'endpoint@0' and 'endpoint@1' here too. Will add in next version, thanks > > > + > > + required: > > + - port@0 > > + - port@1 > > + > > +required: > > + - compatible > > + - detect-gpios > > + - ports > > + > > +examples: > > + - | > > + hdmi_mux: hdmi_mux { > > + compatible = "gpio-display-mux"; > > + status = "okay"; > > Don't show status in examples. > > > + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&hdmi_mux_pins>; > > + ddc-i2c-bus = <&hdmiddc0>; > > Not documented. Is the i2c bus muxed too? If not, then this is in the > wrong place. > It's muxed, but this is required because of [1], so it should be removed in this example. [1]https://elixir.bootlin.com/linux/v5.5-rc2/source/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt#L24 > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + port@0 { /* input */ > > + reg = <0>; > > + > > + hdmi_mux_in: endpoint { > > + remote-endpoint = <&hdmi0_out>; > > + }; > > + }; > > + > > + port@1 { /* output */ > > + reg = <1>; > > + > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + hdmi_mux_out_anx: endpoint@0 { > > + reg = <0>; > > + remote-endpoint = <&anx7688_in>; > > + }; > > + > > + hdmi_mux_out_hdmi: endpoint@1 { > > + reg = <1>; > > + remote-endpoint = <&hdmi_connector_in>; > > + }; > > + }; > > + }; > > + }; > > -- > > 2.24.0.525.g8f36a354ae-goog > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding 2019-12-16 7:16 ` Hsin-Yi Wang @ 2019-12-19 20:48 ` Rob Herring -1 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-19 20:48 UTC (permalink / raw) To: Hsin-Yi Wang Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Mon, Dec 16, 2019 at 03:16:23PM +0800, Hsin-Yi Wang wrote: > On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > Change from RFC to v1: > > > - txt to yaml > > > --- > > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > > 1 file changed, 89 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > new file mode 100644 > > > index 000000000000..cef098749066 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > @@ -0,0 +1,89 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Generic display mux (1 input, 2 outputs) > > > > What makes it generic? Doesn't the mux chip have power supply, > > possibly a reset line or not, etc.? What about a mux where the GPIO > > controls the mux? > > > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > > You can have a generic driver which works on multiple devices. > > > Then how about making it mt8173-oak-gpio-mux? Since this is currently > only used in this board. Isn't there an underlying part# you can use? Or if you can point me to multiple chips implementing the same thing, then maybe a generic binding is fine. Rob ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding @ 2019-12-19 20:48 ` Rob Herring 0 siblings, 0 replies; 51+ messages in thread From: Rob Herring @ 2019-12-19 20:48 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Mon, Dec 16, 2019 at 03:16:23PM +0800, Hsin-Yi Wang wrote: > On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > --- > > > Change from RFC to v1: > > > - txt to yaml > > > --- > > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > > 1 file changed, 89 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > new file mode 100644 > > > index 000000000000..cef098749066 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > @@ -0,0 +1,89 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Generic display mux (1 input, 2 outputs) > > > > What makes it generic? Doesn't the mux chip have power supply, > > possibly a reset line or not, etc.? What about a mux where the GPIO > > controls the mux? > > > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > > You can have a generic driver which works on multiple devices. > > > Then how about making it mt8173-oak-gpio-mux? Since this is currently > only used in this board. Isn't there an underlying part# you can use? Or if you can point me to multiple chips implementing the same thing, then maybe a generic binding is fine. Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding 2019-12-19 20:48 ` Rob Herring @ 2019-12-20 3:57 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:57 UTC (permalink / raw) To: Rob Herring Cc: dri-devel, David Airlie, Daniel Vetter, Mark Rutland, Nicolas Boichat, Devicetree List, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Fri, Dec 20, 2019 at 4:48 AM Rob Herring <robh@kernel.org> wrote: > > On Mon, Dec 16, 2019 at 03:16:23PM +0800, Hsin-Yi Wang wrote: > > On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > Change from RFC to v1: > > > > - txt to yaml > > > > --- > > > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > > > 1 file changed, 89 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > new file mode 100644 > > > > index 000000000000..cef098749066 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > @@ -0,0 +1,89 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Generic display mux (1 input, 2 outputs) > > > > > > What makes it generic? Doesn't the mux chip have power supply, > > > possibly a reset line or not, etc.? What about a mux where the GPIO > > > controls the mux? > > > > > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > > > You can have a generic driver which works on multiple devices. > > > > > Then how about making it mt8173-oak-gpio-mux? Since this is currently > > only used in this board. > > Isn't there an underlying part# you can use? Or if you can point me to > multiple chips implementing the same thing, then maybe a generic binding > is fine. There are some similar chips, for example: https://www.paradetech.com/zh-hant/%E7%94%A2%E5%93%81%E4%BB%8B%E7%B4%B9/ps8223-3-0gbps-hdmi-12-demultiplexer/ and http://www.ti.com/lit/ds/symlink/ts3dv642.pdf If they are used in a similar way (https://lore.kernel.org/lkml/CANMq1KDDEzPWhByEtn-EjNcg+ofVT2MW-hOXANGooYFOYJ35VA@mail.gmail.com/), they would need such driver. But currently we only know that mt8173 oak board have this use case. > > Rob ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding @ 2019-12-20 3:57 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-20 3:57 UTC (permalink / raw) To: Rob Herring Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Matthias Brugger, Laurent Pinchart, Enric Balletbo i Serra, Russell King On Fri, Dec 20, 2019 at 4:48 AM Rob Herring <robh@kernel.org> wrote: > > On Mon, Dec 16, 2019 at 03:16:23PM +0800, Hsin-Yi Wang wrote: > > On Sat, Dec 14, 2019 at 5:29 AM Rob Herring <robh+dt@kernel.org> wrote: > > > > > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote: > > > > > > > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > > > > > Add bindings for Generic GPIO mux driver. > > > > > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > > > --- > > > > Change from RFC to v1: > > > > - txt to yaml > > > > --- > > > > .../bindings/display/bridge/gpio-mux.yaml | 89 +++++++++++++++++++ > > > > 1 file changed, 89 insertions(+) > > > > create mode 100644 Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > new file mode 100644 > > > > index 000000000000..cef098749066 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml > > > > @@ -0,0 +1,89 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +%YAML 1.2 > > > > +--- > > > > +$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml# > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > + > > > > +title: Generic display mux (1 input, 2 outputs) > > > > > > What makes it generic? Doesn't the mux chip have power supply, > > > possibly a reset line or not, etc.? What about a mux where the GPIO > > > controls the mux? > > > > > > Generally, we avoid 'generic' bindings because h/w is rarely generic. > > > You can have a generic driver which works on multiple devices. > > > > > Then how about making it mt8173-oak-gpio-mux? Since this is currently > > only used in this board. > > Isn't there an underlying part# you can use? Or if you can point me to > multiple chips implementing the same thing, then maybe a generic binding > is fine. There are some similar chips, for example: https://www.paradetech.com/zh-hant/%E7%94%A2%E5%93%81%E4%BB%8B%E7%B4%B9/ps8223-3-0gbps-hdmi-12-demultiplexer/ and http://www.ti.com/lit/ds/symlink/ts3dv642.pdf If they are used in a similar way (https://lore.kernel.org/lkml/CANMq1KDDEzPWhByEtn-EjNcg+ofVT2MW-hOXANGooYFOYJ35VA@mail.gmail.com/), they would need such driver. But currently we only know that mt8173 oak board have this use case. > > Rob _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-11 6:19 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King From: Nicolas Boichat <drinkcat@chromium.org> This driver supports single input, 2 output display mux (e.g. HDMI mux), that provide its status via a GPIO. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ 3 files changed, 317 insertions(+) create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 1f3fc6bec842..4734f6993858 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC Support for non-programmable RGB to VGA DAC bridges, such as ADI ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. +config DRM_GENERIC_GPIO_MUX + tristate "Generic GPIO-controlled mux" + depends on OF + select DRM_KMS_HELPER + ---help--- + This bridge driver models a GPIO-controlled display mux with one + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output + is active, reports it as a GPIO, and the driver redirects calls to the + appropriate downstream bridge (if any). + config DRM_LVDS_ENCODER tristate "Transparent parallel to LVDS encoder support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 7a1e0ec032e6..1c0c92667ac4 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c new file mode 100644 index 000000000000..ba08321dcc17 --- /dev/null +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c @@ -0,0 +1,306 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Generic gpio mux bridge driver + * + * Copyright 2016 Google LLC + */ + + +#include <linux/gpio.h> +#include <linux/interrupt.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/of_graph.h> +#include <drm/drm_bridge.h> +#include <drm/drm_crtc_helper.h> +#include <drm/drm_probe_helper.h> + +struct gpio_display_mux { + struct device *dev; + + struct gpio_desc *gpiod_detect; + int detect_irq; + + struct drm_bridge bridge; + + struct drm_bridge *next[2]; +}; + +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( + struct drm_bridge *bridge) +{ + return container_of(bridge, struct gpio_display_mux, bridge); +} + +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) +{ + struct gpio_display_mux *gpio_display_mux = data; + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); + + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); + + if (gpio_display_mux->bridge.dev) + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); + + return IRQ_HANDLED; +} + +static int gpio_display_mux_attach(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next) + next->encoder = bridge->encoder; + } + + return 0; +} + +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + int active; + struct drm_bridge *next; + + active = gpiod_get_value(gpio_display_mux->gpiod_detect); + next = gpio_display_mux->next[active]; + + if (next && next->funcs->mode_fixup) + return next->funcs->mode_fixup(next, mode, adjusted_mode); + else + return true; +} + +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, + struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + int active; + struct drm_bridge *next; + + active = gpiod_get_value(gpio_display_mux->gpiod_detect); + next = gpio_display_mux->next[active]; + + if (next && next->funcs->mode_set) + next->funcs->mode_set(next, mode, adjusted_mode); +} + +/** + * Since this driver _reacts_ to mux changes, we need to make sure all + * downstream bridges are pre-enabled. + */ +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->pre_enable) + next->funcs->pre_enable(next); + } +} + +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->post_disable) + next->funcs->post_disable(next); + } +} + +/** + * In an ideal mux driver, only the currently selected bridge should be enabled. + * For the sake of simplicity, we just just enable/disable all downstream + * bridges at the same time. + */ +static void gpio_display_mux_enable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->enable) + next->funcs->enable(next); + } +} + +static void gpio_display_mux_disable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->disable) + next->funcs->disable(next); + } +} + +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { + .attach = gpio_display_mux_attach, + .mode_fixup = gpio_display_mux_mode_fixup, + .disable = gpio_display_mux_disable, + .post_disable = gpio_display_mux_post_disable, + .mode_set = gpio_display_mux_mode_set, + .pre_enable = gpio_display_mux_pre_enable, + .enable = gpio_display_mux_enable, +}; + +static int gpio_display_mux_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct gpio_display_mux *gpio_display_mux; + struct device_node *port, *ep, *remote; + int ret; + u32 reg; + + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), + GFP_KERNEL); + if (!gpio_display_mux) + return -ENOMEM; + + platform_set_drvdata(pdev, gpio_display_mux); + gpio_display_mux->dev = &pdev->dev; + + gpio_display_mux->bridge.of_node = dev->of_node; + + gpio_display_mux->gpiod_detect = + devm_gpiod_get(dev, "detect", GPIOD_IN); + if (IS_ERR(gpio_display_mux->gpiod_detect)) + return PTR_ERR(gpio_display_mux->gpiod_detect); + + gpio_display_mux->detect_irq = + gpiod_to_irq(gpio_display_mux->gpiod_detect); + if (gpio_display_mux->detect_irq < 0) { + dev_err(dev, "Failed to get output irq %d\n", + gpio_display_mux->detect_irq); + return -ENODEV; + } + + port = of_graph_get_port_by_id(dev->of_node, 1); + if (!port) { + dev_err(dev, "Missing output port node\n"); + return -EINVAL; + } + + for_each_child_of_node(port, ep) { + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { + of_node_put(ep); + continue; + } + + if (of_property_read_u32(ep, "reg", ®) < 0 || + reg >= ARRAY_SIZE(gpio_display_mux->next)) { + dev_err(dev, + "Missing/invalid reg property for endpoint %s\n", + ep->full_name); + of_node_put(ep); + of_node_put(port); + return -EINVAL; + } + + remote = of_graph_get_remote_port_parent(ep); + if (!remote) { + dev_err(dev, + "Missing connector/bridge node for endpoint %s\n", + ep->full_name); + of_node_put(ep); + of_node_put(port); + return -EINVAL; + } + of_node_put(ep); + + if (of_device_is_compatible(remote, "hdmi-connector")) { + of_node_put(remote); + continue; + } + + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); + if (!gpio_display_mux->next[reg]) { + dev_err(dev, "Waiting for external bridge %s\n", + remote->name); + of_node_put(remote); + of_node_put(port); + return -EPROBE_DEFER; + } + + of_node_put(remote); + } + of_node_put(port); + + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; + drm_bridge_add(&gpio_display_mux->bridge); + + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, + NULL, + gpio_display_mux_det_threaded_handler, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | + IRQF_ONESHOT, + "gpio-display-mux-det", gpio_display_mux); + if (ret) { + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); + goto err_bridge_remove; + } + + return 0; + +err_bridge_remove: + drm_bridge_remove(&gpio_display_mux->bridge); + + return ret; +} + +static int gpio_display_mux_remove(struct platform_device *pdev) +{ + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); + + drm_bridge_remove(&gpio_display_mux->bridge); + + return 0; +} + +static const struct of_device_id gpio_display_mux_match[] = { + { .compatible = "gpio-display-mux", }, + {}, +}; + +struct platform_driver gpio_display_mux_driver = { + .probe = gpio_display_mux_probe, + .remove = gpio_display_mux_remove, + .driver = { + .name = "gpio-display-mux", + .of_match_table = gpio_display_mux_match, + }, +}; + +module_platform_driver(gpio_display_mux_driver); + +MODULE_DESCRIPTION("GPIO-controlled display mux"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.525.g8f36a354ae-goog ^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver @ 2019-12-11 6:19 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-11 6:19 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King From: Nicolas Boichat <drinkcat@chromium.org> This driver supports single input, 2 output display mux (e.g. HDMI mux), that provide its status via a GPIO. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ 3 files changed, 317 insertions(+) create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 1f3fc6bec842..4734f6993858 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC Support for non-programmable RGB to VGA DAC bridges, such as ADI ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. +config DRM_GENERIC_GPIO_MUX + tristate "Generic GPIO-controlled mux" + depends on OF + select DRM_KMS_HELPER + ---help--- + This bridge driver models a GPIO-controlled display mux with one + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output + is active, reports it as a GPIO, and the driver redirects calls to the + appropriate downstream bridge (if any). + config DRM_LVDS_ENCODER tristate "Transparent parallel to LVDS encoder support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 7a1e0ec032e6..1c0c92667ac4 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c new file mode 100644 index 000000000000..ba08321dcc17 --- /dev/null +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c @@ -0,0 +1,306 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Generic gpio mux bridge driver + * + * Copyright 2016 Google LLC + */ + + +#include <linux/gpio.h> +#include <linux/interrupt.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/of_graph.h> +#include <drm/drm_bridge.h> +#include <drm/drm_crtc_helper.h> +#include <drm/drm_probe_helper.h> + +struct gpio_display_mux { + struct device *dev; + + struct gpio_desc *gpiod_detect; + int detect_irq; + + struct drm_bridge bridge; + + struct drm_bridge *next[2]; +}; + +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( + struct drm_bridge *bridge) +{ + return container_of(bridge, struct gpio_display_mux, bridge); +} + +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) +{ + struct gpio_display_mux *gpio_display_mux = data; + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); + + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); + + if (gpio_display_mux->bridge.dev) + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); + + return IRQ_HANDLED; +} + +static int gpio_display_mux_attach(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next) + next->encoder = bridge->encoder; + } + + return 0; +} + +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + int active; + struct drm_bridge *next; + + active = gpiod_get_value(gpio_display_mux->gpiod_detect); + next = gpio_display_mux->next[active]; + + if (next && next->funcs->mode_fixup) + return next->funcs->mode_fixup(next, mode, adjusted_mode); + else + return true; +} + +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, + struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + int active; + struct drm_bridge *next; + + active = gpiod_get_value(gpio_display_mux->gpiod_detect); + next = gpio_display_mux->next[active]; + + if (next && next->funcs->mode_set) + next->funcs->mode_set(next, mode, adjusted_mode); +} + +/** + * Since this driver _reacts_ to mux changes, we need to make sure all + * downstream bridges are pre-enabled. + */ +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->pre_enable) + next->funcs->pre_enable(next); + } +} + +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->post_disable) + next->funcs->post_disable(next); + } +} + +/** + * In an ideal mux driver, only the currently selected bridge should be enabled. + * For the sake of simplicity, we just just enable/disable all downstream + * bridges at the same time. + */ +static void gpio_display_mux_enable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->enable) + next->funcs->enable(next); + } +} + +static void gpio_display_mux_disable(struct drm_bridge *bridge) +{ + struct gpio_display_mux *gpio_display_mux = + bridge_to_gpio_display_mux(bridge); + struct drm_bridge *next; + int i; + + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { + next = gpio_display_mux->next[i]; + if (next && next->funcs->disable) + next->funcs->disable(next); + } +} + +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { + .attach = gpio_display_mux_attach, + .mode_fixup = gpio_display_mux_mode_fixup, + .disable = gpio_display_mux_disable, + .post_disable = gpio_display_mux_post_disable, + .mode_set = gpio_display_mux_mode_set, + .pre_enable = gpio_display_mux_pre_enable, + .enable = gpio_display_mux_enable, +}; + +static int gpio_display_mux_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct gpio_display_mux *gpio_display_mux; + struct device_node *port, *ep, *remote; + int ret; + u32 reg; + + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), + GFP_KERNEL); + if (!gpio_display_mux) + return -ENOMEM; + + platform_set_drvdata(pdev, gpio_display_mux); + gpio_display_mux->dev = &pdev->dev; + + gpio_display_mux->bridge.of_node = dev->of_node; + + gpio_display_mux->gpiod_detect = + devm_gpiod_get(dev, "detect", GPIOD_IN); + if (IS_ERR(gpio_display_mux->gpiod_detect)) + return PTR_ERR(gpio_display_mux->gpiod_detect); + + gpio_display_mux->detect_irq = + gpiod_to_irq(gpio_display_mux->gpiod_detect); + if (gpio_display_mux->detect_irq < 0) { + dev_err(dev, "Failed to get output irq %d\n", + gpio_display_mux->detect_irq); + return -ENODEV; + } + + port = of_graph_get_port_by_id(dev->of_node, 1); + if (!port) { + dev_err(dev, "Missing output port node\n"); + return -EINVAL; + } + + for_each_child_of_node(port, ep) { + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { + of_node_put(ep); + continue; + } + + if (of_property_read_u32(ep, "reg", ®) < 0 || + reg >= ARRAY_SIZE(gpio_display_mux->next)) { + dev_err(dev, + "Missing/invalid reg property for endpoint %s\n", + ep->full_name); + of_node_put(ep); + of_node_put(port); + return -EINVAL; + } + + remote = of_graph_get_remote_port_parent(ep); + if (!remote) { + dev_err(dev, + "Missing connector/bridge node for endpoint %s\n", + ep->full_name); + of_node_put(ep); + of_node_put(port); + return -EINVAL; + } + of_node_put(ep); + + if (of_device_is_compatible(remote, "hdmi-connector")) { + of_node_put(remote); + continue; + } + + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); + if (!gpio_display_mux->next[reg]) { + dev_err(dev, "Waiting for external bridge %s\n", + remote->name); + of_node_put(remote); + of_node_put(port); + return -EPROBE_DEFER; + } + + of_node_put(remote); + } + of_node_put(port); + + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; + drm_bridge_add(&gpio_display_mux->bridge); + + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, + NULL, + gpio_display_mux_det_threaded_handler, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | + IRQF_ONESHOT, + "gpio-display-mux-det", gpio_display_mux); + if (ret) { + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); + goto err_bridge_remove; + } + + return 0; + +err_bridge_remove: + drm_bridge_remove(&gpio_display_mux->bridge); + + return ret; +} + +static int gpio_display_mux_remove(struct platform_device *pdev) +{ + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); + + drm_bridge_remove(&gpio_display_mux->bridge); + + return 0; +} + +static const struct of_device_id gpio_display_mux_match[] = { + { .compatible = "gpio-display-mux", }, + {}, +}; + +struct platform_driver gpio_display_mux_driver = { + .probe = gpio_display_mux_probe, + .remove = gpio_display_mux_remove, + .driver = { + .name = "gpio-display-mux", + .of_match_table = gpio_display_mux_match, + }, +}; + +module_platform_driver(gpio_display_mux_driver); + +MODULE_DESCRIPTION("GPIO-controlled display mux"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.525.g8f36a354ae-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-12 11:54 ` Enric Balletbo i Serra -1 siblings, 0 replies; 51+ messages in thread From: Enric Balletbo i Serra @ 2019-12-12 11:54 UTC (permalink / raw) To: Hsin-Yi Wang, dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, p.zabel, Matthias Brugger, Russell King Hi Hsin-Yi, On 11/12/19 7:19, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > This driver supports single input, 2 output display mux (e.g. > HDMI mux), that provide its status via a GPIO. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> I'll let drm maintainers comment on this but if that's the way to go you can add my: Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Only one issue that needs to be solved in next version, see below. > --- > drivers/gpu/drm/bridge/Kconfig | 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > 3 files changed, 317 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 1f3fc6bec842..4734f6993858 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > Support for non-programmable RGB to VGA DAC bridges, such as ADI > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > +config DRM_GENERIC_GPIO_MUX > + tristate "Generic GPIO-controlled mux" > + depends on OF > + select DRM_KMS_HELPER > + ---help--- > + This bridge driver models a GPIO-controlled display mux with one > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > + is active, reports it as a GPIO, and the driver redirects calls to the > + appropriate downstream bridge (if any). > + > config DRM_LVDS_ENCODER > tristate "Transparent parallel to LVDS encoder support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 7a1e0ec032e6..1c0c92667ac4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > new file mode 100644 > index 000000000000..ba08321dcc17 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > @@ -0,0 +1,306 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Generic gpio mux bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > + > +#include <linux/gpio.h> > +#include <linux/interrupt.h> > +#include <linux/platform_device.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_gpio.h> > +#include <linux/of_graph.h> > +#include <drm/drm_bridge.h> > +#include <drm/drm_crtc_helper.h> > +#include <drm/drm_probe_helper.h> > + > +struct gpio_display_mux { > + struct device *dev; > + > + struct gpio_desc *gpiod_detect; > + int detect_irq; > + > + struct drm_bridge bridge; > + > + struct drm_bridge *next[2]; > +}; > + > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > + struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct gpio_display_mux, bridge); > +} > + > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > +{ > + struct gpio_display_mux *gpio_display_mux = data; > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > + > + if (gpio_display_mux->bridge.dev) > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > + > + return IRQ_HANDLED; > +} > + > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next) > + next->encoder = bridge->encoder; > + } > + > + return 0; > +} > + > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_fixup) > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > + else > + return true; > +} > + > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) Those two need to be const now. > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_set) > + next->funcs->mode_set(next, mode, adjusted_mode); > +} > + > +/** > + * Since this driver _reacts_ to mux changes, we need to make sure all > + * downstream bridges are pre-enabled. > + */ > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->pre_enable) > + next->funcs->pre_enable(next); > + } > +} > + > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->post_disable) > + next->funcs->post_disable(next); > + } > +} > + > +/** > + * In an ideal mux driver, only the currently selected bridge should be enabled. > + * For the sake of simplicity, we just just enable/disable all downstream > + * bridges at the same time. > + */ > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->enable) > + next->funcs->enable(next); > + } > +} > + > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->disable) > + next->funcs->disable(next); > + } > +} > + > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > + .attach = gpio_display_mux_attach, > + .mode_fixup = gpio_display_mux_mode_fixup, > + .disable = gpio_display_mux_disable, > + .post_disable = gpio_display_mux_post_disable, > + .mode_set = gpio_display_mux_mode_set, > + .pre_enable = gpio_display_mux_pre_enable, > + .enable = gpio_display_mux_enable, > +}; > + > +static int gpio_display_mux_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct gpio_display_mux *gpio_display_mux; > + struct device_node *port, *ep, *remote; > + int ret; > + u32 reg; > + > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > + GFP_KERNEL); > + if (!gpio_display_mux) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, gpio_display_mux); > + gpio_display_mux->dev = &pdev->dev; > + > + gpio_display_mux->bridge.of_node = dev->of_node; > + > + gpio_display_mux->gpiod_detect = > + devm_gpiod_get(dev, "detect", GPIOD_IN); > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > + return PTR_ERR(gpio_display_mux->gpiod_detect); > + > + gpio_display_mux->detect_irq = > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > + if (gpio_display_mux->detect_irq < 0) { > + dev_err(dev, "Failed to get output irq %d\n", > + gpio_display_mux->detect_irq); > + return -ENODEV; > + } > + > + port = of_graph_get_port_by_id(dev->of_node, 1); > + if (!port) { > + dev_err(dev, "Missing output port node\n"); > + return -EINVAL; > + } > + > + for_each_child_of_node(port, ep) { > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > + of_node_put(ep); > + continue; > + } > + > + if (of_property_read_u32(ep, "reg", ®) < 0 || > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > + dev_err(dev, > + "Missing/invalid reg property for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + > + remote = of_graph_get_remote_port_parent(ep); > + if (!remote) { > + dev_err(dev, > + "Missing connector/bridge node for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + of_node_put(ep); > + > + if (of_device_is_compatible(remote, "hdmi-connector")) { > + of_node_put(remote); > + continue; > + } > + > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); > + if (!gpio_display_mux->next[reg]) { > + dev_err(dev, "Waiting for external bridge %s\n", > + remote->name); > + of_node_put(remote); > + of_node_put(port); > + return -EPROBE_DEFER; > + } > + > + of_node_put(remote); > + } > + of_node_put(port); > + > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > + drm_bridge_add(&gpio_display_mux->bridge); > + > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > + NULL, > + gpio_display_mux_det_threaded_handler, > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > + IRQF_ONESHOT, > + "gpio-display-mux-det", gpio_display_mux); > + if (ret) { > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > + goto err_bridge_remove; > + } > + > + return 0; > + > +err_bridge_remove: > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return ret; > +} > + > +static int gpio_display_mux_remove(struct platform_device *pdev) > +{ > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > + > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return 0; > +} > + > +static const struct of_device_id gpio_display_mux_match[] = { > + { .compatible = "gpio-display-mux", }, > + {}, > +}; > + > +struct platform_driver gpio_display_mux_driver = { > + .probe = gpio_display_mux_probe, > + .remove = gpio_display_mux_remove, > + .driver = { > + .name = "gpio-display-mux", > + .of_match_table = gpio_display_mux_match, > + }, > +}; > + > +module_platform_driver(gpio_display_mux_driver); > + > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver @ 2019-12-12 11:54 ` Enric Balletbo i Serra 0 siblings, 0 replies; 51+ messages in thread From: Enric Balletbo i Serra @ 2019-12-12 11:54 UTC (permalink / raw) To: Hsin-Yi Wang, dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Rob Herring, Laurent Pinchart, Matthias Brugger, Russell King Hi Hsin-Yi, On 11/12/19 7:19, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > This driver supports single input, 2 output display mux (e.g. > HDMI mux), that provide its status via a GPIO. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> I'll let drm maintainers comment on this but if that's the way to go you can add my: Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Only one issue that needs to be solved in next version, see below. > --- > drivers/gpu/drm/bridge/Kconfig | 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > 3 files changed, 317 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 1f3fc6bec842..4734f6993858 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > Support for non-programmable RGB to VGA DAC bridges, such as ADI > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > +config DRM_GENERIC_GPIO_MUX > + tristate "Generic GPIO-controlled mux" > + depends on OF > + select DRM_KMS_HELPER > + ---help--- > + This bridge driver models a GPIO-controlled display mux with one > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > + is active, reports it as a GPIO, and the driver redirects calls to the > + appropriate downstream bridge (if any). > + > config DRM_LVDS_ENCODER > tristate "Transparent parallel to LVDS encoder support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 7a1e0ec032e6..1c0c92667ac4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > new file mode 100644 > index 000000000000..ba08321dcc17 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > @@ -0,0 +1,306 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Generic gpio mux bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > + > +#include <linux/gpio.h> > +#include <linux/interrupt.h> > +#include <linux/platform_device.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_gpio.h> > +#include <linux/of_graph.h> > +#include <drm/drm_bridge.h> > +#include <drm/drm_crtc_helper.h> > +#include <drm/drm_probe_helper.h> > + > +struct gpio_display_mux { > + struct device *dev; > + > + struct gpio_desc *gpiod_detect; > + int detect_irq; > + > + struct drm_bridge bridge; > + > + struct drm_bridge *next[2]; > +}; > + > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > + struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct gpio_display_mux, bridge); > +} > + > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > +{ > + struct gpio_display_mux *gpio_display_mux = data; > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > + > + if (gpio_display_mux->bridge.dev) > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > + > + return IRQ_HANDLED; > +} > + > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next) > + next->encoder = bridge->encoder; > + } > + > + return 0; > +} > + > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_fixup) > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > + else > + return true; > +} > + > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) Those two need to be const now. > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_set) > + next->funcs->mode_set(next, mode, adjusted_mode); > +} > + > +/** > + * Since this driver _reacts_ to mux changes, we need to make sure all > + * downstream bridges are pre-enabled. > + */ > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->pre_enable) > + next->funcs->pre_enable(next); > + } > +} > + > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->post_disable) > + next->funcs->post_disable(next); > + } > +} > + > +/** > + * In an ideal mux driver, only the currently selected bridge should be enabled. > + * For the sake of simplicity, we just just enable/disable all downstream > + * bridges at the same time. > + */ > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->enable) > + next->funcs->enable(next); > + } > +} > + > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->disable) > + next->funcs->disable(next); > + } > +} > + > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > + .attach = gpio_display_mux_attach, > + .mode_fixup = gpio_display_mux_mode_fixup, > + .disable = gpio_display_mux_disable, > + .post_disable = gpio_display_mux_post_disable, > + .mode_set = gpio_display_mux_mode_set, > + .pre_enable = gpio_display_mux_pre_enable, > + .enable = gpio_display_mux_enable, > +}; > + > +static int gpio_display_mux_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct gpio_display_mux *gpio_display_mux; > + struct device_node *port, *ep, *remote; > + int ret; > + u32 reg; > + > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > + GFP_KERNEL); > + if (!gpio_display_mux) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, gpio_display_mux); > + gpio_display_mux->dev = &pdev->dev; > + > + gpio_display_mux->bridge.of_node = dev->of_node; > + > + gpio_display_mux->gpiod_detect = > + devm_gpiod_get(dev, "detect", GPIOD_IN); > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > + return PTR_ERR(gpio_display_mux->gpiod_detect); > + > + gpio_display_mux->detect_irq = > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > + if (gpio_display_mux->detect_irq < 0) { > + dev_err(dev, "Failed to get output irq %d\n", > + gpio_display_mux->detect_irq); > + return -ENODEV; > + } > + > + port = of_graph_get_port_by_id(dev->of_node, 1); > + if (!port) { > + dev_err(dev, "Missing output port node\n"); > + return -EINVAL; > + } > + > + for_each_child_of_node(port, ep) { > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > + of_node_put(ep); > + continue; > + } > + > + if (of_property_read_u32(ep, "reg", ®) < 0 || > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > + dev_err(dev, > + "Missing/invalid reg property for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + > + remote = of_graph_get_remote_port_parent(ep); > + if (!remote) { > + dev_err(dev, > + "Missing connector/bridge node for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + of_node_put(ep); > + > + if (of_device_is_compatible(remote, "hdmi-connector")) { > + of_node_put(remote); > + continue; > + } > + > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); > + if (!gpio_display_mux->next[reg]) { > + dev_err(dev, "Waiting for external bridge %s\n", > + remote->name); > + of_node_put(remote); > + of_node_put(port); > + return -EPROBE_DEFER; > + } > + > + of_node_put(remote); > + } > + of_node_put(port); > + > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > + drm_bridge_add(&gpio_display_mux->bridge); > + > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > + NULL, > + gpio_display_mux_det_threaded_handler, > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > + IRQF_ONESHOT, > + "gpio-display-mux-det", gpio_display_mux); > + if (ret) { > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > + goto err_bridge_remove; > + } > + > + return 0; > + > +err_bridge_remove: > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return ret; > +} > + > +static int gpio_display_mux_remove(struct platform_device *pdev) > +{ > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > + > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return 0; > +} > + > +static const struct of_device_id gpio_display_mux_match[] = { > + { .compatible = "gpio-display-mux", }, > + {}, > +}; > + > +struct platform_driver gpio_display_mux_driver = { > + .probe = gpio_display_mux_probe, > + .remove = gpio_display_mux_remove, > + .driver = { > + .name = "gpio-display-mux", > + .of_match_table = gpio_display_mux_match, > + }, > +}; > + > +module_platform_driver(gpio_display_mux_driver); > + > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver 2019-12-11 6:19 ` Hsin-Yi Wang @ 2019-12-13 22:33 ` Laurent Pinchart -1 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-13 22:33 UTC (permalink / raw) To: Hsin-Yi Wang Cc: dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King Hi Hsin-Yi and Nicolas, Thank you for the patch. On Wed, Dec 11, 2019 at 02:19:11PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > This driver supports single input, 2 output display mux (e.g. > HDMI mux), that provide its status via a GPIO. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > drivers/gpu/drm/bridge/Kconfig | 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > 3 files changed, 317 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 1f3fc6bec842..4734f6993858 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > Support for non-programmable RGB to VGA DAC bridges, such as ADI > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > +config DRM_GENERIC_GPIO_MUX > + tristate "Generic GPIO-controlled mux" > + depends on OF > + select DRM_KMS_HELPER > + ---help--- > + This bridge driver models a GPIO-controlled display mux with one > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > + is active, reports it as a GPIO, and the driver redirects calls to the > + appropriate downstream bridge (if any). My understanding of the issue was that the mux was controllable by a GPIO, not that the GPIO would report its status. This changes a few things. How is the mux controlled then ? > config DRM_LVDS_ENCODER > tristate "Transparent parallel to LVDS encoder support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 7a1e0ec032e6..1c0c92667ac4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > new file mode 100644 > index 000000000000..ba08321dcc17 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > @@ -0,0 +1,306 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Generic gpio mux bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > + One blank line is enough. > +#include <linux/gpio.h> > +#include <linux/interrupt.h> > +#include <linux/platform_device.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_gpio.h> > +#include <linux/of_graph.h> Could you please sort these headers alphabetically ? > +#include <drm/drm_bridge.h> > +#include <drm/drm_crtc_helper.h> > +#include <drm/drm_probe_helper.h> > + > +struct gpio_display_mux { > + struct device *dev; > + > + struct gpio_desc *gpiod_detect; > + int detect_irq; > + > + struct drm_bridge bridge; > + > + struct drm_bridge *next[2]; > +}; > + > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > + struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct gpio_display_mux, bridge); > +} > + > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > +{ > + struct gpio_display_mux *gpio_display_mux = data; gpio_display_mux is a long variable name. You can shorten it to mux here and below. > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > + > + if (gpio_display_mux->bridge.dev) > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > + > + return IRQ_HANDLED; > +} > + > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; i never takes negative values, you can make it an unsigned int. > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next) > + next->encoder = bridge->encoder; > + } > + > + return 0; > +} > + > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); What if the value of the GPIO changes between, let's say, this operation and gpio_display_mux_mode_set() ? This doesn't seem very stable to me. DRM/KMS hasn't been designed to have the output routing configured externally without any control from the drivers. > + next = gpio_display_mux->next[active]; This will crash if gpiod_get_value() returns an error. Same for the other functions below. > + > + if (next && next->funcs->mode_fixup) > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > + else > + return true; > +} > + > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_set) > + next->funcs->mode_set(next, mode, adjusted_mode); > +} > + > +/** This isn't kerneldoc, the comment should start with /*. Same comment below. > + * Since this driver _reacts_ to mux changes, we need to make sure all > + * downstream bridges are pre-enabled. I'm afraid the problem scope seems bigger than I initially anticipated :-( We're in the hack territory here, and I think we need to search for a proper solution. We need to start with a detailed description of the hardware and the use cases. > + */ > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->pre_enable) > + next->funcs->pre_enable(next); > + } > +} > + > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->post_disable) > + next->funcs->post_disable(next); > + } > +} > + > +/** > + * In an ideal mux driver, only the currently selected bridge should be enabled. > + * For the sake of simplicity, we just just enable/disable all downstream > + * bridges at the same time. > + */ > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->enable) > + next->funcs->enable(next); > + } > +} > + > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->disable) > + next->funcs->disable(next); > + } > +} > + > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > + .attach = gpio_display_mux_attach, > + .mode_fixup = gpio_display_mux_mode_fixup, > + .disable = gpio_display_mux_disable, > + .post_disable = gpio_display_mux_post_disable, > + .mode_set = gpio_display_mux_mode_set, > + .pre_enable = gpio_display_mux_pre_enable, > + .enable = gpio_display_mux_enable, > +}; > + > +static int gpio_display_mux_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct gpio_display_mux *gpio_display_mux; > + struct device_node *port, *ep, *remote; > + int ret; > + u32 reg; > + > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > + GFP_KERNEL); > + if (!gpio_display_mux) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, gpio_display_mux); > + gpio_display_mux->dev = &pdev->dev; > + > + gpio_display_mux->bridge.of_node = dev->of_node; > + > + gpio_display_mux->gpiod_detect = > + devm_gpiod_get(dev, "detect", GPIOD_IN); > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > + return PTR_ERR(gpio_display_mux->gpiod_detect); > + > + gpio_display_mux->detect_irq = > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > + if (gpio_display_mux->detect_irq < 0) { > + dev_err(dev, "Failed to get output irq %d\n", > + gpio_display_mux->detect_irq); > + return -ENODEV; > + } > + > + port = of_graph_get_port_by_id(dev->of_node, 1); > + if (!port) { > + dev_err(dev, "Missing output port node\n"); > + return -EINVAL; > + } > + > + for_each_child_of_node(port, ep) { > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > + of_node_put(ep); > + continue; > + } > + > + if (of_property_read_u32(ep, "reg", ®) < 0 || > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > + dev_err(dev, > + "Missing/invalid reg property for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + > + remote = of_graph_get_remote_port_parent(ep); > + if (!remote) { > + dev_err(dev, > + "Missing connector/bridge node for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + of_node_put(ep); > + > + if (of_device_is_compatible(remote, "hdmi-connector")) { > + of_node_put(remote); > + continue; > + } This special case makes me think that something is wrong. I believe the connector driver from https://patchwork.freedesktop.org/patch/344477/?series=63328&rev=59 could help. > + > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); What if the connected device is a panel and not a bridge ? > + if (!gpio_display_mux->next[reg]) { > + dev_err(dev, "Waiting for external bridge %s\n", > + remote->name); > + of_node_put(remote); > + of_node_put(port); > + return -EPROBE_DEFER; > + } > + > + of_node_put(remote); > + } > + of_node_put(port); > + > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > + drm_bridge_add(&gpio_display_mux->bridge); > + > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > + NULL, > + gpio_display_mux_det_threaded_handler, > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > + IRQF_ONESHOT, > + "gpio-display-mux-det", gpio_display_mux); > + if (ret) { > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > + goto err_bridge_remove; > + } > + > + return 0; > + > +err_bridge_remove: > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return ret; > +} > + > +static int gpio_display_mux_remove(struct platform_device *pdev) > +{ > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > + > + drm_bridge_remove(&gpio_display_mux->bridge); If the GPIO IRQ is triggered here you'll have trouble. You need to disable the IRQ, or free it, before removing the bridge. > + > + return 0; > +} > + > +static const struct of_device_id gpio_display_mux_match[] = { > + { .compatible = "gpio-display-mux", }, > + {}, > +}; > + > +struct platform_driver gpio_display_mux_driver = { > + .probe = gpio_display_mux_probe, > + .remove = gpio_display_mux_remove, > + .driver = { > + .name = "gpio-display-mux", > + .of_match_table = gpio_display_mux_match, > + }, > +}; > + > +module_platform_driver(gpio_display_mux_driver); > + > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver @ 2019-12-13 22:33 ` Laurent Pinchart 0 siblings, 0 replies; 51+ messages in thread From: Laurent Pinchart @ 2019-12-13 22:33 UTC (permalink / raw) To: Hsin-Yi Wang Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, dri-devel, Rob Herring, Matthias Brugger, Enric Balletbo i Serra, Russell King Hi Hsin-Yi and Nicolas, Thank you for the patch. On Wed, Dec 11, 2019 at 02:19:11PM +0800, Hsin-Yi Wang wrote: > From: Nicolas Boichat <drinkcat@chromium.org> > > This driver supports single input, 2 output display mux (e.g. > HDMI mux), that provide its status via a GPIO. > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > drivers/gpu/drm/bridge/Kconfig | 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > 3 files changed, 317 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 1f3fc6bec842..4734f6993858 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > Support for non-programmable RGB to VGA DAC bridges, such as ADI > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > +config DRM_GENERIC_GPIO_MUX > + tristate "Generic GPIO-controlled mux" > + depends on OF > + select DRM_KMS_HELPER > + ---help--- > + This bridge driver models a GPIO-controlled display mux with one > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > + is active, reports it as a GPIO, and the driver redirects calls to the > + appropriate downstream bridge (if any). My understanding of the issue was that the mux was controllable by a GPIO, not that the GPIO would report its status. This changes a few things. How is the mux controlled then ? > config DRM_LVDS_ENCODER > tristate "Transparent parallel to LVDS encoder support" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 7a1e0ec032e6..1c0c92667ac4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > new file mode 100644 > index 000000000000..ba08321dcc17 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > @@ -0,0 +1,306 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Generic gpio mux bridge driver > + * > + * Copyright 2016 Google LLC > + */ > + > + One blank line is enough. > +#include <linux/gpio.h> > +#include <linux/interrupt.h> > +#include <linux/platform_device.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_gpio.h> > +#include <linux/of_graph.h> Could you please sort these headers alphabetically ? > +#include <drm/drm_bridge.h> > +#include <drm/drm_crtc_helper.h> > +#include <drm/drm_probe_helper.h> > + > +struct gpio_display_mux { > + struct device *dev; > + > + struct gpio_desc *gpiod_detect; > + int detect_irq; > + > + struct drm_bridge bridge; > + > + struct drm_bridge *next[2]; > +}; > + > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > + struct drm_bridge *bridge) > +{ > + return container_of(bridge, struct gpio_display_mux, bridge); > +} > + > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > +{ > + struct gpio_display_mux *gpio_display_mux = data; gpio_display_mux is a long variable name. You can shorten it to mux here and below. > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > + > + if (gpio_display_mux->bridge.dev) > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > + > + return IRQ_HANDLED; > +} > + > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; i never takes negative values, you can make it an unsigned int. > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next) > + next->encoder = bridge->encoder; > + } > + > + return 0; > +} > + > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > + const struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); What if the value of the GPIO changes between, let's say, this operation and gpio_display_mux_mode_set() ? This doesn't seem very stable to me. DRM/KMS hasn't been designed to have the output routing configured externally without any control from the drivers. > + next = gpio_display_mux->next[active]; This will crash if gpiod_get_value() returns an error. Same for the other functions below. > + > + if (next && next->funcs->mode_fixup) > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > + else > + return true; > +} > + > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > + struct drm_display_mode *mode, > + struct drm_display_mode *adjusted_mode) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + int active; > + struct drm_bridge *next; > + > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > + next = gpio_display_mux->next[active]; > + > + if (next && next->funcs->mode_set) > + next->funcs->mode_set(next, mode, adjusted_mode); > +} > + > +/** This isn't kerneldoc, the comment should start with /*. Same comment below. > + * Since this driver _reacts_ to mux changes, we need to make sure all > + * downstream bridges are pre-enabled. I'm afraid the problem scope seems bigger than I initially anticipated :-( We're in the hack territory here, and I think we need to search for a proper solution. We need to start with a detailed description of the hardware and the use cases. > + */ > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->pre_enable) > + next->funcs->pre_enable(next); > + } > +} > + > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->post_disable) > + next->funcs->post_disable(next); > + } > +} > + > +/** > + * In an ideal mux driver, only the currently selected bridge should be enabled. > + * For the sake of simplicity, we just just enable/disable all downstream > + * bridges at the same time. > + */ > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->enable) > + next->funcs->enable(next); > + } > +} > + > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > +{ > + struct gpio_display_mux *gpio_display_mux = > + bridge_to_gpio_display_mux(bridge); > + struct drm_bridge *next; > + int i; > + > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > + next = gpio_display_mux->next[i]; > + if (next && next->funcs->disable) > + next->funcs->disable(next); > + } > +} > + > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > + .attach = gpio_display_mux_attach, > + .mode_fixup = gpio_display_mux_mode_fixup, > + .disable = gpio_display_mux_disable, > + .post_disable = gpio_display_mux_post_disable, > + .mode_set = gpio_display_mux_mode_set, > + .pre_enable = gpio_display_mux_pre_enable, > + .enable = gpio_display_mux_enable, > +}; > + > +static int gpio_display_mux_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct gpio_display_mux *gpio_display_mux; > + struct device_node *port, *ep, *remote; > + int ret; > + u32 reg; > + > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > + GFP_KERNEL); > + if (!gpio_display_mux) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, gpio_display_mux); > + gpio_display_mux->dev = &pdev->dev; > + > + gpio_display_mux->bridge.of_node = dev->of_node; > + > + gpio_display_mux->gpiod_detect = > + devm_gpiod_get(dev, "detect", GPIOD_IN); > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > + return PTR_ERR(gpio_display_mux->gpiod_detect); > + > + gpio_display_mux->detect_irq = > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > + if (gpio_display_mux->detect_irq < 0) { > + dev_err(dev, "Failed to get output irq %d\n", > + gpio_display_mux->detect_irq); > + return -ENODEV; > + } > + > + port = of_graph_get_port_by_id(dev->of_node, 1); > + if (!port) { > + dev_err(dev, "Missing output port node\n"); > + return -EINVAL; > + } > + > + for_each_child_of_node(port, ep) { > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > + of_node_put(ep); > + continue; > + } > + > + if (of_property_read_u32(ep, "reg", ®) < 0 || > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > + dev_err(dev, > + "Missing/invalid reg property for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + > + remote = of_graph_get_remote_port_parent(ep); > + if (!remote) { > + dev_err(dev, > + "Missing connector/bridge node for endpoint %s\n", > + ep->full_name); > + of_node_put(ep); > + of_node_put(port); > + return -EINVAL; > + } > + of_node_put(ep); > + > + if (of_device_is_compatible(remote, "hdmi-connector")) { > + of_node_put(remote); > + continue; > + } This special case makes me think that something is wrong. I believe the connector driver from https://patchwork.freedesktop.org/patch/344477/?series=63328&rev=59 could help. > + > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); What if the connected device is a panel and not a bridge ? > + if (!gpio_display_mux->next[reg]) { > + dev_err(dev, "Waiting for external bridge %s\n", > + remote->name); > + of_node_put(remote); > + of_node_put(port); > + return -EPROBE_DEFER; > + } > + > + of_node_put(remote); > + } > + of_node_put(port); > + > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > + drm_bridge_add(&gpio_display_mux->bridge); > + > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > + NULL, > + gpio_display_mux_det_threaded_handler, > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > + IRQF_ONESHOT, > + "gpio-display-mux-det", gpio_display_mux); > + if (ret) { > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > + goto err_bridge_remove; > + } > + > + return 0; > + > +err_bridge_remove: > + drm_bridge_remove(&gpio_display_mux->bridge); > + > + return ret; > +} > + > +static int gpio_display_mux_remove(struct platform_device *pdev) > +{ > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > + > + drm_bridge_remove(&gpio_display_mux->bridge); If the GPIO IRQ is triggered here you'll have trouble. You need to disable the IRQ, or free it, before removing the bridge. > + > + return 0; > +} > + > +static const struct of_device_id gpio_display_mux_match[] = { > + { .compatible = "gpio-display-mux", }, > + {}, > +}; > + > +struct platform_driver gpio_display_mux_driver = { > + .probe = gpio_display_mux_probe, > + .remove = gpio_display_mux_remove, > + .driver = { > + .name = "gpio-display-mux", > + .of_match_table = gpio_display_mux_match, > + }, > +}; > + > +module_platform_driver(gpio_display_mux_driver); > + > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > +MODULE_LICENSE("GPL v2"); -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver 2019-12-13 22:33 ` Laurent Pinchart @ 2019-12-16 8:44 ` Hsin-Yi Wang -1 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 8:44 UTC (permalink / raw) To: Laurent Pinchart Cc: dri-devel, David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, Devicetree List, lkml, Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec, Philipp Zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King On Sat, Dec 14, 2019 at 6:33 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi and Nicolas, > > Thank you for the patch. > > On Wed, Dec 11, 2019 at 02:19:11PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > This driver supports single input, 2 output display mux (e.g. > > HDMI mux), that provide its status via a GPIO. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > drivers/gpu/drm/bridge/Kconfig | 10 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > > 3 files changed, 317 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 1f3fc6bec842..4734f6993858 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > > Support for non-programmable RGB to VGA DAC bridges, such as ADI > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > > > +config DRM_GENERIC_GPIO_MUX > > + tristate "Generic GPIO-controlled mux" > > + depends on OF > > + select DRM_KMS_HELPER > > + ---help--- > > + This bridge driver models a GPIO-controlled display mux with one > > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > > + is active, reports it as a GPIO, and the driver redirects calls to the > > + appropriate downstream bridge (if any). > > My understanding of the issue was that the mux was controllable by a > GPIO, not that the GPIO would report its status. This changes a few > things. How is the mux controlled then ? > There's a hardware that would control the gpio to active if HDMI is plugged. The mux driver registered a irq for this gpio, and handle cases depending on gpio status. > > config DRM_LVDS_ENCODER > > tristate "Transparent parallel to LVDS encoder support" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > index 7a1e0ec032e6..1c0c92667ac4 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > > new file mode 100644 > > index 000000000000..ba08321dcc17 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > > @@ -0,0 +1,306 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Generic gpio mux bridge driver > > + * > > + * Copyright 2016 Google LLC > > + */ > > + > > + > > One blank line is enough. > > > +#include <linux/gpio.h> > > +#include <linux/interrupt.h> > > +#include <linux/platform_device.h> > > +#include <linux/module.h> > > +#include <linux/of.h> > > +#include <linux/of_gpio.h> > > +#include <linux/of_graph.h> > > Could you please sort these headers alphabetically ? > > > +#include <drm/drm_bridge.h> > > +#include <drm/drm_crtc_helper.h> > > +#include <drm/drm_probe_helper.h> > > + > > +struct gpio_display_mux { > > + struct device *dev; > > + > > + struct gpio_desc *gpiod_detect; > > + int detect_irq; > > + > > + struct drm_bridge bridge; > > + > > + struct drm_bridge *next[2]; > > +}; > > + > > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > > + struct drm_bridge *bridge) > > +{ > > + return container_of(bridge, struct gpio_display_mux, bridge); > > +} > > + > > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > > +{ > > + struct gpio_display_mux *gpio_display_mux = data; > > gpio_display_mux is a long variable name. You can shorten it to mux here > and below. > > > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > + > > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > > + > > + if (gpio_display_mux->bridge.dev) > > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > > + > > + return IRQ_HANDLED; > > +} > > + > > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > i never takes negative values, you can make it an unsigned int. > > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next) > > + next->encoder = bridge->encoder; > > + } > > + > > + return 0; > > +} > > + > > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + int active; > > + struct drm_bridge *next; > > + > > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > What if the value of the GPIO changes between, let's say, this operation > and gpio_display_mux_mode_set() ? This doesn't seem very stable to me. > DRM/KMS hasn't been designed to have the output routing configured > externally without any control from the drivers. > We will fix it to store the gpio status in struct instead of reading in each bridge functions. Only in irq handler function the gpio status will be updated. > > + next = gpio_display_mux->next[active]; > > This will crash if gpiod_get_value() returns an error. Same for the > other functions below. > Will add check for this in irq handler function. > > + > > + if (next && next->funcs->mode_fixup) > > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > > + else > > + return true; > > +} > > + > > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > > + struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + int active; > > + struct drm_bridge *next; > > + > > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > + next = gpio_display_mux->next[active]; > > + > > + if (next && next->funcs->mode_set) > > + next->funcs->mode_set(next, mode, adjusted_mode); > > +} > > + > > +/** > > This isn't kerneldoc, the comment should start with /*. Same comment > below. > > > + * Since this driver _reacts_ to mux changes, we need to make sure all > > + * downstream bridges are pre-enabled. > > I'm afraid the problem scope seems bigger than I initially anticipated > :-( We're in the hack territory here, and I think we need to search for > a proper solution. We need to start with a detailed description of the > hardware and the use cases. > We are considering making this mux driver mt8173 oak board specific, since it seems that only this board have such design and we only have this board for testing. If so, we also only need mode_fixup bridge function. And the endpoint is anx7688 and hdmi connector. What do you think? > > + */ > > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->pre_enable) > > + next->funcs->pre_enable(next); > > + } > > +} > > + > > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->post_disable) > > + next->funcs->post_disable(next); > > + } > > +} > > + > > +/** > > + * In an ideal mux driver, only the currently selected bridge should be enabled. > > + * For the sake of simplicity, we just just enable/disable all downstream > > + * bridges at the same time. > > + */ > > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->enable) > > + next->funcs->enable(next); > > + } > > +} > > + > > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->disable) > > + next->funcs->disable(next); > > + } > > +} > > + > > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > > + .attach = gpio_display_mux_attach, > > + .mode_fixup = gpio_display_mux_mode_fixup, > > + .disable = gpio_display_mux_disable, > > + .post_disable = gpio_display_mux_post_disable, > > + .mode_set = gpio_display_mux_mode_set, > > + .pre_enable = gpio_display_mux_pre_enable, > > + .enable = gpio_display_mux_enable, > > +}; > > + > > +static int gpio_display_mux_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct gpio_display_mux *gpio_display_mux; > > + struct device_node *port, *ep, *remote; > > + int ret; > > + u32 reg; > > + > > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > > + GFP_KERNEL); > > + if (!gpio_display_mux) > > + return -ENOMEM; > > + > > + platform_set_drvdata(pdev, gpio_display_mux); > > + gpio_display_mux->dev = &pdev->dev; > > + > > + gpio_display_mux->bridge.of_node = dev->of_node; > > + > > + gpio_display_mux->gpiod_detect = > > + devm_gpiod_get(dev, "detect", GPIOD_IN); > > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > > + return PTR_ERR(gpio_display_mux->gpiod_detect); > > + > > + gpio_display_mux->detect_irq = > > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > > + if (gpio_display_mux->detect_irq < 0) { > > + dev_err(dev, "Failed to get output irq %d\n", > > + gpio_display_mux->detect_irq); > > + return -ENODEV; > > + } > > + > > + port = of_graph_get_port_by_id(dev->of_node, 1); > > + if (!port) { > > + dev_err(dev, "Missing output port node\n"); > > + return -EINVAL; > > + } > > + > > + for_each_child_of_node(port, ep) { > > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > > + of_node_put(ep); > > + continue; > > + } > > + > > + if (of_property_read_u32(ep, "reg", ®) < 0 || > > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > > + dev_err(dev, > > + "Missing/invalid reg property for endpoint %s\n", > > + ep->full_name); > > + of_node_put(ep); > > + of_node_put(port); > > + return -EINVAL; > > + } > > + > > + remote = of_graph_get_remote_port_parent(ep); > > + if (!remote) { > > + dev_err(dev, > > + "Missing connector/bridge node for endpoint %s\n", > > + ep->full_name); > > + of_node_put(ep); > > + of_node_put(port); > > + return -EINVAL; > > + } > > + of_node_put(ep); > > + > > + if (of_device_is_compatible(remote, "hdmi-connector")) { > > + of_node_put(remote); > > + continue; > > + } > > This special case makes me think that something is wrong. I believe the > connector driver from > https://patchwork.freedesktop.org/patch/344477/?series=63328&rev=59 > could help. > Thanks for pointing this, we can remove the special case (hdmi) handling here. > > + > > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); > > What if the connected device is a panel and not a bridge ? > If this is oak specific, then we don't need to handle panel case. > > + if (!gpio_display_mux->next[reg]) { > > + dev_err(dev, "Waiting for external bridge %s\n", > > + remote->name); > > + of_node_put(remote); > > + of_node_put(port); > > + return -EPROBE_DEFER; > > + } > > + > > + of_node_put(remote); > > + } > > + of_node_put(port); > > + > > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > > + drm_bridge_add(&gpio_display_mux->bridge); > > + > > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > > + NULL, > > + gpio_display_mux_det_threaded_handler, > > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > > + IRQF_ONESHOT, > > + "gpio-display-mux-det", gpio_display_mux); > > + if (ret) { > > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > > + goto err_bridge_remove; > > + } > > + > > + return 0; > > + > > +err_bridge_remove: > > + drm_bridge_remove(&gpio_display_mux->bridge); > > + > > + return ret; > > +} > > + > > +static int gpio_display_mux_remove(struct platform_device *pdev) > > +{ > > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > > + > > + drm_bridge_remove(&gpio_display_mux->bridge); > > If the GPIO IRQ is triggered here you'll have trouble. You need to > disable the IRQ, or free it, before removing the bridge. > Will fix this. Thanks > > + > > + return 0; > > +} > > + > > +static const struct of_device_id gpio_display_mux_match[] = { > > + { .compatible = "gpio-display-mux", }, > > + {}, > > +}; > > + > > +struct platform_driver gpio_display_mux_driver = { > > + .probe = gpio_display_mux_probe, > > + .remove = gpio_display_mux_remove, > > + .driver = { > > + .name = "gpio-display-mux", > > + .of_match_table = gpio_display_mux_match, > > + }, > > +}; > > + > > +module_platform_driver(gpio_display_mux_driver); > > + > > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > > +MODULE_LICENSE("GPL v2"); > > -- > Regards, > > Laurent Pinchart ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver @ 2019-12-16 8:44 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-16 8:44 UTC (permalink / raw) To: Laurent Pinchart Cc: Mark Rutland, Devicetree List, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, lkml, dri-devel, Rob Herring, Matthias Brugger, Enric Balletbo i Serra, Russell King On Sat, Dec 14, 2019 at 6:33 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi and Nicolas, > > Thank you for the patch. > > On Wed, Dec 11, 2019 at 02:19:11PM +0800, Hsin-Yi Wang wrote: > > From: Nicolas Boichat <drinkcat@chromium.org> > > > > This driver supports single input, 2 output display mux (e.g. > > HDMI mux), that provide its status via a GPIO. > > > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > > --- > > drivers/gpu/drm/bridge/Kconfig | 10 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++++++++++++++++++++++ > > 3 files changed, 317 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index 1f3fc6bec842..4734f6993858 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC > > Support for non-programmable RGB to VGA DAC bridges, such as ADI > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs. > > > > +config DRM_GENERIC_GPIO_MUX > > + tristate "Generic GPIO-controlled mux" > > + depends on OF > > + select DRM_KMS_HELPER > > + ---help--- > > + This bridge driver models a GPIO-controlled display mux with one > > + input, 2 outputs (e.g. an HDMI mux). The hardware decides which output > > + is active, reports it as a GPIO, and the driver redirects calls to the > > + appropriate downstream bridge (if any). > > My understanding of the issue was that the mux was controllable by a > GPIO, not that the GPIO would report its status. This changes a few > things. How is the mux controlled then ? > There's a hardware that would control the gpio to active if HDMI is plugged. The mux driver registered a irq for this gpio, and handle cases depending on gpio status. > > config DRM_LVDS_ENCODER > > tristate "Transparent parallel to LVDS encoder support" > > depends on OF > > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > > index 7a1e0ec032e6..1c0c92667ac4 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o > > +obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o > > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > > obj-$(CONFIG_DRM_MEGACHIPS_STDPXXXX_GE_B850V3_FW) += megachips-stdpxxxx-ge-b850v3-fw.o > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > > diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c b/drivers/gpu/drm/bridge/generic-gpio-mux.c > > new file mode 100644 > > index 000000000000..ba08321dcc17 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c > > @@ -0,0 +1,306 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Generic gpio mux bridge driver > > + * > > + * Copyright 2016 Google LLC > > + */ > > + > > + > > One blank line is enough. > > > +#include <linux/gpio.h> > > +#include <linux/interrupt.h> > > +#include <linux/platform_device.h> > > +#include <linux/module.h> > > +#include <linux/of.h> > > +#include <linux/of_gpio.h> > > +#include <linux/of_graph.h> > > Could you please sort these headers alphabetically ? > > > +#include <drm/drm_bridge.h> > > +#include <drm/drm_crtc_helper.h> > > +#include <drm/drm_probe_helper.h> > > + > > +struct gpio_display_mux { > > + struct device *dev; > > + > > + struct gpio_desc *gpiod_detect; > > + int detect_irq; > > + > > + struct drm_bridge bridge; > > + > > + struct drm_bridge *next[2]; > > +}; > > + > > +static inline struct gpio_display_mux *bridge_to_gpio_display_mux( > > + struct drm_bridge *bridge) > > +{ > > + return container_of(bridge, struct gpio_display_mux, bridge); > > +} > > + > > +static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void *data) > > +{ > > + struct gpio_display_mux *gpio_display_mux = data; > > gpio_display_mux is a long variable name. You can shorten it to mux here > and below. > > > + int active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > + > > + dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active); > > + > > + if (gpio_display_mux->bridge.dev) > > + drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev); > > + > > + return IRQ_HANDLED; > > +} > > + > > +static int gpio_display_mux_attach(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > i never takes negative values, you can make it an unsigned int. > > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next) > > + next->encoder = bridge->encoder; > > + } > > + > > + return 0; > > +} > > + > > +static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge, > > + const struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + int active; > > + struct drm_bridge *next; > > + > > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > What if the value of the GPIO changes between, let's say, this operation > and gpio_display_mux_mode_set() ? This doesn't seem very stable to me. > DRM/KMS hasn't been designed to have the output routing configured > externally without any control from the drivers. > We will fix it to store the gpio status in struct instead of reading in each bridge functions. Only in irq handler function the gpio status will be updated. > > + next = gpio_display_mux->next[active]; > > This will crash if gpiod_get_value() returns an error. Same for the > other functions below. > Will add check for this in irq handler function. > > + > > + if (next && next->funcs->mode_fixup) > > + return next->funcs->mode_fixup(next, mode, adjusted_mode); > > + else > > + return true; > > +} > > + > > +static void gpio_display_mux_mode_set(struct drm_bridge *bridge, > > + struct drm_display_mode *mode, > > + struct drm_display_mode *adjusted_mode) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + int active; > > + struct drm_bridge *next; > > + > > + active = gpiod_get_value(gpio_display_mux->gpiod_detect); > > + next = gpio_display_mux->next[active]; > > + > > + if (next && next->funcs->mode_set) > > + next->funcs->mode_set(next, mode, adjusted_mode); > > +} > > + > > +/** > > This isn't kerneldoc, the comment should start with /*. Same comment > below. > > > + * Since this driver _reacts_ to mux changes, we need to make sure all > > + * downstream bridges are pre-enabled. > > I'm afraid the problem scope seems bigger than I initially anticipated > :-( We're in the hack territory here, and I think we need to search for > a proper solution. We need to start with a detailed description of the > hardware and the use cases. > We are considering making this mux driver mt8173 oak board specific, since it seems that only this board have such design and we only have this board for testing. If so, we also only need mode_fixup bridge function. And the endpoint is anx7688 and hdmi connector. What do you think? > > + */ > > +static void gpio_display_mux_pre_enable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->pre_enable) > > + next->funcs->pre_enable(next); > > + } > > +} > > + > > +static void gpio_display_mux_post_disable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->post_disable) > > + next->funcs->post_disable(next); > > + } > > +} > > + > > +/** > > + * In an ideal mux driver, only the currently selected bridge should be enabled. > > + * For the sake of simplicity, we just just enable/disable all downstream > > + * bridges at the same time. > > + */ > > +static void gpio_display_mux_enable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->enable) > > + next->funcs->enable(next); > > + } > > +} > > + > > +static void gpio_display_mux_disable(struct drm_bridge *bridge) > > +{ > > + struct gpio_display_mux *gpio_display_mux = > > + bridge_to_gpio_display_mux(bridge); > > + struct drm_bridge *next; > > + int i; > > + > > + for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) { > > + next = gpio_display_mux->next[i]; > > + if (next && next->funcs->disable) > > + next->funcs->disable(next); > > + } > > +} > > + > > +static const struct drm_bridge_funcs gpio_display_mux_bridge_funcs = { > > + .attach = gpio_display_mux_attach, > > + .mode_fixup = gpio_display_mux_mode_fixup, > > + .disable = gpio_display_mux_disable, > > + .post_disable = gpio_display_mux_post_disable, > > + .mode_set = gpio_display_mux_mode_set, > > + .pre_enable = gpio_display_mux_pre_enable, > > + .enable = gpio_display_mux_enable, > > +}; > > + > > +static int gpio_display_mux_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct gpio_display_mux *gpio_display_mux; > > + struct device_node *port, *ep, *remote; > > + int ret; > > + u32 reg; > > + > > + gpio_display_mux = devm_kzalloc(dev, sizeof(*gpio_display_mux), > > + GFP_KERNEL); > > + if (!gpio_display_mux) > > + return -ENOMEM; > > + > > + platform_set_drvdata(pdev, gpio_display_mux); > > + gpio_display_mux->dev = &pdev->dev; > > + > > + gpio_display_mux->bridge.of_node = dev->of_node; > > + > > + gpio_display_mux->gpiod_detect = > > + devm_gpiod_get(dev, "detect", GPIOD_IN); > > + if (IS_ERR(gpio_display_mux->gpiod_detect)) > > + return PTR_ERR(gpio_display_mux->gpiod_detect); > > + > > + gpio_display_mux->detect_irq = > > + gpiod_to_irq(gpio_display_mux->gpiod_detect); > > + if (gpio_display_mux->detect_irq < 0) { > > + dev_err(dev, "Failed to get output irq %d\n", > > + gpio_display_mux->detect_irq); > > + return -ENODEV; > > + } > > + > > + port = of_graph_get_port_by_id(dev->of_node, 1); > > + if (!port) { > > + dev_err(dev, "Missing output port node\n"); > > + return -EINVAL; > > + } > > + > > + for_each_child_of_node(port, ep) { > > + if (!ep->name || (of_node_cmp(ep->name, "endpoint") != 0)) { > > + of_node_put(ep); > > + continue; > > + } > > + > > + if (of_property_read_u32(ep, "reg", ®) < 0 || > > + reg >= ARRAY_SIZE(gpio_display_mux->next)) { > > + dev_err(dev, > > + "Missing/invalid reg property for endpoint %s\n", > > + ep->full_name); > > + of_node_put(ep); > > + of_node_put(port); > > + return -EINVAL; > > + } > > + > > + remote = of_graph_get_remote_port_parent(ep); > > + if (!remote) { > > + dev_err(dev, > > + "Missing connector/bridge node for endpoint %s\n", > > + ep->full_name); > > + of_node_put(ep); > > + of_node_put(port); > > + return -EINVAL; > > + } > > + of_node_put(ep); > > + > > + if (of_device_is_compatible(remote, "hdmi-connector")) { > > + of_node_put(remote); > > + continue; > > + } > > This special case makes me think that something is wrong. I believe the > connector driver from > https://patchwork.freedesktop.org/patch/344477/?series=63328&rev=59 > could help. > Thanks for pointing this, we can remove the special case (hdmi) handling here. > > + > > + gpio_display_mux->next[reg] = of_drm_find_bridge(remote); > > What if the connected device is a panel and not a bridge ? > If this is oak specific, then we don't need to handle panel case. > > + if (!gpio_display_mux->next[reg]) { > > + dev_err(dev, "Waiting for external bridge %s\n", > > + remote->name); > > + of_node_put(remote); > > + of_node_put(port); > > + return -EPROBE_DEFER; > > + } > > + > > + of_node_put(remote); > > + } > > + of_node_put(port); > > + > > + gpio_display_mux->bridge.funcs = &gpio_display_mux_bridge_funcs; > > + drm_bridge_add(&gpio_display_mux->bridge); > > + > > + ret = devm_request_threaded_irq(dev, gpio_display_mux->detect_irq, > > + NULL, > > + gpio_display_mux_det_threaded_handler, > > + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | > > + IRQF_ONESHOT, > > + "gpio-display-mux-det", gpio_display_mux); > > + if (ret) { > > + dev_err(dev, "Failed to request MUX_DET threaded irq\n"); > > + goto err_bridge_remove; > > + } > > + > > + return 0; > > + > > +err_bridge_remove: > > + drm_bridge_remove(&gpio_display_mux->bridge); > > + > > + return ret; > > +} > > + > > +static int gpio_display_mux_remove(struct platform_device *pdev) > > +{ > > + struct gpio_display_mux *gpio_display_mux = platform_get_drvdata(pdev); > > + > > + drm_bridge_remove(&gpio_display_mux->bridge); > > If the GPIO IRQ is triggered here you'll have trouble. You need to > disable the IRQ, or free it, before removing the bridge. > Will fix this. Thanks > > + > > + return 0; > > +} > > + > > +static const struct of_device_id gpio_display_mux_match[] = { > > + { .compatible = "gpio-display-mux", }, > > + {}, > > +}; > > + > > +struct platform_driver gpio_display_mux_driver = { > > + .probe = gpio_display_mux_probe, > > + .remove = gpio_display_mux_remove, > > + .driver = { > > + .name = "gpio-display-mux", > > + .of_match_table = gpio_display_mux_match, > > + }, > > +}; > > + > > +module_platform_driver(gpio_display_mux_driver); > > + > > +MODULE_DESCRIPTION("GPIO-controlled display mux"); > > +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); > > +MODULE_LICENSE("GPL v2"); > > -- > Regards, > > Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 51+ messages in thread
* [PATCH RESEND 0/4] drm: bridge: anx7688 and an optional feature
@ 2019-12-09 14:50 Hsin-Yi Wang
2019-12-09 14:50 ` Hsin-Yi Wang
0 siblings, 1 reply; 51+ messages in thread
From: Hsin-Yi Wang @ 2019-12-09 14:50 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland,
Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda,
Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Archit Taneja, p.zabel, Enric Balletbo i Serra, Matthias Brugger,
Russell King
[Resend to cc more reviewers]
This series is to add anx7688 bridge driver. It is extended from
previous work[1].
The first 2 patches are same as previous version, with some modification
due to drm core function changes and use regmap abstraction.
We add an optional feature bypass-gpios so that driver can decide if it serves
as simple pass-thru by reading GPIO values, which is controlled by
hardware.
[1] https://lore.kernel.org/lkml/1467013727-11482-1-git-send-email-drinkcat@chromium.org/
Hsin-Yi Wang (2):
dt-bindings: drm/bridge: analogix-anx78xx: support bypass GPIO
drm: bridge: anx7688: Support bypass GPIO feature
Nicolas Boichat (2):
dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter
binding
drm: bridge: anx7688: Add anx7688 bridge driver support.
.../bindings/display/bridge/anx7688.txt | 70 +++++
drivers/gpu/drm/bridge/Kconfig | 9 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/analogix-anx7688.c | 260 ++++++++++++++++++
4 files changed, 340 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7688.txt
create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
--
2.24.0.393.g34dc348eaf-goog
^ permalink raw reply [flat|nested] 51+ messages in thread* [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. 2019-12-09 14:50 [PATCH RESEND 0/4] drm: bridge: anx7688 and an optional feature Hsin-Yi Wang @ 2019-12-09 14:50 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-09 14:50 UTC (permalink / raw) To: dri-devel Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Nicolas Boichat, devicetree, linux-kernel, Andrzej Hajda, Neil Armstrong, Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Archit Taneja, p.zabel, Enric Balletbo i Serra, Matthias Brugger, Russell King From: Nicolas Boichat <drinkcat@chromium.org> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), that has an internal microcontroller. The only reason a Linux kernel driver is necessary is to reject resolutions that require more bandwidth than what is available on the DP side. DP bandwidth and lane count are reported by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/analogix-anx7688.c | 203 ++++++++++++++++++++++ 3 files changed, 213 insertions(+) create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 34362976cd6f..1f3fc6bec842 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE menu "Display Interface Bridges" depends on DRM && DRM_BRIDGE +config DRM_ANALOGIX_ANX7688 + tristate "Analogix ANX7688 bridge" + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + ANX7688 is a transmitter to support DisplayPort over USB-C for + smartphone and tablets. + This driver only supports the HDMI to DP component of the chip. + config DRM_ANALOGIX_ANX78XX tristate "Analogix ANX78XX bridge" select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 4934fcf5a6f8..7a1e0ec032e6 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c new file mode 100644 index 000000000000..5a3a2251c1c5 --- /dev/null +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c @@ -0,0 +1,203 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ANX7688 HDMI->DP bridge driver + * + * Copyright 2016 Google LLC + */ + +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/regmap.h> +#include <drm/drm_bridge.h> +#include <drm/drm_crtc.h> + +/* Register addresses */ +#define VENDOR_ID_REG 0x00 +#define DEVICE_ID_REG 0x02 + +#define FW_VERSION_REG 0x80 + +#define DP_BANDWIDTH_REG 0x85 +#define DP_LANE_COUNT_REG 0x86 + +#define VENDOR_ID 0x1f29 +#define DEVICE_ID 0x7688 + +/* First supported firmware version (0.85) */ +#define MINIMUM_FW_VERSION 0x0085 + +struct anx7688 { + struct drm_bridge bridge; + struct i2c_client *client; + struct regmap *regmap; + + bool filter; +}; + +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) +{ + return container_of(bridge, struct anx7688, bridge); +} + +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); + u8 regs[2]; + u8 dpbw, lanecount; + int totalbw, requiredbw; + int ret; + + if (!anx7688->filter) + return true; + + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); + if (ret < 0) { + dev_err(&anx7688->client->dev, + "Failed to read bandwidth/lane count\n"); + return false; + } + dpbw = regs[0]; + lanecount = regs[1]; + + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ + if (dpbw > 0x19 || lanecount > 2) { + dev_err(&anx7688->client->dev, + "Invalid bandwidth/lane count (%02x/%d)\n", + dpbw, lanecount); + return false; + } + + /* Compute available bandwidth (kHz) */ + totalbw = dpbw * lanecount * 270000 * 8 / 10; + + /* Required bandwidth (8 bpc, kHz) */ + requiredbw = mode->clock * 8 * 3; + + dev_dbg(&anx7688->client->dev, + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", + totalbw, dpbw, lanecount, requiredbw); + + if (totalbw == 0) { + dev_warn(&anx7688->client->dev, + "Bandwidth/lane count are 0, not rejecting modes\n"); + return true; + } + + return totalbw >= requiredbw; +} + +static const struct drm_bridge_funcs anx7688_bridge_funcs = { + .mode_fixup = anx7688_bridge_mode_fixup, +}; + +static const struct regmap_config anx7688_regmap_config = { + .reg_bits = 8, + .val_bits = 8, +}; + +static int anx7688_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct anx7688 *anx7688; + struct device *dev = &client->dev; + int ret; + u8 buffer[4]; + u16 vendor, device, fwversion; + + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); + if (!anx7688) + return -ENOMEM; + +#if IS_ENABLED(CONFIG_OF) + anx7688->bridge.of_node = client->dev.of_node; +#endif + + anx7688->client = client; + i2c_set_clientdata(client, anx7688); + + anx7688->regmap = + devm_regmap_init_i2c(client, &anx7688_regmap_config); + + /* Read both vendor and device id (4 bytes). */ + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); + if (ret) { + dev_err(dev, "Failed to read chip vendor/device id\n"); + return ret; + } + + vendor = (u16)buffer[1] << 8 | buffer[0]; + device = (u16)buffer[3] << 8 | buffer[2]; + if (vendor != VENDOR_ID || device != DEVICE_ID) { + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", + vendor, device); + return -ENODEV; + } + + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); + if (ret) { + dev_err(&client->dev, "Failed to read firmware version\n"); + return ret; + } + + fwversion = (u16)buffer[0] << 8 | buffer[1]; + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", + buffer[0], buffer[1]); + + /* FW version >= 0.85 supports bandwidth/lane count registers */ + if (fwversion >= MINIMUM_FW_VERSION) { + anx7688->filter = true; + } else { + /* Warn, but not fail, for backwards compatibility. */ + dev_warn(dev, + "Old ANX7688 FW version (%02x.%02x), not filtering\n", + buffer[0], buffer[1]); + } + + anx7688->bridge.funcs = &anx7688_bridge_funcs; + drm_bridge_add(&anx7688->bridge); + + return 0; +} + +static int anx7688_i2c_remove(struct i2c_client *client) +{ + struct anx7688 *anx7688 = i2c_get_clientdata(client); + + drm_bridge_remove(&anx7688->bridge); + + return 0; +} + +static const struct i2c_device_id anx7688_id[] = { + { "anx7688", 0 }, + { /* sentinel */ } +}; + +MODULE_DEVICE_TABLE(i2c, anx7688_id); + +#if IS_ENABLED(CONFIG_OF) +static const struct of_device_id anx7688_match_table[] = { + { .compatible = "analogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), + }, + .probe = anx7688_i2c_probe, + .remove = anx7688_i2c_remove, + .id_table = anx7688_id, +}; + +module_i2c_driver(anx7688_driver); + +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.393.g34dc348eaf-goog ^ permalink raw reply related [flat|nested] 51+ messages in thread
* [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support. @ 2019-12-09 14:50 ` Hsin-Yi Wang 0 siblings, 0 replies; 51+ messages in thread From: Hsin-Yi Wang @ 2019-12-09 14:50 UTC (permalink / raw) To: dri-devel Cc: Mark Rutland, devicetree, Jernej Skrabec, Nicolas Boichat, Neil Armstrong, David Airlie, Jonas Karlman, linux-kernel, Archit Taneja, Rob Herring, Laurent Pinchart, Matthias Brugger, Enric Balletbo i Serra, Russell King From: Nicolas Boichat <drinkcat@chromium.org> ANX7688 is a HDMI to DP converter (as well as USB-C port controller), that has an internal microcontroller. The only reason a Linux kernel driver is necessary is to reject resolutions that require more bandwidth than what is available on the DP side. DP bandwidth and lane count are reported by the bridge via 2 registers on I2C. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/analogix-anx7688.c | 203 ++++++++++++++++++++++ 3 files changed, 213 insertions(+) create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 34362976cd6f..1f3fc6bec842 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE menu "Display Interface Bridges" depends on DRM && DRM_BRIDGE +config DRM_ANALOGIX_ANX7688 + tristate "Analogix ANX7688 bridge" + select DRM_KMS_HELPER + select REGMAP_I2C + ---help--- + ANX7688 is a transmitter to support DisplayPort over USB-C for + smartphone and tablets. + This driver only supports the HDMI to DP component of the chip. + config DRM_ANALOGIX_ANX78XX tristate "Analogix ANX78XX bridge" select DRM_KMS_HELPER diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 4934fcf5a6f8..7a1e0ec032e6 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c b/drivers/gpu/drm/bridge/analogix-anx7688.c new file mode 100644 index 000000000000..5a3a2251c1c5 --- /dev/null +++ b/drivers/gpu/drm/bridge/analogix-anx7688.c @@ -0,0 +1,203 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ANX7688 HDMI->DP bridge driver + * + * Copyright 2016 Google LLC + */ + +#include <linux/i2c.h> +#include <linux/module.h> +#include <linux/regmap.h> +#include <drm/drm_bridge.h> +#include <drm/drm_crtc.h> + +/* Register addresses */ +#define VENDOR_ID_REG 0x00 +#define DEVICE_ID_REG 0x02 + +#define FW_VERSION_REG 0x80 + +#define DP_BANDWIDTH_REG 0x85 +#define DP_LANE_COUNT_REG 0x86 + +#define VENDOR_ID 0x1f29 +#define DEVICE_ID 0x7688 + +/* First supported firmware version (0.85) */ +#define MINIMUM_FW_VERSION 0x0085 + +struct anx7688 { + struct drm_bridge bridge; + struct i2c_client *client; + struct regmap *regmap; + + bool filter; +}; + +static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge) +{ + return container_of(bridge, struct anx7688, bridge); +} + +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct anx7688 *anx7688 = bridge_to_anx7688(bridge); + u8 regs[2]; + u8 dpbw, lanecount; + int totalbw, requiredbw; + int ret; + + if (!anx7688->filter) + return true; + + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */ + ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2); + if (ret < 0) { + dev_err(&anx7688->client->dev, + "Failed to read bandwidth/lane count\n"); + return false; + } + dpbw = regs[0]; + lanecount = regs[1]; + + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */ + if (dpbw > 0x19 || lanecount > 2) { + dev_err(&anx7688->client->dev, + "Invalid bandwidth/lane count (%02x/%d)\n", + dpbw, lanecount); + return false; + } + + /* Compute available bandwidth (kHz) */ + totalbw = dpbw * lanecount * 270000 * 8 / 10; + + /* Required bandwidth (8 bpc, kHz) */ + requiredbw = mode->clock * 8 * 3; + + dev_dbg(&anx7688->client->dev, + "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n", + totalbw, dpbw, lanecount, requiredbw); + + if (totalbw == 0) { + dev_warn(&anx7688->client->dev, + "Bandwidth/lane count are 0, not rejecting modes\n"); + return true; + } + + return totalbw >= requiredbw; +} + +static const struct drm_bridge_funcs anx7688_bridge_funcs = { + .mode_fixup = anx7688_bridge_mode_fixup, +}; + +static const struct regmap_config anx7688_regmap_config = { + .reg_bits = 8, + .val_bits = 8, +}; + +static int anx7688_i2c_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct anx7688 *anx7688; + struct device *dev = &client->dev; + int ret; + u8 buffer[4]; + u16 vendor, device, fwversion; + + anx7688 = devm_kzalloc(dev, sizeof(*anx7688), GFP_KERNEL); + if (!anx7688) + return -ENOMEM; + +#if IS_ENABLED(CONFIG_OF) + anx7688->bridge.of_node = client->dev.of_node; +#endif + + anx7688->client = client; + i2c_set_clientdata(client, anx7688); + + anx7688->regmap = + devm_regmap_init_i2c(client, &anx7688_regmap_config); + + /* Read both vendor and device id (4 bytes). */ + ret = regmap_bulk_read(anx7688->regmap, VENDOR_ID_REG, buffer, 4); + if (ret) { + dev_err(dev, "Failed to read chip vendor/device id\n"); + return ret; + } + + vendor = (u16)buffer[1] << 8 | buffer[0]; + device = (u16)buffer[3] << 8 | buffer[2]; + if (vendor != VENDOR_ID || device != DEVICE_ID) { + dev_err(dev, "Invalid vendor/device id %04x/%04x\n", + vendor, device); + return -ENODEV; + } + + ret = regmap_bulk_read(anx7688->regmap, FW_VERSION_REG, buffer, 2); + if (ret) { + dev_err(&client->dev, "Failed to read firmware version\n"); + return ret; + } + + fwversion = (u16)buffer[0] << 8 | buffer[1]; + dev_info(dev, "ANX7688 firwmare version %02x.%02x\n", + buffer[0], buffer[1]); + + /* FW version >= 0.85 supports bandwidth/lane count registers */ + if (fwversion >= MINIMUM_FW_VERSION) { + anx7688->filter = true; + } else { + /* Warn, but not fail, for backwards compatibility. */ + dev_warn(dev, + "Old ANX7688 FW version (%02x.%02x), not filtering\n", + buffer[0], buffer[1]); + } + + anx7688->bridge.funcs = &anx7688_bridge_funcs; + drm_bridge_add(&anx7688->bridge); + + return 0; +} + +static int anx7688_i2c_remove(struct i2c_client *client) +{ + struct anx7688 *anx7688 = i2c_get_clientdata(client); + + drm_bridge_remove(&anx7688->bridge); + + return 0; +} + +static const struct i2c_device_id anx7688_id[] = { + { "anx7688", 0 }, + { /* sentinel */ } +}; + +MODULE_DEVICE_TABLE(i2c, anx7688_id); + +#if IS_ENABLED(CONFIG_OF) +static const struct of_device_id anx7688_match_table[] = { + { .compatible = "analogix,anx7688", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, anx7688_match_table); +#endif + +static struct i2c_driver anx7688_driver = { + .driver = { + .name = "anx7688", + .of_match_table = of_match_ptr(anx7688_match_table), + }, + .probe = anx7688_i2c_probe, + .remove = anx7688_i2c_remove, + .id_table = anx7688_id, +}; + +module_i2c_driver(anx7688_driver); + +MODULE_DESCRIPTION("ANX7688 SlimPort Transmitter driver"); +MODULE_AUTHOR("Nicolas Boichat <drinkcat@chromium.org>"); +MODULE_LICENSE("GPL v2"); -- 2.24.0.393.g34dc348eaf-goog _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 51+ messages in thread
end of thread, other threads:[~2019-12-23 8:12 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-11 6:19 [PATCH RESEND 0/4] drm: bridge: anx7688 and mux drivers Hsin-Yi Wang 2019-12-11 6:19 ` Hsin-Yi Wang 2019-12-11 6:19 ` [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding Hsin-Yi Wang 2019-12-11 6:19 ` Hsin-Yi Wang 2019-12-19 20:45 ` Rob Herring 2019-12-19 20:45 ` Rob Herring 2019-12-20 3:20 ` Hsin-Yi Wang 2019-12-20 3:20 ` Hsin-Yi Wang 2019-12-20 3:22 ` Laurent Pinchart 2019-12-20 3:22 ` Laurent Pinchart 2019-12-20 3:51 ` Hsin-Yi Wang 2019-12-20 3:51 ` Hsin-Yi Wang 2019-12-11 6:19 ` [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support Hsin-Yi Wang 2019-12-11 6:19 ` Hsin-Yi Wang 2019-12-12 11:50 ` Enric Balletbo i Serra 2019-12-12 11:50 ` Enric Balletbo i Serra 2019-12-13 22:38 ` Laurent Pinchart 2019-12-13 22:38 ` Laurent Pinchart 2019-12-16 8:45 ` Hsin-Yi Wang 2019-12-16 8:45 ` Hsin-Yi Wang 2019-12-16 10:19 ` Nicolas Boichat 2019-12-16 10:19 ` Nicolas Boichat 2019-12-16 16:39 ` Laurent Pinchart 2019-12-16 16:39 ` Laurent Pinchart 2019-12-17 0:20 ` Nicolas Boichat 2019-12-17 0:40 ` Nicolas Boichat 2019-12-17 0:40 ` Nicolas Boichat 2019-12-17 0:52 ` Laurent Pinchart 2019-12-17 0:52 ` Laurent Pinchart 2019-12-17 6:04 ` Nicolas Boichat 2019-12-17 6:04 ` Nicolas Boichat 2019-12-11 6:19 ` [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding Hsin-Yi Wang 2019-12-11 6:19 ` Hsin-Yi Wang 2019-12-13 13:53 ` Rob Herring 2019-12-13 13:53 ` Rob Herring 2019-12-16 7:16 ` Hsin-Yi Wang 2019-12-16 7:16 ` Hsin-Yi Wang 2019-12-19 20:48 ` Rob Herring 2019-12-19 20:48 ` Rob Herring 2019-12-20 3:57 ` Hsin-Yi Wang 2019-12-20 3:57 ` Hsin-Yi Wang 2019-12-11 6:19 ` [PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver Hsin-Yi Wang 2019-12-11 6:19 ` Hsin-Yi Wang 2019-12-12 11:54 ` Enric Balletbo i Serra 2019-12-12 11:54 ` Enric Balletbo i Serra 2019-12-13 22:33 ` Laurent Pinchart 2019-12-13 22:33 ` Laurent Pinchart 2019-12-16 8:44 ` Hsin-Yi Wang 2019-12-16 8:44 ` Hsin-Yi Wang -- strict thread matches above, loose matches on Subject: below -- 2019-12-09 14:50 [PATCH RESEND 0/4] drm: bridge: anx7688 and an optional feature Hsin-Yi Wang 2019-12-09 14:50 ` [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support Hsin-Yi Wang 2019-12-09 14:50 ` Hsin-Yi Wang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.