[PATCH v5 0/9] Add support for the eDP panel on sc7280 CRD

[PATCH v5 0/9] Add support for the eDP panel on sc7280 CRD

[Sankeerth Billakanti]

This series adds support for eDP on sc7280 CRD platform.

These changes are dependent on the following series in order:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=616587&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=613654&state=*

Sankeerth Billakanti (9):
  arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out
  arm64: dts: qcom: sc7280: Add support for eDP panel on CRD
  arm64: dts: qcom: sc7280: Enable backlight for eDP panel
  drm/panel-edp: add LQ140M1JW46 edp panel entry
  drm/msm/dp: Add eDP support via aux_bus
  drm/msm/dp: wait for hpd high before any sink interaction
  drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP
  drm/msm/dp: Handle eDP mode_valid case
  drm/msm/dp: Support edp/dp without hpd

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 111 ++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7280.dtsi    |   2 +-
 drivers/gpu/drm/msm/dp/dp_aux.c         |   6 ++
 drivers/gpu/drm/msm/dp/dp_catalog.c     |  38 ++++++++---
 drivers/gpu/drm/msm/dp/dp_catalog.h     |   1 +
 drivers/gpu/drm/msm/dp/dp_display.c     |  95 +++++++++++++++++++++++++--
 drivers/gpu/drm/msm/dp/dp_drm.c         |  10 +--
 drivers/gpu/drm/msm/dp/dp_parser.c      |  21 +-----
 drivers/gpu/drm/msm/dp/dp_parser.h      |   1 +
 drivers/gpu/drm/msm/dp/dp_reg.h         |   7 +-
 drivers/gpu/drm/panel/panel-edp.c       |   1 +
 11 files changed, 254 insertions(+), 39 deletions(-)

-- 
2.7.4

[PATCH v5 0/9] Add support for the eDP panel on sc7280 CRD

[Sankeerth Billakanti]

This series adds support for eDP on sc7280 CRD platform.

These changes are dependent on the following series in order:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=616587&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=613654&state=*

Sankeerth Billakanti (9):
  arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out
  arm64: dts: qcom: sc7280: Add support for eDP panel on CRD
  arm64: dts: qcom: sc7280: Enable backlight for eDP panel
  drm/panel-edp: add LQ140M1JW46 edp panel entry
  drm/msm/dp: Add eDP support via aux_bus
  drm/msm/dp: wait for hpd high before any sink interaction
  drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP
  drm/msm/dp: Handle eDP mode_valid case
  drm/msm/dp: Support edp/dp without hpd

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 111 ++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7280.dtsi    |   2 +-
 drivers/gpu/drm/msm/dp/dp_aux.c         |   6 ++
 drivers/gpu/drm/msm/dp/dp_catalog.c     |  38 ++++++++---
 drivers/gpu/drm/msm/dp/dp_catalog.h     |   1 +
 drivers/gpu/drm/msm/dp/dp_display.c     |  95 +++++++++++++++++++++++++--
 drivers/gpu/drm/msm/dp/dp_drm.c         |  10 +--
 drivers/gpu/drm/msm/dp/dp_parser.c      |  21 +-----
 drivers/gpu/drm/msm/dp/dp_parser.h      |   1 +
 drivers/gpu/drm/msm/dp/dp_reg.h         |   7 +-
 drivers/gpu/drm/panel/panel-edp.c       |   1 +
 11 files changed, 254 insertions(+), 39 deletions(-)

-- 
2.7.4

[PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Sankeerth Billakanti]

Rename the edp_out label in the sc7280 platform to mdss_edp_out
so that the nodes related to mdss are all grouped together in
the board specific files.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Change the order of patches
  - Modify commit text

 arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index c07765d..bcf7562 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3332,7 +3332,7 @@
 
 					port@1 {
 						reg = <1>;
-						edp_out: endpoint { };
+						mdss_edp_out: endpoint { };
 					};
 				};
 
-- 
2.7.4

[PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Sankeerth Billakanti]

Rename the edp_out label in the sc7280 platform to mdss_edp_out
so that the nodes related to mdss are all grouped together in
the board specific files.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Change the order of patches
  - Modify commit text

 arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index c07765d..bcf7562 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3332,7 +3332,7 @@
 
 					port@1 {
 						reg = <1>;
-						edp_out: endpoint { };
+						mdss_edp_out: endpoint { };
 					};
 				};
 
-- 
2.7.4

Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:46)
> Rename the edp_out label in the sc7280 platform to mdss_edp_out
> so that the nodes related to mdss are all grouped together in
> the board specific files.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:46)
> Rename the edp_out label in the sc7280 platform to mdss_edp_out
> so that the nodes related to mdss are all grouped together in
> the board specific files.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Rename the edp_out label in the sc7280 platform to mdss_edp_out
> so that the nodes related to mdss are all grouped together in
> the board specific files.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Change the order of patches
>   - Modify commit text
>
>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH v5 1/9] arm64: dts: qcom: sc7280: rename edp_out label to mdss_edp_out

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Rename the edp_out label in the sc7280 platform to mdss_edp_out
> so that the nodes related to mdss are all grouped together in
> the board specific files.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Change the order of patches
>   - Modify commit text
>
>  arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

[PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti]

Enable support for eDP interface via aux_bus on CRD platform.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Change the order of patches
  - Remove the backlight nodes
  - Remove the bias setting
  - Fix compilation issue
  - Model VREG_EDP_BP for backlight power

Changes in v4:
  - Create new patch for name changes
  - Remove output-low

Changes in v3:
  - Sort the nodes alphabetically
  - Use - instead of _ as node names
  - Place the backlight and panel nodes under root
  - Change the name of edp_out to mdss_edp_out
  - Change the names of regulator nodes
  - Delete unused properties in the board file


Changes in v2:
  - Sort node references alphabetically
  - Improve readability
  - Move the pwm pinctrl to pwm node
  - Move the regulators to root
  - Define backlight power
  - Remove dummy regulator node
  - Cleanup pinctrl definitions

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93 +++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index e2efbdd..2df654e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include "sc7280-idp.dtsi"
 #include "sc7280-idp-ec-h1.dtsi"
 
@@ -21,6 +22,27 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	edp_3v3_regulator: edp-3v3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "edp_3v3_regulator";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_panel_power>;
+	};
+
+	vreg_edp_bp: vreg-edp-bp-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_edp_bp";
+		regulator-always-on;
+		regulator-boot-on;
+	};
 };
 
 &apps_rsc {
@@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
 	};
 };
 
