date:20230708

[PATCH 3/5] arm64: dts: qcom: qrb5165-rb5: add onboard USB-C redriver

2023-07-08 Thread Dmitry Baryshkov

Add the nb7vpq904m, onboard USB-C redriver / retimer.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 52 +++-
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts 
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index b6c587ffdf8f..a03f334a3d01 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -610,6 +610,46 @@ lt9611_out: endpoint {
 /* LS-I2C1 */
  {
status = "okay";
+
+   typec-mux@1c {
+   compatible = "onnn,nb7vpq904m";
+   reg = <0x1c>;
+
+   vcc-supply = <_s4a_1p8>;
+
+   retimer-switch;
+   orientation-switch;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   redriver_usb_con_ss: endpoint {
+   remote-endpoint = 
<_typec_mux_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   redriver_phy_con_ss: endpoint {
+   remote-endpoint = 
<_1_qmpphy_typec_mux_in>;
+   data-lanes = <0 1 2 3>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   redriver_usb_con_sbu: endpoint {
+   remote-endpoint = 
<_typec_sbu_out>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -1294,7 +1334,7 @@ _1_qmpphy {
 };
 
 _1_qmpphy_typec_mux_in {
-   remote-endpoint = <_typec_mux_out>;
+   remote-endpoint = <_phy_con_ss>;
 };
 
 _2 {
@@ -1382,7 +1422,15 @@ pm8150b_role_switch_out: endpoint {
port@1 {
reg = <1>;
pm8150b_typec_mux_out: endpoint {
-   remote-endpoint = 
<_1_qmpphy_typec_mux_in>;
+   remote-endpoint = 
<_usb_con_ss>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   pm8150b_typec_sbu_out: endpoint {
+   remote-endpoint = 
<_usb_con_sbu>;
};
};
};
-- 
2.39.2

[PATCH 5/5] arm64: dts: qcom: qrb5165-rb5: enable DP altmode

2023-07-08 Thread Dmitry Baryshkov

Add displayport altmode declaration to the Type-C controller node to
enable DP altmode negotiation.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts 
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index 210c60025c32..5f289bf640f1 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -1418,6 +1418,13 @@ PDO_FIXED_DUAL_ROLE |
 PDO_FIXED_USB_COMM |
 PDO_FIXED_DATA_SWAP)>;
 
+   altmodes {
+   displayport {
+   svid = <0xff01>;
+   vdo = <0x1c46>;
+   };
+   };
+
ports {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.39.2

[PATCH 4/5] arm64: dts: qcom: qrb5165-rb5: enable displayport controller

2023-07-08 Thread Dmitry Baryshkov

Enable the onboard displayport controller, connect it to QMP PHY.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts 
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index a03f334a3d01..210c60025c32 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -656,6 +656,15 @@  {
status = "okay";
 };
 
+_dp {
+   status = "okay";
+};
+
+_dp_out {
+   data-lanes = <0 1>;
+   remote-endpoint = <_1_qmpphy_dp_in>;
+};
+
 _dsi0 {
status = "okay";
vdda-supply = <_l9a_1p2>;
@@ -1436,3 +1445,7 @@ pm8150b_typec_sbu_out: endpoint {
};
};
 };
+
+_1_qmpphy_dp_in {
+   remote-endpoint = <_dp_out>;
+};
-- 
2.39.2

[PATCH 2/5] arm64: dts: qcom: sm8250: Add DisplayPort device node

2023-07-08 Thread Dmitry Baryshkov

Declare the displayport controller present on the Qualcomm SM8250 SoC.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 93 
 1 file changed, 93 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi 
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index aaf3f6764fe8..89b3a24d402d 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3626,6 +3626,12 @@ port@0 {
port@1 {
reg = <1>;
};
+
+   port@2 {
+   reg = <2>;
+
+   usb_1_qmpphy_dp_in: endpoint {};
+   };
};
};
 
@@ -4270,6 +4276,14 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+
+   dpu_intf0_out: endpoint {
+   remote-endpoint = 
<_dp_in>;
+   };
+   };
};
 
mdp_opp_table: opp-table {
@@ -4297,6 +4311,85 @@ opp-46000 {
};
};
 
+   mdss_dp: displayport-controller@ae9 {
+   compatible = "qcom,sm8250-dp", "qcom,sm8350-dp";
+   reg = <0 0xae9 0 0x200>,
+ <0 0xae90200 0 0x200>,
+ <0 0xae90400 0 0x600>,
+ <0 0xae91000 0 0x400>,
+ <0 0xae91400 0 0x400>;
+   interrupt-parent = <>;
+   interrupts = <12>;
+   clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_DP_AUX_CLK>,
+< DISP_CC_MDSS_DP_LINK_CLK>,
+< 
DISP_CC_MDSS_DP_LINK_INTF_CLK>,
+< DISP_CC_MDSS_DP_PIXEL_CLK>;
+   clock-names = "core_iface",
+ "core_aux",
+ "ctrl_link",
+ "ctrl_link_iface",
+ "stream_pixel";
+
+   assigned-clocks = < 
DISP_CC_MDSS_DP_LINK_CLK_SRC>,
+ < 
DISP_CC_MDSS_DP_PIXEL_CLK_SRC>;
+   assigned-clock-parents = <_phy 0>,
+<_phy 1>;
+
+   phys = <_phy>;
+   phy-names = "dp";
+
+   #sound-dai-cells = <0>;
+
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SM8250_MMCX>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mdss_dp_in: endpoint {
+   remote-endpoint = 
<_intf0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mdss_dp_out: endpoint {
+   };
+   };
+   };
+
+   dp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-16000 {
+   opp-hz = /bits/ 64 <16000>;
+   required-opps = 
<_opp_low_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<_opp_svs>;
+   };

[PATCH 0/5] arm64: dts: qcom: qrb5165-rb5: enable DP support

2023-07-08 Thread Dmitry Baryshkov

Implement DisplayPort support for the Qualcomm RB5 platform.

Note: while testing this, I had link training issues with several
dongles with DP connectors. Other DisplayPort-USB-C dongles (with HDMI
or VGA connectors) work perfectly.

Dependencies: [1]
Soft-dependencies: [2], [3]

[1] 
https://lore.kernel.org/linux-arm-msm/20230515133643.3621656-1-bryan.odonog...@linaro.org/
[2] 
https://lore.kernel.org/linux-arm-msm/20230709034211.4045004-1-dmitry.barysh...@linaro.org/
[3] 
https://lore.kernel.org/linux-arm-msm/20230709034808.4049383-1-dmitry.barysh...@linaro.org/

Dmitry Baryshkov (5):
  dt-bindings: display: msm: dp-controller: document SM8250 compatible
  arm64: dts: qcom: sm8250: Add DisplayPort device node
  arm64: dts: qcom: qrb5165-rb5: add onboard USB-C redriver
  arm64: dts: qcom: qrb5165-rb5: enable displayport controller
  arm64: dts: qcom: qrb5165-rb5: enable DP altmode

 .../bindings/display/msm/dp-controller.yaml   |  1 +
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts  | 72 +-
 arch/arm64/boot/dts/qcom/sm8250.dtsi  | 93 +++
 3 files changed, 164 insertions(+), 2 deletions(-)

-- 
2.39.2

[PATCH 1/5] dt-bindings: display: msm: dp-controller: document SM8250 compatible

2023-07-08 Thread Dmitry Baryshkov

It looks like DP controlled on SM8250 is the same as DP controller on
SM8350. Use the SM8350 compatible as fallback for SM8250.

Signed-off-by: Dmitry Baryshkov 
---
 Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml 
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 7a7cf3fb3e6d..a31ec9a4179f 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -28,6 +28,7 @@ properties:
   - qcom,sm8350-dp
   - items:
   - enum:
+  - qcom,sm8250-dp
   - qcom,sm8450-dp
   - qcom,sm8550-dp
   - const: qcom,sm8350-dp
-- 
2.39.2

Re: [syzbot] [dri?] divide error in drm_mode_vrefresh

2023-07-08 Thread syzbot

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any 
issue:

Reported-and-tested-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com

Tested on:

commit: 1c7873e3 mm: lock newly mapped VMA with corrected orde..
git tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=101196d2a8
kernel config:  https://syzkaller.appspot.com/x/.config?x=8f6b0c7ae2c9c303
dashboard link: https://syzkaller.appspot.com/bug?extid=622bba18029bcde672e1
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
patch:  https://syzkaller.appspot.com/x/patch.diff?x=10e44354a8

Note: testing is done by a robot and is best-effort only.

[PATCH v5 2/3] drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb()

2023-07-08 Thread Dmitry Baryshkov

In some cases the bridge drivers would like to receive hotplug events
even in the case new status is equal to the old status. In the DP case
this is used to deliver "attention" messages to the DP host. Stop
filtering the events in the drm_bridge_connector_hpd_cb() and let
drivers decide whether they would like to receive the event or not.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_bridge_connector.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 19ae4a177ac3..84d8d310ef04 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -113,16 +113,11 @@ static void drm_bridge_connector_hpd_cb(void *cb_data,
struct drm_bridge_connector *drm_bridge_connector = cb_data;
struct drm_connector *connector = _bridge_connector->base;
struct drm_device *dev = connector->dev;
-   enum drm_connector_status old_status;
 
mutex_lock(>mode_config.mutex);
-   old_status = connector->status;
connector->status = status;
mutex_unlock(>mode_config.mutex);
 
-   if (old_status == status)
-   return;
-
drm_bridge_connector_hpd_notify(connector, status);
 
drm_kms_helper_hotplug_event(dev);
-- 
2.39.2

[PATCH v5 3/3] drm/bridge_connector: implement oob_hotplug_event

2023-07-08 Thread Dmitry Baryshkov

Implement the oob_hotplug_event() callback. Translate it to the HPD
notification sent to the HPD bridge in the chain.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_bridge_connector.c | 29 +++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index 84d8d310ef04..364f6e37fbdc 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -5,6 +5,8 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -107,10 +109,9 @@ static void drm_bridge_connector_hpd_notify(struct 
drm_connector *connector,
}
 }
 
-static void drm_bridge_connector_hpd_cb(void *cb_data,
-   enum drm_connector_status status)
+static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector 
*drm_bridge_connector,
+   enum drm_connector_status status)
 {
-   struct drm_bridge_connector *drm_bridge_connector = cb_data;
struct drm_connector *connector = _bridge_connector->base;
struct drm_device *dev = connector->dev;
 
@@ -123,6 +124,21 @@ static void drm_bridge_connector_hpd_cb(void *cb_data,
drm_kms_helper_hotplug_event(dev);
 }
 
+static void drm_bridge_connector_hpd_cb(void *cb_data,
+   enum drm_connector_status status)
+{
+   drm_bridge_connector_handle_hpd(cb_data, status);
+}
+
+static void drm_bridge_connector_oob_hotplug_event(struct drm_connector 
*connector,
+  enum drm_connector_status 
status)
+{
+   struct drm_bridge_connector *bridge_connector =
+   to_drm_bridge_connector(connector);
+
+   drm_bridge_connector_handle_hpd(bridge_connector, status);
+}
+
 static void drm_bridge_connector_enable_hpd(struct drm_connector *connector)
 {
struct drm_bridge_connector *bridge_connector =
@@ -216,6 +232,7 @@ static const struct drm_connector_funcs 
drm_bridge_connector_funcs = {
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
+   .oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
 };
 
 /* 
-
@@ -351,6 +368,12 @@ struct drm_connector *drm_bridge_connector_init(struct 
drm_device *drm,
if (!drm_bridge_get_next_bridge(bridge))
connector_type = bridge->type;
 
+#ifdef CONFIG_OF
+   if (!drm_bridge_get_next_bridge(bridge) &&
+   bridge->of_node)
+   connector->fwnode = 
fwnode_handle_get(of_fwnode_handle(bridge->of_node));
+#endif
+
if (bridge->ddc)
ddc = bridge->ddc;
 
-- 
2.39.2

[PATCH v5 1/3] drm: Add HPD state to drm_connector_oob_hotplug_event()

2023-07-08 Thread Dmitry Baryshkov

From: Bjorn Andersson 

In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.

Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.

Also push the test for unchanged state in the displayport altmode driver
into the i915 driver, to allow other drivers to act upon each update.

Signed-off-by: Bjorn Andersson 
Reviewed-by: Hans de Goede 
Acked-by: Heikki Krogerus 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/drm_connector.c |  6 --
 .../gpu/drm/i915/display/intel_display_core.h   |  3 +++
 drivers/gpu/drm/i915/display/intel_dp.c | 17 ++---
 drivers/usb/typec/altmodes/displayport.c| 13 ++---
 include/drm/drm_connector.h |  6 --
 5 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3ed4cfcb350c..1128149c74f2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3049,6 +3049,7 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
 /**
  * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to 
connector
  * @connector_fwnode: fwnode_handle to report the event on
+ * @status: hot plug detect logical state
  *
  * On some hardware a hotplug event notification may come from outside the 
display
  * driver / device. An example of this is some USB Type-C setups where the 
hardware
@@ -3058,7 +3059,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct 
fwnode_handle *fwnode)
  * This function can be used to report these out-of-band events after obtaining
  * a drm_connector reference through calling drm_connector_find_by_fwnode().
  */
-void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
+enum drm_connector_status status)
 {
struct drm_connector *connector;
 
@@ -3067,7 +3069,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle 
*connector_fwnode)
return;
 
if (connector->funcs->oob_hotplug_event)
-   connector->funcs->oob_hotplug_event(connector);
+   connector->funcs->oob_hotplug_event(connector, status);
 
drm_connector_put(connector);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 8d2243c71dd8..419efee5df74 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -175,6 +175,9 @@ struct intel_hotplug {
/* Whether or not to count short HPD IRQs in HPD storms */
u8 hpd_short_storm_enabled;
 
+   /* Last state reported by oob_hotplug_event for each encoder */
+   unsigned long oob_hotplug_last_state;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9f40da20e88d..cf633f0df6ff 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5244,15 +5244,26 @@ static int intel_dp_connector_atomic_check(struct 
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
 }
 
-static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
+  enum drm_connector_status hpd_state)
 {
struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
+   bool hpd_high = hpd_state == connector_status_connected;
+   unsigned int hpd_pin = encoder->hpd_pin;
+   bool need_work = false;
 
spin_lock_irq(>irq_lock);
-   i915->display.hotplug.event_bits |= BIT(encoder->hpd_pin);
+   if (hpd_high != test_bit(hpd_pin, 
>display.hotplug.oob_hotplug_last_state)) {
+   i915->display.hotplug.event_bits |= BIT(hpd_pin);
+
+   __assign_bit(hpd_pin, 
>display.hotplug.oob_hotplug_last_state, hpd_high);
+   need_work = true;
+   }
spin_unlock_irq(>irq_lock);
-   queue_delayed_work(i915->unordered_wq, 
>display.hotplug.hotplug_work, 0);
+
+   if (need_work)
+   queue_delayed_work(i915->unordered_wq, 
>display.hotplug.hotplug_work, 0);
 }
 
 static const struct drm_connector_funcs intel_dp_connector_funcs = {
diff --git a/drivers/usb/typec/altmodes/displayport.c 
b/drivers/usb/typec/altmodes/displayport.c
index 66de880b28d0..4e5aa17ce4c8 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++

[PATCH v5 0/3] drm/bridge_connector: implement OOB HPD handling

2023-07-08 Thread Dmitry Baryshkov

Note, this is sent as v5, since there were several revisions for this
patchset under a different series title ([1]).

USB altmodes code would send OOB notifications to the drm_connector
specified in the device tree. However as the MSM DP driver uses
drm_bridge_connector, there is no way to receive these event directly.
Implement a bridge between oob_hotplug_event and drm_bridge's
hpd_notify.

Merge strategy: since this series touches i915 code, it might make sense
to merge it through drm-intel.

[1] https://patchwork.freedesktop.org/series/103449/

Changes since v4:
- Picked up the patchset
- Dropped msm-specific patches
- Changed drm_bridge_connector_oob_hotplug_event to call connector's HPD
  callback directly, rather than going through the last bridge's
  hpd_notify
- Added proper fwnode for the drm_bridge_connector

Bjorn Andersson (1):
  drm: Add HPD state to drm_connector_oob_hotplug_event()

Dmitry Baryshkov (2):
  drm/bridge_connector: stop filtering events in
drm_bridge_connector_hpd_cb()
  drm/bridge_connector: implement oob_hotplug_event

 drivers/gpu/drm/drm_bridge_connector.c| 34 ++-
 drivers/gpu/drm/drm_connector.c   |  6 ++--
 .../gpu/drm/i915/display/intel_display_core.h |  3 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 17 --
 drivers/usb/typec/altmodes/displayport.c  | 13 ---
 include/drm/drm_connector.h   |  6 ++--
 6 files changed, 57 insertions(+), 22 deletions(-)

-- 
2.39.2

Re: [PATCH v1 4/5] drm/msm/dp: move relevant dp initialization code from bind() to probe()

2023-07-08 Thread Bjorn Andersson

On Fri, Jul 07, 2023 at 04:52:22PM -0700, Kuogee Hsieh wrote:
> In preparation of moving edp of_dp_aux_populate_bus() to
> dp_display_probe(), move dp_display_request_irq(),
> dp->parser->parse() and dp_power_client_init() to dp_display_probe()
> too.
> 
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_display.c | 48 
> +
>  drivers/gpu/drm/msm/dp/dp_display.h |  1 -
>  2 files changed, 22 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 44580c2..185f1eb 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -290,12 +290,6 @@ static int dp_display_bind(struct device *dev, struct 
> device *master,
>   goto end;
>   }
>  
> - rc = dp_power_client_init(dp->power);
> - if (rc) {
> - DRM_ERROR("Power client create failed\n");
> - goto end;
> - }
> -
>   rc = dp_register_audio_driver(dev, dp->audio);
>   if (rc) {
>   DRM_ERROR("Audio registration Dp failed\n");
> @@ -752,6 +746,12 @@ static int dp_init_sub_modules(struct dp_display_private 
> *dp)
>   goto error;
>   }
>  
> + rc = dp->parser->parse(dp->parser);

Today dp_init_sub_modules() just allocates memory for all the modules
and ties them together. While I don't fancy this way of structuring
device drivers in Linux, I think it's reasonable to retain that design
for now, and perform the parsing and power initialization in
dp_display_probe().

> + if (rc) {
> + DRM_ERROR("device tree parsing failed\n");
> + goto error;
> + }
> +
>   dp->catalog = dp_catalog_get(dev, >parser->io);
>   if (IS_ERR(dp->catalog)) {
>   rc = PTR_ERR(dp->catalog);
> @@ -768,6 +768,12 @@ static int dp_init_sub_modules(struct dp_display_private 
> *dp)
>   goto error;
>   }
>  
> + rc = dp_power_client_init(dp->power);
> + if (rc) {
> + DRM_ERROR("Power client create failed\n");
> + goto error;
> + }
> +
>   dp->aux = dp_aux_get(dev, dp->catalog, dp->dp_display.is_edp);
>   if (IS_ERR(dp->aux)) {
>   rc = PTR_ERR(dp->aux);
> @@ -1196,26 +1202,20 @@ static irqreturn_t dp_display_irq_handler(int irq, 
> void *dev_id)
>   return ret;
>  }
>  
> -int dp_display_request_irq(struct msm_dp *dp_display)
> +static int dp_display_request_irq(struct dp_display_private *dp)
>  {
>   int rc = 0;
> - struct dp_display_private *dp;
> -
> - if (!dp_display) {
> - DRM_ERROR("invalid input\n");
> - return -EINVAL;
> - }

Love this, but it's unrelated to the rest of the patch.

> -
> - dp = container_of(dp_display, struct dp_display_private, dp_display);
> + struct device *dev = >pdev->dev;
>  
> - dp->irq = irq_of_parse_and_map(dp->pdev->dev.of_node, 0);
>   if (!dp->irq) {
> - DRM_ERROR("failed to get irq\n");
> - return -EINVAL;
> + dp->irq = irq_of_parse_and_map(dp->pdev->dev.of_node, 0);
> + if (!dp->irq) {
> + DRM_ERROR("failed to get irq\n");
> + return -EINVAL;
> + }
>   }
>  
> - rc = devm_request_irq(dp_display->drm_dev->dev, dp->irq,
> - dp_display_irq_handler,
> + rc = devm_request_irq(dev, dp->irq, dp_display_irq_handler,

This is fixing a bug where currently the dp_display_irq_handler()
registration is tied to the DPU device's life cycle, while depending on
resources that are released as the DP device is torn down.

It would be nice if this was not hidden in a patch that claims to just
move calls around.

Regards,
Bjorn

>   IRQF_TRIGGER_HIGH, "dp_display_isr", dp);
>   if (rc < 0) {
>   DRM_ERROR("failed to request IRQ%u: %d\n",
> @@ -1290,6 +1290,8 @@ static int dp_display_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, >dp_display);
>  
> + dp_display_request_irq(dp);
> +
>   rc = component_add(>dev, _display_comp_ops);
>   if (rc) {
>   DRM_ERROR("component add failed, rc=%d\n", rc);
> @@ -1574,12 +1576,6 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, 
> struct drm_device *dev,
>  
>   dp_priv = container_of(dp_display, struct dp_display_private, 
> dp_display);
>  
> - ret = dp_display_request_irq(dp_display);
> - if (ret) {
> - DRM_ERROR("request_irq failed, ret=%d\n", ret);
> - return ret;
> - }
> -
>   ret = dp_display_get_next_bridge(dp_display);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.h 
> b/drivers/gpu/drm/msm/dp/dp_display.h
> index 1e9415a..b3c08de 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.h
> +++ b/drivers/gpu/drm/msm/dp/dp_display.h
> @@ -35,7 +35,6 @@ struct msm_dp {
>  int

Re: [PATCH v1 2/5] drm/msm/dp: incorporate pm_runtime framework into DP driver

2023-07-08 Thread Bjorn Andersson

On Fri, Jul 07, 2023 at 04:52:20PM -0700, Kuogee Hsieh wrote:
> Incorporating pm runtime framework into DP driver so that power
> and clock resource handling can be centralized allowing easier
> control of these resources in preparation of registering aux bus
> uring probe.
> 
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_aux.c |  3 ++
>  drivers/gpu/drm/msm/dp/dp_display.c | 75 
> +
>  2 files changed, 63 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 8e3b677..c592064 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -291,6 +291,7 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>   return -EINVAL;
>   }
>  
> + pm_runtime_get_sync(dp_aux->dev);
>   mutex_lock(>mutex);
>   if (!aux->initted) {
>   ret = -EIO;
> @@ -364,6 +365,8 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>  
>  exit:
>   mutex_unlock(>mutex);
> + pm_runtime_mark_last_busy(dp_aux->dev);
> + pm_runtime_put_autosuspend(dp_aux->dev);
>  
>   return ret;
>  }
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 76f1395..2c5706a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -309,6 +309,10 @@ static int dp_display_bind(struct device *dev, struct 
> device *master,
>   goto end;
>   }
>  
> + pm_runtime_enable(dev);
> + pm_runtime_set_autosuspend_delay(dev, 1000);
> + pm_runtime_use_autosuspend(dev);
> +
>   return 0;
>  end:
>   return rc;
> @@ -320,9 +324,8 @@ static void dp_display_unbind(struct device *dev, struct 
> device *master,
>   struct dp_display_private *dp = dev_get_dp_display_private(dev);
>   struct msm_drm_private *priv = dev_get_drvdata(master);
>  
> - /* disable all HPD interrupts */
> - if (dp->core_initialized)
> - dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_INT_MASK, 
> false);
> + pm_runtime_dont_use_autosuspend(dev);
> + pm_runtime_disable(dev);
>  
>   kthread_stop(dp->ev_tsk);
>  
> @@ -466,10 +469,12 @@ static void dp_display_host_init(struct 
> dp_display_private *dp)
>   dp->dp_display.connector_type, dp->core_initialized,
>   dp->phy_initialized);
>  
> - dp_power_init(dp->power);
> - dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> - dp_aux_init(dp->aux);
> - dp->core_initialized = true;
> + if (!dp->core_initialized) {
> + dp_power_init(dp->power);
> + dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
> + dp_aux_init(dp->aux);
> + dp->core_initialized = true;

There are two cases that queries core_initialized, both of those are
done to avoid accessing the DP block without it first being powered up.
With the introduction of runtime PM, it seems reasonable to just power
up the block in those two code paths (and remove the variable).

> + }
>  }
>  
>  static void dp_display_host_deinit(struct dp_display_private *dp)
> @@ -478,10 +483,12 @@ static void dp_display_host_deinit(struct 
> dp_display_private *dp)
>   dp->dp_display.connector_type, dp->core_initialized,
>   dp->phy_initialized);
>  
> - dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
> - dp_aux_deinit(dp->aux);
> - dp_power_deinit(dp->power);
> - dp->core_initialized = false;
> + if (dp->core_initialized) {
> + dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
> + dp_aux_deinit(dp->aux);
> + dp_power_deinit(dp->power);
> + dp->core_initialized = false;
> + }
>  }
>  
>  static int dp_display_usbpd_configure_cb(struct device *dev)
> @@ -1304,6 +1311,39 @@ static int dp_display_remove(struct platform_device 
> *pdev)
>   dp_display_deinit_sub_modules(dp);
>  
>   platform_set_drvdata(pdev, NULL);
> + pm_runtime_put_sync_suspend(>dev);
> +
> + return 0;
> +}
> +
> +static int dp_pm_runtime_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct msm_dp *dp_display = platform_get_drvdata(pdev);

platform_get_drvdata() is a wrapper for dev_get_drvdata(>dev), so
there's no need to resolve the platform_device first...

> + struct dp_display_private *dp;
> +
> + dp = container_of(dp_display, struct dp_display_private, dp_display);
> +
> + dp_display_host_phy_exit(dp);
> + dp_catalog_ctrl_hpd_enable(dp->catalog);
> + dp_display_host_deinit(dp);
> +
> + return 0;
> +}
> +
> +static int dp_pm_runtime_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct msm_dp *dp_display = platform_get_drvdata(pdev);
> + struct dp_display_private *dp;
> +
> + dp = container_of(dp_display, struct dp_display_private, dp_display);
> +

Re: [PATCH v1 1/5] drm/msm/dp: remove pm_runtime_xxx() from dp_power.c

2023-07-08 Thread Bjorn Andersson

On Fri, Jul 07, 2023 at 04:52:19PM -0700, Kuogee Hsieh wrote:
> Since both pm_runtime_resume() and pm_runtime_suspend() are not
> populated at dp_pm_ops. Those pm_runtime_get/put() functions within
> dp_power.c will not have any effects in addition to increase/decrease
> power counter. Also pm_runtime_xxx() should be executed at top
> layer.
> 

Getting/putting the runtime PM state affects the vote for the GDSC. So I
would suggest that you move this after patch 2, to not create a gap in
the git history of lacking GDSC votes.

Regards,
Bjorn

> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_power.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_power.c 
> b/drivers/gpu/drm/msm/dp/dp_power.c
> index 5cb84ca..ed2f62a 100644
> --- a/drivers/gpu/drm/msm/dp/dp_power.c
> +++ b/drivers/gpu/drm/msm/dp/dp_power.c
> @@ -152,8 +152,6 @@ int dp_power_client_init(struct dp_power *dp_power)
>  
>   power = container_of(dp_power, struct dp_power_private, dp_power);
>  
> - pm_runtime_enable(power->dev);
> -
>   return dp_power_clk_init(power);
>  }
>  
> @@ -162,8 +160,6 @@ void dp_power_client_deinit(struct dp_power *dp_power)
>   struct dp_power_private *power;
>  
>   power = container_of(dp_power, struct dp_power_private, dp_power);
> -
> - pm_runtime_disable(power->dev);
>  }
>  
>  int dp_power_init(struct dp_power *dp_power)
> @@ -173,11 +169,7 @@ int dp_power_init(struct dp_power *dp_power)
>  
>   power = container_of(dp_power, struct dp_power_private, dp_power);
>  
> - pm_runtime_get_sync(power->dev);
> -
>   rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
> - if (rc)
> - pm_runtime_put_sync(power->dev);
>  
>   return rc;
>  }
> @@ -189,7 +181,6 @@ int dp_power_deinit(struct dp_power *dp_power)
>   power = container_of(dp_power, struct dp_power_private, dp_power);
>  
>   dp_power_clk_enable(dp_power, DP_CORE_PM, false);
> - pm_runtime_put_sync(power->dev);
>   return 0;
>  }
>  
> -- 
> 2.7.4
>

