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

Groups > linux.kernel > #1229939 > unrolled thread

[PATCH v5 0/17] Add Analogix Core Display Port Driver

Started byYakir Yang <ykk@rock-chips.com>
First post2015-09-22 09:30 +0200
Last post2015-09-30 09:00 +0200
Articles 7 on this page of 27 — 2 participants

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

  [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:30 +0200
    [PATCH v5 01/17] drm: exynos: dp: convert to drm bridge mode Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:30 +0200
    [PATCH v5 03/17] drm: bridge: analogix/dp: fix some obvious code style Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:40 +0200
      Re: [PATCH v5 03/17] drm: bridge: analogix/dp: fix some obvious code  style Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 07:30 +0200
        Re: [PATCH v5 03/17] drm: bridge: analogix/dp: fix some obvious code  style Yakir Yang <ykk@rock-chips.com> - 2015-09-30 09:00 +0200
    [PATCH v5 06/17] Documentation: drm/bridge: add document for analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:50 +0200
    [PATCH v5 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:50 +0200
      Re: [PATCH v5 07/17] ARM: dts: exynos/dp: remove some properties that  deprecated by analogix_dp driver Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 07:40 +0200
        Re: [PATCH v5 07/17] ARM: dts: exynos/dp: remove some properties  that deprecated by analogix_dp driver Yakir Yang <ykk@rock-chips.com> - 2015-09-30 09:40 +0200
    [PATCH v5 09/17] Documentation: drm/bridge: add document for analogix_dp Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:50 +0200
    [PATCH v5 04/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:50 +0200
    [PATCH v5 08/17] drm: rockchip: dp: add rockchip platform dp driver Yakir Yang <ykk@rock-chips.com> - 2015-09-22 09:50 +0200
    [PATCH v5 11/17] Documentation: phy: add document for rockchip dp phy Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:00 +0200
    [PATCH v5 10/17] phy: Add driver for rockchip Display Port PHY Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:00 +0200
    [PATCH v5 12/17] drm: rockchip: vop: add bpc and color mode setting Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:00 +0200
    [PATCH v5 13/17] drm: bridge: analogix/dp: add some rk3288 special registers setting Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:10 +0200
    [PATCH v5 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:10 +0200
    [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:10 +0200
      Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol  & interlace & dynamic_range Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 07:40 +0200
        Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol  & interlace & dynamic_range Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 09:40 +0200
          Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol  & interlace & dynamic_range Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 10:30 +0200
            Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol  & interlace & dynamic_range Yakir Yang <ykk@rock-chips.com> - 2015-09-30 11:40 +0200
    [PATCH v5 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288 Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:10 +0200
    [PATCH v5 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:30 +0200
    [PATCH v5 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method Yakir Yang <ykk@rock-chips.com> - 2015-09-22 10:40 +0200
    Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver  to bridge directory Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-30 07:20 +0200
      Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver  to bridge directory Yakir Yang <ykk@rock-chips.com> - 2015-09-30 09:00 +0200

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

#1235891 — Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

FromKrzysztof Kozlowski <k.kozlowski@samsung.com>
Date2015-09-30 10:30 +0200
SubjectRe: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Message-ID<qekW0-7TY-39@gated-at.bofh.it>
In reply to#1235829
On 30.09.2015 17:20, Yakir Yang wrote:
> Hi Krzysztof,
> 
> On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:
>> On 30.09.2015 16:19, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
>>>> On 22.09.2015 16:37, Yakir Yang wrote:
>>>>> Both hsync/vsync polarity and interlace mode can be parsed from
>>>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>>>>> by the video code.
>>>>>
>>>>> But presumably Exynos still relies on the DT properties, so take
>>>>> good use of mode_fixup() in to achieve the compatibility hacks.
>>>>>
>>>>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>>>>> ---
>>>>> Changes in v5:
>>>>> - Switch video timing type to "u32", so driver could use "of_property_read_u32"
>>>>>   to get the backword timing values. 
>>>> Okay
>>>>
>>>>> Krzysztof suggest me that driver could use
>>>>>   the "of_property_read_bool" to get backword timing values, but that interfacs
>>>>>   would modify the original drm_display_mode timing directly (whether those
>>>>>   properties exists or not).
>>>> Hmm, I don't understand. You have a:
>>>> 	struct video_info {
>>>> 		bool h_sync_polarity;
>>>> 		bool v_sync_polarity;
>>>> 		bool interlaced;
>>>> 	};
>>>>
>>>> so what is wrong with:
>>>> 	dp_video_config->h_sync_polarity =
>>>> 		of_property_read_bool(dp_node, "hsync-active-high");
>>>>
>>>> Is it exactly the same binding as previously?
>>> Yes, it is the same binding as previously. But just a note that we already
>>> mark those DT binding as deprecated.
>>>
>>> +-interlaced:            deprecated prop that can parsed frm drm_display_mode.
>>> +-vsync-active-high:     deprecated prop that can parsed frm drm_display_mode.
>>> +-hsync-active-high:     deprecated prop that can parsed frm drm_display_mode.
>>>
>>>
>>> For now those values should come from "struct drm_display_mode",
>>> and we already parsed them out from "drm_display_mode" before
>>> driver provide the backward compatibility.
>>>
>>> Let's used the "hsync-active-high" example:
>>>     As for now the code would like:
>>>     static void analogix_dp_bridge_mode_set(...)
>>>     {
>>>         // Parsed timing value from "drm_display_mode"
>>>         video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>>         // Try to detect the deprecated property, providing
>>>         // the backward compatibility
>>>         of_property_read_u32(dp_node, "hsync-active-high",
>>>                                  &video->h_sync_polarity);    
>>>
>>>         /*
>>>          * In this case, if "hsync-active-high" property haven't been
>>>          * found, then the video timing "h_sync_polarity" would  keep
>>>          * no change, keeping the parsed value from "drm_display_mode"
>>>          */     
>>>     }   
>>>
>>>     But if keep the "of_property_read_bool", then code would like:
>>>     static void analogix_dp_bridge_mode_set(...)
>>>     {
>>>         // Parsed timing value from "drm_display_mode"
>>>         video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>
>>>         // Try to detect the deprecated property, providing
>>>         // the backward compatibility
>>>         video->h_sync_polarity =
>>>                     of_property_read_bool(dp_node, "hsync-active-high");
>>>    
>>>
>>>         /*
>>>          * In this case, if "hsync-active-high" property haven't been
>>>          * found, then the video timing "h_sync_polarity" would just
>>>          * modify to "false". That is the place we don't want, cause
>>>          * it would always modify the timing value parsed from
>>>          * "drm_display_mode"
>>>          */  
>>>     }   
>>>
>> OK, I see the point of overwriting values from drm_display_mode. However
>> I think you changed the binding. I believe the of_property_read_u32()
>> will behave differently for such DTS:
>>
>> exynos_dp {
>> 	...
>> 	hsync-active-high;
>> }
>>
>> It will return -EOVERFLOW which means it would be broken now...
> 
> Whoops, thanks for your remind, after try that, I do see over flow error.
> static void *of_find_property_value_of_size(const struct device_node *np,
>                         const char *propname, u32 len)
> {
>         ....
>         if (len > prop->length)
>                 return ERR_PTR(-EOVERFLOW);
>         ...
> }
> 
> So I though code should be:
>     if (of_property_read_bool(dp_node, "hsync-active-high"))
>         video->h_sync_polarity = true;

Looks good.

> 
> And we can't provide full backward compatibility for this property, cause
> the previous exynos_dp driver would set this timing value to "false" when
> property not defined, but analogix_dp driver keep this timing value
> corresponding to "drm_display_mode" when property not found.

Indeed, the behaviour changes. I don't know if this is important issue...

Best regards,
Krzysztof

--
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]

#1235941 — Re: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

FromYakir Yang <ykk@rock-chips.com>
Date2015-09-30 11:40 +0200
SubjectRe: [PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Message-ID<qem1J-Zq-23@gated-at.bofh.it>
In reply to#1235891
Hi Krzysztof,

On 09/30/2015 04:26 PM, Krzysztof Kozlowski wrote:
> On 30.09.2015 17:20, Yakir Yang wrote:
>> Hi Krzysztof,
>>
>> On 09/30/2015 03:34 PM, Krzysztof Kozlowski wrote:
>>> On 30.09.2015 16:19, Yakir Yang wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 09/30/2015 01:32 PM, Krzysztof Kozlowski wrote:
>>>>> On 22.09.2015 16:37, Yakir Yang wrote:
>>>>>> Both hsync/vsync polarity and interlace mode can be parsed from
>>>>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge
>>>>>> by the video code.
>>>>>>
>>>>>> But presumably Exynos still relies on the DT properties, so take
>>>>>> good use of mode_fixup() in to achieve the compatibility hacks.
>>>>>>
>>>>>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - Switch video timing type to "u32", so driver could use "of_property_read_u32"
>>>>>>    to get the backword timing values.
>>>>> Okay
>>>>>
>>>>>> Krzysztof suggest me that driver could use
>>>>>>    the "of_property_read_bool" to get backword timing values, but that interfacs
>>>>>>    would modify the original drm_display_mode timing directly (whether those
>>>>>>    properties exists or not).
>>>>> Hmm, I don't understand. You have a:
>>>>> 	struct video_info {
>>>>> 		bool h_sync_polarity;
>>>>> 		bool v_sync_polarity;
>>>>> 		bool interlaced;
>>>>> 	};
>>>>>
>>>>> so what is wrong with:
>>>>> 	dp_video_config->h_sync_polarity =
>>>>> 		of_property_read_bool(dp_node, "hsync-active-high");
>>>>>
>>>>> Is it exactly the same binding as previously?
>>>> Yes, it is the same binding as previously. But just a note that we already
>>>> mark those DT binding as deprecated.
>>>>
>>>> +-interlaced:            deprecated prop that can parsed frm drm_display_mode.
>>>> +-vsync-active-high:     deprecated prop that can parsed frm drm_display_mode.
>>>> +-hsync-active-high:     deprecated prop that can parsed frm drm_display_mode.
>>>>
>>>>
>>>> For now those values should come from "struct drm_display_mode",
>>>> and we already parsed them out from "drm_display_mode" before
>>>> driver provide the backward compatibility.
>>>>
>>>> Let's used the "hsync-active-high" example:
>>>>      As for now the code would like:
>>>>      static void analogix_dp_bridge_mode_set(...)
>>>>      {
>>>>          // Parsed timing value from "drm_display_mode"
>>>>          video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>>
>>>>          // Try to detect the deprecated property, providing
>>>>          // the backward compatibility
>>>>          of_property_read_u32(dp_node, "hsync-active-high",
>>>>                                   &video->h_sync_polarity);
>>>>
>>>>          /*
>>>>           * In this case, if "hsync-active-high" property haven't been
>>>>           * found, then the video timing "h_sync_polarity" would  keep
>>>>           * no change, keeping the parsed value from "drm_display_mode"
>>>>           */
>>>>      }
>>>>
>>>>      But if keep the "of_property_read_bool", then code would like:
>>>>      static void analogix_dp_bridge_mode_set(...)
>>>>      {
>>>>          // Parsed timing value from "drm_display_mode"
>>>>          video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>>
>>>>          // Try to detect the deprecated property, providing
>>>>          // the backward compatibility
>>>>          video->h_sync_polarity =
>>>>                      of_property_read_bool(dp_node, "hsync-active-high");
>>>>     
>>>>
>>>>          /*
>>>>           * In this case, if "hsync-active-high" property haven't been
>>>>           * found, then the video timing "h_sync_polarity" would just
>>>>           * modify to "false". That is the place we don't want, cause
>>>>           * it would always modify the timing value parsed from
>>>>           * "drm_display_mode"
>>>>           */
>>>>      }
>>>>
>>> OK, I see the point of overwriting values from drm_display_mode. However
>>> I think you changed the binding. I believe the of_property_read_u32()
>>> will behave differently for such DTS:
>>>
>>> exynos_dp {
>>> 	...
>>> 	hsync-active-high;
>>> }
>>>
>>> It will return -EOVERFLOW which means it would be broken now...
>> Whoops, thanks for your remind, after try that, I do see over flow error.
>> static void *of_find_property_value_of_size(const struct device_node *np,
>>                          const char *propname, u32 len)
>> {
>>          ....
>>          if (len > prop->length)
>>                  return ERR_PTR(-EOVERFLOW);
>>          ...
>> }
>>
>> So I though code should be:
>>      if (of_property_read_bool(dp_node, "hsync-active-high"))
>>          video->h_sync_polarity = true;
> Looks good.
>
>> And we can't provide full backward compatibility for this property, cause
>> the previous exynos_dp driver would set this timing value to "false" when
>> property not defined, but analogix_dp driver keep this timing value
>> corresponding to "drm_display_mode" when property not found.
> Indeed, the behaviour changes. I don't know if this is important issue...

Hmm... as I know the timing polarity would influence something like:
     - CTS test
     - HDCP function

But I though it's more likely that driver would made those functions 
failed if
hard code the timing polarity.

And I think it would be better to get timing polarity from 
"drm_display_mode".
Caused the analogix_dp driver have called the drm_add_edid_modes() that
function would parse the EDID "detailed timing" block which contained the
correct timing message that panel request.

Besides I see the exynos_fmid driver already setup the timing polarity from
"drm_display_mode", and there is no doubt that exynos dp should set the
same polarity with fmid driver (I guess, just notice that fmid is a kind 
of CTRC
driver).

That's to say parsing timing polarity dynamically would give more chances to
make those functions works.

Thanks,
- Yakir

> Best regards,
> Krzysztof
>
>
>
>
"

--
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]

#1229966 — [PATCH v5 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

FromYakir Yang <ykk@rock-chips.com>
Date2015-09-22 10:10 +0200
Subject[PATCH v5 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
Message-ID<qbqOe-7Y5-15@gated-at.bofh.it>
In reply to#1229939
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
---
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++++++++++++++--------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6be139b..3efae33 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 		return;
 	}
 
-	ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-					 dp->video_info.link_rate);
+	ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+					 dp->video_info.max_link_rate);
 	if (ret) {
 		dev_err(dp->dev, "unable to do link train\n");
 		return;
@@ -1153,18 +1153,27 @@ static int analogix_dp_create_bridge(struct drm_device *drm_dev,
 static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
 {
 	struct device_node *dp_node = dp->dev->of_node;
-	struct video_info *video_info = &dp->video_info
+	struct video_info *video_info = &dp->video_info;
 
-	if (of_property_read_u32(dp_node, "samsung,link-rate",
-				 &video_info->link_rate)) {
-		dev_err(dev, "failed to get link-rate\n");
-		return -EINVAL;
-	}
-
-	if (of_property_read_u32(dp_node, "samsung,lane-count",
-				 &video_info->lane_count)) {
-		dev_err(dev, "failed to get lane-count\n");
-		return -EINVAL;
+	switch (dp->plat_data && dp->plat_data->dev_type) {
+	case RK3288_DP:
+		/*
+		 * Like Rk3288 DisplayPort TRM indicate that "Main link
+		 * containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+		 */
+		video_info->max_link_rate = 0x0A;
+		video_info->max_lane_count = 0x04;
+		break;
+	case EXYNOS_DP:
+		/*
+		 * NOTE: those property parseing code is used for
+		 * providing backward compatibility for samsung platform.
+		 */
+		of_property_read_u32(dp_node, "samsung,link-rate",
+				     &video_info->max_link_rate);
+		of_property_read_u32(dp_node, "samsung,lane-count",
+				     &video_info->max_lane_count);
+		break;
 	}
 
 	return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 730486d..f4cb799 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
 	enum color_coefficient ycbcr_coeff;
 	enum color_depth color_depth;
 
-	enum link_rate_type link_rate;
-	enum link_lane_count_type lane_count;
+	enum link_rate_type max_link_rate;
+	enum link_lane_count_type max_lane_count;
 };
 
 struct link_train {
-- 
1.9.1


--
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]

#1229979 — [PATCH v5 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function

FromYakir Yang <ykk@rock-chips.com>
Date2015-09-22 10:30 +0200
Subject[PATCH v5 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function
Message-ID<qbr7B-8kH-23@gated-at.bofh.it>
In reply to#1229939
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
---
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7e83738..90c4fda 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 			DRM_ERROR("failed to disable the panel\n");
 	}
 
-	ret = analogix_dp_detect_hpd(dp);
-	if (ret) {
-		/* Cable has been disconnected, we're done */
-		return;
-	}
-
 	ret = analogix_dp_handle_edid(dp);
 	if (ret) {
 		dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 
 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+	struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+	if (analogix_dp_detect_hpd(dp))
+		return connector_status_disconnected;
+
 	return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
-- 
1.9.1


--
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]

#1229983 — [PATCH v5 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method

FromYakir Yang <ykk@rock-chips.com>
Date2015-09-22 10:40 +0200
Subject[PATCH v5 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method
Message-ID<qbrhf-8vS-7@gated-at.bofh.it>
In reply to#1229939
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
---
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 24 +++++++----
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++++++++++-----------
 2 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 90c4fda..5f8fc11 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 
 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-	unsigned char edid[EDID_BLOCK_LENGTH * 2];
+	unsigned char *edid = dp->edid;
 	unsigned int extend_block = 0;
 	unsigned char sum;
 	unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 			DRM_ERROR("failed to disable the panel\n");
 	}
 
-	ret = analogix_dp_handle_edid(dp);
-	if (ret) {
-		dev_err(dp->dev, "unable to handle edid\n");
-		return;
-	}
-
 	ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 					 dp->video_info.max_link_rate);
 	if (ret) {
@@ -947,8 +941,24 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
 	struct analogix_dp_device *dp = dev_get_drvdata(dev);
+	struct edid *edid = (struct edid *)dp->edid;
 	int num_modes = 0;
 
+	if (dp->plat_data && dp->plat_data->panel) {
+		if (drm_panel_prepare(dp->plat_data->panel)) {
+			DRM_ERROR("failed to setup the panel\n");
+			return -EINVAL;
+		}
+	}
+
+	if (analogix_dp_handle_edid(dp)) {
+		dev_err(dp->dev, "unable to handle edid\n");
+		return -EINVAL;
+	}
+
+	drm_mode_connector_update_edid_property(dp->connector, edid);
+	num_modes += drm_add_edid_modes(dp->connector, edid);
+
 	if (dp->plat_data->panel)
 		num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 3a136b8..089489d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR			0x50
+#define I2C_E_EDID_DEVICE_ADDR			0x30
+
+#define EDID_BLOCK_LENGTH			0x80
+#define EDID_HEADER_PATTERN			0x00
+#define EDID_EXTENSION_FLAG			0x7e
+#define EDID_CHECKSUM				0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x)		(((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x)			((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x)			((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)		(((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)		(((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)		(((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)		(((x) >> 0) & 0x3)
+
 enum link_rate_type {
 	LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
 	LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
 	int			dpms_mode;
 	int			hpd_gpio;
 	bool                    need_force_hpd;
+	unsigned char           edid[EDID_BLOCK_LENGTH * 2];
 
 	struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR			0x50
-#define I2C_E_EDID_DEVICE_ADDR			0x30
-
-#define EDID_BLOCK_LENGTH			0x80
-#define EDID_HEADER_PATTERN			0x00
-#define EDID_EXTENSION_FLAG			0x7e
-#define EDID_CHECKSUM				0x7f
-
-/* DP_MAX_LANE_COUNT */
-#define DPCD_ENHANCED_FRAME_CAP(x)		(((x) >> 7) & 0x1)
-#define DPCD_MAX_LANE_COUNT(x)			((x) & 0x1f)
-
-/* DP_LANE_COUNT_SET */
-#define DPCD_LANE_COUNT_SET(x)			((x) & 0x1f)
-
-/* DP_TRAINING_LANE0_SET */
-#define DPCD_PRE_EMPHASIS_SET(x)		(((x) & 0x3) << 3)
-#define DPCD_PRE_EMPHASIS_GET(x)		(((x) >> 3) & 0x3)
-#define DPCD_VOLTAGE_SWING_SET(x)		(((x) & 0x3) << 0)
-#define DPCD_VOLTAGE_SWING_GET(x)		(((x) >> 0) & 0x3)
-
 #endif /* _ANALOGIX_DP_CORE_H */
-- 
1.9.1


--
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]

#1235755 — Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

FromKrzysztof Kozlowski <k.kozlowski@samsung.com>
Date2015-09-30 07:20 +0200
SubjectRe: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory
Message-ID<qehY5-3It-3@gated-at.bofh.it>
In reply to#1229939
On 22.09.2015 16:29, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge directory,
> and rename the core driver to analogix_dp_*, rename the platform
> code to exynos_dp.
> 
> Beside the new analogix_dp driver would export four hooks.
> "analogix_dp_bind()" and "analogix_dp_unbind()"
> "analogix_dp_detect()" and "analogix_dp_get_modes()"
> 
> The bind/unbind symbols is used for analogix platform driver to connect
> with analogix_dp core driver. And the detect/get_modes is used for analogix
> platform driver to init the connector.
> 
> They reason why connector need register in helper driver is rockchip drm
> haven't implement the atomic API, but Exynos drm have implement it, so
> there would need two different connector helper functions, that's why we
> leave the connector register in helper driver.
> 
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> ---
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)

Thanks for fixing this, looks much better.

I don't feel comfortable enough to provide a review tag but it looks
good to me.

Best regards,
Krzysztof

--
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]

#1235813 — Re: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

FromYakir Yang <ykk@rock-chips.com>
Date2015-09-30 09:00 +0200
SubjectRe: [PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory
Message-ID<qejwS-5Mf-5@gated-at.bofh.it>
In reply to#1235755
Hi Krzysztof,

On 09/30/2015 01:17 PM, Krzysztof Kozlowski wrote:
> On 22.09.2015 16:29, Yakir Yang wrote:
>> Split the dp core driver from exynos directory to bridge directory,
>> and rename the core driver to analogix_dp_*, rename the platform
>> code to exynos_dp.
>>
>> Beside the new analogix_dp driver would export four hooks.
>> "analogix_dp_bind()" and "analogix_dp_unbind()"
>> "analogix_dp_detect()" and "analogix_dp_get_modes()"
>>
>> The bind/unbind symbols is used for analogix platform driver to connect
>> with analogix_dp core driver. And the detect/get_modes is used for analogix
>> platform driver to init the connector.
>>
>> They reason why connector need register in helper driver is rockchip drm
>> haven't implement the atomic API, but Exynos drm have implement it, so
>> there would need two different connector helper functions, that's why we
>> leave the connector register in helper driver.
>>
>> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
>> ---
>> Changes in v5:
>> - Correct the check condition of gpio_is_valid when driver try to get
>>    the "hpd-gpios" DT propery. (Heiko)
>> - Move the platform attach callback in the front of core driver bridge
>>    attch function. Cause once platform failed at attach, core driver should
>>    still failed, so no need to init connector before platform attached (Krzysztof)
>> - Keep code style no changes with the previous exynos_dp_code.c in this
>>    patch, and update commit message about the new export symbol (Krzysztof)
>> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
>> - leave out the connector registration to analogix platform driver. (Thierry)
> Thanks for fixing this, looks much better.
>
> I don't feel comfortable enough to provide a review tag but it looks
> good to me.

Thanks  ;)

- Yakir

> Best regards,
> Krzysztof
>
>
>
>


--
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