+&mdss {
+	status = "okay";
+};
+
+&mdss_dp {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dp_hot_plug_det>;
+	data-lanes = <0 1>;
+	vdda-1p2-supply = <&vreg_l6b_1p2>;
+	vdda-0p9-supply = <&vreg_l1b_0p8>;
+};
+
+&mdss_edp {
+	status = "okay";
+
+	data-lanes = <0 1 2 3>;
+	vdda-1p2-supply = <&vreg_l6b_1p2>;
+	vdda-0p9-supply = <&vreg_l10c_0p8>;
+
+	aux-bus {
+		edp_panel: edp-panel {
+			compatible = "edp-panel";
+
+			power-supply = <&edp_3v3_regulator>;
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				port@0 {
+					reg = <0>;
+					edp_panel_in: endpoint {
+						remote-endpoint = <&mdss_edp_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&mdss_edp_out {
+	remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_edp_phy {
+	status = "okay";
+};
+
+&mdss_mdp {
+	status = "okay";
+};
+
 &nvme_3v3_regulator {
 	gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
 };
@@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
 	pins = "gpio51";
 };
 
+&pm8350c_gpios {
+	edp_bl_power: edp-bl-power {
+		pins = "gpio7";
+		function = "normal";
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+	};
+
+	edp_bl_pwm: edp-bl-pwm {
+		pins = "gpio8";
+		function = "func1";
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+	};
+};
+
 &tlmm {
+	edp_panel_power: edp-panel-power {
+		pins = "gpio80";
+		function = "gpio";
+	};
+
 	tp_int_odl: tp-int-odl {
 		pins = "gpio7";
 		function = "gpio";
-- 
2.7.4

[PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti]

Enable support for eDP interface via aux_bus on CRD platform.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Change the order of patches
  - Remove the backlight nodes
  - Remove the bias setting
  - Fix compilation issue
  - Model VREG_EDP_BP for backlight power

Changes in v4:
  - Create new patch for name changes
  - Remove output-low

Changes in v3:
  - Sort the nodes alphabetically
  - Use - instead of _ as node names
  - Place the backlight and panel nodes under root
  - Change the name of edp_out to mdss_edp_out
  - Change the names of regulator nodes
  - Delete unused properties in the board file


Changes in v2:
  - Sort node references alphabetically
  - Improve readability
  - Move the pwm pinctrl to pwm node
  - Move the regulators to root
  - Define backlight power
  - Remove dummy regulator node
  - Cleanup pinctrl definitions

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93 +++++++++++++++++++++++++++++++++
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index e2efbdd..2df654e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
 #include "sc7280-idp.dtsi"
 #include "sc7280-idp-ec-h1.dtsi"
 
@@ -21,6 +22,27 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	edp_3v3_regulator: edp-3v3-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "edp_3v3_regulator";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_panel_power>;
+	};
+
+	vreg_edp_bp: vreg-edp-bp-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_edp_bp";
+		regulator-always-on;
+		regulator-boot-on;
+	};
 };
 
 &apps_rsc {
@@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
 	};
 };
 
+&mdss {
+	status = "okay";
+};
+
+&mdss_dp {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dp_hot_plug_det>;
+	data-lanes = <0 1>;
+	vdda-1p2-supply = <&vreg_l6b_1p2>;
+	vdda-0p9-supply = <&vreg_l1b_0p8>;
+};
+
+&mdss_edp {
+	status = "okay";
+
+	data-lanes = <0 1 2 3>;
+	vdda-1p2-supply = <&vreg_l6b_1p2>;
+	vdda-0p9-supply = <&vreg_l10c_0p8>;
+
+	aux-bus {
+		edp_panel: edp-panel {
+			compatible = "edp-panel";
+
+			power-supply = <&edp_3v3_regulator>;
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				port@0 {
+					reg = <0>;
+					edp_panel_in: endpoint {
+						remote-endpoint = <&mdss_edp_out>;
+					};
+				};
+			};
+		};
+	};
+};
+
+&mdss_edp_out {
+	remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_edp_phy {
+	status = "okay";
+};
+
+&mdss_mdp {
+	status = "okay";
+};
+
 &nvme_3v3_regulator {
 	gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
 };
@@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
 	pins = "gpio51";
 };
 
+&pm8350c_gpios {
+	edp_bl_power: edp-bl-power {
+		pins = "gpio7";
+		function = "normal";
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+	};
+
+	edp_bl_pwm: edp-bl-pwm {
+		pins = "gpio8";
+		function = "func1";
+		qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+	};
+};
+
 &tlmm {
+	edp_panel_power: edp-panel-power {
+		pins = "gpio80";
+		function = "gpio";
+	};
+
 	tp_int_odl: tp-int-odl {
 		pins = "gpio7";
 		function = "gpio";
-- 
2.7.4

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:47)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index e2efbdd..2df654e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -7,6 +7,7 @@
>
>  /dts-v1/;
>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>  #include "sc7280-idp.dtsi"
>  #include "sc7280-idp-ec-h1.dtsi"
>
> @@ -21,6 +22,27 @@
>         chosen {
>                 stdout-path = "serial0:115200n8";
>         };
> +
> +       edp_3v3_regulator: edp-3v3-regulator {
> +               compatible = "regulator-fixed";
> +               regulator-name = "edp_3v3_regulator";
> +
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +
> +               gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> +               enable-active-high;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&edp_panel_power>;
> +       };
> +
> +       vreg_edp_bp: vreg-edp-bp-regulator {
> +               compatible = "regulator-fixed";
> +               regulator-name = "vreg_edp_bp";
> +               regulator-always-on;
> +               regulator-boot-on;
> +       };
>  };
>
>  &apps_rsc {
> @@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
>         };
>  };
>
> +&mdss {
> +       status = "okay";
> +};
> +
> +&mdss_dp {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&dp_hot_plug_det>;
> +       data-lanes = <0 1>;
> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l1b_0p8>;
> +};
> +
> +&mdss_edp {
> +       status = "okay";
> +
> +       data-lanes = <0 1 2 3>;

Is this property necessary? It looks like the default.

> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> +
> +       aux-bus {

Can this move to sc7280.dtsi and get a phandle?

> +               edp_panel: edp-panel {

I'd prefer

	edp_panel: panel {

because there's only one panel node at this level.

> +                       compatible = "edp-panel";
> +
> +                       power-supply = <&edp_3v3_regulator>;

This is board specific, but I thought it was on the qcard so we should
move this to sc7280-qcard.dtsi?

> +                       ports {
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +                               port@0 {
> +                                       reg = <0>;
> +                                       edp_panel_in: endpoint {

This can be shortened to

			port {
				edp_panel_in: endpoint {

according to panel-edp.yaml

> +                                               remote-endpoint = <&mdss_edp_out>;
> +                                       };
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&mdss_edp_out {
> +       remote-endpoint = <&edp_panel_in>;
> +};
> +
> +&mdss_edp_phy {
> +       status = "okay";
> +};
> +
> +&mdss_mdp {
> +       status = "okay";
> +};
> +
>  &nvme_3v3_regulator {
>         gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
>  };
> @@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
>         pins = "gpio51";
>  };
>
> +&pm8350c_gpios {
> +       edp_bl_power: edp-bl-power {

Is this used in a later patch?

> +               pins = "gpio7";
> +               function = "normal";
> +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> +       };
> +
> +       edp_bl_pwm: edp-bl-pwm {

Is this used in a later patch? Can it be moved to the patch that uses
it?

> +               pins = "gpio8";
> +               function = "func1";
> +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> +       };
> +};
> +
>  &tlmm {
> +       edp_panel_power: edp-panel-power {
> +               pins = "gpio80";
> +               function = "gpio";

function of gpio is unnecessary. Where is the bias and drive-strength
settings?

> +       };
> +
>         tp_int_odl: tp-int-odl {
>                 pins = "gpio7";
>                 function = "gpio";
> --
> 2.7.4
>

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:47)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index e2efbdd..2df654e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -7,6 +7,7 @@
>
>  /dts-v1/;
>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>  #include "sc7280-idp.dtsi"
>  #include "sc7280-idp-ec-h1.dtsi"
>
> @@ -21,6 +22,27 @@
>         chosen {
>                 stdout-path = "serial0:115200n8";
>         };
> +
> +       edp_3v3_regulator: edp-3v3-regulator {
> +               compatible = "regulator-fixed";
> +               regulator-name = "edp_3v3_regulator";
> +
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +
> +               gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> +               enable-active-high;
> +
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&edp_panel_power>;
> +       };
> +
> +       vreg_edp_bp: vreg-edp-bp-regulator {
> +               compatible = "regulator-fixed";
> +               regulator-name = "vreg_edp_bp";
> +               regulator-always-on;
> +               regulator-boot-on;
> +       };
>  };
>
>  &apps_rsc {
> @@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
>         };
>  };
>
> +&mdss {
> +       status = "okay";
> +};
> +
> +&mdss_dp {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&dp_hot_plug_det>;
> +       data-lanes = <0 1>;
> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l1b_0p8>;
> +};
> +
> +&mdss_edp {
> +       status = "okay";
> +
> +       data-lanes = <0 1 2 3>;

Is this property necessary? It looks like the default.

> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> +
> +       aux-bus {

Can this move to sc7280.dtsi and get a phandle?

> +               edp_panel: edp-panel {

I'd prefer

	edp_panel: panel {

because there's only one panel node at this level.

> +                       compatible = "edp-panel";
> +
> +                       power-supply = <&edp_3v3_regulator>;

This is board specific, but I thought it was on the qcard so we should
move this to sc7280-qcard.dtsi?

> +                       ports {
> +                               #address-cells = <1>;
> +                               #size-cells = <0>;
> +                               port@0 {
> +                                       reg = <0>;
> +                                       edp_panel_in: endpoint {

This can be shortened to

			port {
				edp_panel_in: endpoint {

according to panel-edp.yaml

> +                                               remote-endpoint = <&mdss_edp_out>;
> +                                       };
> +                               };
> +                       };
> +               };
> +       };
> +};
> +
> +&mdss_edp_out {
> +       remote-endpoint = <&edp_panel_in>;
> +};
> +
> +&mdss_edp_phy {
> +       status = "okay";
> +};
> +
> +&mdss_mdp {
> +       status = "okay";
> +};
> +
>  &nvme_3v3_regulator {
>         gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
>  };
> @@ -84,7 +158,26 @@ ap_ts_pen_1v8: &i2c13 {
>         pins = "gpio51";
>  };
>
> +&pm8350c_gpios {
> +       edp_bl_power: edp-bl-power {

Is this used in a later patch?

> +               pins = "gpio7";
> +               function = "normal";
> +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> +       };
> +
> +       edp_bl_pwm: edp-bl-pwm {

Is this used in a later patch? Can it be moved to the patch that uses
it?

> +               pins = "gpio8";
> +               function = "func1";
> +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> +       };
> +};
> +
>  &tlmm {
> +       edp_panel_power: edp-panel-power {
> +               pins = "gpio80";
> +               function = "gpio";

function of gpio is unnecessary. Where is the bias and drive-strength
settings?

> +       };
> +
>         tp_int_odl: tp-int-odl {
>                 pins = "gpio7";
>                 function = "gpio";
> --
> 2.7.4
>

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 2:53 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> panel on CRD
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:47)
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > index e2efbdd..2df654e 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > @@ -7,6 +7,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> >  #include "sc7280-idp.dtsi"
> >  #include "sc7280-idp-ec-h1.dtsi"
> >
> > @@ -21,6 +22,27 @@
> >         chosen {
> >                 stdout-path = "serial0:115200n8";
> >         };
> > +
> > +       edp_3v3_regulator: edp-3v3-regulator {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "edp_3v3_regulator";
> > +
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> > +
> > +               gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> > +               enable-active-high;
> > +
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&edp_panel_power>;
> > +       };
> > +
> > +       vreg_edp_bp: vreg-edp-bp-regulator {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "vreg_edp_bp";
> > +               regulator-always-on;
> > +               regulator-boot-on;
> > +       };
> >  };
> >
> >  &apps_rsc {
> > @@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
> >         };
> >  };
> >
> > +&mdss {
> > +       status = "okay";
> > +};
> > +
> > +&mdss_dp {
> > +       status = "okay";
> > +
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&dp_hot_plug_det>;
> > +       data-lanes = <0 1>;
> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l1b_0p8>; };
> > +
> > +&mdss_edp {
> > +       status = "okay";
> > +
> > +       data-lanes = <0 1 2 3>;
> 
> Is this property necessary? It looks like the default.
> 

Will remove it

> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > +
> > +       aux-bus {
> 
> Can this move to sc7280.dtsi and get a phandle?
>

Okay, I will move this to sc7280.dtsi like below.
Shall I define the required properties under &mdss_edp_panel node in the sc7280-crd3.dts?

--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3283,6 +3283,18 @@

                                status = "disabled";

+                               aux-bus {
+                                       mdss_edp_panel: panel {
+                                               compatible = "edp-panel";
+
+                                               port {
+                                                       mdss_edp_panel_in: endpoint {
+                                                               remote-endpoint = <&mdss_edp_out>;
+                                                       };
+                                               };
+                                       };
+                               };
+
                                ports {
                                        #address-cells = <1>;
                                        #size-cells = <0>;
@@ -3296,7 +3308,9 @@

                                        port@1 {
                                                reg = <1>;
-                                               mdss_edp_out: endpoint { };
+                                               mdss_edp_out: endpoint {
+                                                       remote-endpoint = <&mdss_edp_panel_in>;
+                                               };
                                        };
                                };
 
> > +               edp_panel: edp-panel {
> 
> I'd prefer
> 
> 	edp_panel: panel {
> 
> because there's only one panel node at this level.
> 

Okay. I will change it.

> > +                       compatible = "edp-panel";
> > +
> > +                       power-supply = <&edp_3v3_regulator>;
> 
> This is board specific, but I thought it was on the qcard so we should move
> this to sc7280-qcard.dtsi?
> 

Qcard is used only for herobrine as of now according to the code. We defined this only for CRD. We will discuss this internally to understand the plan ahead.

> > +                       ports {
> > +                               #address-cells = <1>;
> > +                               #size-cells = <0>;
> > +                               port@0 {
> > +                                       reg = <0>;
> > +                                       edp_panel_in: endpoint {
> 
> This can be shortened to
> 
> 			port {
> 				edp_panel_in: endpoint {
> 
> according to panel-edp.yaml
> 

Okay. I will do it

> > +                                               remote-endpoint = <&mdss_edp_out>;
> > +                                       };
> > +                               };
> > +                       };
> > +               };
> > +       };
> > +};
> > +
> > +&mdss_edp_out {
> > +       remote-endpoint = <&edp_panel_in>; };
> > +
> > +&mdss_edp_phy {
> > +       status = "okay";
> > +};
> > +
> > +&mdss_mdp {
> > +       status = "okay";
> > +};
> > +
> >  &nvme_3v3_regulator {
> >         gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;  }; @@ -84,7 +158,26 @@
> > ap_ts_pen_1v8: &i2c13 {
> >         pins = "gpio51";
> >  };
> >
> > +&pm8350c_gpios {
> > +       edp_bl_power: edp-bl-power {
> 
> Is this used in a later patch?
>

Yes, will move it to that patch.
 
> > +               pins = "gpio7";
> > +               function = "normal";
> > +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> > +       };
> > +
> > +       edp_bl_pwm: edp-bl-pwm {
> 
> Is this used in a later patch? Can it be moved to the patch that uses it?
> 

Yes, will move it to that patch. We split the patch to exclude the dependent pwm nodes so that Bjorn can merge this patch. But we will move all the related nodes to the next patch

> > +               pins = "gpio8";
> > +               function = "func1";
> > +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> > +       };
> > +};
> > +
> >  &tlmm {
> > +       edp_panel_power: edp-panel-power {
> > +               pins = "gpio80";
> > +               function = "gpio";
> 
> function of gpio is unnecessary. Where is the bias and drive-strength
> settings?
> 

Will add it

> > +       };
> > +
> >         tp_int_odl: tp-int-odl {
> >                 pins = "gpio7";
> >                 function = "gpio";
> > --
> > 2.7.4
> >

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 2:53 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> panel on CRD
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:47)
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > index e2efbdd..2df654e 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > @@ -7,6 +7,7 @@
> >
> >  /dts-v1/;
> >
> > +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> >  #include "sc7280-idp.dtsi"
> >  #include "sc7280-idp-ec-h1.dtsi"
> >
> > @@ -21,6 +22,27 @@
> >         chosen {
> >                 stdout-path = "serial0:115200n8";
> >         };
> > +
> > +       edp_3v3_regulator: edp-3v3-regulator {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "edp_3v3_regulator";
> > +
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> > +
> > +               gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
> > +               enable-active-high;
> > +
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&edp_panel_power>;
> > +       };
> > +
> > +       vreg_edp_bp: vreg-edp-bp-regulator {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "vreg_edp_bp";
> > +               regulator-always-on;
> > +               regulator-boot-on;
> > +       };
> >  };
> >
> >  &apps_rsc {
> > @@ -76,6 +98,58 @@ ap_ts_pen_1v8: &i2c13 {
> >         };
> >  };
> >
> > +&mdss {
> > +       status = "okay";
> > +};
> > +
> > +&mdss_dp {
> > +       status = "okay";
> > +
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&dp_hot_plug_det>;
> > +       data-lanes = <0 1>;
> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l1b_0p8>; };
> > +
> > +&mdss_edp {
> > +       status = "okay";
> > +
> > +       data-lanes = <0 1 2 3>;
> 
> Is this property necessary? It looks like the default.
> 

Will remove it

> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > +
> > +       aux-bus {
> 
> Can this move to sc7280.dtsi and get a phandle?
>

Okay, I will move this to sc7280.dtsi like below.
Shall I define the required properties under &mdss_edp_panel node in the sc7280-crd3.dts?

--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3283,6 +3283,18 @@

                                status = "disabled";

+                               aux-bus {
+                                       mdss_edp_panel: panel {
+                                               compatible = "edp-panel";
+
+                                               port {
+                                                       mdss_edp_panel_in: endpoint {
+                                                               remote-endpoint = <&mdss_edp_out>;
+                                                       };
+                                               };
+                                       };
+                               };
+
                                ports {
                                        #address-cells = <1>;
                                        #size-cells = <0>;
@@ -3296,7 +3308,9 @@

                                        port@1 {
                                                reg = <1>;
-                                               mdss_edp_out: endpoint { };
+                                               mdss_edp_out: endpoint {
+                                                       remote-endpoint = <&mdss_edp_panel_in>;
+                                               };
                                        };
                                };
 
> > +               edp_panel: edp-panel {
> 
> I'd prefer
> 
> 	edp_panel: panel {
> 
> because there's only one panel node at this level.
> 

Okay. I will change it.

> > +                       compatible = "edp-panel";
> > +
> > +                       power-supply = <&edp_3v3_regulator>;
> 
> This is board specific, but I thought it was on the qcard so we should move
> this to sc7280-qcard.dtsi?
> 

Qcard is used only for herobrine as of now according to the code. We defined this only for CRD. We will discuss this internally to understand the plan ahead.

> > +                       ports {
> > +                               #address-cells = <1>;
> > +                               #size-cells = <0>;
> > +                               port@0 {
> > +                                       reg = <0>;
> > +                                       edp_panel_in: endpoint {
> 
> This can be shortened to
> 
> 			port {
> 				edp_panel_in: endpoint {
> 
> according to panel-edp.yaml
> 

Okay. I will do it

> > +                                               remote-endpoint = <&mdss_edp_out>;
> > +                                       };
> > +                               };
> > +                       };
> > +               };
> > +       };
> > +};
> > +
> > +&mdss_edp_out {
> > +       remote-endpoint = <&edp_panel_in>; };
> > +
> > +&mdss_edp_phy {
> > +       status = "okay";
> > +};
> > +
> > +&mdss_mdp {
> > +       status = "okay";
> > +};
> > +
> >  &nvme_3v3_regulator {
> >         gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;  }; @@ -84,7 +158,26 @@
> > ap_ts_pen_1v8: &i2c13 {
> >         pins = "gpio51";
> >  };
> >
> > +&pm8350c_gpios {
> > +       edp_bl_power: edp-bl-power {
> 
> Is this used in a later patch?
>

Yes, will move it to that patch.
 
> > +               pins = "gpio7";
> > +               function = "normal";
> > +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> > +       };
> > +
> > +       edp_bl_pwm: edp-bl-pwm {
> 
> Is this used in a later patch? Can it be moved to the patch that uses it?
> 

Yes, will move it to that patch. We split the patch to exclude the dependent pwm nodes so that Bjorn can merge this patch. But we will move all the related nodes to the next patch

> > +               pins = "gpio8";
> > +               function = "func1";
> > +               qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
> > +       };
> > +};
> > +
> >  &tlmm {
> > +       edp_panel_power: edp-panel-power {
> > +               pins = "gpio80";
> > +               function = "gpio";
> 
> function of gpio is unnecessary. Where is the bias and drive-strength
> settings?
> 

Will add it

> > +       };
> > +
> >         tp_int_odl: tp-int-odl {
> >                 pins = "gpio7";
> >                 function = "gpio";
> > --
> > 2.7.4
> >

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Stephen Boyd]

Quoting Sankeerth Billakanti (QUIC) (2022-03-25 06:30:58)
>
>
> > > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > > +
> > > +       aux-bus {
> >
> > Can this move to sc7280.dtsi and get a phandle?
> >
>
> Okay, I will move this to sc7280.dtsi like below.
> Shall I define the required properties under &mdss_edp_panel node in the sc7280-crd3.dts?

The below patch looks good.

>
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3283,6 +3283,18 @@
>
>                                 status = "disabled";

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Stephen Boyd]

Quoting Sankeerth Billakanti (QUIC) (2022-03-25 06:30:58)
>
>
> > > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > > +
> > > +       aux-bus {
> >
> > Can this move to sc7280.dtsi and get a phandle?
> >
>
> Okay, I will move this to sc7280.dtsi like below.
> Shall I define the required properties under &mdss_edp_panel node in the sc7280-crd3.dts?

The below patch looks good.

>
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3283,6 +3283,18 @@
>
>                                 status = "disabled";

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Enable support for eDP interface via aux_bus on CRD platform.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Change the order of patches
>   - Remove the backlight nodes
>   - Remove the bias setting
>   - Fix compilation issue
>   - Model VREG_EDP_BP for backlight power
>
> Changes in v4:
>   - Create new patch for name changes
>   - Remove output-low
>
> Changes in v3:
>   - Sort the nodes alphabetically
>   - Use - instead of _ as node names
>   - Place the backlight and panel nodes under root
>   - Change the name of edp_out to mdss_edp_out
>   - Change the names of regulator nodes
>   - Delete unused properties in the board file
>
>
> Changes in v2:
>   - Sort node references alphabetically
>   - Improve readability
>   - Move the pwm pinctrl to pwm node
>   - Move the regulators to root
>   - Define backlight power
>   - Remove dummy regulator node
>   - Cleanup pinctrl definitions
>
>  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93 +++++++++++++++++++++++++++++++++
>  1 file changed, 93 insertions(+)

At a high level, I'd expect your patch to be based upon Matthias's
series, AKA the 4 patches from:

https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8fee008a8477b7b0e@changeid/

I'll leave it up to you about whether you care to support eDP on the
old CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.

Then, I'd expect your patch to mostly incorporate
<https://crrev.com/c/3379844>, though that patch was written before
aux-bus support so the panel would need to go in a different place.

Stephen already gave some comments and basing on Matthias's patches
will be a pretty big change, so I probably won't comment lots more.


> +&mdss_edp {
> +       status = "okay";
> +
> +       data-lanes = <0 1 2 3>;
> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> +
> +       aux-bus {
> +               edp_panel: edp-panel {

As Stephen pointed out, it should be called "panel".

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Enable support for eDP interface via aux_bus on CRD platform.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Change the order of patches
>   - Remove the backlight nodes
>   - Remove the bias setting
>   - Fix compilation issue
>   - Model VREG_EDP_BP for backlight power
>
> Changes in v4:
>   - Create new patch for name changes
>   - Remove output-low
>
> Changes in v3:
>   - Sort the nodes alphabetically
>   - Use - instead of _ as node names
>   - Place the backlight and panel nodes under root
>   - Change the name of edp_out to mdss_edp_out
>   - Change the names of regulator nodes
>   - Delete unused properties in the board file
>
>
> Changes in v2:
>   - Sort node references alphabetically
>   - Improve readability
>   - Move the pwm pinctrl to pwm node
>   - Move the regulators to root
>   - Define backlight power
>   - Remove dummy regulator node
>   - Cleanup pinctrl definitions
>
>  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93 +++++++++++++++++++++++++++++++++
>  1 file changed, 93 insertions(+)

At a high level, I'd expect your patch to be based upon Matthias's
series, AKA the 4 patches from:

https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8fee008a8477b7b0e@changeid/

I'll leave it up to you about whether you care to support eDP on the
old CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.

Then, I'd expect your patch to mostly incorporate
<https://crrev.com/c/3379844>, though that patch was written before
aux-bus support so the panel would need to go in a different place.

Stephen already gave some comments and basing on Matthias's patches
will be a pretty big change, so I probably won't comment lots more.


> +&mdss_edp {
> +       status = "okay";
> +
> +       data-lanes = <0 1 2 3>;
> +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> +
> +       aux-bus {
> +               edp_panel: edp-panel {

As Stephen pointed out, it should be called "panel".

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Friday, March 18, 2022 10:51 PM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> LKML <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Clark
> <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>; Stephen
> Boyd <swboyd@chromium.org>; quic_kalyant <quic_kalyant@quicinc.com>;
> Abhinav Kumar (QUIC) <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> panel on CRD
> 
> Hi,
> 
> On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
> <quic_sbillaka@quicinc.com> wrote:
> >
> > Enable support for eDP interface via aux_bus on CRD platform.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >
> > Changes in v5:
> >   - Change the order of patches
> >   - Remove the backlight nodes
> >   - Remove the bias setting
> >   - Fix compilation issue
> >   - Model VREG_EDP_BP for backlight power
> >
> > Changes in v4:
> >   - Create new patch for name changes
> >   - Remove output-low
> >
> > Changes in v3:
> >   - Sort the nodes alphabetically
> >   - Use - instead of _ as node names
> >   - Place the backlight and panel nodes under root
> >   - Change the name of edp_out to mdss_edp_out
> >   - Change the names of regulator nodes
> >   - Delete unused properties in the board file
> >
> >
> > Changes in v2:
> >   - Sort node references alphabetically
> >   - Improve readability
> >   - Move the pwm pinctrl to pwm node
> >   - Move the regulators to root
> >   - Define backlight power
> >   - Remove dummy regulator node
> >   - Cleanup pinctrl definitions
> >
> >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93
> > +++++++++++++++++++++++++++++++++
> >  1 file changed, 93 insertions(+)
> 
> At a high level, I'd expect your patch to be based upon Matthias's series, AKA
> the 4 patches from:
> 
> https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8f
> ee008a8477b7b0e@changeid/
> 
> I'll leave it up to you about whether you care to support eDP on the old
> CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.
> 
> Then, I'd expect your patch to mostly incorporate
> <https://crrev.com/c/3379844>, though that patch was written before aux-
> bus support so the panel would need to go in a different place.
> 
> Stephen already gave some comments and basing on Matthias's patches will
> be a pretty big change, so I probably won't comment lots more.
> 
> 

I rebased my change on top of Matthias's changes now. We are discussing about the qcard changes internally to understand the way ahead.
I believe all my current changes are localized to the crd-r3 files only for the qyalcomm crd3.1

I want to have a different series for c and dt changes to expedite review process. May I separate the c changes from this series?

> > +&mdss_edp {
> > +       status = "okay";
> > +
> > +       data-lanes = <0 1 2 3>;
> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > +
> > +       aux-bus {
> > +               edp_panel: edp-panel {
> 
> As Stephen pointed out, it should be called "panel".

Okay. Will make that change

RE: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Friday, March 18, 2022 10:51 PM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> LKML <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Clark
> <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>; Stephen
> Boyd <swboyd@chromium.org>; quic_kalyant <quic_kalyant@quicinc.com>;
> Abhinav Kumar (QUIC) <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> panel on CRD
> 
> Hi,
> 
> On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
> <quic_sbillaka@quicinc.com> wrote:
> >
> > Enable support for eDP interface via aux_bus on CRD platform.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >
> > Changes in v5:
> >   - Change the order of patches
> >   - Remove the backlight nodes
> >   - Remove the bias setting
> >   - Fix compilation issue
> >   - Model VREG_EDP_BP for backlight power
> >
> > Changes in v4:
> >   - Create new patch for name changes
> >   - Remove output-low
> >
> > Changes in v3:
> >   - Sort the nodes alphabetically
> >   - Use - instead of _ as node names
> >   - Place the backlight and panel nodes under root
> >   - Change the name of edp_out to mdss_edp_out
> >   - Change the names of regulator nodes
> >   - Delete unused properties in the board file
> >
> >
> > Changes in v2:
> >   - Sort node references alphabetically
> >   - Improve readability
> >   - Move the pwm pinctrl to pwm node
> >   - Move the regulators to root
> >   - Define backlight power
> >   - Remove dummy regulator node
> >   - Cleanup pinctrl definitions
> >
> >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93
> > +++++++++++++++++++++++++++++++++
> >  1 file changed, 93 insertions(+)
> 
> At a high level, I'd expect your patch to be based upon Matthias's series, AKA
> the 4 patches from:
> 
> https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8f
> ee008a8477b7b0e@changeid/
> 
> I'll leave it up to you about whether you care to support eDP on the old
> CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.
> 
> Then, I'd expect your patch to mostly incorporate
> <https://crrev.com/c/3379844>, though that patch was written before aux-
> bus support so the panel would need to go in a different place.
> 
> Stephen already gave some comments and basing on Matthias's patches will
> be a pretty big change, so I probably won't comment lots more.
> 
> 

I rebased my change on top of Matthias's changes now. We are discussing about the qcard changes internally to understand the way ahead.
I believe all my current changes are localized to the crd-r3 files only for the qyalcomm crd3.1

I want to have a different series for c and dt changes to expedite review process. May I separate the c changes from this series?

> > +&mdss_edp {
> > +       status = "okay";
> > +
> > +       data-lanes = <0 1 2 3>;
> > +       vdda-1p2-supply = <&vreg_l6b_1p2>;
> > +       vdda-0p9-supply = <&vreg_l10c_0p8>;
> > +
> > +       aux-bus {
> > +               edp_panel: edp-panel {
> 
> As Stephen pointed out, it should be called "panel".

Okay. Will make that change

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 6:41 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Doug Anderson <dianders@chromium.org>
> > Sent: Friday, March 18, 2022 10:51 PM
> > To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> > Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> > msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> > LKML <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Clark
> > <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>; Stephen
> > Boyd <swboyd@chromium.org>; quic_kalyant <quic_kalyant@quicinc.com>;
> > Abhinav Kumar (QUIC) <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> > Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> > panel on CRD
> >
> > Hi,
> >
> > On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
> > <quic_sbillaka@quicinc.com> wrote:
> > >
> > > Enable support for eDP interface via aux_bus on CRD platform.
> > >
> > > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > > ---
> > >
> > > Changes in v5:
> > >   - Change the order of patches
> > >   - Remove the backlight nodes
> > >   - Remove the bias setting
> > >   - Fix compilation issue
> > >   - Model VREG_EDP_BP for backlight power
> > >
> > > Changes in v4:
> > >   - Create new patch for name changes
> > >   - Remove output-low
> > >
> > > Changes in v3:
> > >   - Sort the nodes alphabetically
> > >   - Use - instead of _ as node names
> > >   - Place the backlight and panel nodes under root
> > >   - Change the name of edp_out to mdss_edp_out
> > >   - Change the names of regulator nodes
> > >   - Delete unused properties in the board file
> > >
> > >
> > > Changes in v2:
> > >   - Sort node references alphabetically
> > >   - Improve readability
> > >   - Move the pwm pinctrl to pwm node
> > >   - Move the regulators to root
> > >   - Define backlight power
> > >   - Remove dummy regulator node
> > >   - Cleanup pinctrl definitions
> > >
> > >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93
> > > +++++++++++++++++++++++++++++++++
> > >  1 file changed, 93 insertions(+)
> >
> > At a high level, I'd expect your patch to be based upon Matthias's series, AKA
> > the 4 patches from:
> >
> > https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8f
> > ee008a8477b7b0e@changeid/
> >
> > I'll leave it up to you about whether you care to support eDP on the old
> > CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.
> >
> > Then, I'd expect your patch to mostly incorporate
> > <https://crrev.com/c/3379844>, though that patch was written before aux-
> > bus support so the panel would need to go in a different place.
> >
> > Stephen already gave some comments and basing on Matthias's patches will
> > be a pretty big change, so I probably won't comment lots more.
> >
> >
>
> I rebased my change on top of Matthias's changes now. We are discussing about the qcard changes internally to understand the way ahead.
> I believe all my current changes are localized to the crd-r3 files only for the qyalcomm crd3.1
>
> I want to have a different series for c and dt changes to expedite review process. May I separate the c changes from this series?

I'd have no problems with that. They go into different trees and if it
makes it easier to get a new version of the driver out while you're
figuring out what to do about the dts then I'd say let's do it.

-Doug

Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 6:41 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Doug Anderson <dianders@chromium.org>
> > Sent: Friday, March 18, 2022 10:51 PM
> > To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> > Cc: dri-devel <dri-devel@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> > msm@vger.kernel.org>; freedreno <freedreno@lists.freedesktop.org>;
> > LKML <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND
> > FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Rob Clark
> > <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>; Stephen
> > Boyd <swboyd@chromium.org>; quic_kalyant <quic_kalyant@quicinc.com>;
> > Abhinav Kumar (QUIC) <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> > Subject: Re: [PATCH v5 2/9] arm64: dts: qcom: sc7280: Add support for eDP
> > panel on CRD
> >
> > Hi,
> >
> > On Wed, Mar 16, 2022 at 10:36 AM Sankeerth Billakanti
> > <quic_sbillaka@quicinc.com> wrote:
> > >
> > > Enable support for eDP interface via aux_bus on CRD platform.
> > >
> > > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > > ---
> > >
> > > Changes in v5:
> > >   - Change the order of patches
> > >   - Remove the backlight nodes
> > >   - Remove the bias setting
> > >   - Fix compilation issue
> > >   - Model VREG_EDP_BP for backlight power
> > >
> > > Changes in v4:
> > >   - Create new patch for name changes
> > >   - Remove output-low
> > >
> > > Changes in v3:
> > >   - Sort the nodes alphabetically
> > >   - Use - instead of _ as node names
> > >   - Place the backlight and panel nodes under root
> > >   - Change the name of edp_out to mdss_edp_out
> > >   - Change the names of regulator nodes
> > >   - Delete unused properties in the board file
> > >
> > >
> > > Changes in v2:
> > >   - Sort node references alphabetically
> > >   - Improve readability
> > >   - Move the pwm pinctrl to pwm node
> > >   - Move the regulators to root
> > >   - Define backlight power
> > >   - Remove dummy regulator node
> > >   - Cleanup pinctrl definitions
> > >
> > >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 93
> > > +++++++++++++++++++++++++++++++++
> > >  1 file changed, 93 insertions(+)
> >
> > At a high level, I'd expect your patch to be based upon Matthias's series, AKA
> > the 4 patches from:
> >
> > https://lore.kernel.org/r/20220316172814.v1.1.I2deda8f2cd6adfbb525a97d8f
> > ee008a8477b7b0e@changeid/
> >
> > I'll leave it up to you about whether you care to support eDP on the old
> > CRD1/2 or just on CRD3. Personally I'd think CRD3 would be enough.
> >
> > Then, I'd expect your patch to mostly incorporate
> > <https://crrev.com/c/3379844>, though that patch was written before aux-
> > bus support so the panel would need to go in a different place.
> >
> > Stephen already gave some comments and basing on Matthias's patches will
> > be a pretty big change, so I probably won't comment lots more.
> >
> >
>
> I rebased my change on top of Matthias's changes now. We are discussing about the qcard changes internally to understand the way ahead.
> I believe all my current changes are localized to the crd-r3 files only for the qyalcomm crd3.1
>
> I want to have a different series for c and dt changes to expedite review process. May I separate the c changes from this series?

I'd have no problems with that. They go into different trees and if it
makes it easier to get a new version of the driver out while you're
figuring out what to do about the dts then I'd say let's do it.

-Doug

[PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Sankeerth Billakanti]

Enable backlight support for eDP panel on CRD platform for sc7280.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Separate out backlight nodes

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index 2df654e..16d1a5b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -37,6 +37,15 @@
 		pinctrl-0 = <&edp_panel_power>;
 	};
 
+	edp_backlight: edp-backlight {
+		compatible = "pwm-backlight";
+
+		power-supply = <&vreg_edp_bp>;
+		pwms = <&pm8350c_pwm 3 65535>;
+
+		enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
+	};
+
 	vreg_edp_bp: vreg-edp-bp-regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "vreg_edp_bp";
@@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
 		edp_panel: edp-panel {
 			compatible = "edp-panel";
 
+			backlight = <&edp_backlight>;
 			power-supply = <&edp_3v3_regulator>;
+
 			ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
@@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
 	};
 };
 
+&pm8350c_pwm {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&edp_bl_pwm>;
+};
+
 &tlmm {
 	edp_panel_power: edp-panel-power {
 		pins = "gpio80";
-- 
2.7.4

[PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Sankeerth Billakanti]

Enable backlight support for eDP panel on CRD platform for sc7280.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---

Changes in v5:
  - Separate out backlight nodes

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index 2df654e..16d1a5b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -37,6 +37,15 @@
 		pinctrl-0 = <&edp_panel_power>;
 	};
 
+	edp_backlight: edp-backlight {
+		compatible = "pwm-backlight";
+
+		power-supply = <&vreg_edp_bp>;
+		pwms = <&pm8350c_pwm 3 65535>;
+
+		enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
+	};
+
 	vreg_edp_bp: vreg-edp-bp-regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "vreg_edp_bp";
@@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
 		edp_panel: edp-panel {
 			compatible = "edp-panel";
 
+			backlight = <&edp_backlight>;
 			power-supply = <&edp_3v3_regulator>;
+
 			ports {
 				#address-cells = <1>;
 				#size-cells = <0>;
@@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
 	};
 };
 
+&pm8350c_pwm {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&edp_bl_pwm>;
+};
+
 &tlmm {
 	edp_panel_power: edp-panel-power {
 		pins = "gpio80";
-- 
2.7.4

Re: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:48)
> Enable backlight support for eDP panel on CRD platform for sc7280.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Separate out backlight nodes
>
>  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index 2df654e..16d1a5b 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -37,6 +37,15 @@
>                 pinctrl-0 = <&edp_panel_power>;
>         };
>
> +       edp_backlight: edp-backlight {

Does this also move to qcard.dtsi? Why can't this be combined with the
previous patch?

> +               compatible = "pwm-backlight";
> +
> +               power-supply = <&vreg_edp_bp>;
> +               pwms = <&pm8350c_pwm 3 65535>;
> +
> +               enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> +       };
> +
>         vreg_edp_bp: vreg-edp-bp-regulator {
>                 compatible = "regulator-fixed";
>                 regulator-name = "vreg_edp_bp";
> @@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
>                 edp_panel: edp-panel {
>                         compatible = "edp-panel";
>
> +                       backlight = <&edp_backlight>;
>                         power-supply = <&edp_3v3_regulator>;
> +

Nitpick: Remove this newline from this hunk and put it in when
power-supply is introduced.

>                         ports {
>                                 #address-cells = <1>;
>                                 #size-cells = <0>;
> @@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
>         };
>  };
>
> +&pm8350c_pwm {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&edp_bl_pwm>;

I see the pinctrl is used now but it would be easier to review this
patch if the pinctrl was in this patch.

Re: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:48)
> Enable backlight support for eDP panel on CRD platform for sc7280.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>
> Changes in v5:
>   - Separate out backlight nodes
>
>  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index 2df654e..16d1a5b 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -37,6 +37,15 @@
>                 pinctrl-0 = <&edp_panel_power>;
>         };
>
> +       edp_backlight: edp-backlight {

Does this also move to qcard.dtsi? Why can't this be combined with the
previous patch?

> +               compatible = "pwm-backlight";
> +
> +               power-supply = <&vreg_edp_bp>;
> +               pwms = <&pm8350c_pwm 3 65535>;
> +
> +               enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> +       };
> +
>         vreg_edp_bp: vreg-edp-bp-regulator {
>                 compatible = "regulator-fixed";
>                 regulator-name = "vreg_edp_bp";
> @@ -123,7 +132,9 @@ ap_ts_pen_1v8: &i2c13 {
>                 edp_panel: edp-panel {
>                         compatible = "edp-panel";
>
> +                       backlight = <&edp_backlight>;
>                         power-supply = <&edp_3v3_regulator>;
> +

Nitpick: Remove this newline from this hunk and put it in when
power-supply is introduced.

>                         ports {
>                                 #address-cells = <1>;
>                                 #size-cells = <0>;
> @@ -172,6 +183,13 @@ ap_ts_pen_1v8: &i2c13 {
>         };
>  };
>
> +&pm8350c_pwm {
> +       status = "okay";
> +
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&edp_bl_pwm>;

I see the pinctrl is used now but it would be easier to review this
patch if the pinctrl was in this patch.

RE: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 2:58 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for
> eDP panel
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:48)
> > Enable backlight support for eDP panel on CRD platform for sc7280.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >
> > Changes in v5:
> >   - Separate out backlight nodes
> >
> >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > index 2df654e..16d1a5b 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > @@ -37,6 +37,15 @@
> >                 pinctrl-0 = <&edp_panel_power>;
> >         };
> >
> > +       edp_backlight: edp-backlight {
> 
> Does this also move to qcard.dtsi? Why can't this be combined with the
> previous patch?
> 
The nodes related to pwm are dependent on
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*

We moved them to different patch so that the other patch can be merged without depending on above series. I will rearrange to get backlight definitions also here.

> > +               compatible = "pwm-backlight";
> > +
> > +               power-supply = <&vreg_edp_bp>;
> > +               pwms = <&pm8350c_pwm 3 65535>;
> > +
> > +               enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> > +       };
> > +
> >         vreg_edp_bp: vreg-edp-bp-regulator {
> >                 compatible = "regulator-fixed";
> >                 regulator-name = "vreg_edp_bp"; @@ -123,7 +132,9 @@
> > ap_ts_pen_1v8: &i2c13 {
> >                 edp_panel: edp-panel {
> >                         compatible = "edp-panel";
> >
> > +                       backlight = <&edp_backlight>;
> >                         power-supply = <&edp_3v3_regulator>;
> > +
> 
> Nitpick: Remove this newline from this hunk and put it in when power-supply
> is introduced.
> 

Okay, will make that change.

> >                         ports {
> >                                 #address-cells = <1>;
> >                                 #size-cells = <0>; @@ -172,6 +183,13
> > @@ ap_ts_pen_1v8: &i2c13 {
> >         };
> >  };
> >
> > +&pm8350c_pwm {
> > +       status = "okay";
> > +
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&edp_bl_pwm>;
> 
> I see the pinctrl is used now but it would be easier to review this patch if the
> pinctrl was in this patch.

Okay. I will rearrange the hunks from this and the previous patch.

RE: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for eDP panel

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 2:58 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 3/9] arm64: dts: qcom: sc7280: Enable backlight for
> eDP panel
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:48)
> > Enable backlight support for eDP panel on CRD platform for sc7280.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >
> > Changes in v5:
> >   - Separate out backlight nodes
> >
> >  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > index 2df654e..16d1a5b 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> > @@ -37,6 +37,15 @@
> >                 pinctrl-0 = <&edp_panel_power>;
> >         };
> >
> > +       edp_backlight: edp-backlight {
> 
> Does this also move to qcard.dtsi? Why can't this be combined with the
> previous patch?
> 
The nodes related to pwm are dependent on
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*

We moved them to different patch so that the other patch can be merged without depending on above series. I will rearrange to get backlight definitions also here.

> > +               compatible = "pwm-backlight";
> > +
> > +               power-supply = <&vreg_edp_bp>;
> > +               pwms = <&pm8350c_pwm 3 65535>;
> > +
> > +               enable-gpios = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
> > +       };
> > +
> >         vreg_edp_bp: vreg-edp-bp-regulator {
> >                 compatible = "regulator-fixed";
> >                 regulator-name = "vreg_edp_bp"; @@ -123,7 +132,9 @@
> > ap_ts_pen_1v8: &i2c13 {
> >                 edp_panel: edp-panel {
> >                         compatible = "edp-panel";
> >
> > +                       backlight = <&edp_backlight>;
> >                         power-supply = <&edp_3v3_regulator>;
> > +
> 
> Nitpick: Remove this newline from this hunk and put it in when power-supply
> is introduced.
> 

Okay, will make that change.

> >                         ports {
> >                                 #address-cells = <1>;
> >                                 #size-cells = <0>; @@ -172,6 +183,13
> > @@ ap_ts_pen_1v8: &i2c13 {
> >         };
> >  };
> >
> > +&pm8350c_pwm {
> > +       status = "okay";
> > +
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&edp_bl_pwm>;
> 
> I see the pinctrl is used now but it would be easier to review this patch if the
> pinctrl was in this patch.

Okay. I will rearrange the hunks from this and the previous patch.

[PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Sankeerth Billakanti]

Add panel identification entry for the sharp LQ140M1JW46 eDP panel
with power sequencing delay information.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/panel/panel-edp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index f7bfcf6..e15e62f 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1859,6 +1859,7 @@ static const struct edp_panel_entry edp_panels[] = {
 	EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624, &kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
 	EDP_PANEL_ENTRY('K', 'D', 'B', 0x1120, &delay_200_500_e80_d50, "116N29-30NK-C007"),
 
+	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1523, &sharp_lq140m1jw46.delay, "LQ140M1JW46"),
 	EDP_PANEL_ENTRY('S', 'H', 'P', 0x154c, &delay_200_500_p2e100, "LQ116M1JW10"),
 
 	EDP_PANEL_ENTRY('S', 'T', 'A', 0x0100, &delay_100_500_e200, "2081116HHD028001-51D"),
-- 
2.7.4

[PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Sankeerth Billakanti]

Add panel identification entry for the sharp LQ140M1JW46 eDP panel
with power sequencing delay information.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/panel/panel-edp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
index f7bfcf6..e15e62f 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1859,6 +1859,7 @@ static const struct edp_panel_entry edp_panels[] = {
 	EDP_PANEL_ENTRY('K', 'D', 'B', 0x0624, &kingdisplay_kd116n21_30nv_a010.delay, "116N21-30NV-A010"),
 	EDP_PANEL_ENTRY('K', 'D', 'B', 0x1120, &delay_200_500_e80_d50, "116N29-30NK-C007"),
 
+	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1523, &sharp_lq140m1jw46.delay, "LQ140M1JW46"),
 	EDP_PANEL_ENTRY('S', 'H', 'P', 0x154c, &delay_200_500_p2e100, "LQ116M1JW10"),
 
 	EDP_PANEL_ENTRY('S', 'T', 'A', 0x0100, &delay_100_500_e200, "2081116HHD028001-51D"),
-- 
2.7.4

Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:49)
> Add panel identification entry for the sharp LQ140M1JW46 eDP panel
> with power sequencing delay information.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:49)
> Add panel identification entry for the sharp LQ140M1JW46 eDP panel
> with power sequencing delay information.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:37 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Add panel identification entry for the sharp LQ140M1JW46 eDP panel
> with power sequencing delay information.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/panel/panel-edp.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

This is trivial and going through a different tree than everything
else, so I'm just pushing it to drm-misc-next (which is setup to land
things without regard to the merge window) without sitting on it.

You can leave it out of future spins of this series.

9f493fd71d4b drm/panel-edp: add LQ140M1JW46 edp panel entry

Re: [PATCH v5 4/9] drm/panel-edp: add LQ140M1JW46 edp panel entry

[Doug Anderson]

Hi,

On Wed, Mar 16, 2022 at 10:37 AM Sankeerth Billakanti
<quic_sbillaka@quicinc.com> wrote:
>
> Add panel identification entry for the sharp LQ140M1JW46 eDP panel
> with power sequencing delay information.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/panel/panel-edp.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Douglas Anderson <dianders@chromium.org>

This is trivial and going through a different tree than everything
else, so I'm just pushing it to drm-misc-next (which is setup to land
things without regard to the merge window) without sitting on it.

You can leave it out of future spins of this series.

9f493fd71d4b drm/panel-edp: add LQ140M1JW46 edp panel entry

[PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Sankeerth Billakanti]

	This patch adds support for generic eDP sink through aux_bus.
The eDP/DP controller driver should support aux transactions originating
from the panel-edp driver and hence should be initialized and ready.

	The panel bridge supporting the panel should be ready before
the bridge connector is initialized. The generic panel probe needs the
controller resources to be enabled to support aux tractions originating
from it. So, the host_init and phy_init are moved to execute before the
panel probe.

	The host_init has to return early if the core is already
initialized so that the regulator and clock votes for the controller
resources are balanced.

	EV_HPD_INIT_SETUP needs to execute immediately to enable the
interrupts for the aux transactions from panel-edp to get the modes
supported.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_display.c | 65 +++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
 drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
 drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
 4 files changed, 70 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 382b3aa..688bbed 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -10,6 +10,7 @@
 #include <linux/component.h>
 #include <linux/of_irq.h>
 #include <linux/delay.h>
+#include <drm/drm_dp_aux_bus.h>
 
 #include "msm_drv.h"
 #include "msm_kms.h"
@@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct device *master,
 		goto end;
 	}
 
-	dp->dp_display.next_bridge = dp->parser->next_bridge;
-
 	dp->aux->drm_dev = drm;
 	rc = dp_aux_register(dp->aux);
 	if (rc) {
@@ -421,6 +420,11 @@ static void dp_display_host_init(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (dp->core_initialized) {
+		DRM_DEBUG_DP("DP core already initialized\n");
+		return;
+	}
+
 	dp_power_init(dp->power, false);
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
 	dp_aux_init(dp->aux);
@@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (!dp->core_initialized) {
+		DRM_DEBUG_DP("DP core not initialized\n");
+		return;
+	}
+
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
 	dp_aux_deinit(dp->aux);
 	dp_power_deinit(dp->power);
@@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
 
 	dp_hpd_event_setup(dp);
 
-	dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
+	dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
 }
 
 void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
@@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
 	}
 }
 
+static int dp_display_get_next_bridge(struct msm_dp *dp)
+{
+	int rc = 0;
+	struct dp_display_private *dp_priv;
+	struct device_node *aux_bus;
+	struct device *dev;
+
+	dp_priv = container_of(dp, struct dp_display_private, dp_display);
+	dev = &dp_priv->pdev->dev;
+	aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
+
+	if (aux_bus) {
+		dp_display_host_init(dp_priv);
+		dp_catalog_ctrl_hpd_config(dp_priv->catalog);
+		enable_irq(dp_priv->irq);
+		dp_display_host_phy_init(dp_priv);
+
+		devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
+
+		disable_irq(dp_priv->irq);
+	}
+
+	/*
+	 * External bridges are mandatory for eDP interfaces: one has to
+	 * provide at least an eDP panel (which gets wrapped into panel-bridge).
+	 *
+	 * For DisplayPort interfaces external bridges are optional, so
+	 * silently ignore an error if one is not present (-ENODEV).
+	 */
+	rc = dp_parser_find_next_bridge(dp_priv->parser);
+	if (rc == -ENODEV) {
+		if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+			DRM_ERROR("eDP: next bridge is not present\n");
+			return rc;
+		}
+	} else if (rc) {
+		if (rc != -EPROBE_DEFER)
+			DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
+		return rc;
+	}
+
+	dp->next_bridge = dp_priv->parser->next_bridge;
+
+	return 0;
+}
+
 int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
 			struct drm_encoder *encoder)
 {
@@ -1547,6 +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
 
 	dp_display->encoder = encoder;
 
+	ret = dp_display_get_next_bridge(dp_display);
+	if (ret)
+		return ret;
+
 	dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
 	if (IS_ERR(dp_display->bridge)) {
 		ret = PTR_ERR(dp_display->bridge);
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 7ce1aca..5254bd6 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *
 	bridge->funcs = &dp_bridge_ops;
 	bridge->type = dp_display->connector_type;
 
-	bridge->ops =
-		DRM_BRIDGE_OP_DETECT |
-		DRM_BRIDGE_OP_HPD |
-		DRM_BRIDGE_OP_MODES;
+	if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
+		bridge->ops =
+			DRM_BRIDGE_OP_DETECT |
+			DRM_BRIDGE_OP_HPD |
+			DRM_BRIDGE_OP_MODES;
+	}
 
 	rc = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
 	if (rc) {
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index 1056b8d..6317dce 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -265,7 +265,7 @@ static int dp_parser_clock(struct dp_parser *parser)
 	return 0;
 }
 
-static int dp_parser_find_next_bridge(struct dp_parser *parser)
+int dp_parser_find_next_bridge(struct dp_parser *parser)
 {
 	struct device *dev = &parser->pdev->dev;
 	struct drm_bridge *bridge;
@@ -300,25 +300,6 @@ static int dp_parser_parse(struct dp_parser *parser, int connector_type)
 	if (rc)
 		return rc;
 
-	/*
-	 * External bridges are mandatory for eDP interfaces: one has to
-	 * provide at least an eDP panel (which gets wrapped into panel-bridge).
-	 *
-	 * For DisplayPort interfaces external bridges are optional, so
-	 * silently ignore an error if one is not present (-ENODEV).
-	 */
-	rc = dp_parser_find_next_bridge(parser);
-	if (rc == -ENODEV) {
-		if (connector_type == DRM_MODE_CONNECTOR_eDP) {
-			DRM_ERROR("eDP: next bridge is not present\n");
-			return rc;
-		}
-	} else if (rc) {
-		if (rc != -EPROBE_DEFER)
-			DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
-		return rc;
-	}
-
 	/* Map the corresponding regulator information according to
 	 * version. Currently, since we only have one supported platform,
 	 * mapping the regulator directly.
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index d371bae..091ff41 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -140,5 +140,6 @@ struct dp_parser {
  * can be parsed using this module.
  */
 struct dp_parser *dp_parser_get(struct platform_device *pdev);
+int dp_parser_find_next_bridge(struct dp_parser *parser);
 
 #endif
-- 
2.7.4

[PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Sankeerth Billakanti]

	This patch adds support for generic eDP sink through aux_bus.
The eDP/DP controller driver should support aux transactions originating
from the panel-edp driver and hence should be initialized and ready.

	The panel bridge supporting the panel should be ready before
the bridge connector is initialized. The generic panel probe needs the
controller resources to be enabled to support aux tractions originating
from it. So, the host_init and phy_init are moved to execute before the
panel probe.

	The host_init has to return early if the core is already
initialized so that the regulator and clock votes for the controller
resources are balanced.

	EV_HPD_INIT_SETUP needs to execute immediately to enable the
interrupts for the aux transactions from panel-edp to get the modes
supported.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_display.c | 65 +++++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
 drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
 drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
 4 files changed, 70 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 382b3aa..688bbed 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -10,6 +10,7 @@
 #include <linux/component.h>
 #include <linux/of_irq.h>
 #include <linux/delay.h>
+#include <drm/drm_dp_aux_bus.h>
 
 #include "msm_drv.h"
 #include "msm_kms.h"
@@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct device *master,
 		goto end;
 	}
 
-	dp->dp_display.next_bridge = dp->parser->next_bridge;
-
 	dp->aux->drm_dev = drm;
 	rc = dp_aux_register(dp->aux);
 	if (rc) {
@@ -421,6 +420,11 @@ static void dp_display_host_init(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (dp->core_initialized) {
+		DRM_DEBUG_DP("DP core already initialized\n");
+		return;
+	}
+
 	dp_power_init(dp->power, false);
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
 	dp_aux_init(dp->aux);
@@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct dp_display_private *dp)
 		dp->dp_display.connector_type, dp->core_initialized,
 		dp->phy_initialized);
 
+	if (!dp->core_initialized) {
+		DRM_DEBUG_DP("DP core not initialized\n");
+		return;
+	}
+
 	dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
 	dp_aux_deinit(dp->aux);
 	dp_power_deinit(dp->power);
@@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
 
 	dp_hpd_event_setup(dp);
 
-	dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
+	dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
 }
 
 void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
@@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
 	}
 }
 
+static int dp_display_get_next_bridge(struct msm_dp *dp)
+{
+	int rc = 0;
+	struct dp_display_private *dp_priv;
+	struct device_node *aux_bus;
+	struct device *dev;
+
+	dp_priv = container_of(dp, struct dp_display_private, dp_display);
+	dev = &dp_priv->pdev->dev;
+	aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
+
+	if (aux_bus) {
+		dp_display_host_init(dp_priv);
+		dp_catalog_ctrl_hpd_config(dp_priv->catalog);
+		enable_irq(dp_priv->irq);
+		dp_display_host_phy_init(dp_priv);
+
+		devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
+
+		disable_irq(dp_priv->irq);
+	}
+
+	/*
+	 * External bridges are mandatory for eDP interfaces: one has to
+	 * provide at least an eDP panel (which gets wrapped into panel-bridge).
+	 *
+	 * For DisplayPort interfaces external bridges are optional, so
+	 * silently ignore an error if one is not present (-ENODEV).
+	 */
+	rc = dp_parser_find_next_bridge(dp_priv->parser);
+	if (rc == -ENODEV) {
+		if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+			DRM_ERROR("eDP: next bridge is not present\n");
+			return rc;
+		}
+	} else if (rc) {
+		if (rc != -EPROBE_DEFER)
+			DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
+		return rc;
+	}
+
+	dp->next_bridge = dp_priv->parser->next_bridge;
+
+	return 0;
+}
+
 int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
 			struct drm_encoder *encoder)
 {
@@ -1547,6 +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
 
 	dp_display->encoder = encoder;
 
+	ret = dp_display_get_next_bridge(dp_display);
+	if (ret)
+		return ret;
+
 	dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
 	if (IS_ERR(dp_display->bridge)) {
 		ret = PTR_ERR(dp_display->bridge);
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 7ce1aca..5254bd6 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *
 	bridge->funcs = &dp_bridge_ops;
 	bridge->type = dp_display->connector_type;
 
-	bridge->ops =
-		DRM_BRIDGE_OP_DETECT |
-		DRM_BRIDGE_OP_HPD |
-		DRM_BRIDGE_OP_MODES;
+	if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
+		bridge->ops =
+			DRM_BRIDGE_OP_DETECT |
+			DRM_BRIDGE_OP_HPD |
+			DRM_BRIDGE_OP_MODES;
+	}
 
 	rc = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
 	if (rc) {
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index 1056b8d..6317dce 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -265,7 +265,7 @@ static int dp_parser_clock(struct dp_parser *parser)
 	return 0;
 }
 
-static int dp_parser_find_next_bridge(struct dp_parser *parser)
+int dp_parser_find_next_bridge(struct dp_parser *parser)
 {
 	struct device *dev = &parser->pdev->dev;
 	struct drm_bridge *bridge;
@@ -300,25 +300,6 @@ static int dp_parser_parse(struct dp_parser *parser, int connector_type)
 	if (rc)
 		return rc;
 
-	/*
-	 * External bridges are mandatory for eDP interfaces: one has to
-	 * provide at least an eDP panel (which gets wrapped into panel-bridge).
-	 *
-	 * For DisplayPort interfaces external bridges are optional, so
-	 * silently ignore an error if one is not present (-ENODEV).
-	 */
-	rc = dp_parser_find_next_bridge(parser);
-	if (rc == -ENODEV) {
-		if (connector_type == DRM_MODE_CONNECTOR_eDP) {
-			DRM_ERROR("eDP: next bridge is not present\n");
-			return rc;
-		}
-	} else if (rc) {
-		if (rc != -EPROBE_DEFER)
-			DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
-		return rc;
-	}
-
 	/* Map the corresponding regulator information according to
 	 * version. Currently, since we only have one supported platform,
 	 * mapping the regulator directly.
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index d371bae..091ff41 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -140,5 +140,6 @@ struct dp_parser {
  * can be parsed using this module.
  */
 struct dp_parser *dp_parser_get(struct platform_device *pdev);
+int dp_parser_find_next_bridge(struct dp_parser *parser);
 
 #endif
-- 
2.7.4

Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:50)
>         This patch adds support for generic eDP sink through aux_bus.

Please unindent commit text paragraphs. This isn't a book.

> The eDP/DP controller driver should support aux transactions originating
> from the panel-edp driver and hence should be initialized and ready.
>
>         The panel bridge supporting the panel should be ready before
> the bridge connector is initialized. The generic panel probe needs the
> controller resources to be enabled to support aux tractions originating

s/tractions/transactions/

> from it. So, the host_init and phy_init are moved to execute before the
> panel probe.
>
>         The host_init has to return early if the core is already
> initialized so that the regulator and clock votes for the controller
> resources are balanced.
>
>         EV_HPD_INIT_SETUP needs to execute immediately to enable the
> interrupts for the aux transactions from panel-edp to get the modes
> supported.

There are a lot of things going on in this patch. Can it be split up?

>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 65 +++++++++++++++++++++++++++++++++++--
>  drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
>  drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
>  drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
>  4 files changed, 70 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 382b3aa..688bbed 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -10,6 +10,7 @@
>  #include <linux/component.h>
>  #include <linux/of_irq.h>
>  #include <linux/delay.h>
> +#include <drm/drm_dp_aux_bus.h>
>
>  #include "msm_drv.h"
>  #include "msm_kms.h"
> @@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct device *master,
>                 goto end;
>         }
>
> -       dp->dp_display.next_bridge = dp->parser->next_bridge;
> -
>         dp->aux->drm_dev = drm;
>         rc = dp_aux_register(dp->aux);
>         if (rc) {
> @@ -421,6 +420,11 @@ static void dp_display_host_init(struct dp_display_private *dp)
>                 dp->dp_display.connector_type, dp->core_initialized,
>                 dp->phy_initialized);
>
> +       if (dp->core_initialized) {
> +               DRM_DEBUG_DP("DP core already initialized\n");
> +               return;
> +       }
> +
>         dp_power_init(dp->power, false);
>         dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
>         dp_aux_init(dp->aux);
> @@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct dp_display_private *dp)
>                 dp->dp_display.connector_type, dp->core_initialized,
>                 dp->phy_initialized);
>
> +       if (!dp->core_initialized) {
> +               DRM_DEBUG_DP("DP core not initialized\n");
> +               return;
> +       }
> +
>         dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
>         dp_aux_deinit(dp->aux);
>         dp_power_deinit(dp->power);
> @@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
>
>         dp_hpd_event_setup(dp);
>
> -       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
> +       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
>  }
>
>  void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
> @@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
>         }
>  }
>
> +static int dp_display_get_next_bridge(struct msm_dp *dp)
> +{
> +       int rc = 0;

Drop initialization.

> +       struct dp_display_private *dp_priv;
> +       struct device_node *aux_bus;
> +       struct device *dev;
> +
> +       dp_priv = container_of(dp, struct dp_display_private, dp_display);
> +       dev = &dp_priv->pdev->dev;
> +       aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
> +
> +       if (aux_bus) {
> +               dp_display_host_init(dp_priv);
> +               dp_catalog_ctrl_hpd_config(dp_priv->catalog);
> +               enable_irq(dp_priv->irq);
> +               dp_display_host_phy_init(dp_priv);
> +
> +               devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
> +
> +               disable_irq(dp_priv->irq);

Why do we disable irq?

> +       }

The aux_bus node leaked.

> +
> +       /*
> +        * External bridges are mandatory for eDP interfaces: one has to
> +        * provide at least an eDP panel (which gets wrapped into panel-bridge).
> +        *
> +        * For DisplayPort interfaces external bridges are optional, so
> +        * silently ignore an error if one is not present (-ENODEV).
> +        */
> +       rc = dp_parser_find_next_bridge(dp_priv->parser);
> +       if (rc == -ENODEV) {
> +               if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
> +                       DRM_ERROR("eDP: next bridge is not present\n");
> +                       return rc;
> +               }
> +       } else if (rc) {
> +               if (rc != -EPROBE_DEFER)
> +                       DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
> +               return rc;
> +       }
> +
> +       dp->next_bridge = dp_priv->parser->next_bridge;
> +
> +       return 0;
> +}
> +
>  int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
>                         struct drm_encoder *encoder)
>  {
> @@ -1547,6 +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
>
>         dp_display->encoder = encoder;
>
> +       ret = dp_display_get_next_bridge(dp_display);

Didn't we just move bridge attachment out of modeset? Why is it being
done here?

> +       if (ret)
> +               return ret;
> +
>         dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
>         if (IS_ERR(dp_display->bridge)) {
>                 ret = PTR_ERR(dp_display->bridge);
> diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
> index 7ce1aca..5254bd6 100644
> --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *
>         bridge->funcs = &dp_bridge_ops;
>         bridge->type = dp_display->connector_type;
>
> -       bridge->ops =
> -               DRM_BRIDGE_OP_DETECT |
> -               DRM_BRIDGE_OP_HPD |
> -               DRM_BRIDGE_OP_MODES;
> +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {

Why can't eDP have bridge ops that are the same?

> +               bridge->ops =
> +                       DRM_BRIDGE_OP_DETECT |
> +                       DRM_BRIDGE_OP_HPD |
> +                       DRM_BRIDGE_OP_MODES;
> +       }
>
>         rc = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>         if (rc) {

Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:50)
>         This patch adds support for generic eDP sink through aux_bus.

Please unindent commit text paragraphs. This isn't a book.

> The eDP/DP controller driver should support aux transactions originating
> from the panel-edp driver and hence should be initialized and ready.
>
>         The panel bridge supporting the panel should be ready before
> the bridge connector is initialized. The generic panel probe needs the
> controller resources to be enabled to support aux tractions originating

s/tractions/transactions/

> from it. So, the host_init and phy_init are moved to execute before the
> panel probe.
>
>         The host_init has to return early if the core is already
> initialized so that the regulator and clock votes for the controller
> resources are balanced.
>
>         EV_HPD_INIT_SETUP needs to execute immediately to enable the
> interrupts for the aux transactions from panel-edp to get the modes
> supported.

There are a lot of things going on in this patch. Can it be split up?

>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 65 +++++++++++++++++++++++++++++++++++--
>  drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
>  drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
>  drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
>  4 files changed, 70 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 382b3aa..688bbed 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -10,6 +10,7 @@
>  #include <linux/component.h>
>  #include <linux/of_irq.h>
>  #include <linux/delay.h>
> +#include <drm/drm_dp_aux_bus.h>
>
>  #include "msm_drv.h"
>  #include "msm_kms.h"
> @@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct device *master,
>                 goto end;
>         }
>
> -       dp->dp_display.next_bridge = dp->parser->next_bridge;
> -
>         dp->aux->drm_dev = drm;
>         rc = dp_aux_register(dp->aux);
>         if (rc) {
> @@ -421,6 +420,11 @@ static void dp_display_host_init(struct dp_display_private *dp)
>                 dp->dp_display.connector_type, dp->core_initialized,
>                 dp->phy_initialized);
>
> +       if (dp->core_initialized) {
> +               DRM_DEBUG_DP("DP core already initialized\n");
> +               return;
> +       }
> +
>         dp_power_init(dp->power, false);
>         dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
>         dp_aux_init(dp->aux);
> @@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct dp_display_private *dp)
>                 dp->dp_display.connector_type, dp->core_initialized,
>                 dp->phy_initialized);
>
> +       if (!dp->core_initialized) {
> +               DRM_DEBUG_DP("DP core not initialized\n");
> +               return;
> +       }
> +
>         dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
>         dp_aux_deinit(dp->aux);
>         dp_power_deinit(dp->power);
> @@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display)
>
>         dp_hpd_event_setup(dp);
>
> -       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
> +       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
>  }
>
>  void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
> @@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor *minor)
>         }
>  }
>
> +static int dp_display_get_next_bridge(struct msm_dp *dp)
> +{
> +       int rc = 0;

Drop initialization.

> +       struct dp_display_private *dp_priv;
> +       struct device_node *aux_bus;
> +       struct device *dev;
> +
> +       dp_priv = container_of(dp, struct dp_display_private, dp_display);
> +       dev = &dp_priv->pdev->dev;
> +       aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
> +
> +       if (aux_bus) {
> +               dp_display_host_init(dp_priv);
> +               dp_catalog_ctrl_hpd_config(dp_priv->catalog);
> +               enable_irq(dp_priv->irq);
> +               dp_display_host_phy_init(dp_priv);
> +
> +               devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
> +
> +               disable_irq(dp_priv->irq);

Why do we disable irq?

> +       }

The aux_bus node leaked.

> +
> +       /*
> +        * External bridges are mandatory for eDP interfaces: one has to
> +        * provide at least an eDP panel (which gets wrapped into panel-bridge).
> +        *
> +        * For DisplayPort interfaces external bridges are optional, so
> +        * silently ignore an error if one is not present (-ENODEV).
> +        */
> +       rc = dp_parser_find_next_bridge(dp_priv->parser);
> +       if (rc == -ENODEV) {
> +               if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
> +                       DRM_ERROR("eDP: next bridge is not present\n");
> +                       return rc;
> +               }
> +       } else if (rc) {
> +               if (rc != -EPROBE_DEFER)
> +                       DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
> +               return rc;
> +       }
> +
> +       dp->next_bridge = dp_priv->parser->next_bridge;
> +
> +       return 0;
> +}
> +
>  int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
>                         struct drm_encoder *encoder)
>  {
> @@ -1547,6 +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
>
>         dp_display->encoder = encoder;
>
> +       ret = dp_display_get_next_bridge(dp_display);

Didn't we just move bridge attachment out of modeset? Why is it being
done here?

> +       if (ret)
> +               return ret;
> +
>         dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
>         if (IS_ERR(dp_display->bridge)) {
>                 ret = PTR_ERR(dp_display->bridge);
> diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
> index 7ce1aca..5254bd6 100644
> --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct msm_dp *dp_display, struct drm_device *
>         bridge->funcs = &dp_bridge_ops;
>         bridge->type = dp_display->connector_type;
>
> -       bridge->ops =
> -               DRM_BRIDGE_OP_DETECT |
> -               DRM_BRIDGE_OP_HPD |
> -               DRM_BRIDGE_OP_MODES;
> +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {

Why can't eDP have bridge ops that are the same?

> +               bridge->ops =
> +                       DRM_BRIDGE_OP_DETECT |
> +                       DRM_BRIDGE_OP_HPD |
> +                       DRM_BRIDGE_OP_MODES;
> +       }
>
>         rc = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>         if (rc) {

RE: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 3:08 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:50)
> >         This patch adds support for generic eDP sink through aux_bus.
> 
> Please unindent commit text paragraphs. This isn't a book.
> 

Okay. Will change it.

> > The eDP/DP controller driver should support aux transactions
> > originating from the panel-edp driver and hence should be initialized and
> ready.
> >
> >         The panel bridge supporting the panel should be ready before
> > the bridge connector is initialized. The generic panel probe needs the
> > controller resources to be enabled to support aux tractions
> > originating
> 
> s/tractions/transactions/
>

Will correct it
 
> > from it. So, the host_init and phy_init are moved to execute before
> > the panel probe.
> >
> >         The host_init has to return early if the core is already
> > initialized so that the regulator and clock votes for the controller
> > resources are balanced.
> >
> >         EV_HPD_INIT_SETUP needs to execute immediately to enable the
> > interrupts for the aux transactions from panel-edp to get the modes
> > supported.
> 
> There are a lot of things going on in this patch. Can it be split up?
>

I can split them up.

> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/dp/dp_display.c | 65
> +++++++++++++++++++++++++++++++++++--
> >  drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
> >  drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
> > drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
> >  4 files changed, 70 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> > b/drivers/gpu/drm/msm/dp/dp_display.c
> > index 382b3aa..688bbed 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > @@ -10,6 +10,7 @@
> >  #include <linux/component.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/delay.h>
> > +#include <drm/drm_dp_aux_bus.h>
> >
> >  #include "msm_drv.h"
> >  #include "msm_kms.h"
> > @@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct
> device *master,
> >                 goto end;
> >         }
> >
> > -       dp->dp_display.next_bridge = dp->parser->next_bridge;
> > -
> >         dp->aux->drm_dev = drm;
> >         rc = dp_aux_register(dp->aux);
> >         if (rc) {
> > @@ -421,6 +420,11 @@ static void dp_display_host_init(struct
> dp_display_private *dp)
> >                 dp->dp_display.connector_type, dp->core_initialized,
> >                 dp->phy_initialized);
> >
> > +       if (dp->core_initialized) {
> > +               DRM_DEBUG_DP("DP core already initialized\n");
> > +               return;
> > +       }
> > +
> >         dp_power_init(dp->power, false);
> >         dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> >         dp_aux_init(dp->aux);
> > @@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct
> dp_display_private *dp)
> >                 dp->dp_display.connector_type, dp->core_initialized,
> >                 dp->phy_initialized);
> >
> > +       if (!dp->core_initialized) {
> > +               DRM_DEBUG_DP("DP core not initialized\n");
> > +               return;
> > +       }
> > +
> >         dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
> >         dp_aux_deinit(dp->aux);
> >         dp_power_deinit(dp->power);
> > @@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp
> > *dp_display)
> >
> >         dp_hpd_event_setup(dp);
> >
> > -       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
> > +       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
> >  }
> >
> >  void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor
> > *minor) @@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct
> msm_dp *dp_display, struct drm_minor *minor)
> >         }
> >  }
> >
> > +static int dp_display_get_next_bridge(struct msm_dp *dp) {
> > +       int rc = 0;
> 
> Drop initialization.
> 

Okay.

> > +       struct dp_display_private *dp_priv;
> > +       struct device_node *aux_bus;
> > +       struct device *dev;
> > +
> > +       dp_priv = container_of(dp, struct dp_display_private, dp_display);
> > +       dev = &dp_priv->pdev->dev;
> > +       aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
> > +
> > +       if (aux_bus) {
> > +               dp_display_host_init(dp_priv);
> > +               dp_catalog_ctrl_hpd_config(dp_priv->catalog);
> > +               enable_irq(dp_priv->irq);
> > +               dp_display_host_phy_init(dp_priv);
> > +
> > +               devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
> > +
> > +               disable_irq(dp_priv->irq);
> 
> Why do we disable irq?
> 

To support panel without aux_bus.

If aux_bus is not present and eDP panel is enumerated as a single mode simple sharp panel (panel-edp.c),
the clocks and aux resources required for the panel will be enabled in dp_display_config_hpd and irq will also
be enabled from there like external DP display. So, the dp_display_config_hpd is to be executed for both eDP and DP.

We disabled it here to balance it with the enable_irq in dp_display_config_hpd, which executes for both edp and dp.
 
> > +       }
> 
> The aux_bus node leaked.
>

Will add a of_node_put.
 
> > +
> > +       /*
> > +        * External bridges are mandatory for eDP interfaces: one has to
> > +        * provide at least an eDP panel (which gets wrapped into panel-
> bridge).
> > +        *
> > +        * For DisplayPort interfaces external bridges are optional, so
> > +        * silently ignore an error if one is not present (-ENODEV).
> > +        */
> > +       rc = dp_parser_find_next_bridge(dp_priv->parser);
> > +       if (rc == -ENODEV) {
> > +               if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > +                       DRM_ERROR("eDP: next bridge is not present\n");
> > +                       return rc;
> > +               }
> > +       } else if (rc) {
> > +               if (rc != -EPROBE_DEFER)
> > +                       DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
> > +               return rc;
> > +       }
> > +
> > +       dp->next_bridge = dp_priv->parser->next_bridge;
> > +
> > +       return 0;
> > +}
> > +
> >  int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device
> *dev,
> >                         struct drm_encoder *encoder)  { @@ -1547,6
> > +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
> struct
> > drm_device *dev,
> >
> >         dp_display->encoder = encoder;
> >
> > +       ret = dp_display_get_next_bridge(dp_display);
> 
> Didn't we just move bridge attachment out of modeset? Why is it being done
> here?
> 

After Dmitry's patches, there is a need to get all the required bridges before the bridge_connector_init.
The bridge_connector_init will instantiate the ops for the farthest bridge. If we do not get the next_bridge here,
then the get_modes for eDP will be using the dp_bridge function instead of the panel bridge function.

> > +       if (ret)
> > +               return ret;
> > +
> >         dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
> >         if (IS_ERR(dp_display->bridge)) {
> >                 ret = PTR_ERR(dp_display->bridge); diff --git
> > a/drivers/gpu/drm/msm/dp/dp_drm.c
> b/drivers/gpu/drm/msm/dp/dp_drm.c
> > index 7ce1aca..5254bd6 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct
> msm_dp *dp_display, struct drm_device *
> >         bridge->funcs = &dp_bridge_ops;
> >         bridge->type = dp_display->connector_type;
> >
> > -       bridge->ops =
> > -               DRM_BRIDGE_OP_DETECT |
> > -               DRM_BRIDGE_OP_HPD |
> > -               DRM_BRIDGE_OP_MODES;
> > +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
> 
> Why can't eDP have bridge ops that are the same?
> 

eDP needs to be reported as always connected. Whichever bridge is setting these ops flags should provide the ops.
The farthest bridge from the encoder with the ops flag set should implement the ops.
drm_bridge_connector_detect  reports always connected for eDP. So, we don't need DRM_BRIDGE_OP_DETECT 
eDP panel bridge will add DRM_BRIDGE_OP_MODES in drm_panel_bridge_add_typed and will call panel_edp_get_modes.
As we are not supporting HPD for EDP, we are not setting the HPD ops flag.

> > +               bridge->ops =
> > +                       DRM_BRIDGE_OP_DETECT |
> > +                       DRM_BRIDGE_OP_HPD |
> > +                       DRM_BRIDGE_OP_MODES;
> > +       }
> >
> >         rc = drm_bridge_attach(encoder, bridge, NULL,
> DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >         if (rc) {

RE: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Stephen Boyd <swboyd@chromium.org>
> Sent: Friday, March 18, 2022 3:08 AM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>;
> devicetree@vger.kernel.org; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-msm@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: robdclark@gmail.com; seanpaul@chromium.org; quic_kalyant
> <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; dianders@chromium.org; Kuogee Hsieh
> (QUIC) <quic_khsieh@quicinc.com>; agross@kernel.org;
> bjorn.andersson@linaro.org; robh+dt@kernel.org; krzk+dt@kernel.org;
> sean@poorly.run; airlied@linux.ie; daniel@ffwll.ch;
> thierry.reding@gmail.com; sam@ravnborg.org;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus
> 
> Quoting Sankeerth Billakanti (2022-03-16 10:35:50)
> >         This patch adds support for generic eDP sink through aux_bus.
> 
> Please unindent commit text paragraphs. This isn't a book.
> 

Okay. Will change it.

> > The eDP/DP controller driver should support aux transactions
> > originating from the panel-edp driver and hence should be initialized and
> ready.
> >
> >         The panel bridge supporting the panel should be ready before
> > the bridge connector is initialized. The generic panel probe needs the
> > controller resources to be enabled to support aux tractions
> > originating
> 
> s/tractions/transactions/
>

Will correct it
 
> > from it. So, the host_init and phy_init are moved to execute before
> > the panel probe.
> >
> >         The host_init has to return early if the core is already
> > initialized so that the regulator and clock votes for the controller
> > resources are balanced.
> >
> >         EV_HPD_INIT_SETUP needs to execute immediately to enable the
> > interrupts for the aux transactions from panel-edp to get the modes
> > supported.
> 
> There are a lot of things going on in this patch. Can it be split up?
>

I can split them up.

> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/dp/dp_display.c | 65
> +++++++++++++++++++++++++++++++++++--
> >  drivers/gpu/drm/msm/dp/dp_drm.c     | 10 +++---
> >  drivers/gpu/drm/msm/dp/dp_parser.c  | 21 +-----------
> > drivers/gpu/drm/msm/dp/dp_parser.h  |  1 +
> >  4 files changed, 70 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> > b/drivers/gpu/drm/msm/dp/dp_display.c
> > index 382b3aa..688bbed 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > @@ -10,6 +10,7 @@
> >  #include <linux/component.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/delay.h>
> > +#include <drm/drm_dp_aux_bus.h>
> >
> >  #include "msm_drv.h"
> >  #include "msm_kms.h"
> > @@ -265,8 +266,6 @@ static int dp_display_bind(struct device *dev, struct
> device *master,
> >                 goto end;
> >         }
> >
> > -       dp->dp_display.next_bridge = dp->parser->next_bridge;
> > -
> >         dp->aux->drm_dev = drm;
> >         rc = dp_aux_register(dp->aux);
> >         if (rc) {
> > @@ -421,6 +420,11 @@ static void dp_display_host_init(struct
> dp_display_private *dp)
> >                 dp->dp_display.connector_type, dp->core_initialized,
> >                 dp->phy_initialized);
> >
> > +       if (dp->core_initialized) {
> > +               DRM_DEBUG_DP("DP core already initialized\n");
> > +               return;
> > +       }
> > +
> >         dp_power_init(dp->power, false);
> >         dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> >         dp_aux_init(dp->aux);
> > @@ -433,6 +437,11 @@ static void dp_display_host_deinit(struct
> dp_display_private *dp)
> >                 dp->dp_display.connector_type, dp->core_initialized,
> >                 dp->phy_initialized);
> >
> > +       if (!dp->core_initialized) {
> > +               DRM_DEBUG_DP("DP core not initialized\n");
> > +               return;
> > +       }
> > +
> >         dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
> >         dp_aux_deinit(dp->aux);
> >         dp_power_deinit(dp->power);
> > @@ -1502,7 +1511,7 @@ void msm_dp_irq_postinstall(struct msm_dp
> > *dp_display)
> >
> >         dp_hpd_event_setup(dp);
> >
> > -       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100);
> > +       dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0);
> >  }
> >
> >  void msm_dp_debugfs_init(struct msm_dp *dp_display, struct drm_minor
> > *minor) @@ -1524,6 +1533,52 @@ void msm_dp_debugfs_init(struct
> msm_dp *dp_display, struct drm_minor *minor)
> >         }
> >  }
> >
> > +static int dp_display_get_next_bridge(struct msm_dp *dp) {
> > +       int rc = 0;
> 
> Drop initialization.
> 

Okay.

> > +       struct dp_display_private *dp_priv;
> > +       struct device_node *aux_bus;
> > +       struct device *dev;
> > +
> > +       dp_priv = container_of(dp, struct dp_display_private, dp_display);
> > +       dev = &dp_priv->pdev->dev;
> > +       aux_bus = of_get_child_by_name(dev->of_node, "aux-bus");
> > +
> > +       if (aux_bus) {
> > +               dp_display_host_init(dp_priv);
> > +               dp_catalog_ctrl_hpd_config(dp_priv->catalog);
> > +               enable_irq(dp_priv->irq);
> > +               dp_display_host_phy_init(dp_priv);
> > +
> > +               devm_of_dp_aux_populate_ep_devices(dp_priv->aux);
> > +
> > +               disable_irq(dp_priv->irq);
> 
> Why do we disable irq?
> 

To support panel without aux_bus.

If aux_bus is not present and eDP panel is enumerated as a single mode simple sharp panel (panel-edp.c),
the clocks and aux resources required for the panel will be enabled in dp_display_config_hpd and irq will also
be enabled from there like external DP display. So, the dp_display_config_hpd is to be executed for both eDP and DP.

We disabled it here to balance it with the enable_irq in dp_display_config_hpd, which executes for both edp and dp.
 
> > +       }
> 
> The aux_bus node leaked.
>

Will add a of_node_put.
 
> > +
> > +       /*
> > +        * External bridges are mandatory for eDP interfaces: one has to
> > +        * provide at least an eDP panel (which gets wrapped into panel-
> bridge).
> > +        *
> > +        * For DisplayPort interfaces external bridges are optional, so
> > +        * silently ignore an error if one is not present (-ENODEV).
> > +        */
> > +       rc = dp_parser_find_next_bridge(dp_priv->parser);
> > +       if (rc == -ENODEV) {
> > +               if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > +                       DRM_ERROR("eDP: next bridge is not present\n");
> > +                       return rc;
> > +               }
> > +       } else if (rc) {
> > +               if (rc != -EPROBE_DEFER)
> > +                       DRM_ERROR("DP: error parsing next bridge: %d\n", rc);
> > +               return rc;
> > +       }
> > +
> > +       dp->next_bridge = dp_priv->parser->next_bridge;
> > +
> > +       return 0;
> > +}
> > +
> >  int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device
> *dev,
> >                         struct drm_encoder *encoder)  { @@ -1547,6
> > +1602,10 @@ int msm_dp_modeset_init(struct msm_dp *dp_display,
> struct
> > drm_device *dev,
> >
> >         dp_display->encoder = encoder;
> >
> > +       ret = dp_display_get_next_bridge(dp_display);
> 
> Didn't we just move bridge attachment out of modeset? Why is it being done
> here?
> 

After Dmitry's patches, there is a need to get all the required bridges before the bridge_connector_init.
The bridge_connector_init will instantiate the ops for the farthest bridge. If we do not get the next_bridge here,
then the get_modes for eDP will be using the dp_bridge function instead of the panel bridge function.

> > +       if (ret)
> > +               return ret;
> > +
> >         dp_display->bridge = dp_bridge_init(dp_display, dev, encoder);
> >         if (IS_ERR(dp_display->bridge)) {
> >                 ret = PTR_ERR(dp_display->bridge); diff --git
> > a/drivers/gpu/drm/msm/dp/dp_drm.c
> b/drivers/gpu/drm/msm/dp/dp_drm.c
> > index 7ce1aca..5254bd6 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_drm.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_drm.c
> > @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct
> msm_dp *dp_display, struct drm_device *
> >         bridge->funcs = &dp_bridge_ops;
> >         bridge->type = dp_display->connector_type;
> >
> > -       bridge->ops =
> > -               DRM_BRIDGE_OP_DETECT |
> > -               DRM_BRIDGE_OP_HPD |
> > -               DRM_BRIDGE_OP_MODES;
> > +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
> 
> Why can't eDP have bridge ops that are the same?
> 

eDP needs to be reported as always connected. Whichever bridge is setting these ops flags should provide the ops.
The farthest bridge from the encoder with the ops flag set should implement the ops.
drm_bridge_connector_detect  reports always connected for eDP. So, we don't need DRM_BRIDGE_OP_DETECT 
eDP panel bridge will add DRM_BRIDGE_OP_MODES in drm_panel_bridge_add_typed and will call panel_edp_get_modes.
As we are not supporting HPD for EDP, we are not setting the HPD ops flag.

> > +               bridge->ops =
> > +                       DRM_BRIDGE_OP_DETECT |
> > +                       DRM_BRIDGE_OP_HPD |
> > +                       DRM_BRIDGE_OP_MODES;
> > +       }
> >
> >         rc = drm_bridge_attach(encoder, bridge, NULL,
> DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >         if (rc) {

Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 7:11 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > > @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct
> > msm_dp *dp_display, struct drm_device *
> > >         bridge->funcs = &dp_bridge_ops;
> > >         bridge->type = dp_display->connector_type;
> > >
> > > -       bridge->ops =
> > > -               DRM_BRIDGE_OP_DETECT |
> > > -               DRM_BRIDGE_OP_HPD |
> > > -               DRM_BRIDGE_OP_MODES;
> > > +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
> >
> > Why can't eDP have bridge ops that are the same?
> >
>
> eDP needs to be reported as always connected. Whichever bridge is setting these ops flags should provide the ops.
> The farthest bridge from the encoder with the ops flag set should implement the ops.
> drm_bridge_connector_detect  reports always connected for eDP. So, we don't need DRM_BRIDGE_OP_DETECT
> eDP panel bridge will add DRM_BRIDGE_OP_MODES in drm_panel_bridge_add_typed and will call panel_edp_get_modes.
> As we are not supporting HPD for EDP, we are not setting the HPD ops flag.

Right. It's Expected that eDP and DP would have different ops. If we
define "detect" and "HPD" as whether the display is _physically_
connected, not the status of the poorly-named eDP "HPD" pin, then eDP
is _supposed_ to be considered always connected and thus would never
support DETECT / HPD.

...and right that the panel is expected to handle the modes.

This matches how things have been progressing in Laurent's patches
(taken over by Kieran) to add full DP support to sn65dsi86. For
instance:

https://lore.kernel.org/r/20220317131250.1481275-3-kieran.bingham+renesas@ideasonboard.com/
https://lore.kernel.org/r/20220317131250.1481275-4-kieran.bingham+renesas@ideasonboard.com/

-Doug

Re: [PATCH v5 5/9] drm/msm/dp: Add eDP support via aux_bus

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 7:11 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > > @@ -114,10 +114,12 @@ struct drm_bridge *dp_bridge_init(struct
> > msm_dp *dp_display, struct drm_device *
> > >         bridge->funcs = &dp_bridge_ops;
> > >         bridge->type = dp_display->connector_type;
> > >
> > > -       bridge->ops =
> > > -               DRM_BRIDGE_OP_DETECT |
> > > -               DRM_BRIDGE_OP_HPD |
> > > -               DRM_BRIDGE_OP_MODES;
> > > +       if (bridge->type == DRM_MODE_CONNECTOR_DisplayPort) {
> >
> > Why can't eDP have bridge ops that are the same?
> >
>
> eDP needs to be reported as always connected. Whichever bridge is setting these ops flags should provide the ops.
> The farthest bridge from the encoder with the ops flag set should implement the ops.
> drm_bridge_connector_detect  reports always connected for eDP. So, we don't need DRM_BRIDGE_OP_DETECT
> eDP panel bridge will add DRM_BRIDGE_OP_MODES in drm_panel_bridge_add_typed and will call panel_edp_get_modes.
> As we are not supporting HPD for EDP, we are not setting the HPD ops flag.

Right. It's Expected that eDP and DP would have different ops. If we
define "detect" and "HPD" as whether the display is _physically_
connected, not the status of the poorly-named eDP "HPD" pin, then eDP
is _supposed_ to be considered always connected and thus would never
support DETECT / HPD.

...and right that the panel is expected to handle the modes.

This matches how things have been progressing in Laurent's patches
(taken over by Kieran) to add full DP support to sn65dsi86. For
instance:

https://lore.kernel.org/r/20220317131250.1481275-3-kieran.bingham+renesas@ideasonboard.com/
https://lore.kernel.org/r/20220317131250.1481275-4-kieran.bingham+renesas@ideasonboard.com/

-Doug

[PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti]

	The source device should ensure the sink is ready before
proceeding to read the sink capability or performing any aux transactions.
The sink will indicate its readiness by asserting the HPD line.

	The eDP sink requires power from the source and its HPD line will
be asserted only after the panel is powered on. The panel power will be
enabled from the panel-edp driver.

	The controller driver needs to wait for the hpd line to be asserted
by the sink.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
 drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
 drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
 drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 6d36f63..2ddc303 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
 		goto exit;
 	}
 
+	ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
+	if (ret) {
+		DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
+		goto exit;
+	}
+
 	dp_aux_update_offset_and_segment(aux, msg);
 	dp_aux_transfer_helper(aux, msg, true);
 
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index fac815f..2c3b0f7 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
 	phy_calibrate(phy);
 }
 
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
+{
+	u32 state, hpd_en, timeout;
+	struct dp_catalog_private *catalog = container_of(dp_catalog,
+				struct dp_catalog_private, dp_catalog);
+
+	hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
+					DP_DP_HPD_CTRL_HPD_EN;
+
+	/* no-hpd case */
+	if (!hpd_en)
+		return 0;
+
+	/* Poll for HPD connected status */
+	timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
+					DP_HPD_CONNECT_TIME_MASK;
+
+	return readl_poll_timeout(catalog->io->dp_controller.aux.base +
+				REG_DP_DP_HPD_INT_STATUS,
+				state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
+				2000, timeout);
+}
+
 static void dump_regs(void __iomem *base, int len)
 {
 	int i;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 7dea101..45140a3 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -84,6 +84,7 @@ int dp_catalog_aux_clear_hw_interrupts(struct dp_catalog *dp_catalog);
 void dp_catalog_aux_reset(struct dp_catalog *dp_catalog);
 void dp_catalog_aux_enable(struct dp_catalog *dp_catalog, bool enable);
 void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog);
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog);
 u32 dp_catalog_aux_get_irq(struct dp_catalog *dp_catalog);
 
 /* DP Controller APIs */
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
index 2686028..d68c71b 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -53,9 +53,14 @@
 #define DP_DP_HPD_REFTIMER_ENABLE		(1 << 16)
 
 #define REG_DP_DP_HPD_EVENT_TIME_0		(0x0000001C)
-#define REG_DP_DP_HPD_EVENT_TIME_1		(0x00000020)
 #define DP_DP_HPD_EVENT_TIME_0_VAL		(0x3E800FA)
+#define DP_HPD_GLITCH_TIME_MASK			(0xFFFC0000)
+#define DP_HPD_CONNECT_TIME_MASK		(0x0003FFFF)
+
+#define REG_DP_DP_HPD_EVENT_TIME_1		(0x00000020)
 #define DP_DP_HPD_EVENT_TIME_1_VAL		(0x1F407D0)
+#define DP_HPD_DISCONNECT_TIME_MASK		(0xFFFFC000)
+#define DP_IRQ_HPD_MAX_TIME_MASK		(0x00003FFF)
 
 #define REG_DP_AUX_CTRL				(0x00000030)
 #define DP_AUX_CTRL_ENABLE			(0x00000001)
-- 
2.7.4

[PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti]

	The source device should ensure the sink is ready before
proceeding to read the sink capability or performing any aux transactions.
The sink will indicate its readiness by asserting the HPD line.

	The eDP sink requires power from the source and its HPD line will
be asserted only after the panel is powered on. The panel power will be
enabled from the panel-edp driver.

	The controller driver needs to wait for the hpd line to be asserted
by the sink.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
 drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
 drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
 drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
 4 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 6d36f63..2ddc303 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
 		goto exit;
 	}
 
+	ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
+	if (ret) {
+		DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
+		goto exit;
+	}
+
 	dp_aux_update_offset_and_segment(aux, msg);
 	dp_aux_transfer_helper(aux, msg, true);
 
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index fac815f..2c3b0f7 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
 	phy_calibrate(phy);
 }
 
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
+{
+	u32 state, hpd_en, timeout;
+	struct dp_catalog_private *catalog = container_of(dp_catalog,
+				struct dp_catalog_private, dp_catalog);
+
+	hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
+					DP_DP_HPD_CTRL_HPD_EN;
+
+	/* no-hpd case */
+	if (!hpd_en)
+		return 0;
+
+	/* Poll for HPD connected status */
+	timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
+					DP_HPD_CONNECT_TIME_MASK;
+
+	return readl_poll_timeout(catalog->io->dp_controller.aux.base +
+				REG_DP_DP_HPD_INT_STATUS,
+				state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
+				2000, timeout);
+}
+
 static void dump_regs(void __iomem *base, int len)
 {
 	int i;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 7dea101..45140a3 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -84,6 +84,7 @@ int dp_catalog_aux_clear_hw_interrupts(struct dp_catalog *dp_catalog);
 void dp_catalog_aux_reset(struct dp_catalog *dp_catalog);
 void dp_catalog_aux_enable(struct dp_catalog *dp_catalog, bool enable);
 void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog);
+int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog);
 u32 dp_catalog_aux_get_irq(struct dp_catalog *dp_catalog);
 
 /* DP Controller APIs */
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
index 2686028..d68c71b 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -53,9 +53,14 @@
 #define DP_DP_HPD_REFTIMER_ENABLE		(1 << 16)
 
 #define REG_DP_DP_HPD_EVENT_TIME_0		(0x0000001C)