[PATCH v5] drm/vkms: Add support to 1D gamma LUT

2023-07-08 Thread Arthur Grillo

Support a 1D gamma LUT with interpolation for each color channel on the
VKMS driver. Add a check for the LUT length by creating
vkms_atomic_check().

Enable VKMS to run the test igt@kms_plane@pixel-format.

Tested with:
igt@kms_color@gamma
igt@kms_color@legacy-gamma
igt@kms_color@invalid-gamma-lut-sizes

v2:
- Add interpolation between the values of the LUT (Simon Ser)

v3:
- s/ratio/delta (Pekka)
- s/color_channel/channel_value (Pekka)
- s/lut_area/lut_channel
- Store the `drm_color_lut`, `lut_length`, and
  `channel_value2index_ratio` inside a struct called `vkms_lut`
  (Pekka)
- Pre-compute some constants values used through the LUT procedure
  (Pekka)
- Change the switch statement to a cast to __u16* (Pekka)
- Make the apply_lut_to_channel_value return the computation result
  (Pekka)

v4:
- Add a comment explaining that `enum lut_area` depends on the
  layout of `struct drm_color_lut` (Pekka)
- Remove unused variable (kernel test robot)

v5:
- Mention that this will make it possible to run the test
  igt@kms_plane@pixel-format (Maíra)
