Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Philipp Zabel <p.zabel@pengutronix.de>]

Am Donnerstag, den 23.06.2016, 12:08 +0800 schrieb Nicolas Boichat:
[...]
> >> >> I think it'd be a bit weird to have the DDC bus phandle on the DP
> >> >> connector, as we're not reading the EDID on the DP side of the bridge,
> >> >> but on the HDMI side (and the bridge can do all sort of things to the
> >> >> EDID: At the very least, I think it caches it).
> >>>
> >> > On the board, do the DDC lines join directly from the SoC pins to the
> >> > DP connector, or does it go via the ANX7688 chip?
> >>
> >> The DDC/I2C lines go to the ANX7688 chip. (DP has AUX channel instead)
> >
> > The anx7688 should get the i2c-ddc-bus property then, and the driver
> > should use it to implement get_modes (or its bridge API equivalent, once
> > it exists).
> 
> Ok, I can do that (I tried it). It's a lot a duplication from the
> existing connector in mtk-hdmi, but I understand there may not be a
> better way currently.

Is there a thread where moving connectors back out of the bridge drivers
was discussed?

> However, the problem I'm facing is how to implement "detect" in the
> connector function. I'm still getting the interrupts from the MTK cec
> module (so the detect function gets called), but then I don't see a
> good way to read the HPD status (ANX7688 does not have a register for
> that: it passes the HPD signal downstream).
> 
> mtk_hdmi implements detect this way:
>         return mtk_cec_hpd_high(hdmi->cec_dev) ?
>                connector_status_connected : connector_status_disconnected;
> 
> But of course I can't call this function from the ANX7688 bridge driver...

If the bridge API is extended to get a .detect equivalent, the ANX7688
could just not implement it or return -ENOTSUPP to indicate HPD
passthrough and the mtk_hdmi connector could fall back to current
behaviour.

> >> > Even with the current bindings (referred from the link below), the
> >> > hdmi connector has the DDC node. Shouldn't it be the same in the DP
> >> > case too? The DP connector, like before, is still manged by the HDMI
> >> > driver, the only difference being the name and that it's two hops away
> >> > in the DT bindings.
> >> >
> >> > https://patchwork.kernel.org/patch/9137089/
> >>
> >> True, the bindings say so, but the current code actually looks for
> >> ddc-i2c-bus property in whatever is connected on the endpoint (be it a
> >> bridge or a connector).
> >
> > The HDMI driver only handles this itself because there are no separate
> > connector drivers (or helpers) to do this. Ideally the HDMI driver
> > shouldn't have to parse the connector DT node.
> >
> >> And again, a bit odd as DP connector does not have true I2C lines...
> >>
> >> Phillip? Any opinion?
> >
> > Make the HDMI driver leave the bridges' DT node alone and let the bridge
> > handle DDC, if that's where it is connected physically.
> 
> Again, a bit odd... AFAICT, all other bridge drivers, and encoders,
> read EDID from a bus that is downstream of it. If we handle DDC in the
> ANX driver, it'll have to read the EDID upstream (on the HDMI side),
> as there is no way to read the EDID on the DP side on this chip.

Well, the chip is a bit odd in that it seems to be intended to be
transparent to the software with the EDID and HPD passthrough, but then
still needs to have a driver.

regards
Philipp