-#define REG_DP_DP_HPD_EVENT_TIME_1		(0x00000020)
 #define DP_DP_HPD_EVENT_TIME_0_VAL		(0x3E800FA)
+#define DP_HPD_GLITCH_TIME_MASK			(0xFFFC0000)
+#define DP_HPD_CONNECT_TIME_MASK		(0x0003FFFF)
+
+#define REG_DP_DP_HPD_EVENT_TIME_1		(0x00000020)
 #define DP_DP_HPD_EVENT_TIME_1_VAL		(0x1F407D0)
+#define DP_HPD_DISCONNECT_TIME_MASK		(0xFFFFC000)
+#define DP_IRQ_HPD_MAX_TIME_MASK		(0x00003FFF)
 
 #define REG_DP_AUX_CTRL				(0x00000030)
 #define DP_AUX_CTRL_ENABLE			(0x00000001)
-- 
2.7.4

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
>         The source device should ensure the sink is ready before
> proceeding to read the sink capability or performing any aux transactions.
> The sink will indicate its readiness by asserting the HPD line.
>
>         The eDP sink requires power from the source and its HPD line will
> be asserted only after the panel is powered on. The panel power will be
> enabled from the panel-edp driver.
>
>         The controller driver needs to wait for the hpd line to be asserted
> by the sink.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
>  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
>  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
>  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
>  4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 6d36f63..2ddc303 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>                 goto exit;
>         }
>
> +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);

