Hi Rob,
After some internal discussions, we decided to drop this series because the driver is trying to do runtime routing of the display signals, which is not supported by the current DRM system, even if we can describe the design in the device tree. I'm explaining our use case as a record, and I can follow up on the mtk_hdmi.c change if anyone is interested.
The more detailed schematics looks like:
+----------+ +----------------+ +-----------+
| MTK | | | | HDMI |
| HDMI +--->| TS3DV642 +--->| connector |
| bridge | | | +-----------+
+----------+ | |
| HDMI MUX | +-------------+
| | | anx7688 | +-----------+
+----------+ | | | HDMI to DP | | USB-C |
| cros EC +--->| +--->| bridge +-->| connector |
+----------+ +----------------+ +-------------+ +-----------+
The TS3DV642 HDMI MUX is controlled by the CrOS EC to switch the HDMI signal between two output ports, and the generic-display-mux driver was trying to control the downstream bridges according to the GPIO status reported by EC. However, as far as I know, this kind of runtime routing is not supported by DRM.
After some internal discussions, we decided to drop this series because the driver is trying to do runtime routing of the display signals, which is not supported by the current DRM system, even if we can describe the design in the device tree. I'm explaining our use case as a record, and I can follow up on the mtk_hdmi.c change if anyone is interested.
The more detailed schematics looks like:
+----------+ +----------------+ +-----------+
| MTK | | | | HDMI |
| HDMI +--->| TS3DV642 +--->| connector |
| bridge | | | +-----------+
+----------+ | |
| HDMI MUX | +-------------+
| | | anx7688 | +-----------+
+----------+ | | | HDMI to DP | | USB-C |
| cros EC +--->| +--->| bridge +-->| connector |
+----------+ +----------------+ +-------------+ +-----------+
The TS3DV642 HDMI MUX is controlled by the CrOS EC to switch the HDMI signal between two output ports, and the generic-display-mux driver was trying to control the downstream bridges according to the GPIO status reported by EC. However, as far as I know, this kind of runtime routing is not supported by DRM.
And, it can work fine if we only describe the following design in DT:
+---------+ +-------------+ +-----------+
| MTK | | anx7688 | | USB-C |
| HDMI +-->| HDMI to DP +-->| connector |
| bridge | | bridge | +-----------+
+---------+ +-------------+
This can work because the anx7688 driver won't reject any display modes when the DP lane count is 0 ([1]), which is true when the HDMI connector is used.
Thanks for your time for reviewing this series and sorry for not explaining everything clearly at the beginning.
+---------+ +-------------+ +-----------+
| MTK | | anx7688 | | USB-C |
| HDMI +-->| HDMI to DP +-->| connector |
| bridge | | bridge | +-----------+
+---------+ +-------------+
This can work because the anx7688 driver won't reject any display modes when the DP lane count is 0 ([1]), which is true when the HDMI connector is used.
Thanks for your time for reviewing this series and sorry for not explaining everything clearly at the beginning.
On Tue, Feb 21, 2023 at 11:41 PM Rob Herring <robh@xxxxxxxxxx> wrote:
On Sat, Feb 18, 2023 at 07:17:08PM +0800, Pin-yen Lin wrote:
> Introduce a optional "ddc-i2c-bus" property for anx7688 bridge. This
> allows the bridge to register a .get_edid callback.
What's .get_edid? This is a binding and is independent of Linux.
>
> Signed-off-by: Pin-yen Lin <treapking@xxxxxxxxxxxx>
> ---
>
> Changes in v3:
> - New in v3
>
> .../bindings/display/bridge/google,cros-ec-anx7688.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> index a44d025d33bd..9d5ce8172e88 100644
> --- a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
> @@ -25,6 +25,10 @@ properties:
> maxItems: 1
> description: I2C address of the device.
>
> + ddc-i2c-bus:
> + description: phandle link to the I2C controller used for DDC EDID probing
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
No, this belongs in the connector node. The DDC signals are routed to
the connector, not the bridge chip.
Rob
