From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752105AbbIFIV7 (ORCPT ); Sun, 6 Sep 2015 04:21:59 -0400 Received: from lucky1.263xmail.com ([211.157.147.131]:57209 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbbIFIVv (ORCPT ); Sun, 6 Sep 2015 04:21:51 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: ykk@rock-chips.com X-FST-TO: linux-arm-kernel@lists.infradead.org X-SENDER-IP: 172.245.202.19 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: <1fe9ddb3310cff54d603491be5fb2a13> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 5 Message-ID: <55EBF757.20108@rock-chips.com> Date: Sun, 06 Sep 2015 16:20:39 +0800 From: Yakir Yang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Rob Herring CC: Heiko Stuebner , Thierry Reding , Jingoo Han , Inki Dae , Joe Perches , Kukjin Kim , Krzysztof Kozlowski , Mark Yao , Russell King , djkurtz@chromium.com, dianders@chromium.com, seanpaul@chromium.com, 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@codeaurora.org, dri-devel , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-samsung-soc@vger.kernel.org" , linux-rockchip@lists.infradead.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 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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, 在 09/05/2015 05:46 AM, Rob Herring 写道: > On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote: >> Hi Rob, >> >> 在 09/03/2015 04:17 AM, Rob Herring 写道: >>> 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 specific >> 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. Oh, I think the first/second case isn't suitable in this case, my panel "cnm,n116bgeea2" haven't included HPD signal. > >>> 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. 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 common panel driver. :) - Yakir > Rob > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yakir Yang Subject: Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed Date: Sun, 06 Sep 2015 16:20:39 +0800 Message-ID: <55EBF757.20108@rock-chips.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Heiko Stuebner , Thierry Reding , 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 Hi Rob, =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 wrot= e: >> 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 wro= te: >>>> 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 an= d >>> not specific to this chip. We could have an HDMI connector and fail= ed >>> to hook up HPD for example. A connector node is also where hpd-gpio= s >>> should be located instead (and are already defined by >>> ../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connec= tor >>> binding, too. >> >> Yep, I agree with your front point, it is a property of panel, not s= pecific >> 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 analogi= x_dp >> code and meet this "no-hpd" situation, then they would need duplica= te >> to parse this property and fill the hook in analogix_dp_core.c drive= r. >> 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 you= r > 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. Oh, I think the first/second case isn't suitable in this case, my panel "cnm,n116bgeea2" haven't included HPD signal. > >>> Are there any eDP panels which don't have EDID and need panel detai= ls 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 e= ven. Yeah, just like I reply to Thierry, this is a panel quirk. And he=20 suggest we should handle this in panel driver, but I have no idea how to handle this in=20 common panel driver. :) - Yakir > Rob > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n 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: ykk@rock-chips.com (Yakir Yang) Date: Sun, 06 Sep 2015 16:20:39 +0800 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> <55E7CC43.7040608@rock-chips.com> Message-ID: <55EBF757.20108@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Rob, ? 09/05/2015 05:46 AM, Rob Herring ??: > On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote: >> Hi Rob, >> >> ? 09/03/2015 04:17 AM, Rob Herring ??: >>> 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 specific >> 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. Oh, I think the first/second case isn't suitable in this case, my panel "cnm,n116bgeea2" haven't included HPD signal. > >>> 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. 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 common panel driver. :) - Yakir > Rob > > >