Why are we making aux transactions when hpd isn't asserted? Can we only
register the aux device once we know that state is "connected"? I'm
concerned that we're going to be possibly polling the connected bit up
to some amount of time (0x0003FFFF usecs?) for each aux transfer when
that doesn't make any sense to keep checking. We should be able to check
it once, register aux, and then when disconnect happens we can
unregister aux.

> +       if (ret) {
> +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> +               goto exit;
> +       }
> +
>         dp_aux_update_offset_and_segment(aux, msg);
>         dp_aux_transfer_helper(aux, msg, true);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index fac815f..2c3b0f7 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
>         phy_calibrate(phy);
>  }
>
> +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> +{
> +       u32 state, hpd_en, timeout;
> +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> +                               struct dp_catalog_private, dp_catalog);
> +
> +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> +                                       DP_DP_HPD_CTRL_HPD_EN;

Use two lines

	hpd_en = dp_read_aux();
	hpd_en &= DP_DP_HPD_CTRL_HPD_EN;

> +
> +       /* no-hpd case */
> +       if (!hpd_en)
> +               return 0;
> +
> +       /* Poll for HPD connected status */
> +       timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
> +                                       DP_HPD_CONNECT_TIME_MASK;
> +
> +       return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> +                               REG_DP_DP_HPD_INT_STATUS,
> +                               state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
> +                               2000, timeout);
> +}
> +
>  static void dump_regs(void __iomem *base, int len)
>  {
>         int i;

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
>         The source device should ensure the sink is ready before
> proceeding to read the sink capability or performing any aux transactions.
> The sink will indicate its readiness by asserting the HPD line.
>
>         The eDP sink requires power from the source and its HPD line will
> be asserted only after the panel is powered on. The panel power will be
> enabled from the panel-edp driver.
>
>         The controller driver needs to wait for the hpd line to be asserted
> by the sink.
>
> Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> ---
>  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
>  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
>  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
>  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
>  4 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 6d36f63..2ddc303 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>                 goto exit;
>         }
>
> +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);

Why are we making aux transactions when hpd isn't asserted? Can we only
register the aux device once we know that state is "connected"? I'm
concerned that we're going to be possibly polling the connected bit up
to some amount of time (0x0003FFFF usecs?) for each aux transfer when
that doesn't make any sense to keep checking. We should be able to check
it once, register aux, and then when disconnect happens we can
unregister aux.

> +       if (ret) {
> +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> +               goto exit;
> +       }
> +
>         dp_aux_update_offset_and_segment(aux, msg);
>         dp_aux_transfer_helper(aux, msg, true);
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index fac815f..2c3b0f7 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
>         phy_calibrate(phy);
>  }
>
> +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> +{
> +       u32 state, hpd_en, timeout;
> +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> +                               struct dp_catalog_private, dp_catalog);
> +
> +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> +                                       DP_DP_HPD_CTRL_HPD_EN;

Use two lines

	hpd_en = dp_read_aux();
	hpd_en &= DP_DP_HPD_CTRL_HPD_EN;

> +
> +       /* no-hpd case */
> +       if (!hpd_en)
> +               return 0;
> +
> +       /* Poll for HPD connected status */
> +       timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
> +                                       DP_HPD_CONNECT_TIME_MASK;
> +
> +       return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> +                               REG_DP_DP_HPD_INT_STATUS,
> +                               state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
> +                               2000, timeout);
> +}
> +
>  static void dump_regs(void __iomem *base, int len)
>  {
>         int i;

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Thu, Mar 17, 2022 at 6:19 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
> >         The source device should ensure the sink is ready before
> > proceeding to read the sink capability or performing any aux transactions.
> > The sink will indicate its readiness by asserting the HPD line.
> >
> >         The eDP sink requires power from the source and its HPD line will
> > be asserted only after the panel is powered on. The panel power will be
> > enabled from the panel-edp driver.
> >
> >         The controller driver needs to wait for the hpd line to be asserted
> > by the sink.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
> >  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
> >  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
> >  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
> >  4 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> > index 6d36f63..2ddc303 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
> >                 goto exit;
> >         }
> >
> > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
>
> Why are we making aux transactions when hpd isn't asserted? Can we only
> register the aux device once we know that state is "connected"? I'm
> concerned that we're going to be possibly polling the connected bit up
> to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> that doesn't make any sense to keep checking. We should be able to check
> it once, register aux, and then when disconnect happens we can
> unregister aux.

This is for eDP and, unless someone wants to redesign it again, is
just how it works.

Specifically:

1. On eDP you _always_ report "connected". This is because when an eDP
panel is turned off (but still there) you actually have no way to
detect it--you just have to assume it's there. And thus you _always_
register the AUX bus.

2. When we are asked to read the EDID that happens _before_ the normal
prepare/enable steps. The way that this should work is that the
request travels down to the panel. The panel turns itself on (waiting
for any hardcoded delays it knows about) and then initiates an AUX
transaction. The AUX transaction is in charge of waiting for HPD.


For the DP case this should not cause any significant overhead, right?
HPD should always be asserted so this is basically just one extra IO
read confirming that HPD is asserted which should be almost nothing...
You're just about to do a whole bunch of IO reads/writes in order to
program the AUX transaction anyway.


> > +       if (ret) {
> > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > +               goto exit;
> > +       }
> > +
> >         dp_aux_update_offset_and_segment(aux, msg);
> >         dp_aux_transfer_helper(aux, msg, true);
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > index fac815f..2c3b0f7 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> >         phy_calibrate(phy);
> >  }
> >
> > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > +{
> > +       u32 state, hpd_en, timeout;
> > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > +                               struct dp_catalog_private, dp_catalog);
> > +
> > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > +                                       DP_DP_HPD_CTRL_HPD_EN;
>
> Use two lines
>
>         hpd_en = dp_read_aux();
>         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
>
> > +
> > +       /* no-hpd case */
> > +       if (!hpd_en)
> > +               return 0;

