(Resend this with plaintext mode. Sorry for the previous spam.)
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.
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.
[1]: https://elixir.bootlin.com/linux/v6.2/source/drivers/gpu/drm/bridge/cros-ec-anx7688.c#L87
Regards,
Pin-yen
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
