From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754174AbbIGIjc (ORCPT ); Mon, 7 Sep 2015 04:39:32 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:10988 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754132AbbIGIj2 (ORCPT ); Mon, 7 Sep 2015 04:39:28 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Mon, 07 Sep 2015 01:35:03 -0700 Date: Mon, 7 Sep 2015 10:39:18 +0200 From: Thierry Reding To: Yakir Yang CC: Rob Herring , Heiko Stuebner , Jingoo Han , Inki Dae , "Joe Perches" , Kukjin Kim , Krzysztof Kozlowski , Mark Yao , Russell King , , , , Ajay kumar , Andrzej Hajda , Kyungmin Park , David Airlie , Gustavo Padovan , Andy Yan , "Kumar Gala" , Ian Campbell , Rob Herring , Pawel Moll , "Kishon Vijay Abraham I" , , dri-devel , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed Message-ID: <20150907083916.GC19961@ulmo.nvidia.com> References: <1441086371-24838-1-git-send-email-ykk@rock-chips.com> <1441088079-25809-1-git-send-email-ykk@rock-chips.com> <55E7CC43.7040608@rock-chips.com> <55EBF757.20108@rock-chips.com> MIME-Version: 1.0 In-Reply-To: <55EBF757.20108@rock-chips.com> X-NVConfidentiality: public User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) X-Originating-IP: [10.2.71.38] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XMCwj5IQnwKtuyBG" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --XMCwj5IQnwKtuyBG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 06, 2015 at 04:20:39PM +0800, Yakir Yang wrote: > Hi Rob, >=20 > =E5=9C=A8 09/05/2015 05:46 AM, Rob Herring =E5=86=99=E9=81=93: > >On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote: > >>Hi Rob, > >> > >>=E5=9C=A8 09/03/2015 04:17 AM, Rob Herring =E5=86=99=E9=81=93: > >>>On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > >>>>Some edp screen do not have hpd signal, so we can't just return > >>>>failed when hpd plug in detect failed. > >>>This is a property of the panel (or connector perhaps), so this > >>>property should be located there. At least, it is a common issue and > >>>not specific to this chip. We could have an HDMI connector and failed > >>>to hook up HPD for example. A connector node is also where hpd-gpios > >>>should be located instead (and are already defined by > >>>../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >>>binding, too. > >> > >>Yep, I agree with your front point, it is a property of panel, not spec= ific > >>to eDP controller, so this code should handle in connector logic. > >> > >>But another question, if we just leave this property to connector, > >>then we would need to parse this property in analogix_dp-rockchip.c, > >>and then make an hook in analogix_dp_core.c driver. This is not nice, > >>and if there are some coming platform which alse want to use analogix_dp > >>code and meet this "no-hpd" situation, then they would need duplicate > >>to parse this property and fill the hook in analogix_dp_core.c driver. > >>So it's little bit conflict :-) > >Ideally, you would be able to just retrieve this quirk from the > >connector or panel. Getting this property from your node vs. the port > >you are attached to should not be much harder. Either the connector > >struct can have this info or there can be a DT function that can walk > >the graph and get it. Just don't open code the graph traversal in your > >driver. > > > >>Beside I can not understand your example very well. Do you mean > >>that there are some HDMI monitor which also do not have HPD > >>signal (just like some eDP panel do not have hpd too), and then > >>the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want > >>to help in this case, would you mind show some sample code :-D > >I don't know that there is h/w, but it is always possible HPD is not > >hooked up or hooked up incorrectly some how. > > > >If there is no HPD support, then hpd-gpios is not going to help you. > > > >I think there are 3 cases to handle: > >- HPD handled by bridge chip - The bridge driver knows it has this > >capability. No DT properties are needed and no HPD properties on the > >connector node imply the bridge chip should handle HPD functions. > >- HPD handled by GPIO line (or some other block) - Indicated by > >hpd-gpios present > >- No or broken HPD - Indicated by "hpd-force" property. >=20 > Oh, I think the first/second case isn't suitable in this case, my panel > "cnm,n116bgeea2" haven't included HPD signal. Note that if your panel doesn't signal HPD you're supposed to poll the sink to make sure you catch loss of link integrity. I've always found it odd that people would want to save a couple of bucks on the HPD signal conductor when that means that you will consume more power because you need to periodically poll the link for integrity. > >>>Are there any eDP panels which don't have EDID and need panel details = in > >>>DT? > >> > >>Oh, I think you want to collect some info that belong to panel > >>property but no indicate in panel EDID message, so those can > >>be collect in eDP connector binding, is it right ? > >Yes, and as Thierry pointed out we may need to know the exact panel even. >=20 > Yeah, just like I reply to Thierry, this is a panel quirk. And he suggest= we > should > handle this in panel driver, but I have no idea how to handle this in com= mon > panel > driver. :) Like I said in another subthread, this panel does have an HPD line in a variant that I've used in the past. So if your variant doesn't have the HPD line, we're dealing with quirks within the same family of panels. That would make this some sort of quirk, and I'm not sure if there is a standard way for defining quirks in DT. Rob, do you know of any precedent for this? I suppose we could always add a variant-specific compatible string that would allow this quirk to be encoded in the driver, though I'm not sure if the model string in datasheets has enough detail to tell them apart. Thierry --XMCwj5IQnwKtuyBG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV7U0yAAoJEN0jrNd/PrOhdwEP/18HFrEGDwU/m9okI56Ou1X8 2ZIM5d2eK1+MDXTWoQsdAdd3uI2+Rt1gCjmalSBmAbOCqBuNTx3Y1OTJ6TgGdcPW /cdAoasKReOqCb5XOm2q+92tCbtCpA4htYEGBIwkwlPbm0krPzCO1FUMlkYzzDQx anNfpYsRJPDDMv6ebBVicBZuFobhp5xSUoUajQvrsESm9EBXlI0xeLuw4f6HltBX rEmz/KePlkNajjgKzC7sab3kAyRWgzbSdt4VgKm92HDvQPkK84SfzT/H1rmLwkyk KxRSWicF3o2/xFLlfikGQLKiO+k1gzIveEOO8RuIZTObF6xc/ePz1wMdQtfB0CzI pcH4xcRf8byU1mZeSsIa1aSOiHS1cBNpMsSdOCM3vr6L9ssA1OYXmPgZLoy7pcn+ WKKdOFNLC/VHG+B0VxlP7WyvLBURA0zQfYwPol6VESogdkbKfoNyGUbjkN7AdwHc dinPAIc2w+/aeIHXlGsEpxMpSBibJh+LdL/kyAAGoMMXBlPvmrYxo0oMxHXXL2Ph i4eWyJO6MkGrDZkOMPieRkxenl4U2M4P4cr9HeyajL/IAvENP66S9E+IRF5zHnf0 /IzOTw4augIeSeQpTYKNTeVg0SBi9jBCFPTWd+weaNBg5C5t27DhJxkZtd9wVyRK yfO1RRKg2fKgkMrNmOa4 =y65I -----END PGP SIGNATURE----- --XMCwj5IQnwKtuyBG--