I guess reading from hardware is fine, but I would have expected the
driver to simply know whether HPD is used or not. Don't need to read
it from hardware, do we? It's not like it's changing from minute to
minute--this is something known at probe time.


> > +       /* Poll for HPD connected status */
> > +       timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
> > +                                       DP_HPD_CONNECT_TIME_MASK;
> > +
> > +       return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> > +                               REG_DP_DP_HPD_INT_STATUS,
> > +                               state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
> > +                               2000, timeout);

The timeout that comes from hardware is really stored in microseconds?
That's the units of the value passed to readl_poll_timeout(), right?
Looking at your #defines, that means that your max value here is
0x3fff which is 16383 microseconds or ~16 ms. That doesn't seem like
nearly a long enough timeout to wait for a panel to power itself up.

Also: I'm not sure why exactly you're using the timeout in the
register here. Isn't the time you need to wait more about how long an
eDP panel might conceivably need to power itself on? Most eDP panels
I've seen have max delays of ~200 ms. I'd probably just wait 500 ms to
be on the safe side.

-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Thu, Mar 17, 2022 at 6:19 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
> >         The source device should ensure the sink is ready before
> > proceeding to read the sink capability or performing any aux transactions.
> > The sink will indicate its readiness by asserting the HPD line.
> >
> >         The eDP sink requires power from the source and its HPD line will
> > be asserted only after the panel is powered on. The panel power will be
> > enabled from the panel-edp driver.
> >
> >         The controller driver needs to wait for the hpd line to be asserted
> > by the sink.
> >
> > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > ---
> >  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
> >  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
> >  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
> >  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
> >  4 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> > index 6d36f63..2ddc303 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
> >                 goto exit;
> >         }
> >
> > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
>
> Why are we making aux transactions when hpd isn't asserted? Can we only
> register the aux device once we know that state is "connected"? I'm
> concerned that we're going to be possibly polling the connected bit up
> to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> that doesn't make any sense to keep checking. We should be able to check
> it once, register aux, and then when disconnect happens we can
> unregister aux.

This is for eDP and, unless someone wants to redesign it again, is
just how it works.

Specifically:

1. On eDP you _always_ report "connected". This is because when an eDP
panel is turned off (but still there) you actually have no way to
detect it--you just have to assume it's there. And thus you _always_
register the AUX bus.

2. When we are asked to read the EDID that happens _before_ the normal
prepare/enable steps. The way that this should work is that the
request travels down to the panel. The panel turns itself on (waiting
for any hardcoded delays it knows about) and then initiates an AUX
transaction. The AUX transaction is in charge of waiting for HPD.


For the DP case this should not cause any significant overhead, right?
HPD should always be asserted so this is basically just one extra IO
read confirming that HPD is asserted which should be almost nothing...
You're just about to do a whole bunch of IO reads/writes in order to
program the AUX transaction anyway.


> > +       if (ret) {
> > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > +               goto exit;
> > +       }
> > +
> >         dp_aux_update_offset_and_segment(aux, msg);
> >         dp_aux_transfer_helper(aux, msg, true);
> >
> > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > index fac815f..2c3b0f7 100644
> > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> >         phy_calibrate(phy);
> >  }
> >
> > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > +{
> > +       u32 state, hpd_en, timeout;
> > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > +                               struct dp_catalog_private, dp_catalog);
> > +
> > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > +                                       DP_DP_HPD_CTRL_HPD_EN;
>
> Use two lines
>
>         hpd_en = dp_read_aux();
>         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
>
> > +
> > +       /* no-hpd case */
> > +       if (!hpd_en)
> > +               return 0;

I guess reading from hardware is fine, but I would have expected the
driver to simply know whether HPD is used or not. Don't need to read
it from hardware, do we? It's not like it's changing from minute to
minute--this is something known at probe time.


> > +       /* Poll for HPD connected status */
> > +       timeout = dp_read_aux(catalog, REG_DP_DP_HPD_EVENT_TIME_0) &
> > +                                       DP_HPD_CONNECT_TIME_MASK;
> > +
> > +       return readl_poll_timeout(catalog->io->dp_controller.aux.base +
> > +                               REG_DP_DP_HPD_INT_STATUS,
> > +                               state, state & DP_DP_HPD_STATE_STATUS_CONNECTED,
> > +                               2000, timeout);

The timeout that comes from hardware is really stored in microseconds?
That's the units of the value passed to readl_poll_timeout(), right?
Looking at your #defines, that means that your max value here is
0x3fff which is 16383 microseconds or ~16 ms. That doesn't seem like
nearly a long enough timeout to wait for a panel to power itself up.

Also: I'm not sure why exactly you're using the timeout in the
register here. Isn't the time you need to wait more about how long an
eDP panel might conceivably need to power itself on? Most eDP panels
I've seen have max delays of ~200 ms. I'd probably just wait 500 ms to
be on the safe side.

-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Doug Anderson (2022-03-18 09:24:17)
> Hi,
>
> On Thu, Mar 17, 2022 at 6:19 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
> > >         The source device should ensure the sink is ready before
> > > proceeding to read the sink capability or performing any aux transactions.
> > > The sink will indicate its readiness by asserting the HPD line.
> > >
> > >         The eDP sink requires power from the source and its HPD line will
> > > be asserted only after the panel is powered on. The panel power will be
> > > enabled from the panel-edp driver.
> > >
> > >         The controller driver needs to wait for the hpd line to be asserted
> > > by the sink.
> > >
> > > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > > ---
> > >  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
> > >  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
> > >  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
> > >  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
> > >  4 files changed, 36 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> > > index 6d36f63..2ddc303 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > > @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
> > >                 goto exit;
> > >         }
> > >
> > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> >
> > Why are we making aux transactions when hpd isn't asserted? Can we only
> > register the aux device once we know that state is "connected"? I'm
> > concerned that we're going to be possibly polling the connected bit up
> > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > that doesn't make any sense to keep checking. We should be able to check
> > it once, register aux, and then when disconnect happens we can
> > unregister aux.
>
> This is for eDP and, unless someone wants to redesign it again, is
> just how it works.
>
> Specifically:
>
> 1. On eDP you _always_ report "connected". This is because when an eDP
> panel is turned off (but still there) you actually have no way to
> detect it--you just have to assume it's there. And thus you _always_
> register the AUX bus.

Is reporting "connected" the same as HPD being asserted in the case of
eDP? I can understand wanting to report "connected", because as you say,
the panel is always connected; there aren't dongles or cables involved.
But the state of the HPD pin is changing at runtime, and eDP supports
irq_hpd pulses from what I recall, for "link management".

I think this device requires the status bit in the hardware to say it is
"connected" before aux transactions are guaranteed to work. Presumably
the HPD pin could go be asserted at the SoC's pad and there could be
some time still where the hardware status bit hasn't flipped over to
"connected" yet and thus aux transactions are going to fail. Can qcom
confirm this?

>
> 2. When we are asked to read the EDID that happens _before_ the normal
> prepare/enable steps. The way that this should work is that the
> request travels down to the panel. The panel turns itself on (waiting
> for any hardcoded delays it knows about) and then initiates an AUX
> transaction. The AUX transaction is in charge of waiting for HPD.

Are we talking about generic_edp_panel_probe()? Why doesn't that poll
hpd gpio like panel_edp_prepare_once() does? Are there any links to
discussions about this I can read? Pushing hpd state checking into aux
transactions looks like the wrong direction. Also, as I said up above I
am concerned that even checking the GPIO won't work and we need some way
to ask the bridge if HPD is asserted or not and then fallback to the
GPIO method if the display phy/controller doesn't have support to check
HPD internally. Something on top of DRM_BRIDGE_OP_HPD?

>
>
> For the DP case this should not cause any significant overhead, right?
> HPD should always be asserted so this is basically just one extra IO
> read confirming that HPD is asserted which should be almost nothing...
> You're just about to do a whole bunch of IO reads/writes in order to
> program the AUX transaction anyway.

In the DP case the dongle/cable can be disconnected in the middle of aux
transactions. If that happens we could be waiting a while in this
transfer function to timeout looking for the status bit. The driver
already gets an "unplug" irq when the cable is disconnected though so it
would be better to figure out a way to stop the aux transactions quickly
when that happens without having to read the hardware and poll the bit
that we already know is doomed to timeout. I think apple dongles throw
this logic for a loop though because the HDMI cable can be disconnected
from the dongle and then we don't see an "unplug" irq, just the number
of sinks becomes 0. Maybe there's an irq_hpd event, not sure.

>
>
> > > +       if (ret) {
> > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > +               goto exit;
> > > +       }
> > > +
> > >         dp_aux_update_offset_and_segment(aux, msg);
> > >         dp_aux_transfer_helper(aux, msg, true);
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > index fac815f..2c3b0f7 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > >         phy_calibrate(phy);
> > >  }
> > >
> > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > +{
> > > +       u32 state, hpd_en, timeout;
> > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > +                               struct dp_catalog_private, dp_catalog);
> > > +
> > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> >
> > Use two lines
> >
> >         hpd_en = dp_read_aux();
> >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> >
> > > +
> > > +       /* no-hpd case */
> > > +       if (!hpd_en)
> > > +               return 0;
>
> I guess reading from hardware is fine, but I would have expected the
> driver to simply know whether HPD is used or not. Don't need to read
> it from hardware, do we? It's not like it's changing from minute to
> minute--this is something known at probe time.

Are you saying that HPD is always asserted? That doesn't sound right.
My understanding is that HPD will be asserted after the panel is powered
up. Before that HPD is deasserted. Similarly, when we power down the
panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
panel is always connected? That sounds like it might be OK as long as
userspace doesn't use "connected" to know that it's OK to do things like
read/write aux or push pixels to the panel when HPD is deasserted.

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Doug Anderson (2022-03-18 09:24:17)
> Hi,
>
> On Thu, Mar 17, 2022 at 6:19 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Sankeerth Billakanti (2022-03-16 10:35:51)
> > >         The source device should ensure the sink is ready before
> > > proceeding to read the sink capability or performing any aux transactions.
> > > The sink will indicate its readiness by asserting the HPD line.
> > >
> > >         The eDP sink requires power from the source and its HPD line will
> > > be asserted only after the panel is powered on. The panel power will be
> > > enabled from the panel-edp driver.
> > >
> > >         The controller driver needs to wait for the hpd line to be asserted
> > > by the sink.
> > >
> > > Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
> > > ---
> > >  drivers/gpu/drm/msm/dp/dp_aux.c     |  6 ++++++
> > >  drivers/gpu/drm/msm/dp/dp_catalog.c | 23 +++++++++++++++++++++++
> > >  drivers/gpu/drm/msm/dp/dp_catalog.h |  1 +
> > >  drivers/gpu/drm/msm/dp/dp_reg.h     |  7 ++++++-
> > >  4 files changed, 36 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> > > index 6d36f63..2ddc303 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> > > @@ -337,6 +337,12 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
> > >                 goto exit;
> > >         }
> > >
> > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> >
> > Why are we making aux transactions when hpd isn't asserted? Can we only
> > register the aux device once we know that state is "connected"? I'm
> > concerned that we're going to be possibly polling the connected bit up
> > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > that doesn't make any sense to keep checking. We should be able to check
> > it once, register aux, and then when disconnect happens we can
> > unregister aux.
>
> This is for eDP and, unless someone wants to redesign it again, is
> just how it works.
>
> Specifically:
>
> 1. On eDP you _always_ report "connected". This is because when an eDP
> panel is turned off (but still there) you actually have no way to
> detect it--you just have to assume it's there. And thus you _always_
> register the AUX bus.

Is reporting "connected" the same as HPD being asserted in the case of
eDP? I can understand wanting to report "connected", because as you say,
the panel is always connected; there aren't dongles or cables involved.
But the state of the HPD pin is changing at runtime, and eDP supports
irq_hpd pulses from what I recall, for "link management".

I think this device requires the status bit in the hardware to say it is
"connected" before aux transactions are guaranteed to work. Presumably
the HPD pin could go be asserted at the SoC's pad and there could be
some time still where the hardware status bit hasn't flipped over to
"connected" yet and thus aux transactions are going to fail. Can qcom
confirm this?

>
> 2. When we are asked to read the EDID that happens _before_ the normal
> prepare/enable steps. The way that this should work is that the
> request travels down to the panel. The panel turns itself on (waiting
> for any hardcoded delays it knows about) and then initiates an AUX
> transaction. The AUX transaction is in charge of waiting for HPD.

Are we talking about generic_edp_panel_probe()? Why doesn't that poll
hpd gpio like panel_edp_prepare_once() does? Are there any links to
discussions about this I can read? Pushing hpd state checking into aux
transactions looks like the wrong direction. Also, as I said up above I
am concerned that even checking the GPIO won't work and we need some way
to ask the bridge if HPD is asserted or not and then fallback to the
GPIO method if the display phy/controller doesn't have support to check
HPD internally. Something on top of DRM_BRIDGE_OP_HPD?

>
>
> For the DP case this should not cause any significant overhead, right?
> HPD should always be asserted so this is basically just one extra IO
> read confirming that HPD is asserted which should be almost nothing...
> You're just about to do a whole bunch of IO reads/writes in order to
> program the AUX transaction anyway.

In the DP case the dongle/cable can be disconnected in the middle of aux
transactions. If that happens we could be waiting a while in this
transfer function to timeout looking for the status bit. The driver
already gets an "unplug" irq when the cable is disconnected though so it
would be better to figure out a way to stop the aux transactions quickly
when that happens without having to read the hardware and poll the bit
that we already know is doomed to timeout. I think apple dongles throw
this logic for a loop though because the HDMI cable can be disconnected
from the dongle and then we don't see an "unplug" irq, just the number
of sinks becomes 0. Maybe there's an irq_hpd event, not sure.

>
>
> > > +       if (ret) {
> > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > +               goto exit;
> > > +       }
> > > +
> > >         dp_aux_update_offset_and_segment(aux, msg);
> > >         dp_aux_transfer_helper(aux, msg, true);
> > >
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > index fac815f..2c3b0f7 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > >         phy_calibrate(phy);
> > >  }
> > >
> > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > +{
> > > +       u32 state, hpd_en, timeout;
> > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > +                               struct dp_catalog_private, dp_catalog);
> > > +
> > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> >
> > Use two lines
> >
> >         hpd_en = dp_read_aux();
> >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> >
> > > +
> > > +       /* no-hpd case */
> > > +       if (!hpd_en)
> > > +               return 0;
>
> I guess reading from hardware is fine, but I would have expected the
> driver to simply know whether HPD is used or not. Don't need to read
> it from hardware, do we? It's not like it's changing from minute to
> minute--this is something known at probe time.

Are you saying that HPD is always asserted? That doesn't sound right.
My understanding is that HPD will be asserted after the panel is powered
up. Before that HPD is deasserted. Similarly, when we power down the
panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
panel is always connected? That sounds like it might be OK as long as
userspace doesn't use "connected" to know that it's OK to do things like
read/write aux or push pixels to the panel when HPD is deasserted.

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 18, 2022 at 1:17 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> > > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> > >
> > > Why are we making aux transactions when hpd isn't asserted? Can we only
> > > register the aux device once we know that state is "connected"? I'm
> > > concerned that we're going to be possibly polling the connected bit up
> > > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > > that doesn't make any sense to keep checking. We should be able to check
> > > it once, register aux, and then when disconnect happens we can
> > > unregister aux.
> >
> > This is for eDP and, unless someone wants to redesign it again, is
> > just how it works.
> >
> > Specifically:
> >
> > 1. On eDP you _always_ report "connected". This is because when an eDP
> > panel is turned off (but still there) you actually have no way to
> > detect it--you just have to assume it's there. And thus you _always_
> > register the AUX bus.
>
> Is reporting "connected" the same as HPD being asserted in the case of
> eDP? I can understand wanting to report "connected", because as you say,
> the panel is always connected; there aren't dongles or cables involved.

No. What I mean by connected is that when DRM asks "hey, do you have a
panel" connected then for eDP we always say "yes" regardless of any
hardware state.

HPD is a _huge_ misnomer for eDP and IMO the name causes lots of
confusion. It's not "hot plug detect". You don't hot plug eDP. It's
really "panel ready / panel IRQ"


> But the state of the HPD pin is changing at runtime, and eDP supports
> irq_hpd pulses from what I recall, for "link management".
>
> I think this device requires the status bit in the hardware to say it is
> "connected" before aux transactions are guaranteed to work. Presumably
> the HPD pin could go be asserted at the SoC's pad and there could be
> some time still where the hardware status bit hasn't flipped over to
> "connected" yet and thus aux transactions are going to fail. Can qcom
> confirm this?
>
> >
> > 2. When we are asked to read the EDID that happens _before_ the normal
> > prepare/enable steps. The way that this should work is that the
> > request travels down to the panel. The panel turns itself on (waiting
> > for any hardcoded delays it knows about) and then initiates an AUX
> > transaction. The AUX transaction is in charge of waiting for HPD.
>
> Are we talking about generic_edp_panel_probe()? Why doesn't that poll
> hpd gpio like panel_edp_prepare_once() does?

There's no HPD GPIO in this case, right?

In the trogdor case we ended up not using the HPD that was part of the
ti-sn65dsi86 controller because it was fairly useless (it debounced
for far too long), so we ended up hooking it up as a GPIO and I guess
gave up on getting the extra notifications from the panel. Maybe a
good thing, in hindsight, that we didn't do PSR because that might
have been a pain.

In any case, originally I had the GPIO being handled by the
ti-sn65dsi86 controller driver and that seemed like it made sense to
me (after all, the ti-sn65dsi86 driver would have to handle HPD if
this went to the dedicated HPD pin) but got told "no, put it in the
panel" by both you and Laurent [1].

[1] https://lore.kernel.org/r/20200415203256.GP4758@pendragon.ideasonboard.com/


> Are there any links to
> discussions about this I can read?

I'm not sure if there's any more than the conversation I pointed at
above where we talked about hpd-gpios. Atop that, I believe I just
realized that this was the only way it could work without re-designing
again.

To some extent the status quo is documented in commit a64ad9c3e4a5
("drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle
HPD"). I wrote that commit when I thought about how HPD would need to
be handled if it was a dedicated pin on the controller and the panel
didn't have knowledge about it.


> Pushing hpd state checking into aux
> transactions looks like the wrong direction. Also, as I said up above I
> am concerned that even checking the GPIO won't work and we need some way
> to ask the bridge if HPD is asserted or not and then fallback to the
> GPIO method if the display phy/controller doesn't have support to check
> HPD internally. Something on top of DRM_BRIDGE_OP_HPD?

If we could somehow get the HPD status from the bridge in the panel
driver it definitely would be convenient. It does feel like that's an
improvement that could be done later, though. We've already landed a
few instances of doing what's done here, like for parade-ps8640 and
analogix_dp. I suspect designing a new mechanism might not be the most
trivial.

I haven't actually tried it, but I suspect that to get something like
what you're talking about we'd have to get the rest of drm to know
that for eDP ports that it should assume something is connected
_regardless_ of what the "detect" / "HPD" options say. Then we'd have
to extend the edp-panel code to be able to be able to query the next
bridge in the chain if a GPIO wasn't provided.


> > For the DP case this should not cause any significant overhead, right?
> > HPD should always be asserted so this is basically just one extra IO
> > read confirming that HPD is asserted which should be almost nothing...
> > You're just about to do a whole bunch of IO reads/writes in order to
> > program the AUX transaction anyway.
>
> In the DP case the dongle/cable can be disconnected in the middle of aux
> transactions. If that happens we could be waiting a while in this
> transfer function to timeout looking for the status bit. The driver
> already gets an "unplug" irq when the cable is disconnected though so it
> would be better to figure out a way to stop the aux transactions quickly
> when that happens without having to read the hardware and poll the bit
> that we already know is doomed to timeout. I think apple dongles throw
> this logic for a loop though because the HDMI cable can be disconnected
> from the dongle and then we don't see an "unplug" irq, just the number
> of sinks becomes 0. Maybe there's an irq_hpd event, not sure.

Ah, interesting. Having a DP cable unplugged in the middle of an aux
transaction does seem like it could be a problem. What if we just wait
in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
be easy, right?


> > > > +       if (ret) {
> > > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > > +               goto exit;
> > > > +       }
> > > > +
> > > >         dp_aux_update_offset_and_segment(aux, msg);
> > > >         dp_aux_transfer_helper(aux, msg, true);
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > index fac815f..2c3b0f7 100644
> > > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > > >         phy_calibrate(phy);
> > > >  }
> > > >
> > > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > > +{
> > > > +       u32 state, hpd_en, timeout;
> > > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > > +                               struct dp_catalog_private, dp_catalog);
> > > > +
> > > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> > >
> > > Use two lines
> > >
> > >         hpd_en = dp_read_aux();
> > >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > >
> > > > +
> > > > +       /* no-hpd case */
> > > > +       if (!hpd_en)
> > > > +               return 0;
> >
> > I guess reading from hardware is fine, but I would have expected the
> > driver to simply know whether HPD is used or not. Don't need to read
> > it from hardware, do we? It's not like it's changing from minute to
> > minute--this is something known at probe time.
>
> Are you saying that HPD is always asserted?

I don't think this is looking for HPD assertion, is it? This is
looking for whether the HPD interrupt is enabled, isn't it? This is to
support the case of eDP panels where we didn't hook the HPD line up,
right? It should be known at probe time whether we've hooked HPD up or
not. ...or am I misreading?


> That doesn't sound right.
> My understanding is that HPD will be asserted after the panel is powered
> up. Before that HPD is deasserted. Similarly, when we power down the
> panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> panel is always connected? That sounds like it might be OK as long as
> userspace doesn't use "connected" to know that it's OK to do things like
> read/write aux or push pixels to the panel when HPD is deasserted.

IMO having userspace reading / writing aux directly and expecting it
to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
case, but it's really not good in the eDP case. To me it's sorta like
expecting things to be amazing and foolproof when you go behind the
kernel's back and write to an i2c device using `i2cset -f`. Sure, it
might work, but it can also confuse the heck out of things. It also
turns out to be a huge problem when you get to PSR because userspace
will get errors if it tries to write to the AUX channel and the panel
is in PSR mode. This came up in the context of Brian's analogix dp
patches [1]. The right answer, in my mind, is to treat userspace
accessing the AUX channel directly as more of a debug feature, at
least for eDP panels.

In terms of userspace pushing pixels to the panel, I don't think
that's quite the same, is it? Generally userspace is in charge of
whether the eDP panel is powered on or powered off, isn't it?

So generally I think that for eDP a panel is always "connected" in all
senses of the word. It might not be "powered" at some given point of
time, but it's always connected.

[1] https://lore.kernel.org/r/CAD=FV=VYe1rLKANQ8eom7g8x1v6_s_OYnX819Ax4m7O3UwDHmg@mail.gmail.com/


-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 18, 2022 at 1:17 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> > > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> > >
> > > Why are we making aux transactions when hpd isn't asserted? Can we only
> > > register the aux device once we know that state is "connected"? I'm
> > > concerned that we're going to be possibly polling the connected bit up
> > > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > > that doesn't make any sense to keep checking. We should be able to check
> > > it once, register aux, and then when disconnect happens we can
> > > unregister aux.
> >
> > This is for eDP and, unless someone wants to redesign it again, is
> > just how it works.
> >
> > Specifically:
> >
> > 1. On eDP you _always_ report "connected". This is because when an eDP
> > panel is turned off (but still there) you actually have no way to
> > detect it--you just have to assume it's there. And thus you _always_
> > register the AUX bus.
>
> Is reporting "connected" the same as HPD being asserted in the case of
> eDP? I can understand wanting to report "connected", because as you say,
> the panel is always connected; there aren't dongles or cables involved.

No. What I mean by connected is that when DRM asks "hey, do you have a
panel" connected then for eDP we always say "yes" regardless of any
hardware state.

HPD is a _huge_ misnomer for eDP and IMO the name causes lots of
confusion. It's not "hot plug detect". You don't hot plug eDP. It's
really "panel ready / panel IRQ"


> But the state of the HPD pin is changing at runtime, and eDP supports
> irq_hpd pulses from what I recall, for "link management".
>
> I think this device requires the status bit in the hardware to say it is
> "connected" before aux transactions are guaranteed to work. Presumably
> the HPD pin could go be asserted at the SoC's pad and there could be
> some time still where the hardware status bit hasn't flipped over to
> "connected" yet and thus aux transactions are going to fail. Can qcom
> confirm this?
>
> >
> > 2. When we are asked to read the EDID that happens _before_ the normal
> > prepare/enable steps. The way that this should work is that the
> > request travels down to the panel. The panel turns itself on (waiting
> > for any hardcoded delays it knows about) and then initiates an AUX
> > transaction. The AUX transaction is in charge of waiting for HPD.
>
> Are we talking about generic_edp_panel_probe()? Why doesn't that poll
> hpd gpio like panel_edp_prepare_once() does?

There's no HPD GPIO in this case, right?

In the trogdor case we ended up not using the HPD that was part of the
ti-sn65dsi86 controller because it was fairly useless (it debounced
for far too long), so we ended up hooking it up as a GPIO and I guess
gave up on getting the extra notifications from the panel. Maybe a
good thing, in hindsight, that we didn't do PSR because that might
have been a pain.

In any case, originally I had the GPIO being handled by the
ti-sn65dsi86 controller driver and that seemed like it made sense to
me (after all, the ti-sn65dsi86 driver would have to handle HPD if
this went to the dedicated HPD pin) but got told "no, put it in the
panel" by both you and Laurent [1].

[1] https://lore.kernel.org/r/20200415203256.GP4758@pendragon.ideasonboard.com/


> Are there any links to
> discussions about this I can read?

I'm not sure if there's any more than the conversation I pointed at
above where we talked about hpd-gpios. Atop that, I believe I just
realized that this was the only way it could work without re-designing
again.

