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
