Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1211694 > unrolled thread

Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Rob Herring <robherring2@gmail.com> - 2015-08-24 01:30 +0200
    Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-08-24 02:50 +0200
      Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-24 04:50 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-08-24 06:30 +0200
          Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-24 14:50 +0200
            Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Heiko Stuebner <heiko@sntech.de> - 2015-08-24 15:10 +0200
              Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 03:40 +0200
            Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-08-25 02:00 +0200
              Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-08-25 03:40 +0200
              Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 03:40 +0200
      Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Jingoo Han <jingoohan1@gmail.com> - 2015-08-24 09:50 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-24 15:00 +0200
    Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-24 04:30 +0200
    Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-08-24 15:00 +0200
      Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Rob Herring <robherring2@gmail.com> - 2015-08-24 16:50 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Heiko Stuebner <heiko@sntech.de> - 2015-08-24 18:20 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 03:30 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Thierry Reding <treding@nvidia.com> - 2015-08-25 11:20 +0200
          Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-08-25 11:40 +0200
            Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Thierry Reding <treding@nvidia.com> - 2015-08-25 12:50 +0200
              Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-08-25 13:00 +0200
          Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 11:50 +0200
            Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Thierry Reding <treding@nvidia.com> - 2015-08-25 12:10 +0200
              Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 16:10 +0200
    Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Thierry Reding <treding@nvidia.com> - 2015-08-25 11:20 +0200
      Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 11:40 +0200
      Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp Rob Herring <robherring2@gmail.com> - 2015-08-25 15:30 +0200
        Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Thierry Reding <treding@nvidia.com> - 2015-08-25 16:20 +0200
          Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for  analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-08-25 16:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1212953 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

On Tue, Aug 25, 2015 at 12:40:01PM +0200, Thierry Reding wrote:
> On Tue, Aug 25, 2015 at 10:29:39AM +0100, Russell King - ARM Linux wrote:
> > Now, what happens when some other DRM driver wants to use the tda998x
> > driver, and its bindings are not compatible with the component helpers?
> > They're pretty much stuck up the creek without a paddle.
> 
> I'm sure that will be very helpful response for whoever's going to end
> up having to deal with that situation.

Thank you for that comment, it's very constructive and much appreciated.
I can see it's well worth me continuing to spend time on this thread.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212915 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

Hi Thierry,

在 2015/8/25 17:12, Thierry Reding 写道:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
>> On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
>>>>> +       -analogix,color-depth:
>>>>> +               number of bits per colour component.
>>>>> +                       COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
>>>> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
>>>> drop the vendor prefix.
>>> Please think about this some more.  What does "color-depth" mean?  Does it
>>> mean the number of bits per colour _component_, or does it mean the total
>>> number of bits to represent a particular colour.  It's confusing as it
>>> stands.
>> Then "component-color-bpp" perhaps?
> There should be no need to have this in DT at all. The BPC is a property
> of the attached panel and it should come from the panel (either the
> panel driver or parsed from EDID if available).

Actually I have send an email about this one to you in version 2, just 
past from that email:

"samsung,color_space" and "samsung,color-depth"

The drm_display_info's color_formats and bpc indicate the monitor 
display ability, but
the edp driver could not take it as input video format directly.

For example, with my DP TV I would found "RGB444 & YCRCB422 & & YCRCB444"
support in drm_display_info.color_formats and 16bit bpc support, but 
RK3288 crtc
driver could only output RGB & ITU formats, so finally 
analogix_dp-rockchip driver
config crtc to RGBaaa 10bpc mode.

In this sutiation, the analogix_dp core driver would pazzled by the 
drm_display_info,
can't chose the right color_space and bpc.

And this is the place that confused me, wish you could give some ideas 
about this one :-)