To some extent the status quo is documented in commit a64ad9c3e4a5
("drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle
HPD"). I wrote that commit when I thought about how HPD would need to
be handled if it was a dedicated pin on the controller and the panel
didn't have knowledge about it.


> Pushing hpd state checking into aux
> transactions looks like the wrong direction. Also, as I said up above I
> am concerned that even checking the GPIO won't work and we need some way
> to ask the bridge if HPD is asserted or not and then fallback to the
> GPIO method if the display phy/controller doesn't have support to check
> HPD internally. Something on top of DRM_BRIDGE_OP_HPD?

If we could somehow get the HPD status from the bridge in the panel
driver it definitely would be convenient. It does feel like that's an
improvement that could be done later, though. We've already landed a
few instances of doing what's done here, like for parade-ps8640 and
analogix_dp. I suspect designing a new mechanism might not be the most
trivial.

I haven't actually tried it, but I suspect that to get something like
what you're talking about we'd have to get the rest of drm to know
that for eDP ports that it should assume something is connected
_regardless_ of what the "detect" / "HPD" options say. Then we'd have
to extend the edp-panel code to be able to be able to query the next
bridge in the chain if a GPIO wasn't provided.


> > For the DP case this should not cause any significant overhead, right?
> > HPD should always be asserted so this is basically just one extra IO
> > read confirming that HPD is asserted which should be almost nothing...
> > You're just about to do a whole bunch of IO reads/writes in order to
> > program the AUX transaction anyway.
>
> In the DP case the dongle/cable can be disconnected in the middle of aux
> transactions. If that happens we could be waiting a while in this
> transfer function to timeout looking for the status bit. The driver
> already gets an "unplug" irq when the cable is disconnected though so it
> would be better to figure out a way to stop the aux transactions quickly
> when that happens without having to read the hardware and poll the bit
> that we already know is doomed to timeout. I think apple dongles throw
> this logic for a loop though because the HDMI cable can be disconnected
> from the dongle and then we don't see an "unplug" irq, just the number
> of sinks becomes 0. Maybe there's an irq_hpd event, not sure.

Ah, interesting. Having a DP cable unplugged in the middle of an aux
transaction does seem like it could be a problem. What if we just wait
in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
be easy, right?


> > > > +       if (ret) {
> > > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > > +               goto exit;
> > > > +       }
> > > > +
> > > >         dp_aux_update_offset_and_segment(aux, msg);
> > > >         dp_aux_transfer_helper(aux, msg, true);
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > index fac815f..2c3b0f7 100644
> > > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > > >         phy_calibrate(phy);
> > > >  }
> > > >
> > > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > > +{
> > > > +       u32 state, hpd_en, timeout;
> > > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > > +                               struct dp_catalog_private, dp_catalog);
> > > > +
> > > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> > >
> > > Use two lines
> > >
> > >         hpd_en = dp_read_aux();
> > >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > >
> > > > +
> > > > +       /* no-hpd case */
> > > > +       if (!hpd_en)
> > > > +               return 0;
> >
> > I guess reading from hardware is fine, but I would have expected the
> > driver to simply know whether HPD is used or not. Don't need to read
> > it from hardware, do we? It's not like it's changing from minute to
> > minute--this is something known at probe time.
>
> Are you saying that HPD is always asserted?

I don't think this is looking for HPD assertion, is it? This is
looking for whether the HPD interrupt is enabled, isn't it? This is to
support the case of eDP panels where we didn't hook the HPD line up,
right? It should be known at probe time whether we've hooked HPD up or
not. ...or am I misreading?


> That doesn't sound right.
> My understanding is that HPD will be asserted after the panel is powered
> up. Before that HPD is deasserted. Similarly, when we power down the
> panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> panel is always connected? That sounds like it might be OK as long as
> userspace doesn't use "connected" to know that it's OK to do things like
> read/write aux or push pixels to the panel when HPD is deasserted.

IMO having userspace reading / writing aux directly and expecting it
to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
case, but it's really not good in the eDP case. To me it's sorta like
expecting things to be amazing and foolproof when you go behind the
kernel's back and write to an i2c device using `i2cset -f`. Sure, it
might work, but it can also confuse the heck out of things. It also
turns out to be a huge problem when you get to PSR because userspace
will get errors if it tries to write to the AUX channel and the panel
is in PSR mode. This came up in the context of Brian's analogix dp
patches [1]. The right answer, in my mind, is to treat userspace
accessing the AUX channel directly as more of a debug feature, at
least for eDP panels.

In terms of userspace pushing pixels to the panel, I don't think
that's quite the same, is it? Generally userspace is in charge of
whether the eDP panel is powered on or powered off, isn't it?

So generally I think that for eDP a panel is always "connected" in all
senses of the word. It might not be "powered" at some given point of
time, but it's always connected.

[1] https://lore.kernel.org/r/CAD=FV=VYe1rLKANQ8eom7g8x1v6_s_OYnX819Ax4m7O3UwDHmg@mail.gmail.com/


-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Doug Anderson (2022-03-18 14:58:55)
> Hi,
>
> On Fri, Mar 18, 2022 at 1:17 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > > > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> > > >
> > > > Why are we making aux transactions when hpd isn't asserted? Can we only
> > > > register the aux device once we know that state is "connected"? I'm
> > > > concerned that we're going to be possibly polling the connected bit up
> > > > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > > > that doesn't make any sense to keep checking. We should be able to check
> > > > it once, register aux, and then when disconnect happens we can
> > > > unregister aux.
> > >
> > > This is for eDP and, unless someone wants to redesign it again, is
> > > just how it works.
> > >
> > > Specifically:
> > >
> > > 1. On eDP you _always_ report "connected". This is because when an eDP
> > > panel is turned off (but still there) you actually have no way to
> > > detect it--you just have to assume it's there. And thus you _always_
> > > register the AUX bus.
> >
> > Is reporting "connected" the same as HPD being asserted in the case of
> > eDP? I can understand wanting to report "connected", because as you say,
> > the panel is always connected; there aren't dongles or cables involved.
>
> No. What I mean by connected is that when DRM asks "hey, do you have a
> panel" connected then for eDP we always say "yes" regardless of any
> hardware state.
>
> HPD is a _huge_ misnomer for eDP and IMO the name causes lots of
> confusion. It's not "hot plug detect". You don't hot plug eDP. It's
> really "panel ready / panel IRQ"
>
>
> > But the state of the HPD pin is changing at runtime, and eDP supports
> > irq_hpd pulses from what I recall, for "link management".
> >
> > I think this device requires the status bit in the hardware to say it is
> > "connected" before aux transactions are guaranteed to work. Presumably
> > the HPD pin could go be asserted at the SoC's pad and there could be
> > some time still where the hardware status bit hasn't flipped over to
> > "connected" yet and thus aux transactions are going to fail. Can qcom
> > confirm this?
> >
> > >
> > > 2. When we are asked to read the EDID that happens _before_ the normal
> > > prepare/enable steps. The way that this should work is that the
> > > request travels down to the panel. The panel turns itself on (waiting
> > > for any hardcoded delays it knows about) and then initiates an AUX
> > > transaction. The AUX transaction is in charge of waiting for HPD.
> >
> > Are we talking about generic_edp_panel_probe()? Why doesn't that poll
> > hpd gpio like panel_edp_prepare_once() does?
>
> There's no HPD GPIO in this case, right?

Right. The hardware supports HPD here, so polling the pin as a gpio is
incorrect.

>
> In the trogdor case we ended up not using the HPD that was part of the
> ti-sn65dsi86 controller because it was fairly useless (it debounced
> for far too long), so we ended up hooking it up as a GPIO and I guess
> gave up on getting the extra notifications from the panel. Maybe a
> good thing, in hindsight, that we didn't do PSR because that might
> have been a pain.
>
> In any case, originally I had the GPIO being handled by the
> ti-sn65dsi86 controller driver and that seemed like it made sense to
> me (after all, the ti-sn65dsi86 driver would have to handle HPD if
> this went to the dedicated HPD pin) but got told "no, put it in the
> panel" by both you and Laurent [1].
>
> [1] https://lore.kernel.org/r/20200415203256.GP4758@pendragon.ideasonboard.com/
>
>
> > Are there any links to
> > discussions about this I can read?
>
> I'm not sure if there's any more than the conversation I pointed at
> above where we talked about hpd-gpios. Atop that, I believe I just
> realized that this was the only way it could work without re-designing
> again.
>
> To some extent the status quo is documented in commit a64ad9c3e4a5
> ("drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle
> HPD"). I wrote that commit when I thought about how HPD would need to
> be handled if it was a dedicated pin on the controller and the panel
> didn't have knowledge about it.
>
>
> > Pushing hpd state checking into aux
> > transactions looks like the wrong direction. Also, as I said up above I
> > am concerned that even checking the GPIO won't work and we need some way
> > to ask the bridge if HPD is asserted or not and then fallback to the
> > GPIO method if the display phy/controller doesn't have support to check
> > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
>
> If we could somehow get the HPD status from the bridge in the panel
> driver it definitely would be convenient. It does feel like that's an
> improvement that could be done later, though. We've already landed a
> few instances of doing what's done here, like for parade-ps8640 and
> analogix_dp. I suspect designing a new mechanism might not be the most
> trivial.

What is done in the bridge drivers is to wait for a fixed timeout and
assume aux is ready? Or is it something else? If there's just a fixed
timeout for the eDP case it sounds OK to do that for now and we can fine
tune it later to actually check HPD status register before the panel
tries to read EDID.

>
> I haven't actually tried it, but I suspect that to get something like
> what you're talking about we'd have to get the rest of drm to know
> that for eDP ports that it should assume something is connected
> _regardless_ of what the "detect" / "HPD" options say. Then we'd have
> to extend the edp-panel code to be able to be able to query the next
> bridge in the chain if a GPIO wasn't provided.

Can the panel interrogate the bridge chain somehow? It feels like either
something in the chain should know the status of HPD (the case here
where display controller in the SoC knows) or it should be a gpio to the
panel (trogdor case). The bridge ops can implement DRM_BRIDGE_OP_HPD and
the first bridge from the encoder that supports HPD can implement some
sort of "wait for hpd asserted" function that the panel then uses once
it powers up the panel during probe. If the panel has a gpio and nothing
else in the chain can detect hpd then the panel polls the gpio, or it
waits for the amount of time delay after powering on the panel if the
panel's hpd function is called.

>
>
> > > For the DP case this should not cause any significant overhead, right?
> > > HPD should always be asserted so this is basically just one extra IO
> > > read confirming that HPD is asserted which should be almost nothing...
> > > You're just about to do a whole bunch of IO reads/writes in order to
> > > program the AUX transaction anyway.
> >
> > In the DP case the dongle/cable can be disconnected in the middle of aux
> > transactions. If that happens we could be waiting a while in this
> > transfer function to timeout looking for the status bit. The driver
> > already gets an "unplug" irq when the cable is disconnected though so it
> > would be better to figure out a way to stop the aux transactions quickly
> > when that happens without having to read the hardware and poll the bit
> > that we already know is doomed to timeout. I think apple dongles throw
> > this logic for a loop though because the HDMI cable can be disconnected
> > from the dongle and then we don't see an "unplug" irq, just the number
> > of sinks becomes 0. Maybe there's an irq_hpd event, not sure.
>
> Ah, interesting. Having a DP cable unplugged in the middle of an aux
> transaction does seem like it could be a problem. What if we just wait
> in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
> be easy, right?

Sounds like it would work. Is this supposed to fix some DP case as well
though? There were some patches to speed up aux failures when the dongle
was unplugged but I haven't checked after that. I guess this waiting is
only important for eDP because the edp-panel code is trying to read EDID
and it isn't waiting for HPD to be asserted before doing that.

>
>
> > > > > +       if (ret) {
> > > > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > > > +               goto exit;
> > > > > +       }
> > > > > +
> > > > >         dp_aux_update_offset_and_segment(aux, msg);
> > > > >         dp_aux_transfer_helper(aux, msg, true);
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > index fac815f..2c3b0f7 100644
> > > > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > > > >         phy_calibrate(phy);
> > > > >  }
> > > > >
> > > > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > > > +{
> > > > > +       u32 state, hpd_en, timeout;
> > > > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > > > +                               struct dp_catalog_private, dp_catalog);
> > > > > +
> > > > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> > > >
> > > > Use two lines
> > > >
> > > >         hpd_en = dp_read_aux();
> > > >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > > >
> > > > > +
> > > > > +       /* no-hpd case */
> > > > > +       if (!hpd_en)
> > > > > +               return 0;
> > >
> > > I guess reading from hardware is fine, but I would have expected the
> > > driver to simply know whether HPD is used or not. Don't need to read
> > > it from hardware, do we? It's not like it's changing from minute to
> > > minute--this is something known at probe time.
> >
> > Are you saying that HPD is always asserted?
>
> I don't think this is looking for HPD assertion, is it? This is
> looking for whether the HPD interrupt is enabled, isn't it? This is to
> support the case of eDP panels where we didn't hook the HPD line up,
> right? It should be known at probe time whether we've hooked HPD up or
> not. ...or am I misreading?

Ah right. This is basically a proxy for "is no-hpd present in DT?" per
the last patch in this series.

>
>
> > That doesn't sound right.
> > My understanding is that HPD will be asserted after the panel is powered
> > up. Before that HPD is deasserted. Similarly, when we power down the
> > panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> > panel is always connected? That sounds like it might be OK as long as
> > userspace doesn't use "connected" to know that it's OK to do things like
> > read/write aux or push pixels to the panel when HPD is deasserted.
>
> IMO having userspace reading / writing aux directly and expecting it
> to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> case, but it's really not good in the eDP case. To me it's sorta like
> expecting things to be amazing and foolproof when you go behind the
> kernel's back and write to an i2c device using `i2cset -f`. Sure, it
> might work, but it can also confuse the heck out of things. It also
> turns out to be a huge problem when you get to PSR because userspace
> will get errors if it tries to write to the AUX channel and the panel
> is in PSR mode. This came up in the context of Brian's analogix dp
> patches [1]. The right answer, in my mind, is to treat userspace
> accessing the AUX channel directly as more of a debug feature, at
> least for eDP panels.

If it's a debug feature then it should be removed from the system. The
flow of data is passing through the kernel so if the kernel is getting
confused about backdoor access over aux it should snoop the transactions
and block things it doesn't like. I don't know the backstory on aux
being exposed to userspace, but leaving it in a broken state isn't good.

>
> In terms of userspace pushing pixels to the panel, I don't think
> that's quite the same, is it? Generally userspace is in charge of
> whether the eDP panel is powered on or powered off, isn't it?

I'm not sure what it's the same as, but I meant drawing on the screen
when the display is powering on but not visible yet is concerning.
drm_helper_hpd_irq_event() is used to tell userspace that it can "start
drawing now" because it calls drm_kms_helper_hotplug_event() when the
connector status changes. This is my understanding of how the DP path
works in this driver. I don't know how it works for eDP bridge drivers.

>
> So generally I think that for eDP a panel is always "connected" in all
> senses of the word. It might not be "powered" at some given point of
> time, but it's always connected.
>
> [1] https://lore.kernel.org/r/CAD=FV=VYe1rLKANQ8eom7g8x1v6_s_OYnX819Ax4m7O3UwDHmg@mail.gmail.com/
>

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Stephen Boyd]

Quoting Doug Anderson (2022-03-18 14:58:55)
> Hi,
>
> On Fri, Mar 18, 2022 at 1:17 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > > > > +       ret = dp_catalog_aux_wait_for_hpd_connect_state(aux->catalog);
> > > >
> > > > Why are we making aux transactions when hpd isn't asserted? Can we only
> > > > register the aux device once we know that state is "connected"? I'm
> > > > concerned that we're going to be possibly polling the connected bit up
> > > > to some amount of time (0x0003FFFF usecs?) for each aux transfer when
> > > > that doesn't make any sense to keep checking. We should be able to check
> > > > it once, register aux, and then when disconnect happens we can
> > > > unregister aux.
> > >
> > > This is for eDP and, unless someone wants to redesign it again, is
> > > just how it works.
> > >
> > > Specifically:
> > >
> > > 1. On eDP you _always_ report "connected". This is because when an eDP
> > > panel is turned off (but still there) you actually have no way to
> > > detect it--you just have to assume it's there. And thus you _always_
> > > register the AUX bus.
> >
> > Is reporting "connected" the same as HPD being asserted in the case of
> > eDP? I can understand wanting to report "connected", because as you say,
> > the panel is always connected; there aren't dongles or cables involved.
>
> No. What I mean by connected is that when DRM asks "hey, do you have a
> panel" connected then for eDP we always say "yes" regardless of any
> hardware state.
>
> HPD is a _huge_ misnomer for eDP and IMO the name causes lots of
> confusion. It's not "hot plug detect". You don't hot plug eDP. It's
> really "panel ready / panel IRQ"
>
>
> > But the state of the HPD pin is changing at runtime, and eDP supports
> > irq_hpd pulses from what I recall, for "link management".
> >
> > I think this device requires the status bit in the hardware to say it is
> > "connected" before aux transactions are guaranteed to work. Presumably
> > the HPD pin could go be asserted at the SoC's pad and there could be
> > some time still where the hardware status bit hasn't flipped over to
> > "connected" yet and thus aux transactions are going to fail. Can qcom
> > confirm this?
> >
> > >
> > > 2. When we are asked to read the EDID that happens _before_ the normal
> > > prepare/enable steps. The way that this should work is that the
> > > request travels down to the panel. The panel turns itself on (waiting
> > > for any hardcoded delays it knows about) and then initiates an AUX
> > > transaction. The AUX transaction is in charge of waiting for HPD.
> >
> > Are we talking about generic_edp_panel_probe()? Why doesn't that poll
> > hpd gpio like panel_edp_prepare_once() does?
>
> There's no HPD GPIO in this case, right?

Right. The hardware supports HPD here, so polling the pin as a gpio is
incorrect.

