All of lore.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Inki Dae <daeinki@gmail.com>, Daniel Stone <daniel@fooishbar.org>
Cc: Kevin Hilman <khilman@linaro.org>,
	Tyler Baker <tyler.baker@linaro.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	DRI mailing list <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 0/7] drm/exynos: add pm runtime support
Date: Mon, 23 Nov 2015 09:25:55 -0300	[thread overview]
Message-ID: <565305D3.8060006@osg.samsung.com> (raw)
In-Reply-To: <CAAQKjZNBeW9u6CtuL__mej1QLGV53Ft2A_RxPz8RMuda0wegLg@mail.gmail.com>

Hello,

On 11/21/2015 11:59 AM, Inki Dae wrote:
> Hi Daniel,
> 
> 
> 2015-11-21 22:40 GMT+09:00 Daniel Stone <daniel@fooishbar.org>:
>> Hi Inki,
>>
>> On 21 November 2015 at 09:38, Inki Dae <daeinki@gmail.com> wrote:
>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas <javier@osg.samsung.com>:
>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>> The boot log says,
>>>>> [    5.754493] vdd_ldo9: supplied by vdd_2v
>>>>> [    5.765510] of_graph_get_next_endpoint(): no port node found in /dp-controller@145B0000
>>>>>
>>>>
>>>> This message is a red herring for the reported issue, the message is also
>>>> present when the machine boots and the display is brought correctly.
>>>>
>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have 'ports' node in dp node.
>>>>>
>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>> &dp {
>>>>>       status = "okay";
>>>>>       pinctrl-names = "default";
>>>>>       pinctrl-0 = <&dp_hpd_gpio>;
>>>>>       samsung,color-space = <0>;
>>>>>       samsung,dynamic-range = <0>;
>>>>>       samsung,ycbcr-coeff = <0>;
>>>>>       samsung,color-depth = <1>;
>>>>>       samsung,link-rate = <0x06>;
>>>>>       samsung,lane-count = <2>;
>>>>>       samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
>>>>>
>>>>>       ports {
>>>>>               port@0 {
>>>>>                       dp_out: endpoint {
>>>>>                               remote-endpoint = <&bridge_in>;
>>>>>                       };
>>>>>               };
>>>>>       };
>>>>> };
>>>>>
>>>>> And below is for exynos5800-peash-pit.dts,
>>>>> &dp {
>>>>>       status = "okay";
>>>>>       pinctrl-names = "default";
>>>>>       pinctrl-0 = <&dp_hpd_gpio>;
>>>>>       samsung,color-space = <0>;
>>>>>       samsung,dynamic-range = <0>;
>>>>>       samsung,ycbcr-coeff = <0>;
>>>>>       samsung,color-depth = <1>;
>>>>>       samsung,link-rate = <0x0a>;
>>>>>       samsung,lane-count = <2>;
>>>>>       samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
>>>>>       panel = <&panel>;
>>>>> };
>>>>>
>>>>
>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>
>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>> that points to the panel.
>>>>
>>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>
>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800 Peach PI
>>> board doesn't use eDP, then the dp node __should be removed__ from
>>> exynos5800-peach-pit.dts.
>>>
>>> From a common-sense standpoint, there is no any reason to build
>>> and probe dp driver if the board doesn't use dp hardware.
>>
>> I agree with what you say, but unfortunately you've slightly misread
>> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
>> the eDP -> LVDS bridge in between (ps8622). exynos5800-peach-pi (from
>> which I am writing this) has an eDP panel directly connected. The DT

Thanks a lot Daniel for clarifying my comments to Inki :)

>> describes both the eDP connector from FIMD and the eDP panel, except
>> that there is no connection between the DT nodes.

There *is* a connection between the FIMD eDP connector and the eDP panel
nodes but these are connected using a phandle while the connection for
the FIMD eDP connector and the eDP/LVDS bridge is using the OF graph DT
bindings (Documentation/devicetree/bindings/graph.txt).

And also the connection between the eDP/LVDS bridge and the LVDS panel
is using an OF graph node, so what I meant is that it would be much more
consistent if both the eDP -> panel and eDP -> eDP/LVDS bridge -> panel
connections used the OF graph DT bindings.