- Yakir
>>> When we adopted the graph bindings for iMX DRM, I thought exactly at that
>>> time "it would be nice if this could become the standard for binding DRM
>>> components together" but I don't have the authority from either the DT
>>> perspective or the DRM perspective to mandate that.  Neither does anyone
>>> else.  That's the _real_ problem here.
>>>
>>> I've seen several DRM bindings go by which don't use the of-graph stuff,
>>> which means that they'll never be compatible with generic components
>>> which do use the of-graph stuff.
>> It goes beyond bindings IMO. The use of the component framework or not
>> has been at the whim of driver writers as well. It is either used or
>> private APIs are created. I'm using components and my need for it
>> boils down to passing the struct drm_device pointer to the encoder.
>> Other components like panels and bridges have different ways to attach
>> to the DRM driver.
> I certainly support unification, but it needs to be reasonable. There
> are cases where a different structure for the binding work better than
> another and I think this always needs to be evaluated on a case by case
> basis.
>
> Because of that I think it makes sense to make all these framework bits
> opt-in, otherwise we could easily end up in a situation where drivers
> have to be rearchitected (or even DT bindings altered!) in order to be
> able to reuse code.
>
> Thierry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212923 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 25, 2015 at 05:41:19PM +0800, Yakir Yang wrote:
> Hi Thierry,
> 
> 在 2015/8/25 17:12, Thierry Reding 写道:
> >On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> >>On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
> >><linux@arm.linux.org.uk> wrote:
> >>>On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
> >>>>On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
> >>>>>+       -analogix,color-depth:
> >>>>>+               number of bits per colour component.
> >>>>>+                       COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> >>>>This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
> >>>>drop the vendor prefix.
> >>>Please think about this some more.  What does "color-depth" mean?  Does it
> >>>mean the number of bits per colour _component_, or does it mean the total
> >>>number of bits to represent a particular colour.  It's confusing as it
> >>>stands.
> >>Then "component-color-bpp" perhaps?
> >There should be no need to have this in DT at all. The BPC is a property
> >of the attached panel and it should come from the panel (either the
> >panel driver or parsed from EDID if available).
> 
> Actually I have send an email about this one to you in version 2, just past
> from that email:
> 
> "samsung,color_space" and "samsung,color-depth"
> 
> The drm_display_info's color_formats and bpc indicate the monitor display
> ability, but
> the edp driver could not take it as input video format directly.
> 
> For example, with my DP TV I would found "RGB444 & YCRCB422 & & YCRCB444"
> support in drm_display_info.color_formats and 16bit bpc support, but RK3288
> crtc
> driver could only output RGB & ITU formats, so finally analogix_dp-rockchip
> driver
> config crtc to RGBaaa 10bpc mode.
> 
> In this sutiation, the analogix_dp core driver would pazzled by the
> drm_display_info,
> can't chose the right color_space and bpc.
> 
> And this is the place that confused me, wish you could give some ideas about
> this one :-)

Your display driver should choose whatever it is capable of outputting.
If the display reports that it can do 16 bits-per-color, but your
display driver can't do it, then it should choose a configuration that
it supports. Similarily for the color encodings. If you can't generate
YCrCb444 with your hardware, then it's the driver's job to know about
that and select the next appropriate configuration.

But hard-coding this is not the right solution because the value in DT
may end up conflicting with what the display reports.

Thierry

[toc] | [prev] | [next] | [standalone]

#1213058 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

Hi Thierry,

在 2015/8/25 18:06, Thierry Reding 写道:
> On Tue, Aug 25, 2015 at 05:41:19PM +0800, Yakir Yang wrote:
>> Hi Thierry,
>>
>> 在 2015/8/25 17:12, Thierry Reding 写道:
>>> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
>>>> On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
>>>> <linux@arm.linux.org.uk> wrote:
>>>>> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>>>>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
>>>>>>> +       -analogix,color-depth:
>>>>>>> +               number of bits per colour component.
>>>>>>> +                       COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
>>>>>> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
>>>>>> drop the vendor prefix.
>>>>> Please think about this some more.  What does "color-depth" mean?  Does it
>>>>> mean the number of bits per colour _component_, or does it mean the total
>>>>> number of bits to represent a particular colour.  It's confusing as it
>>>>> stands.
>>>> Then "component-color-bpp" perhaps?
>>> There should be no need to have this in DT at all. The BPC is a property
>>> of the attached panel and it should come from the panel (either the
>>> panel driver or parsed from EDID if available).
>> Actually I have send an email about this one to you in version 2, just past
>> from that email:
>>
>> "samsung,color_space" and "samsung,color-depth"
>>
>> The drm_display_info's color_formats and bpc indicate the monitor display
>> ability, but
>> the edp driver could not take it as input video format directly.
>>
>> For example, with my DP TV I would found "RGB444 & YCRCB422 & & YCRCB444"
>> support in drm_display_info.color_formats and 16bit bpc support, but RK3288
>> crtc
>> driver could only output RGB & ITU formats, so finally analogix_dp-rockchip
>> driver
>> config crtc to RGBaaa 10bpc mode.
>>
>> In this sutiation, the analogix_dp core driver would pazzled by the
>> drm_display_info,
>> can't chose the right color_space and bpc.
>>
>> And this is the place that confused me, wish you could give some ideas about
>> this one :-)
> Your display driver should choose whatever it is capable of outputting.
> If the display reports that it can do 16 bits-per-color, but your
> display driver can't do it, then it should choose a configuration that
> it supports. Similarily for the color encodings. If you can't generate
> YCrCb444 with your hardware, then it's the driver's job to know about
> that and select the next appropriate configuration.
>
> But hard-coding this is not the right solution because the value in DT
> may end up conflicting with what the display reports.