- s/had/has (Maíra)

Signed-off-by: Arthur Grillo 
Acked-by: Pekka Paalanen 
Reviewed-by: Maíra Canal 
---
Maíra asked me to run a benchmark on some IGT tests:

Each test ran 100 times. The result with 'X' are tests that were not able to
run because of the absence of gamma LUT.

+--+---+-+---+
| Test |  No LUT   | Unoptimized 
LUT | Optimized LUT |
+ 
-+---+-+---+
| igt@kms_rotation@primary-rotation-180| 174.298s  |181.130s
 |   178.800s|
+ 
-+---+-+---+
| igt@kms_plane@pixel-format   |X  |1420.453s   
 |   1218.229s   |
+ 
-+---+-+---+
| igt@kms_plane@pixel-format-source-clamping   |X  |704.236s
 |   612.318s|
+ 
-+---+-+---+
| igt@kms_plane@plane-position-covered | 12.535s   |12.864s 
 |   12.025s |
+ 
-+---+-+---+
| igt@kms_plane@plane-position-hole| 11.752s   |12.873s 
 |   11.202s |
+ 
-+---+-+---+
| igt@kms_plane@plane-position-hole-dpms   | 15.188s   |15.238s 
 |   15.652s |
+ 
-+---+-+---+
| igt@kms_plane@plane-panning-top-left | 10.797s   |11.873s 
 |   11.041s |
