| Message ID | 20191209145016.227784-4-hsinyi@chromium.org |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | drm: bridge: anx7688 and an optional feature | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
Hi Hsin-Yi, Thank you for the patch. On Mon, Dec 09, 2019 at 10:50:15PM +0800, Hsin-Yi Wang wrote: > Support optional feature: bypass GPIO. > > Some SoC (eg. mt8173) have a hardware mux that connects to 2 ports: > anx7688 and hdmi. When the GPIO is active, the bridge is bypassed. This doesn't look like the right place to fix this, as the mux is unrelated to the bridge. You would have to duplicate this logic in every bridge driver otherwise. Could you describe the hardware topology in a bit more details ? I can then try to advise on how to best support it. > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> > --- > .../bindings/display/bridge/anx7688.txt | 40 ++++++++++++++++++- > 1 file changed, 39 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.txt b/Documentation/devicetree/bindings/display/bridge/anx7688.txt > index 78b55bdb18f7..44185dcac839 100644 > --- a/Documentation/devicetree/bindings/display/bridge/anx7688.txt > +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.txt > @@ -15,10 +15,13 @@ Required properties: > Optional properties: > > - Video port for HDMI input, using the DT bindings defined in [1]. > + - bypass-gpios : External GPIO. If this GPIO is active, we assume > + the bridge is bypassed (e.g. by a mux). > + - pinctrl-0, pinctrl-names: the pincontrol settings to configure bypass GPIO. > > [1]: Documentation/devicetree/bindings/media/video-interfaces.txt > > -Example: > +Example 1: > > anx7688: anx7688@2c { > compatible = "analogix,anx7688"; > @@ -30,3 +33,38 @@ Example: > }; > }; > }; > + > +Example 2: > + > + anx7688: anx7688@2c { > + compatible = "analogix,anx7688"; > + status = "okay"; > + reg = <0x2c>; > + ddc-i2c-bus = <&hdmiddc0>; > + > + bypass-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; > + pinctrl-names = "default"; > + pinctrl-0 = <&hdmi_mux_pins>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { /* input */ > + reg = <0>; > + > + anx7688_in: endpoint { > + remote-endpoint = <&hdmi_out_anx>; > + }; > + }; > + > + port@1 { /* output */ > + reg = <1>; > + > + anx7688_out: endpoint { > + remote-endpoint = <&hdmi_connector_in>; > + }; > + }; > + }; > + }; > +
On Mon, Dec 9, 2019 at 10:55 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hsin-Yi, > > Thank you for the patch. > > On Mon, Dec 09, 2019 at 10:50:15PM +0800, Hsin-Yi Wang wrote: > > Support optional feature: bypass GPIO. > > > > Some SoC (eg. mt8173) have a hardware mux that connects to 2 ports: > > anx7688 and hdmi. When the GPIO is active, the bridge is bypassed. > > This doesn't look like the right place to fix this, as the mux is > unrelated to the bridge. You would have to duplicate this logic in every > bridge driver otherwise. > > Could you describe the hardware topology in a bit more details ? I can > then try to advise on how to best support it. > Hi Laurent, The mt8173 layout is: MT8173 HDMI bridge-- hardware mux --- HDMI | ------------ anx7688 There's a hardware mux that takes mt8173 hdmi as input and has 2 output port: native hdmi and anx7688 bridge. If gpio is active, we would like it to go to HDMI. Previous approach is to make hardware mux a generic gpio mux bridge, but this is probably a very rare use case that is only for mt8173.(https://lore.kernel.org/lkml/57723AD2.8020806@codeaurora.org/) We merge the mux and anx7688 to a single bridge and leave this as an optional feature in this time. Thanks.
Hi Hsin-Yi, On Mon, Dec 09, 2019 at 11:09:34PM +0800, Hsin-Yi Wang wrote: > On Mon, Dec 9, 2019 at 10:55 PM Laurent Pinchart wrote: > > On Mon, Dec 09, 2019 at 10:50:15PM +0800, Hsin-Yi Wang wrote: > > > Support optional feature: bypass GPIO. > > > > > > Some SoC (eg. mt8173) have a hardware mux that connects to 2 ports: > > > anx7688 and hdmi. When the GPIO is active, the bridge is bypassed. > > > > This doesn't look like the right place to fix this, as the mux is > > unrelated to the bridge. You would have to duplicate this logic in every > > bridge driver otherwise. > > > > Could you describe the hardware topology in a bit more details ? I can > > then try to advise on how to best support it. > > Hi Laurent, > > The mt8173 layout is: > > MT8173 HDMI bridge-- hardware mux --- HDMI > | > ------------ anx7688 You may have used a proportional font when writing this, the | doesn't align with anything using a fixed font. Do I assume correctly that the hardware multiplexer is actually a demultiplexer with one input and two outputs ? +-----------+ +---------+ +------+ /--> | HDMI | | MT8173 | HDMI | -->| --/ | Connector | | HDMI | ------> |--/ | +-----------+ | Encoder | | ->| --\ +-----------+ +-----------+ +---------+ +------+ \--> | ANX7688 | ---> | USB-C | | Bridge | | Connector | +-----------+ +-----------+ > There's a hardware mux that takes mt8173 hdmi as input and has 2 > output port: native hdmi and anx7688 bridge. > If gpio is active, we would like it to go to HDMI. > > Previous approach is to make hardware mux a generic gpio mux bridge, > but this is probably a very rare use case that is only for > mt8173.(https://lore.kernel.org/lkml/57723AD2.8020806@codeaurora.org/) > We merge the mux and anx7688 to a single bridge and leave this as an > optional feature in this time. I think that's a better approach, at least at the DT level. The HDMI demultiplexer should be represented as a DT node with 3 ports (one input and two outputs) with a control GPIO. From a video point of view, the ANX7688 should be represented as a DT node with 2 ports (one input and one output), regardless of whether it is used in conjunction with an HDMI switch as shown above, or directly connected to the output of an HDMI encoder. However, as the ANX7688 supports both DP output and USB-C output, the situation may be slightly more complex. Please see https://patchwork.kernel.org/patch/11184895/ for a similar discussion, related to the ANX7625. In any case, I don't think the ANX7688 should care about the GPIO.
On Mon, Dec 9, 2019 at 11:32 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Laurent, > You may have used a proportional font when writing this, the | doesn't > align with anything using a fixed font. Do I assume correctly that the > hardware multiplexer is actually a demultiplexer with one input and two > outputs ? > +-----------+ > +---------+ +------+ /--> | HDMI | > | MT8173 | HDMI | -->| --/ | Connector | > | HDMI | ------> |--/ | +-----------+ > | Encoder | | ->| --\ +-----------+ +-----------+ > +---------+ +------+ \--> | ANX7688 | ---> | USB-C | > | Bridge | | Connector | > +-----------+ +-----------+ > Sorry for not noticing the font issue, this graph is correct. > > There's a hardware mux that takes mt8173 hdmi as input and has 2 > > output port: native hdmi and anx7688 bridge. > > If gpio is active, we would like it to go to HDMI. > > > > Previous approach is to make hardware mux a generic gpio mux bridge, > > but this is probably a very rare use case that is only for > > mt8173.(https://lore.kernel.org/lkml/57723AD2.8020806@codeaurora.org/) > > We merge the mux and anx7688 to a single bridge and leave this as an > > optional feature in this time. > > I think that's a better approach, at least at the DT level. The HDMI > demultiplexer should be represented as a DT node with 3 ports (one input > and two outputs) with a control GPIO. > I've resend the original gpio mux driver. So for anx7688 there's 1 input and 1 output. Thanks
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.txt b/Documentation/devicetree/bindings/display/bridge/anx7688.txt index 78b55bdb18f7..44185dcac839 100644 --- a/Documentation/devicetree/bindings/display/bridge/anx7688.txt +++ b/Documentation/devicetree/bindings/display/bridge/anx7688.txt @@ -15,10 +15,13 @@ Required properties: Optional properties: - Video port for HDMI input, using the DT bindings defined in [1]. + - bypass-gpios : External GPIO. If this GPIO is active, we assume + the bridge is bypassed (e.g. by a mux). + - pinctrl-0, pinctrl-names: the pincontrol settings to configure bypass GPIO. [1]: Documentation/devicetree/bindings/media/video-interfaces.txt -Example: +Example 1: anx7688: anx7688@2c { compatible = "analogix,anx7688"; @@ -30,3 +33,38 @@ Example: }; }; }; + +Example 2: + + anx7688: anx7688@2c { + compatible = "analogix,anx7688"; + status = "okay"; + reg = <0x2c>; + ddc-i2c-bus = <&hdmiddc0>; + + bypass-gpios = <&pio 36 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_mux_pins>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { /* input */ + reg = <0>; + + anx7688_in: endpoint { + remote-endpoint = <&hdmi_out_anx>; + }; + }; + + port@1 { /* output */ + reg = <1>; + + anx7688_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; +
Support optional feature: bypass GPIO. Some SoC (eg. mt8173) have a hardware mux that connects to 2 ports: anx7688 and hdmi. When the GPIO is active, the bridge is bypassed. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> --- .../bindings/display/bridge/anx7688.txt | 40 ++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-)