>
> In the trogdor case we ended up not using the HPD that was part of the
> ti-sn65dsi86 controller because it was fairly useless (it debounced
> for far too long), so we ended up hooking it up as a GPIO and I guess
> gave up on getting the extra notifications from the panel. Maybe a
> good thing, in hindsight, that we didn't do PSR because that might
> have been a pain.
>
> In any case, originally I had the GPIO being handled by the
> ti-sn65dsi86 controller driver and that seemed like it made sense to
> me (after all, the ti-sn65dsi86 driver would have to handle HPD if
> this went to the dedicated HPD pin) but got told "no, put it in the
> panel" by both you and Laurent [1].
>
> [1] https://lore.kernel.org/r/20200415203256.GP4758@pendragon.ideasonboard.com/
>
>
> > Are there any links to
> > discussions about this I can read?
>
> I'm not sure if there's any more than the conversation I pointed at
> above where we talked about hpd-gpios. Atop that, I believe I just
> realized that this was the only way it could work without re-designing
> again.
>
> To some extent the status quo is documented in commit a64ad9c3e4a5
> ("drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle
> HPD"). I wrote that commit when I thought about how HPD would need to
> be handled if it was a dedicated pin on the controller and the panel
> didn't have knowledge about it.
>
>
> > Pushing hpd state checking into aux
> > transactions looks like the wrong direction. Also, as I said up above I
> > am concerned that even checking the GPIO won't work and we need some way
> > to ask the bridge if HPD is asserted or not and then fallback to the
> > GPIO method if the display phy/controller doesn't have support to check
> > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
>
> If we could somehow get the HPD status from the bridge in the panel
> driver it definitely would be convenient. It does feel like that's an
> improvement that could be done later, though. We've already landed a
> few instances of doing what's done here, like for parade-ps8640 and
> analogix_dp. I suspect designing a new mechanism might not be the most
> trivial.

What is done in the bridge drivers is to wait for a fixed timeout and
assume aux is ready? Or is it something else? If there's just a fixed
timeout for the eDP case it sounds OK to do that for now and we can fine
tune it later to actually check HPD status register before the panel
tries to read EDID.

>
> I haven't actually tried it, but I suspect that to get something like
> what you're talking about we'd have to get the rest of drm to know
> that for eDP ports that it should assume something is connected
> _regardless_ of what the "detect" / "HPD" options say. Then we'd have
> to extend the edp-panel code to be able to be able to query the next
> bridge in the chain if a GPIO wasn't provided.

Can the panel interrogate the bridge chain somehow? It feels like either
something in the chain should know the status of HPD (the case here
where display controller in the SoC knows) or it should be a gpio to the
panel (trogdor case). The bridge ops can implement DRM_BRIDGE_OP_HPD and
the first bridge from the encoder that supports HPD can implement some
sort of "wait for hpd asserted" function that the panel then uses once
it powers up the panel during probe. If the panel has a gpio and nothing
else in the chain can detect hpd then the panel polls the gpio, or it
waits for the amount of time delay after powering on the panel if the
panel's hpd function is called.

>
>
> > > For the DP case this should not cause any significant overhead, right?
> > > HPD should always be asserted so this is basically just one extra IO
> > > read confirming that HPD is asserted which should be almost nothing...
> > > You're just about to do a whole bunch of IO reads/writes in order to
> > > program the AUX transaction anyway.
> >
> > In the DP case the dongle/cable can be disconnected in the middle of aux
> > transactions. If that happens we could be waiting a while in this
> > transfer function to timeout looking for the status bit. The driver
> > already gets an "unplug" irq when the cable is disconnected though so it
> > would be better to figure out a way to stop the aux transactions quickly
> > when that happens without having to read the hardware and poll the bit
> > that we already know is doomed to timeout. I think apple dongles throw
> > this logic for a loop though because the HDMI cable can be disconnected
> > from the dongle and then we don't see an "unplug" irq, just the number
> > of sinks becomes 0. Maybe there's an irq_hpd event, not sure.
>
> Ah, interesting. Having a DP cable unplugged in the middle of an aux
> transaction does seem like it could be a problem. What if we just wait
> in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
> be easy, right?

Sounds like it would work. Is this supposed to fix some DP case as well
though? There were some patches to speed up aux failures when the dongle
was unplugged but I haven't checked after that. I guess this waiting is
only important for eDP because the edp-panel code is trying to read EDID
and it isn't waiting for HPD to be asserted before doing that.

>
>
> > > > > +       if (ret) {
> > > > > +               DRM_DEBUG_DP("DP sink not ready for aux transactions\n");
> > > > > +               goto exit;
> > > > > +       }
> > > > > +
> > > > >         dp_aux_update_offset_and_segment(aux, msg);
> > > > >         dp_aux_transfer_helper(aux, msg, true);
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > index fac815f..2c3b0f7 100644
> > > > > --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> > > > > @@ -242,6 +242,29 @@ void dp_catalog_aux_update_cfg(struct dp_catalog *dp_catalog)
> > > > >         phy_calibrate(phy);
> > > > >  }
> > > > >
> > > > > +int dp_catalog_aux_wait_for_hpd_connect_state(struct dp_catalog *dp_catalog)
> > > > > +{
> > > > > +       u32 state, hpd_en, timeout;
> > > > > +       struct dp_catalog_private *catalog = container_of(dp_catalog,
> > > > > +                               struct dp_catalog_private, dp_catalog);
> > > > > +
> > > > > +       hpd_en = dp_read_aux(catalog, REG_DP_DP_HPD_CTRL) &
> > > > > +                                       DP_DP_HPD_CTRL_HPD_EN;
> > > >
> > > > Use two lines
> > > >
> > > >         hpd_en = dp_read_aux();
> > > >         hpd_en &= DP_DP_HPD_CTRL_HPD_EN;
> > > >
> > > > > +
> > > > > +       /* no-hpd case */
> > > > > +       if (!hpd_en)
> > > > > +               return 0;
> > >
> > > I guess reading from hardware is fine, but I would have expected the
> > > driver to simply know whether HPD is used or not. Don't need to read
> > > it from hardware, do we? It's not like it's changing from minute to
> > > minute--this is something known at probe time.
> >
> > Are you saying that HPD is always asserted?
>
> I don't think this is looking for HPD assertion, is it? This is
> looking for whether the HPD interrupt is enabled, isn't it? This is to
> support the case of eDP panels where we didn't hook the HPD line up,
> right? It should be known at probe time whether we've hooked HPD up or
> not. ...or am I misreading?

Ah right. This is basically a proxy for "is no-hpd present in DT?" per
the last patch in this series.

>
>
> > That doesn't sound right.
> > My understanding is that HPD will be asserted after the panel is powered
> > up. Before that HPD is deasserted. Similarly, when we power down the
> > panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> > panel is always connected? That sounds like it might be OK as long as
> > userspace doesn't use "connected" to know that it's OK to do things like
> > read/write aux or push pixels to the panel when HPD is deasserted.
>
> IMO having userspace reading / writing aux directly and expecting it
> to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> case, but it's really not good in the eDP case. To me it's sorta like
> expecting things to be amazing and foolproof when you go behind the
> kernel's back and write to an i2c device using `i2cset -f`. Sure, it
> might work, but it can also confuse the heck out of things. It also
> turns out to be a huge problem when you get to PSR because userspace
> will get errors if it tries to write to the AUX channel and the panel
> is in PSR mode. This came up in the context of Brian's analogix dp
> patches [1]. The right answer, in my mind, is to treat userspace
> accessing the AUX channel directly as more of a debug feature, at
> least for eDP panels.

If it's a debug feature then it should be removed from the system. The
flow of data is passing through the kernel so if the kernel is getting
confused about backdoor access over aux it should snoop the transactions
and block things it doesn't like. I don't know the backstory on aux
being exposed to userspace, but leaving it in a broken state isn't good.

>
> In terms of userspace pushing pixels to the panel, I don't think
> that's quite the same, is it? Generally userspace is in charge of
> whether the eDP panel is powered on or powered off, isn't it?

I'm not sure what it's the same as, but I meant drawing on the screen
when the display is powering on but not visible yet is concerning.
drm_helper_hpd_irq_event() is used to tell userspace that it can "start
drawing now" because it calls drm_kms_helper_hotplug_event() when the
connector status changes. This is my understanding of how the DP path
works in this driver. I don't know how it works for eDP bridge drivers.

>
> So generally I think that for eDP a panel is always "connected" in all
> senses of the word. It might not be "powered" at some given point of
> time, but it's always connected.
>
> [1] https://lore.kernel.org/r/CAD=FV=VYe1rLKANQ8eom7g8x1v6_s_OYnX819Ax4m7O3UwDHmg@mail.gmail.com/
>

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> > > Pushing hpd state checking into aux
> > > transactions looks like the wrong direction. Also, as I said up above I
> > > am concerned that even checking the GPIO won't work and we need some way
> > > to ask the bridge if HPD is asserted or not and then fallback to the
> > > GPIO method if the display phy/controller doesn't have support to check
> > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> >
> > If we could somehow get the HPD status from the bridge in the panel
> > driver it definitely would be convenient. It does feel like that's an
> > improvement that could be done later, though. We've already landed a
> > few instances of doing what's done here, like for parade-ps8640 and
> > analogix_dp. I suspect designing a new mechanism might not be the most
> > trivial.
>
> What is done in the bridge drivers is to wait for a fixed timeout and
> assume aux is ready? Or is it something else? If there's just a fixed
> timeout for the eDP case it sounds OK to do that for now and we can fine
> tune it later to actually check HPD status register before the panel
> tries to read EDID.

Right. For the parade chip (which is only used for eDP as far as I
know--never DP) waits for up to 200 ms. See ps8640_ensure_hpd().

So I guess tl;dr to Sankeerth that it's OK for his patch to have the
wait in the aux transfer function, but only for eDP. Other discussions
here are about how we could make it better in future patches.


> > I haven't actually tried it, but I suspect that to get something like
> > what you're talking about we'd have to get the rest of drm to know
> > that for eDP ports that it should assume something is connected
> > _regardless_ of what the "detect" / "HPD" options say. Then we'd have
> > to extend the edp-panel code to be able to be able to query the next
> > bridge in the chain if a GPIO wasn't provided.
>
> Can the panel interrogate the bridge chain somehow? It feels like either
> something in the chain should know the status of HPD (the case here
> where display controller in the SoC knows) or it should be a gpio to the
> panel (trogdor case). The bridge ops can implement DRM_BRIDGE_OP_HPD and
> the first bridge from the encoder that supports HPD can implement some
> sort of "wait for hpd asserted" function that the panel then uses once
> it powers up the panel during probe. If the panel has a gpio and nothing
> else in the chain can detect hpd then the panel polls the gpio, or it
> waits for the amount of time delay after powering on the panel if the
> panel's hpd function is called.

Yeah, there ought to be some way to make something like that work. I
don't think it's just DRM_BRIDGE_OP_HPD, though, for a few reasons:

1. That operation actually specifically means that HPD can cause an
interrupt and that the bridge promises to call drm_bridge_hpd_notify()
when the interrupt occurs. It seems to work hand-in-hand with
"DRM_BRIDGE_OP_DETECT". I know it's legit to advertise "detect"
without "HPD" (you have an HPD line that can be polled but not cause
interrupts) but I'd have to research whether it's legal to advertise
"HPD" without "detect".

2. If it were up to me, I'd rather avoid conflating what we need with
the existing "HPD" and "DETECT" ops. While the line is called "HPD" in
the eDP spec, what we're looking for here is really a different
concept. eDP panels are never hot plugged and are always present, so
I'd personally rather it be a new OP like "OP_PANEL_READY". Of course,
in whatever future patch we could always debate this.

3. The main reason I'd prefer a different op is that I think using the
existing ops will confuse DRM (not just because I'm being pedantic).
If DRM sees that the eDP controller driver advertises that it can
"detect" and support "hpd" then it will use these functions to decide
whether it should start turning on the panel. ...and it won't even try
using the panel until one is detected, right? ...but that means that
it won't be powered on and will never be detected. ;-) This is what
I'm trying to get at: it's a different concept. The panel is always
there and never hotplugged. The existing DRM ops (IMO) are for knowing
whether a panel is physically present. For eDP the answer is always a
resounding "yes", even if we have no actual evidence (because we can't
gather evidence for an "off" panel). On eDP the HPD line simply means
something different than on DP.


> > > > For the DP case this should not cause any significant overhead, right?
> > > > HPD should always be asserted so this is basically just one extra IO
> > > > read confirming that HPD is asserted which should be almost nothing...
> > > > You're just about to do a whole bunch of IO reads/writes in order to
> > > > program the AUX transaction anyway.
> > >
> > > In the DP case the dongle/cable can be disconnected in the middle of aux
> > > transactions. If that happens we could be waiting a while in this
> > > transfer function to timeout looking for the status bit. The driver
> > > already gets an "unplug" irq when the cable is disconnected though so it
> > > would be better to figure out a way to stop the aux transactions quickly
> > > when that happens without having to read the hardware and poll the bit
> > > that we already know is doomed to timeout. I think apple dongles throw
> > > this logic for a loop though because the HDMI cable can be disconnected
> > > from the dongle and then we don't see an "unplug" irq, just the number
> > > of sinks becomes 0. Maybe there's an irq_hpd event, not sure.
> >
> > Ah, interesting. Having a DP cable unplugged in the middle of an aux
> > transaction does seem like it could be a problem. What if we just wait
> > in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
> > be easy, right?
>
> Sounds like it would work. Is this supposed to fix some DP case as well
> though? There were some patches to speed up aux failures when the dongle
> was unplugged but I haven't checked after that. I guess this waiting is
> only important for eDP because the edp-panel code is trying to read EDID
> and it isn't waiting for HPD to be asserted before doing that.

Right, I think this is only important for eDP.


> > > That doesn't sound right.
> > > My understanding is that HPD will be asserted after the panel is powered
> > > up. Before that HPD is deasserted. Similarly, when we power down the
> > > panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> > > panel is always connected? That sounds like it might be OK as long as
> > > userspace doesn't use "connected" to know that it's OK to do things like
> > > read/write aux or push pixels to the panel when HPD is deasserted.
> >
> > IMO having userspace reading / writing aux directly and expecting it
> > to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> > case, but it's really not good in the eDP case. To me it's sorta like
> > expecting things to be amazing and foolproof when you go behind the
> > kernel's back and write to an i2c device using `i2cset -f`. Sure, it
> > might work, but it can also confuse the heck out of things. It also
> > turns out to be a huge problem when you get to PSR because userspace
> > will get errors if it tries to write to the AUX channel and the panel
> > is in PSR mode. This came up in the context of Brian's analogix dp
> > patches [1]. The right answer, in my mind, is to treat userspace
> > accessing the AUX channel directly as more of a debug feature, at
> > least for eDP panels.
>
> If it's a debug feature then it should be removed from the system. The
> flow of data is passing through the kernel so if the kernel is getting
> confused about backdoor access over aux it should snoop the transactions
> and block things it doesn't like. I don't know the backstory on aux
> being exposed to userspace, but leaving it in a broken state isn't good.

Agreed, it's not a great situation. :(

-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> > > Pushing hpd state checking into aux
> > > transactions looks like the wrong direction. Also, as I said up above I
> > > am concerned that even checking the GPIO won't work and we need some way
> > > to ask the bridge if HPD is asserted or not and then fallback to the
> > > GPIO method if the display phy/controller doesn't have support to check
> > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> >
> > If we could somehow get the HPD status from the bridge in the panel
> > driver it definitely would be convenient. It does feel like that's an
> > improvement that could be done later, though. We've already landed a
> > few instances of doing what's done here, like for parade-ps8640 and
> > analogix_dp. I suspect designing a new mechanism might not be the most
> > trivial.
>
> What is done in the bridge drivers is to wait for a fixed timeout and
> assume aux is ready? Or is it something else? If there's just a fixed
> timeout for the eDP case it sounds OK to do that for now and we can fine
> tune it later to actually check HPD status register before the panel
> tries to read EDID.

Right. For the parade chip (which is only used for eDP as far as I
know--never DP) waits for up to 200 ms. See ps8640_ensure_hpd().

So I guess tl;dr to Sankeerth that it's OK for his patch to have the
wait in the aux transfer function, but only for eDP. Other discussions
here are about how we could make it better in future patches.


> > I haven't actually tried it, but I suspect that to get something like
> > what you're talking about we'd have to get the rest of drm to know
> > that for eDP ports that it should assume something is connected
> > _regardless_ of what the "detect" / "HPD" options say. Then we'd have
> > to extend the edp-panel code to be able to be able to query the next
> > bridge in the chain if a GPIO wasn't provided.
>
> Can the panel interrogate the bridge chain somehow? It feels like either
> something in the chain should know the status of HPD (the case here
> where display controller in the SoC knows) or it should be a gpio to the
> panel (trogdor case). The bridge ops can implement DRM_BRIDGE_OP_HPD and
> the first bridge from the encoder that supports HPD can implement some
> sort of "wait for hpd asserted" function that the panel then uses once
> it powers up the panel during probe. If the panel has a gpio and nothing
> else in the chain can detect hpd then the panel polls the gpio, or it
> waits for the amount of time delay after powering on the panel if the
> panel's hpd function is called.

Yeah, there ought to be some way to make something like that work. I
don't think it's just DRM_BRIDGE_OP_HPD, though, for a few reasons:

1. That operation actually specifically means that HPD can cause an
interrupt and that the bridge promises to call drm_bridge_hpd_notify()
when the interrupt occurs. It seems to work hand-in-hand with
"DRM_BRIDGE_OP_DETECT". I know it's legit to advertise "detect"
without "HPD" (you have an HPD line that can be polled but not cause
interrupts) but I'd have to research whether it's legal to advertise
"HPD" without "detect".

2. If it were up to me, I'd rather avoid conflating what we need with
the existing "HPD" and "DETECT" ops. While the line is called "HPD" in
the eDP spec, what we're looking for here is really a different
concept. eDP panels are never hot plugged and are always present, so
I'd personally rather it be a new OP like "OP_PANEL_READY". Of course,
in whatever future patch we could always debate this.

3. The main reason I'd prefer a different op is that I think using the
existing ops will confuse DRM (not just because I'm being pedantic).
If DRM sees that the eDP controller driver advertises that it can
"detect" and support "hpd" then it will use these functions to decide
whether it should start turning on the panel. ...and it won't even try
using the panel until one is detected, right? ...but that means that
it won't be powered on and will never be detected. ;-) This is what
I'm trying to get at: it's a different concept. The panel is always
there and never hotplugged. The existing DRM ops (IMO) are for knowing
whether a panel is physically present. For eDP the answer is always a
resounding "yes", even if we have no actual evidence (because we can't
gather evidence for an "off" panel). On eDP the HPD line simply means
something different than on DP.


> > > > For the DP case this should not cause any significant overhead, right?
> > > > HPD should always be asserted so this is basically just one extra IO
> > > > read confirming that HPD is asserted which should be almost nothing...
> > > > You're just about to do a whole bunch of IO reads/writes in order to
> > > > program the AUX transaction anyway.
> > >
> > > In the DP case the dongle/cable can be disconnected in the middle of aux
> > > transactions. If that happens we could be waiting a while in this
> > > transfer function to timeout looking for the status bit. The driver
> > > already gets an "unplug" irq when the cable is disconnected though so it
> > > would be better to figure out a way to stop the aux transactions quickly
> > > when that happens without having to read the hardware and poll the bit
> > > that we already know is doomed to timeout. I think apple dongles throw
> > > this logic for a loop though because the HDMI cable can be disconnected
> > > from the dongle and then we don't see an "unplug" irq, just the number
> > > of sinks becomes 0. Maybe there's an irq_hpd event, not sure.
> >
> > Ah, interesting. Having a DP cable unplugged in the middle of an aux
> > transaction does seem like it could be a problem. What if we just wait
> > in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"? That should
> > be easy, right?
>
> Sounds like it would work. Is this supposed to fix some DP case as well
> though? There were some patches to speed up aux failures when the dongle
> was unplugged but I haven't checked after that. I guess this waiting is
> only important for eDP because the edp-panel code is trying to read EDID
> and it isn't waiting for HPD to be asserted before doing that.

Right, I think this is only important for eDP.


> > > That doesn't sound right.
> > > My understanding is that HPD will be asserted after the panel is powered
> > > up. Before that HPD is deasserted. Similarly, when we power down the
> > > panel, HPD will be deasserted. I guess DRM wants to assume that an eDP
> > > panel is always connected? That sounds like it might be OK as long as
> > > userspace doesn't use "connected" to know that it's OK to do things like
> > > read/write aux or push pixels to the panel when HPD is deasserted.
> >
> > IMO having userspace reading / writing aux directly and expecting it
> > to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> > case, but it's really not good in the eDP case. To me it's sorta like
> > expecting things to be amazing and foolproof when you go behind the
> > kernel's back and write to an i2c device using `i2cset -f`. Sure, it
> > might work, but it can also confuse the heck out of things. It also
> > turns out to be a huge problem when you get to PSR because userspace
> > will get errors if it tries to write to the AUX channel and the panel
> > is in PSR mode. This came up in the context of Brian's analogix dp
> > patches [1]. The right answer, in my mind, is to treat userspace
> > accessing the AUX channel directly as more of a debug feature, at
> > least for eDP panels.
>
> If it's a debug feature then it should be removed from the system. The
> flow of data is passing through the kernel so if the kernel is getting
> confused about backdoor access over aux it should snoop the transactions
> and block things it doesn't like. I don't know the backstory on aux
> being exposed to userspace, but leaving it in a broken state isn't good.

Agreed, it's not a great situation. :(

-Doug

RE: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Saturday, March 19, 2022 5:26 AM
> To: Stephen Boyd <swboyd@chromium.org>
> Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; dri-devel <dri-devel@lists.freedesktop.org>;
> freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob Clark
> <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>;
> quic_kalyant <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> interaction
> 
> Hi,
> 
> On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> wrote:
> >
> > > > Pushing hpd state checking into aux transactions looks like the
> > > > wrong direction. Also, as I said up above I am concerned that even
> > > > checking the GPIO won't work and we need some way to ask the
> > > > bridge if HPD is asserted or not and then fallback to the GPIO
> > > > method if the display phy/controller doesn't have support to check
> > > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> > >
> > > If we could somehow get the HPD status from the bridge in the panel
> > > driver it definitely would be convenient. It does feel like that's
> > > an improvement that could be done later, though. We've already
> > > landed a few instances of doing what's done here, like for
> > > parade-ps8640 and analogix_dp. I suspect designing a new mechanism
> > > might not be the most trivial.
> >
> > What is done in the bridge drivers is to wait for a fixed timeout and
> > assume aux is ready? Or is it something else? If there's just a fixed
> > timeout for the eDP case it sounds OK to do that for now and we can
> > fine tune it later to actually check HPD status register before the
> > panel tries to read EDID.
> 
> Right. For the parade chip (which is only used for eDP as far as I know--never
> DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> 
> So I guess tl;dr to Sankeerth that it's OK for his patch to have the wait in the
> aux transfer function, but only for eDP. Other discussions here are about
> how we could make it better in future patches.
> 
> 

The aux transactions for external DP are initiated by the dp_display driver only after the
display is hot plugged to the connector. The phy_init is necessary for the aux transactions
to take place. So, for the DP case, like Doug mentioned below, this patch is introducing
an overhead of three register reads to detect hpd_high before performing aux transactions.
So, we felt this was okay to do for DP.

On the other hand, for eDP, it is necessary to wait for panel ready through this hpd connect status.
Currently there is no way to know which type of connector it is in the dp_aux sub-module.

However, as the discussion suggested, to have the wait only for eDP, I am thinking to pass the
connector_type information to aux sub-module and register different aux_transfer functions
for eDP and DP. The eDP transfer function will wait for hpd_high and the DP transfer function
will be same as the one before this patch.

What do you think?

> > > I haven't actually tried it, but I suspect that to get something
> > > like what you're talking about we'd have to get the rest of drm to
> > > know that for eDP ports that it should assume something is connected
> > > _regardless_ of what the "detect" / "HPD" options say. Then we'd
> > > have to extend the edp-panel code to be able to be able to query the
> > > next bridge in the chain if a GPIO wasn't provided.
> >
> > Can the panel interrogate the bridge chain somehow? It feels like
> > either something in the chain should know the status of HPD (the case
> > here where display controller in the SoC knows) or it should be a gpio
> > to the panel (trogdor case). The bridge ops can implement
> > DRM_BRIDGE_OP_HPD and the first bridge from the encoder that supports
> > HPD can implement some sort of "wait for hpd asserted" function that
> > the panel then uses once it powers up the panel during probe. If the
> > panel has a gpio and nothing else in the chain can detect hpd then the
> > panel polls the gpio, or it waits for the amount of time delay after
> > powering on the panel if the panel's hpd function is called.
> 
> Yeah, there ought to be some way to make something like that work. I don't
> think it's just DRM_BRIDGE_OP_HPD, though, for a few reasons:
> 
> 1. That operation actually specifically means that HPD can cause an interrupt
> and that the bridge promises to call drm_bridge_hpd_notify() when the
> interrupt occurs. It seems to work hand-in-hand with
> "DRM_BRIDGE_OP_DETECT". I know it's legit to advertise "detect"
> without "HPD" (you have an HPD line that can be polled but not cause
> interrupts) but I'd have to research whether it's legal to advertise "HPD"
> without "detect".
> 
> 2. If it were up to me, I'd rather avoid conflating what we need with the
> existing "HPD" and "DETECT" ops. While the line is called "HPD" in the eDP
> spec, what we're looking for here is really a different concept. eDP panels are
> never hot plugged and are always present, so I'd personally rather it be a
> new OP like "OP_PANEL_READY". Of course, in whatever future patch we
> could always debate this.
> 
> 3. The main reason I'd prefer a different op is that I think using the existing
> ops will confuse DRM (not just because I'm being pedantic).
> If DRM sees that the eDP controller driver advertises that it can "detect" and
> support "hpd" then it will use these functions to decide whether it should
> start turning on the panel. ...and it won't even try using the panel until one is
> detected, right? ...but that means that it won't be powered on and will never
> be detected. ;-) This is what I'm trying to get at: it's a different concept. The
> panel is always there and never hotplugged. The existing DRM ops (IMO) are
> for knowing whether a panel is physically present. For eDP the answer is
> always a resounding "yes", even if we have no actual evidence (because we
> can't gather evidence for an "off" panel). On eDP the HPD line simply means
> something different than on DP.
> 
> 
> > > > > For the DP case this should not cause any significant overhead, right?
> > > > > HPD should always be asserted so this is basically just one
> > > > > extra IO read confirming that HPD is asserted which should be almost
> nothing...
> > > > > You're just about to do a whole bunch of IO reads/writes in
> > > > > order to program the AUX transaction anyway.
> > > >
> > > > In the DP case the dongle/cable can be disconnected in the middle
> > > > of aux transactions. If that happens we could be waiting a while
> > > > in this transfer function to timeout looking for the status bit.
> > > > The driver already gets an "unplug" irq when the cable is
> > > > disconnected though so it would be better to figure out a way to
> > > > stop the aux transactions quickly when that happens without having
> > > > to read the hardware and poll the bit that we already know is
> > > > doomed to timeout. I think apple dongles throw this logic for a
> > > > loop though because the HDMI cable can be disconnected from the
> > > > dongle and then we don't see an "unplug" irq, just the number of sinks
> becomes 0. Maybe there's an irq_hpd event, not sure.
> > >
> > > Ah, interesting. Having a DP cable unplugged in the middle of an aux
> > > transaction does seem like it could be a problem. What if we just
> > > wait in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"?
> That
> > > should be easy, right?
> >
> > Sounds like it would work. Is this supposed to fix some DP case as
> > well though? There were some patches to speed up aux failures when the
> > dongle was unplugged but I haven't checked after that. I guess this
> > waiting is only important for eDP because the edp-panel code is trying
> > to read EDID and it isn't waiting for HPD to be asserted before doing that.
> 
> Right, I think this is only important for eDP.
> 
> 
> > > > That doesn't sound right.
> > > > My understanding is that HPD will be asserted after the panel is
> > > > powered up. Before that HPD is deasserted. Similarly, when we
> > > > power down the panel, HPD will be deasserted. I guess DRM wants to
> > > > assume that an eDP panel is always connected? That sounds like it
> > > > might be OK as long as userspace doesn't use "connected" to know
> > > > that it's OK to do things like read/write aux or push pixels to the panel
> when HPD is deasserted.
> > >
> > > IMO having userspace reading / writing aux directly and expecting it
> > > to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> > > case, but it's really not good in the eDP case. To me it's sorta
> > > like expecting things to be amazing and foolproof when you go behind
> > > the kernel's back and write to an i2c device using `i2cset -f`.
> > > Sure, it might work, but it can also confuse the heck out of things.
> > > It also turns out to be a huge problem when you get to PSR because
> > > userspace will get errors if it tries to write to the AUX channel
> > > and the panel is in PSR mode. This came up in the context of Brian's
> > > analogix dp patches [1]. The right answer, in my mind, is to treat
> > > userspace accessing the AUX channel directly as more of a debug
> > > feature, at least for eDP panels.
> >
> > If it's a debug feature then it should be removed from the system. The
> > flow of data is passing through the kernel so if the kernel is getting
> > confused about backdoor access over aux it should snoop the
> > transactions and block things it doesn't like. I don't know the
> > backstory on aux being exposed to userspace, but leaving it in a broken
> state isn't good.
> 
> Agreed, it's not a great situation. :(
> 
> -Doug

RE: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti (QUIC)]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Saturday, March 19, 2022 5:26 AM
> To: Stephen Boyd <swboyd@chromium.org>
> Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; dri-devel <dri-devel@lists.freedesktop.org>;
> freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob Clark
> <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>;
> quic_kalyant <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> interaction
> 
> Hi,
> 
> On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> wrote:
> >
> > > > Pushing hpd state checking into aux transactions looks like the
> > > > wrong direction. Also, as I said up above I am concerned that even
> > > > checking the GPIO won't work and we need some way to ask the
> > > > bridge if HPD is asserted or not and then fallback to the GPIO
> > > > method if the display phy/controller doesn't have support to check
> > > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> > >
> > > If we could somehow get the HPD status from the bridge in the panel
> > > driver it definitely would be convenient. It does feel like that's
> > > an improvement that could be done later, though. We've already
> > > landed a few instances of doing what's done here, like for
> > > parade-ps8640 and analogix_dp. I suspect designing a new mechanism
> > > might not be the most trivial.
> >
> > What is done in the bridge drivers is to wait for a fixed timeout and
> > assume aux is ready? Or is it something else? If there's just a fixed
> > timeout for the eDP case it sounds OK to do that for now and we can
> > fine tune it later to actually check HPD status register before the
> > panel tries to read EDID.
> 
> Right. For the parade chip (which is only used for eDP as far as I know--never
> DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> 
> So I guess tl;dr to Sankeerth that it's OK for his patch to have the wait in the
> aux transfer function, but only for eDP. Other discussions here are about
> how we could make it better in future patches.
> 
> 

The aux transactions for external DP are initiated by the dp_display driver only after the
display is hot plugged to the connector. The phy_init is necessary for the aux transactions
to take place. So, for the DP case, like Doug mentioned below, this patch is introducing
an overhead of three register reads to detect hpd_high before performing aux transactions.
So, we felt this was okay to do for DP.

On the other hand, for eDP, it is necessary to wait for panel ready through this hpd connect status.
Currently there is no way to know which type of connector it is in the dp_aux sub-module.

However, as the discussion suggested, to have the wait only for eDP, I am thinking to pass the
connector_type information to aux sub-module and register different aux_transfer functions
for eDP and DP. The eDP transfer function will wait for hpd_high and the DP transfer function
will be same as the one before this patch.

What do you think?

> > > I haven't actually tried it, but I suspect that to get something
> > > like what you're talking about we'd have to get the rest of drm to
> > > know that for eDP ports that it should assume something is connected
> > > _regardless_ of what the "detect" / "HPD" options say. Then we'd
> > > have to extend the edp-panel code to be able to be able to query the
> > > next bridge in the chain if a GPIO wasn't provided.
> >
> > Can the panel interrogate the bridge chain somehow? It feels like
> > either something in the chain should know the status of HPD (the case
> > here where display controller in the SoC knows) or it should be a gpio
> > to the panel (trogdor case). The bridge ops can implement
> > DRM_BRIDGE_OP_HPD and the first bridge from the encoder that supports
> > HPD can implement some sort of "wait for hpd asserted" function that
> > the panel then uses once it powers up the panel during probe. If the
> > panel has a gpio and nothing else in the chain can detect hpd then the
> > panel polls the gpio, or it waits for the amount of time delay after
> > powering on the panel if the panel's hpd function is called.
> 
> Yeah, there ought to be some way to make something like that work. I don't
> think it's just DRM_BRIDGE_OP_HPD, though, for a few reasons:
> 
> 1. That operation actually specifically means that HPD can cause an interrupt
> and that the bridge promises to call drm_bridge_hpd_notify() when the
> interrupt occurs. It seems to work hand-in-hand with
> "DRM_BRIDGE_OP_DETECT". I know it's legit to advertise "detect"
> without "HPD" (you have an HPD line that can be polled but not cause
> interrupts) but I'd have to research whether it's legal to advertise "HPD"
> without "detect".
> 
> 2. If it were up to me, I'd rather avoid conflating what we need with the
> existing "HPD" and "DETECT" ops. While the line is called "HPD" in the eDP
> spec, what we're looking for here is really a different concept. eDP panels are
> never hot plugged and are always present, so I'd personally rather it be a
> new OP like "OP_PANEL_READY". Of course, in whatever future patch we
> could always debate this.
> 
> 3. The main reason I'd prefer a different op is that I think using the existing
> ops will confuse DRM (not just because I'm being pedantic).
> If DRM sees that the eDP controller driver advertises that it can "detect" and
> support "hpd" then it will use these functions to decide whether it should
> start turning on the panel. ...and it won't even try using the panel until one is
> detected, right? ...but that means that it won't be powered on and will never
> be detected. ;-) This is what I'm trying to get at: it's a different concept. The
> panel is always there and never hotplugged. The existing DRM ops (IMO) are
> for knowing whether a panel is physically present. For eDP the answer is
> always a resounding "yes", even if we have no actual evidence (because we
> can't gather evidence for an "off" panel). On eDP the HPD line simply means
> something different than on DP.
> 
> 
> > > > > For the DP case this should not cause any significant overhead, right?
> > > > > HPD should always be asserted so this is basically just one
> > > > > extra IO read confirming that HPD is asserted which should be almost
> nothing...
> > > > > You're just about to do a whole bunch of IO reads/writes in
> > > > > order to program the AUX transaction anyway.
> > > >
> > > > In the DP case the dongle/cable can be disconnected in the middle
> > > > of aux transactions. If that happens we could be waiting a while
> > > > in this transfer function to timeout looking for the status bit.
> > > > The driver already gets an "unplug" irq when the cable is
> > > > disconnected though so it would be better to figure out a way to
> > > > stop the aux transactions quickly when that happens without having
> > > > to read the hardware and poll the bit that we already know is
> > > > doomed to timeout. I think apple dongles throw this logic for a
> > > > loop though because the HDMI cable can be disconnected from the
> > > > dongle and then we don't see an "unplug" irq, just the number of sinks
> becomes 0. Maybe there's an irq_hpd event, not sure.
> > >
> > > Ah, interesting. Having a DP cable unplugged in the middle of an aux
> > > transaction does seem like it could be a problem. What if we just
> > > wait in the case our bridge.type is "DRM_MODE_CONNECTOR_eDP"?
> That
> > > should be easy, right?
> >
> > Sounds like it would work. Is this supposed to fix some DP case as
> > well though? There were some patches to speed up aux failures when the
> > dongle was unplugged but I haven't checked after that. I guess this
> > waiting is only important for eDP because the edp-panel code is trying
> > to read EDID and it isn't waiting for HPD to be asserted before doing that.
> 
> Right, I think this is only important for eDP.
> 
> 
> > > > That doesn't sound right.
> > > > My understanding is that HPD will be asserted after the panel is
> > > > powered up. Before that HPD is deasserted. Similarly, when we
> > > > power down the panel, HPD will be deasserted. I guess DRM wants to
> > > > assume that an eDP panel is always connected? That sounds like it
> > > > might be OK as long as userspace doesn't use "connected" to know
> > > > that it's OK to do things like read/write aux or push pixels to the panel
> when HPD is deasserted.
> > >
> > > IMO having userspace reading / writing aux directly and expecting it
> > > to work is a terrible idea anyway. It's _maybe_ sorta OK in the DP
> > > case, but it's really not good in the eDP case. To me it's sorta
> > > like expecting things to be amazing and foolproof when you go behind
> > > the kernel's back and write to an i2c device using `i2cset -f`.
> > > Sure, it might work, but it can also confuse the heck out of things.
> > > It also turns out to be a huge problem when you get to PSR because
> > > userspace will get errors if it tries to write to the AUX channel
> > > and the panel is in PSR mode. This came up in the context of Brian's
> > > analogix dp patches [1]. The right answer, in my mind, is to treat
> > > userspace accessing the AUX channel directly as more of a debug
> > > feature, at least for eDP panels.
> >
> > If it's a debug feature then it should be removed from the system. The
> > flow of data is passing through the kernel so if the kernel is getting
> > confused about backdoor access over aux it should snoop the
> > transactions and block things it doesn't like. I don't know the
> > backstory on aux being exposed to userspace, but leaving it in a broken
> state isn't good.
> 
> Agreed, it's not a great situation. :(
> 
> -Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 8:54 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Doug Anderson <dianders@chromium.org>
> > Sent: Saturday, March 19, 2022 5:26 AM
> > To: Stephen Boyd <swboyd@chromium.org>
> > Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open list:OPEN
> > FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > <devicetree@vger.kernel.org>; dri-devel <dri-devel@lists.freedesktop.org>;
> > freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> > msm@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob Clark
> > <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>;
> > quic_kalyant <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> > <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> > Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> > interaction
> >
> > Hi,
> >
> > On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> > wrote:
> > >
> > > > > Pushing hpd state checking into aux transactions looks like the
> > > > > wrong direction. Also, as I said up above I am concerned that even
> > > > > checking the GPIO won't work and we need some way to ask the
> > > > > bridge if HPD is asserted or not and then fallback to the GPIO
> > > > > method if the display phy/controller doesn't have support to check
> > > > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> > > >
> > > > If we could somehow get the HPD status from the bridge in the panel
> > > > driver it definitely would be convenient. It does feel like that's
> > > > an improvement that could be done later, though. We've already
> > > > landed a few instances of doing what's done here, like for
> > > > parade-ps8640 and analogix_dp. I suspect designing a new mechanism
> > > > might not be the most trivial.
> > >
> > > What is done in the bridge drivers is to wait for a fixed timeout and
> > > assume aux is ready? Or is it something else? If there's just a fixed
> > > timeout for the eDP case it sounds OK to do that for now and we can
> > > fine tune it later to actually check HPD status register before the
> > > panel tries to read EDID.
> >
> > Right. For the parade chip (which is only used for eDP as far as I know--never
> > DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> >
> > So I guess tl;dr to Sankeerth that it's OK for his patch to have the wait in the
> > aux transfer function, but only for eDP. Other discussions here are about
> > how we could make it better in future patches.
> >
> >
>
> The aux transactions for external DP are initiated by the dp_display driver only after the
> display is hot plugged to the connector. The phy_init is necessary for the aux transactions
> to take place. So, for the DP case, like Doug mentioned below, this patch is introducing
> an overhead of three register reads to detect hpd_high before performing aux transactions.
> So, we felt this was okay to do for DP.

Personally I'm not that upset about the 3 register reads. The problem
Stephen pointed out is bigger. It's possible that a DP cable is
unplugged _just_ as we started an AUX transaction. In that case we'll
have a big delay here when we don't actually need one.


> On the other hand, for eDP, it is necessary to wait for panel ready through this hpd connect status.
> Currently there is no way to know which type of connector it is in the dp_aux sub-module.
>
> However, as the discussion suggested, to have the wait only for eDP, I am thinking to pass the
> connector_type information to aux sub-module and register different aux_transfer functions
> for eDP and DP. The eDP transfer function will wait for hpd_high and the DP transfer function
> will be same as the one before this patch.

Personally I wouldn't register two separate functions. You could just
store a boolean in your structure and only wait for HPD if this is
eDP. One extra "if" test doesn't seem like it justifies splitting off
into two functions...

-Doug

Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Doug Anderson]

Hi,

On Fri, Mar 25, 2022 at 8:54 AM Sankeerth Billakanti (QUIC)
<quic_sbillaka@quicinc.com> wrote:
>
> > -----Original Message-----
> > From: Doug Anderson <dianders@chromium.org>
> > Sent: Saturday, March 19, 2022 5:26 AM
> > To: Stephen Boyd <swboyd@chromium.org>
> > Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open list:OPEN
> > FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > <devicetree@vger.kernel.org>; dri-devel <dri-devel@lists.freedesktop.org>;
> > freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm <linux-arm-
> > msm@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org>; Rob Clark
> > <robdclark@gmail.com>; Sean Paul <seanpaul@chromium.org>;
> > quic_kalyant <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> > <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > dmitry.baryshkov@linaro.org; quic_vproddut <quic_vproddut@quicinc.com>
> > Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> > interaction
> >
> > Hi,
> >
> > On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> > wrote:
> > >
> > > > > Pushing hpd state checking into aux transactions looks like the
> > > > > wrong direction. Also, as I said up above I am concerned that even
> > > > > checking the GPIO won't work and we need some way to ask the
> > > > > bridge if HPD is asserted or not and then fallback to the GPIO
> > > > > method if the display phy/controller doesn't have support to check
> > > > > HPD internally. Something on top of DRM_BRIDGE_OP_HPD?
> > > >
> > > > If we could somehow get the HPD status from the bridge in the panel
> > > > driver it definitely would be convenient. It does feel like that's
> > > > an improvement that could be done later, though. We've already
> > > > landed a few instances of doing what's done here, like for
> > > > parade-ps8640 and analogix_dp. I suspect designing a new mechanism
> > > > might not be the most trivial.
> > >
> > > What is done in the bridge drivers is to wait for a fixed timeout and
> > > assume aux is ready? Or is it something else? If there's just a fixed
> > > timeout for the eDP case it sounds OK to do that for now and we can
> > > fine tune it later to actually check HPD status register before the
> > > panel tries to read EDID.
> >
> > Right. For the parade chip (which is only used for eDP as far as I know--never
> > DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> >
> > So I guess tl;dr to Sankeerth that it's OK for his patch to have the wait in the
> > aux transfer function, but only for eDP. Other discussions here are about
> > how we could make it better in future patches.
> >
> >
>
> The aux transactions for external DP are initiated by the dp_display driver only after the
> display is hot plugged to the connector. The phy_init is necessary for the aux transactions
> to take place. So, for the DP case, like Doug mentioned below, this patch is introducing
> an overhead of three register reads to detect hpd_high before performing aux transactions.
> So, we felt this was okay to do for DP.

Personally I'm not that upset about the 3 register reads. The problem
Stephen pointed out is bigger. It's possible that a DP cable is
unplugged _just_ as we started an AUX transaction. In that case we'll
have a big delay here when we don't actually need one.


> On the other hand, for eDP, it is necessary to wait for panel ready through this hpd connect status.
> Currently there is no way to know which type of connector it is in the dp_aux sub-module.
>
> However, as the discussion suggested, to have the wait only for eDP, I am thinking to pass the
> connector_type information to aux sub-module and register different aux_transfer functions
> for eDP and DP. The eDP transfer function will wait for hpd_high and the DP transfer function
> will be same as the one before this patch.

Personally I wouldn't register two separate functions. You could just
store a boolean in your structure and only wait for HPD if this is
eDP. One extra "if" test doesn't seem like it justifies splitting off
into two functions...

-Doug

RE: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Friday, March 25, 2022 9:36 PM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> Cc: Stephen Boyd <swboyd@chromium.org>; David Airlie <airlied@linux.ie>;
> dri-devel <dri-devel@lists.freedesktop.org>; bjorn.andersson@linaro.org;
> Thierry Reding <thierry.reding@gmail.com>; Sam Ravnborg
> <sam@ravnborg.org>; Kuogee Hsieh (QUIC) <quic_khsieh@quicinc.com>;
> Andy Gross <agross@kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
> quic_vproddut <quic_vproddut@quicinc.com>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; Rob Herring <robh+dt@kernel.org>; Sean
> Paul <seanpaul@chromium.org>; Sean Paul <sean@poorly.run>;
> quic_kalyant <quic_kalyant@quicinc.com>; LKML <linux-
> kernel@vger.kernel.org>; dmitry.baryshkov@linaro.org;
> krzk+dt@kernel.org; freedreno <freedreno@lists.freedesktop.org>
> Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> interaction
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Fri, Mar 25, 2022 at 8:54 AM Sankeerth Billakanti (QUIC)
> <quic_sbillaka@quicinc.com> wrote:
> >
> > > -----Original Message-----
> > > From: Doug Anderson <dianders@chromium.org>
> > > Sent: Saturday, March 19, 2022 5:26 AM
> > > To: Stephen Boyd <swboyd@chromium.org>
> > > Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open
> > > list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > <devicetree@vger.kernel.org>; dri-devel
> > > <dri-devel@lists.freedesktop.org>;
> > > freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm
> > > <linux-arm- msm@vger.kernel.org>; LKML
> > > <linux-kernel@vger.kernel.org>; Rob Clark <robdclark@gmail.com>;
> > > Sean Paul <seanpaul@chromium.org>; quic_kalyant
> > > <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> > > <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > > dmitry.baryshkov@linaro.org; quic_vproddut
> > > <quic_vproddut@quicinc.com>
> > > Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any
> > > sink interaction
> > >
> > > Hi,
> > >
> > > On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> > > wrote:
> > > >
> > > > > > Pushing hpd state checking into aux transactions looks like
> > > > > > the wrong direction. Also, as I said up above I am concerned
> > > > > > that even checking the GPIO won't work and we need some way to
> > > > > > ask the bridge if HPD is asserted or not and then fallback to
> > > > > > the GPIO method if the display phy/controller doesn't have
> > > > > > support to check HPD internally. Something on top of
> DRM_BRIDGE_OP_HPD?
> > > > >
> > > > > If we could somehow get the HPD status from the bridge in the
> > > > > panel driver it definitely would be convenient. It does feel
> > > > > like that's an improvement that could be done later, though.
> > > > > We've already landed a few instances of doing what's done here,
> > > > > like for
> > > > > parade-ps8640 and analogix_dp. I suspect designing a new
> > > > > mechanism might not be the most trivial.
> > > >
> > > > What is done in the bridge drivers is to wait for a fixed timeout
> > > > and assume aux is ready? Or is it something else? If there's just
> > > > a fixed timeout for the eDP case it sounds OK to do that for now
> > > > and we can fine tune it later to actually check HPD status
> > > > register before the panel tries to read EDID.
> > >
> > > Right. For the parade chip (which is only used for eDP as far as I
> > > know--never
> > > DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> > >
> > > So I guess tl;dr to Sankeerth that it's OK for his patch to have the
> > > wait in the aux transfer function, but only for eDP. Other
> > > discussions here are about how we could make it better in future
> patches.
> > >
> > >
> >
> > The aux transactions for external DP are initiated by the dp_display
> > driver only after the display is hot plugged to the connector. The
> > phy_init is necessary for the aux transactions to take place. So, for
> > the DP case, like Doug mentioned below, this patch is introducing an
> overhead of three register reads to detect hpd_high before performing aux
> transactions.
> > So, we felt this was okay to do for DP.
> 
> Personally I'm not that upset about the 3 register reads. The problem
> Stephen pointed out is bigger. It's possible that a DP cable is unplugged
> _just_ as we started an AUX transaction. In that case we'll have a big delay
> here when we don't actually need one.
> 
> 
Okay. Got it

> > On the other hand, for eDP, it is necessary to wait for panel ready through
> this hpd connect status.
> > Currently there is no way to know which type of connector it is in the
> dp_aux sub-module.
> >
> > However, as the discussion suggested, to have the wait only for eDP, I
> > am thinking to pass the connector_type information to aux sub-module
> > and register different aux_transfer functions for eDP and DP. The eDP
> > transfer function will wait for hpd_high and the DP transfer function will be
> same as the one before this patch.
> 
> Personally I wouldn't register two separate functions. You could just store a
> boolean in your structure and only wait for HPD if this is eDP. One extra "if"
> test doesn't seem like it justifies splitting off into two functions...
> 
> -Doug
Okay. I will make that change. Thank you.

RE: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink interaction

[Sankeerth Billakanti]

> -----Original Message-----
> From: Doug Anderson <dianders@chromium.org>
> Sent: Friday, March 25, 2022 9:36 PM
> To: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>
> Cc: Stephen Boyd <swboyd@chromium.org>; David Airlie <airlied@linux.ie>;
> dri-devel <dri-devel@lists.freedesktop.org>; bjorn.andersson@linaro.org;
> Thierry Reding <thierry.reding@gmail.com>; Sam Ravnborg
> <sam@ravnborg.org>; Kuogee Hsieh (QUIC) <quic_khsieh@quicinc.com>;
> Andy Gross <agross@kernel.org>; open list:OPEN FIRMWARE AND
> FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>;
> quic_vproddut <quic_vproddut@quicinc.com>; linux-arm-msm <linux-arm-
> msm@vger.kernel.org>; Abhinav Kumar (QUIC)
> <quic_abhinavk@quicinc.com>; Rob Herring <robh+dt@kernel.org>; Sean
> Paul <seanpaul@chromium.org>; Sean Paul <sean@poorly.run>;
> quic_kalyant <quic_kalyant@quicinc.com>; LKML <linux-
> kernel@vger.kernel.org>; dmitry.baryshkov@linaro.org;
> krzk+dt@kernel.org; freedreno <freedreno@lists.freedesktop.org>
> Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any sink
> interaction
> 
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
> 
> Hi,
> 
> On Fri, Mar 25, 2022 at 8:54 AM Sankeerth Billakanti (QUIC)
> <quic_sbillaka@quicinc.com> wrote:
> >
> > > -----Original Message-----
> > > From: Doug Anderson <dianders@chromium.org>
> > > Sent: Saturday, March 19, 2022 5:26 AM
> > > To: Stephen Boyd <swboyd@chromium.org>
> > > Cc: Sankeerth Billakanti (QUIC) <quic_sbillaka@quicinc.com>; open
> > > list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > <devicetree@vger.kernel.org>; dri-devel
> > > <dri-devel@lists.freedesktop.org>;
> > > freedreno <freedreno@lists.freedesktop.org>; linux-arm-msm
> > > <linux-arm- msm@vger.kernel.org>; LKML
> > > <linux-kernel@vger.kernel.org>; Rob Clark <robdclark@gmail.com>;
> > > Sean Paul <seanpaul@chromium.org>; quic_kalyant
> > > <quic_kalyant@quicinc.com>; Abhinav Kumar (QUIC)
> > > <quic_abhinavk@quicinc.com>; Kuogee Hsieh (QUIC)
> > > <quic_khsieh@quicinc.com>; Andy Gross <agross@kernel.org>;
> > > bjorn.andersson@linaro.org; Rob Herring <robh+dt@kernel.org>;
> > > krzk+dt@kernel.org; Sean Paul <sean@poorly.run>; David Airlie
> > > <airlied@linux.ie>; Daniel Vetter <daniel@ffwll.ch>; Thierry Reding
> > > <thierry.reding@gmail.com>; Sam Ravnborg <sam@ravnborg.org>;
> > > dmitry.baryshkov@linaro.org; quic_vproddut
> > > <quic_vproddut@quicinc.com>
> > > Subject: Re: [PATCH v5 6/9] drm/msm/dp: wait for hpd high before any
> > > sink interaction
> > >
> > > Hi,
> > >
> > > On Fri, Mar 18, 2022 at 4:27 PM Stephen Boyd <swboyd@chromium.org>
> > > wrote:
> > > >
> > > > > > Pushing hpd state checking into aux transactions looks like
> > > > > > the wrong direction. Also, as I said up above I am concerned
> > > > > > that even checking the GPIO won't work and we need some way to
> > > > > > ask the bridge if HPD is asserted or not and then fallback to
> > > > > > the GPIO method if the display phy/controller doesn't have
> > > > > > support to check HPD internally. Something on top of
> DRM_BRIDGE_OP_HPD?
> > > > >
> > > > > If we could somehow get the HPD status from the bridge in the
> > > > > panel driver it definitely would be convenient. It does feel
> > > > > like that's an improvement that could be done later, though.
> > > > > We've already landed a few instances of doing what's done here,
> > > > > like for
> > > > > parade-ps8640 and analogix_dp. I suspect designing a new
> > > > > mechanism might not be the most trivial.
> > > >
> > > > What is done in the bridge drivers is to wait for a fixed timeout
> > > > and assume aux is ready? Or is it something else? If there's just
> > > > a fixed timeout for the eDP case it sounds OK to do that for now
> > > > and we can fine tune it later to actually check HPD status
> > > > register before the panel tries to read EDID.
> > >
> > > Right. For the parade chip (which is only used for eDP as far as I
> > > know--never
> > > DP) waits for up to 200 ms. See ps8640_ensure_hpd().
> > >
> > > So I guess tl;dr to Sankeerth that it's OK for his patch to have the
> > > wait in the aux transfer function, but only for eDP. Other
> > > discussions here are about how we could make it better in future
> patches.
> > >
> > >
> >
> > The aux transactions for external DP are initiated by the dp_display
> > driver only after the display is hot plugged to the connector. The
> > phy_init is necessary for the aux transactions to take place. So, for
> > the DP case, like Doug mentioned below, this patch is introducing an
> overhead of three register reads to detect hpd_high before performing aux
> transactions.
> > So, we felt this was okay to do for DP.
> 
> Personally I'm not that upset about the 3 register reads. The problem
> Stephen pointed out is bigger. It's possible that a DP cable is unplugged
> _just_ as we started an AUX transaction. In that case we'll have a big delay
> here when we don't actually need one.
> 
> 
Okay. Got it

> > On the other hand, for eDP, it is necessary to wait for panel ready through
> this hpd connect status.
> > Currently there is no way to know which type of connector it is in the
> dp_aux sub-module.
> >
> > However, as the discussion suggested, to have the wait only for eDP, I
> > am thinking to pass the connector_type information to aux sub-module
> > and register different aux_transfer functions for eDP and DP. The eDP
> > transfer function will wait for hpd_high and the DP transfer function will be
> same as the one before this patch.
> 
> Personally I wouldn't register two separate functions. You could just store a
> boolean in your structure and only wait for HPD if this is eDP. One extra "if"
> test doesn't seem like it justifies splitting off into two functions...
> 
> -Doug
Okay. I will make that change. Thank you.

[PATCH v5 7/9] drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP

[Sankeerth Billakanti]

	The panel-edp enables the eDP panel power during probe, get_modes
and enable. The eDP connect and disconnect interrupts for the eDP/DP
controller are directly dependent on panel power. As eDP display can be
assumed as always connected, the controller driver can skip the eDP
connect and disconnect interrupts. Any disruption in the link status
will be indicated via the IRQ_HPD interrupts.

	So, the eDP controller driver can just enable the IRQ_HPD and
replug interrupts. The DP controller driver still needs to enable all
the interrupts.

	The interrupt register will still reflect the connect and
disconnect interrupt status without generating an actual HW interrupt.
The controller driver should not handle those masked interrupts.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_catalog.c |  9 +++------
 drivers/gpu/drm/msm/dp/dp_display.c | 24 ++++++++++++++++++++++--
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 2c3b0f7..f15316b 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -592,10 +592,6 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
 
 	u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
 
-	/* enable HPD plug and unplug interrupts */
-	dp_catalog_hpd_config_intr(dp_catalog,
-		DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, true);
-
 	/* Configure REFTIMER and enable it */
 	reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
 	dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
@@ -622,13 +618,14 @@ u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
 {
 	struct dp_catalog_private *catalog = container_of(dp_catalog,
 				struct dp_catalog_private, dp_catalog);
-	int isr = 0;
+	int isr, mask;
 
 	isr = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
 	dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
 				 (isr & DP_DP_HPD_INT_MASK));
+	mask = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
 
-	return isr;
+	return isr & (DP_DP_HPD_STATE_STATUS_MASK | mask);
 }
 
 int dp_catalog_ctrl_get_interrupt(struct dp_catalog *dp_catalog)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 688bbed..5775db8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -687,7 +687,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data)
 	dp_display_handle_plugged_change(&dp->dp_display, false);
 
 	/* enable HDP plug interrupt to prepare for next plugin */
-	dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true);
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true);
 
 	DRM_DEBUG_DP("After, type=%d hpd_state=%d\n",
 			dp->dp_display.connector_type, state);
@@ -1096,10 +1097,17 @@ void msm_dp_snapshot(struct msm_disp_state *disp_state, struct msm_dp *dp)
 
 static void dp_display_config_hpd(struct dp_display_private *dp)
 {
-
 	dp_display_host_init(dp);
+
 	dp_catalog_ctrl_hpd_config(dp->catalog);
 
+	/* Enable plug and unplug interrupts only for external DisplayPort */
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog,
+				DP_DP_HPD_PLUG_INT_MASK |
+				DP_DP_HPD_UNPLUG_INT_MASK,
+				true);
+
 	/* Enable interrupt first time
 	 * we are leaving dp clocks on during disconnect
 	 * and never disable interrupt
@@ -1383,6 +1391,12 @@ static int dp_pm_resume(struct device *dev)
 	dp_catalog_ctrl_hpd_config(dp->catalog);
 
 
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog,
+				DP_DP_HPD_PLUG_INT_MASK |
+				DP_DP_HPD_UNPLUG_INT_MASK,
+				true);
+
 	if (dp_catalog_link_is_connected(dp->catalog)) {
 		/*
 		 * set sink to normal operation mode -- D0
@@ -1647,6 +1661,9 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
 		return;
 	}
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+		dp_hpd_plug_handle(dp_display, 0);
+
 	mutex_lock(&dp_display->event_mutex);
 
 	/* stop sentinel checking */
@@ -1711,6 +1728,9 @@ void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
 
 	dp_display = container_of(dp, struct dp_display_private, dp_display);
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+		dp_hpd_unplug_handle(dp_display, 0);
+
 	mutex_lock(&dp_display->event_mutex);
 
 	/* stop sentinel checking */
-- 
2.7.4

[PATCH v5 7/9] drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP

[Sankeerth Billakanti]

	The panel-edp enables the eDP panel power during probe, get_modes
and enable. The eDP connect and disconnect interrupts for the eDP/DP
controller are directly dependent on panel power. As eDP display can be
assumed as always connected, the controller driver can skip the eDP
connect and disconnect interrupts. Any disruption in the link status
will be indicated via the IRQ_HPD interrupts.

	So, the eDP controller driver can just enable the IRQ_HPD and
replug interrupts. The DP controller driver still needs to enable all
the interrupts.

	The interrupt register will still reflect the connect and
disconnect interrupt status without generating an actual HW interrupt.
The controller driver should not handle those masked interrupts.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_catalog.c |  9 +++------
 drivers/gpu/drm/msm/dp/dp_display.c | 24 ++++++++++++++++++++++--
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 2c3b0f7..f15316b 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -592,10 +592,6 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
 
 	u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
 
-	/* enable HPD plug and unplug interrupts */
-	dp_catalog_hpd_config_intr(dp_catalog,
-		DP_DP_HPD_PLUG_INT_MASK | DP_DP_HPD_UNPLUG_INT_MASK, true);
-
 	/* Configure REFTIMER and enable it */
 	reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
 	dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
@@ -622,13 +618,14 @@ u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
 {
 	struct dp_catalog_private *catalog = container_of(dp_catalog,
 				struct dp_catalog_private, dp_catalog);
-	int isr = 0;
+	int isr, mask;
 
 	isr = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
 	dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
 				 (isr & DP_DP_HPD_INT_MASK));
+	mask = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
 
-	return isr;
+	return isr & (DP_DP_HPD_STATE_STATUS_MASK | mask);
 }
 
 int dp_catalog_ctrl_get_interrupt(struct dp_catalog *dp_catalog)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 688bbed..5775db8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -687,7 +687,8 @@ static int dp_hpd_unplug_handle(struct dp_display_private *dp, u32 data)
 	dp_display_handle_plugged_change(&dp->dp_display, false);
 
 	/* enable HDP plug interrupt to prepare for next plugin */
-	dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true);
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK, true);
 
 	DRM_DEBUG_DP("After, type=%d hpd_state=%d\n",
 			dp->dp_display.connector_type, state);
@@ -1096,10 +1097,17 @@ void msm_dp_snapshot(struct msm_disp_state *disp_state, struct msm_dp *dp)
 
 static void dp_display_config_hpd(struct dp_display_private *dp)
 {
-
 	dp_display_host_init(dp);
+
 	dp_catalog_ctrl_hpd_config(dp->catalog);
 
+	/* Enable plug and unplug interrupts only for external DisplayPort */
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog,
+				DP_DP_HPD_PLUG_INT_MASK |
+				DP_DP_HPD_UNPLUG_INT_MASK,
+				true);
+
 	/* Enable interrupt first time
 	 * we are leaving dp clocks on during disconnect
 	 * and never disable interrupt
@@ -1383,6 +1391,12 @@ static int dp_pm_resume(struct device *dev)
 	dp_catalog_ctrl_hpd_config(dp->catalog);
 
 
+	if (dp->dp_display.connector_type == DRM_MODE_CONNECTOR_DisplayPort)
+		dp_catalog_hpd_config_intr(dp->catalog,
+				DP_DP_HPD_PLUG_INT_MASK |
+				DP_DP_HPD_UNPLUG_INT_MASK,
+				true);
+
 	if (dp_catalog_link_is_connected(dp->catalog)) {
 		/*
 		 * set sink to normal operation mode -- D0
@@ -1647,6 +1661,9 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
 		return;
 	}
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+		dp_hpd_plug_handle(dp_display, 0);
+
 	mutex_lock(&dp_display->event_mutex);
 
 	/* stop sentinel checking */
@@ -1711,6 +1728,9 @@ void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
 
 	dp_display = container_of(dp, struct dp_display_private, dp_display);
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+		dp_hpd_unplug_handle(dp_display, 0);
+
 	mutex_lock(&dp_display->event_mutex);
 
 	/* stop sentinel checking */
-- 
2.7.4

[PATCH v5 8/9] drm/msm/dp: Handle eDP mode_valid case

[Sankeerth Billakanti]

The panel-edp driver modes needs to be validated differently from DP
because the link capabilities are not available for EDP by that time.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_display.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 5775db8..8b150d1 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1002,6 +1002,12 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
 		return -EINVAL;
 	}
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+		if (mode_pclk_khz > DP_MAX_PIXEL_CLK_KHZ)
+			return MODE_CLOCK_HIGH;
+		return MODE_OK;
+	}
+
 	if ((dp->max_pclk_khz <= 0) ||
 			(dp->max_pclk_khz > DP_MAX_PIXEL_CLK_KHZ) ||
 			(mode->clock > dp->max_pclk_khz))