+ 
-+---+-+---+
| igt@kms_plane@plane-bottom-right | 10.764s   |11.613s 
 |   10.053s |
+ 
-+---+-+---+
| igt@kms_plane@plane-panning-bottom-right-suspend | 2011.344s |2009.410s   
 |   2011.496s   |
+ 
-+---+-+---+
| igt@kms_cursor_crc@cursor-onscreen-512x5112  | 359.209s  |337.830s
 |   308.168s|
+ 
-+---+-+---+
| igt@kms_color@gamma  |X  |137.702s
 |   118.139s|
+ 
-+---+-+---+

---
 drivers/gpu/drm/vkms/vkms_composer.c | 86 
 drivers/gpu/drm/vkms/vkms_crtc.c |  3 +
 drivers/gpu/drm/vkms/vkms_drv.c  | 20 ++-
 drivers/gpu/drm/vkms/vkms_drv.h  |  9 +++
 4 files changed, 117 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 906d3df40cdb..e3a79dcd2e38 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -89,6 +90,73 @@ static void fill_background(const struct pixel_argb_u16 
*background_color,
output_buffer->pixels[i] = *background_color;
 }
 
+// lerp(a, b, t) = a + (b - a) * t
+static u16 lerp_u16(u16 a, u16 b, s64 t)
+{
+   s64 a_fp = drm_int2fixp(a);
+   s64 b_fp = drm_int2fixp(b);
+
+   s64 delta = drm_fixp_mul(b_fp - a_fp,  t);
+
+   return drm_fixp2int(a_fp + delta);
+}
+
+static s64 get_lut_index(const struct vkms_color_lut *lut, u16 channel_value)
+{
+

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

2023-07-08 Thread Abhinav Kumar

On 7/7/2023 1:47 AM, Neil Armstrong wrote:

On 07/07/2023 09:18, Neil Armstrong wrote:

Hi,

On 06/07/2023 11:20, Amit Pundir wrote:

On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote:

Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as these packets are not required. This makes the bridge
work with Samsung DSIM on i.MX8MM and i.MX8MP.

This patch broke display on Dragonboard 845c (SDM845) devboard
running

AOSP. This is what I see
https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
Reverting this patch fixes this regression for me.

Might be msm dsi host require proper handling on these updated
mode_flags? did they?

The msm DSI host supports those flags. Also, I'd like to point out
that the patch didn't change the rest of the driver code. So even if
drm/msm ignored some of the flags, it should not have caused the
issue. Most likely the issue is on the lt9611 side. I's suspect that
additional programming is required to make it work with these flags.

I spent some time today on smoke testing these flags (individually and
in limited combination) on DB845c, to narrow down this breakage to one
or more flag(s) triggering it. Here are my observations in limited
testing done so far.

There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
alone and system boots to UI as usual.

MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
screenshot[1] shared earlier as well.

Adding either of MIPI_DSI_MODE_VIDEO_NO_HSA and
MIPI_DSI_MODE_VIDEO_NO_HBP always result in no display, unless paired
with MIPI_DSI_MODE_VIDEO_NO_HFP and in that case we get the broken
display as reported.

In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
added in this commit break the display on DB845c one way or another.

I think the investigation would be to understand why samsung-dsim
requires
such flags and/or what are the difference in behavior between MSM DSI
and samsung DSIM

for those flags ?

If someone has access to the lt9611 datasheet, so it requires
HSA/HFP/HBP to be

skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?

I think there's a mismatch, where on one side this flags sets the link
in LP-11 while
in HSA/HFP/HPB while on the other it completely removes those blanking
packets.

The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not LP-11
while HPB.

the registers used in both controllers are different:
- samsung-dsim: DSIM_HBP_DISABLE_MODE
- msm dsi: DSI_VID_CFG0_HBP_POWER_STOP

The first one suggest removing the packet, while the second one suggests
powering

off the line while in the blanking packet period.

@Abhinav, can you comment on that ?

I dont get what it means by completely removes blanking packets in DSIM.

It should be replacing those periods with LP11 too.

The traffic mode being used on this bridge is
MIPI_DSI_MODE_VIDEO_SYNC_PULSE which is "Non-Burst Mode with Sync Pulses".

As per this traffic mode in the DSI spec,

"Normally, periods shown as HSA (Horizontal Sync Active), HBP
(Horizontal Back Porch) and HFP (Horizontal Front Porch) are filled by
Blanking Packets, with lengths (including packet overhead) calculated
to match the period specified by the peripheral’s data sheet.
Alternatively, if there is sufficient time to transition from HS to LP
mode and back again, a timed interval in LP mode may substitute for a
Blanking Packet, thus saving power. During HSA, HBP and HFP periods, the
bus should stay in the LP-11 state."

So we can either send the blanking packets or transition to LP state and
those 3 flags are controlling exactly that during those periods for MSM
driver.

If you stop sending the blanking packets, you need to replace that gap
with LP.

One reason I can think of why this could break with MSM is perhaps we do
not have sufficient time in those periods for the LP-HS transition like
the spec has written.

1) What is the resolution which is getting broken on db845c with this? I
would like to know the full drm_display_mode for it to see how much time
we have in those periods. Is any resolution working or all are broken.