Yeah, thanks for your explain, you are right. It's the best way to get 
"color-depth"
and "color-space" from display driver, not to hard-code in DT prop.

But if the common analogix-dp driver want to get those values, then 
those values
should come from the common drm struct data. Personally I think "struct 
drm_crtc"
is the best place that should indicate the output ability of SoC vop/lcdc.

But I haven't find out there are some place to store those message for 
now (I don't
think it's good to modify the original color-space and color-bpc which 
parsed from
monitor edid).

So could you share sme ideas about this, and I would rather to talk with 
Mark (Author
of rockchip drm driver) to find out the better way to fix this one.

Besides, I would appreciate very much if you can share some ideas about 
how Exynos
handler with this problem ;)

Thanks,
- Yakir
> Thierry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212867 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
[...]
> > +       -analogix,link-rate:
> > +               max link rate supported by the eDP controller.
> > +                       LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
> > +                       LINK_RATE_5_40GBPS = 0x14
> 
> Same here. I'd rather see something like "link-rate-mbps" and use the
> actual rate.

There is no need whatsoever to hard-code this in DT. (e)DP provides the
means to detect what rate the link supports and the specification
provides guidance on how to select an appropriate one.

> 
> > +       -analogix,lane-count:
> > +               max number of lanes supported by the eDP contoller.
> > +                       LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> 
> And drop the vendor prefix here.

Same as for the link rate.

Thierry

[toc] | [prev] | [next] | [standalone]

#1212913 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

Hi Thierry,

在 2015/8/25 17:15, Thierry Reding 写道:
> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
> [...]
>>> +       -analogix,link-rate:
>>> +               max link rate supported by the eDP controller.
>>> +                       LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
>>> +                       LINK_RATE_5_40GBPS = 0x14
>> Same here. I'd rather see something like "link-rate-mbps" and use the
>> actual rate.
> There is no need whatsoever to hard-code this in DT. (e)DP provides the
> means to detect what rate the link supports and the specification
> provides guidance on how to select an appropriate one.

Hmm... could you share more about this :-)

I only find that drm_dp_link_probe() could get the panel link-rate and
num-lanes by reading the DP_DPCD_REV messag.

I don't found there are some guidance to help select the approriate one.
Beside this DT prop just indicate the max eDP controller link-rate & lanes
support, how could eDP detect them automatically?

- Yakir

>>> +       -analogix,lane-count:
>>> +               max number of lanes supported by the eDP contoller.
>>> +                       LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
>> And drop the vendor prefix here.
> Same as for the link rate.
>
> Thierry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213036

On Tue, Aug 25, 2015 at 4:15 AM, Thierry Reding <treding@nvidia.com> wrote:
> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
> [...]
>> > +       -analogix,link-rate:
>> > +               max link rate supported by the eDP controller.
>> > +                       LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
>> > +                       LINK_RATE_5_40GBPS = 0x14
>>
>> Same here. I'd rather see something like "link-rate-mbps" and use the
>> actual rate.
>
> There is no need whatsoever to hard-code this in DT. (e)DP provides the
> means to detect what rate the link supports and the specification
> provides guidance on how to select an appropriate one.