-- 
2.7.4

[PATCH v5 8/9] drm/msm/dp: Handle eDP mode_valid case

[Sankeerth Billakanti]

The panel-edp driver modes needs to be validated differently from DP
because the link capabilities are not available for EDP by that time.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_display.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 5775db8..8b150d1 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1002,6 +1002,12 @@ enum drm_mode_status dp_bridge_mode_valid(struct drm_bridge *bridge,
 		return -EINVAL;
 	}
 
+	if (dp->connector_type == DRM_MODE_CONNECTOR_eDP) {
+		if (mode_pclk_khz > DP_MAX_PIXEL_CLK_KHZ)
+			return MODE_CLOCK_HIGH;
+		return MODE_OK;
+	}
+
 	if ((dp->max_pclk_khz <= 0) ||
 			(dp->max_pclk_khz > DP_MAX_PIXEL_CLK_KHZ) ||
 			(mode->clock > dp->max_pclk_khz))
-- 
2.7.4

[PATCH v5 9/9] drm/msm/dp: Support edp/dp without hpd

[Sankeerth Billakanti]

Some eDP sinks or platform boards will not support hpd.
This patch adds support for those cases.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_catalog.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index f15316b..f8ddc73 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -596,8 +596,10 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
 	reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
 	dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
 
-	/* Enable HPD */
-	dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
+	/* Enable HPD if supported*/
+	if (!of_property_read_bool(catalog->dev->of_node, "no-hpd"))
+		dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
+				DP_DP_HPD_CTRL_HPD_EN);
 }
 
 u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog)
-- 
2.7.4

[PATCH v5 9/9] drm/msm/dp: Support edp/dp without hpd

[Sankeerth Billakanti]

Some eDP sinks or platform boards will not support hpd.
This patch adds support for those cases.

Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com>
---
 drivers/gpu/drm/msm/dp/dp_catalog.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c b/drivers/gpu/drm/msm/dp/dp_catalog.c
index f15316b..f8ddc73 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -596,8 +596,10 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
 	reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
 	dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
 
-	/* Enable HPD */
-	dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
+	/* Enable HPD if supported*/
+	if (!of_property_read_bool(catalog->dev->of_node, "no-hpd"))
+		dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
+				DP_DP_HPD_CTRL_HPD_EN);
 }
 
 u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog)
-- 
2.7.4