2) I also do not completely get the last line of the DSI spec on this
traffic mode. Is it suggesting that we *must* use only LP11 for those
periods in this traffic mode? I need to check little more on that.
Because if thats the case the change is doing just that and we need to
investigate the MSM failure little more. If not and its indeed optional
to save power like the DSI spec says, then its weird why DSIM should be
blank without that too.

@Jagan, Andrezej So you have any documentation on what
DSIM_xxx_DISABLE_MODE does ?

@Dmitry, so you have access to the

[drm-misc:drm-misc-next 1/14] drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared

2023-07-08 Thread kernel test robot

tree:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head:   b63f5e5ca945e1c0341a2c3278575bb82bf8b890
commit: 8b0d13545b091729e0aa05ff9981e2d06c1e2ee5 [1/14] efi: Do not include 
 from EFI header
config: arm64-allyesconfig 
(https://download.01.org/0day-ci/archive/20230709/202307090823.nxnt8kk5-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.3.0
reproduce: 
(https://download.01.org/0day-ci/archive/20230709/202307090823.nxnt8kk5-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202307090823.nxnt8kk5-...@intel.com/

All errors (new ones prefixed by >>):

   drivers/video/fbdev/hyperv_fb.c: In function 'hvfb_getmem':
>> drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared 
>> (first use in this function)
1033 | base = screen_info.lfb_base;
 |^~~
   drivers/video/fbdev/hyperv_fb.c:1033:24: note: each undeclared identifier is 
reported only once for each function it appears in
--
   drivers/gpu/drm/hyperv/hyperv_drm_drv.c: In function 'hyperv_setup_vram':
>> drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: error: 'screen_info' 
>> undeclared (first use in this function)
  75 | 
drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base,
 |  ^~~
   drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: note: each undeclared 
identifier is reported only once for each function it appears in


vim +/screen_info +1033 drivers/video/fbdev/hyperv_fb.c

3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09   
988  
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29   
989  
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29   
990  /* Get framebuffer memory from Hyper-V video pci space */
3546448338e76a drivers/video/fbdev/hyperv_fb.c Jake Oshins   2015-08-05   
991  static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29   
992  {
9069fd54960304 drivers/video/hyperv_fb.c   Gerd Hoffmann 2014-02-26   
993   struct hvfb_par *par = info->par;
9069fd54960304 drivers/video/hyperv_fb.c   Gerd Hoffmann 2014-02-26   
994   struct pci_dev *pdev  = NULL;
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29   
995   void __iomem *fb_virt;
9069fd54960304 drivers/video/hyperv_fb.c   Gerd Hoffmann 2014-02-26   
996   int gen2vm = efi_enabled(EFI_BOOT);
81d2393485f099 drivers/video/fbdev/hyperv_fb.c Thomas Zimmermann 2022-12-19   
997   resource_size_t base, size;
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09   
998   phys_addr_t paddr;
9069fd54960304 drivers/video/hyperv_fb.c   Gerd Hoffmann 2014-02-26   
999   int ret;
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1000  
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1001   if (!gen2vm) {
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1002   pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1003   PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1004   if (!pdev) {
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1005   pr_err("Unable to find PCI Hyper-V video\n");
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1006   return -ENODEV;
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1007   }
68a2d20b79b105 drivers/video/hyperv_fb.c   Haiyang Zhang 2013-04-29  
1008  
81d2393485f099 drivers/video/fbdev/hyperv_fb.c Thomas Zimmermann 2022-12-19  
1009   base = pci_resource_start(pdev, 0);
81d2393485f099 drivers/video/fbdev/hyperv_fb.c Thomas Zimmermann 2022-12-19  
1010   size = pci_resource_len(pdev, 0);
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1011  
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1012   /*
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1013* For Gen 1 VM, we can directly use the contiguous memory
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1014* from VM. If we succeed, deferred IO happens directly
3a6fb6c4255c38 drivers/video/fbdev/hyperv_fb.c Wei Hu2019-12-09  
1015* on this

Re: [PATCH] drm/nouveau/nvkm/dp: Add hack to fix DP 1.3+ DPCD issues

2023-07-08 Thread Karol Herbst

On Fri, Jul 7, 2023 at 11:58 PM Lyude Paul  wrote:
>
> Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of
> nouveau in order to read the DPCD of a DP connector, which makes sure we do
> the right thing and also check for extended DPCD caps. However, it turns
> out we're not currently doing this on the nvkm side since we don't have
> access to the drm_dp_aux structure there - which means that the DRM side of
> the driver and the NVKM side can end up with different DPCD capabilities
> for the same connector.
>
> Ideally to fix this, we want to start setting up the drm_dp_aux device in
> NVKM before we've made contact with the DRM side - which should be pretty
> easy to accomplish (I'm already working on it!). Until then however, let's
> workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into
> NVKM - which should fix this issue.
>
> Issue: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211

Should a Fixes: or Cc: stable tag be added so it gets backported?

> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 ++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> index 40c8ea43c42f..b8ac66b4a2c4 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c
> @@ -26,6 +26,8 @@
>  #include "head.h"
>  #include "ior.h"
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(struct nvkm_outp 
> *outp)
> return outp->dp.rates != 0;
>  }
>
> +/* XXX: This is a big fat hack, and this is just drm_dp_read_dpcd_caps()

Well.. maybe we should rephrase that _if_ we want to see it
backported. But is this code really that bad? It kinda looks
reasonable enough.

> + * converted to work inside nvkm. This is a temporary holdover until we start
> + * passing the drm_dp_aux device through NVKM
> + */
> +static int
> +nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp)
> +{
> +   struct nvkm_i2c_aux *aux = outp->dp.aux;
> +   u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> +   int ret;
> +
> +   ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, 
> DP_RECEIVER_CAP_SIZE);
> +   if (ret < 0)
> +   return ret;
> +
> +   /*
> +* Prior to DP1.3 the bit represented by
> +* DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> +* If it is set DP_DPCD_REV at h could be at a value less than
> +* the true capability of the panel. The only way to check is to
> +* then compare h and 2200h.
> +*/
> +   if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT))
> +   return 0;
> +
> +   ret = nvkm_rdaux(aux, DP_DP13_DPCD_REV, dpcd_ext, sizeof(dpcd_ext));
> +   if (ret < 0)
> +   return ret;
> +
> +   if (outp->dp.dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) {
> +   OUTP_DBG(outp, "Extended DPCD rev less than base DPCD rev (%d 
> > %d)\n",
> +outp->dp.dpcd[DP_DPCD_REV], dpcd_ext[DP_DPCD_REV]);
> +   return 0;
> +   }
> +
> +   if (!memcmp(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext)))
> +   return 0;
> +
> +   memcpy(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext));
> +
> +   return 0;
> +}
> +
>  void
>  nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
>  {
> @@ -689,7 +735,7 @@ nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr)
> memset(outp->dp.lttpr, 0x00, sizeof(outp->dp.lttpr));
> }
>
> -   if (!nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, 
> sizeof(outp->dp.dpcd))) {
> +   if (!nvkm_dp_read_dpcd_caps(outp)) {
> const u8 rates[] = { 0x1e, 0x14, 0x0a, 0x06, 0 };
> const u8 *rate;
> int rate_max;
> --
> 2.40.1
>

Re: [PATCH v2 1/2] drm/msm/dpu: fix DSC 1.2 block lengths

2023-07-08 Thread Abhinav Kumar





On 7/8/2023 6:00 AM, Dmitry Baryshkov wrote:

All DSC_BLK_1_2 declarations incorrectly pass 0x29c as the block length.
This includes the common block itself, enc subblocks and some empty
space around. Change that to pass 0x4 instead, the length of common
register block itself.

Fixes: 0d1b10c63346 ("drm/msm/dpu: add DSC 1.2 hw blocks for relevant chipsets")
Reported-by: Ryan McCann 
Signed-off-by: Dmitry Baryshkov 
---

Changes since v2:
  - Added Reported-by tag.

---
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   |  8 
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   |  2 +-
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 12 ++--
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   |  8 
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   |  8 
  5 files changed, 19 insertions(+), 19 deletions(-)



Reviewed-by: Abhinav Kumar

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

2023-07-08 Thread Marek Vasut

On 7/8/23 21:40, Dmitry Baryshkov wrote:

On Sat, 8 Jul 2023 at 22:39, Marek Vasut wrote:

On 7/8/23 17:53, Dmitry Baryshkov wrote:

On 08/07/2023 18:40, Marek Vasut wrote:

On 7/7/23 10:47, Neil Armstrong wrote:

On 07/07/2023 09:18, Neil Armstrong wrote:

Hi,

On 06/07/2023 11:20, Amit Pundir wrote:

On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote:

Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as these packets are not required. This makes the
bridge
work with Samsung DSIM on i.MX8MM and i.MX8MP.

This patch broke display on Dragonboard 845c (SDM845) devboard
running
AOSP. This is what I see
https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
Reverting this patch fixes this regression for me.

Might be msm dsi host require proper handling on these updated
mode_flags? did they?

There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
alone and system boots to UI as usual.

MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
screenshot[1] shared earlier as well.

In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
added in this commit break the display on DB845c one way or another.

I think the investigation would be to understand why samsung-dsim
requires
such flags and/or what are the difference in behavior between MSM
DSI and samsung DSIM
for those flags ?

If someone has access to the lt9611 datasheet, so it requires
HSA/HFP/HBP to be
skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?

I don't have the LT9611 datasheet, no.

I also don't have an lt9611 datasheet, unfortunately. I was using the
existing third-party drivers as a source.

The MX8M DSI (samsung-dsim) skips the HSA/HFP/HBP completely (see
i.MX8MP RM 13.6.2.7.2 RGB Interface , there is infographics on the
following pages).

Do you know, why did you have to disable HPB/HSA/HFP on your platform?
What was the result otherwise?

No image on the HDMI monitor at all. This flags change has fixed the
problem for multiple other bridges too btw, not just the LT9611, but
also TI SN65DSI83 and ICN6211. The flags were likely not set in all
those bridge drivers because no DSI host implemented them so far.

MSM DSI host have had those implemented for ages, but we never needed
them AFAIR.

The MSM one is exception in more ways than one it seems (in a positive way).

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

2023-07-08 Thread Dmitry Baryshkov

On Sat, 8 Jul 2023 at 22:39, Marek Vasut  wrote:
>
> On 7/8/23 17:53, Dmitry Baryshkov wrote:
> > On 08/07/2023 18:40, Marek Vasut wrote:
> >> On 7/7/23 10:47, Neil Armstrong wrote:
> >>> On 07/07/2023 09:18, Neil Armstrong wrote:
>  Hi,
> 
>  On 06/07/2023 11:20, Amit Pundir wrote:
> > On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
> >  wrote:
> >>
> >> [Adding freedreno@ to cc list]
> >>
> >> On Wed, 5 Jul 2023 at 08:31, Jagan Teki
> >>  wrote:
> >>>
> >>> Hi Amit,
> >>>
> >>> On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
> >>>  wrote:
> 
>  Hi Marek,
> 
>  On Wed, 5 Jul 2023 at 01:48, Marek Vasut  wrote:
> >
> > Do not generate the HS front and back porch gaps, the HSA gap and
> > EOT packet, as these packets are not required. This makes the
> > bridge
> > work with Samsung DSIM on i.MX8MM and i.MX8MP.
> 
>  This patch broke display on Dragonboard 845c (SDM845) devboard
>  running
>  AOSP. This is what I see
>  https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
>  Reverting this patch fixes this regression for me.
> >>>
> >>> Might be msm dsi host require proper handling on these updated
> >>> mode_flags? did they?
> >>
> >> The msm DSI host supports those flags. Also, I'd like to point out
> >> that the patch didn't change the rest of the driver code. So even if
> >> drm/msm ignored some of the flags, it should not have caused the
> >> issue. Most likely the issue is on the lt9611 side. I's suspect that
> >> additional programming is required to make it work with these flags.
> >
> > I spent some time today on smoke testing these flags (individually and
> > in limited combination) on DB845c, to narrow down this breakage to one
> > or more flag(s) triggering it. Here are my observations in limited
> > testing done so far.
> >
> > There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
> > alone and system boots to UI as usual.
> >
> > MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
> > screenshot[1] shared earlier as well.
> >
> > Adding either of MIPI_DSI_MODE_VIDEO_NO_HSA and
> > MIPI_DSI_MODE_VIDEO_NO_HBP always result in no display, unless paired
> > with MIPI_DSI_MODE_VIDEO_NO_HFP and in that case we get the broken
> > display as reported.
> >
> > In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
> > added in this commit break the display on DB845c one way or another.
> 
>  I think the investigation would be to understand why samsung-dsim
>  requires
>  such flags and/or what are the difference in behavior between MSM
>  DSI and samsung DSIM
>  for those flags ?
> 
>  If someone has access to the lt9611 datasheet, so it requires
>  HSA/HFP/HBP to be
>  skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?
> >>
> >> I don't have the LT9611 datasheet, no.
> >
> > I also don't have an lt9611 datasheet, unfortunately. I was using the
> > existing third-party drivers as a source.
> >
> >>
> >> The MX8M DSI (samsung-dsim) skips the HSA/HFP/HBP completely (see
> >> i.MX8MP RM 13.6.2.7.2 RGB Interface , there is infographics on the
> >> following pages).
> >
> > Do you know, why did you have to disable HPB/HSA/HFP on your platform?
> > What was the result otherwise?
>
> No image on the HDMI monitor at all. This flags change has fixed the
> problem for multiple other bridges too btw, not just the LT9611, but
> also TI SN65DSI83 and ICN6211. The flags were likely not set in all
> those bridge drivers because no DSI host implemented them so far.

MSM DSI host have had those implemented for ages, but we never needed
them AFAIR.

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

2023-07-08 Thread Marek Vasut

On 7/8/23 17:53, Dmitry Baryshkov wrote:

On 08/07/2023 18:40, Marek Vasut wrote:

On 7/7/23 10:47, Neil Armstrong wrote:

On 07/07/2023 09:18, Neil Armstrong wrote:

Hi,

On 06/07/2023 11:20, Amit Pundir wrote:

On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote:

Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as these packets are not required. This makes the
bridge

work with Samsung DSIM on i.MX8MM and i.MX8MP.

This patch broke display on Dragonboard 845c (SDM845) devboard
running

AOSP. This is what I see
https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
Reverting this patch fixes this regression for me.

Might be msm dsi host require proper handling on these updated
mode_flags? did they?

There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
alone and system boots to UI as usual.

MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
screenshot[1] shared earlier as well.

In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
added in this commit break the display on DB845c one way or another.

I think the investigation would be to understand why samsung-dsim
requires
such flags and/or what are the difference in behavior between MSM
DSI and samsung DSIM

for those flags ?

If someone has access to the lt9611 datasheet, so it requires
HSA/HFP/HBP to be

skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?

I don't have the LT9611 datasheet, no.

I also don't have an lt9611 datasheet, unfortunately. I was using the
existing third-party drivers as a source.

The MX8M DSI (samsung-dsim) skips the HSA/HFP/HBP completely (see
i.MX8MP RM 13.6.2.7.2 RGB Interface , there is infographics on the
following pages).

Do you know, why did you have to disable HPB/HSA/HFP on your platform?
What was the result otherwise?

Re: [PATCH 3/9] drm/verisilicon: Add basic drm driver

2023-07-08 Thread Thomas Zimmermann


Hi

Am 07.07.23 um 20:09 schrieb Nicolas Dufresne:
[...]

+config DRM_VERISILICON
+   tristate "DRM Support for VeriSilicon"


Can you rename the driver and files? 'VeriSilicon' seems
unpronounceable. Simply 'StarFive' and starfive/ would be fine.


Are you sure you want to request this ? If the display controller is a
Verisilicon design, it will be super odd to use on other SoC that aren't from
StarFive. Think about STM network driver, which is DesignWare.


It's not a hard requirement. If that's the name, so be it.

Best regards
Thomas



Nicolas




+   depends on DRM
+   select DRM_KMS_HELPER
+   select CMA
+   select DMA_CMA
+   help
+ Choose this option if you have a VeriSilicon soc chipset.
+ This driver provides VeriSilicon kernel mode
+ setting and buffer management. It does not
+ provide 2D or 3D acceleration.
diff --git a/drivers/gpu/drm/verisilicon/Makefile 
b/drivers/gpu/drm/verisilicon/Makefile
new file mode 100644
index ..64ce1b26546c
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+
+vs_drm-objs := vs_drv.o
+
+obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
+
diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c 
b/drivers/gpu/drm/verisilicon/vs_drv.c
new file mode 100644
index ..24d333598477
--- /dev/null
+++ b/drivers/gpu/drm/verisilicon/vs_drv.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vs_drv.h"
+
+#define DRV_NAME   "starfive"
+#define DRV_DESC   "Starfive DRM driver"
+#define DRV_DATE   "202305161"
+#define DRV_MAJOR  1
+#define DRV_MINOR  0
+
+static struct platform_driver vs_drm_platform_driver;
+
+static const struct file_operations fops = {
+   .owner  = THIS_MODULE,
+   .open   = drm_open,
+   .release= drm_release,
+   .unlocked_ioctl = drm_ioctl,
+   .compat_ioctl   = drm_compat_ioctl,
+   .poll   = drm_poll,
+   .read   = drm_read,
+};
+
+static struct drm_driver vs_drm_driver = {
+   .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
+   .lastclose  = drm_fb_helper_lastclose,
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .fops   = ,
+   .name   = DRV_NAME,
+   .desc   = DRV_DESC,
+   .date   = DRV_DATE,
+   .major  = DRV_MAJOR,
+   .minor  = DRV_MINOR,
+};
+
+void vs_drm_update_pitch_alignment(struct drm_device *drm_dev,
+  unsigned int alignment)
+{
+   struct vs_drm_private *priv = drm_dev->dev_private;
+
+   if (alignment > priv->pitch_alignment)
+   priv->pitch_alignment = alignment;
+}
+
+static int vs_drm_bind(struct device *dev)
+{
+   struct drm_device *drm_dev;
+   struct vs_drm_private *priv;
+   int ret;
+   static u64 dma_mask = DMA_BIT_MASK(40);
+
+   /* Remove existing drivers that may own the framebuffer memory. */
+   ret = drm_aperture_remove_framebuffers(false, _drm_driver);
+   if (ret) {
+   DRM_DEV_ERROR(dev,


drm_err(), drm_info(), drm_warn(), etc.  Here and everwhere else. The
DRM_DEV_*() print macros are obsolete.


+ "Failed to remove existing framebuffers - %d.\n",
+ ret);
+   return ret;
+   }
+
+   drm_dev = drm_dev_alloc(_drm_driver, dev);
+   if (IS_ERR(drm_dev))
+   return PTR_ERR(drm_dev);
+
+   dev_set_drvdata(dev, drm_dev);
+
+   priv = devm_kzalloc(drm_dev->dev, sizeof(struct vs_drm_private),
+   GFP_KERNEL);
+   if (!priv) {
+   ret = -ENOMEM;
+   goto err_put_dev;
+   }
+
+   priv->pitch_alignment = 64;
+   priv->dma_dev = drm_dev->dev;
+   priv->dma_dev->coherent_dma_mask = dma_mask;
+   drm_dev->dev_private = priv;


dev_private is obsolete and about to go away at some point.

Please embed drm_device in vs_drm_private and allocate the memory with
devm_drm_dev_alloc().


+
+   drm_mode_config_init(drm_dev);


drmm_mode_config_init() please.


+
+   /* Now try and bind all our sub-components */
+   ret = component_bind_all(dev, drm_dev);
+   if (ret)
+   goto err_mode;
+
+   ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
+   if (ret)
+   goto err_bind;
+
+

Re: [PATCH 2/2] drm: bridge: tc358767: give VSDELAY some positive value

2023-07-08 Thread Marek Vasut


On 6/8/23 10:11, Lucas Stach wrote:

Am Mittwoch, dem 07.06.2023 um 15:54 +0200 schrieb Marek Vasut:

On 6/7/23 14:53, Lucas Stach wrote:

Am Freitag, dem 02.06.2023 um 23:34 +0200 schrieb Marek Vasut:

On 6/2/23 21:15, Lucas Stach wrote:

From: David Jander 

The documentation is not clear about how this delay works.
Empirical tests have shown that with a VSDELAY of 0, the first
scanline is not properly formatted in the output stream when
DSI->DP mode is used. The calculation spreadsheets from Toshiba
seem to always make this value equal to the HFP + 10 for DSI->DP
use-case. For DSI->DPI this value should be > 2 and for DPI->DP
it seems to always be 0x64.

Signed-off-by: David Jander 
Signed-off-by: Lucas Stach 
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 46916ae30f8f..9f2c67b4a488 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -817,7 +817,7 @@ static int tc_set_common_video_mode(struct tc_data *tc,
 * sync signals
 */
ret = regmap_write(tc->regmap, VPCTRL0,
-  FIELD_PREP(VSDELAY, 0) |
+  FIELD_PREP(VSDELAY, right_margin + 10) |
   OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
if (ret)
return ret;


Aren't you running into a problem due to VS timing misconfiguration on
the scanout engine or DSI serializer side ? The VSDELAY seems to
increase the length of VSYNC active .



No, as far as I understand the VSDELAY adds an offset between input an
output side of the video FIFO. It shouldn't increase the length of any
sync signal, but delays the read side of the FIFO, so the write (DSI)
side has some margin to put data into the FIFO before DP side starts to
assemble packets.


Does this apply to DSI-to-DPI mode too ?


I guess it does the same thing, but the technical documents I have
don't really say anything about it. I don't think the VSDELAY really
matters in the DPI output case, as DPI is much slower in pulling data
out of the FIFO compared to the DP packetizing, so the DSI side should
always be able to keep up with the DPI side.




   Which DSI bus mode do you use, sync events/pulses/burst ?


At the time when this patch was written it still was the SYNC_PULSE
mode.


Can you please double-check this with current burst mode ?


It works fine on a hardware in DSI to DPI mode. I could check that
things are still as expected in DSI to DP mode later, but I don't
expect any issues.


Tested-by: Marek Vasut  # TC9595
Reviewed-by: Marek Vasut 

Sorry for the delay

Re: [PATCH 1/2] drm: bridge: tc358767: increase PLL lock time delay

2023-07-08 Thread Marek Vasut


On 6/2/23 21:15, Lucas Stach wrote:

From: David Jander 

The PLL often fails to lock with this delay. The new value was
determined by trial and error increasing the delay bit by bit
until the error did not occurr anymore even after several tries.
Then double that value was taken as the minimum delay to be safe.

Signed-off-by: David Jander 
Signed-off-by: Lucas Stach 


Tested-by: Marek Vasut  # TC9595
Reviewed-by: Marek Vasut

Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet

2023-07-08 Thread Dmitry Baryshkov

On 08/07/2023 18:40, Marek Vasut wrote:

On 7/7/23 10:47, Neil Armstrong wrote:

On 07/07/2023 09:18, Neil Armstrong wrote:

Hi,

On 06/07/2023 11:20, Amit Pundir wrote:

On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote:

Do not generate the HS front and back porch gaps, the HSA gap and
EOT packet, as these packets are not required. This makes the
bridge

work with Samsung DSIM on i.MX8MM and i.MX8MP.

This patch broke display on Dragonboard 845c (SDM845) devboard
running

AOSP. This is what I see
https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
Reverting this patch fixes this regression for me.

Might be msm dsi host require proper handling on these updated
mode_flags? did they?

There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
alone and system boots to UI as usual.

MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
screenshot[1] shared earlier as well.

In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
added in this commit break the display on DB845c one way or another.

I think the investigation would be to understand why samsung-dsim
requires
such flags and/or what are the difference in behavior between MSM DSI
and samsung DSIM

for those flags ?

If someone has access to the lt9611 datasheet, so it requires
HSA/HFP/HBP to be

skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?

I don't have the LT9611 datasheet, no.

I also don't have an lt9611 datasheet, unfortunately. I was using the
existing third-party drivers as a source.

The MX8M DSI (samsung-dsim) skips the HSA/HFP/HBP completely (see
i.MX8MP RM 13.6.2.7.2 RGB Interface , there is infographics on the
following pages).

Do you know, why did you have to disable HPB/HSA/HFP on your platform?
What was the result otherwise?

I think there's a mismatch, where on one side this flags sets the link
in LP-11 while
in HSA/HFP/HPB while on the other it completely removes those blanking
packets.

The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not LP-11
while HPB.

the registers used in both controllers are different:
- samsung-dsim: DSIM_HBP_DISABLE_MODE
- msm dsi: DSI_VID_CFG0_HBP_POWER_STOP

The first one suggest removing the packet, while the second one
suggests powering

off the line while in the blanking packet period.

@Abhinav, can you comment on that ?

@Jagan, Andrezej So you have any documentation on what
DSIM_xxx_DISABLE_MODE does ?

See above, i.MX8M M/N/P uses the samsung-dsim block .

@Dmitry, so you have access to the lt9611 datasheet to know what's
needed here ?

[...]

--
With best wishes
Dmitry