From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752064AbcFWJTM (ORCPT ); Thu, 23 Jun 2016 05:19:12 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:46190 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751756AbcFWJTI (ORCPT ); Thu, 23 Jun 2016 05:19:08 -0400 Message-ID: <1466673536.2278.43.camel@pengutronix.de> Subject: Re: [RFC PATCH 1/2] drm: bridge: anx7688: Add anx7688 bridge driver support. From: Philipp Zabel To: Nicolas Boichat Cc: Archit Taneja , dri-devel@lists.freedesktop.org, =?ISO-8859-1?Q?St=E9phane?= Marchesin , linux-kernel@vger.kernel.org, Enric Balletbo i Serra , Russell King , Thierry Reding Date: Thu, 23 Jun 2016 11:18:56 +0200 In-Reply-To: References: <1466406853-26465-1-git-send-email-drinkcat@chromium.org> <57695F94.7030801@codeaurora.org> <576A0C11.9030707@codeaurora.org> <1466585509.4123.23.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:96de:80ff:fec2:9969 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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