Add DP both data-lanes and link-frequencies property to dp_out endpoint and support
functions to DP driver.
Kuogee Hsieh (5):
arm64: dts: qcom: add data-lanes and link-freuencies into dp_out
endpoint
dt-bindings: msm/dp: add data-lanes and link-frequencies property
drm/msm/dp: parser data-lanes as property of dp_out endpoint
drm/msm/dp: parser link-frequencies as property of dp_out endpoint
drm/msm/dp: add support of max dp link rate
.../bindings/display/msm/dp-controller.yaml | 27 +++++++++++
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 ++-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++
drivers/gpu/drm/msm/dp/dp_panel.c | 7 +--
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
drivers/gpu/drm/msm/dp/dp_parser.c | 52 ++++++++++++++++++----
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +
8 files changed, 92 insertions(+), 13 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Add capability to parser data-lanes as property of dp_out endpoint.
Also retain the original capability to parser data-lanes as property
of mdss_dp node to handle legacy case.
Changes in v6:
-- first patch after split parser patch into two
Changes in v7:
-- check "data-lanes" from endpoint first
Signed-off-by: Kuogee Hsieh <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
---
drivers/gpu/drm/msm/dp/dp_parser.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index dd73221..b5f7e70 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -94,16 +94,25 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
- int len;
-
- len = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
- if (len < 0) {
- DRM_WARN("Invalid property \"data-lanes\", default max DP lanes = %d\n",
- DP_MAX_NUM_DP_LANES);
- len = DP_MAX_NUM_DP_LANES;
+ int cnt;
+
+ /*
+ * data-lanes is the property of dp_out endpoint
+ */
+ cnt = drm_of_get_data_lanes_count_ep(of_node, 1, 0, 1, DP_MAX_NUM_DP_LANES);
+ if (cnt > 0)
+ parser->max_dp_lanes = cnt;
+ else {
+ /*
+ * legacy code, data-lanes is the property of mdss_dp node
+ */
+ cnt = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
+ if (cnt > 0)
+ parser->max_dp_lanes = cnt;
+ else
+ parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes */
}
- parser->max_dp_lanes = len;
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Add both data-lanes and link-frequencies property into endpoint
Changes in v7:
-- split yaml out of dtsi patch
-- link-frequencies from link rate to symbol rate
-- deprecation of old data-lanes property
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v10:
-- add menu item to data-lanes and link-frequecnis
Changes in v11:
-- add endpoint property at port@1
Signed-off-by: Kuogee Hsieh <[email protected]>`
---
.../bindings/display/msm/dp-controller.yaml | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index f2515af..2a7fdef8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -81,6 +81,7 @@ properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
+ deprecated: true
minItems: 1
maxItems: 4
items:
@@ -96,6 +97,7 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
@@ -105,6 +107,29 @@ properties:
$ref: /schemas/graph.yaml#/properties/port
description: Output endpoint of the controller
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+
+ properties:
+ remote-endpoint: true
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 3
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ minItems: 1
+ maxItems: 4
+ items:
+ maximum: 8100000000
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -193,6 +218,8 @@ examples:
reg = <1>;
endpoint {
remote-endpoint = <&typec>;
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Add capability to parser and retrieve max DP link supported rate from
link-frequencies property of dp_out endpoint.
Changes in v6:
-- second patch after split parser patch into two patches
Changes in v7:
-- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
Changes in v9:
-- separate parser link-frequencies out of data-lanes
Changes in v10:
-- add dp_parser_link_frequencies()
Changes in v11:
-- return 0 if(!endpoint)
Signed-off-by: Kuogee Hsieh <[email protected]>
---
drivers/gpu/drm/msm/dp/dp_parser.c | 27 +++++++++++++++++++++++++++
drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index b5f7e70..9a7dcd4 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -91,6 +91,29 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
return 0;
}
+static u32 dp_parser_link_frequencies(struct device_node *of_node)
+{
+ struct device_node *endpoint;
+ u64 frequency = 0;
+ int cnt = 0;
+
+ endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
+ if (!endpoint)
+ return 0;
+
+ cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
+
+ if (cnt > 0)
+ of_property_read_u64_index(endpoint, "link-frequencies",
+ cnt - 1, &frequency);
+ of_node_put(endpoint);
+
+ frequency /= 10; /* from symbol rate to link rate */
+ frequency /= 1000; /* kbytes */
+
+ return frequency;
+}
+
static int dp_parser_misc(struct dp_parser *parser)
{
struct device_node *of_node = parser->pdev->dev.of_node;
@@ -113,6 +136,10 @@ static int dp_parser_misc(struct dp_parser *parser)
parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes */
}
+ parser->max_dp_link_rate = dp_parser_link_frequencies(of_node);
+ if (!parser->max_dp_link_rate)
+ parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 540000 khz */
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index 866c1a8..6b10c3e 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -15,6 +15,7 @@
#define DP_LABEL "MDSS DP DISPLAY"
#define DP_MAX_PIXEL_CLK_KHZ 675000
#define DP_MAX_NUM_DP_LANES 4
+#define DP_LINK_RATE_HBR2 540000 /* khz */
enum dp_pm_type {
DP_CORE_PM,
@@ -119,6 +120,7 @@ struct dp_parser {
struct dp_io io;
struct dp_display_data disp_data;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
struct drm_bridge *next_bridge;
int (*parse)(struct dp_parser *parser);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
By default, HBR2 (5.4G) is the max link link be supported. This patch uses the
actual limit specified by DT and removes the artificial limitation to 5.4 Gbps.
Supporting HBR3 is a consequence of that.
Changes in v2:
-- add max link rate from dtsi
Changes in v3:
-- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4:
-- delete unnecessary pr_err
Changes in v5:
-- split parser function into different patch
Changes in v9:
-- revised commit test
Signed-off-by: Kuogee Hsieh <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
---
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++++
drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++++---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index bfd0aef..edee550 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -390,6 +390,10 @@ static int dp_display_process_hpd_high(struct dp_display_private *dp)
struct edid *edid;
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+ dp->panel->max_dp_link_rate = dp->parser->max_dp_link_rate;
+
+ drm_dbg_dp(dp->drm_dev, "max_lanes=%d max_link_rate=%d\n",
+ dp->panel->max_dp_lanes, dp->panel->max_dp_link_rate);
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
index 5149ceb..933fa9c 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -75,12 +75,13 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
link_info->rate = drm_dp_bw_code_to_link_rate(dpcd[DP_MAX_LINK_RATE]);
link_info->num_lanes = dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
+ /* Limit data lanes from data-lanes of endpoint properity of dtsi */
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
- /* Limit support upto HBR2 until HBR3 support is added */
- if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
- link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+ /* Limit link rate from link-frequencies of endpoint properity of dtsi */
+ if (link_info->rate > dp_panel->max_dp_link_rate)
+ link_info->rate = dp_panel->max_dp_link_rate;
drm_dbg_dp(panel->drm_dev, "version: %d.%d\n", major, minor);
drm_dbg_dp(panel->drm_dev, "link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h b/drivers/gpu/drm/msm/dp/dp_panel.h
index d861197a..f04d021 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -50,6 +50,7 @@ struct dp_panel {
u32 vic;
u32 max_dp_lanes;
+ u32 max_dp_link_rate;
u32 max_bw_code;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Changes in v5:
-- revert changes at sc7180.dtsi and sc7280.dtsi
-- add &dp_out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
Changes in v6:
-- add data-lanes and link-frequencies to yaml
Changes in v7:
-- change 160000000 to 1620000000
-- separate yaml to different patch
Changes in v8:
-- correct Bjorn mail address to kernel.org
Changes in v9:
-- use symbol rate (hz) for link-frequencies at dp_out at sc7180_trogdor.dtsi
Signed-off-by: Kuogee Hsieh <[email protected]>
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++++-
arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index eae22e6..93b0cde 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -814,7 +814,11 @@ hp_i2c: &i2c9 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&dp_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+&dp_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
};
&pm6150_adc {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index c11e371..3c7a9d8 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -442,7 +442,11 @@ ap_i2c_tpm: &i2c14 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&dp_hot_plug_det>;
- data-lanes = <0 1>;
+};
+
+&dp_out {
+ data-lanes = <0 1>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};
&mdss_mdp {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On 09/12/2022 00:36, Kuogee Hsieh wrote:
> Add capability to parser and retrieve max DP link supported rate from
> link-frequencies property of dp_out endpoint.
>
> Changes in v6:
> -- second patch after split parser patch into two patches
>
> Changes in v7:
> -- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate
>
> Changes in v9:
> -- separate parser link-frequencies out of data-lanes
>
> Changes in v10:
> -- add dp_parser_link_frequencies()
>
> Changes in v11:
> -- return 0 if(!endpoint)
>
> Signed-off-by: Kuogee Hsieh <[email protected]>
> ---
> drivers/gpu/drm/msm/dp/dp_parser.c | 27 +++++++++++++++++++++++++++
> drivers/gpu/drm/msm/dp/dp_parser.h | 2 ++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
> index b5f7e70..9a7dcd4 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.c
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.c
> @@ -91,6 +91,29 @@ static int dp_parser_ctrl_res(struct dp_parser *parser)
> return 0;
> }
>
> +static u32 dp_parser_link_frequencies(struct device_node *of_node)
> +{
> + struct device_node *endpoint;
> + u64 frequency = 0;
> + int cnt = 0;
> +
> + endpoint = of_graph_get_endpoint_by_regs(of_node, 1, 0); /* port@1 */
> + if (!endpoint)
> + return 0;
> +
> + cnt = of_property_count_u64_elems(endpoint, "link-frequencies");
> +
> + if (cnt > 0)
> + of_property_read_u64_index(endpoint, "link-frequencies",
> + cnt - 1, &frequency);
> + of_node_put(endpoint);
> +
> + frequency /= 10; /* from symbol rate to link rate */
> + frequency /= 1000; /* kbytes */
> +
> + return frequency;
> +}
> +
> static int dp_parser_misc(struct dp_parser *parser)
> {
> struct device_node *of_node = parser->pdev->dev.of_node;
> @@ -113,6 +136,10 @@ static int dp_parser_misc(struct dp_parser *parser)
> parser->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes */
> }
>
> + parser->max_dp_link_rate = dp_parser_link_frequencies(of_node);
> + if (!parser->max_dp_link_rate)
> + parser->max_dp_link_rate = DP_LINK_RATE_HBR2; /* 540000 khz */
Drop the comment please. One can jump to the defined value to see what
is it equal to. So it adds no information.
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
> index 866c1a8..6b10c3e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.h
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.h
> @@ -15,6 +15,7 @@
> #define DP_LABEL "MDSS DP DISPLAY"
> #define DP_MAX_PIXEL_CLK_KHZ 675000
> #define DP_MAX_NUM_DP_LANES 4
> +#define DP_LINK_RATE_HBR2 540000 /* khz */
kbytes, not kHz. Otherwise it would have been 5400000.
>
> enum dp_pm_type {
> DP_CORE_PM,
> @@ -119,6 +120,7 @@ struct dp_parser {
> struct dp_io io;
> struct dp_display_data disp_data;
> u32 max_dp_lanes;
> + u32 max_dp_link_rate;
> struct drm_bridge *next_bridge;
>
> int (*parse)(struct dp_parser *parser);
--
With best wishes
Dmitry
On 09/12/2022 00:36, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
>
> Changes in v8:
> -- correct Bjorn mail address to kernel.org
>
> Changes in v10:
> -- add menu item to data-lanes and link-frequecnis
>
> Changes in v11:
> -- add endpoint property at port@1
>
> Signed-off-by: Kuogee Hsieh <[email protected]>`
Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies property
.git/rebase-apply/patch:47: trailing whitespace.
.git/rebase-apply/patch:51: trailing whitespace.
Also the dt_binding_check fails with an error for this schema. And after
fixing the error in the schema I faced an example validation error. Did
you check that the schema is correct and that the example validates
against the schema?
> ---
> .../bindings/display/msm/dp-controller.yaml | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> index f2515af..2a7fdef8 100644
> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> @@ -81,6 +81,7 @@ properties:
>
> data-lanes:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> + deprecated: true
> minItems: 1
> maxItems: 4
> items:
> @@ -96,6 +97,7 @@ properties:
>
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
> +
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> @@ -105,6 +107,29 @@ properties:
> $ref: /schemas/graph.yaml#/properties/port
> description: Output endpoint of the controller
>
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> +
> + properties:
> + remote-endpoint: true
PLease add empty lines between the property definitions
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
This is already a part of video-interfaces, so you don't need $ref
> + minItems: 1
> + maxItems: 4
> + items:
> + maximum: 3
enum: [0, 1, 2, 3]
> + link-frequencies:
> + $ref: /schemas/types.yaml#/definitions/uint64-array
> + minItems: 1
> + maxItems: 4
> + items:
> + maximum: 8100000000
I think we can have enum here too.
> +
> + required:
> + - port@0
> + - port@1
> +
> required:
> - compatible
> - reg
> @@ -193,6 +218,8 @@ examples:
> reg = <1>;
> endpoint {
> remote-endpoint = <&typec>;
> + data-lanes = <0 1>;
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> };
> };
> };
--
With best wishes
Dmitry
On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>> Add both data-lanes and link-frequencies property into endpoint
>>
>> Changes in v7:
>> -- split yaml out of dtsi patch
>> -- link-frequencies from link rate to symbol rate
>> -- deprecation of old data-lanes property
>>
>> Changes in v8:
>> -- correct Bjorn mail address to kernel.org
>>
>> Changes in v10:
>> -- add menu item to data-lanes and link-frequecnis
>>
>> Changes in v11:
>> -- add endpoint property at port@1
>>
>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>
> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
> property
> .git/rebase-apply/patch:47: trailing whitespace.
>
> .git/rebase-apply/patch:51: trailing whitespace.
>
>
> Also the dt_binding_check fails with an error for this schema. And
> after fixing the error in the schema I faced an example validation
> error. Did you check that the schema is correct and that the example
> validates against the schema?
yes, but i run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
at mu v5.15 branch since
"make dt_binding_check" does not work at msm-next branch.
But I did not check trainiling whitespace this time.
>
>> ---
>> .../bindings/display/msm/dp-controller.yaml | 27
>> ++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> index f2515af..2a7fdef8 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>> @@ -81,6 +81,7 @@ properties:
>> data-lanes:
>> $ref: /schemas/types.yaml#/definitions/uint32-array
>> + deprecated: true
>> minItems: 1
>> maxItems: 4
>> items:
>> @@ -96,6 +97,7 @@ properties:
>> ports:
>> $ref: /schemas/graph.yaml#/properties/ports
>> +
>> properties:
>> port@0:
>> $ref: /schemas/graph.yaml#/properties/port
>> @@ -105,6 +107,29 @@ properties:
>> $ref: /schemas/graph.yaml#/properties/port
>> description: Output endpoint of the controller
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> +
>> + properties:
>> + remote-endpoint: true
>
> PLease add empty lines between the property definitions
>
>> + data-lanes:
>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>
> This is already a part of video-interfaces, so you don't need $ref
>
>> + minItems: 1
>> + maxItems: 4
>> + items:
>> + maximum: 3
>
> enum: [0, 1, 2, 3]
>
>> + link-frequencies:
>> + $ref: /schemas/types.yaml#/definitions/uint64-array
>> + minItems: 1
>> + maxItems: 4
>> + items:
>> + maximum: 8100000000
>
> I think we can have enum here too.
>
>> +
>> + required:
>> + - port@0
>> + - port@1
>> +
>> required:
>> - compatible
>> - reg
>> @@ -193,6 +218,8 @@ examples:
>> reg = <1>;
>> endpoint {
>> remote-endpoint = <&typec>;
>> + data-lanes = <0 1>;
>> + link-frequencies = /bits/ 64 <1620000000
>> 2700000000 5400000000 8100000000>;
>> };
>> };
>> };
>
On 09/12/2022 01:38, Kuogee Hsieh wrote:
>
> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>> Add both data-lanes and link-frequencies property into endpoint
>>>
>>> Changes in v7:
>>> -- split yaml out of dtsi patch
>>> -- link-frequencies from link rate to symbol rate
>>> -- deprecation of old data-lanes property
>>>
>>> Changes in v8:
>>> -- correct Bjorn mail address to kernel.org
>>>
>>> Changes in v10:
>>> -- add menu item to data-lanes and link-frequecnis
>>>
>>> Changes in v11:
>>> -- add endpoint property at port@1
>>>
>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>
>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>> property
>> .git/rebase-apply/patch:47: trailing whitespace.
>>
>> .git/rebase-apply/patch:51: trailing whitespace.
>>
>>
>> Also the dt_binding_check fails with an error for this schema. And
>> after fixing the error in the schema I faced an example validation
>> error. Did you check that the schema is correct and that the example
>> validates against the schema?
>
> yes, but i run "make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml" at mu v5.15 branch since
I wouldn't ask you to post the log here. But I don't think that either
of the errors that I see here is related to 5.15 vs 6.1-rc.
In fact after applying this patch against 5.15 I saw the expected failure:
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties:required: ['port@0', 'port@1'] is not of type 'object', 'boolean'
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
ignoring, error in schema: properties: required
>
> "make dt_binding_check" does not work at msm-next branch.
I went ahead and just checked.
`make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
msm-next and reports a single example-related warning in msm-next-lumag.
I pushed a patch to fix that warning (wich can hopefully be picked up by
Abhinav into msm-fixes). So you can assume that both these branches have
consistent error-free display/msm schemas.
>
> But I did not check trainiling whitespace this time.
>
>>
>>> ---
>>> .../bindings/display/msm/dp-controller.yaml | 27
>>> ++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>> index f2515af..2a7fdef8 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>> @@ -81,6 +81,7 @@ properties:
>>> data-lanes:
>>> $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + deprecated: true
>>> minItems: 1
>>> maxItems: 4
>>> items:
>>> @@ -96,6 +97,7 @@ properties:
>>> ports:
>>> $ref: /schemas/graph.yaml#/properties/ports
>>> +
>>> properties:
>>> port@0:
>>> $ref: /schemas/graph.yaml#/properties/port
>>> @@ -105,6 +107,29 @@ properties:
>>> $ref: /schemas/graph.yaml#/properties/port
>>> description: Output endpoint of the controller
>>> + properties:
>>> + endpoint:
>>> + $ref: /schemas/media/video-interfaces.yaml#
>>> +
>>> + properties:
>>> + remote-endpoint: true
>>
>> PLease add empty lines between the property definitions
>>
>>> + data-lanes:
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>
>> This is already a part of video-interfaces, so you don't need $ref
>>
>>> + minItems: 1
>>> + maxItems: 4
>>> + items:
>>> + maximum: 3
>>
>> enum: [0, 1, 2, 3]
>>
>>> + link-frequencies:
>>> + $ref: /schemas/types.yaml#/definitions/uint64-array
>>> + minItems: 1
>>> + maxItems: 4
>>> + items:
>>> + maximum: 8100000000
>>
>> I think we can have enum here too.
>>
>>> +
>>> + required:
>>> + - port@0
>>> + - port@1
>>> +
>>> required:
>>> - compatible
>>> - reg
>>> @@ -193,6 +218,8 @@ examples:
>>> reg = <1>;
>>> endpoint {
>>> remote-endpoint = <&typec>;
>>> + data-lanes = <0 1>;
>>> + link-frequencies = /bits/ 64 <1620000000
>>> 2700000000 5400000000 8100000000>;
>>> };
>>> };
>>> };
>>
--
With best wishes
Dmitry
On 09/12/2022 02:22, Kuogee Hsieh wrote:
>
> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>>
>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>>>> Add both data-lanes and link-frequencies property into endpoint
>>>>>
>>>>> Changes in v7:
>>>>> -- split yaml out of dtsi patch
>>>>> -- link-frequencies from link rate to symbol rate
>>>>> -- deprecation of old data-lanes property
>>>>>
>>>>> Changes in v8:
>>>>> -- correct Bjorn mail address to kernel.org
>>>>>
>>>>> Changes in v10:
>>>>> -- add menu item to data-lanes and link-frequecnis
>>>>>
>>>>> Changes in v11:
>>>>> -- add endpoint property at port@1
>>>>>
>>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>>>
>>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>>>> property
>>>> .git/rebase-apply/patch:47: trailing whitespace.
>>>>
>>>> .git/rebase-apply/patch:51: trailing whitespace.
>>>>
>>>>
>>>> Also the dt_binding_check fails with an error for this schema. And
>>>> after fixing the error in the schema I faced an example validation
>>>> error. Did you check that the schema is correct and that the example
>>>> validates against the schema?
>>>
>>> yes, but i run "make dt_binding_check
>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml" at mu v5.15 branch since
>>
>> I wouldn't ask you to post the log here. But I don't think that either
>> of the errors that I see here is related to 5.15 vs 6.1-rc.
>>
>> In fact after applying this patch against 5.15 I saw the expected
>> failure:
>>
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> properties:required: ['port@0', 'port@1'] is not of type 'object',
>> 'boolean'
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> properties: 'required' should not be valid under {'$ref':
>> '#/definitions/json-schema-prop-names'}
>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>> ignoring, error in schema: properties: required
>>
>>>
>>> "make dt_binding_check" does not work at msm-next branch.
>>
>> I went ahead and just checked.
>>
>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
>> msm-next and reports a single example-related warning in
>> msm-next-lumag. I pushed a patch to fix that warning (wich can
>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
>> that both these branches have consistent error-free display/msm schemas.
>>
> I have clean msm-next branch (without my data-lines yaml patch applied)
> and run "make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml", then I saw below error messages.
>
> Have you run into this problem?
No.
>
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/dtc/dtc.o
> HOSTCC scripts/dtc/flattree.o
> HOSTCC scripts/dtc/fstree.o
> HOSTCC scripts/dtc/data.o
> HOSTCC scripts/dtc/livetree.o
> HOSTCC scripts/dtc/treesource.o
> HOSTCC scripts/dtc/srcpos.o
> HOSTCC scripts/dtc/checks.o
> HOSTCC scripts/dtc/util.o
> LEX scripts/dtc/dtc-lexer.lex.c
> HOSTCC scripts/dtc/dtc-lexer.lex.o
> HOSTCC scripts/dtc/dtc-parser.tab.o
> HOSTLD scripts/dtc/dtc
> sort: -:2: disorder: 2022.1
> ERROR: dtschema minimum version is v2022.3
> make[2]: *** [check_dtschema_version] Error 1
> make[1]: *** [dt_binding_check] Error 2
> make: *** [__sub-make] Error 2
This means that somewhere in your path you have an older dtschema instance.
When you sent me a question regarding this error, I asked for the
additional info. You provided none. Instead you went on sending the
untested patch that doesn't work.
>
>>>
>>> But I did not check trainiling whitespace this time.
>>>
>>>>
>>>>> ---
>>>>> .../bindings/display/msm/dp-controller.yaml | 27
>>>>> ++++++++++++++++++++++
>>>>> 1 file changed, 27 insertions(+)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>> index f2515af..2a7fdef8 100644
>>>>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>> @@ -81,6 +81,7 @@ properties:
>>>>> data-lanes:
>>>>> $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> + deprecated: true
>>>>> minItems: 1
>>>>> maxItems: 4
>>>>> items:
>>>>> @@ -96,6 +97,7 @@ properties:
>>>>> ports:
>>>>> $ref: /schemas/graph.yaml#/properties/ports
>>>>> +
>>>>> properties:
>>>>> port@0:
>>>>> $ref: /schemas/graph.yaml#/properties/port
>>>>> @@ -105,6 +107,29 @@ properties:
>>>>> $ref: /schemas/graph.yaml#/properties/port
>>>>> description: Output endpoint of the controller
>>>>> + properties:
>>>>> + endpoint:
>>>>> + $ref: /schemas/media/video-interfaces.yaml#
>>>>> +
>>>>> + properties:
>>>>> + remote-endpoint: true
>>>>
>>>> PLease add empty lines between the property definitions
>>>>
>>>>> + data-lanes:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>
>>>> This is already a part of video-interfaces, so you don't need $ref
>>>>
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> + items:
>>>>> + maximum: 3
>>>>
>>>> enum: [0, 1, 2, 3]
>>>>
>>>>> + link-frequencies:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint64-array
>>>>> + minItems: 1
>>>>> + maxItems: 4
>>>>> + items:
>>>>> + maximum: 8100000000
>>>>
>>>> I think we can have enum here too.
>>>>
>>>>> +
>>>>> + required:
>>>>> + - port@0
>>>>> + - port@1
>>>>> +
>>>>> required:
>>>>> - compatible
>>>>> - reg
>>>>> @@ -193,6 +218,8 @@ examples:
>>>>> reg = <1>;
>>>>> endpoint {
>>>>> remote-endpoint = <&typec>;
>>>>> + data-lanes = <0 1>;
>>>>> + link-frequencies = /bits/ 64 <1620000000
>>>>> 2700000000 5400000000 8100000000>;
>>>>> };
>>>>> };
>>>>> };
>>>>
>>
--
With best wishes
Dmitry
On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>
>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>>> Add both data-lanes and link-frequencies property into endpoint
>>>>
>>>> Changes in v7:
>>>> -- split yaml out of dtsi patch
>>>> -- link-frequencies from link rate to symbol rate
>>>> -- deprecation of old data-lanes property
>>>>
>>>> Changes in v8:
>>>> -- correct Bjorn mail address to kernel.org
>>>>
>>>> Changes in v10:
>>>> -- add menu item to data-lanes and link-frequecnis
>>>>
>>>> Changes in v11:
>>>> -- add endpoint property at port@1
>>>>
>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>>
>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>>> property
>>> .git/rebase-apply/patch:47: trailing whitespace.
>>>
>>> .git/rebase-apply/patch:51: trailing whitespace.
>>>
>>>
>>> Also the dt_binding_check fails with an error for this schema. And
>>> after fixing the error in the schema I faced an example validation
>>> error. Did you check that the schema is correct and that the example
>>> validates against the schema?
>>
>> yes, but i run "make dt_binding_check
>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
>> at mu v5.15 branch since
>
> I wouldn't ask you to post the log here. But I don't think that either
> of the errors that I see here is related to 5.15 vs 6.1-rc.
>
> In fact after applying this patch against 5.15 I saw the expected
> failure:
>
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> properties:required: ['port@0', 'port@1'] is not of type 'object',
> 'boolean'
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> properties: 'required' should not be valid under {'$ref':
> '#/definitions/json-schema-prop-names'}
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> ignoring, error in schema: properties: required
>
>>
>> "make dt_binding_check" does not work at msm-next branch.
>
> I went ahead and just checked.
>
> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly in
> msm-next and reports a single example-related warning in
> msm-next-lumag. I pushed a patch to fix that warning (wich can
> hopefully be picked up by Abhinav into msm-fixes). So you can assume
> that both these branches have consistent error-free display/msm schemas.
>
I have clean msm-next branch (without my data-lines yaml patch applied)
and run "make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
then I saw below error messages.
Have you run into this problem?
HOSTCC scripts/basic/fixdep
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
HOSTCC scripts/dtc/dtc-lexer.lex.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTLD scripts/dtc/dtc
sort: -:2: disorder: 2022.1
ERROR: dtschema minimum version is v2022.3
make[2]: *** [check_dtschema_version] Error 1
make[1]: *** [dt_binding_check] Error 2
make: *** [__sub-make] Error 2
>>
>> But I did not check trainiling whitespace this time.
>>
>>>
>>>> ---
>>>> .../bindings/display/msm/dp-controller.yaml | 27
>>>> ++++++++++++++++++++++
>>>> 1 file changed, 27 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>> index f2515af..2a7fdef8 100644
>>>> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>> @@ -81,6 +81,7 @@ properties:
>>>> data-lanes:
>>>> $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> + deprecated: true
>>>> minItems: 1
>>>> maxItems: 4
>>>> items:
>>>> @@ -96,6 +97,7 @@ properties:
>>>> ports:
>>>> $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> properties:
>>>> port@0:
>>>> $ref: /schemas/graph.yaml#/properties/port
>>>> @@ -105,6 +107,29 @@ properties:
>>>> $ref: /schemas/graph.yaml#/properties/port
>>>> description: Output endpoint of the controller
>>>> + properties:
>>>> + endpoint:
>>>> + $ref: /schemas/media/video-interfaces.yaml#
>>>> +
>>>> + properties:
>>>> + remote-endpoint: true
>>>
>>> PLease add empty lines between the property definitions
>>>
>>>> + data-lanes:
>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>>
>>> This is already a part of video-interfaces, so you don't need $ref
>>>
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> + items:
>>>> + maximum: 3
>>>
>>> enum: [0, 1, 2, 3]
>>>
>>>> + link-frequencies:
>>>> + $ref: /schemas/types.yaml#/definitions/uint64-array
>>>> + minItems: 1
>>>> + maxItems: 4
>>>> + items:
>>>> + maximum: 8100000000
>>>
>>> I think we can have enum here too.
>>>
>>>> +
>>>> + required:
>>>> + - port@0
>>>> + - port@1
>>>> +
>>>> required:
>>>> - compatible
>>>> - reg
>>>> @@ -193,6 +218,8 @@ examples:
>>>> reg = <1>;
>>>> endpoint {
>>>> remote-endpoint = <&typec>;
>>>> + data-lanes = <0 1>;
>>>> + link-frequencies = /bits/ 64 <1620000000
>>>> 2700000000 5400000000 8100000000>;
>>>> };
>>>> };
>>>> };
>>>
>
On Thu, 08 Dec 2022 14:36:52 -0800, Kuogee Hsieh wrote:
> Add both data-lanes and link-frequencies property into endpoint
>
> Changes in v7:
> -- split yaml out of dtsi patch
> -- link-frequencies from link rate to symbol rate
> -- deprecation of old data-lanes property
>
> Changes in v8:
> -- correct Bjorn mail address to kernel.org
>
> Changes in v10:
> -- add menu item to data-lanes and link-frequecnis
>
> Changes in v11:
> -- add endpoint property at port@1
>
> Signed-off-by: Kuogee Hsieh <[email protected]>`
> ---
> .../bindings/display/msm/dp-controller.yaml | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml: properties:required: ['port@0', 'port@1'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml: properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/msm/dp-controller.yaml: ignoring, error in schema: properties: required
Documentation/devicetree/bindings/display/msm/dp-controller.example.dtb:0:0: /example-0/displayport-controller@ae90000: failed to match any schema with compatible: ['qcom,sc7180-dp']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
On 08/12/2022 23:36, Kuogee Hsieh wrote:
> Move data-lanes property from mdss_dp node to dp_out endpoint. Also
> add link-frequencies property into dp_out endpoint as well. The last
> frequency specified at link-frequencies will be the max link rate
> supported by DP.
>
> Changes in v5:
> -- revert changes at sc7180.dtsi and sc7280.dtsi
> -- add &dp_out to sc7180-trogdor.dtsi and sc7280-herobrine.dtsi
>
> Changes in v6:
> -- add data-lanes and link-frequencies to yaml
>
> Changes in v7:
> -- change 160000000 to 1620000000
> -- separate yaml to different patch
>
> Changes in v8:
> -- correct Bjorn mail address to kernel.org
>
> Changes in v9:
> -- use symbol rate (hz) for link-frequencies at dp_out at sc7180_trogdor.dtsi
>
> Signed-off-by: Kuogee Hsieh <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++++-
> arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 6 +++++-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> index eae22e6..93b0cde 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> @@ -814,7 +814,11 @@ hp_i2c: &i2c9 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hot_plug_det>;
> - data-lanes = <0 1>;
> +};
> +
> +&dp_out {
> + data-lanes = <0 1>;
Why adding two spaces? Just cut previous line and paste it, don't change it.
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
> };
>
> &pm6150_adc {
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> index c11e371..3c7a9d8 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> @@ -442,7 +442,11 @@ ap_i2c_tpm: &i2c14 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hot_plug_det>;
> - data-lanes = <0 1>;
> +};
> +
> +&dp_out {
> + data-lanes = <0 1>;
Ditto
Best regards,
Krzysztof
On 09/12/2022 00:38, Kuogee Hsieh wrote:
>
> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>> Add both data-lanes and link-frequencies property into endpoint
>>>
>>> Changes in v7:
>>> -- split yaml out of dtsi patch
>>> -- link-frequencies from link rate to symbol rate
>>> -- deprecation of old data-lanes property
>>>
>>> Changes in v8:
>>> -- correct Bjorn mail address to kernel.org
>>>
>>> Changes in v10:
>>> -- add menu item to data-lanes and link-frequecnis
>>>
>>> Changes in v11:
>>> -- add endpoint property at port@1
>>>
>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>
>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>> property
>> .git/rebase-apply/patch:47: trailing whitespace.
>>
>> .git/rebase-apply/patch:51: trailing whitespace.
>>
>>
>> Also the dt_binding_check fails with an error for this schema. And
>> after fixing the error in the schema I faced an example validation
>> error. Did you check that the schema is correct and that the example
>> validates against the schema?
>
> yes, but i run "make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
> at mu v5.15 branch since
v5.15 branch is not correct branch to work on a kernel. Please do not
send patches based on this. You must work on mainline, maintainer's next
branch or linux-next.
>
> "make dt_binding_check" does not work at msm-next branch.
Why would it not work there? I doubt that msm-next broke anything...
Best regards,
Krzysztof
Hi Kuogee,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on robh/for-next drm/drm-next linus/master v6.1-rc8 next-20221208]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kuogee-Hsieh/Add-data-lanes-and-link-frequencies-to-dp_out-endpoint/20221209-063949
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/1670539015-11808-5-git-send-email-quic_khsieh%40quicinc.com
patch subject: [PATCH v11 4/5] drm/msm/dp: parser link-frequencies as property of dp_out endpoint
config: arm-allyesconfig
compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/68f1162e16784bcedfb73b7a660077772686d0ef
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Kuogee-Hsieh/Add-data-lanes-and-link-frequencies-to-dp_out-endpoint/20221209-063949
git checkout 68f1162e16784bcedfb73b7a660077772686d0ef
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
arm-linux-gnueabi-ld: drivers/gpu/drm/msm/dp/dp_parser.o: in function `dp_parser_parse':
>> dp_parser.c:(.text+0xdf0): undefined reference to `__aeabi_uldivmod'
--
0-DAY CI Kernel Test Service
https://01.org/lkp
On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
> On 09/12/2022 02:22, Kuogee Hsieh wrote:
>>
>> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
>>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>>>
>>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>>>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>>>>> Add both data-lanes and link-frequencies property into endpoint
>>>>>>
>>>>>> Changes in v7:
>>>>>> -- split yaml out of dtsi patch
>>>>>> -- link-frequencies from link rate to symbol rate
>>>>>> -- deprecation of old data-lanes property
>>>>>>
>>>>>> Changes in v8:
>>>>>> -- correct Bjorn mail address to kernel.org
>>>>>>
>>>>>> Changes in v10:
>>>>>> -- add menu item to data-lanes and link-frequecnis
>>>>>>
>>>>>> Changes in v11:
>>>>>> -- add endpoint property at port@1
>>>>>>
>>>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>>>>
>>>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>>>>> property
>>>>> .git/rebase-apply/patch:47: trailing whitespace.
>>>>>
>>>>> .git/rebase-apply/patch:51: trailing whitespace.
>>>>>
>>>>>
>>>>> Also the dt_binding_check fails with an error for this schema. And
>>>>> after fixing the error in the schema I faced an example validation
>>>>> error. Did you check that the schema is correct and that the
>>>>> example validates against the schema?
>>>>
>>>> yes, but i run "make dt_binding_check
>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
>>>> at mu v5.15 branch since
>>>
>>> I wouldn't ask you to post the log here. But I don't think that
>>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
>>>
>>> In fact after applying this patch against 5.15 I saw the expected
>>> failure:
>>>
>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>> properties:required: ['port@0', 'port@1'] is not of type 'object',
>>> 'boolean'
>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>> properties: 'required' should not be valid under {'$ref':
>>> '#/definitions/json-schema-prop-names'}
>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>> ignoring, error in schema: properties: required
>>>
>>>>
>>>> "make dt_binding_check" does not work at msm-next branch.
>>>
>>> I went ahead and just checked.
>>>
>>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
>>> in msm-next and reports a single example-related warning in
>>> msm-next-lumag. I pushed a patch to fix that warning (wich can
>>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
>>> that both these branches have consistent error-free display/msm
>>> schemas.
>>>
>> I have clean msm-next branch (without my data-lines yaml patch
>> applied) and run "make dt_binding_check
>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
>> then I saw below error messages.
>>
>> Have you run into this problem?
>
> No.
Did you do anything to fix "older dtschema instance"?
I had run "pip3 install dtschema --upgrade" according Rob Herring response.
but it still shows same problem.
Please let know how can I fix this problem.
>
>>
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/dtc/dtc.o
>> HOSTCC scripts/dtc/flattree.o
>> HOSTCC scripts/dtc/fstree.o
>> HOSTCC scripts/dtc/data.o
>> HOSTCC scripts/dtc/livetree.o
>> HOSTCC scripts/dtc/treesource.o
>> HOSTCC scripts/dtc/srcpos.o
>> HOSTCC scripts/dtc/checks.o
>> HOSTCC scripts/dtc/util.o
>> LEX scripts/dtc/dtc-lexer.lex.c
>> HOSTCC scripts/dtc/dtc-lexer.lex.o
>> HOSTCC scripts/dtc/dtc-parser.tab.o
>> HOSTLD scripts/dtc/dtc
>> sort: -:2: disorder: 2022.1
>> ERROR: dtschema minimum version is v2022.3
>> make[2]: *** [check_dtschema_version] Error 1
>> make[1]: *** [dt_binding_check] Error 2
>> make: *** [__sub-make] Error 2
>
> This means that somewhere in your path you have an older dtschema
> instance.
>
> When you sent me a question regarding this error, I asked for the
> additional info. You provided none. Instead you went on sending the
> untested patch that doesn't work.
since i can not test it on msm-next so that I did test it at my v5-15
branch.
besides, i think i have to sent the whole series patches include this
one to address your new comments on other patch.
is this correct?
>
>>
>>>>
>>>> But I did not check trainiling whitespace this time.
>>>>
>>>>>
>>>>>> ---
>>>>>> .../bindings/display/msm/dp-controller.yaml | 27
>>>>>> ++++++++++++++++++++++
>>>>>> 1 file changed, 27 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>>> index f2515af..2a7fdef8 100644
>>>>>> ---
>>>>>> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>>> +++
>>>>>> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
>>>>>> @@ -81,6 +81,7 @@ properties:
>>>>>> data-lanes:
>>>>>> $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>> + deprecated: true
>>>>>> minItems: 1
>>>>>> maxItems: 4
>>>>>> items:
>>>>>> @@ -96,6 +97,7 @@ properties:
>>>>>> ports:
>>>>>> $ref: /schemas/graph.yaml#/properties/ports
>>>>>> +
>>>>>> properties:
>>>>>> port@0:
>>>>>> $ref: /schemas/graph.yaml#/properties/port
>>>>>> @@ -105,6 +107,29 @@ properties:
>>>>>> $ref: /schemas/graph.yaml#/properties/port
>>>>>> description: Output endpoint of the controller
>>>>>> + properties:
>>>>>> + endpoint:
>>>>>> + $ref: /schemas/media/video-interfaces.yaml#
>>>>>> +
>>>>>> + properties:
>>>>>> + remote-endpoint: true
>>>>>
>>>>> PLease add empty lines between the property definitions
>>>>>
>>>>>> + data-lanes:
>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>
>>>>> This is already a part of video-interfaces, so you don't need $ref
>>>>>
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> + items:
>>>>>> + maximum: 3
>>>>>
>>>>> enum: [0, 1, 2, 3]
>>>>>
>>>>>> + link-frequencies:
>>>>>> + $ref: /schemas/types.yaml#/definitions/uint64-array
>>>>>> + minItems: 1
>>>>>> + maxItems: 4
>>>>>> + items:
>>>>>> + maximum: 8100000000
>>>>>
>>>>> I think we can have enum here too.
>>>>>
>>>>>> +
>>>>>> + required:
>>>>>> + - port@0
>>>>>> + - port@1
>>>>>> +
>>>>>> required:
>>>>>> - compatible
>>>>>> - reg
>>>>>> @@ -193,6 +218,8 @@ examples:
>>>>>> reg = <1>;
>>>>>> endpoint {
>>>>>> remote-endpoint = <&typec>;
>>>>>> + data-lanes = <0 1>;
>>>>>> + link-frequencies = /bits/ 64 <1620000000
>>>>>> 2700000000 5400000000 8100000000>;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>
>>>
>
On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh <[email protected]> wrote:
>
>
> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
> > On 09/12/2022 02:22, Kuogee Hsieh wrote:
> >>
> >> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
> >>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
> >>>>
> >>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
> >>>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
> >>>>>> Add both data-lanes and link-frequencies property into endpoint
> >>>>>>
> >>>>>> Changes in v7:
> >>>>>> -- split yaml out of dtsi patch
> >>>>>> -- link-frequencies from link rate to symbol rate
> >>>>>> -- deprecation of old data-lanes property
> >>>>>>
> >>>>>> Changes in v8:
> >>>>>> -- correct Bjorn mail address to kernel.org
> >>>>>>
> >>>>>> Changes in v10:
> >>>>>> -- add menu item to data-lanes and link-frequecnis
> >>>>>>
> >>>>>> Changes in v11:
> >>>>>> -- add endpoint property at port@1
> >>>>>>
> >>>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
> >>>>>
> >>>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
> >>>>> property
> >>>>> .git/rebase-apply/patch:47: trailing whitespace.
> >>>>>
> >>>>> .git/rebase-apply/patch:51: trailing whitespace.
> >>>>>
> >>>>>
> >>>>> Also the dt_binding_check fails with an error for this schema. And
> >>>>> after fixing the error in the schema I faced an example validation
> >>>>> error. Did you check that the schema is correct and that the
> >>>>> example validates against the schema?
> >>>>
> >>>> yes, but i run "make dt_binding_check
> >>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
> >>>> at mu v5.15 branch since
> >>>
> >>> I wouldn't ask you to post the log here. But I don't think that
> >>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
> >>>
> >>> In fact after applying this patch against 5.15 I saw the expected
> >>> failure:
> >>>
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> properties:required: ['port@0', 'port@1'] is not of type 'object',
> >>> 'boolean'
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> properties: 'required' should not be valid under {'$ref':
> >>> '#/definitions/json-schema-prop-names'}
> >>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
> >>> ignoring, error in schema: properties: required
> >>>
> >>>>
> >>>> "make dt_binding_check" does not work at msm-next branch.
> >>>
> >>> I went ahead and just checked.
> >>>
> >>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
> >>> in msm-next and reports a single example-related warning in
> >>> msm-next-lumag. I pushed a patch to fix that warning (wich can
> >>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
> >>> that both these branches have consistent error-free display/msm
> >>> schemas.
> >>>
> >> I have clean msm-next branch (without my data-lines yaml patch
> >> applied) and run "make dt_binding_check
> >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
> >> then I saw below error messages.
> >>
> >> Have you run into this problem?
> >
> > No.
>
> Did you do anything to fix "older dtschema instance"?
I did not since I hadn't had such a problem. I can refer again to the
steps I provided you beforehand. The email was sent 6 days ago. No
answer from your side since that time.
> I had run "pip3 install dtschema --upgrade" and still not work.
Can you please post a full log of this command?
>
> D you know how to fix this problem?
>
> Thanks,
>
> kuogee
>
> sort: -:2: disorder: 2022.1
> ERROR: dtschema minimum version is v2022.3
> make[2]: *** [check_dtschema_version] Error 1
> make[1]: *** [dt_binding_check] Error 2
> make: *** [__sub-make] Error 2
Please add the output of:
which dt-validate
dt-validate -V
And also a full log of your failing kernel build.
> I had run "pip3 install dtschema --upgrade" according Rob Herring response.
> but it still shows same problem.
> Please let know how can I fix this problem.
>
> >
> >>
> >> HOSTCC scripts/basic/fixdep
> >> HOSTCC scripts/dtc/dtc.o
> >> HOSTCC scripts/dtc/flattree.o
> >> HOSTCC scripts/dtc/fstree.o
> >> HOSTCC scripts/dtc/data.o
> >> HOSTCC scripts/dtc/livetree.o
> >> HOSTCC scripts/dtc/treesource.o
> >> HOSTCC scripts/dtc/srcpos.o
> >> HOSTCC scripts/dtc/checks.o
> >> HOSTCC scripts/dtc/util.o
> >> LEX scripts/dtc/dtc-lexer.lex.c
> >> HOSTCC scripts/dtc/dtc-lexer.lex.o
> >> HOSTCC scripts/dtc/dtc-parser.tab.o
> >> HOSTLD scripts/dtc/dtc
> >> sort: -:2: disorder: 2022.1
> >> ERROR: dtschema minimum version is v2022.3
> >> make[2]: *** [check_dtschema_version] Error 1
> >> make[1]: *** [dt_binding_check] Error 2
> >> make: *** [__sub-make] Error 2
> >
> > This means that somewhere in your path you have an older dtschema
> > instance.
> >
> > When you sent me a question regarding this error, I asked for the
> > additional info. You provided none. Instead you went on sending the
> > untested patch that doesn't work.
>
> since i can not test it on msm-next so that I did test it at my v5-15
> branch.
Wrong.
>
> besides, i think i have to sent the whole series patches include this
> one to address your new comments on other patch.
>
> is this correct?
No. Please fix your system first, validate your patches and send them
afterwards. You can not expect others to do your job.
--
With best wishes
Dmitry
Hi Dmitry
On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
> On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh <[email protected]> wrote:
>>
>>
>> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
>>> On 09/12/2022 02:22, Kuogee Hsieh wrote:
>>>>
>>>> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
>>>>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>>>>>
>>>>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>>>>>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>>>>>>> Add both data-lanes and link-frequencies property into endpoint
>>>>>>>>
>>>>>>>> Changes in v7:
>>>>>>>> -- split yaml out of dtsi patch
>>>>>>>> -- link-frequencies from link rate to symbol rate
>>>>>>>> -- deprecation of old data-lanes property
>>>>>>>>
>>>>>>>> Changes in v8:
>>>>>>>> -- correct Bjorn mail address to kernel.org
>>>>>>>>
>>>>>>>> Changes in v10:
>>>>>>>> -- add menu item to data-lanes and link-frequecnis
>>>>>>>>
>>>>>>>> Changes in v11:
>>>>>>>> -- add endpoint property at port@1
>>>>>>>>
>>>>>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>>>>>>
>>>>>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>>>>>>> property
>>>>>>> .git/rebase-apply/patch:47: trailing whitespace.
>>>>>>>
>>>>>>> .git/rebase-apply/patch:51: trailing whitespace.
>>>>>>>
>>>>>>>
>>>>>>> Also the dt_binding_check fails with an error for this schema. And
>>>>>>> after fixing the error in the schema I faced an example validation
>>>>>>> error. Did you check that the schema is correct and that the
>>>>>>> example validates against the schema?
>>>>>>
>>>>>> yes, but i run "make dt_binding_check
>>>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
>>>>>> at mu v5.15 branch since
>>>>>
>>>>> I wouldn't ask you to post the log here. But I don't think that
>>>>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
>>>>>
>>>>> In fact after applying this patch against 5.15 I saw the expected
>>>>> failure:
>>>>>
>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>> properties:required: ['port@0', 'port@1'] is not of type 'object',
>>>>> 'boolean'
>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>> properties: 'required' should not be valid under {'$ref':
>>>>> '#/definitions/json-schema-prop-names'}
>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>> ignoring, error in schema: properties: required
>>>>>
>>>>>>
>>>>>> "make dt_binding_check" does not work at msm-next branch.
>>>>>
>>>>> I went ahead and just checked.
>>>>>
>>>>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
>>>>> in msm-next and reports a single example-related warning in
>>>>> msm-next-lumag. I pushed a patch to fix that warning (wich can
>>>>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
>>>>> that both these branches have consistent error-free display/msm
>>>>> schemas.
>>>>>
>>>> I have clean msm-next branch (without my data-lines yaml patch
>>>> applied) and run "make dt_binding_check
>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
>>>> then I saw below error messages.
>>>>
>>>> Have you run into this problem?
>>>
>>> No.
>>
>> Did you do anything to fix "older dtschema instance"?
>
> I did not since I hadn't had such a problem. I can refer again to the
> steps I provided you beforehand. The email was sent 6 days ago. No
> answer from your side since that time.
>
>> I had run "pip3 install dtschema --upgrade" and still not work.
>
> Can you please post a full log of this command?
>
>>
>> D you know how to fix this problem?
>>
>> Thanks,
>>
>> kuogee
>>
>> sort: -:2: disorder: 2022.1
>> ERROR: dtschema minimum version is v2022.3
>> make[2]: *** [check_dtschema_version] Error 1
>> make[1]: *** [dt_binding_check] Error 2
>> make: *** [__sub-make] Error 2
>
> Please add the output of:
>
> which dt-validate
> dt-validate -V
>
> And also a full log of your failing kernel build.
>
>
>
>> I had run "pip3 install dtschema --upgrade" according Rob Herring response.
>> but it still shows same problem.
>> Please let know how can I fix this problem.
>>
>>>
>>>>
>>>> HOSTCC scripts/basic/fixdep
>>>> HOSTCC scripts/dtc/dtc.o
>>>> HOSTCC scripts/dtc/flattree.o
>>>> HOSTCC scripts/dtc/fstree.o
>>>> HOSTCC scripts/dtc/data.o
>>>> HOSTCC scripts/dtc/livetree.o
>>>> HOSTCC scripts/dtc/treesource.o
>>>> HOSTCC scripts/dtc/srcpos.o
>>>> HOSTCC scripts/dtc/checks.o
>>>> HOSTCC scripts/dtc/util.o
>>>> LEX scripts/dtc/dtc-lexer.lex.c
>>>> HOSTCC scripts/dtc/dtc-lexer.lex.o
>>>> HOSTCC scripts/dtc/dtc-parser.tab.o
>>>> HOSTLD scripts/dtc/dtc
>>>> sort: -:2: disorder: 2022.1
>>>> ERROR: dtschema minimum version is v2022.3
>>>> make[2]: *** [check_dtschema_version] Error 1
>>>> make[1]: *** [dt_binding_check] Error 2
>>>> make: *** [__sub-make] Error 2
>>>
>>> This means that somewhere in your path you have an older dtschema
>>> instance.
>>>
>>> When you sent me a question regarding this error, I asked for the
>>> additional info. You provided none. Instead you went on sending the
>>> untested patch that doesn't work.
>>
>> since i can not test it on msm-next so that I did test it at my v5-15
>> branch.
>
> Wrong.
>
>>
>> besides, i think i have to sent the whole series patches include this
>> one to address your new comments on other patch.
>>
>> is this correct?
>
> No. Please fix your system first, validate your patches and send them
> afterwards. You can not expect others to do your job.
>
Just finished working with kuogee on this. This issue had been reported
by few others earlier (example
https://lore.kernel.org/lkml/[email protected]/T/).
So let me summarize the fix:
1) We do need up upgrade the dtschema first
pip3 install git+https://github.com/devicetree-org/dt-schema.git@main
2) Python version issues were hitting some of the developers so even if
we had the right version installed the PATH wasnt pointing to the right one
3) We had to install yamllint
We have documented these now for the benefit of others internally.
With all these 3 done, we can compile msm-next-lumag using
make dt_binding_check DT_SCHEMA_FILES=display/msm
Apologies for the setup issues on our end. These are resolved now and
kuogee will post a v12 for this.
Thanks
Abhinav
> --
> With best wishes
> Dmitry
On 13 December 2022 02:41:55 GMT+03:00, Abhinav Kumar <[email protected]> wrote:
>Hi Dmitry
>
>On 12/12/2022 2:35 PM, Dmitry Baryshkov wrote:
>> On Mon, 12 Dec 2022 at 19:51, Kuogee Hsieh <[email protected]> wrote:
>>>
>>>
>>> On 12/8/2022 4:35 PM, Dmitry Baryshkov wrote:
>>>> On 09/12/2022 02:22, Kuogee Hsieh wrote:
>>>>>
>>>>> On 12/8/2022 4:11 PM, Dmitry Baryshkov wrote:
>>>>>> On 09/12/2022 01:38, Kuogee Hsieh wrote:
>>>>>>>
>>>>>>> On 12/8/2022 3:33 PM, Dmitry Baryshkov wrote:
>>>>>>>> On 09/12/2022 00:36, Kuogee Hsieh wrote:
>>>>>>>>> Add both data-lanes and link-frequencies property into endpoint
>>>>>>>>>
>>>>>>>>> Changes in v7:
>>>>>>>>> -- split yaml out of dtsi patch
>>>>>>>>> -- link-frequencies from link rate to symbol rate
>>>>>>>>> -- deprecation of old data-lanes property
>>>>>>>>>
>>>>>>>>> Changes in v8:
>>>>>>>>> -- correct Bjorn mail address to kernel.org
>>>>>>>>>
>>>>>>>>> Changes in v10:
>>>>>>>>> -- add menu item to data-lanes and link-frequecnis
>>>>>>>>>
>>>>>>>>> Changes in v11:
>>>>>>>>> -- add endpoint property at port@1
>>>>>>>>>
>>>>>>>>> Signed-off-by: Kuogee Hsieh <[email protected]>`
>>>>>>>>
>>>>>>>> Applying: dt-bindings: msm/dp: add data-lanes and link-frequencies
>>>>>>>> property
>>>>>>>> .git/rebase-apply/patch:47: trailing whitespace.
>>>>>>>>
>>>>>>>> .git/rebase-apply/patch:51: trailing whitespace.
>>>>>>>>
>>>>>>>>
>>>>>>>> Also the dt_binding_check fails with an error for this schema. And
>>>>>>>> after fixing the error in the schema I faced an example validation
>>>>>>>> error. Did you check that the schema is correct and that the
>>>>>>>> example validates against the schema?
>>>>>>>
>>>>>>> yes, but i run "make dt_binding_check
>>>>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml"
>>>>>>> at mu v5.15 branch since
>>>>>>
>>>>>> I wouldn't ask you to post the log here. But I don't think that
>>>>>> either of the errors that I see here is related to 5.15 vs 6.1-rc.
>>>>>>
>>>>>> In fact after applying this patch against 5.15 I saw the expected
>>>>>> failure:
>>>>>>
>>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>>> properties:required: ['port@0', 'port@1'] is not of type 'object',
>>>>>> 'boolean'
>>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>>> properties: 'required' should not be valid under {'$ref':
>>>>>> '#/definitions/json-schema-prop-names'}
>>>>>> Documentation/devicetree/bindings/display/msm/dp-controller.yaml:
>>>>>> ignoring, error in schema: properties: required
>>>>>>
>>>>>>>
>>>>>>> "make dt_binding_check" does not work at msm-next branch.
>>>>>>
>>>>>> I went ahead and just checked.
>>>>>>
>>>>>> `make dt_binding_check DT_SCHEMA_FILES=display/msm` works cleanly
>>>>>> in msm-next and reports a single example-related warning in
>>>>>> msm-next-lumag. I pushed a patch to fix that warning (wich can
>>>>>> hopefully be picked up by Abhinav into msm-fixes). So you can assume
>>>>>> that both these branches have consistent error-free display/msm
>>>>>> schemas.
>>>>>>
>>>>> I have clean msm-next branch (without my data-lines yaml patch
>>>>> applied) and run "make dt_binding_check
>>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/msm/dp-controller.yaml",
>>>>> then I saw below error messages.
>>>>>
>>>>> Have you run into this problem?
>>>>
>>>> No.
>>>
>>> Did you do anything to fix "older dtschema instance"?
>>
>> I did not since I hadn't had such a problem. I can refer again to the
>> steps I provided you beforehand. The email was sent 6 days ago. No
>> answer from your side since that time.
>>
>>> I had run "pip3 install dtschema --upgrade" and still not work.
>>
>> Can you please post a full log of this command?
>>
>>>
>>> D you know how to fix this problem?
>>>
>>> Thanks,
>>>
>>> kuogee
>>>
>>> sort: -:2: disorder: 2022.1
>>> ERROR: dtschema minimum version is v2022.3
>>> make[2]: *** [check_dtschema_version] Error 1
>>> make[1]: *** [dt_binding_check] Error 2
>>> make: *** [__sub-make] Error 2
>>
>> Please add the output of:
>>
>> which dt-validate
>> dt-validate -V
>>
>> And also a full log of your failing kernel build.
>>
>>
>>
>>> I had run "pip3 install dtschema --upgrade" according Rob Herring response.
>>> but it still shows same problem.
>>> Please let know how can I fix this problem.
>>>
>>>>
>>>>>
>>>>> HOSTCC scripts/basic/fixdep
>>>>> HOSTCC scripts/dtc/dtc.o
>>>>> HOSTCC scripts/dtc/flattree.o
>>>>> HOSTCC scripts/dtc/fstree.o
>>>>> HOSTCC scripts/dtc/data.o
>>>>> HOSTCC scripts/dtc/livetree.o
>>>>> HOSTCC scripts/dtc/treesource.o
>>>>> HOSTCC scripts/dtc/srcpos.o
>>>>> HOSTCC scripts/dtc/checks.o
>>>>> HOSTCC scripts/dtc/util.o
>>>>> LEX scripts/dtc/dtc-lexer.lex.c
>>>>> HOSTCC scripts/dtc/dtc-lexer.lex.o
>>>>> HOSTCC scripts/dtc/dtc-parser.tab.o
>>>>> HOSTLD scripts/dtc/dtc
>>>>> sort: -:2: disorder: 2022.1
>>>>> ERROR: dtschema minimum version is v2022.3
>>>>> make[2]: *** [check_dtschema_version] Error 1
>>>>> make[1]: *** [dt_binding_check] Error 2
>>>>> make: *** [__sub-make] Error 2
>>>>
>>>> This means that somewhere in your path you have an older dtschema
>>>> instance.
>>>>
>>>> When you sent me a question regarding this error, I asked for the
>>>> additional info. You provided none. Instead you went on sending the
>>>> untested patch that doesn't work.
>>>
>>> since i can not test it on msm-next so that I did test it at my v5-15
>>> branch.
>>
>> Wrong.
>>
>>>
>>> besides, i think i have to sent the whole series patches include this
>>> one to address your new comments on other patch.
>>>
>>> is this correct?
>>
>> No. Please fix your system first, validate your patches and send them
>> afterwards. You can not expect others to do your job.
>>
>
>Just finished working with kuogee on this. This issue had been reported by few others earlier (example https://lore.kernel.org/lkml/[email protected]/T/).
Thanks a lot for helping Kuogee!
>
>So let me summarize the fix:
>
>1) We do need up upgrade the dtschema first
>
>pip3 install git+https://github.com/devicetree-org/dt-schema.git@main
I'd stick to the released version, unless there is any indication that the trunk has any significant features. Rob, Krzysztof, please correct me if I'm wrong.
>
>2) Python version issues were hitting some of the developers so even if we had the right version installed the PATH wasnt pointing to the right one
Yes, that is what I expected, when I asked for the pip command log and for the `which' command output.
I usually install dtschema to my user's dir and add ~/.local/bin to PATH.
>
>3) We had to install yamllint
>
>We have documented these now for the benefit of others internally.
>
>With all these 3 done, we can compile msm-next-lumag using
>make dt_binding_check DT_SCHEMA_FILES=display/msm
>
>Apologies for the setup issues on our end. These are resolved now and kuogee will post a v12 for this.
Great, I'm looking forward to seeing it and finally merging it!
>
>Thanks
>
>Abhinav
>> --
>> With best wishes
>> Dmitry
--
With best wishes
Dmitry
On 13/12/2022 00:41, Abhinav Kumar wrote:
>>>
>>> besides, i think i have to sent the whole series patches include this
>>> one to address your new comments on other patch.
>>>
>>> is this correct?
>>
>> No. Please fix your system first, validate your patches and send them
>> afterwards. You can not expect others to do your job.
>>
>
> Just finished working with kuogee on this. This issue had been reported
> by few others earlier (example
> https://lore.kernel.org/lkml/[email protected]/T/).
This report says:
"Sorry for the inconvenience, please ignore this false positive."
Best regards,
Krzysztof
On 12/13/2022 5:13 AM, Krzysztof Kozlowski wrote:
> On 13/12/2022 00:41, Abhinav Kumar wrote:
>>>>
>>>> besides, i think i have to sent the whole series patches include this
>>>> one to address your new comments on other patch.
>>>>
>>>> is this correct?
>>>
>>> No. Please fix your system first, validate your patches and send them
>>> afterwards. You can not expect others to do your job.
>>>
>>
>> Just finished working with kuogee on this. This issue had been reported
>> by few others earlier (example
>> https://lore.kernel.org/lkml/[email protected]/T/).
>
> This report says:
> "Sorry for the inconvenience, please ignore this false positive."
>
That was one of them, and I dont think its false, maybe because after
fixing the PATH issues, the user deemed them as false.
Here is another one
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]/
with the same report but no resolution.
So i thought for the benefit of others I would atleast summarize how we
resolved them.
> Best regards,
> Krzysztof
>
On 13/12/2022 18:31, Abhinav Kumar wrote:
>
>
> On 12/13/2022 5:13 AM, Krzysztof Kozlowski wrote:
>> On 13/12/2022 00:41, Abhinav Kumar wrote:
>>>>>
>>>>> besides, i think i have to sent the whole series patches include this
>>>>> one to address your new comments on other patch.
>>>>>
>>>>> is this correct?
>>>>
>>>> No. Please fix your system first, validate your patches and send them
>>>> afterwards. You can not expect others to do your job.
>>>>
>>>
>>> Just finished working with kuogee on this. This issue had been reported
>>> by few others earlier (example
>>> https://lore.kernel.org/lkml/[email protected]/T/).
>>
>> This report says:
>> "Sorry for the inconvenience, please ignore this false positive."
>>
>
> That was one of them, and I dont think its false, maybe because after
> fixing the PATH issues, the user deemed them as false.
>
> Here is another one
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]/
> with the same report but no resolution.
Thanks. Could be also Python mismatch. `make dt_binding_check` could use
dtschema from Python2 but the reporter used Python3 for checking the
version: `pip3 show dtschema`
>
> So i thought for the benefit of others I would atleast summarize how we
> resolved them.
Sure, that's helpful.
Best regards,
Krzysztof