>
> Right. I misread what Javier said. :)
>
>>
>>>> error if the port so OF graph endpoints it seems can't be optional as
>>>> used in this driver. Maybe that message should be change to debug then?
>>>>
>>>> Another option is to extend the DP driver DT binding to be more generic
>>>> supporting having a port to a panel besides a bridge, so we could have
>>>> something like this for Exynos5800 Peach and be consistent in both cases:
>>>
>>> It's really not good. This would make it more complex. The best
>>> solution is just to
>>> remove the dt node from the device tree file.
>>
>> Given the above, not really. Javier's patch seems correct to me - as
>> you can see, there is a panel node, and that is the panel that's
>> really connected.
> 
> Indeed. Javier's patch will correct it.
>

Just to be clear, my patch is not correct since the Exynos DP driver and
its DT binding does not support to connect an FIMD eDP connector to an
eDP panel directly using OF graph ports / endpoints (only a phandle). But
is an example of how the DT will look like if we extend to support that.

IIRC at the beginning only eDP -> panel was supported and the phandle
was used and later when the eDP -> eDP/LVDS bridge -> LVDS panel use
case was needed, then a bridge phandle was added but Ajay was asked to
use OF graph instead a phandle and we ended with different approaches
to connect components depending if a bridge is used or not.

> Thanks,
> Inki Dae
> 
>>
>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>> @@ -122,6 +122,12 @@
>>>>                 compatible = "auo,b133htn01";
>>>>                 power-supply = <&tps65090_fet6>;
>>>>                 backlight = <&backlight>;
>>>> +
>>>> +               port {
>>>> +                       panel_in: endpoint {
>>>> +                               remote-endpoint = <&dp_out>;
>>>> +                       };
>>>> +               };
>>>>         };
>>>>
>>>>         mmc1_pwrseq: mmc1_pwrseq {
>>>> @@ -148,7 +154,14 @@
>>>>         samsung,link-rate = <0x0a>;
>>>>         samsung,lane-count = <2>;
>>>>         samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
>>>> -       panel = <&panel>;
>>>> +
>>>> +       ports {
>>>> +               port@0 {
>>>> +                       dp_out: endpoint {
>>>> +                               remote-endpoint = <&panel_in>;
>>>> +                       };
>>>> +               };
>>>> +       };
>>>>  };
>>
>> Cheers,
>> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

  reply	other threads:[~2015-11-23 12:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 10:47 [PATCH v2 0/7] drm/exynos: add pm runtime support Inki Dae
2015-11-03 10:47 ` [PATCH v2 1/7] drm/exynos: do not start enabling DP at bind() phase Inki Dae
2015-11-03 10:47 ` [PATCH v2 2/7] drm/exynos: add pm_runtime to DP Inki Dae
2015-11-03 10:47 ` [PATCH v2 3/7] drm/exynos: add pm_runtime to HDMI Inki Dae
2015-11-03 10:47 ` [PATCH v2 4/7] drm/exynos: add pm_runtime to Mixer Inki Dae
2015-11-03 10:47 ` [PATCH v2 5/7] drm/exynos: add pm_runtime to FIMD Inki Dae
2015-11-03 10:47 ` [PATCH v2 6/7] drm/exynos: add pm_runtime to DECON 5433 Inki Dae
2015-11-03 10:47 ` [PATCH v2 7/7] drm/exynos: add pm_runtime to DECON 7 Inki Dae
2015-11-03 13:24 ` [PATCH v2 0/7] drm/exynos: add pm runtime support Andrzej Hajda
2015-11-03 15:38   ` Inki Dae
2015-11-04  7:24     ` Andrzej Hajda
2015-11-04  7:56       ` Inki Dae
2015-11-04 10:13         ` Andrzej Hajda
2015-11-04 11:46           ` Inki Dae
2015-11-19 14:51 ` Javier Martinez Canillas
2015-11-19 14:55   ` Javier Martinez Canillas
2015-11-19 15:51     ` Javier Martinez Canillas
2015-11-20 10:59       ` Inki Dae
2015-11-20 11:13         ` Inki Dae
2015-11-20 16:44           ` Javier Martinez Canillas
2015-11-21  9:38             ` Inki Dae
2015-11-21 13:40               ` Daniel Stone
2015-11-21 14:59                 ` Inki Dae
2015-11-23 12:25                   ` Javier Martinez Canillas [this message]
2015-11-23 16:47                     ` Inki Dae
2015-11-23 18:38                       ` Javier Martinez Canillas
2015-11-24  2:28                         ` Inki Dae
2015-11-24 13:19                           ` Javier Martinez Canillas
2015-11-25 15:52                             ` Inki Dae
2015-11-20 16:23         ` Javier Martinez Canillas
2015-11-21  9:40           ` Inki Dae

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=565305D3.8060006@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=daeinki@gmail.com \
    --cc=daniel@fooishbar.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=khilman@linaro.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=tyler.baker@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.