Good, even better.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213063 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 25, 2015 at 09:48:01PM +0800, Yakir Yang wrote:
> Hi Thierry & Rob,
> 
> 在 2015/8/25 21:27, Rob Herring 写道:
> >On Tue, Aug 25, 2015 at 4:15 AM, Thierry Reding <treding@nvidia.com> wrote:
> >>On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
> >>>On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
> >>[...]
> >>>>+       -analogix,link-rate:
> >>>>+               max link rate supported by the eDP controller.
> >>>>+                       LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
> >>>>+                       LINK_RATE_5_40GBPS = 0x14
> >>>Same here. I'd rather see something like "link-rate-mbps" and use the
> >>>actual rate.
> >>There is no need whatsoever to hard-code this in DT. (e)DP provides the
> >>means to detect what rate the link supports and the specification
> >>provides guidance on how to select an appropriate one.
> >Good, even better.
> 
> I do think we still need keep this DT prop yet.
> 
> I think drm_dp_help.c could get the "panel" max link-rate and lane-count,
> but it's not enough, we still need knew the "eDP controller" max link-rate
> and lane-count.
> 
> Let me show the exact example that happened in my side. When I connect
> my board to my 2K DP-1.2 TV. Analogix dp driver would get the max link-rate
> from dpcd, and the max link-rate is 5.4Gbps. So if I just set eDP controller
> link-rate
> to 5.4Gbps, the DP TV just broken, do not light up normally.
> 
> This reason why TV broken is the max link-rate which support by RK3288 eDP
> controller is 2.7Gbps. Here are the exact words that RK3288 eDP TRM said:
> 
> *Compliant with DisplayPortTM Specification, Version 1.2.
> Compliant with eDPTM Specification, Version 1.3.
> HDCP v1.3 amendment for DisplayPortTM Revision 1.0.
> Main link containing 4 physical lanes of 2.7/1.62 Gbps/lane
> *
> **
> 
> 
> Beside I haven't found there are some registers would indicate the eDP
> controller
> max link-rate and lane-count, so this is why I still instance that we need
> this DT
> prop to indicata "Max rate controller support".
> 
> So, I wish you could agree with me on this point.

Your driver should know what link rates it supports and restrict itself
to use those. This is implied by the compatible string and doesn't need
to be duplicated into device tree.

Thierry

[toc] | [prev] | [next] | [standalone]

#1213080 — Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp

Hi Thierry,

在 2015/8/25 22:16, Thierry Reding 写道:
> On Tue, Aug 25, 2015 at 09:48:01PM +0800, Yakir Yang wrote:
>> Hi Thierry & Rob,
>>
>> 在 2015/8/25 21:27, Rob Herring 写道:
>>> On Tue, Aug 25, 2015 at 4:15 AM, Thierry Reding <treding@nvidia.com> wrote:
>>>> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>>>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@rock-chips.com> wrote:
>>>> [...]
>>>>>> +       -analogix,link-rate:
>>>>>> +               max link rate supported by the eDP controller.
>>>>>> +                       LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
>>>>>> +                       LINK_RATE_5_40GBPS = 0x14
>>>>> Same here. I'd rather see something like "link-rate-mbps" and use the
>>>>> actual rate.
>>>> There is no need whatsoever to hard-code this in DT. (e)DP provides the
>>>> means to detect what rate the link supports and the specification
>>>> provides guidance on how to select an appropriate one.
>>> Good, even better.
>> I do think we still need keep this DT prop yet.
>>
>> I think drm_dp_help.c could get the "panel" max link-rate and lane-count,
>> but it's not enough, we still need knew the "eDP controller" max link-rate
>> and lane-count.
>>
>> Let me show the exact example that happened in my side. When I connect
>> my board to my 2K DP-1.2 TV. Analogix dp driver would get the max link-rate
>> from dpcd, and the max link-rate is 5.4Gbps. So if I just set eDP controller
>> link-rate
>> to 5.4Gbps, the DP TV just broken, do not light up normally.
>>
>> This reason why TV broken is the max link-rate which support by RK3288 eDP
>> controller is 2.7Gbps. Here are the exact words that RK3288 eDP TRM said:
>>
>> *Compliant with DisplayPortTM Specification, Version 1.2.
>> Compliant with eDPTM Specification, Version 1.3.
>> HDCP v1.3 amendment for DisplayPortTM Revision 1.0.
>> Main link containing 4 physical lanes of 2.7/1.62 Gbps/lane
>> *
>> **
>>
>>
>> Beside I haven't found there are some registers would indicate the eDP
>> controller
>> max link-rate and lane-count, so this is why I still instance that we need
>> this DT
>> prop to indicata "Max rate controller support".
>>
>> So, I wish you could agree with me on this point.
> Your driver should know what link rates it supports and restrict itself
> to use those. This is implied by the compatible string and doesn't need
> to be duplicated into device tree.

Oh, yeah, good idea   :-D
Thanks for your point out.

- Yakir

> Thierry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web