From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758585AbbIDKCH (ORCPT ); Fri, 4 Sep 2015 06:02:07 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:10439 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758522AbbIDKCE (ORCPT ); Fri, 4 Sep 2015 06:02:04 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Fri, 04 Sep 2015 02:57:46 -0700 Date: Fri, 4 Sep 2015 12:01:48 +0200 From: Thierry Reding To: Rob Herring CC: Yakir Yang , 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: <20150904100147.GE22056@ulmo.nvidia.com> References: <1441086371-24838-1-git-send-email-ykk@rock-chips.com> <1441088079-25809-1-git-send-email-ykk@rock-chips.com> <20150903084735.GB3784@ulmo.nvidia.com> MIME-Version: 1.0 In-Reply-To: X-NVConfidentiality: public User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) X-Originating-IP: [10.2.71.9] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 04:55:59PM -0500, Rob Herring wrote: > On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding wrote: > > On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote: > > [...] > >> Are there any eDP panels which don't have EDID and need panel details = in DT? > > > > Most panels need information other than EDID. They typically have some > > requirements regarding the power up sequence that aren't to be found > > anywhere in EDID or detectable by some other mechanism. A decision was > > therefore made a long time ago to require panels to be listed in DT with > > a specific compatible string. That way all of these details can be > > stashed away in drivers that know how to deal with these kinds of > > details. >=20 > I guess I was being hopeful that eDP was improving that situation. Unfortunately not. eDP helps with a number of things (DPCD and link training take care of a lot of the issues), but it doesn't provide a solution for everything. To my knowledge in most cases the power up sequence isn't strictly necessary to get the panel to operate. But there have been instances where this is absolutely required if you want to avoid visual artifacts as you set a mode. A lot of panels that I've come across require receiving a couple of frames before they guarantee that something will actually be displayed on the screen. So if your code is too quickly enabling backlight, and your backlight doesn't happen to have just the right amount of ramp-up time you might end up seeing garbage on the screen for a couple of frames. It would be great if somebody came up with, say, an EDID extension to describe these requirements, but I'm not sure if even that would give us panels that could be driven with a generic driver. Often the power supplies or reset/enable signals are very different across panels. So describing it all generically would become messy rather quickly. Thierry --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV6WwIAAoJEN0jrNd/PrOhupUP/R8NGiS4+QlVvgcwjg8bApv3 4t98ttuU/sxl3qA5V2PXkq5GCuPByrAoFRV+hqvabfOYV6EYTpe8SoCjoBcuipzP 3dXdV5Wo/MCIAdFEsf2rasZve4RLAxyJt0VGkc3hEXiNmC1TKzJmWe9utLDGxmbL 7bPfj4izEu3Z8MqIadao95PiVUyN3U1rtOB0BwzLZg5nQv+YnzB1t+rXhc2nqsCn bXs7F9CMrw7sHtPTPe1JwnWxNWfECaqOJ25UrN5T2mus1+X7/nkVQa2VoiltMAD/ BayxfsjWXr6bbGSE+WYLDP2oRfNxcfSGBP+sU5yrUHnkw6domsxAmOdd5buMRhpi 84JoAtePV0jeNQNzG1kP+OAQ7Ug3pxHS9WkqoNAGNUB3PwJ1aF25+aRG+5KSj9ct i7CPDoYRjz88TxMEaoG41zOkCedcyGAJYdCtFneCDhP1cvX1NECIt7toA6252/yQ Qbvyq/3xTHSOkzJWhkLlMGUoqWa99wdAPzklfSGtEIVY2uNUljGTT6bPKxeZcWfA dPWCY+ER+iLRPJw9zqfSzULAafXZcmjQxQqU5OxUQQ3u4yUmjS6wY6rTbnZ1t5dc fEYRMvqIAC62vnlLq+2k7aNI5kcUXvpaCBet/dlaeUYyMw5DDFGNzdCMGSxz6K++ nCEyQGo/n0DNQU9bnz01 =fFha -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed Date: Fri, 4 Sep 2015 12:01:48 +0200 Message-ID: <20150904100147.GE22056@ulmo.nvidia.com> References: <1441086371-24838-1-git-send-email-ykk@rock-chips.com> <1441088079-25809-1-git-send-email-ykk@rock-chips.com> <20150903084735.GB3784@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Return-path: In-Reply-To: Content-Disposition: inline Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Yakir Yang , Heiko Stuebner , Jingoo Han , Inki Dae , Joe Perches , Kukjin Kim , Krzysztof Kozlowski , Mark Yao , Russell King , djkurtz-F7+t8E8rja9Wk0Htik3J/w@public.gmane.org, dianders-F7+t8E8rja9Wk0Htik3J/w@public.gmane.org, seanpaul-F7+t8E8rja9Wk0Htik3J/w@public.gmane.org, Ajay kumar , Andrzej Hajda , Kyungmin Park , David Airlie , Gustavo Padovan , Andy Yan , Kumar Gala , Ian Campbell , Rob Herring , Pawel Moll , Kishon Vijay Abraham I , architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, dri-devel List-Id: devicetree@vger.kernel.org --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2015 at 04:55:59PM -0500, Rob Herring wrote: > On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding wrote: > > On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote: > > [...] > >> Are there any eDP panels which don't have EDID and need panel details = in DT? > > > > Most panels need information other than EDID. They typically have some > > requirements regarding the power up sequence that aren't to be found > > anywhere in EDID or detectable by some other mechanism. A decision was > > therefore made a long time ago to require panels to be listed in DT with > > a specific compatible string. That way all of these details can be > > stashed away in drivers that know how to deal with these kinds of > > details. >=20 > I guess I was being hopeful that eDP was improving that situation. Unfortunately not. eDP helps with a number of things (DPCD and link training take care of a lot of the issues), but it doesn't provide a solution for everything. To my knowledge in most cases the power up sequence isn't strictly necessary to get the panel to operate. But there have been instances where this is absolutely required if you want to avoid visual artifacts as you set a mode. A lot of panels that I've come across require receiving a couple of frames before they guarantee that something will actually be displayed on the screen. So if your code is too quickly enabling backlight, and your backlight doesn't happen to have just the right amount of ramp-up time you might end up seeing garbage on the screen for a couple of frames. It would be great if somebody came up with, say, an EDID extension to describe these requirements, but I'm not sure if even that would give us panels that could be driven with a generic driver. Often the power supplies or reset/enable signals are very different across panels. So describing it all generically would become messy rather quickly. Thierry --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV6WwIAAoJEN0jrNd/PrOhupUP/R8NGiS4+QlVvgcwjg8bApv3 4t98ttuU/sxl3qA5V2PXkq5GCuPByrAoFRV+hqvabfOYV6EYTpe8SoCjoBcuipzP 3dXdV5Wo/MCIAdFEsf2rasZve4RLAxyJt0VGkc3hEXiNmC1TKzJmWe9utLDGxmbL 7bPfj4izEu3Z8MqIadao95PiVUyN3U1rtOB0BwzLZg5nQv+YnzB1t+rXhc2nqsCn bXs7F9CMrw7sHtPTPe1JwnWxNWfECaqOJ25UrN5T2mus1+X7/nkVQa2VoiltMAD/ BayxfsjWXr6bbGSE+WYLDP2oRfNxcfSGBP+sU5yrUHnkw6domsxAmOdd5buMRhpi 84JoAtePV0jeNQNzG1kP+OAQ7Ug3pxHS9WkqoNAGNUB3PwJ1aF25+aRG+5KSj9ct i7CPDoYRjz88TxMEaoG41zOkCedcyGAJYdCtFneCDhP1cvX1NECIt7toA6252/yQ Qbvyq/3xTHSOkzJWhkLlMGUoqWa99wdAPzklfSGtEIVY2uNUljGTT6bPKxeZcWfA dPWCY+ER+iLRPJw9zqfSzULAafXZcmjQxQqU5OxUQQ3u4yUmjS6wY6rTbnZ1t5dc fEYRMvqIAC62vnlLq+2k7aNI5kcUXvpaCBet/dlaeUYyMw5DDFGNzdCMGSxz6K++ nCEyQGo/n0DNQU9bnz01 =fFha -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: treding@nvidia.com (Thierry Reding) Date: Fri, 4 Sep 2015 12:01:48 +0200 Subject: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed In-Reply-To: References: <1441086371-24838-1-git-send-email-ykk@rock-chips.com> <1441088079-25809-1-git-send-email-ykk@rock-chips.com> <20150903084735.GB3784@ulmo.nvidia.com> Message-ID: <20150904100147.GE22056@ulmo.nvidia.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Sep 03, 2015 at 04:55:59PM -0500, Rob Herring wrote: > On Thu, Sep 3, 2015 at 3:47 AM, Thierry Reding wrote: > > On Wed, Sep 02, 2015 at 03:17:57PM -0500, Rob Herring wrote: > > [...] > >> Are there any eDP panels which don't have EDID and need panel details in DT? > > > > Most panels need information other than EDID. They typically have some > > requirements regarding the power up sequence that aren't to be found > > anywhere in EDID or detectable by some other mechanism. A decision was > > therefore made a long time ago to require panels to be listed in DT with > > a specific compatible string. That way all of these details can be > > stashed away in drivers that know how to deal with these kinds of > > details. > > I guess I was being hopeful that eDP was improving that situation. Unfortunately not. eDP helps with a number of things (DPCD and link training take care of a lot of the issues), but it doesn't provide a solution for everything. To my knowledge in most cases the power up sequence isn't strictly necessary to get the panel to operate. But there have been instances where this is absolutely required if you want to avoid visual artifacts as you set a mode. A lot of panels that I've come across require receiving a couple of frames before they guarantee that something will actually be displayed on the screen. So if your code is too quickly enabling backlight, and your backlight doesn't happen to have just the right amount of ramp-up time you might end up seeing garbage on the screen for a couple of frames. It would be great if somebody came up with, say, an EDID extension to describe these requirements, but I'm not sure if even that would give us panels that could be driven with a generic driver. Often the power supplies or reset/enable signals are very different across panels. So describing it all generically would become messy rather quickly. Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: