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.
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