[PATCH v11 0/7] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ

2023-10-17 Thread Sandor Yu
The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge
drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ.

The patch set compose of DRM bridge drivers and PHY drivers.

Both of them need patche #1 and #2 to pass build.

DRM bridges driver patches:
  #1: drm: bridge: Cadence: Creat mhdp helper driver
  #2: phy: Add HDMI configuration options
  #3: dt-bindings: display: bridge: Add Cadence MHDP8501
  #4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

PHY driver patches:
  #1: drm: bridge: Cadence: Creat mhdp helper driver
  #2: phy: Add HDMI configuration options
  #5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
  #6: phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
  #7: phy: freescale: Add HDMI PHY driver for i.MX8MQ

v10->v11:
- rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.
- use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
and remove them from EXPORT_SYMBOL_GPL().
- remove MODULE_ALIAS() from mhdp8501 driver.

v9->v10:
- Create mhdp helper driver to replace macro functions,
move all mhdp mailbox access functions and common functions
into the helper driver.
Patch #1:drm: bridge: Cadence: Creat mhdp helper driver
it is totaly different with v9.

v8->v9:
- Remove compatible string "cdns,mhdp8501" that had removed
  from dt-bindings file in v8.
- Add Dmitry's R-b tag to patch #2
- Add Krzysztof's R-b tag to patch #3

v7->v8:
MHDP8501 HDMI/DP:
- Correct DT node name to "display-bridge".
- Remove "cdns,mhdp8501" from mhdp8501 dt-binding doc.

HDMI/DP PHY:
- Introduced functions `wait_for_ack` and `wait_for_ack_clear` to handle
  waiting with acknowledgment bits set and cleared respectively.
- Use FIELD_PRE() to set bitfields for both HDMI and DP PHY.

v6->v7:
MHDP8501 HDMI/DP:
- Combine HDMI and DP driver into one mhdp8501 driver.
  Use the connector type to load the corresponding functions.
- Remove connector init functions.
- Add  in phy_hdmi.h to reuse ‘enum hdmi_colorspace’.

HDMI/DP PHY:
- Lowercase hex values
- Fix parameters indent issue on some functions
- Replace ‘udelay’ with ‘usleep_range’

v5->v6:
HDMI/DP bridge driver
- 8501 is the part number of Cadence MHDP on i.MX8MQ.
  Use MHDP8501 to name hdmi/dp drivers and files. 
- Add compatible "fsl,imx8mq-mhdp8501-dp" for i.MX8MQ DP driver
- Add compatible "fsl,imx8mq-mhdp8501-hdmi" for i.MX8MQ HDMI driver
- Combine HDMI and DP dt-bindings into one file cdns,mhdp8501.yaml
- Fix HDMI scrambling is not enable issue when driver working in 4Kp60
  mode.
- Add HDMI/DP PHY API mailbox protect.

HDMI/DP PHY driver:
- Rename DP and HDMI PHY files and move to folder phy/freescale/
- Remove properties num_lanes and link_rate from DP PHY driver.
- Combine HDMI and DP dt-bindings into one file fsl,imx8mq-dp-hdmi-phy.yaml
- Update compatible string to "fsl,imx8mq-dp-phy".
- Update compatible string to "fsl,imx8mq-hdmi-phy".

v4->v5:
- Drop "clk" suffix in clock name.
- Add output port property in the example of hdmi/dp.

v3->v4:
dt-bindings:
- Correct dt-bindings coding style and address review comments.
- Add apb_clk description.
- Add output port for HDMI/DP connector
PHY:
- Alphabetically sorted in Kconfig and Makefile for DP and HDMI PHY
- Remove unused registers define from HDMI and DP PHY drivers.
- More description in phy_hdmi.h.
- Add apb_clk to HDMI and DP phy driver.
HDMI/DP:
- Use get_unaligned_le32() to replace hardcode type conversion
  in HDMI AVI infoframe data fill function.
- Add mailbox mutex lock in HDMI/DP driver for phy functions
  to reslove race conditions between HDMI/DP and PHY drivers.
- Add apb_clk to both HDMI and DP driver.
- Rename some function names and add prefix with "cdns_hdmi/cdns_dp".
- Remove bpc 12 and 16 optional that not supported.

v2->v3:
Address comments for dt-bindings files.
- Correct dts-bindings file names 
  Rename phy-cadence-hdptx-dp.yaml to cdns,mhdp-imx8mq-dp.yaml
  Rename phy-cadence-hdptx-hdmi.yaml to cdns,mhdp-imx8mq-hdmi.yaml
- Drop redundant words and descriptions.
- Correct hdmi/dp node name.

v2 is a completely different version compared to v1.
Previous v1 can be available here [1].

v1->v2:
- Reuse Cadence mailbox access functions from mhdp8546 instead of
  rockchip DP.
- Mailbox access functions be convert to marco functions
  that will be referenced by HDP-TX PHY(HDMI/DP) driver too.
- Plain bridge instead of component driver.
- Standalone Cadence HDP-TX PHY(HDMI/DP) driver.
- Audio driver are removed from the patch set, it will be add in another
  patch set later.

[1] 
https://patchwork.kernel.org/project/linux-rockchip/cover/cover.1590982881.git.sandor...@nxp.com/
Sandor Yu (7):
  drm: bridge: Cadence: Creat mhdp helper driver
  phy: Add HDMI configuration options
  dt-bindings: display: bridge: Add Cadence MHDP8501
  drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
  dt-bindings: phy: Add Freescale i

[PATCH v11 1/7] drm: bridge: Cadence: Creat mhdp helper driver

2023-10-17 Thread Sandor Yu
MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Create a new mhdp helper driver and move all those functions into.

cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
because it use the DPTX command ID DPTX_WRITE_REGISTER.

New cdns_mhdp_reg_write() is created with the general command ID
GENERAL_REGISTER_WRITE.

rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.

Signed-off-by: Sandor Yu 
---
v10->v11:
- rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.
- use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
and remove them from EXPORT_SYMBOL_GPL().

v9->v10:
 *use mhdp helper driver to replace macro functions,
 move maibox access function and mhdp hdmi/dp common API
 functions into the driver.

 drivers/gpu/drm/bridge/cadence/Kconfig|   4 +
 drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
 .../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 304 +
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 403 +++---
 .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  44 +-
 include/drm/bridge/cdns-mhdp-helper.h |  94 
 6 files changed, 476 insertions(+), 374 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
 create mode 100644 include/drm/bridge/cdns-mhdp-helper.h

diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..0b7b4626a7af0 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -20,6 +20,9 @@ config DRM_CDNS_DSI_J721E
  the routing of the DSS DPI signal to the Cadence DSI.
 endif
 
+config CDNS_MHDP_HELPER
+   tristate
+
 config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
@@ -27,6 +30,7 @@ config DRM_CDNS_MHDP8546
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
+   select CDNS_MHDP_HELPER
depends on OF
help
  Support Cadence DPI to DP bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d137..087dc074820d7 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 cdns-dsi-y := cdns-dsi-core.o
 cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
 obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
 cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
 cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
new file mode 100644
index 0..8cabd79ad9663
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 NXP Semiconductor, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+
+/* Mailbox helper functions */
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base)
+{
+   int ret, empty;
+
+   WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+   ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+   if (ret < 0)
+   return ret;
+
+   return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val)
+{
+   int ret, full;
+
+   WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+   ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+   if (ret < 0)
+   return ret;
+
+   writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
+
+   return 0;
+}
+
+int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+   u32 mbox_size, i;
+   u8 header[4];
+   int ret;
+
+   /* read the header of the message */
+   for (i = 0; i < sizeof(header); i++) {
+   ret = cdns_mhdp_mailbox_read(base);
+   if (ret < 0)
+   return ret;
+
+   header[i] = ret;
+   }
+
+   mbox_size = get_unaligned_be16(header + 2);
+
+   if (opcode != header[0] || module_id != header[1] ||
+   req_size != mbox_size) {
+

[PATCH v11 2/7] phy: Add HDMI configuration options

2023-10-17 Thread Sandor Yu
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.

The parameters added here are based on HDMI PHY
implementation practices.  The current set of parameters
should cover the potential users.

Signed-off-by: Sandor Yu 
Reviewed-by: Dmitry Baryshkov 
Acked-by: Vinod Koul 
---
v9->v11:
 *No change.

 include/linux/phy/phy-hdmi.h | 24 
 include/linux/phy/phy.h  |  7 ++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/phy/phy-hdmi.h

diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
new file mode 100644
index 0..b7de88e9090f0
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+#include 
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate: Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+   unsigned int pixel_clk_rate;
+   unsigned int bpc;
+   enum hdmi_colorspace color_space;
+};
+
+#endif /* __PHY_HDMI_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f6d607ef0e801..94d489a8a163c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -42,7 +43,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
-   PHY_MODE_DP
+   PHY_MODE_DP,
+   PHY_MODE_HDMI,
 };
 
 enum phy_media {
@@ -60,11 +62,14 @@ enum phy_media {
  * the DisplayPort protocol.
  * @lvds:  Configuration set applicable for phys supporting
  * the LVDS phy mode.
+ * @hdmi:  Configuration set applicable for phys supporting
+ * the HDMI phy mode.
  */
 union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
struct phy_configure_opts_lvds  lvds;
+   struct phy_configure_opts_hdmi  hdmi;
 };
 
 /**
-- 
2.34.1



[PATCH v11 3/7] dt-bindings: display: bridge: Add Cadence MHDP8501

2023-10-17 Thread Sandor Yu
Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.

Signed-off-by: Sandor Yu 
Reviewed-by: Krzysztof Kozlowski 
---
v9->v11:
 *No change.

 .../display/bridge/cdns,mhdp8501.yaml | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml 
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
new file mode 100644
index 0..3ae643845cfee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP8501 DP/HDMI bridge
+
+maintainers:
+  - Sandor Yu 
+
+description:
+  Cadence MHDP8501 DisplayPort/HDMI interface.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8mq-mhdp8501
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+description: MHDP8501 DP/HDMI APB clock.
+
+  phys:
+maxItems: 1
+description:
+  phandle to the DisplayPort or HDMI PHY
+
+  interrupts:
+items:
+  - description: Hotplug cable plugin.
+  - description: Hotplug cable plugout.
+
+  interrupt-names:
+items:
+  - const: plug_in
+  - const: plug_out
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Input port from display controller output.
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output port to DisplayPort or HDMI connector.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+  - interrupt-names
+  - phys
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+mhdp: display-bridge@32c0 {
+compatible = "fsl,imx8mq-mhdp8501";
+reg = <0x32c0 0x10>;
+interrupts = ,
+ ;
+interrupt-names = "plug_in", "plug_out";
+clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+phys = <&dp_phy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+mhdp_in: endpoint {
+remote-endpoint = <&dcss_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mhdp_out: endpoint {
+remote-endpoint = <&dp_connector>;
+};
+};
+};
+};
-- 
2.34.1



[PATCH v11 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

2023-10-17 Thread Sandor Yu
Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
standards according embedded Firmware running in the uCPU.

For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
SOC's ROM code. Bootload binary included respective specific firmware
is required.

Driver will check display connector type and
then load the corresponding driver.

Signed-off-by: Sandor Yu 
Tested-by: Alexander Stein 
---
v10->v11:
- remove MODULE_ALIAS() from mhdp8501 driver.

v9->v10:
 - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
 - update for mhdp helper driver is introduced.
Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
Add struct cdns_mhdp_base base to struct cdns_mhdp8501_device.
Init struct cdns_mhdp_base base when driver probe.

 drivers/gpu/drm/bridge/cadence/Kconfig|  16 +
 drivers/gpu/drm/bridge/cadence/Makefile   |   2 +
 .../drm/bridge/cadence/cdns-mhdp8501-core.c   | 315 
 .../drm/bridge/cadence/cdns-mhdp8501-core.h   | 365 +
 .../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 708 ++
 .../drm/bridge/cadence/cdns-mhdp8501-hdmi.c   | 673 +
 6 files changed, 2079 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c

diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 0b7b4626a7af0..81685ab4e874a 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -50,3 +50,19 @@ config DRM_CDNS_MHDP8546_J721E
  initializes the J721E Display Port and sets up the
  clock and data muxes.
 endif
+
+config DRM_CDNS_MHDP8501
+   tristate "Cadence MHDP8501 DP/HDMI bridge"
+   select DRM_KMS_HELPER
+   select DRM_PANEL_BRIDGE
+   select DRM_DISPLAY_DP_HELPER
+   select DRM_DISPLAY_HELPER
+   select CDNS_MHDP_HELPER
+   select DRM_CDNS_AUDIO
+   depends on OF
+   help
+ Support Cadence MHDP8501 DisplayPort/HDMI bridge.
+ Cadence MHDP8501 support one or more protocols,
+ including DisplayPort and HDMI.
+ To use the DP and HDMI drivers, their respective
+ specific firmware is required.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
b/drivers/gpu/drm/bridge/cadence/Makefile
index 087dc074820d7..02c1a9f3cf6fc 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
 obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
 cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
 cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
+obj-$(CONFIG_DRM_CDNS_MHDP8501) += cdns-mhdp8501.o
+cdns-mhdp8501-y := cdns-mhdp8501-core.o cdns-mhdp8501-dp.o cdns-mhdp8501-hdmi.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
new file mode 100644
index 0..23860a260e637
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) driver
+ *
+ * Copyright (C) 2023 NXP Semiconductor, Inc.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cdns-mhdp8501-core.h"
+
+static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
+{
+   u8 status;
+   int ret;
+
+   mutex_lock(&mhdp->mbox_mutex);
+
+   ret = cdns_mhdp_mailbox_send(&mhdp->base, MB_MODULE_ID_GENERAL,
+GENERAL_GET_HPD_STATE, 0, NULL);
+   if (ret)
+   goto err_get_hpd;
+
+   ret = cdns_mhdp_mailbox_recv_header(&mhdp->base, MB_MODULE_ID_GENERAL,
+   GENERAL_GET_HPD_STATE,
+   sizeof(status));
+   if (ret)
+   goto err_get_hpd;
+
+   ret = cdns_mhdp_mailbox_recv_data(&mhdp->base, &status, sizeof(status));
+   if (ret)
+   goto err_get_hpd;
+
+   mutex_unlock(&mhdp->mbox_mutex);
+
+   return status;
+
+err_get_hpd:
+   DRM_ERROR("read hpd  failed: %d\n", ret);
+   mutex_unlock(&mhdp->mbox_mutex);
+
+   return ret;
+}
+
+enum drm_connector_status cdns_mhdp8501_detect(struct cdns_mhdp8501_device 
*mhdp)
+{
+   u8 hpd = 0xf;
+
+   hpd = cdns_mhdp8501_read_hpd(mhdp);
+   if (hpd == 1)
+   return connector_status_connected;
+   else if (hpd == 0)
+   return connector_status_disconnected;
+
+   DRM_INFO("Unknown cable status, hdp=%u\n", hpd);
+   return connector_status_unknown;
+}
+
+

[PATCH v11 5/7] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY

2023-10-17 Thread Sandor Yu
Add bindings for Freescale iMX8MQ DP and HDMI PHY.

Signed-off-by: Sandor Yu 
Reviewed-by: Rob Herring 
---
v9->v11:
 *No change.

 .../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml  | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml 
b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
new file mode 100644
index 0..917f113503dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mq-dp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
+
+maintainers:
+  - Sandor Yu 
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8mq-dp-phy
+  - fsl,imx8mq-hdmi-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: PHY reference clock.
+  - description: APB clock.
+
+  clock-names:
+items:
+  - const: ref
+  - const: apb
+
+  "#phy-cells":
+const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+dp_phy: phy@32c0 {
+compatible = "fsl,imx8mq-dp-phy";
+reg = <0x32c0 0x10>;
+#phy-cells = <0>;
+clocks = <&hdmi_phy_27m>, <&clk IMX8MQ_CLK_DISP_APB_ROOT>;
+clock-names = "ref", "apb";
+};
-- 
2.34.1



[PATCH v11 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ

2023-10-17 Thread Sandor Yu
Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ

Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
DisplayPort PHY mode is configurated in the driver.

Signed-off-by: Sandor Yu 
---
v9->v11:
 *No change.

 drivers/phy/freescale/Kconfig |  10 +
 drivers/phy/freescale/Makefile|   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 720 ++
 3 files changed, 731 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c063..c39709fd700ac 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE
  Enable this to add support for the PCIE PHY as found on
  i.MX8M family of SOCs.
 
+config PHY_FSL_IMX8MQ_DP
+   tristate "Freescale i.MX8MQ DP PHY support"
+   depends on OF && HAS_IOMEM
+   depends on COMMON_CLK
+   select GENERIC_PHY
+   select CDNS_MHDP_HELPER
+   help
+ Enable this to support the Cadence HDPTX DP PHY driver
+ on i.MX8MQ SOC.
+
 endif
 
 config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index cedb328bc4d28..47e5285209fa8 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)   += phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)   += phy-fsl-imx8qm-lvds-phy.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)  += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c 
b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
new file mode 100644
index 0..5f0d7da16b422
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
@@ -0,0 +1,720 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence HDP-TX Display Port Interface (DP) PHY driver
+ *
+ * Copyright (C) 2022, 2023 NXP Semiconductor, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_PHY_AFE   0x8
+
+/* PHY registers */
+#define CMN_SSM_BIAS_TMR   0x0022
+#define CMN_PLLSM0_PLLEN_TMR   0x0029
+#define CMN_PLLSM0_PLLPRE_TMR  0x002a
+#define CMN_PLLSM0_PLLVREF_TMR 0x002b
+#define CMN_PLLSM0_PLLLOCK_TMR 0x002c
+#define CMN_PLLSM0_USER_DEF_CTRL   0x002f
+#define CMN_PSM_CLK_CTRL   0x0061
+#define CMN_PLL0_VCOCAL_START  0x0081
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085
+#define CMN_PLL0_INTDIV0x0094
+#define CMN_PLL0_FRACDIV   0x0095
+#define CMN_PLL0_HIGH_THR  0x0096
+#define CMN_PLL0_DSM_DIAG  0x0097
+#define CMN_PLL0_SS_CTRL2  0x0099
+#define CMN_ICAL_INIT_TMR  0x00c4
+#define CMN_ICAL_ITER_TMR  0x00c5
+#define CMN_RXCAL_INIT_TMR 0x00d4
+#define CMN_RXCAL_ITER_TMR 0x00d5
+#define CMN_TXPUCAL_INIT_TMR   0x00e4
+#define CMN_TXPUCAL_ITER_TMR   0x00e5
+#define CMN_TXPDCAL_INIT_TMR   0x00f4
+#define CMN_TXPDCAL_ITER_TMR   0x00f5
+#define CMN_ICAL_ADJ_INIT_TMR  0x0102
+#define CMN_ICAL_ADJ_ITER_TMR  0x0103
+#define CMN_RX_ADJ_INIT_TMR0x0106
+#define CMN_RX_ADJ_ITER_TMR0x0107
+#define CMN_TXPU_ADJ_INIT_TMR  0x010a
+#define CMN_TXPU_ADJ_ITER_TMR  0x010b
+#define CMN_TXPD_ADJ_INIT_TMR  0x010e
+#define CMN_TXPD_ADJ_ITER_TMR  0x010f
+#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0
+#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1
+#define CMN_DIAG_PLL0_OVRD 0x01c2
+#define CMN_DIAG_PLL0_TEST_MODE0x01c4
+#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5
+#define CMN_DIAG_PLL0_CP_TUNE  0x01c6
+#define CMN_DIAG_PLL0_LF_PROG  0x01c7
+#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8
+#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9
+#define CMN_DIAG_HSCLK_SEL 0x01e0
+#define CMN_DIAG_PER_CAL_ADJ   0x01ec
+#define CMN_DIAG_CAL_CTRL  0x01ed
+#define CMN_DIAG_ACYA  0x01ff
+#define XCVR_PSM_RCTRL 0x4001
+#define XCVR_PSM_CAL_TMR   0x4002
+#define XCVR_PSM_A0IN_TMR  0x4003
+#define TX_TXCC_CAL_SCLR_MULT_00x4047
+#define TX_TXCC_CPOST_MULT_00_00x

[PATCH v11 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ

2023-10-17 Thread Sandor Yu
Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.

Cadence HDP-TX PHY could be put in either DP mode or
HDMI mode base on the configuration chosen.
HDMI PHY mode is configurated in the driver.

Signed-off-by: Sandor Yu 
Tested-by: Alexander Stein 
---
v9->v11:
 *No change.

 drivers/phy/freescale/Kconfig   |  10 +
 drivers/phy/freescale/Makefile  |   1 +
 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 961 
 3 files changed, 972 insertions(+)
 create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c

diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index c39709fd700ac..14f47b7cc77ab 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP
  Enable this to support the Cadence HDPTX DP PHY driver
  on i.MX8MQ SOC.
 
+config PHY_FSL_IMX8MQ_HDMI
+   tristate "Freescale i.MX8MQ HDMI PHY support"
+   depends on OF && HAS_IOMEM
+   depends on COMMON_CLK
+   select GENERIC_PHY
+   select CDNS_MHDP_HELPER
+   help
+ Enable this to support the Cadence HDPTX HDMI PHY driver
+ on i.MX8MQ SOC.
+
 endif
 
 config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index 47e5285209fa8..1380ac31c2ead 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o
+obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI)  += phy-fsl-imx8mq-hdmi.o
 obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)   += phy-fsl-imx8mq-usb.o
 obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)   += phy-fsl-imx8qm-lvds-phy.o
 obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)  += phy-fsl-imx8-mipi-dphy.o
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c 
b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
new file mode 100644
index 0..9722b5e1803c7
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
@@ -0,0 +1,961 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence High-Definition Multimedia Interface (HDMI) PHY driver
+ *
+ * Copyright (C) 2022,2023 NXP Semiconductor, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADDR_PHY_AFE   0x8
+
+/* PHY registers */
+#define CMN_SSM_BIAS_TMR   0x0022
+#define CMN_PLLSM0_USER_DEF_CTRL   0x002f
+#define CMN_PSM_CLK_CTRL   0x0061
+#define CMN_CDIAG_REFCLK_CTRL  0x0062
+#define CMN_PLL0_VCOCAL_START  0x0081
+#define CMN_PLL0_VCOCAL_INIT_TMR   0x0084
+#define CMN_PLL0_VCOCAL_ITER_TMR   0x0085
+#define CMN_TXPUCAL_CTRL   0x00e0
+#define CMN_TXPDCAL_CTRL   0x00f0
+#define CMN_TXPU_ADJ_CTRL  0x0108
+#define CMN_TXPD_ADJ_CTRL  0x010c
+#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0
+#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1
+#define CMN_DIAG_PLL0_OVRD 0x01c2
+#define CMN_DIAG_PLL0_TEST_MODE0x01c4
+#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5
+#define CMN_DIAG_PLL0_CP_TUNE  0x01c6
+#define CMN_DIAG_PLL0_LF_PROG  0x01c7
+#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8
+#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9
+#define CMN_DIAG_PLL0_INCLK_CTRL   0x01ca
+#define CMN_DIAG_PLL0_PXL_DIVH 0x01cb
+#define CMN_DIAG_PLL0_PXL_DIVL 0x01cc
+#define CMN_DIAG_HSCLK_SEL 0x01e0
+#define XCVR_PSM_RCTRL 0x4001
+#define TX_TXCC_CAL_SCLR_MULT_00x4047
+#define TX_TXCC_CPOST_MULT_00_00x404c
+#define XCVR_DIAG_PLLDRC_CTRL  0x40e0
+#define XCVR_DIAG_PLLDRC_CTRL  0x40e0
+#define XCVR_DIAG_HSCLK_SEL0x40e1
+#define XCVR_DIAG_BIDI_CTRL0x40e8
+#define TX_PSC_A0  0x4100
+#define TX_PSC_A1  0x4101
+#define TX_PSC_A2  0x4102
+#define TX_PSC_A3  0x4103
+#define TX_DIAG_TX_CTRL0x41e0
+#define TX_DIAG_TX_DRV 0x41e1
+#define TX_DIAG_BGREF_PREDRV_DELAY 0x41e7
+#define TX_DIAG_ACYA_0 0x41ff
+#define TX_DIAG_ACYA_1 0x43ff
+#define TX_DIAG_ACYA_2 0x45ff
+#define TX_DIAG_ACYA_3 0x47ff
+#define TX_ANA_CTRL_REG_1  0x5020
+#define TX_ANA_CTRL_REG_2  0x5021
+#define TX_DIG_CTRL_REG_2  0x5024
+#define TXDA_CYA_AUXDA_CYA 0x5025
+#define TX_ANA_CTRL_REG_3  0x5026
+#define TX_ANA_CTR

Re: [Freedreno] [PATCH RFC v6 07/10] drm/atomic: Loosen FB atomic checks

2023-10-17 Thread Dmitry Baryshkov
Hi Jessica,

On Tue, 17 Oct 2023 at 03:41, Jessica Zhang  wrote:
> On 9/24/2023 3:23 AM, Dmitry Baryshkov wrote:
> > On 22/09/2023 20:49, Jessica Zhang wrote:
> >>
> >>
> >> On 8/29/2023 1:22 AM, Pekka Paalanen wrote:
> >>> On Mon, 28 Aug 2023 17:05:13 -0700
> >>> Jessica Zhang  wrote:
> >>>
>  Loosen the requirements for atomic and legacy commit so that, in cases
>  where pixel_source != FB, the commit can still go through.
> 
>  This includes adding framebuffer NULL checks in other areas to
>  account for
>  FB being NULL when non-FB pixel sources are enabled.
> 
>  To disable a plane, the pixel_source must be NONE or the FB must be
>  NULL
>  if pixel_source == FB.
> 
>  Signed-off-by: Jessica Zhang 
>  ---
>    drivers/gpu/drm/drm_atomic.c| 20 +++-
>    drivers/gpu/drm/drm_atomic_helper.c | 36
>  
>    include/drm/drm_atomic_helper.h |  4 ++--
>    include/drm/drm_plane.h | 29
>  +
>    4 files changed, 62 insertions(+), 27 deletions(-)
> >>>
> >>> ...
> >>>
>  diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
>  index a58f84b6bd5e..4c5b7bcdb25c 100644
>  --- a/include/drm/drm_plane.h
>  +++ b/include/drm/drm_plane.h
>  @@ -992,6 +992,35 @@ static inline struct drm_plane
>  *drm_plane_find(struct drm_device *dev,
>    #define drm_for_each_plane(plane, dev) \
>    list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
>  +/**
>  + * drm_plane_solid_fill_enabled - Check if solid fill is enabled on
>  plane
>  + * @state: plane state
>  + *
>  + * Returns:
>  + * Whether the plane has been assigned a solid_fill_blob
>  + */
>  +static inline bool drm_plane_solid_fill_enabled(struct
>  drm_plane_state *state)
>  +{
>  +if (!state)
>  +return false;
>  +return state->pixel_source == DRM_PLANE_PIXEL_SOURCE_SOLID_FILL
>  && state->solid_fill_blob;
>  +}
>  +
>  +static inline bool drm_plane_has_visible_data(const struct
>  drm_plane_state *state)
>  +{
>  +switch (state->pixel_source) {
>  +case DRM_PLANE_PIXEL_SOURCE_NONE:
>  +return false;
>  +case DRM_PLANE_PIXEL_SOURCE_SOLID_FILL:
>  +return state->solid_fill_blob != NULL;
> >>>
> >>> This reminds me, new UAPI docs did not say what the requirements are for
> >>> choosing solid fill pixel source. Is the atomic commit rejected if
> >>> pixel source is solid fill, but solid_fill property has no blob?
> >>
> >> Hi Pekka,
> >>
> >> Yes, if pixel_source is solid_fill and the solid_fill property blob
> >> isn't set, the atomic commit should throw an error.
> >>
> >> Will document this in the UAPI.
> >
> > I don't see a corresponding error check in atomic_check() functions.
> > Could you please check that there is one, as you are updating the uAPI.
>
> Hi Dmitry,
>
> Sorry for the late response.

No worries.

>
> drm_plane_has_visible_data() is being called from
> drm_atomic_plane_check() which is called from drm_atomic_commit() (via
> drm_atomic_check_only()).
>
> It's also called within the atomic_check() callstack in
> drm_atomic_helper_check_plane_state(), though that check will set
> plane.visible to false and return 0.
>
> Would it be better to have a more explicit `if (source == solid_fill &&
> !plane->solid_fill_blob) then return -EINVAL` check in atomic_check()?

No. Your current code is good already. It was me who missed the
visible data check.
If you are going to send the next version for some reason, it might be
good to add a small comment to drm_atomic_helper_check_plane_state().
Something like 'check that the selected pixel source (fb, solid fill,
etc.) is valid'.

>
> Thanks,
>
> Jessica Zhang
>
> >
> >>
> >> Thanks,
> >>
> >> Jessica Zhang
> >>
> >>>
> >>> This should be doc'd.
> >>>
> >>>
> >>> Thanks,
> >>> pq
> >>>
>  +case DRM_PLANE_PIXEL_SOURCE_FB:
>  +default:
>  +WARN_ON(state->pixel_source != DRM_PLANE_PIXEL_SOURCE_FB);
>  +}
>  +
>  +return state->fb != NULL;
>  +}
>  +
>    bool drm_any_plane_has_format(struct drm_device *dev,
>  u32 format, u64 modifier);
> 
> >>>
> >
> > --
> > With best wishes
> > Dmitry
> >



-- 
With best wishes
Dmitry


Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

2023-10-17 Thread Daniel Vetter
On Fri, Oct 13, 2023 at 12:22:52PM +0200, Michel Dänzer wrote:
> On 10/13/23 11:41, Daniel Vetter wrote:
> > On Thu, Oct 12, 2023 at 02:19:41PM -0400, Ray Strode wrote:
> >> On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:
> >> To be clear, my take is, if driver code is running in process context
> >> and needs to wait for periods of time on the order of or in excess of
> >> a typical process time slice it should be sleeping during the waiting.
> >> If the operation is at a point where it can be cancelled without side
> >> effects, the sleeping should be INTERRUPTIBLE. If it's past the point
> >> of no return, sleeping should be UNINTERRUPTIBLE. At no point, in my
> >> opinion, should kernel code busy block a typical process for dozens of
> >> milliseconds while keeping the process RUNNING. I don't think this is
> >> a controversial take.
> > Exactly that's what I completely disagree on.
> >>
> >> Okay if we can't agree that it's not okay for user space (or the
> >> kernel running in the context of user space) to busy loop a cpu core
> >> at 100% utilization throughout and beyond the process's entire
> >> scheduled time slice then we really are at an impasse. I gotta say i'm
> >> astonished that this seemingly indefensible behavior is somehow a
> >> point of contention, but I'm not going to keep arguing about it beyond
> >> this email.
> >>
> >> I mean we're not talking about scientific computing, or code
> >> compilation, or seti@home. We're talking about nearly the equivalent
> >> of `while (1) __asm__ ("nop");`
> > 
> > I don't think anyone said this shouldn't be fixed or improved.
> > 
> > What I'm saying is that the atomic ioctl is not going to make guarantees
> > that it will not take up to much cpu time (for some extremely vague value
> > of "too much") to the point that userspace can configure it's compositor
> > in a way that it _will_ get killed if we _ever_ violate this rule.
> > 
> > We should of course try to do as good as job as possible, but that's not
> > what you're asking for. You're asking for a hard real-time guarantee with
> > the implication if we ever break it, it's a regression, and the kernel has
> > to bend over backwards with tricks like in your patch to make it work.
> 
> I don't think mutter really needs or wants such a hard real-time
> guarantee. What it needs is a fighting chance to react before the kernel
> kills its process.
> 
> The intended mechanism for this is SIGXCPU, but that can't work if the
> kernel is stuck in a busy-loop. Ray's patch seems like one way to avoid
> that.

I don't think signals will get us out of this either, or at least still
has risk. We are trying to make everything interruptible and bail out
asap, but those checks are when we're blocking, not when the cpu is busy.

So this also wont guarantee that you expire your timeslice when a driver
is doing a silly expensive atomic_check computation. Much less likely, but
definitely not a zero chance.

> That said, as long as SIGXCPU can work as intended with the non-blocking
> commits mutter uses for everything except modesets, mutter's workaround
> of dropping RT priority for the blocking commits seems acceptable for
> the time being.

Is there no rt setup where the kernel just auto-demotes when you've used
up your slice? That's the only setup I see that guarantees you're not
getting killed here.

I think dropping rt priority around full modesets is still good since
modests really shouldn't ever run as rt, that makes no sense to me.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH 2/7] drm/msm/adreno: Add ZAP firmware name to A635

2023-10-17 Thread Rob Clark
On Mon, Oct 16, 2023 at 1:12 PM Akhil P Oommen  wrote:
>
> On Tue, Sep 26, 2023 at 08:24:37PM +0200, Konrad Dybcio wrote:
> >
> > Some (many?) devices with A635 expect a ZAP shader to be loaded.
> >
> > Set the file name to allow for that.
> >
> > Signed-off-by: Konrad Dybcio 
> > ---
> >  drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> > b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > index fa527935ffd4..16527fe8584d 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> > @@ -454,6 +454,7 @@ static const struct adreno_info gpulist[] = {
> >   .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
> >   ADRENO_QUIRK_HAS_HW_APRIV,
> >   .init = a6xx_gpu_init,
> > + .zapfw = "a660_zap.mbn",
>
> sc7280 doesn't have a TZ and so no zap shader support. Can we handle
> this using "firmware-name" property in your top level platform dt? Zap
> firmwares are signed with different keys for each OEMs. So there is
> cross-compatibility anyway.

I think this ends up working out because the version of sc7280 that
doesn't have TZ also doesn't have the associated mem-region/etc..  but
maybe we should deprecate the zapfw field as in practice it isn't
useful (ie. always overriden by firmware-name).

Fwiw there are windows laptops with sc7180/sc7280 which do use zap fw.

BR,
-R

>
> -Ahil.
>
> >   .hwcg = a660_hwcg,
> >   .address_space_size = SZ_16G,
> >   .speedbins = ADRENO_SPEEDBINS(
> >
> > --
> > 2.42.0
> >


Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

2023-10-17 Thread Daniel Vetter
On Fri, Oct 13, 2023 at 10:04:02AM -0400, Ray Strode wrote:
> Hi
> 
> On Fri, Oct 13, 2023 at 5:41 AM Daniel Vetter  wrote:
> > > I mean we're not talking about scientific computing, or code
> > > compilation, or seti@home. We're talking about nearly the equivalent
> > > of `while (1) __asm__ ("nop");`
> >
> > I don't think anyone said this shouldn't be fixed or improved.
> 
> Yea but we apparently disagree that it would be an improvement to stop
> discrediting user space for driver problems.
> You see, to me, there are two problems 1) The behavior itself is not
> nice and should be fixed 2) The blame/accounting/attribution for a
> driver problem is getting directed to user space. I think both issues
> should be fixed. One brought the other issue to light, but both
> problems, in my mind, are legitimate and should be addressed. You
> think fixing the second problem is some tactic to paper over the first
> problem. Christian thinks the second problem isn't a problem at all
> but the correct design.  So none of us are completely aligned and I
> don't see anyone changing their mind anytime soon.
> 
> > What I'm saying is that the atomic ioctl is not going to make guarantees
> > that it will not take up to much cpu time (for some extremely vague value
> > of "too much") to the point that userspace can configure it's compositor
> > in a way that it _will_ get killed if we _ever_ violate this rule.
> yea I find that strange, all kernel tasks have a certain implied
> baseline responsibility to be good citizens to the system.
> And how user space is configured seems nearly immaterial.
> 
> But we're talking in circles.
> 
> > Fixing the worst offenders I don't think will see any pushback at all.
> Yea we all agree fixing this one busy loop is a problem but we don't
> agree on where the cpu time blame should go.
> 
> > > But *this* feels like duct tape: You've already said there's no
> > > guarantee the problem won't also happen during preliminary computation
> > > during non-blocking commits or via other drm entry points. So it
> > > really does seem like a fix that won't age well. I won't be surprised
> > > if in ~3 years (or whatever) in some RHEL release there's a customer
> > > bug leading to the real-time thread getting blocklisted for obscure
> > > server display hardware because it's causing the session to tank on a
> > > production machine.
> >
> > Yes the atomic ioctl makes no guarantees across drivers and hw platforms
> > of guaranteed "we will never violate, you can kill your compositor if you
> > do" cpu bound limits. We'll try to not suck too badly, and we'll try to
> > focus on fixing the suck where it upsets the people the most.
> >
> > But there is fundamentally no hard real time guarantee in atomic. At least
> > not with the current uapi.
> 
> So in your mind mutter should get out of the real-time thread business 
> entirely?

Yes. At least the hard-real time "the kernel kills your process if you
fail" business. Because desktop drawing just isn't hard real-time, nothing
disastrous happens if we miss a deadline.

Of course special setups where everything is very controlled might be
different.

> > The problem isn't about wasting cpu time. It's about you having set up the
> > system in a way so that mutter gets killed if we ever waste too much cpu
> > time, ever.
> 
> mutter is not set up in a way to kill itself if the driver wastes too
> much cpu time,
> ever. mutter is set up in a way to kill itself if it, itself, wastes
> too much cpu time, ever.
> The fact that the kernel is killing it when a kernel driver is wasting
> cpu time is the
> bug that led to the patch in the first place!
> 
> > The latter is flat out not a guarantee the kernel currently makes, and I
> > see no practical feasible way to make that happen. And pretending we do
> > make this guarantee will just result in frustrated users filling bugs that
> > they desktop session died and developers closing them as "too hard to
> > fix".
> 
> I think all three of us agree busy loops are not nice (though maybe we
> aren't completely aligned on severity). And I'll certainly concede
> that fixing all the busy loops can be hard. Some of the cpu-bound code
> paths may even be doing legitimate computation.  I still assert that
> if the uapi calls into driver code that might potentially be doing
> something slow where it can't sleep, it should be doing it on a
> workqueue or thread. That seems orthogonal to fixing all the places
> where the drivers aren't acting nicely.

Again no, because underlying this your requirement boils down to hard real
time.

And we just cannot guarantee that with atomic kms. Best effort,
absolutely. Guaranteed to never fail, no way.

> > Maybe as a bit more useful outcome of this entire discussion: Could you
> > sign up to write a documentation patch for the atomic ioctl that adds a
> > paragraph stating extremely clearly that this ioctl does not make hard
> > real time guarantees, but only best effort soft realtime, a

RE: [PATCH v1 1/3] mm/gup: Introduce pin_user_pages_fd() for pinning shmem/hugetlbfs file pages

2023-10-17 Thread Kasireddy, Vivek
Hi David,

> > For drivers that would like to longterm-pin the pages associated
> > with a file, the pin_user_pages_fd() API provides an option to
> > not only FOLL_PIN the pages but also to check and migrate them
> > if they reside in movable zone or CMA block. For now, this API
> > can only work with files belonging to shmem or hugetlbfs given
> > that the udmabuf driver is the only user.
> 
> Maybe add "Other files are rejected.". Wasn't clear to me before I
> looked into the code.
Ok, will add it in v2.

> 
> >
> > It must be noted that the pages associated with hugetlbfs files
> > are expected to be found in the page cache. An error is returned
> > if they are not found. However, shmem pages can be swapped in or
> > allocated if they are not present in the page cache.
> >
> > Cc: David Hildenbrand 
> > Cc: Daniel Vetter 
> > Cc: Mike Kravetz 
> > Cc: Hugh Dickins 
> > Cc: Peter Xu 
> > Cc: Gerd Hoffmann 
> > Cc: Dongwon Kim 
> > Cc: Junxiao Chang 
> > Suggested-by: Jason Gunthorpe 
> > Signed-off-by: Vivek Kasireddy 
> > ---
> >   include/linux/mm.h |  2 ++
> >   mm/gup.c   | 87
> ++
> >   2 files changed, 89 insertions(+)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index bf5d0b1b16f4..af2121fb8101 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2457,6 +2457,8 @@ long get_user_pages_unlocked(unsigned long
> start, unsigned long nr_pages,
> > struct page **pages, unsigned int gup_flags);
> >   long pin_user_pages_unlocked(unsigned long start, unsigned long
> nr_pages,
> > struct page **pages, unsigned int gup_flags);
> > +long pin_user_pages_fd(int fd, pgoff_t start, unsigned long nr_pages,
> > +  unsigned int gup_flags, struct page **pages);
> >
> >   int get_user_pages_fast(unsigned long start, int nr_pages,
> > unsigned int gup_flags, struct page **pages);
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 2f8a2d89fde1..e34b77a15fa8 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -3400,3 +3400,90 @@ long pin_user_pages_unlocked(unsigned long
> start, unsigned long nr_pages,
> >  &locked, gup_flags);
> >   }
> >   EXPORT_SYMBOL(pin_user_pages_unlocked);
> > +
> 
> This does look quite neat, nice! Let's take a closer look ...
> 
> > +/**
> > + * pin_user_pages_fd() - pin user pages associated with a file
> > + * @fd: the fd whose pages are to be pinned
> > + * @start:  starting file offset
> > + * @nr_pages:   number of pages from start to pin
> > + * @gup_flags:  flags modifying pin behaviour
> 
> ^ I assume we should drop that. At least for now the flags are
> completely unused. And most likely we would want a different set of
> flags later (GUPFD_ ...).
Right now, FOLL_LONGTERM is the only accepted value for gup_flags but
yes, as you suggest, this can be made implicit by dropping gup_flags.

> 
> > + * @pages:  array that receives pointers to the pages pinned.
> > + *  Should be at least nr_pages long.
> > + *
> > + * Attempt to pin (and migrate) pages associated with a file belonging to
> 
> I'd drop the "and migrate" part, it's more of an implementation detail.
> 
> > + * either shmem or hugetlbfs. An error is returned if pages associated with
> > + * hugetlbfs files are not present in the page cache. However, shmem
> pages
> > + * are swapped in or allocated if they are not present in the page cache.
> 
> Why don't we do the same for hugetlbfs? Would make the interface more
> streamlined.
I am going off of what Mike has stated previously:
"It may not matter to your users, but the semantics for hugetlb and shmem
pages is different.  hugetlb requires the pages exist in the page cache
while shmem will create/add pages to the cache if necessary."

However, if we were to allocate a hugepage (assuming one is not present in the
page cache at a given index), what needs to be done in addition to calling 
these APIs?
folio = alloc_hugetlb_folio_nodemask(h, NUMA_NO_NODE, NULL, GFP_USER)
hugetlb_add_to_page_cache(folio, mapping, idx)

> 
> Certainly add that pinned pages have to be released using
> unpin_user_pages().
Sure, will include that in v2.

> 
> > + *
> > + * Returns number of pages pinned. This would be equal to the number of
> > + * pages requested.
> > + * If nr_pages is 0 or negative, returns 0. If no pages were pinned, 
> > returns
> > + * -errno.
> > + */
> > +long pin_user_pages_fd(int fd, pgoff_t start, unsigned long nr_pages,
> > +  unsigned int gup_flags, struct page **pages)
> > +{
> > +   struct page *page;
> > +   struct file *filep;
> > +   unsigned int flags, i;
> > +   long ret;
> > +
> > +   if (nr_pages <= 0)
> > +   return 0;
> 
> I think we should just forbid that and use a WARN_ON_ONCE() here /
> return -EINVAL. So we'll never end up returning 0.
I think I'll drop this check in v2 as Jason suggested.

> 
> > +   if (!is_valid_gup_ar

Re: [PATCH 3/5] drm/panel: st7703: Add Powkiddy RGB30 Panel Support

2023-10-17 Thread Heiko Stübner
Hi Chris,

Am Montag, 16. Oktober 2023, 20:26:58 CEST schrieb Chris Morgan:
> On Mon, Oct 16, 2023 at 08:18:25PM +0200, Heiko Stübner wrote:
> > Hi,
> > 
> > Am Montag, 16. Oktober 2023, 18:07:52 CEST schrieb Dragan Simic:
> > > On 2023-10-16 17:52, Chris Morgan wrote:
> > > > Confirmed that those pending patches DO fix the panel suspend issues. 
> > > > Thank you.
> > > 
> > > Awesome, that's great to hear!  Perhaps a "Tested-by" in the original 
> > > LKML thread [1] could help with having the patch pulled sooner.
> > > 
> > > Links:
> > > [1] 
> > > https://lore.kernel.org/lkml/33b72957-1062-1b66-85eb-c37dc5ca2...@redhat.com/T/
> > > 
> > > 
> > > > On Mon, Oct 16, 2023 at 3:41 AM Guido Günther  
> > > > wrote:
> > > >> 
> > > >> Hi Chris,
> > > >> On Fri, Oct 13, 2023 at 01:39:16PM -0500, Chris Morgan wrote:
> > > >> > From: Chris Morgan 
> > > >> >
> > > >> > The Powkiddy RGB30 4 inch panel is a 4 inch 720x720 DSI panel used in
> > > >> > the Powkiddy RGB30 handheld gaming device. Add support for it.
> > > >> >
> > > >> > TODO: The panel seems to not resume properly from suspend. I've
> > > >> > confirmed on the other ST7703 based devices it works correctly.
> > 
> > so this TODO item could go away, right?
> > I can remove it when applying the patch, just want to make sure
> > all review comments are addressed - only the suspend thing it seems.
> 
> That is correct, but let me send a v2 of this instead. I'll remove this
> verbiage among other fixes. End users wanted me to see if I could get
> this panel to run at precisely 60hz, which I believe I am able to do
> with the addition of a new PLL clock in clk_rk3568. I believe I have
> taken every constraint detailed in the datasheet to heart for the new
> frequency I'll be requesting. By using the frequency of 29250 for
> the VPLL I can get the panel running at 59.969hz which in my view is
> close enough to the ideal 59.98hz.
> 
> I also accidentally left the UART2 active even though this device has
> no exposed UART port, so I need to fix that too by disabling it.
> 
> Lastly I'll add my tested by to the dri-devel patches as well.

too late ;-)

Looks like your mail and me applying the series happened at a similar
time and I just saw your mail.

So if you want to change the dts now, please do a followup patch.

Thanks
Heiko




Re: [PATCH] drm/atomic: Perform blocking commits on workqueue

2023-10-17 Thread Christian König

Am 17.10.23 um 09:32 schrieb Daniel Vetter:

On Fri, Oct 13, 2023 at 12:22:52PM +0200, Michel Dänzer wrote:

On 10/13/23 11:41, Daniel Vetter wrote:

On Thu, Oct 12, 2023 at 02:19:41PM -0400, Ray Strode wrote:

On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:

To be clear, my take is, if driver code is running in process context
and needs to wait for periods of time on the order of or in excess of
a typical process time slice it should be sleeping during the waiting.
If the operation is at a point where it can be cancelled without side
effects, the sleeping should be INTERRUPTIBLE. If it's past the point
of no return, sleeping should be UNINTERRUPTIBLE. At no point, in my
opinion, should kernel code busy block a typical process for dozens of
milliseconds while keeping the process RUNNING. I don't think this is
a controversial take.

Exactly that's what I completely disagree on.

Okay if we can't agree that it's not okay for user space (or the
kernel running in the context of user space) to busy loop a cpu core
at 100% utilization throughout and beyond the process's entire
scheduled time slice then we really are at an impasse. I gotta say i'm
astonished that this seemingly indefensible behavior is somehow a
point of contention, but I'm not going to keep arguing about it beyond
this email.

I mean we're not talking about scientific computing, or code
compilation, or seti@home. We're talking about nearly the equivalent
of `while (1) __asm__ ("nop");`

I don't think anyone said this shouldn't be fixed or improved.

What I'm saying is that the atomic ioctl is not going to make guarantees
that it will not take up to much cpu time (for some extremely vague value
of "too much") to the point that userspace can configure it's compositor
in a way that it _will_ get killed if we _ever_ violate this rule.

We should of course try to do as good as job as possible, but that's not
what you're asking for. You're asking for a hard real-time guarantee with
the implication if we ever break it, it's a regression, and the kernel has
to bend over backwards with tricks like in your patch to make it work.

I don't think mutter really needs or wants such a hard real-time
guarantee. What it needs is a fighting chance to react before the kernel
kills its process.

The intended mechanism for this is SIGXCPU, but that can't work if the
kernel is stuck in a busy-loop. Ray's patch seems like one way to avoid
that.

I don't think signals will get us out of this either, or at least still
has risk. We are trying to make everything interruptible and bail out
asap, but those checks are when we're blocking, not when the cpu is busy.

So this also wont guarantee that you expire your timeslice when a driver
is doing a silly expensive atomic_check computation. Much less likely, but
definitely not a zero chance.


That said, as long as SIGXCPU can work as intended with the non-blocking
commits mutter uses for everything except modesets, mutter's workaround
of dropping RT priority for the blocking commits seems acceptable for
the time being.

Is there no rt setup where the kernel just auto-demotes when you've used
up your slice? That's the only setup I see that guarantees you're not
getting killed here.

I think dropping rt priority around full modesets is still good since
modests really shouldn't ever run as rt, that makes no sense to me.


Completely agree.

One more data point not mentioned before: While amdgpu could be improved 
we do have devices which (for example) have to do I2C by bit banging 
because they lack the necessary functionality in the hardware.


And IIRC transmitting the 256 bytes EDID takes something like ~5ms (fast 
mode) or ~20ms (standard mode) in which the CPU usually just busy loops 
most of the time. Not saying that we should do a full EDID transmit with 
every modeset, but just to give an example of what might be necessary here.


Christian.


-Sima




Re: [PATCH] drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT

2023-10-17 Thread Danilo Krummrich
On Tue, Oct 10, 2023 at 04:27:24PM +0200, Thomas Hellström wrote:
> Dual-licence in order to make it possible for other non-GPL os'es
> to re-implement the code. The use of EXPORT_SYMBOL_GPL() is intentionally
> left untouched to prevent use of drm_gpuvm as a proxy for non-GPL drivers
> to access GPL-only kernel symbols.
> 
> Much of the ideas and algorithms used in the drm_gpuvm code is already
> present in one way or another in MIT-licensed code.
> 
> Cc: Danilo Krummrich 
> Cc: airl...@gmail.com
> Cc: dan...@ffwll.ch
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Thomas Hellström 

Acked-by: Danilo Krummrich 

> ---
>  drivers/gpu/drm/drm_gpuvm.c | 2 +-
>  include/drm/drm_gpuvm.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> index 02ce6baacdad..08c088319652 100644
> --- a/drivers/gpu/drm/drm_gpuvm.c
> +++ b/drivers/gpu/drm/drm_gpuvm.c
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>  /*
>   * Copyright (c) 2022 Red Hat.
>   *
> diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
> index 361fea5cb849..21bbf11415b3 100644
> --- a/include/drm/drm_gpuvm.h
> +++ b/include/drm/drm_gpuvm.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>  
>  #ifndef __DRM_GPUVM_H__
>  #define __DRM_GPUVM_H__
> -- 
> 2.41.0
> 



[PATCH][next] drm/amd/display: Fix a handful of spelling mistakes in dml_print output

2023-10-17 Thread Colin Ian King
There are a few spelling mistakes and an minor grammatical issue in
some dml_print messages. Fix these.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c 
b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
index 851db026f251..218c355a97a4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2/display_mode_core.c
@@ -1507,7 +1507,7 @@ static dml_bool_t CalculatePrefetchSchedule(struct 
display_mode_lib_scratch_st *
dml_print("DML: Tvm: %fus - time to fetch page tables for meta 
surface\n", s->TimeForFetchingMetaPTE);
dml_print("DML: Tr0: %fus - time to fetch first row of data 
pagetables and first row of meta data (done in parallel)\n", 
s->TimeForFetchingRowInVBlank);
dml_print("DML: Tsw: %fus = time to fetch enough pixel data and 
cursor data to feed the scalers init position and detile\n", 
(dml_float_t)s->LinesToRequestPrefetchPixelData * s->LineTime);
-   dml_print("DML: To: %fus - time for propogation from scaler to 
optc\n", (*p->DSTYAfterScaler + ((dml_float_t) (*p->DSTXAfterScaler) / 
(dml_float_t)p->myPipe->HTotal)) * s->LineTime);
+   dml_print("DML: To: %fus - time for propagation from scaler to 
optc\n", (*p->DSTYAfterScaler + ((dml_float_t) (*p->DSTXAfterScaler) / 
(dml_float_t)p->myPipe->HTotal)) * s->LineTime);
dml_print("DML: Tvstartup - TSetup - Tcalc - Twait - Tpre - To 
> 0\n");
dml_print("DML: Tslack(pre): %fus - time left over in 
schedule\n", p->VStartup * s->LineTime - s->TimeForFetchingMetaPTE - 2 * 
s->TimeForFetchingRowInVBlank - (*p->DSTYAfterScaler + ((dml_float_t) 
(*p->DSTXAfterScaler) / (dml_float_t)p->myPipe->HTotal)) * s->LineTime - 
p->TWait - p->TCalc - *p->TSetup);
dml_print("DML: row_bytes = dpte_row_bytes (per_pipe) = 
PixelPTEBytesPerRow = : %u\n", p->PixelPTEBytesPerRow);
@@ -9323,7 +9323,7 @@ void dml_core_mode_programming(struct display_mode_lib_st 
*mode_lib, const struc
if 
(mode_lib->ms.policy.ImmediateFlipRequirement[k] != 
dml_immediate_flip_not_required && locals->ImmediateFlipSupportedForPipe[k] == 
false) {
locals->ImmediateFlipSupported = false;
 #ifdef __DML_VBA_DEBUG__
-   dml_print("DML::%s: Pipe %0d not 
supporing iflip\n", __func__, k);
+   dml_print("DML::%s: Pipe %0d not 
supporting iflip\n", __func__, k);
 #endif
}
}
@@ -9376,7 +9376,7 @@ void dml_core_mode_programming(struct display_mode_lib_st 
*mode_lib, const struc
if (locals->PrefetchAndImmediateFlipSupported) {
dml_print("DML::%s: Good, Prefetch and flip scheduling solution 
found at VStartupLines=%u (MaxVStartupAllPlanes=%u)\n", __func__, 
s->VStartupLines-1, s->MaxVStartupAllPlanes);
} else {
-   dml_print("DML::%s: Bad, Prefetch and flip scheduling soluation 
NOT found solution! (MaxVStartupAllPlanes=%u)\n", __func__, 
s->MaxVStartupAllPlanes);
+   dml_print("DML::%s: Bad, Prefetch and flip scheduling solution 
did NOT find solution! (MaxVStartupAllPlanes=%u)\n", __func__, 
s->MaxVStartupAllPlanes);
}
 
//Watermarks and NB P-State/DRAM Clock Change Support
-- 
2.39.2



Re: [PATCH] drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT

2023-10-17 Thread Thomas Hellström



On 10/17/23 09:54, Danilo Krummrich wrote:

On Tue, Oct 10, 2023 at 04:27:24PM +0200, Thomas Hellström wrote:

Dual-licence in order to make it possible for other non-GPL os'es
to re-implement the code. The use of EXPORT_SYMBOL_GPL() is intentionally
left untouched to prevent use of drm_gpuvm as a proxy for non-GPL drivers
to access GPL-only kernel symbols.

Much of the ideas and algorithms used in the drm_gpuvm code is already
present in one way or another in MIT-licensed code.

Cc: Danilo Krummrich 
Cc: airl...@gmail.com
Cc: dan...@ffwll.ch
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellström 

Acked-by: Danilo Krummrich 


Thanks, Danilo

Thomas





---
  drivers/gpu/drm/drm_gpuvm.c | 2 +-
  include/drm/drm_gpuvm.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 02ce6baacdad..08c088319652 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0-only
+// SPDX-License-Identifier: GPL-2.0 OR MIT
  /*
   * Copyright (c) 2022 Red Hat.
   *
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 361fea5cb849..21bbf11415b3 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
  
  #ifndef __DRM_GPUVM_H__

  #define __DRM_GPUVM_H__
--
2.41.0



RE: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP

2023-10-17 Thread Manna, Animesh


> -Original Message-
> From: Murthy, Arun R 
> Sent: Monday, October 16, 2023 9:56 AM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Hogander, Jouni
> ; Nikula, Jani 
> Subject: RE: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dpcd
> initialization for DP
> 
> 
> > -Original Message-
> > From: Manna, Animesh 
> > Sent: Wednesday, October 11, 2023 4:40 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; Hogander, Jouni
> ;
> > Murthy, Arun R ; Nikula, Jani
> > 
> > Subject: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dpcd
> > initialization for DP
> >
> > Due to similarity panel replay dpcd initialization got added in psr
> > function which is specific for edp panel. This patch enables panel
> > replay initialization for dp connector.
> >
> If panelreplay initialization then why is the function name psr_init_dpcd() ?
> Also it its similar to PSR then these dpcd should already be available.

Hi Arun,

The first call for intel_psr_init_dpcd() get called from intel_edp_init_dpcd() 
which is not reachable for DP.
So, in this patch need to add intel_psr_init_dpcd() for DP(non-edp) in 
intel_psr_init().
Panel replay initialization added in intel_psr_init() as per previous feedback 
just to align panel-replay with psr framework. 

Regards,
Animesh
> 
> Thanks and Regards,
> Arun R Murthy
> 
> 
> > Cc: Jouni Högander 
> > Cc: Arun R Murthy 
> > Cc: Jani Nikula 
> > Signed-off-by: Animesh Manna 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index f9837001aa5f..a2e0637c53fb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -2738,6 +2738,9 @@ void intel_psr_init(struct intel_dp *intel_dp)
> > if (!(HAS_PSR(dev_priv) || HAS_DP20(dev_priv)))
> > return;
> >
> > +   if (!intel_dp_is_edp(intel_dp))
> > +   intel_psr_init_dpcd(intel_dp);
> > +
> > /*
> >  * HSW spec explicitly says PSR is tied to port A.
> >  * BDW+ platforms have a instance of PSR registers per transcoder
> > but
> > --
> > 2.29.0



[PATCH 00/12] drm/ast: Align VGA register names with documentation

2023-10-17 Thread Thomas Zimmermann
Update the names of ast's VGA registers to follow the documentation
and put all constants into a separate header. The update make the
driver source code more grep-able. No functional changes.

Thomas Zimmermann (12):
  drm/ast: Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W
  drm/ast: Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W
  drm/ast: Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER
  drm/ast: Rename AST_IO_SEQ_PORT to AST_IO_VGASRI
  drm/ast: Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR
  drm/ast: Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR
  drm/ast: Rename AST_IO_DAC_DATA to AST_IO_VGAPDR
  drm/ast: Rename AST_IO_GR_PORT to AST_IO_VGAGRI
  drm/ast: Rename AST_IO_CRTC_PORT to AST_IO_VGACRI
  drm/ast: Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R
  drm/ast: Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R
  drm/ast: Move register constants to ast_reg.h

 drivers/gpu/drm/ast/ast_dp.c|  70 +--
 drivers/gpu/drm/ast/ast_dp501.c |  38 +++---
 drivers/gpu/drm/ast/ast_drv.h   |  83 +
 drivers/gpu/drm/ast/ast_i2c.c   |  20 ++--
 drivers/gpu/drm/ast/ast_main.c  |  24 ++--
 drivers/gpu/drm/ast/ast_mm.c|   4 +-
 drivers/gpu/drm/ast/ast_mode.c  | 200 
 drivers/gpu/drm/ast/ast_post.c  |  26 ++---
 drivers/gpu/drm/ast/ast_reg.h   |  99 
 9 files changed, 292 insertions(+), 272 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/ast_reg.h

-- 
2.42.0



[PATCH 04/12] drm/ast: Rename AST_IO_SEQ_PORT to AST_IO_VGASRI

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_VGA_SEQ_PORT to AST_IO_VGASRI to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  |  2 +-
 drivers/gpu/drm/ast/ast_mode.c | 22 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index e31ba929f18db..dc8b4d86ca9a5 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -262,7 +262,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGAARI_W(0x40)
 #define AST_IO_VGAMR_W (0x42)
 #define AST_IO_VGAER   (0x43)
-#define AST_IO_SEQ_PORT(0x44)
+#define AST_IO_VGASRI  (0x44)
 #define AST_IO_DAC_INDEX_READ  (0x47)
 #define AST_IO_DAC_INDEX_WRITE (0x48)
 #define AST_IO_DAC_DATA(0x49)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 3f52648c20a09..6f8375dd80a39 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -56,13 +56,13 @@ static inline void ast_load_palette_index(struct ast_device 
*ast,
 u8 blue)
 {
ast_io_write8(ast, AST_IO_DAC_INDEX_WRITE, index);
-   ast_io_read8(ast, AST_IO_SEQ_PORT);
+   ast_io_read8(ast, AST_IO_VGASRI);
ast_io_write8(ast, AST_IO_DAC_DATA, red);
-   ast_io_read8(ast, AST_IO_SEQ_PORT);
+   ast_io_read8(ast, AST_IO_VGASRI);
ast_io_write8(ast, AST_IO_DAC_DATA, green);
-   ast_io_read8(ast, AST_IO_SEQ_PORT);
+   ast_io_read8(ast, AST_IO_VGASRI);
ast_io_write8(ast, AST_IO_DAC_DATA, blue);
-   ast_io_read8(ast, AST_IO_SEQ_PORT);
+   ast_io_read8(ast, AST_IO_VGASRI);
 }
 
 static void ast_crtc_set_gamma_linear(struct ast_device *ast,
@@ -301,11 +301,11 @@ static void ast_set_std_reg(struct ast_device *ast,
ast_io_write8(ast, AST_IO_VGAMR_W, jreg);
 
/* Set SEQ; except Screen Disable field */
-   ast_set_index_reg(ast, AST_IO_SEQ_PORT, 0x00, 0x03);
-   ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x01, 0xdf, 
stdtable->seq[0]);
+   ast_set_index_reg(ast, AST_IO_VGASRI, 0x00, 0x03);
+   ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x01, 0xdf, 
stdtable->seq[0]);
for (i = 1; i < 4; i++) {
jreg = stdtable->seq[i];
-   ast_set_index_reg(ast, AST_IO_SEQ_PORT, (i + 1), jreg);
+   ast_set_index_reg(ast, AST_IO_VGASRI, (i + 1), jreg);
}
 
/* Set CRTC; except base address and offset */
@@ -689,7 +689,7 @@ static void ast_primary_plane_helper_atomic_enable(struct 
drm_plane *plane,
 * Therefore only reprogram the address after enabling the plane.
 */
ast_set_start_address_crt1(ast, (u32)ast_plane->offset);
-   ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x00);
+   ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x1, 0xdf, 0x00);
 }
 
 static void ast_primary_plane_helper_atomic_disable(struct drm_plane *plane,
@@ -697,7 +697,7 @@ static void ast_primary_plane_helper_atomic_disable(struct 
drm_plane *plane,
 {
struct ast_device *ast = to_ast_device(plane->dev);
 
-   ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x20);
+   ast_set_index_reg_mask(ast, AST_IO_VGASRI, 0x1, 0xdf, 0x20);
 }
 
 static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = {
@@ -1014,7 +1014,7 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
 */
switch (mode) {
case DRM_MODE_DPMS_ON:
-   ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT,  0x01, 0xdf, 0);
+   ast_set_index_reg_mask(ast, AST_IO_VGASRI,  0x01, 0xdf, 0);
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb6, 0xfc, 0);
if (ast->tx_chip_types & AST_TX_DP501_BIT)
ast_set_dp501_video_output(crtc->dev, 1);
@@ -1051,7 +1051,7 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
ast_dp_power_on_off(crtc->dev, AST_DP_POWER_OFF);
}
 
-   ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT,  0x01, 0xdf, 0x20);
+   ast_set_index_reg_mask(ast, AST_IO_VGASRI,  0x01, 0xdf, 0x20);
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb6, 0xfc, ch);
break;
}
-- 
2.42.0



[PATCH 12/12] drm/ast: Move register constants to ast_reg.h

2023-10-17 Thread Thomas Zimmermann
Improve readability by putting all register constants into a separate
header file. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h | 83 +
 drivers/gpu/drm/ast/ast_reg.h | 99 +++
 2 files changed, 101 insertions(+), 81 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/ast_reg.h

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 214bfac0798ab..2aee32344f4a2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -39,6 +39,8 @@
 #include 
 #include 
 
+#include "ast_reg.h"
+
 #define DRIVER_AUTHOR  "Dave Airlie"
 
 #define DRIVER_NAME"ast"
@@ -259,25 +261,6 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define IS_AST_GEN6(__ast) __ast_gen_is_eq(__ast, 6)
 #define IS_AST_GEN7(__ast) __ast_gen_is_eq(__ast, 7)
 
-#define AST_IO_VGAARI_W(0x40)
-#define AST_IO_VGAMR_W (0x42)
-#define AST_IO_VGAER   (0x43)
-#define AST_IO_VGASRI  (0x44)
-#define AST_IO_VGADRR  (0x47)
-#define AST_IO_VGADWR  (0x48)
-#define AST_IO_VGAPDR  (0x49)
-#define AST_IO_VGAGRI  (0x4E)
-#define AST_IO_VGACRI  (0x54)
-#define AST_IO_VGAIR1_R(0x5A)
-#define AST_IO_VGAMR_R (0x4C)
-
-#define AST_IO_MM_OFFSET   (0x380)
-
-#define AST_IO_VGAIR1_VREFRESH BIT(3)
-
-#define AST_IO_VGACRCB_HWC_ENABLED BIT(1)
-#define AST_IO_VGACRCB_HWC_16BPP   BIT(0) /* set: ARGB, cleared: 2bpp 
palette */
-
 static inline u32 ast_read32(struct ast_device *ast, u32 reg)
 {
return ioread32(ast->regs + reg);
@@ -399,71 +382,9 @@ int ast_mode_config_init(struct ast_device *ast);
 #define AST_DP501_LINKRATE 0xf014
 #define AST_DP501_EDID_DATA0xf020
 
-/*
- * Display Transmitter Type:
- */
-#define TX_TYPE_MASK   GENMASK(3, 1)
-#define NO_TX  (0 << 1)
-#define ITE66121_VBIOS_TX  (1 << 1)
-#define SI164_VBIOS_TX (2 << 1)
-#define CH7003_VBIOS_TX(3 << 1)
-#define DP501_VBIOS_TX (4 << 1)
-#define ANX9807_VBIOS_TX   (5 << 1)
-#define TX_FW_EMBEDDED_FW_TX   (6 << 1)
-#define ASTDP_DPMCU_TX (7 << 1)
-
-#define AST_VRAM_INIT_STATUS_MASK  GENMASK(7, 6)
-//#define AST_VRAM_INIT_BY_BMC BIT(7)
-//#define AST_VRAM_INIT_READY  BIT(6)
-
-/* Define for Soc scratched reg used on ASTDP */
-#define AST_DP_PHY_SLEEP   BIT(4)
-#define AST_DP_VIDEO_ENABLEBIT(0)
-
 #define AST_DP_POWER_ONtrue
 #define AST_DP_POWER_OFF   false
 
-/*
- * CRD1[b5]: DP MCU FW is executing
- * CRDC[b0]: DP link success
- * CRDF[b0]: DP HPD
- * CRE5[b0]: Host reading EDID process is done
- */
-#define ASTDP_MCU_FW_EXECUTING BIT(5)
-#define ASTDP_LINK_SUCCESS BIT(0)
-#define ASTDP_HPD  BIT(0)
-#define ASTDP_HOST_EDID_READ_DONE  BIT(0)
-#define ASTDP_HOST_EDID_READ_DONE_MASK GENMASK(0, 0)
-
-/*
- * CRB8[b1]: Enable VSYNC off
- * CRB8[b0]: Enable HSYNC off
- */
-#define AST_DPMS_VSYNC_OFF BIT(1)
-#define AST_DPMS_HSYNC_OFF BIT(0)
-
-/*
- * CRDF[b4]: Mirror of AST_DP_VIDEO_ENABLE
- * Precondition:   A. ~AST_DP_PHY_SLEEP  &&
- * B. DP_HPD &&
- * C. DP_LINK_SUCCESS
- */
-#define ASTDP_MIRROR_VIDEO_ENABLE  BIT(4)
-
-#define ASTDP_EDID_READ_POINTER_MASK   GENMASK(7, 0)
-#define ASTDP_EDID_VALID_FLAG_MASK GENMASK(0, 0)
-#define ASTDP_EDID_READ_DATA_MASK  GENMASK(7, 0)
-
-/*
- * ASTDP setmode registers:
- * CRE0[7:0]: MISC0 ((0x00: 18-bpp) or (0x20: 24-bpp)
- * CRE1[7:0]: MISC1 (default: 0x00)
- * CRE2[7:0]: video format index (0x00 ~ 0x20 or 0x40 ~ 0x50)
- */
-#define ASTDP_MISC0_24bpp  BIT(5)
-#define ASTDP_MISC10
-#define ASTDP_AND_CLEAR_MASK   0x00
-
 /*
  * ASTDP resoultion table:
  * EX: ASTDP_A_B_C:
diff --git a/drivers/gpu/drm/ast/ast_reg.h b/drivers/gpu/drm/ast/ast_reg.h
new file mode 100644
index 0..555286ecf5209
--- /dev/null
+++ b/drivers/gpu/drm/ast/ast_reg.h
@@ -0,0 +1,99 @@
+/* SPDX-License-Identifier: MIT */
+
+#ifndef __AST_REG_H__
+#define __AST_REG_H__
+
+#include 
+
+/*
+ * Modesetting
+ */
+
+#define AST_IO_MM_OFFSET   (0x380)
+
+#define AST_IO_VGAARI_W(0x40)
+#define AST_IO_VGAMR_W (0x42)
+#define AST_IO_VGAER   (0x43)
+#define AST_IO_VGASRI  (0x44)
+#define AST_IO_V

[PATCH 08/12] drm/ast: Rename AST_IO_GR_PORT to AST_IO_VGAGRI

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_GR_PORT to AST_IO_VGAGRI to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 43d1861d62624..86860ab547113 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -266,7 +266,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGADRR  (0x47)
 #define AST_IO_VGADWR  (0x48)
 #define AST_IO_VGAPDR  (0x49)
-#define AST_IO_GR_PORT (0x4E)
+#define AST_IO_VGAGRI  (0x4E)
 #define AST_IO_CRTC_PORT   (0x54)
 #define AST_IO_INPUT_STATUS1_READ  (0x5A)
 #define AST_IO_MISC_PORT_READ  (0x4C)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index fa21cdfd6c4f5..19dc050d6e815 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -332,7 +332,7 @@ static void ast_set_std_reg(struct ast_device *ast,
 
/* Set GR */
for (i = 0; i < 9; i++)
-   ast_set_index_reg(ast, AST_IO_GR_PORT, i, stdtable->gr[i]);
+   ast_set_index_reg(ast, AST_IO_VGAGRI, i, stdtable->gr[i]);
 }
 
 static void ast_set_crtc_reg(struct ast_device *ast,
-- 
2.42.0



[PATCH 10/12] drm/ast: Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index a8bcb1903294e..03f1edf95e73c 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -268,7 +268,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGAPDR  (0x49)
 #define AST_IO_VGAGRI  (0x4E)
 #define AST_IO_VGACRI  (0x54)
-#define AST_IO_INPUT_STATUS1_READ  (0x5A)
+#define AST_IO_VGAIR1_R(0x5A)
 #define AST_IO_MISC_PORT_READ  (0x4C)
 
 #define AST_IO_MM_OFFSET   (0x380)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c4381342af04b..289e32227f6b9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -318,7 +318,7 @@ static void ast_set_std_reg(struct ast_device *ast,
ast_set_index_reg(ast, AST_IO_VGACRI, i, stdtable->crtc[i]);
 
/* set AR */
-   jreg = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
+   jreg = ast_io_read8(ast, AST_IO_VGAIR1_R);
for (i = 0; i < 20; i++) {
jreg = stdtable->ar[i];
ast_io_write8(ast, AST_IO_VGAARI_W, (u8)i);
@@ -327,7 +327,7 @@ static void ast_set_std_reg(struct ast_device *ast,
ast_io_write8(ast, AST_IO_VGAARI_W, 0x14);
ast_io_write8(ast, AST_IO_VGAARI_W, 0x00);
 
-   jreg = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
+   jreg = ast_io_read8(ast, AST_IO_VGAIR1_R);
ast_io_write8(ast, AST_IO_VGAARI_W, 0x20);
 
/* Set GR */
@@ -558,7 +558,7 @@ static void ast_wait_for_vretrace(struct ast_device *ast)
u8 vgair1;
 
do {
-   vgair1 = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
+   vgair1 = ast_io_read8(ast, AST_IO_VGAIR1_R);
} while (!(vgair1 & AST_IO_VGAIR1_VREFRESH) && time_before(jiffies, 
timeout));
 }
 
-- 
2.42.0



[PATCH 02/12] drm/ast: Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_main.c | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 3d64dc356d699..ff86db3604cda 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -260,7 +260,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define IS_AST_GEN7(__ast) __ast_gen_is_eq(__ast, 7)
 
 #define AST_IO_VGAARI_W(0x40)
-#define AST_IO_MISC_PORT_WRITE (0x42)
+#define AST_IO_VGAMR_W (0x42)
 #define AST_IO_VGA_ENABLE_PORT (0x43)
 #define AST_IO_SEQ_PORT(0x44)
 #define AST_IO_DAC_INDEX_READ  (0x47)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index dae365ed39696..f8a682c4cbd01 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -50,7 +50,7 @@ static void ast_enable_vga(struct drm_device *dev)
struct ast_device *ast = to_ast_device(dev);
 
ast_io_write8(ast, AST_IO_VGA_ENABLE_PORT, 0x01);
-   ast_io_write8(ast, AST_IO_MISC_PORT_WRITE, 0x01);
+   ast_io_write8(ast, AST_IO_VGAMR_W, 0x01);
 }
 
 /*
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 1ccbfdf27356e..3f52648c20a09 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -298,7 +298,7 @@ static void ast_set_std_reg(struct ast_device *ast,
stdtable = vbios_mode->std_table;
 
jreg = stdtable->misc;
-   ast_io_write8(ast, AST_IO_MISC_PORT_WRITE, jreg);
+   ast_io_write8(ast, AST_IO_VGAMR_W, jreg);
 
/* Set SEQ; except Screen Disable field */
ast_set_index_reg(ast, AST_IO_SEQ_PORT, 0x00, 0x03);
@@ -537,7 +537,7 @@ static void ast_set_sync_reg(struct ast_device *ast,
jreg |= 0x80;
if (vbios_mode->enh_table->flags & NHSync)
jreg |= 0x40;
-   ast_io_write8(ast, AST_IO_MISC_PORT_WRITE, jreg);
+   ast_io_write8(ast, AST_IO_VGAMR_W, jreg);
 }
 
 static void ast_set_start_address_crt1(struct ast_device *ast,
-- 
2.42.0



[PATCH 07/12] drm/ast: Rename AST_IO_DAC_DATA to AST_IO_VGAPDR

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_DAC_DATA to AST_IO_VGAPDR to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 2b46fafd3467f..43d1861d62624 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -265,7 +265,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGASRI  (0x44)
 #define AST_IO_VGADRR  (0x47)
 #define AST_IO_VGADWR  (0x48)
-#define AST_IO_DAC_DATA(0x49)
+#define AST_IO_VGAPDR  (0x49)
 #define AST_IO_GR_PORT (0x4E)
 #define AST_IO_CRTC_PORT   (0x54)
 #define AST_IO_INPUT_STATUS1_READ  (0x5A)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index a719f6c9493dc..fa21cdfd6c4f5 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -57,11 +57,11 @@ static inline void ast_load_palette_index(struct ast_device 
*ast,
 {
ast_io_write8(ast, AST_IO_VGADWR, index);
ast_io_read8(ast, AST_IO_VGASRI);
-   ast_io_write8(ast, AST_IO_DAC_DATA, red);
+   ast_io_write8(ast, AST_IO_VGAPDR, red);
ast_io_read8(ast, AST_IO_VGASRI);
-   ast_io_write8(ast, AST_IO_DAC_DATA, green);
+   ast_io_write8(ast, AST_IO_VGAPDR, green);
ast_io_read8(ast, AST_IO_VGASRI);
-   ast_io_write8(ast, AST_IO_DAC_DATA, blue);
+   ast_io_write8(ast, AST_IO_VGAPDR, blue);
ast_io_read8(ast, AST_IO_VGASRI);
 }
 
-- 
2.42.0



[PATCH 05/12] drm/ast: Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index dc8b4d86ca9a5..ff95b8f088f8d 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -263,7 +263,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGAMR_W (0x42)
 #define AST_IO_VGAER   (0x43)
 #define AST_IO_VGASRI  (0x44)
-#define AST_IO_DAC_INDEX_READ  (0x47)
+#define AST_IO_VGADRR  (0x47)
 #define AST_IO_DAC_INDEX_WRITE (0x48)
 #define AST_IO_DAC_DATA(0x49)
 #define AST_IO_GR_PORT (0x4E)
-- 
2.42.0



[PATCH 01/12] drm/ast: Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  |  2 +-
 drivers/gpu/drm/ast/ast_mode.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 848a9f1403e89..3d64dc356d699 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -259,7 +259,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define IS_AST_GEN6(__ast) __ast_gen_is_eq(__ast, 6)
 #define IS_AST_GEN7(__ast) __ast_gen_is_eq(__ast, 7)
 
-#define AST_IO_AR_PORT_WRITE   (0x40)
+#define AST_IO_VGAARI_W(0x40)
 #define AST_IO_MISC_PORT_WRITE (0x42)
 #define AST_IO_VGA_ENABLE_PORT (0x43)
 #define AST_IO_SEQ_PORT(0x44)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 32f04ec6c386f..1ccbfdf27356e 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -321,14 +321,14 @@ static void ast_set_std_reg(struct ast_device *ast,
jreg = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
for (i = 0; i < 20; i++) {
jreg = stdtable->ar[i];
-   ast_io_write8(ast, AST_IO_AR_PORT_WRITE, (u8)i);
-   ast_io_write8(ast, AST_IO_AR_PORT_WRITE, jreg);
+   ast_io_write8(ast, AST_IO_VGAARI_W, (u8)i);
+   ast_io_write8(ast, AST_IO_VGAARI_W, jreg);
}
-   ast_io_write8(ast, AST_IO_AR_PORT_WRITE, 0x14);
-   ast_io_write8(ast, AST_IO_AR_PORT_WRITE, 0x00);
+   ast_io_write8(ast, AST_IO_VGAARI_W, 0x14);
+   ast_io_write8(ast, AST_IO_VGAARI_W, 0x00);
 
jreg = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
-   ast_io_write8(ast, AST_IO_AR_PORT_WRITE, 0x20);
+   ast_io_write8(ast, AST_IO_VGAARI_W, 0x20);
 
/* Set GR */
for (i = 0; i < 9; i++)
-- 
2.42.0



[PATCH 03/12] drm/ast: Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_main.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ff86db3604cda..e31ba929f18db 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -261,7 +261,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 
 #define AST_IO_VGAARI_W(0x40)
 #define AST_IO_VGAMR_W (0x42)
-#define AST_IO_VGA_ENABLE_PORT (0x43)
+#define AST_IO_VGAER   (0x43)
 #define AST_IO_SEQ_PORT(0x44)
 #define AST_IO_DAC_INDEX_READ  (0x47)
 #define AST_IO_DAC_INDEX_WRITE (0x48)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f8a682c4cbd01..7db1f50044542 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -40,7 +40,7 @@ static bool ast_is_vga_enabled(struct drm_device *dev)
struct ast_device *ast = to_ast_device(dev);
u8 ch;
 
-   ch = ast_io_read8(ast, AST_IO_VGA_ENABLE_PORT);
+   ch = ast_io_read8(ast, AST_IO_VGAER);
 
return !!(ch & 0x01);
 }
@@ -49,7 +49,7 @@ static void ast_enable_vga(struct drm_device *dev)
 {
struct ast_device *ast = to_ast_device(dev);
 
-   ast_io_write8(ast, AST_IO_VGA_ENABLE_PORT, 0x01);
+   ast_io_write8(ast, AST_IO_VGAER, 0x01);
ast_io_write8(ast, AST_IO_VGAMR_W, 0x01);
 }
 
-- 
2.42.0



[PATCH 06/12] drm/ast: Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ff95b8f088f8d..2b46fafd3467f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -264,7 +264,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGAER   (0x43)
 #define AST_IO_VGASRI  (0x44)
 #define AST_IO_VGADRR  (0x47)
-#define AST_IO_DAC_INDEX_WRITE (0x48)
+#define AST_IO_VGADWR  (0x48)
 #define AST_IO_DAC_DATA(0x49)
 #define AST_IO_GR_PORT (0x4E)
 #define AST_IO_CRTC_PORT   (0x54)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 6f8375dd80a39..a719f6c9493dc 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -55,7 +55,7 @@ static inline void ast_load_palette_index(struct ast_device 
*ast,
 u8 index, u8 red, u8 green,
 u8 blue)
 {
-   ast_io_write8(ast, AST_IO_DAC_INDEX_WRITE, index);
+   ast_io_write8(ast, AST_IO_VGADWR, index);
ast_io_read8(ast, AST_IO_VGASRI);
ast_io_write8(ast, AST_IO_DAC_DATA, red);
ast_io_read8(ast, AST_IO_VGASRI);
-- 
2.42.0



[PATCH 09/12] drm/ast: Rename AST_IO_CRTC_PORT to AST_IO_VGACRI

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_CRTC_PORT to AST_IO_VGACRI to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_dp.c|  70 +++
 drivers/gpu/drm/ast/ast_dp501.c |  38 -
 drivers/gpu/drm/ast/ast_drv.h   |   2 +-
 drivers/gpu/drm/ast/ast_i2c.c   |  20 ++---
 drivers/gpu/drm/ast/ast_main.c  |  18 ++--
 drivers/gpu/drm/ast/ast_mm.c|   4 +-
 drivers/gpu/drm/ast/ast_mode.c  | 146 
 drivers/gpu/drm/ast/ast_post.c  |  26 +++---
 8 files changed, 162 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
index fdd9a493aa9c0..ebb6d8ebd44eb 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -9,11 +9,11 @@
 
 bool ast_astdp_is_connected(struct ast_device *ast)
 {
-   if (!ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1, 
ASTDP_MCU_FW_EXECUTING))
+   if (!ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xD1, 
ASTDP_MCU_FW_EXECUTING))
return false;
-   if (!ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDF, ASTDP_HPD))
+   if (!ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xDF, ASTDP_HPD))
return false;
-   if (!ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDC, 
ASTDP_LINK_SUCCESS))
+   if (!ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xDC, 
ASTDP_LINK_SUCCESS))
return false;
return true;
 }
@@ -29,22 +29,22 @@ int ast_astdp_read_edid(struct drm_device *dev, u8 
*ediddata)
 * CRDF[b0]: DP HPD
 * CRE5[b0]: Host reading EDID process is done
 */
-   if (!(ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1, 
ASTDP_MCU_FW_EXECUTING) &&
-   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDC, 
ASTDP_LINK_SUCCESS) &&
-   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDF, ASTDP_HPD) 
&&
-   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5,
+   if (!(ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xD1, 
ASTDP_MCU_FW_EXECUTING) &&
+   ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xDC, 
ASTDP_LINK_SUCCESS) &&
+   ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xDF, ASTDP_HPD) &&
+   ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xE5,

ASTDP_HOST_EDID_READ_DONE_MASK))) {
goto err_astdp_edid_not_ready;
}
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE5, (u8) 
~ASTDP_HOST_EDID_READ_DONE_MASK,
+   ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xE5, (u8) 
~ASTDP_HOST_EDID_READ_DONE_MASK,
0x00);
 
for (i = 0; i < 32; i++) {
/*
 * CRE4[7:0]: Read-Pointer for EDID (Unit: 4bytes); valid 
range: 0~64
 */
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE4,
+   ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xE4,
   ASTDP_AND_CLEAR_MASK, (u8)i);
j = 0;
 
@@ -52,9 +52,9 @@ int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata)
 * CRD7[b0]: valid flag for EDID
 * CRD6[b0]: mirror read pointer for EDID
 */
-   while ((ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD7,
+   while ((ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xD7,
ASTDP_EDID_VALID_FLAG_MASK) != 0x01) ||
-   (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD6,
+   (ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xD6,
ASTDP_EDID_READ_POINTER_MASK) 
!= i)) {
/*
 * Delay are getting longer with each retry.
@@ -64,11 +64,11 @@ int ast_astdp_read_edid(struct drm_device *dev, u8 
*ediddata)
 */
mdelay(j+1);
 
-   if (!(ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xD1,
+   if (!(ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xD1,
ASTDP_MCU_FW_EXECUTING) 
&&
-   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xDC,
+   ast_get_index_reg_mask(ast, AST_IO_VGACRI, 0xDC,
ASTDP_LINK_SUCCESS) &&
-   ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 
0xDF, ASTDP_HPD))) {
+   ast_get_index_reg_mask(ast, AST_IO_VGACRI, 
0xDF, ASTDP_HPD))) {
goto err_astdp_jump_out_loop_of_edid;
}
 
@@ -77,13 +77,13 @@ int ast_astdp_read_edid(struct drm_device *dev, u8 
*ediddata)
goto err_astdp_jump_out_loop_of_edid;
}
 
-

[PATCH 11/12] drm/ast: Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R

2023-10-17 Thread Thomas Zimmermann
Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R to align naming
in the driver with documentation. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 2 +-
 drivers/gpu/drm/ast/ast_mode.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 03f1edf95e73c..214bfac0798ab 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -269,7 +269,7 @@ static inline bool __ast_gen_is_eq(struct ast_device *ast, 
unsigned long gen)
 #define AST_IO_VGAGRI  (0x4E)
 #define AST_IO_VGACRI  (0x54)
 #define AST_IO_VGAIR1_R(0x5A)
-#define AST_IO_MISC_PORT_READ  (0x4C)
+#define AST_IO_VGAMR_R (0x4C)
 
 #define AST_IO_MM_OFFSET   (0x380)
 
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 289e32227f6b9..cb96149842851 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -531,7 +531,7 @@ static void ast_set_sync_reg(struct ast_device *ast,
 {
u8 jreg;
 
-   jreg  = ast_io_read8(ast, AST_IO_MISC_PORT_READ);
+   jreg  = ast_io_read8(ast, AST_IO_VGAMR_R);
jreg &= ~0xC0;
if (vbios_mode->enh_table->flags & NVSync)
jreg |= 0x80;
-- 
2.42.0



Re: [PATCH] accel/ivpu: Don't enter d0i3 during FLR

2023-10-17 Thread Stanislaw Gruszka
On Fri, Oct 06, 2023 at 09:25:29AM -0600, Jeffrey Hugo wrote:
> On 10/3/2023 12:42 AM, Stanislaw Gruszka wrote:
> > From: Jacek Lawrynowicz 
> > 
> > Fix a bug on some platforms where FLR causes complete system
> > hang when CPU is low power states (C8 or above).
> 
> Why does FLR cause a complete system hang?

This HW bug is still under debug and it is not yet root caused.

> Why does avoiding d0i3 fix the
> issue?  Feels like there could be a lot more detail here.

We only know that we should avoid entering D0i3.

I will change the log this way:

Avoid HW bug on some platforms where we enter D0i3 state
and CPU is in low power states (C8 or above).

Regards
Stanislaw

> > Fixes: 852be13f3bd3 ("accel/ivpu: Add PM support")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Jacek Lawrynowicz 
> > Reviewed-by: Stanislaw Gruszka 
> > Signed-off-by: Stanislaw Gruszka 
> > ---
> >   drivers/accel/ivpu/ivpu_drv.c | 11 ---
> >   drivers/accel/ivpu/ivpu_drv.h |  1 +
> >   drivers/accel/ivpu/ivpu_hw.h  |  8 
> >   drivers/accel/ivpu/ivpu_hw_37xx.c |  1 +
> >   drivers/accel/ivpu/ivpu_hw_40xx.c |  1 +
> >   drivers/accel/ivpu/ivpu_pm.c  |  3 ++-
> >   6 files changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> > index 3f4efa07ce7c..1eb232e903e8 100644
> > --- a/drivers/accel/ivpu/ivpu_drv.c
> > +++ b/drivers/accel/ivpu/ivpu_drv.c
> > @@ -367,14 +367,19 @@ int ivpu_boot(struct ivpu_device *vdev)
> > return 0;
> >   }
> > -int ivpu_shutdown(struct ivpu_device *vdev)
> > +void ivpu_prepare_for_reset(struct ivpu_device *vdev)
> >   {
> > -   int ret;
> > -
> > ivpu_hw_irq_disable(vdev);
> > disable_irq(vdev->irq);
> > ivpu_ipc_disable(vdev);
> > ivpu_mmu_disable(vdev);
> > +}
> > +
> > +int ivpu_shutdown(struct ivpu_device *vdev)
> > +{
> > +   int ret;
> > +
> > +   ivpu_prepare_for_reset(vdev);
> > ret = ivpu_hw_power_down(vdev);
> > if (ret)
> > diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
> > index 98380c1db9fa..a3b45032e6cf 100644
> > --- a/drivers/accel/ivpu/ivpu_drv.h
> > +++ b/drivers/accel/ivpu/ivpu_drv.h
> > @@ -158,6 +158,7 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link);
> >   int ivpu_boot(struct ivpu_device *vdev);
> >   int ivpu_shutdown(struct ivpu_device *vdev);
> > +void ivpu_prepare_for_reset(struct ivpu_device *vdev);
> >   static inline u8 ivpu_revision(struct ivpu_device *vdev)
> >   {
> > diff --git a/drivers/accel/ivpu/ivpu_hw.h b/drivers/accel/ivpu/ivpu_hw.h
> > index ab341237bcf9..1079e06255ba 100644
> > --- a/drivers/accel/ivpu/ivpu_hw.h
> > +++ b/drivers/accel/ivpu/ivpu_hw.h
> > @@ -13,6 +13,7 @@ struct ivpu_hw_ops {
> > int (*power_up)(struct ivpu_device *vdev);
> > int (*boot_fw)(struct ivpu_device *vdev);
> > int (*power_down)(struct ivpu_device *vdev);
> > +   int (*reset)(struct ivpu_device *vdev);
> > bool (*is_idle)(struct ivpu_device *vdev);
> > void (*wdt_disable)(struct ivpu_device *vdev);
> > void (*diagnose_failure)(struct ivpu_device *vdev);
> > @@ -91,6 +92,13 @@ static inline int ivpu_hw_power_down(struct ivpu_device 
> > *vdev)
> > return vdev->hw->ops->power_down(vdev);
> >   };
> > +static inline int ivpu_hw_reset(struct ivpu_device *vdev)
> > +{
> > +   ivpu_dbg(vdev, PM, "HW reset\n");
> > +
> > +   return vdev->hw->ops->reset(vdev);
> > +};
> > +
> >   static inline void ivpu_hw_wdt_disable(struct ivpu_device *vdev)
> >   {
> > vdev->hw->ops->wdt_disable(vdev);
> > diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c 
> > b/drivers/accel/ivpu/ivpu_hw_37xx.c
> > index edd4d860f135..1e842739e937 100644
> > --- a/drivers/accel/ivpu/ivpu_hw_37xx.c
> > +++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
> > @@ -1036,6 +1036,7 @@ const struct ivpu_hw_ops ivpu_hw_37xx_ops = {
> > .power_up = ivpu_hw_37xx_power_up,
> > .is_idle = ivpu_hw_37xx_is_idle,
> > .power_down = ivpu_hw_37xx_power_down,
> > +   .reset = ivpu_hw_37xx_reset,
> > .boot_fw = ivpu_hw_37xx_boot_fw,
> > .wdt_disable = ivpu_hw_37xx_wdt_disable,
> > .diagnose_failure = ivpu_hw_37xx_diagnose_failure,
> > diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c 
> > b/drivers/accel/ivpu/ivpu_hw_40xx.c
> > index a48cd36f9931..d7b8ec0410af 100644
> > --- a/drivers/accel/ivpu/ivpu_hw_40xx.c
> > +++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
> > @@ -1186,6 +1186,7 @@ const struct ivpu_hw_ops ivpu_hw_40xx_ops = {
> > .power_up = ivpu_hw_40xx_power_up,
> > .is_idle = ivpu_hw_40xx_is_idle,
> > .power_down = ivpu_hw_40xx_power_down,
> > +   .reset = ivpu_hw_40xx_reset,
> > .boot_fw = ivpu_hw_40xx_boot_fw,
> > .wdt_disable = ivpu_hw_40xx_wdt_disable,
> > .diagnose_failure = ivpu_hw_40xx_diagnose_failure,
> > diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c
> > index 28a0de12..da46f95b008a 100644
> > --- a/drivers/accel/ivpu/ivpu_pm.c
> > +++ b/drivers/accel/ivpu/ivpu_pm.c
> > @@ -261

Re: [Intel-xe] [PATCH] drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT

2023-10-17 Thread Francois Dugast
On Tue, Oct 17, 2023 at 10:14:59AM +0200, Thomas Hellström wrote:
> 
> On 10/17/23 09:54, Danilo Krummrich wrote:
> > On Tue, Oct 10, 2023 at 04:27:24PM +0200, Thomas Hellström wrote:
> > > Dual-licence in order to make it possible for other non-GPL os'es
> > > to re-implement the code. The use of EXPORT_SYMBOL_GPL() is intentionally
> > > left untouched to prevent use of drm_gpuvm as a proxy for non-GPL drivers
> > > to access GPL-only kernel symbols.
> > > 
> > > Much of the ideas and algorithms used in the drm_gpuvm code is already
> > > present in one way or another in MIT-licensed code.
> > > 
> > > Cc: Danilo Krummrich 
> > > Cc: airl...@gmail.com
> > > Cc: dan...@ffwll.ch
> > > Cc: linux-ker...@vger.kernel.org
> > > Signed-off-by: Thomas Hellström 
> > Acked-by: Danilo Krummrich 

As this was acked by author:

Reviewed-by: Francois Dugast 

> 
> Thanks, Danilo
> 
> Thomas
> 
> 
> > 
> > > ---
> > >   drivers/gpu/drm/drm_gpuvm.c | 2 +-
> > >   include/drm/drm_gpuvm.h | 2 +-
> > >   2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> > > index 02ce6baacdad..08c088319652 100644
> > > --- a/drivers/gpu/drm/drm_gpuvm.c
> > > +++ b/drivers/gpu/drm/drm_gpuvm.c
> > > @@ -1,4 +1,4 @@
> > > -// SPDX-License-Identifier: GPL-2.0-only
> > > +// SPDX-License-Identifier: GPL-2.0 OR MIT
> > >   /*
> > >* Copyright (c) 2022 Red Hat.
> > >*
> > > diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
> > > index 361fea5cb849..21bbf11415b3 100644
> > > --- a/include/drm/drm_gpuvm.h
> > > +++ b/include/drm/drm_gpuvm.h
> > > @@ -1,4 +1,4 @@
> > > -/* SPDX-License-Identifier: GPL-2.0-only */
> > > +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
> > >   #ifndef __DRM_GPUVM_H__
> > >   #define __DRM_GPUVM_H__
> > > -- 
> > > 2.41.0
> > > 


[PATCH v7 1/6] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits

2023-10-17 Thread André Almeida
From: Simon Ser 

If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.

Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back to
something else. For instance, Xorg falls back to a blit.
Another option is to wait as close to the next vblank as
possible before performing the page-flip to reduce latency.

Signed-off-by: Simon Ser 
Reviewed-by: Alex Deucher 
Co-developed-by: André Almeida 
Signed-off-by: André Almeida 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 28 +---
 include/uapi/drm/drm_mode.h   |  9 +
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 98d3b10c08ae..a15121e75a0a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1323,6 +1323,18 @@ static void complete_signaling(struct drm_device *dev,
kfree(fence_state);
 }
 
+static void
+set_async_flip(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int i;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   crtc_state->async_flip = true;
+   }
+}
+
 int drm_mode_atomic_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
 {
@@ -1363,9 +1375,16 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
 
if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC) {
-   drm_dbg_atomic(dev,
-  "commit failed: invalid flag 
DRM_MODE_PAGE_FLIP_ASYNC\n");
-   return -EINVAL;
+   if (!dev->mode_config.async_page_flip) {
+   drm_dbg_atomic(dev,
+  "commit failed: DRM_MODE_PAGE_FLIP_ASYNC 
not supported\n");
+   return -EINVAL;
+   }
+   if (dev->mode_config.atomic_async_page_flip_not_supported) {
+   drm_dbg_atomic(dev,
+  "commit failed: DRM_MODE_PAGE_FLIP_ASYNC 
not supported with atomic\n");
+   return -EINVAL;
+   }
}
 
/* can't test and expect an event at the same time. */
@@ -1468,6 +1487,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (ret)
goto out;
 
+   if (arg->flags & DRM_MODE_PAGE_FLIP_ASYNC)
+   set_async_flip(state);
+
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index ea1b639bcb28..04e6a3caa675 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -957,6 +957,15 @@ struct hdr_output_metadata {
  * Request that the page-flip is performed as soon as possible, ie. with no
  * delay due to waiting for vblank. This may cause tearing to be visible on
  * the screen.
+ *
+ * When used with atomic uAPI, the driver will return an error if the hardware
+ * doesn't support performing an asynchronous page-flip for this update.
+ * User-space should handle this, e.g. by falling back to a regular page-flip.
+ *
+ * Note, some hardware might need to perform one last synchronous page-flip
+ * before being able to switch to asynchronous page-flips. As an exception,
+ * the driver will return success even though that first page-flip is not
+ * asynchronous.
  */
 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
 #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
-- 
2.42.0



[PATCH v7 0/6] drm: Add support for atomic async page-flip

2023-10-17 Thread André Almeida
Hi,

This work from me and Simon adds support for DRM_MODE_PAGE_FLIP_ASYNC through
the atomic API. This feature is already available via the legacy API. The use
case is to be able to present a new frame immediately (or as soon as
possible), even if after missing a vblank. This might result in tearing, but
it's useful when a high framerate is desired, such as for gaming.

Differently from earlier versions, this one refuses to flip if any prop changes
for async flips. The idea is that the fast path of immediate page flips doesn't
play well with modeset changes, so only the fb_id can be changed.
Thanks,
André

- User-space patch: https://github.com/Plagman/gamescope/pull/595
- IGT tests: 
https://gitlab.freedesktop.org/andrealmeid/igt-gpu-tools/-/tree/atomic_async_page_flip

Changes from v6:
- Dropped the exception to allow MODE_ID changes (Simon)
- Clarify what happens when flipping with the same FB_ID (Pekka)

v6: 
https://lore.kernel.org/dri-devel/20230815185710.159779-1-andrealm...@igalia.com/

Changes from v5:
- Add note in the docs that not every redundant attribute will result in no-op,
  some might cause oversynchronization issues.

v5: 
https://lore.kernel.org/dri-devel/20230707224059.305474-1-andrealm...@igalia.com/

Changes from v4:
 - Documentation rewrote by Pekka Paalanen

v4: 
https://lore.kernel.org/dri-devel/20230701020917.143394-1-andrealm...@igalia.com/

Changes from v3:
 - Add new patch to reject prop changes
 - Add a documentation clarifying the KMS atomic state set

v3: 
https://lore.kernel.org/dri-devel/20220929184307.258331-1-cont...@emersion.fr/

André Almeida (1):
  drm: Refuse to async flip with atomic prop changes

Pekka Paalanen (1):
  drm/doc: Define KMS atomic state set

Simon Ser (4):
  drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
  drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
  drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
  amd/display: indicate support for atomic async page-flips on DC

 Documentation/gpu/drm-uapi.rst| 47 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c | 75 +--
 drivers/gpu/drm/drm_crtc_internal.h   |  2 +-
 drivers/gpu/drm/drm_ioctl.c   |  5 ++
 drivers/gpu/drm/drm_mode_object.c |  2 +-
 .../drm/i915/display/intel_display_driver.c   |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c |  1 +
 include/drm/drm_mode_config.h | 11 +++
 include/uapi/drm/drm.h| 10 ++-
 include/uapi/drm/drm_mode.h   |  9 +++
 11 files changed, 155 insertions(+), 9 deletions(-)

-- 
2.42.0



[PATCH v7 3/6] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported

2023-10-17 Thread André Almeida
From: Simon Ser 

This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.

All atomic drivers setting drm_mode_config.async_page_flip are updated
to also set drm_mode_config.atomic_async_page_flip_not_supported. We
will gradually check and update these drivers to properly handle
drm_crtc_state.async_flip in their atomic logic.

The goal of this negative flag is the same as
fb_modifiers_not_supported: we want to eventually get rid of all
drivers missing atomic support for async flips. New drivers should not
set this flag, instead they should support atomic async flips (if
they support async flips at all). IOW, we don't want more drivers
with async flip support for legacy but not atomic.

Signed-off-by: Simon Ser 
Reviewed-by: André Almeida 
Reviewed-by: Alex Deucher 
Signed-off-by: André Almeida 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  1 +
 drivers/gpu/drm/i915/display/intel_display_driver.c |  1 +
 drivers/gpu/drm/nouveau/nouveau_display.c   |  1 +
 include/drm/drm_mode_config.h   | 11 +++
 5 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c6fd34bab358..9d5742923aed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3997,6 +3997,7 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
/* indicates support for immediate flip */
adev_to_drm(adev)->mode_config.async_page_flip = true;
+   adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = 
true;
 
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 84c54e8622d1..f1d9bb1d7c34 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -639,6 +639,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)
dev->mode_config.max_height = dc->desc->max_height;
dev->mode_config.funcs = &mode_config_funcs;
dev->mode_config.async_page_flip = true;
+   dev->mode_config.atomic_async_page_flip_not_supported = true;
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 44b59ac301e6..6142c83fba06 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -126,6 +126,7 @@ static void intel_mode_config_init(struct drm_i915_private 
*i915)
mode_config->helper_private = &intel_mode_config_funcs;
 
mode_config->async_page_flip = HAS_ASYNC_FLIPS(i915);
+   mode_config->atomic_async_page_flip_not_supported = true;
 
/*
 * Maximum framebuffer dimensions, chosen to match
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d8c92521226d..586aa51794e8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -720,6 +720,7 @@ nouveau_display_create(struct drm_device *dev)
dev->mode_config.async_page_flip = false;
else
dev->mode_config.async_page_flip = true;
+   dev->mode_config.atomic_async_page_flip_not_supported = true;
 
drm_kms_helper_poll_init(dev);
drm_kms_helper_poll_disable(dev);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..47b005671e6a 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -918,6 +918,17 @@ struct drm_mode_config {
 */
bool async_page_flip;
 
+   /**
+* @atomic_async_page_flip_not_supported:
+*
+* If true, the driver does not support async page-flips with the
+* atomic uAPI. This is only used by old drivers which haven't yet
+* accomodated for &drm_crtc_state.async_flip in their atomic logic,
+* even if they have &drm_mode_config.async_page_flip set to true.
+* New drivers shall not set this flag.
+*/
+   bool atomic_async_page_flip_not_supported;
+
/**
 * @fb_modifiers_not_supported:
 *
-- 
2.42.0



[PATCH v7 2/6] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP

2023-10-17 Thread André Almeida
From: Simon Ser 

This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.

Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.

Signed-off-by: Simon Ser 
Reviewed-by: André Almeida 
Reviewed-by: Alex Deucher 
Signed-off-by: André Almeida 
---
 drivers/gpu/drm/drm_ioctl.c |  5 +
 include/uapi/drm/drm.h  | 10 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 77590b0f38fa..a96e7acb9071 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -301,6 +301,11 @@ static int drm_getcap(struct drm_device *dev, void *data, 
struct drm_file *file_
case DRM_CAP_CRTC_IN_VBLANK_EVENT:
req->value = 1;
break;
+   case DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP:
+   req->value = drm_core_check_feature(dev, DRIVER_ATOMIC) &&
+dev->mode_config.async_page_flip &&
+
!dev->mode_config.atomic_async_page_flip_not_supported;
+   break;
default:
return -EINVAL;
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 794c1d857677..58baefe32c23 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -713,7 +713,8 @@ struct drm_gem_open {
 /**
  * DRM_CAP_ASYNC_PAGE_FLIP
  *
- * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC.
+ * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC for legacy
+ * page-flips.
  */
 #define DRM_CAP_ASYNC_PAGE_FLIP0x7
 /**
@@ -773,6 +774,13 @@ struct drm_gem_open {
  * :ref:`drm_sync_objects`.
  */
 #define DRM_CAP_SYNCOBJ_TIMELINE   0x14
+/**
+ * DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
+ *
+ * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC for atomic
+ * commits.
+ */
+#define DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP 0x15
 
 /* DRM_IOCTL_GET_CAP ioctl argument type */
 struct drm_get_cap {
-- 
2.42.0



[PATCH v7 6/6] amd/display: indicate support for atomic async page-flips on DC

2023-10-17 Thread André Almeida
From: Simon Ser 

amdgpu_dm_commit_planes() already sets the flip_immediate flag for
async page-flips. This flag is used to set the UNP_FLIP_CONTROL
register. Thus, no additional change is required to handle async
page-flips with the atomic uAPI.

Signed-off-by: Simon Ser 
Reviewed-by: André Almeida 
Reviewed-by: Alex Deucher 
Signed-off-by: André Almeida 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 9d5742923aed..c6fd34bab358 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3997,7 +3997,6 @@ static int amdgpu_dm_mode_config_init(struct 
amdgpu_device *adev)
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
/* indicates support for immediate flip */
adev_to_drm(adev)->mode_config.async_page_flip = true;
-   adev_to_drm(adev)->mode_config.atomic_async_page_flip_not_supported = 
true;
 
state = kzalloc(sizeof(*state), GFP_KERNEL);
if (!state)
-- 
2.42.0



[PATCH v7 5/6] drm/doc: Define KMS atomic state set

2023-10-17 Thread André Almeida
From: Pekka Paalanen 

Specify how the atomic state is maintained between userspace and
kernel, plus the special case for async flips.

Signed-off-by: Pekka Paalanen 
Signed-off-by: André Almeida 
---
v7:
- add a note that drivers can make exceptions for ad-hoc prop changes
- add a note about flipping the same FB_ID as a no-op
---
 Documentation/gpu/drm-uapi.rst | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 632989df3727..34bd02270ee7 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -570,3 +570,50 @@ dma-buf interoperability
 
 Please see Documentation/userspace-api/dma-buf-alloc-exchange.rst for
 information on how dma-buf is integrated and exposed within DRM.
+
+KMS atomic state
+
+
+An atomic commit can change multiple KMS properties in an atomic fashion,
+without ever applying intermediate or partial state changes.  Either the whole
+commit succeeds or fails, and it will never be applied partially. This is the
+fundamental improvement of the atomic API over the older non-atomic API which 
is
+referred to as the "legacy API".  Applying intermediate state could 
unexpectedly
+fail, cause visible glitches, or delay reaching the final state.
+
+An atomic commit can be flagged with DRM_MODE_ATOMIC_TEST_ONLY, which means the
+complete state change is validated but not applied.  Userspace should use this
+flag to validate any state change before asking to apply it. If validation 
fails
+for any reason, userspace should attempt to fall back to another, perhaps
+simpler, final state.  This allows userspace to probe for various 
configurations
+without causing visible glitches on screen and without the need to undo a
+probing change.
+
+The changes recorded in an atomic commit apply on top the current KMS state in
+the kernel. Hence, the complete new KMS state is the complete old KMS state 
with
+the committed property settings done on top. The kernel will try to avoid
+no-operation changes, so it is safe for userspace to send redundant property
+settings.  However, not every situation allows for no-op changes, due to the
+need to acquire locks for some attributes. Userspace needs to be aware that 
some
+redundant information might result in oversynchronization issues.  No-operation
+changes do not count towards actually needed changes, e.g.  setting MODE_ID to 
a
+different blob with identical contents as the current KMS state shall not be a
+modeset on its own. As a special exception for VRR needs, explicitly setting
+FB_ID to its current value is not a no-op.
+
+A "modeset" is a change in KMS state that might enable, disable, or temporarily
+disrupt the emitted video signal, possibly causing visible glitches on screen. 
A
+modeset may also take considerably more time to complete than other kinds of
+changes, and the video sink might also need time to adapt to the new signal
+properties. Therefore a modeset must be explicitly allowed with the flag
+DRM_MODE_ATOMIC_ALLOW_MODESET.  This in combination with
+DRM_MODE_ATOMIC_TEST_ONLY allows userspace to determine if a state change is
+likely to cause visible disruption on screen and avoid such changes when end
+users do not expect them.
+
+An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is allowed to
+effectively change only the FB_ID property on any planes. No-operation changes
+are ignored as always. Changing any other property will cause the commit to be
+rejected. Each driver may relax this restriction if they have guarantees that
+such property change doesn't cause modesets. Userspace can use TEST_ONLY 
commits
+to query the driver about this.
-- 
2.42.0



[PATCH v7 4/6] drm: Refuse to async flip with atomic prop changes

2023-10-17 Thread André Almeida
Given that prop changes may lead to modesetting, which would defeat the
fast path of the async flip, refuse any atomic prop change for async
flips in atomic API. The only exceptions are the framebuffer ID to flip
to and the mode ID, that could be referring to an identical mode.

Signed-off-by: André Almeida 
---
v7: drop the mode_id exception for prop changes
---
 drivers/gpu/drm/drm_atomic_uapi.c   | 47 +++--
 drivers/gpu/drm/drm_crtc_internal.h |  2 +-
 drivers/gpu/drm/drm_mode_object.c   |  2 +-
 3 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index a15121e75a0a..b358de1bf4e7 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1006,13 +1006,28 @@ int drm_atomic_connector_commit_dpms(struct 
drm_atomic_state *state,
return ret;
 }
 
+static int drm_atomic_check_prop_changes(int ret, uint64_t old_val, uint64_t 
prop_value,
+struct drm_property *prop)
+{
+   if (ret != 0 || old_val != prop_value) {
+   drm_dbg_atomic(prop->dev,
+  "[PROP:%d:%s] No prop can be changed during 
async flip\n",
+  prop->base.id, prop->name);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 int drm_atomic_set_property(struct drm_atomic_state *state,
struct drm_file *file_priv,
struct drm_mode_object *obj,
struct drm_property *prop,
-   uint64_t prop_value)
+   uint64_t prop_value,
+   bool async_flip)
 {
struct drm_mode_object *ref;
+   uint64_t old_val;
int ret;
 
if (!drm_property_change_valid_get(prop, prop_value, &ref))
@@ -1029,6 +1044,13 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
+   if (async_flip) {
+   ret = drm_atomic_connector_get_property(connector, 
connector_state,
+   prop, &old_val);
+   ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
+   break;
+   }
+
ret = drm_atomic_connector_set_property(connector,
connector_state, file_priv,
prop, prop_value);
@@ -1037,6 +1059,7 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
case DRM_MODE_OBJECT_CRTC: {
struct drm_crtc *crtc = obj_to_crtc(obj);
struct drm_crtc_state *crtc_state;
+   struct drm_mode_config *config = &crtc->dev->mode_config;
 
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
@@ -1044,6 +1067,13 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
+   if (async_flip) {
+   ret = drm_atomic_crtc_get_property(crtc, crtc_state,
+  prop, &old_val);
+   ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
+   break;
+   }
+
ret = drm_atomic_crtc_set_property(crtc,
crtc_state, prop, prop_value);
break;
@@ -1051,6 +1081,7 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
case DRM_MODE_OBJECT_PLANE: {
struct drm_plane *plane = obj_to_plane(obj);
struct drm_plane_state *plane_state;
+   struct drm_mode_config *config = &plane->dev->mode_config;
 
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
@@ -1058,6 +1089,13 @@ int drm_atomic_set_property(struct drm_atomic_state 
*state,
break;
}
 
+   if (async_flip && prop != config->prop_fb_id) {
+   ret = drm_atomic_plane_get_property(plane, plane_state,
+   prop, &old_val);
+   ret = drm_atomic_check_prop_changes(ret, old_val, 
prop_value, prop);
+   break;
+   }
+
ret = drm_atomic_plane_set_property(plane,
plane_state, file_priv,
prop, prop_value);
@@ -1349,6 +1387,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_out_fence_state *fence_state;
int ret = 0;
unsigned int i, j, num_fences;
+   bool async_flip = false;
 
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, 

Re: [PATCH v8 04/23] dt-bindings: display: mediatek: padding: Add MT8188

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:39, Hsiao Chien Sung ha scritto:

Padding is a new hardware module on MediaTek MT8188,
add dt-bindings for it.

Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 





Re: [PATCH v8 17/23] drm/mediatek: Support MT8188 Padding in display driver

2023-10-17 Thread 胡俊光


Re: [PATCH v8 18/23] drm/mediatek: Add Padding to OVL adaptor

2023-10-17 Thread 胡俊光


Re: [PATCH v8 11/23] drm/mediatek: Rename OVL_ADAPTOR_TYPE_RDMA

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:39, Hsiao Chien Sung ha scritto:

Rename OVL_ADAPTOR_TYPE_RDMA to OVL_ADAPTOR_TYPE_MDP_RDMA
to align the naming rule of mtk_ovl_adaptor_comp_id.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 12/23] drm/mediatek: Refine device table of OVL adaptor

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:39, Hsiao Chien Sung ha scritto:

- Adjust indentation to align with other files
- Sort device table in alphabetical order
- Add sentinel to device table

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 13/23] drm/mediatek: Sort OVL adaptor components

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Sort OVL adaptor components' names in alphabetical order.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 





Re: [PATCH v8 14/23] drm/mediatek: Add component ID to component match structure

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Add component ID to component match structure so we can
configure them with a for-loop.

The main reason we do such code refactoring is that
there is a new hardware component called "Padding" since
MT8188, while MT8195 doesn't have this module, we can't
use the original logic to manage the components.

While MT8195 does not define Padding in the device tree,
the corresponding components will be NULL and being skipped
by the functions.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 15/23] drm/mediatek: Manage component's clock with function pointers

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of clock control significantly.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 16/23] drm/mediatek: Start/Stop components with function pointers

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of component start/stop process.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 17/23] drm/mediatek: Support MT8188 Padding in display driver

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Padding is a new display module on MT8188, it provides ability
to add pixels to width and height of a layer with specified colors.

Due to hardware design, Mixer in VDOSYS1 requires width of a layer
to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled,
we need Padding to deal with odd width.

Signed-off-by: Hsiao Chien Sung 
---
  drivers/gpu/drm/mediatek/Makefile   |   3 +-
  drivers/gpu/drm/mediatek/mtk_disp_drv.h |   4 +
  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   1 +
  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   2 +-
  drivers/gpu/drm/mediatek/mtk_padding.c  | 160 
  5 files changed, 168 insertions(+), 2 deletions(-)
  create mode 100644 drivers/gpu/drm/mediatek/mtk_padding.c

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index d4d193f60271..5e4436403b8d 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -16,7 +16,8 @@ mediatek-drm-y := mtk_disp_aal.o \
  mtk_dsi.o \
  mtk_dpi.o \
  mtk_ethdr.o \
- mtk_mdp_rdma.o
+ mtk_mdp_rdma.o \
+ mtk_padding.o
  
  obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
  
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h

index bf06ccb65652..e2b602037ac3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -159,4 +159,8 @@ void mtk_mdp_rdma_config(struct device *dev, struct 
mtk_mdp_rdma_cfg *cfg,
  const u32 *mtk_mdp_rdma_get_formats(struct device *dev);
  size_t mtk_mdp_rdma_get_num_formats(struct device *dev);
  
+int mtk_padding_clk_enable(struct device *dev);

+void mtk_padding_clk_disable(struct device *dev);
+void mtk_padding_start(struct device *dev);
+void mtk_padding_stop(struct device *dev);
  #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index cdce165c092e..62e6e9785443 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -1025,6 +1025,7 @@ static struct platform_driver * const mtk_drm_drivers[] = 
{
&mtk_dsi_driver,
&mtk_ethdr_driver,
&mtk_mdp_rdma_driver,
+   &mtk_padding_driver,
  };
  
  static int __init mtk_drm_init(void)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 8dca68ea1b94..d2efd715699f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -72,5 +72,5 @@ extern struct platform_driver mtk_dpi_driver;
  extern struct platform_driver mtk_dsi_driver;
  extern struct platform_driver mtk_ethdr_driver;
  extern struct platform_driver mtk_mdp_rdma_driver;
-
+extern struct platform_driver mtk_padding_driver;
  #endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_padding.c 
b/drivers/gpu/drm/mediatek/mtk_padding.c
new file mode 100644
index ..fa2e7fc9c7bd
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_padding.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 MediaTek Inc.
+ */
+


..snip..


+
+static const struct of_device_id mtk_padding_driver_dt_match[] = {
+   { .compatible = "mediatek,mt8188-padding" },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mtk_padding_driver_dt_match);
+
+struct platform_driver mtk_padding_driver = {
+   .probe  = mtk_padding_probe,
+   .remove = mtk_padding_remove,
+   .driver = {
+   .name   = "mediatek-padding",


Please let's be consistent with the driver names, this should be
"mediatek-disp-padding".

After changing that,

Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 21/23] drm/mediatek: Fix underrun in VDO1 when switches off the layer

2023-10-17 Thread 胡俊光


Re: [PATCH v8 15/23] drm/mediatek: Manage component's clock with function pointers

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of clock control significantly.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 111 +++---
  1 file changed, 44 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 60e5dfe9ef0d..fffef2a4f919 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -53,6 +53,7 @@ struct ovl_adaptor_comp_match {
enum mtk_ovl_adaptor_comp_type type;
enum mtk_ddp_comp_id comp_id;
int alias_id;
+   const struct mtk_ddp_comp_funcs *funcs;
  };
  
  struct mtk_disp_ovl_adaptor {

@@ -67,20 +68,35 @@ static const char * const 
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
  };
  
+static const struct mtk_ddp_comp_funcs _ethdr = {


Sorry I just noticed that; can you please remove the leading "_" from all
of those?

_ethdr -> ethdr or mtk_ethdr
_merge -> merge or mtk_merge
_rdma  -> rdma  or mtk_rdma

Thanks,
Angelo



Re: [PATCH v8 18/23] drm/mediatek: Add Padding to OVL adaptor

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Add MT8188 Padding to OVL adaptor to probe the driver.

Signed-off-by: Hsiao Chien Sung 


---
  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 26 +++
  1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 354ba6186166..b80425360e76 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -29,6 +29,7 @@ enum mtk_ovl_adaptor_comp_type {
OVL_ADAPTOR_TYPE_ETHDR,
OVL_ADAPTOR_TYPE_MDP_RDMA,
OVL_ADAPTOR_TYPE_MERGE,
+   OVL_ADAPTOR_TYPE_PADDING,
OVL_ADAPTOR_TYPE_NUM,
  };
  
@@ -46,6 +47,14 @@ enum mtk_ovl_adaptor_comp_id {

OVL_ADAPTOR_MERGE1,
OVL_ADAPTOR_MERGE2,
OVL_ADAPTOR_MERGE3,
+   OVL_ADAPTOR_PADDING0,
+   OVL_ADAPTOR_PADDING1,
+   OVL_ADAPTOR_PADDING2,
+   OVL_ADAPTOR_PADDING3,
+   OVL_ADAPTOR_PADDING4,
+   OVL_ADAPTOR_PADDING5,
+   OVL_ADAPTOR_PADDING6,
+   OVL_ADAPTOR_PADDING7,
OVL_ADAPTOR_ID_MAX
  };
  
@@ -66,6 +75,7 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {

[OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
[OVL_ADAPTOR_TYPE_MDP_RDMA] = "vdo1-rdma",
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
+   [OVL_ADAPTOR_TYPE_PADDING]  = "padding",
  };
  
  static const struct mtk_ddp_comp_funcs _ethdr = {

@@ -80,6 +90,13 @@ static const struct mtk_ddp_comp_funcs _merge = {
.clk_disable = mtk_merge_clk_disable,
  };
  
+static const struct mtk_ddp_comp_funcs _padding = {


Please, _padding -> padding or mtk_padding


Thanks,
Angelo


Re: [PATCH v8 19/23] drm/mediatek: Return error if MDP RDMA failed to enable the clock

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Return the result of clk_prepare_enable() instead of
always returns 0.

Fixes: f8946e2b6bb2 ("drm/mediatek: Add display MDP RDMA support for MT8195")

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 





Re: [PATCH v8 20/23] drm/mediatek: Remove the redundant driver data for DPI

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

DPI input is in 1T2P mode on both MT8195 and MT8188.
Remove the redundant driver data to align the settings, or
the screen will glitch.

Fixes: 2847cd7e6403 ("drm/mediatek: Add mt8188 dpi compatibles and platform 
data")

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 





Re: [PATCH v8 21/23] drm/mediatek: Fix underrun in VDO1 when switches off the layer

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Do not reset Merge while using CMDQ because reset API doesn't
wait for frame done event as CMDQ does and could lead to
underrun when the layer is switching off.

Fixes: aaf94f7c3ae6 ("drm/mediatek: Add display merge async reset control")

Signed-off-by: Hsiao Chien Sung 


Reviewed-by: AngeloGioacchino Del Regno 





Re: [PATCH v8 22/23] drm/mediatek: Power on devices in OVL adaptor when atomic enable

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

Different from OVL, OVL adaptor is a pseudo device so we didn't
define it in the device tree, consequently, pm_runtime_resume_and_get()
called by .atomic_enable() powers on no device in OVL adaptor and
leads to power outage in the corresponding IOMMU.

To resolve the issue, we implement a function to power on the RDMAs
in OVL adaptor, and the system will make sure the IOMMU is powered on
as well because of the device link (iommus) in the RDMA nodes in DTS.

Fixes: 5db12f5d843b ("media: drm/mediatek: Add pm runtime support for ovl and 
rdma")

Signed-off-by: Hsiao Chien Sung 
---
  drivers/gpu/drm/mediatek/mtk_disp_drv.h   |  4 ++
  .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 62 +++
  drivers/gpu/drm/mediatek/mtk_drm_crtc.c   | 28 +++--
  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  2 +
  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   | 20 ++
  drivers/gpu/drm/mediatek/mtk_mdp_rdma.c   | 16 +
  6 files changed, 111 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h 
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index e2b602037ac3..c44f5b31bab5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -109,6 +109,8 @@ void mtk_ovl_adaptor_connect(struct device *dev, struct 
device *mmsys_dev,
 unsigned int next);
  void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
unsigned int next);
+int mtk_ovl_adaptor_power_on(struct device *dev);
+void mtk_ovl_adaptor_power_off(struct device *dev);
  int mtk_ovl_adaptor_clk_enable(struct device *dev);
  void mtk_ovl_adaptor_clk_disable(struct device *dev);
  void mtk_ovl_adaptor_config(struct device *dev, unsigned int w,
@@ -150,6 +152,8 @@ void mtk_rdma_disable_vblank(struct device *dev);
  const u32 *mtk_rdma_get_formats(struct device *dev);
  size_t mtk_rdma_get_num_formats(struct device *dev);
  
+int mtk_mdp_rdma_power_on(struct device *dev);

+void mtk_mdp_rdma_power_off(struct device *dev);
  int mtk_mdp_rdma_clk_enable(struct device *dev);
  void mtk_mdp_rdma_clk_disable(struct device *dev);
  void mtk_mdp_rdma_start(struct device *dev, struct cmdq_pkt *cmdq_pkt);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index b80425360e76..8de57a5f5518 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -98,6 +98,8 @@ static const struct mtk_ddp_comp_funcs _padding = {
  };
  
  static const struct mtk_ddp_comp_funcs _rdma = {

+   .power_on = mtk_mdp_rdma_power_on,
+   .power_off = mtk_mdp_rdma_power_off,
.clk_enable = mtk_mdp_rdma_clk_enable,
.clk_disable = mtk_mdp_rdma_clk_disable,
  };
@@ -241,6 +243,66 @@ void mtk_ovl_adaptor_stop(struct device *dev)
}
  }
  
+/**

+ * mtk_ovl_adaptor_power_on - Power on devices in OVL adaptor
+ * @dev: device to be powered on
+ *
+ * Different from OVL, OVL adaptor is a pseudo device so
+ * we didn't define it in the device tree, pm_runtime_resume_and_get()
+ * called by .atomic_enable() power on no device in OVL adaptor,
+ * we have to implement a function to do the job instead.
+ *
+ * returns:
+ * zero on success, errno on failures.


You're almost there! There's just one mistake making this invalid kerneldoc;
change to...

 * Return: Zero for success or negative number for failure.

https://docs.kernel.org/doc-guide/kernel-doc.html


+ */
+int mtk_ovl_adaptor_power_on(struct device *dev)
+{
+   int i, ret;
+   struct mtk_disp_ovl_adaptor *ovl_adaptor = dev_get_drvdata(dev);
+
+   for (i = 0; i < OVL_ADAPTOR_ID_MAX; i++) {
+   if (!ovl_adaptor->ovl_adaptor_comp[i] ||
+   !comp_matches[i].funcs->power_on)
+   continue;
+
+   /*
+* do not power on the devices that don't define
+* .power_off() function
+*/
+   if (!comp_matches[i].funcs->power_off) {
+   dev_warn(dev, ".power_off() is undefined\n");
+   continue;
+   }
+
+   ret = 
comp_matches[i].funcs->power_on(ovl_adaptor->ovl_adaptor_comp[i]);
+   if (ret < 0) {
+   mtk_ovl_adaptor_power_off(dev);
+   return ret;
+   }
+   }
+   return 0;
+}
+
+/**
+ * mtk_ovl_adaptor_power_off - Power off devices in OVL adaptor
+ * @dev: device to be powered off
+ *
+ * call .power_off() function if defined


 * Calls the .power_off() ovl_adaptor component callback if it is present.


+ */


Regards,
Angelo



Re: [PATCH drm-misc-next v6 3/6] drm/gpuvm: add an abstraction for a VM / BO combination

2023-10-17 Thread Danilo Krummrich
On Fri, Oct 13, 2023 at 02:30:29PM +0200, Thomas Hellström wrote:
> On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:
> > Add an abstraction layer between the drm_gpuva mappings of a
> > particular
> > drm_gem_object and this GEM object itself. The abstraction represents
> > a
> > combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> > holds
> > a list of drm_gpuvm_bo structures (the structure representing this
> > abstraction), while each drm_gpuvm_bo contains list of mappings of
> > this
> > GEM object.
> > 
> > This has multiple advantages:
> > 
> > 1) We can use the drm_gpuvm_bo structure to attach it to various
> > lists
> >    of the drm_gpuvm. This is useful for tracking external and evicted
> >    objects per VM, which is introduced in subsequent patches.
> > 
> > 2) Finding mappings of a certain drm_gem_object mapped in a certain
> >    drm_gpuvm becomes much cheaper.
> > 
> > 3) Drivers can derive and extend the structure to easily represent
> >    driver specific states of a BO for a certain GPUVM.
> > 
> > The idea of this abstraction was taken from amdgpu, hence the credit
> > for
> > this idea goes to the developers of amdgpu.
> > 
> > Cc: Christian König 
> > Signed-off-by: Danilo Krummrich 
> > ---
> >  drivers/gpu/drm/drm_gpuvm.c    | 332 +--
> > --
> >  drivers/gpu/drm/nouveau/nouveau_uvmm.c |  64 +++--
> >  include/drm/drm_gem.h  |  32 +--
> >  include/drm/drm_gpuvm.h    | 177 -
> >  4 files changed, 521 insertions(+), 84 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gpuvm.c
> > b/drivers/gpu/drm/drm_gpuvm.c
> > index 6368dfdbe9dd..28282283ddaf 100644
> > --- a/drivers/gpu/drm/drm_gpuvm.c
> > +++ b/drivers/gpu/drm/drm_gpuvm.c
> > @@ -70,6 +70,18 @@
> >   * &drm_gem_object, such as the &drm_gem_object containing the root
> > page table,
> >   * but it can also be a 'dummy' object, which can be allocated with
> >   * drm_gpuvm_root_object_alloc().
> > + *
> > + * In order to connect a struct drm_gpuva its backing
> > &drm_gem_object each
> NIT: Same as previous patch regarding kerneldoc references

I was intentionally using generic references here to make the documentation
more readable while still keeping references to be able to look up the
structure's fields.

> 
> > + * &drm_gem_object maintains a list of &drm_gpuvm_bo structures, and
> > each
> > + * &drm_gpuvm_bo contains a list of &&drm_gpuva structures.
> > + *
> > + * A &drm_gpuvm_bo is an abstraction that represents a combination
> > of a
> > + * &drm_gpuvm and a &drm_gem_object. Every such combination should
> > be unique.
> > + * This is ensured by the API through drm_gpuvm_bo_obtain() and
> > + * drm_gpuvm_bo_obtain_prealloc() which first look into the
> > corresponding
> > + * &drm_gem_object list of &drm_gpuvm_bos for an existing instance
> > of this
> > + * particular combination. If not existent a new instance is created
> > and linked
> > + * to the &drm_gem_object.
> >   */
> >  
> >  /**
> > @@ -395,21 +407,28 @@
> >  /**
> >   * DOC: Locking
> >   *
> > - * Generally, the GPU VA manager does not take care of locking
> > itself, it is
> > - * the drivers responsibility to take care about locking. Drivers
> > might want to
> > - * protect the following operations: inserting, removing and
> > iterating
> > - * &drm_gpuva objects as well as generating all kinds of operations,
> > such as
> > - * split / merge or prefetch.
> > - *
> > - * The GPU VA manager also does not take care of the locking of the
> > backing
> > - * &drm_gem_object buffers GPU VA lists by itself; drivers are
> > responsible to
> > - * enforce mutual exclusion using either the GEMs dma_resv lock or
> > alternatively
> > - * a driver specific external lock. For the latter see also
> > - * drm_gem_gpuva_set_lock().
> > - *
> > - * However, the GPU VA manager contains lockdep checks to ensure
> > callers of its
> > - * API hold the corresponding lock whenever the &drm_gem_objects GPU
> > VA list is
> > - * accessed by functions such as drm_gpuva_link() or
> > drm_gpuva_unlink().
> > + * In terms of managing &drm_gpuva entries DRM GPUVM does not take
> > care of
> > + * locking itself, it is the drivers responsibility to take care
> > about locking.
> > + * Drivers might want to protect the following operations:
> > inserting, removing
> > + * and iterating &drm_gpuva objects as well as generating all kinds
> > of
> > + * operations, such as split / merge or prefetch.
> > + *
> > + * DRM GPUVM also does not take care of the locking of the backing
> > + * &drm_gem_object buffers GPU VA lists and &drm_gpuvm_bo
> > abstractions by
> > + * itself; drivers are responsible to enforce mutual exclusion using
> > either the
> > + * GEMs dma_resv lock or alternatively a driver specific external
> > lock. For the
> > + * latter see also drm_gem_gpuva_set_lock().
> > + *
> > + * However, DRM GPUVM contains lockdep checks to ensure callers of
> > its API hold
> > + * the

Re: [PATCH v11 1/7] drm: bridge: Cadence: Creat mhdp helper driver

2023-10-17 Thread Alexander Stein
Hi Sandor,

thanks for the update.

One small typo in the commit message: 'Creat' -> 'Create'

Am Dienstag, 17. Oktober 2023, 09:03:57 CEST schrieb Sandor Yu:
> MHDP8546 mailbox access functions will be share to other mhdp driver
> and Cadence HDP-TX HDMI/DP PHY drivers.
> Create a new mhdp helper driver and move all those functions into.
> 
> cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
> because it use the DPTX command ID DPTX_WRITE_REGISTER.
> 
> New cdns_mhdp_reg_write() is created with the general command ID
> GENERAL_REGISTER_WRITE.
> 
> rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
> use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
> same as the other mailbox access functions.
> 
> Signed-off-by: Sandor Yu 
> ---
> v10->v11:
> - rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
> use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
> same as the other mailbox access functions.
> - use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read()
> and remove them from EXPORT_SYMBOL_GPL().
> 
> v9->v10:
>  *use mhdp helper driver to replace macro functions,
>  move maibox access function and mhdp hdmi/dp common API
>  functions into the driver.
> 
>  drivers/gpu/drm/bridge/cadence/Kconfig|   4 +
>  drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
>  .../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 304 +
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 403 +++---
>  .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  44 +-
>  include/drm/bridge/cdns-mhdp-helper.h |  94 
>  6 files changed, 476 insertions(+), 374 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
>  create mode 100644 include/drm/bridge/cdns-mhdp-helper.h
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig index ec35215a20034..0b7b4626a7af0
> 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -20,6 +20,9 @@ config DRM_CDNS_DSI_J721E
> the routing of the DSS DPI signal to the Cadence DSI.
>  endif
> 
> +config CDNS_MHDP_HELPER
> + tristate
> +
>  config DRM_CDNS_MHDP8546
>   tristate "Cadence DPI/DP bridge"
>   select DRM_DISPLAY_DP_HELPER
> @@ -27,6 +30,7 @@ config DRM_CDNS_MHDP8546
>   select DRM_DISPLAY_HELPER
>   select DRM_KMS_HELPER
>   select DRM_PANEL_BRIDGE
> + select CDNS_MHDP_HELPER
>   depends on OF
>   help
> Support Cadence DPI to DP bridge. This is an internal
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile index
> c95fd5b81d137..087dc074820d7 100644
> --- a/drivers/gpu/drm/bridge/cadence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  cdns-dsi-y := cdns-dsi-core.o
>  cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
> +obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
>  obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
>  cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
>  cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c new file mode 100644
> index 0..8cabd79ad9663
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
> @@ -0,0 +1,304 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 NXP Semiconductor, Inc.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +
> +/* Mailbox helper functions */
> +static int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base)
> +{
> + int ret, empty;
> +
> + WARN_ON(!mutex_is_locked(base->mbox_mutex));

Actually this should be moved to cdns_mhdp_mailbox_recv_header() and 
cdns_mhdp_mailbox_recv_data().

> + ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_EMPTY,
> +  empty, !empty, MAILBOX_RETRY_US,
> +  MAILBOX_TIMEOUT_US);
> + if (ret < 0)
> + return ret;
> +
> + return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
> +}
> +
> +static int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val)
> +{
> + int ret, full;
> +
> + WARN_ON(!mutex_is_locked(base->mbox_mutex));

I think this should be moved to cdns_mhdp_mailbox_send() as well.

> + ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
> +  full, !full, MAILBOX_RETRY_US,
> +  MAILBOX_TIMEOUT_US);
> + if (ret < 0)
> + return ret;
> +
> + writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
> +
> + return 0;
> +}

Nice, much better having these as static now.

> +int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
> +   u8 module_id

RE: [PATCH 5/9] drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc

2023-10-17 Thread Ying Liu
On Tuesday, October 17, 2023 2:15 AM, Heiko Stübner  wrote:
> Hi,

Hi,

>
> Am Montag, 17. Juli 2023, 08:18:27 CEST schrieb Liu Ying:
> > To get better accuration, use pixel clock rate to calculate lbcc instead of
> > lane_mbps since the pixel clock rate is in KHz while lane_mbps is in MHz.
> > Without this, distorted image can be seen on a HDMI monitor connected
> with
> > i.MX93 11x11 EVK through ADV7535 DSI to HDMI bridge in 1920x1080p@60
> video
> > mode.
> >
> > Signed-off-by: Liu Ying 
>
> looks like I'm late to the party, but this change breaks the display output
> my px30 minievb with the xinpeng xpp055c272 dsi display [0].

Hmm, I asked for a test, but anyway sorry for the breakage.

The panel driver sets MIPI_DSI_MODE_VIDEO_BURST.
And, it seems that rockchip dsi driver [1] only supports the burst mode,
because it takes 1/0.8 = 1.25 faster lane_mbps than "bandwidth of RGB".

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#n568

>
> Found this commit via git bisection and added a bit of debug output to
> compare the value differences for the old and new calculation:
>
> [   34.810722] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 810 * 480 * 1000
> / 8
> [   34.810749] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 810 * 64000 *
> 24 / (4 * 8)
> [   34.810756] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 4860, new
> lbcc: 3888
> [   34.810762] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 10 * 480 * 1000 /
> 8
> [   34.810767] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 10 * 64000 * 24
> / (4 * 8)
> [   34.810773] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 60, new lbcc:
> 48
> [   34.810778] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 40 * 480 * 1000 /
> 8
> [   34.810783] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 40 * 64000 * 24
> / (4 * 8)
> [   34.810789] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 240, new
> lbcc: 192

Old lbcc / new lbcc is always 1.25.

The new lbcc is for non-burst modes(sync pulse/sync event), IIUC.
At least, it works for i.MX93 with the RM67191 panel and ADV7535 in
sync pulse mode.

>
> With the new lbcc I get a blank dsi panel and just going back to the old
> calculation of lbcc restores the image.
>
> I don't have that much in-depth knowledge about dsi stuff and the original
> panel times also "just" came from the vendor tree, but I really would like
> to keep that display working ;-) .
>
> Do you have any idea which way to go to fix this?

Can you please test the below patch for your case?

8<-
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -774,13 +774,19 @@ static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct 
dw_mipi_dsi *dsi,
u32 frac, lbcc, minimum_lbcc;
int bpp;

-   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
-   if (bpp < 0) {
-   dev_err(dsi->dev, "failed to get bpp\n");
-   return 0;
-   }
+   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
+   /* lbcc based on lane_mbps */
+   lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
+   } else {
+   /* lbcc based on pixel clock */
+   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+   if (bpp < 0) {
+   dev_err(dsi->dev, "failed to get bpp\n");
+   return 0;
+   }

-   lbcc = div_u64((u64)hcomponent * mode->clock * bpp, dsi->lanes * 8);
+   lbcc = div_u64((u64)hcomponent * mode->clock * bpp, dsi->lanes 
* 8);
+   }

frac = lbcc % mode->clock;
lbcc = lbcc / mode->clock;
8<-

It kind of keeps the old lbcc for burst mode, except for the minimum lbcc check
I introduced.

It seems that meson supports non-burst modes only and stm supports both
non-burst modes and burst mode.  With the patch, I still worry about non-burst
modes for stm, assuming the minimum lbcc check is ok and everything works
for meson since I guess Neil has already tested the patch set on meson.

Should we go with the above patch?  If yes, I may send it out.

Regards,
Liu Ying

>
>
> Thanks
> Heiko
>
>
> [0]
> https://git.ker/
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2F
> tree%2Farch%2Farm64%2Fboot%2Fdts%2Frockchip%2Fpx30-
> evb.dts%23n138&data=05%7C01%7Cvictor.liu%40nxp.com%7C8f712ad41720
> 4ba7411808dbce73ce63%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C638330769044424464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=effPCbPOk3GGuO8mR%2FSlcjFJfDUEZmq082simvjkux0%3D&r
> eserved=0
> https://git.ker/
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fto

Re: [PATCH v7 4/6] drm: Refuse to async flip with atomic prop changes

2023-10-17 Thread Simon Ser
Reviewed-by: Simon Ser 


Re: [PATCH v7 15/16] dt-bindings: display: mediatek: split: add compatible for MT8195

2023-10-17 Thread AngeloGioacchino Del Regno

Il 16/10/23 18:21, Krzysztof Kozlowski ha scritto:

On 12/10/2023 10:40, Moudy Ho wrote:

Add compatible string and GCE property for MT8195 SPLIT, of
which is operated by MDP3.

Signed-off-by: Moudy Ho 
---


After feedback from Angelo:

Reviewed-by: Krzysztof Kozlowski 



Reviewed-by: AngeloGioacchino Del Regno 




Re: [PATCH v8 15/23] drm/mediatek: Manage component's clock with function pointers

2023-10-17 Thread 宋孝謙


Re: [PATCH drm-misc-next v6 3/6] drm/gpuvm: add an abstraction for a VM / BO combination

2023-10-17 Thread Thomas Hellström

Hi,

On 10/17/23 11:58, Danilo Krummrich wrote:

On Fri, Oct 13, 2023 at 02:30:29PM +0200, Thomas Hellström wrote:

On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:

Add an abstraction layer between the drm_gpuva mappings of a
particular
drm_gem_object and this GEM object itself. The abstraction represents
a
combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
holds
a list of drm_gpuvm_bo structures (the structure representing this
abstraction), while each drm_gpuvm_bo contains list of mappings of
this
GEM object.

This has multiple advantages:

1) We can use the drm_gpuvm_bo structure to attach it to various
lists
    of the drm_gpuvm. This is useful for tracking external and evicted
    objects per VM, which is introduced in subsequent patches.

2) Finding mappings of a certain drm_gem_object mapped in a certain
    drm_gpuvm becomes much cheaper.

3) Drivers can derive and extend the structure to easily represent
    driver specific states of a BO for a certain GPUVM.

The idea of this abstraction was taken from amdgpu, hence the credit
for
this idea goes to the developers of amdgpu.

Cc: Christian König 
Signed-off-by: Danilo Krummrich 
---
  drivers/gpu/drm/drm_gpuvm.c    | 332 +--
--
  drivers/gpu/drm/nouveau/nouveau_uvmm.c |  64 +++--
  include/drm/drm_gem.h  |  32 +--
  include/drm/drm_gpuvm.h    | 177 -
  4 files changed, 521 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c
b/drivers/gpu/drm/drm_gpuvm.c
index 6368dfdbe9dd..28282283ddaf 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -70,6 +70,18 @@
   * &drm_gem_object, such as the &drm_gem_object containing the root
page table,
   * but it can also be a 'dummy' object, which can be allocated with
   * drm_gpuvm_root_object_alloc().
+ *
+ * In order to connect a struct drm_gpuva its backing
&drm_gem_object each

NIT: Same as previous patch regarding kerneldoc references

I was intentionally using generic references here to make the documentation
more readable while still keeping references to be able to look up the
structure's fields.


+ * &drm_gem_object maintains a list of &drm_gpuvm_bo structures, and
each
+ * &drm_gpuvm_bo contains a list of &&drm_gpuva structures.
+ *
+ * A &drm_gpuvm_bo is an abstraction that represents a combination
of a
+ * &drm_gpuvm and a &drm_gem_object. Every such combination should
be unique.
+ * This is ensured by the API through drm_gpuvm_bo_obtain() and
+ * drm_gpuvm_bo_obtain_prealloc() which first look into the
corresponding
+ * &drm_gem_object list of &drm_gpuvm_bos for an existing instance
of this
+ * particular combination. If not existent a new instance is created
and linked
+ * to the &drm_gem_object.
   */
  
  /**

@@ -395,21 +407,28 @@
  /**
   * DOC: Locking
   *
- * Generally, the GPU VA manager does not take care of locking
itself, it is
- * the drivers responsibility to take care about locking. Drivers
might want to
- * protect the following operations: inserting, removing and
iterating
- * &drm_gpuva objects as well as generating all kinds of operations,
such as
- * split / merge or prefetch.
- *
- * The GPU VA manager also does not take care of the locking of the
backing
- * &drm_gem_object buffers GPU VA lists by itself; drivers are
responsible to
- * enforce mutual exclusion using either the GEMs dma_resv lock or
alternatively
- * a driver specific external lock. For the latter see also
- * drm_gem_gpuva_set_lock().
- *
- * However, the GPU VA manager contains lockdep checks to ensure
callers of its
- * API hold the corresponding lock whenever the &drm_gem_objects GPU
VA list is
- * accessed by functions such as drm_gpuva_link() or
drm_gpuva_unlink().
+ * In terms of managing &drm_gpuva entries DRM GPUVM does not take
care of
+ * locking itself, it is the drivers responsibility to take care
about locking.
+ * Drivers might want to protect the following operations:
inserting, removing
+ * and iterating &drm_gpuva objects as well as generating all kinds
of
+ * operations, such as split / merge or prefetch.
+ *
+ * DRM GPUVM also does not take care of the locking of the backing
+ * &drm_gem_object buffers GPU VA lists and &drm_gpuvm_bo
abstractions by
+ * itself; drivers are responsible to enforce mutual exclusion using
either the
+ * GEMs dma_resv lock or alternatively a driver specific external
lock. For the
+ * latter see also drm_gem_gpuva_set_lock().
+ *
+ * However, DRM GPUVM contains lockdep checks to ensure callers of
its API hold
+ * the corresponding lock whenever the &drm_gem_objects GPU VA list
is accessed
+ * by functions such as drm_gpuva_link() or drm_gpuva_unlink(), but
also
+ * drm_gpuvm_bo_obtain() and drm_gpuvm_bo_put().
+ *
+ * The latter is required since on creation and destruction of a
&drm_gpuvm_bo
+ * the &drm_gpuvm_bo is attached / removed from the &drm_gem_objects
gpuva list.
+ * Subsequent calls to drm_gpuvm_bo_obtain() for the 

Re: [PATCH v8 22/23] drm/mediatek: Power on devices in OVL adaptor when atomic enable

2023-10-17 Thread 宋孝謙


Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Karolina Stolarek

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:

Add tests for building blocks of the TTM subsystem, such as ttm_resource,
ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of each
struct. Testing of ttm_buffer_object also includes locking and unlocking
the object for validation, with special scenarios such as an interrupted
wait or deadlock.

Some of the test cases check the bulk move mechanism and how it interacts
with pinned buffers. This is to be seen if we want to add dedicated 
testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager

for now. Resources that don't use system memory will be indirectly tested
via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all the 
patches here?


All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an empty 
one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are tested but
 not widely exported. Thanks to this change, TTM tests can be built
 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
 are built as one. This allows building the tests as a module, even
 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c



Re: [PATCH v8 18/23] drm/mediatek: Add Padding to OVL adaptor

2023-10-17 Thread 宋孝謙


Re: [Intel-gfx] [PATCH] drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3

2023-10-17 Thread Mika Kuoppala
Vinay Belgaumkar  writes:

> This bit does not cause an explicit L3 flush. We already use
> PIPE_CONTROL_DC_FLUSH_ENABLE for that purpose.
>
> Cc: Nirmoy Das 
> Cc: Mikka Kuoppala 
s/kk/k

> Signed-off-by: Vinay Belgaumkar 
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index ba4c2422b340..abbc02f3e66e 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -247,6 +247,7 @@ static int mtl_dummy_pipe_control(struct i915_request *rq)
>  int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
>  {
>   struct intel_engine_cs *engine = rq->engine;
> + struct intel_gt *gt = rq->engine->gt;
>  
>   /*
>* On Aux CCS platforms the invalidation of the Aux
> @@ -278,7 +279,8 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>* deals with Protected Memory which is not needed for
>* AUX CCS invalidation and lead to unwanted side effects.
>*/
> - if (mode & EMIT_FLUSH)
> + if ((mode & EMIT_FLUSH) &&
> + !(IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71
>   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;

Yes its best to apply for MTL first.

Acked-by: Mika Kuoppala   
>   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
> @@ -812,12 +814,14 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
> *rq, u32 *cs)
>   u32 flags = (PIPE_CONTROL_CS_STALL |
>PIPE_CONTROL_TLB_INVALIDATE |
>PIPE_CONTROL_TILE_CACHE_FLUSH |
> -  PIPE_CONTROL_FLUSH_L3 |
>PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
>PIPE_CONTROL_DEPTH_CACHE_FLUSH |
>PIPE_CONTROL_DC_FLUSH_ENABLE |
>PIPE_CONTROL_FLUSH_ENABLE);
>  
> + if (!(IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71
> + flags |= PIPE_CONTROL_FLUSH_L3;
> +
>   /* Wa_14016712196 */
>   if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) || 
> IS_DG2(i915))
>   /* dummy PIPE_CONTROL + depth flush */
> -- 
> 2.38.1


Re: [PATCH v8 17/23] drm/mediatek: Support MT8188 Padding in display driver

2023-10-17 Thread 宋孝謙


Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Somalapuram, Amaranath



On 10/17/2023 4:35 PM, Karolina Stolarek wrote:

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:
Add tests for building blocks of the TTM subsystem, such as 
ttm_resource,

ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of each
struct. Testing of ttm_buffer_object also includes locking and 
unlocking
the object for validation, with special scenarios such as an 
interrupted

wait or deadlock.

Some of the test cases check the bulk move mechanism and how it 
interacts
with pinned buffers. This is to be seen if we want to add dedicated 
testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager
for now. Resources that don't use system memory will be indirectly 
tested

via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all the 
patches here?



Yes, I have tested all the 4 patches together.

Regards,
S.Amarnath

All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an 
empty one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are 
tested but

 not widely exported. Thanks to this change, TTM tests can be built
 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
 are built as one. This allows building the tests as a module, even
 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 
++

  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c



Re: [PATCH v8 15/23] drm/mediatek: Manage component's clock with function pointers

2023-10-17 Thread AngeloGioacchino Del Regno

Il 17/10/23 12:50, Shawn Sung (宋孝謙) ha scritto:

Hi Angelo,

On Tue, 2023-10-17 at 11:47 +0200, AngeloGioacchino Del Regno wrote:

Il 16/10/23 12:40, Hsiao Chien Sung ha scritto:

By registering component related functions to the pointers,
we can easily manage them within a for-loop and simplify the
logic of clock control significantly.

Reviewed-by: CK Hu 
Signed-off-by: Hsiao Chien Sung 
---
   .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   | 111 +++
---
   1 file changed, 44 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index 60e5dfe9ef0d..fffef2a4f919 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -53,6 +53,7 @@ struct ovl_adaptor_comp_match {
enum mtk_ovl_adaptor_comp_type type;
enum mtk_ddp_comp_id comp_id;
int alias_id;
+   const struct mtk_ddp_comp_funcs *funcs;
   };
   
   struct mtk_disp_ovl_adaptor {

@@ -67,20 +68,35 @@ static const char * const
private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
   };
   
+static const struct mtk_ddp_comp_funcs _ethdr = {


Sorry I just noticed that; can you please remove the leading "_" from
all
of those?

_ethdr -> ethdr or mtk_ethdr
_merge -> merge or mtk_merge
_rdma  -> rdma  or mtk_rdma

Thanks,
Angelo



Sure. Will do in the next version.
The reason I didn't use mtk_* is simply because of the column width
will exceed 100 characaters.



Okay that would not be good, I guess that just `ethdr`, `merge`, `rdma` will
be fine then.

Cheers,
Angelo


Thanks,
Shawn






Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Christian König




Am 17.10.23 um 13:22 schrieb Somalapuram, Amaranath:


On 10/17/2023 4:35 PM, Karolina Stolarek wrote:

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:
Add tests for building blocks of the TTM subsystem, such as 
ttm_resource,

ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of 
each
struct. Testing of ttm_buffer_object also includes locking and 
unlocking
the object for validation, with special scenarios such as an 
interrupted

wait or deadlock.

Some of the test cases check the bulk move mechanism and how it 
interacts
with pinned buffers. This is to be seen if we want to add dedicated 
testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager
for now. Resources that don't use system memory will be indirectly 
tested

via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all the 
patches here?



Yes, I have tested all the 4 patches together.


No time for an in deep review, but I'm going to pick this up and push it 
to drm-misc-next.


Thanks,
Christian.



Regards,
S.Amarnath

All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an 
empty one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are 
tested but
 not widely exported. Thanks to this change, TTM tests can be 
built

 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
 are built as one. This allows building the tests as a module, 
even

 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 
++

  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c





Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Karolina Stolarek

On 17.10.2023 13:57, Christian König wrote:



Am 17.10.23 um 13:22 schrieb Somalapuram, Amaranath:


On 10/17/2023 4:35 PM, Karolina Stolarek wrote:

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:
Add tests for building blocks of the TTM subsystem, such as 
ttm_resource,

ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of 
each
struct. Testing of ttm_buffer_object also includes locking and 
unlocking
the object for validation, with special scenarios such as an 
interrupted

wait or deadlock.

Some of the test cases check the bulk move mechanism and how it 
interacts
with pinned buffers. This is to be seen if we want to add dedicated 
testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager
for now. Resources that don't use system memory will be indirectly 
tested

via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all the 
patches here?



Yes, I have tested all the 4 patches together.


No time for an in deep review, but I'm going to pick this up and push it 
to drm-misc-next.


Oh! Could you at least take a look at ttm_bo_reserve_deadlock and/or 
interrupted subtests? I'm not 100% sure if my solution is right.


Many thanks,
Karolina



Thanks,
Christian.



Regards,
S.Amarnath

All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an 
empty one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are 
tested but
 not widely exported. Thanks to this change, TTM tests can be 
built

 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
 are built as one. This allows building the tests as a module, 
even

 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 
++

  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c





Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Christian König

Am 17.10.23 um 14:06 schrieb Karolina Stolarek:

On 17.10.2023 13:57, Christian König wrote:



Am 17.10.23 um 13:22 schrieb Somalapuram, Amaranath:


On 10/17/2023 4:35 PM, Karolina Stolarek wrote:

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:
Add tests for building blocks of the TTM subsystem, such as 
ttm_resource,
ttm_resource_manager, ttm_tt and ttm_buffer_object. This series 
covers
basic functions such as initialization, allocation and clean-up 
of each
struct. Testing of ttm_buffer_object also includes locking and 
unlocking
the object for validation, with special scenarios such as an 
interrupted

wait or deadlock.

Some of the test cases check the bulk move mechanism and how it 
interacts
with pinned buffers. This is to be seen if we want to add 
dedicated testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager
for now. Resources that don't use system memory will be 
indirectly tested

via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable 
CONFIG_KUNIT, and

then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all 
the patches here?



Yes, I have tested all the 4 patches together.


No time for an in deep review, but I'm going to pick this up and push 
it to drm-misc-next.


Oh! Could you at least take a look at ttm_bo_reserve_deadlock and/or 
interrupted subtests? I'm not 100% sure if my solution is right.


Than this will have to wait till next week when I have some more time.

Christian.



Many thanks,
Karolina



Thanks,
Christian.



Regards,
S.Amarnath

All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an 
empty one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are 
tested but
 not widely exported. Thanks to this change, TTM tests can be 
built

 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM 
module
 are built as one. This allows building the tests as a 
module, even

 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 
++

  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c







Re: [PATCH v6 6/6] drm/doc: Define KMS atomic state set

2023-10-17 Thread Ville Syrjälä
On Mon, Oct 16, 2023 at 10:00:51PM +, Simon Ser wrote:
> On Monday, October 16th, 2023 at 17:10, Ville Syrjälä 
>  wrote:
> 
> > On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
> > 
> > > On Mon, 16 Oct 2023 15:42:16 +0200
> > > André Almeida andrealm...@igalia.com wrote:
> > > 
> > > > Hi Pekka,
> > > > 
> > > > On 10/16/23 14:18, Pekka Paalanen wrote:
> > > > 
> > > > > On Mon, 16 Oct 2023 12:52:32 +0200
> > > > > André Almeida andrealm...@igalia.com wrote:
> > > > > 
> > > > > > Hi Michel,
> > > > > > 
> > > > > > On 8/17/23 12:37, Michel Dänzer wrote:
> > > > > > 
> > > > > > > On 8/15/23 20:57, André Almeida wrote:
> > > > > > > 
> > > > > > > > From: Pekka Paalanen pekka.paala...@collabora.com
> > > > > > > > 
> > > > > > > > Specify how the atomic state is maintained between userspace and
> > > > > > > > kernel, plus the special case for async flips.
> > > > > > > > 
> > > > > > > > Signed-off-by: Pekka Paalanen pekka.paala...@collabora.com
> > > > > > > > Signed-off-by: André Almeida andrealm...@igalia.com
> > > > > > > > [...]
> > > > > > > 
> > > > > > > > +An atomic commit with the flag DRM_MODE_PAGE_FLIP_ASYNC is 
> > > > > > > > allowed to
> > > > > > > > +effectively change only the FB_ID property on any planes. 
> > > > > > > > No-operation changes
> > > > > > > > +are ignored as always. [...]
> > > > > > > > During the hackfest in Brno, it was mentioned that a commit 
> > > > > > > > which re-sets the same FB_ID could actually have an effect with 
> > > > > > > > VRR: It could trigger scanout of the next frame before vertical 
> > > > > > > > blank has reached its maximum duration. Some kind of mechanism 
> > > > > > > > is required for this in order to allow user space to perform 
> > > > > > > > low frame rate compensation.
> > > > > > 
> > > > > > Xaver tested this hypothesis in a flipping the same fb in a VRR 
> > > > > > monitor
> > > > > > and it worked as expected, so this shouldn't be a concern.
> > > > > > Right, so it must have some effect. It cannot be simply ignored 
> > > > > > like in
> > > > > > the proposed doc wording. Do we special-case re-setting the same 
> > > > > > FB_ID
> > > > > > as "not a no-op" or "not ignored" or some other way?
> > > > > > There's an effect in the refresh rate, the image won't change but it
> > > > > > will report that a flip had happened asynchronously so the reported
> > > > > > framerate will be increased. Maybe an additional wording could be 
> > > > > > like:
> > > > 
> > > > Flipping to the same FB_ID will result in a immediate flip as if it was
> > > > changing to a different one, with no effect on the image but effecting
> > > > the reported frame rate.
> > > 
> > > Re-setting FB_ID to its current value is a special case regardless of
> > > PAGE_FLIP_ASYNC, is it not?
> > 
> > No. The rule has so far been that all side effects are observed
> > even if you flip to the same fb. And that is one of my annoyances
> > with this proposal. The rules will now be different for async flips
> > vs. everything else.
> 
> Well with the patches the async page-flip case is exactly the same as
> the non-async page-flip case. In both cases, if a FB_ID is included in
> an atomic commit then the side effects are triggered even if the property
> value didn't change. The rules are the same for everything.

I see it only checking if FB_ID changes or not. If it doesn't
change then the implication is that the side effects will in
fact be skipped as not all planes may even support async flips.

-- 
Ville Syrjälä
Intel


Re: [PATCH 5/9] drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc

2023-10-17 Thread Heiko Stübner
Hi,

Am Dienstag, 17. Oktober 2023, 12:15:11 CEST schrieb Ying Liu:
> On Tuesday, October 17, 2023 2:15 AM, Heiko Stübner  wrote:
> > Am Montag, 17. Juli 2023, 08:18:27 CEST schrieb Liu Ying:
> > > To get better accuration, use pixel clock rate to calculate lbcc instead 
> > > of
> > > lane_mbps since the pixel clock rate is in KHz while lane_mbps is in MHz.
> > > Without this, distorted image can be seen on a HDMI monitor connected
> > with
> > > i.MX93 11x11 EVK through ADV7535 DSI to HDMI bridge in 1920x1080p@60
> > video
> > > mode.
> > >
> > > Signed-off-by: Liu Ying 
> >
> > looks like I'm late to the party, but this change breaks the display output
> > my px30 minievb with the xinpeng xpp055c272 dsi display [0].
> 
> Hmm, I asked for a test, but anyway sorry for the breakage.

I'm often way behind with looking at drm-related changes, sorry about that.

So thanks a lot for taking the time to look into the problem.


> The panel driver sets MIPI_DSI_MODE_VIDEO_BURST.
> And, it seems that rockchip dsi driver [1] only supports the burst mode,
> because it takes 1/0.8 = 1.25 faster lane_mbps than "bandwidth of RGB".
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c#n568
> 
> >
> > Found this commit via git bisection and added a bit of debug output to
> > compare the value differences for the old and new calculation:
> >
> > [   34.810722] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 810 * 480 * 1000
> > / 8
> > [   34.810749] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 810 * 64000 *
> > 24 / (4 * 8)
> > [   34.810756] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 4860, new
> > lbcc: 3888
> > [   34.810762] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 10 * 480 * 1000 /
> > 8
> > [   34.810767] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 10 * 64000 * 24
> > / (4 * 8)
> > [   34.810773] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 60, new lbcc:
> > 48
> > [   34.810778] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 40 * 480 * 1000 /
> > 8
> > [   34.810783] dw_mipi_dsi_get_hcomponent_lbcc: new lbcc: 40 * 64000 * 24
> > / (4 * 8)
> > [   34.810789] dw_mipi_dsi_get_hcomponent_lbcc: old lbcc: 240, new
> > lbcc: 192
> 
> Old lbcc / new lbcc is always 1.25.
> 
> The new lbcc is for non-burst modes(sync pulse/sync event), IIUC.
> At least, it works for i.MX93 with the RM67191 panel and ADV7535 in
> sync pulse mode.
> 
> >
> > With the new lbcc I get a blank dsi panel and just going back to the old
> > calculation of lbcc restores the image.
> >
> > I don't have that much in-depth knowledge about dsi stuff and the original
> > panel times also "just" came from the vendor tree, but I really would like
> > to keep that display working ;-) .
> >
> > Do you have any idea which way to go to fix this?
> 
> Can you please test the below patch for your case?

The patch below does fix the display on the device. After applying it
I do get a working display again.


> 8<-
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -774,13 +774,19 @@ static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct 
> dw_mipi_dsi *dsi,
> u32 frac, lbcc, minimum_lbcc;
> int bpp;
> 
> -   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> -   if (bpp < 0) {
> -   dev_err(dsi->dev, "failed to get bpp\n");
> -   return 0;
> -   }
> +   if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> +   /* lbcc based on lane_mbps */
> +   lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
> +   } else {
> +   /* lbcc based on pixel clock */
> +   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +   if (bpp < 0) {
> +   dev_err(dsi->dev, "failed to get bpp\n");
> +   return 0;
> +   }
> 
> -   lbcc = div_u64((u64)hcomponent * mode->clock * bpp, dsi->lanes * 8);
> +   lbcc = div_u64((u64)hcomponent * mode->clock * bpp, 
> dsi->lanes * 8);
> +   }
> 
> frac = lbcc % mode->clock;
> lbcc = lbcc / mode->clock;
> 8<-
> 
> It kind of keeps the old lbcc for burst mode, except for the minimum lbcc 
> check
> I introduced.
> 
> It seems that meson supports non-burst modes only and stm supports both
> non-burst modes and burst mode.  With the patch, I still worry about non-burst
> modes for stm, assuming the minimum lbcc check is ok and everything works
> for meson since I guess Neil has already tested the patch set on meson.
> 
> Should we go with the above patch?  If yes, I may send it out.

In my mind, definitly :-) .

But maybe Neil as the other reviewer also wants to c

[PATCH] Revert "accel/ivpu: Use cached buffers for FW loading"

2023-10-17 Thread Stanislaw Gruszka
This reverts commit 645d694559cab36fe6a57c717efcfa27d9321396.

The commit cause issues with memory access from the device side.
Switch back to write-combined memory mappings until the issues
will be properly addressed.

Add extra wmb() needed when boot_params->save_restore_ret_address() is
modified.

Reviewed-by: Karol Wachowski 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/accel/ivpu/ivpu_fw.c  | 9 -
 drivers/accel/ivpu/ivpu_gem.h | 5 -
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 0191cf8e5964..a277bbae78fc 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -220,8 +220,7 @@ static int ivpu_fw_mem_init(struct ivpu_device *vdev)
if (ret)
return ret;
 
-   fw->mem = ivpu_bo_alloc_internal(vdev, fw->runtime_addr, 
fw->runtime_size,
-DRM_IVPU_BO_CACHED | 
DRM_IVPU_BO_NOSNOOP);
+   fw->mem = ivpu_bo_alloc_internal(vdev, fw->runtime_addr, 
fw->runtime_size, DRM_IVPU_BO_WC);
if (!fw->mem) {
ivpu_err(vdev, "Failed to allocate firmware runtime memory\n");
return -ENOMEM;
@@ -331,7 +330,7 @@ int ivpu_fw_load(struct ivpu_device *vdev)
memset(start, 0, size);
}
 
-   clflush_cache_range(fw->mem->kvaddr, fw->mem->base.size);
+   wmb(); /* Flush WC buffers after writing fw->mem */
 
return 0;
 }
@@ -433,7 +432,7 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev, 
struct vpu_boot_params
if (!ivpu_fw_is_cold_boot(vdev)) {
boot_params->save_restore_ret_address = 0;
vdev->pm->is_warmboot = true;
-   clflush_cache_range(vdev->fw->mem->kvaddr, SZ_4K);
+   wmb(); /* Flush WC buffers after writing 
save_restore_ret_address */
return;
}
 
@@ -495,7 +494,7 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev, 
struct vpu_boot_params
boot_params->punit_telemetry_sram_size = 
ivpu_hw_reg_telemetry_size_get(vdev);
boot_params->vpu_telemetry_enable = 
ivpu_hw_reg_telemetry_enable_get(vdev);
 
-   clflush_cache_range(vdev->fw->mem->kvaddr, SZ_4K);
+   wmb(); /* Flush WC buffers after writing bootparams */
 
ivpu_fw_boot_params_print(vdev, boot_params);
 }
diff --git a/drivers/accel/ivpu/ivpu_gem.h b/drivers/accel/ivpu/ivpu_gem.h
index f4130586ff1b..6b0ceda5f253 100644
--- a/drivers/accel/ivpu/ivpu_gem.h
+++ b/drivers/accel/ivpu/ivpu_gem.h
@@ -8,8 +8,6 @@
 #include 
 #include 
 
-#define DRM_IVPU_BO_NOSNOOP   0x1000
-
 struct dma_buf;
 struct ivpu_bo_ops;
 struct ivpu_file_priv;
@@ -85,9 +83,6 @@ static inline u32 ivpu_bo_cache_mode(struct ivpu_bo *bo)
 
 static inline bool ivpu_bo_is_snooped(struct ivpu_bo *bo)
 {
-   if (bo->flags & DRM_IVPU_BO_NOSNOOP)
-   return false;
-
return ivpu_bo_cache_mode(bo) == DRM_IVPU_BO_CACHED;
 }
 
-- 
2.25.1



Re: [PATCH 00/12] drm/ast: Align VGA register names with documentation

2023-10-17 Thread Jocelyn Falempe

On 17/10/2023 10:31, Thomas Zimmermann wrote:

Update the names of ast's VGA registers to follow the documentation
and put all constants into a separate header. The update make the
driver source code more grep-able. No functional changes.


I think the previous name is more meaningful than the one from the 
documentation. But I agree it's better to match the documentation.


For the whole series:

Reviewed-by: Jocelyn Falempe 

--

Jocelyn




Thomas Zimmermann (12):
   drm/ast: Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W
   drm/ast: Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W
   drm/ast: Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER
   drm/ast: Rename AST_IO_SEQ_PORT to AST_IO_VGASRI
   drm/ast: Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR
   drm/ast: Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR
   drm/ast: Rename AST_IO_DAC_DATA to AST_IO_VGAPDR
   drm/ast: Rename AST_IO_GR_PORT to AST_IO_VGAGRI
   drm/ast: Rename AST_IO_CRTC_PORT to AST_IO_VGACRI
   drm/ast: Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R
   drm/ast: Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R
   drm/ast: Move register constants to ast_reg.h

  drivers/gpu/drm/ast/ast_dp.c|  70 +--
  drivers/gpu/drm/ast/ast_dp501.c |  38 +++---
  drivers/gpu/drm/ast/ast_drv.h   |  83 +
  drivers/gpu/drm/ast/ast_i2c.c   |  20 ++--
  drivers/gpu/drm/ast/ast_main.c  |  24 ++--
  drivers/gpu/drm/ast/ast_mm.c|   4 +-
  drivers/gpu/drm/ast/ast_mode.c  | 200 
  drivers/gpu/drm/ast/ast_post.c  |  26 ++---
  drivers/gpu/drm/ast/ast_reg.h   |  99 
  9 files changed, 292 insertions(+), 272 deletions(-)
  create mode 100644 drivers/gpu/drm/ast/ast_reg.h





Re: [PATCH v7 4/6] drm: Refuse to async flip with atomic prop changes

2023-10-17 Thread Simon Ser
After discussing with André it seems like we missed a plane type check
here. We need to make sure FB_ID changes are only allowed on primary
planes.


[PATCH] drm: Remove struct drm_flip_task from DRM interfaces

2023-10-17 Thread Thomas Zimmermann
Contain struct drm_flip_task and its helper functions
drm_flip_work_allocate_task() and drm_flip_work_queue_task() within
drm_flip_work.c There are no callers outside of the flip-work code.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_flip_work.c | 27 +++
 include/drm/drm_flip_work.h | 18 ++
 2 files changed, 9 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
index 060b753881a27..8c6090a90d564 100644
--- a/drivers/gpu/drm/drm_flip_work.c
+++ b/drivers/gpu/drm/drm_flip_work.c
@@ -27,14 +27,12 @@
 #include 
 #include 
 
-/**
- * drm_flip_work_allocate_task - allocate a flip-work task
- * @data: data associated to the task
- * @flags: allocator flags
- *
- * Allocate a drm_flip_task object and attach private data to it.
- */
-struct drm_flip_task *drm_flip_work_allocate_task(void *data, gfp_t flags)
+struct drm_flip_task {
+   struct list_head node;
+   void *data;
+};
+
+static struct drm_flip_task *drm_flip_work_allocate_task(void *data, gfp_t 
flags)
 {
struct drm_flip_task *task;
 
@@ -44,18 +42,8 @@ struct drm_flip_task *drm_flip_work_allocate_task(void 
*data, gfp_t flags)
 
return task;
 }
-EXPORT_SYMBOL(drm_flip_work_allocate_task);
 
-/**
- * drm_flip_work_queue_task - queue a specific task
- * @work: the flip-work
- * @task: the task to handle
- *
- * Queues task, that will later be run (passed back to drm_flip_func_t
- * func) on a work queue after drm_flip_work_commit() is called.
- */
-void drm_flip_work_queue_task(struct drm_flip_work *work,
- struct drm_flip_task *task)
+static void drm_flip_work_queue_task(struct drm_flip_work *work, struct 
drm_flip_task *task)
 {
unsigned long flags;
 
@@ -63,7 +51,6 @@ void drm_flip_work_queue_task(struct drm_flip_work *work,
list_add_tail(&task->node, &work->queued);
spin_unlock_irqrestore(&work->lock, flags);
 }
-EXPORT_SYMBOL(drm_flip_work_queue_task);
 
 /**
  * drm_flip_work_queue - queue work
diff --git a/include/drm/drm_flip_work.h b/include/drm/drm_flip_work.h
index 21c3d512d25c4..6be4ba6f35143 100644
--- a/include/drm/drm_flip_work.h
+++ b/include/drm/drm_flip_work.h
@@ -33,9 +33,8 @@
  *
  * Util to queue up work to run from work-queue context after flip/vblank.
  * Typically this can be used to defer unref of framebuffer's, cursor
- * bo's, etc until after vblank.  The APIs are all thread-safe.
- * Moreover, drm_flip_work_queue_task and drm_flip_work_queue can be called
- * in atomic context.
+ * bo's, etc until after vblank.  The APIs are all thread-safe. Moreover,
+ * drm_flip_work_queue can be called in atomic context.
  */
 
 struct drm_flip_work;
@@ -51,16 +50,6 @@ struct drm_flip_work;
  */
 typedef void (*drm_flip_func_t)(struct drm_flip_work *work, void *val);
 
-/**
- * struct drm_flip_task - flip work task
- * @node: list entry element
- * @data: data to pass to &drm_flip_work.func
- */
-struct drm_flip_task {
-   struct list_head node;
-   void *data;
-};
-
 /**
  * struct drm_flip_work - flip work queue
  * @name: debug name
@@ -79,9 +68,6 @@ struct drm_flip_work {
spinlock_t lock;
 };
 
-struct drm_flip_task *drm_flip_work_allocate_task(void *data, gfp_t flags);
-void drm_flip_work_queue_task(struct drm_flip_work *work,
- struct drm_flip_task *task);
 void drm_flip_work_queue(struct drm_flip_work *work, void *val);
 void drm_flip_work_commit(struct drm_flip_work *work,
struct workqueue_struct *wq);
-- 
2.42.0



Re: [PATCH] drm/msm/a6xx: add QMP dependency

2023-10-17 Thread Konrad Dybcio




On 10/16/23 22:04, Arnd Bergmann wrote:

From: Arnd Bergmann 

When QMP is in a loadable module, the A6xx GPU driver fails to link
as built-in:

x86_64-linux-ld: drivers/gpu/drm/msm/adreno/a6xx_gmu.o: in function 
`a6xx_gmu_resume':
a6xx_gmu.c:(.text+0xd62): undefined reference to `qmp_send'

Add the usual dependency that still allows compiling without QMP but
otherwise avoids the broken combination of options.

Fixes: 88a0997f2f949 ("drm/msm/a6xx: Send ACD state to QMP at GMU resume")
Signed-off-by: Arnd Bergmann 
---

Right, thanks!

Reviewed-by: Konrad Dybcio 

Konrad


Re: [PATCH v11 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

2023-10-17 Thread Alexander Stein
Hi Sandor,

thanks for the patch.

Am Dienstag, 17. Oktober 2023, 09:04:00 CEST schrieb Sandor Yu:
> Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
> used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> standards according embedded Firmware running in the uCPU.
> 
> For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
> SOC's ROM code. Bootload binary included respective specific firmware
> is required.
> 
> Driver will check display connector type and
> then load the corresponding driver.
> 
> Signed-off-by: Sandor Yu 
> Tested-by: Alexander Stein 
> ---
> v10->v11:
> - remove MODULE_ALIAS() from mhdp8501 driver.
> 
> v9->v10:
>  - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
>  - update for mhdp helper driver is introduced.
> Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
> Add struct cdns_mhdp_base base to struct cdns_mhdp8501_device.
> Init struct cdns_mhdp_base base when driver probe.
> 
>  drivers/gpu/drm/bridge/cadence/Kconfig|  16 +
>  drivers/gpu/drm/bridge/cadence/Makefile   |   2 +
>  .../drm/bridge/cadence/cdns-mhdp8501-core.c   | 315 
>  .../drm/bridge/cadence/cdns-mhdp8501-core.h   | 365 +
>  .../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 708 ++
>  .../drm/bridge/cadence/cdns-mhdp8501-hdmi.c   | 673 +
>  6 files changed, 2079 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
>  create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig index 0b7b4626a7af0..81685ab4e874a
> 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -50,3 +50,19 @@ config DRM_CDNS_MHDP8546_J721E
> initializes the J721E Display Port and sets up the
> clock and data muxes.
>  endif
> +
> +config DRM_CDNS_MHDP8501
> + tristate "Cadence MHDP8501 DP/HDMI bridge"
> + select DRM_KMS_HELPER
> + select DRM_PANEL_BRIDGE
> + select DRM_DISPLAY_DP_HELPER
> + select DRM_DISPLAY_HELPER
> + select CDNS_MHDP_HELPER
> + select DRM_CDNS_AUDIO
> + depends on OF
> + help
> +   Support Cadence MHDP8501 DisplayPort/HDMI bridge.
> +   Cadence MHDP8501 support one or more protocols,
> +   including DisplayPort and HDMI.
> +   To use the DP and HDMI drivers, their respective
> +   specific firmware is required.
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile index
> 087dc074820d7..02c1a9f3cf6fc 100644
> --- a/drivers/gpu/drm/bridge/cadence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -6,3 +6,5 @@ obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
>  obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
>  cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
>  cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> +obj-$(CONFIG_DRM_CDNS_MHDP8501) += cdns-mhdp8501.o
> +cdns-mhdp8501-y := cdns-mhdp8501-core.o cdns-mhdp8501-dp.o
> cdns-mhdp8501-hdmi.o diff --git
> a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c new file mode 100644
> index 0..23860a260e637
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
> @@ -0,0 +1,315 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cadence Display Port Interface (DP) driver
> + *
> + * Copyright (C) 2023 NXP Semiconductor, Inc.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cdns-mhdp8501-core.h"
> +
> +static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
> +{
> + u8 status;
> + int ret;
> +
> + mutex_lock(&mhdp->mbox_mutex);
> +
> + ret = cdns_mhdp_mailbox_send(&mhdp->base, MB_MODULE_ID_GENERAL,
> +  GENERAL_GET_HPD_STATE, 0, NULL);
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdns_mhdp_mailbox_recv_header(&mhdp->base, 
MB_MODULE_ID_GENERAL,
> + GENERAL_GET_HPD_STATE,
> + sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + ret = cdns_mhdp_mailbox_recv_data(&mhdp->base, &status, 
sizeof(status));
> + if (ret)
> + goto err_get_hpd;
> +
> + mutex_unlock(&mhdp->mbox_mutex);
> +
> + return status;
> +
> +err_get_hpd:
> + DRM_ERROR("read hpd  failed: %d\n", ret);

Use dev_err() instead, there is a device pointer available.

> + mutex_unlock(&mhdp->mbox_mutex);
> +
> + return ret;
> +}
> +
> +enum drm_connector_status cdns_mhdp8501_detect(struct cdns_mhdp850

Re: [PATCH v11 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ

2023-10-17 Thread Alexander Stein
Hi Sandor,

thanks for the patch.

Am Dienstag, 17. Oktober 2023, 09:04:02 CEST schrieb Sandor Yu:
> Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ
> 
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> DisplayPort PHY mode is configurated in the driver.
> 
> Signed-off-by: Sandor Yu 
> ---
> v9->v11:
>  *No change.
> 
>  drivers/phy/freescale/Kconfig |  10 +
>  drivers/phy/freescale/Makefile|   1 +
>  drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 720 ++
>  3 files changed, 731 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 853958fb2c063..c39709fd700ac 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE
> Enable this to add support for the PCIE PHY as found on
> i.MX8M family of SOCs.
> 
> +config PHY_FSL_IMX8MQ_DP
> + tristate "Freescale i.MX8MQ DP PHY support"
> + depends on OF && HAS_IOMEM
> + depends on COMMON_CLK
> + select GENERIC_PHY
> + select CDNS_MHDP_HELPER
> + help
> +   Enable this to support the Cadence HDPTX DP PHY driver
> +   on i.MX8MQ SOC.
> +
>  endif
> 
>  config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index cedb328bc4d28..47e5285209fa8 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)  += phy-fsl-imx8mq-dp.o
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
> b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c new file mode 100644
> index 0..5f0d7da16b422
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cadence HDP-TX Display Port Interface (DP) PHY driver
> + *
> + * Copyright (C) 2022, 2023 NXP Semiconductor, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADDR_PHY_AFE 0x8
> +
> +/* PHY registers */
> +#define CMN_SSM_BIAS_TMR 0x0022
> +#define CMN_PLLSM0_PLLEN_TMR 0x0029
> +#define CMN_PLLSM0_PLLPRE_TMR0x002a
> +#define CMN_PLLSM0_PLLVREF_TMR   0x002b
> +#define CMN_PLLSM0_PLLLOCK_TMR   0x002c
> +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f
> +#define CMN_PSM_CLK_CTRL 0x0061
> +#define CMN_PLL0_VCOCAL_START0x0081
> +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084
> +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085
> +#define CMN_PLL0_INTDIV  0x0094
> +#define CMN_PLL0_FRACDIV 0x0095
> +#define CMN_PLL0_HIGH_THR0x0096
> +#define CMN_PLL0_DSM_DIAG0x0097
> +#define CMN_PLL0_SS_CTRL20x0099
> +#define CMN_ICAL_INIT_TMR0x00c4
> +#define CMN_ICAL_ITER_TMR0x00c5
> +#define CMN_RXCAL_INIT_TMR   0x00d4
> +#define CMN_RXCAL_ITER_TMR   0x00d5
> +#define CMN_TXPUCAL_INIT_TMR 0x00e4
> +#define CMN_TXPUCAL_ITER_TMR 0x00e5
> +#define CMN_TXPDCAL_INIT_TMR 0x00f4
> +#define CMN_TXPDCAL_ITER_TMR 0x00f5
> +#define CMN_ICAL_ADJ_INIT_TMR0x0102
> +#define CMN_ICAL_ADJ_ITER_TMR0x0103
> +#define CMN_RX_ADJ_INIT_TMR  0x0106
> +#define CMN_RX_ADJ_ITER_TMR  0x0107
> +#define CMN_TXPU_ADJ_INIT_TMR0x010a
> +#define CMN_TXPU_ADJ_ITER_TMR0x010b
> +#define CMN_TXPD_ADJ_INIT_TMR0x010e
> +#define CMN_TXPD_ADJ_ITER_TMR0x010f
> +#define CMN_DIAG_PLL0_FBH_OVRD   0x01c0
> +#define CMN_DIAG_PLL0_FBL_OVRD   0x01c1
> +#define CMN_DIAG_PLL0_OVRD   0x01c2
> +#define CMN_DIAG_PLL0_TEST_MODE  0x01c4
> +#define CMN_DIAG_PLL0_V2I_TUNE   0x01c5
> +#define CMN_DIAG_PLL0_CP_TUNE0x01c6
> +#define CMN_DIAG_PLL0_LF_PROG0x01c7
> +#define CMN_DIAG_PLL0_PTATIS_TUNE1   0x01c8
> +#define CMN_DIAG_PLL0_PTATIS_TUNE2   0x01c9
> +#define CMN_DIAG_HSCLK_SEL   0x01e0
> +#define CMN_DIAG_PER_CAL_ADJ 0x01ec
> +#define CMN_DIAG_CAL_CTRL0x01ed
> +#define 

Re: [PATCH v5 0/4] Improve test coverage of TTM

2023-10-17 Thread Karolina Stolarek

On 17.10.2023 14:10, Christian König wrote:

Am 17.10.23 um 14:06 schrieb Karolina Stolarek:

On 17.10.2023 13:57, Christian König wrote:



Am 17.10.23 um 13:22 schrieb Somalapuram, Amaranath:


On 10/17/2023 4:35 PM, Karolina Stolarek wrote:

Hi Amaranath,

On 16.10.2023 15:08, Somalapuram, Amaranath wrote:


On 10/16/2023 2:22 PM, Karolina Stolarek wrote:
Add tests for building blocks of the TTM subsystem, such as 
ttm_resource,
ttm_resource_manager, ttm_tt and ttm_buffer_object. This series 
covers
basic functions such as initialization, allocation and clean-up 
of each
struct. Testing of ttm_buffer_object also includes locking and 
unlocking
the object for validation, with special scenarios such as an 
interrupted

wait or deadlock.

Some of the test cases check the bulk move mechanism and how it 
interacts
with pinned buffers. This is to be seen if we want to add 
dedicated testing
for bulk move or not. The resource allocation subtests use 
ttm_sys_manager
for now. Resources that don't use system memory will be 
indirectly tested

via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


To build a kernel with TTM KUnit tests, first enable 
CONFIG_KUNIT, and

then CONFIG_DRM_TTM_KUNIT_TEST.
Tested [PATCH v4 0/4] Improve test coverage of TTM patches on AMD 
platform, looks good.


Many thanks for taking a look.

Do I understand correctly that your Tested-by would apply to all 
the patches here?



Yes, I have tested all the 4 patches together.


No time for an in deep review, but I'm going to pick this up and push 
it to drm-misc-next.


Oh! Could you at least take a look at ttm_bo_reserve_deadlock and/or 
interrupted subtests? I'm not 100% sure if my solution is right.


Than this will have to wait till next week when I have some more time.


That's fine, I think. I still have to tie up loose ends in my 
ttm_bo_validate testing (with no eviction cases), so this will keep me 
busy for a couple more days.


All the best,
Karolina



Christian.



Many thanks,
Karolina



Thanks,
Christian.



Regards,
S.Amarnath

All the best,
Karolina



Regards,
S.Amarnath

Many thanks,
Karolina

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to 
suggestions

 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an 
empty one


v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are 
tested but
 not widely exported. Thanks to this change, TTM tests can be 
built

 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes 
ttm_pool_pre_populated()


v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM 
module
 are built as one. This allows building the tests as a 
module, even

 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (4):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

  drivers/gpu/drm/ttm/tests/Makefile    |   3 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 
++

  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  51 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 +
  drivers/gpu/drm/ttm/ttm_resource.c    |   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  9 files changed, 1313 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c







Re: [PATCH v11 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ

2023-10-17 Thread Alexander Stein
Hi Sandor,

thanks for the patch.

Am Dienstag, 17. Oktober 2023, 09:04:03 CEST schrieb Sandor Yu:
> Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ.
> 
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> HDMI PHY mode is configurated in the driver.
> 
> Signed-off-by: Sandor Yu 
> Tested-by: Alexander Stein 
> ---
> v9->v11:
>  *No change.
> 
>  drivers/phy/freescale/Kconfig   |  10 +
>  drivers/phy/freescale/Makefile  |   1 +
>  drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 961 
>  3 files changed, 972 insertions(+)
>  create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index c39709fd700ac..14f47b7cc77ab 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP
> Enable this to support the Cadence HDPTX DP PHY driver
> on i.MX8MQ SOC.
> 
> +config PHY_FSL_IMX8MQ_HDMI
> + tristate "Freescale i.MX8MQ HDMI PHY support"
> + depends on OF && HAS_IOMEM
> + depends on COMMON_CLK
> + select GENERIC_PHY
> + select CDNS_MHDP_HELPER
> + help
> +   Enable this to support the Cadence HDPTX HDMI PHY driver
> +   on i.MX8MQ SOC.
> +
>  endif
> 
>  config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index 47e5285209fa8..1380ac31c2ead 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)  += phy-fsl-imx8mq-dp.o
> +obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI)+= phy-fsl-imx8mq-hdmi.o
>  obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
> b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c new file mode 100644
> index 0..9722b5e1803c7
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c
> @@ -0,0 +1,961 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver
> + *
> + * Copyright (C) 2022,2023 NXP Semiconductor, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ADDR_PHY_AFE 0x8
> +
> +/* PHY registers */
> +#define CMN_SSM_BIAS_TMR 0x0022
> +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f
> +#define CMN_PSM_CLK_CTRL 0x0061
> +#define CMN_CDIAG_REFCLK_CTRL0x0062
> +#define CMN_PLL0_VCOCAL_START0x0081
> +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084
> +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085
> +#define CMN_TXPUCAL_CTRL 0x00e0
> +#define CMN_TXPDCAL_CTRL 0x00f0
> +#define CMN_TXPU_ADJ_CTRL0x0108
> +#define CMN_TXPD_ADJ_CTRL0x010c
> +#define CMN_DIAG_PLL0_FBH_OVRD   0x01c0
> +#define CMN_DIAG_PLL0_FBL_OVRD   0x01c1
> +#define CMN_DIAG_PLL0_OVRD   0x01c2
> +#define CMN_DIAG_PLL0_TEST_MODE  0x01c4
> +#define CMN_DIAG_PLL0_V2I_TUNE   0x01c5
> +#define CMN_DIAG_PLL0_CP_TUNE0x01c6
> +#define CMN_DIAG_PLL0_LF_PROG0x01c7
> +#define CMN_DIAG_PLL0_PTATIS_TUNE1   0x01c8
> +#define CMN_DIAG_PLL0_PTATIS_TUNE2   0x01c9
> +#define CMN_DIAG_PLL0_INCLK_CTRL 0x01ca
> +#define CMN_DIAG_PLL0_PXL_DIVH   0x01cb
> +#define CMN_DIAG_PLL0_PXL_DIVL   0x01cc
> +#define CMN_DIAG_HSCLK_SEL   0x01e0
> +#define XCVR_PSM_RCTRL   0x4001
> +#define TX_TXCC_CAL_SCLR_MULT_0  0x4047
> +#define TX_TXCC_CPOST_MULT_00_0  0x404c
> +#define XCVR_DIAG_PLLDRC_CTRL0x40e0
> +#define XCVR_DIAG_PLLDRC_CTRL0x40e0
> +#define XCVR_DIAG_HSCLK_SEL  0x40e1
> +#define XCVR_DIAG_BIDI_CTRL  0x40e8
> +#define TX_PSC_A00x4100
> +#define TX_PSC_A10x4101
> +#define TX_PSC_A20x4102
> +#define TX_PSC_A30x4103
> +#define TX_DIAG_TX_CTRL  0x41e0
> +#define TX_DIAG_TX_DRV   0x41e1
> +#define TX_DIAG_BGREF_PREDRV_DELAY   0x41e7
> +#define TX_DIAG_ACYA_0   0x41ff
> +#define TX_DIAG_ACYA_1   0x43ff
> +#define TX_DIAG_ACYA_2   0x45ff
> +#define 

Re: [PATCH drm-misc-next v6 1/6] drm/gpuvm: add common dma-resv per struct drm_gpuvm

2023-10-17 Thread Danilo Krummrich

On 10/13/23 15:00, Thomas Hellström wrote:

On Fri, 2023-10-13 at 13:51 +0200, Danilo Krummrich wrote:

On 10/13/23 13:38, Thomas Hellström wrote:

On Mon, 2023-10-09 at 01:32 +0200, Danilo Krummrich wrote:

Provide a common dma-resv for GEM objects not being used outside
of
this
GPU-VM. This is used in a subsequent patch to generalize dma-
resv,
external and evicted object handling and GEM validation.

Signed-off-by: Danilo Krummrich 
---
   drivers/gpu/drm/drm_gpuvm.c    | 56
+-
   drivers/gpu/drm/nouveau/nouveau_uvmm.c | 13 +-
   include/drm/drm_gpuvm.h    | 35 +++-
   3 files changed, 99 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c
b/drivers/gpu/drm/drm_gpuvm.c
index 02ecb45a2544..ebda9d594165 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -61,6 +61,15 @@
    * contained within struct drm_gpuva already. Hence, for
inserting
&drm_gpuva
    * entries from within dma-fence signalling critical sections
it is
enough to
    * pre-allocate the &drm_gpuva structures.
+ *
+ * &drm_gem_objects which are private to a single VM can share a
common
+ * &dma_resv in order to improve locking efficiency (e.g. with
&drm_exec).
+ * For this purpose drivers must pass a &drm_gem_object to
drm_gpuvm_init(), in
+ * the following called 'root object', which serves as the
container


Nit: Perhaps resv object altough it might typically be the root
page-
table object, that doesn't have any meaning to drm_gpuvm, which
uses it
solely as a container for the resv?


With "root" I didn't want to refer to the object representing the
root
page-table object, but being *the* object every other (internal)
object
needs to keep a reference to.


OK, yes but the reason they need a reference is because of the shared
resv, so IMO resv_object is a good fit. (I later noticed there's even
the function name drm_gpuvm_resv_obj()). And it will probably get
confused with the driver's "root" page table object, but up to you.


Yeah, maybe 'resv object' is better, gonna change it.




  Maybe I should be more explicit here and say
that drivers need to make sure every internal object requires a
reference
to take a reference to this root object.




of the
+ * GPUVM's shared &dma_resv. This root object can be a driver
specific
+ * &drm_gem_object, such as the &drm_gem_object containing the
root
page table,
+ * but it can also be a 'dummy' object, which can be allocated
with
+ * drm_gpuvm_root_object_alloc().
    */
   
   /**

@@ -652,9 +661,47 @@ drm_gpuvm_range_valid(struct drm_gpuvm
*gpuvm,
     !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
   }
   
+static void

+drm_gpuvm_gem_object_free(struct drm_gem_object *obj)
+{
+   drm_gem_object_release(obj);
+   kfree(obj);
+}
+
+static const struct drm_gem_object_funcs drm_gpuvm_object_funcs
= {
+   .free = drm_gpuvm_gem_object_free,
+};
+
+/**
+ * drm_gpuvm_root_object_alloc() - allocate a dummy
&drm_gem_object
+ * @drm: the drivers &drm_device
+ *
+ * Allocates a dummy &drm_gem_object which can be passed to
drm_gpuvm_init() in
+ * order to serve as root GEM object providing the &drm_resv
shared
across
+ * &drm_gem_objects local to a single GPUVM.
+ *
+ * Returns: the &drm_gem_object on success, NULL on failure
+ */
+struct drm_gem_object *
+drm_gpuvm_root_object_alloc(struct drm_device *drm)
+{
+   struct drm_gem_object *obj;
+
+   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+   if (!obj)
+   return NULL;
+
+   obj->funcs = &drm_gpuvm_object_funcs;
+   drm_gem_private_object_init(drm, obj, 0);
+
+   return obj;
+}
+EXPORT_SYMBOL_GPL(drm_gpuvm_root_object_alloc);
+
   /**
    * drm_gpuvm_init() - initialize a &drm_gpuvm
    * @gpuvm: pointer to the &drm_gpuvm to initialize
+ * @r_obj: the root &drm_gem_object providing the GPUVM's common
&dma_resv
    * @name: the name of the GPU VA space
    * @start_offset: the start offset of the GPU VA space
    * @range: the size of the GPU VA space
@@ -668,7 +715,7 @@ drm_gpuvm_range_valid(struct drm_gpuvm
*gpuvm,
    * &name is expected to be managed by the surrounding driver
structures.
    */
   void
-drm_gpuvm_init(struct drm_gpuvm *gpuvm,
+drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_gem_object
*r_obj,
     const char *name,
     u64 start_offset, u64 range,
     u64 reserve_offset, u64 reserve_range,
@@ -683,6 +730,9 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm,
   
  gpuvm->name = name ? name : "unknown";

  gpuvm->ops = ops;
+   gpuvm->r_obj = r_obj;
+
+   drm_gem_object_get(r_obj);
   
  memset(&gpuvm->kernel_alloc_node, 0, sizeof(struct

drm_gpuva));
   
@@ -713,7 +763,9 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm)

  __drm_gpuva_remove(&gpuvm->kernel_alloc_node);
   
  WARN(!RB_EMPTY_ROOT(&gpuvm->rb.tree.rb_root),

-    "GPUVA tree is not empty, potentially leaking
memory.");
+  

Re: [PATCH 1/2] drm/amdgpu: Unset context priority is now invalid

2023-10-17 Thread Alex Deucher
On Tue, Oct 17, 2023 at 12:52 AM Luben Tuikov  wrote:
>
> A context priority value of AMD_CTX_PRIORITY_UNSET is now invalid--instead of
> carrying it around and passing it to the Direct Rendering Manager--and it
> becomes AMD_CTX_PRIORITY_NORMAL in amdgpu_ctx_ioctl(), the gateway to context
> creation.
>
> Cc: Alex Deucher 
> Cc: Christian König 
> Signed-off-by: Luben Tuikov 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 0dc9c655c4fbdb..092962b93064fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -47,7 +47,6 @@ const unsigned int 
> amdgpu_ctx_num_entities[AMDGPU_HW_IP_NUM] = {
>  bool amdgpu_ctx_priority_is_valid(int32_t ctx_prio)
>  {
> switch (ctx_prio) {
> -   case AMDGPU_CTX_PRIORITY_UNSET:
> case AMDGPU_CTX_PRIORITY_VERY_LOW:
> case AMDGPU_CTX_PRIORITY_LOW:
> case AMDGPU_CTX_PRIORITY_NORMAL:
> @@ -55,6 +54,7 @@ bool amdgpu_ctx_priority_is_valid(int32_t ctx_prio)
> case AMDGPU_CTX_PRIORITY_VERY_HIGH:
> return true;
> default:
> +   case AMDGPU_CTX_PRIORITY_UNSET:
> return false;

I  don't recall if any userspace uses this, but this would break
userspace if it does.

Alex

> }
>  }
>
> base-commit: dc9b2e683bcba017588b9aaad80f442ad004a48f
> --
> 2.42.0
>


Re: [PATCH v7 0/6] drm: Add support for atomic async page-flip

2023-10-17 Thread Helen Koike




On 17/10/2023 06:28, André Almeida wrote:

Hi,

This work from me and Simon adds support for DRM_MODE_PAGE_FLIP_ASYNC through
the atomic API. This feature is already available via the legacy API. The use
case is to be able to present a new frame immediately (or as soon as
possible), even if after missing a vblank. This might result in tearing, but
it's useful when a high framerate is desired, such as for gaming.

Differently from earlier versions, this one refuses to flip if any prop changes
for async flips. The idea is that the fast path of immediate page flips doesn't
play well with modeset changes, so only the fb_id can be changed.
Thanks,
André

- User-space patch: https://github.com/Plagman/gamescope/pull/595
- IGT tests: 
https://gitlab.freedesktop.org/andrealmeid/igt-gpu-tools/-/tree/atomic_async_page_flip

Changes from v6:
- Dropped the exception to allow MODE_ID changes (Simon)
- Clarify what happens when flipping with the same FB_ID (Pekka)

v6: 
https://lore.kernel.org/dri-devel/20230815185710.159779-1-andrealm...@igalia.com/

Changes from v5:
- Add note in the docs that not every redundant attribute will result in no-op,
   some might cause oversynchronization issues.

v5: 
https://lore.kernel.org/dri-devel/20230707224059.305474-1-andrealm...@igalia.com/

Changes from v4:
  - Documentation rewrote by Pekka Paalanen

v4: 
https://lore.kernel.org/dri-devel/20230701020917.143394-1-andrealm...@igalia.com/

Changes from v3:
  - Add new patch to reject prop changes
  - Add a documentation clarifying the KMS atomic state set

v3: 
https://lore.kernel.org/dri-devel/20220929184307.258331-1-cont...@emersion.fr/

André Almeida (1):
   drm: Refuse to async flip with atomic prop changes

Pekka Paalanen (1):
   drm/doc: Define KMS atomic state set

Simon Ser (4):
   drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
   drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP
   drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
   amd/display: indicate support for atomic async page-flips on DC

  Documentation/gpu/drm-uapi.rst| 47 
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  1 +
  drivers/gpu/drm/drm_atomic_uapi.c | 75 +--
  drivers/gpu/drm/drm_crtc_internal.h   |  2 +-
  drivers/gpu/drm/drm_ioctl.c   |  5 ++
  drivers/gpu/drm/drm_mode_object.c |  2 +-
  .../drm/i915/display/intel_display_driver.c   |  1 +
  drivers/gpu/drm/nouveau/nouveau_display.c |  1 +
  include/drm/drm_mode_config.h | 11 +++
  include/uapi/drm/drm.h| 10 ++-
  include/uapi/drm/drm_mode.h   |  9 +++
  11 files changed, 155 insertions(+), 9 deletions(-)



Hello o/

Maybe it is not related (since there are a few years I don't work on 
this) but this reminds me of 
https://yhbt.net/lore/all/20190412125827.5877-1-helen.ko...@collabora.com/T/


(just sharing for the sake of communication flow)

Regards,
Helen


Re: [PATCH 1/2] drm/amdgpu: Unset context priority is now invalid

2023-10-17 Thread Luben Tuikov
On 2023-10-17 09:22, Alex Deucher wrote:
> On Tue, Oct 17, 2023 at 12:52 AM Luben Tuikov  wrote:
>>
>> A context priority value of AMD_CTX_PRIORITY_UNSET is now invalid--instead of
>> carrying it around and passing it to the Direct Rendering Manager--and it
>> becomes AMD_CTX_PRIORITY_NORMAL in amdgpu_ctx_ioctl(), the gateway to context
>> creation.
>>
>> Cc: Alex Deucher 
>> Cc: Christian König 
>> Signed-off-by: Luben Tuikov 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
>> index 0dc9c655c4fbdb..092962b93064fc 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
>> @@ -47,7 +47,6 @@ const unsigned int 
>> amdgpu_ctx_num_entities[AMDGPU_HW_IP_NUM] = {
>>  bool amdgpu_ctx_priority_is_valid(int32_t ctx_prio)
>>  {
>> switch (ctx_prio) {
>> -   case AMDGPU_CTX_PRIORITY_UNSET:
>> case AMDGPU_CTX_PRIORITY_VERY_LOW:
>> case AMDGPU_CTX_PRIORITY_LOW:
>> case AMDGPU_CTX_PRIORITY_NORMAL:
>> @@ -55,6 +54,7 @@ bool amdgpu_ctx_priority_is_valid(int32_t ctx_prio)
>> case AMDGPU_CTX_PRIORITY_VERY_HIGH:
>> return true;
>> default:
>> +   case AMDGPU_CTX_PRIORITY_UNSET:
>> return false;
> 
> I  don't recall if any userspace uses this, but this would break
> userspace if it does.

This is shielded from user space in the following manner,
1) amdgpu_ctx_priority_is_valid() is called from amdgpu_ctx_ioctl() and
   if amdgpu_ctx_priority_is_valid() returns false, we set the priority to 
NORMAL.
   See the 2nd patch.
2) It is also called from amdgpu_ctx_priority_permit(), which is called
   from amdgpu_ctx_init() which is called from amdgpu_ctx_alloc() which
   is called from amdgpu_ctx_ioctl(), _after_ the call described above,
   and thus priority is now NORMAL.

Plus I'm typing this on a running system with 6.6.0 + those two patches.

User space can send us down UNSET, but we set it to NORMAL.

Can I get an R-B?

> 
> Alex
> 
>> }
>>  }
>>
>> base-commit: dc9b2e683bcba017588b9aaad80f442ad004a48f
>> --
>> 2.42.0
>>

-- 
Regards,
Luben



Re: [Intel-gfx] [PATCH] drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3

2023-10-17 Thread Andi Shyti
Hi Vinay,

> > > This bit does not cause an explicit L3 flush. We already use
> > At all? Or only on newer hardware? And as a genuine spec change or as a
> > bug / workaround?
> > 
> > If the hardware has re-purposed the bit then it is probably worth at
> > least adding a comment to the bit definition to say that it is only
> > valid up to IP version 12.70.
> At this point, this is a bug on MTL since this bit is not related to L3
> flushes as per spec. Regarding older platforms, still checking the reason
> why this was added (i.e if it fixed something and will regress if removed).
> If not, we can extend the change for others as well in a separate patch. On
> older platforms, this bit seems to cause an implicit flush at best.
> > 
> > > PIPE_CONTROL_DC_FLUSH_ENABLE for that purpose.
> > > 
> > > Cc: Nirmoy Das 
> > > Cc: Mikka Kuoppala 
> > > Signed-off-by: Vinay Belgaumkar 
> > > ---
> > >   drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8 ++--
> > >   1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > > index ba4c2422b340..abbc02f3e66e 100644
> > > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > > @@ -247,6 +247,7 @@ static int mtl_dummy_pipe_control(struct
> > > i915_request *rq)
> > >   int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
> > >   {
> > >   struct intel_engine_cs *engine = rq->engine;
> > > +    struct intel_gt *gt = rq->engine->gt;
> > >     /*
> > >    * On Aux CCS platforms the invalidation of the Aux
> > > @@ -278,7 +279,8 @@ int gen12_emit_flush_rcs(struct i915_request
> > > *rq, u32 mode)
> > >    * deals with Protected Memory which is not needed for
> > >    * AUX CCS invalidation and lead to unwanted side effects.
> > >    */
> > > -    if (mode & EMIT_FLUSH)
> > > +    if ((mode & EMIT_FLUSH) &&
> > > +    !(IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71
> > Why stop at 12.71? Is the meaning only changed for 12.70 and the
> > old/correct version will be restored in later hardware?
> 
> Was trying to keep this limited to MTL for now until the above statements
> are verified.

I'm not fully conviced here... this is not what the hardware spec
says. Am I reading the specs wrong?

Is there any ongoing discussion with the hardware developers?

Andi


[PATCH v6 2/7] drm/sched: Convert drm scheduler to use a work queue rather than kthread

2023-10-17 Thread Matthew Brost
In Xe, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
seems a bit odd but let us explain the reasoning below.

1. In Xe the submission order from multiple drm_sched_entity is not
guaranteed to be the same completion even if targeting the same hardware
engine. This is because in Xe we have a firmware scheduler, the GuC,
which allowed to reorder, timeslice, and preempt submissions. If a using
shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
apart as the TDR expects submission order == completion order. Using a
dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.

2. In Xe submissions are done via programming a ring buffer (circular
buffer), a drm_gpu_scheduler provides a limit on number of jobs, if the
limit of number jobs is set to RING_SIZE / MAX_SIZE_PER_JOB we get flow
control on the ring for free.

A problem with this design is currently a drm_gpu_scheduler uses a
kthread for submission / job cleanup. This doesn't scale if a large
number of drm_gpu_scheduler are used. To work around the scaling issue,
use a worker rather than kthread for submission / job cleanup.

v2:
  - (Rob Clark) Fix msm build
  - Pass in run work queue
v3:
  - (Boris) don't have loop in worker
v4:
  - (Tvrtko) break out submit ready, stop, start helpers into own patch
v5:
  - (Boris) default to ordered work queue
v6:
  - (Luben / checkpatch) fix alignment in msm_ringbuffer.c
  - (Luben) s/drm_sched_submit_queue/drm_sched_wqueue_enqueue
  - (Luben) Update comment for drm_sched_wqueue_enqueue
  - (Luben) Positive check for submit_wq in drm_sched_init
  - (Luben) s/alloc_submit_wq/own_submit_wq

Signed-off-by: Matthew Brost 
Reviewed-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   2 +-
 drivers/gpu/drm/etnaviv/etnaviv_sched.c|   2 +-
 drivers/gpu/drm/lima/lima_sched.c  |   2 +-
 drivers/gpu/drm/msm/msm_ringbuffer.c   |   7 +-
 drivers/gpu/drm/nouveau/nouveau_sched.c|   2 +-
 drivers/gpu/drm/panfrost/panfrost_job.c|   2 +-
 drivers/gpu/drm/scheduler/sched_main.c | 118 ++---
 drivers/gpu/drm/v3d/v3d_sched.c|  10 +-
 include/drm/gpu_scheduler.h|  14 ++-
 9 files changed, 82 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b1aafe815f28..b54c4d771104 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2279,7 +2279,7 @@ static int amdgpu_device_init_schedulers(struct 
amdgpu_device *adev)
break;
}
 
-   r = drm_sched_init(&ring->sched, &amdgpu_sched_ops,
+   r = drm_sched_init(&ring->sched, &amdgpu_sched_ops, NULL,
   ring->num_hw_submission, 0,
   timeout, adev->reset_domain->wq,
   ring->sched_score, ring->name,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 345fec6cb1a4..618a804ddc34 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -134,7 +134,7 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
 {
int ret;
 
-   ret = drm_sched_init(&gpu->sched, &etnaviv_sched_ops,
+   ret = drm_sched_init(&gpu->sched, &etnaviv_sched_ops, NULL,
 etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
 msecs_to_jiffies(500), NULL, NULL,
 dev_name(gpu->dev), gpu->dev);
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index ffd91a5ee299..8d858aed0e56 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -488,7 +488,7 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe, 
const char *name)
 
INIT_WORK(&pipe->recover_work, lima_sched_recover_work);
 
-   return drm_sched_init(&pipe->base, &lima_sched_ops, 1,
+   return drm_sched_init(&pipe->base, &lima_sched_ops, NULL, 1,
  lima_job_hang_limit,
  msecs_to_jiffies(timeout), NULL,
  NULL, name, pipe->ldev->dev);
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 40c0bc35a44c..1097f8e93d6b 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -94,9 +94,10 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu 
*gpu, int id,
 /* currently managing hangcheck ourselves: */
sched_timeout = MAX_SCHEDULE_TIMEOUT;
 
-   ret = drm_sched_init(&ring->sched, &msm_sched_ops,
-   num_hw_submissions, 0, sched_timeout,
-   NULL, NULL, to_msm_bo(ring->bo)->name, gpu->dev->dev);
+   ret = d

[PATCH v6 0/7] DRM scheduler changes for Xe

2023-10-17 Thread Matthew Brost
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first.

This a continuation of a RFC [3] with all comments addressed, ready for
a full review, and hopefully in state which can merged in the near
future. More details of this series can found in the cover letter of the
RFC [3].

These changes have been tested with the Xe driver. Based on drm-tip branch.

A follow up series will be posted to address some of dakr requets for
kernel doc changes.

v2:
 - Break run job, free job, and process message in own work items
 - This might break other drivers as run job and free job now can run in
   parallel, can fix up if needed

v3:
 - Include missing patch 'drm/sched: Add drm_sched_submit_* helpers'
 - Fix issue with setting timestamp to early
 - Don't dequeue jobs for single entity after calling entity fini
 - Flush pending jobs on entity fini
 - Add documentation for entity teardown
 - Add Matthew Brost to maintainers of DRM scheduler

v4:
 - Drop message interface
 - Drop 'Flush pending jobs on entity fini'
 - Drop 'Add documentation for entity teardown'
 - Address all feedback

v5:
 - Address Luben's feedback
 - Drop starting TDR after calling run_job()
 - Drop adding Matthew Brost to maintainers of DRM scheduler

v6:
 - Address Luben's feedback
 - Include base commit

Matt

[1] https://gitlab.freedesktop.org/drm/xe/kernel
[2] https://patchwork.freedesktop.org/series/112188/
[3] https://patchwork.freedesktop.org/series/116055/


Matthew Brost (7):
  drm/sched: Add drm_sched_wqueue_* helpers
  drm/sched: Convert drm scheduler to use a work queue rather than
kthread
  drm/sched: Move schedule policy to scheduler
  drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy
  drm/sched: Split free_job into own work item
  drm/sched: Add drm_sched_start_timeout_unlocked helper
  drm/sched: Add a helper to queue TDR immediately

 .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   |  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  15 +-
 drivers/gpu/drm/etnaviv/etnaviv_sched.c   |   5 +-
 drivers/gpu/drm/lima/lima_sched.c |   5 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c|   6 +-
 drivers/gpu/drm/msm/msm_ringbuffer.c  |   7 +-
 drivers/gpu/drm/nouveau/nouveau_sched.c   |   5 +-
 drivers/gpu/drm/panfrost/panfrost_job.c   |   5 +-
 drivers/gpu/drm/scheduler/sched_entity.c  |  85 ++-
 drivers/gpu/drm/scheduler/sched_fence.c   |   2 +-
 drivers/gpu/drm/scheduler/sched_main.c| 507 --
 drivers/gpu/drm/v3d/v3d_sched.c   |  25 +-
 include/drm/gpu_scheduler.h   |  48 +-
 14 files changed, 498 insertions(+), 234 deletions(-)


base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe
-- 
2.34.1



[PATCH v6 1/7] drm/sched: Add drm_sched_wqueue_* helpers

2023-10-17 Thread Matthew Brost
Add scheduler wqueue ready, stop, and start helpers to hide the
implementation details of the scheduler from the drivers.

v2:
  - s/sched_wqueue/sched_wqueue (Luben)
  - Remove the extra white line after the return-statement (Luben)
  - update drm_sched_wqueue_ready comment (Luben)

Cc: Luben Tuikov 
Signed-off-by: Matthew Brost 
Reviewed-by: Luben Tuikov 
---
 .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   | 15 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 12 +++---
 drivers/gpu/drm/msm/adreno/adreno_device.c|  6 ++-
 drivers/gpu/drm/scheduler/sched_main.c| 39 ++-
 include/drm/gpu_scheduler.h   |  3 ++
 6 files changed, 59 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
index 625db444df1c..10d56979fe3b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
@@ -290,7 +290,7 @@ static int suspend_resume_compute_scheduler(struct 
amdgpu_device *adev, bool sus
for (i = 0; i < adev->gfx.num_compute_rings; i++) {
struct amdgpu_ring *ring = &adev->gfx.compute_ring[i];
 
-   if (!(ring && ring->sched.thread))
+   if (!(ring && drm_sched_wqueue_ready(&ring->sched)))
continue;
 
/* stop secheduler and drain ring. */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index a4faea4fa0b5..a4c0bb358db7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1659,9 +1659,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file 
*m, void *unused)
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
 
-   if (!ring || !ring->sched.thread)
+   if (!ring || !drm_sched_wqueue_ready(&ring->sched))
continue;
-   kthread_park(ring->sched.thread);
+   drm_sched_wqueue_stop(&ring->sched);
}
 
seq_puts(m, "run ib test:\n");
@@ -1675,9 +1675,9 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file 
*m, void *unused)
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
 
-   if (!ring || !ring->sched.thread)
+   if (!ring || !drm_sched_wqueue_ready(&ring->sched))
continue;
-   kthread_unpark(ring->sched.thread);
+   drm_sched_wqueue_start(&ring->sched);
}
 
up_write(&adev->reset_domain->sem);
@@ -1897,7 +1897,8 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
 
ring = adev->rings[val];
 
-   if (!ring || !ring->funcs->preempt_ib || !ring->sched.thread)
+   if (!ring || !ring->funcs->preempt_ib ||
+   !drm_sched_wqueue_ready(&ring->sched))
return -EINVAL;
 
/* the last preemption failed */
@@ -1915,7 +1916,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
goto pro_end;
 
/* stop the scheduler */
-   kthread_park(ring->sched.thread);
+   drm_sched_wqueue_stop(&ring->sched);
 
/* preempt the IB */
r = amdgpu_ring_preempt_ib(ring);
@@ -1949,7 +1950,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
 
 failure:
/* restart the scheduler */
-   kthread_unpark(ring->sched.thread);
+   drm_sched_wqueue_start(&ring->sched);
 
up_read(&adev->reset_domain->sem);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2b8356699f23..b1aafe815f28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4588,7 +4588,7 @@ bool amdgpu_device_has_job_running(struct amdgpu_device 
*adev)
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
 
-   if (!ring || !ring->sched.thread)
+   if (!ring || !drm_sched_wqueue_ready(&ring->sched))
continue;
 
spin_lock(&ring->sched.job_list_lock);
@@ -4727,7 +4727,7 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device 
*adev,
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
 
-   if (!ring || !ring->sched.thread)
+   if (!ring || !drm_sched_wqueue_ready(&ring->sched))
continue;
 
/* Clear job fence from fence drv to avoid force_completion
@@ -5266,7 +5266,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = tmp_adev->rings[i];
 
-

[PATCH v6 3/7] drm/sched: Move schedule policy to scheduler

2023-10-17 Thread Matthew Brost
Rather than a global modparam for scheduling policy, move the scheduling
policy to scheduler so user can control each scheduler policy.

v2:
  - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
  - Only include policy in scheduler (Luben)
v3:
  - use a ternary operator as opposed to an if-control (Luben)
  - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
  - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
  - Update commit message (Boris)
  - Fix v3d build (CI)
  - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
  - Don't update modparam doc (Luben)
v4:
  - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)

Signed-off-by: Matthew Brost 
Reviewed-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_sched.c|  3 ++-
 drivers/gpu/drm/lima/lima_sched.c  |  3 ++-
 drivers/gpu/drm/msm/msm_ringbuffer.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_sched.c|  3 ++-
 drivers/gpu/drm/panfrost/panfrost_job.c|  3 ++-
 drivers/gpu/drm/scheduler/sched_entity.c   | 24 ++
 drivers/gpu/drm/scheduler/sched_main.c | 19 -
 drivers/gpu/drm/v3d/v3d_sched.c| 15 +-
 include/drm/gpu_scheduler.h| 20 --
 10 files changed, 68 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b54c4d771104..e4e6f91450a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2283,6 +2283,7 @@ static int amdgpu_device_init_schedulers(struct 
amdgpu_device *adev)
   ring->num_hw_submission, 0,
   timeout, adev->reset_domain->wq,
   ring->sched_score, ring->name,
+  DRM_SCHED_POLICY_UNSET,
   adev->dev);
if (r) {
DRM_ERROR("Failed to create scheduler on ring %s.\n",
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 618a804ddc34..15b0e2f1abe5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -137,7 +137,8 @@ int etnaviv_sched_init(struct etnaviv_gpu *gpu)
ret = drm_sched_init(&gpu->sched, &etnaviv_sched_ops, NULL,
 etnaviv_hw_jobs_limit, etnaviv_job_hang_limit,
 msecs_to_jiffies(500), NULL, NULL,
-dev_name(gpu->dev), gpu->dev);
+dev_name(gpu->dev), DRM_SCHED_POLICY_UNSET,
+gpu->dev);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 8d858aed0e56..50c2075228aa 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -491,7 +491,8 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe, 
const char *name)
return drm_sched_init(&pipe->base, &lima_sched_ops, NULL, 1,
  lima_job_hang_limit,
  msecs_to_jiffies(timeout), NULL,
- NULL, name, pipe->ldev->dev);
+ NULL, name, DRM_SCHED_POLICY_UNSET,
+ pipe->ldev->dev);
 }
 
 void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index 1097f8e93d6b..173ad2f17c50 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -97,7 +97,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu 
*gpu, int id,
ret = drm_sched_init(&ring->sched, &msm_sched_ops, NULL,
 num_hw_submissions, 0, sched_timeout,
 NULL, NULL, to_msm_bo(ring->bo)->name,
-gpu->dev->dev);
+DRM_SCHED_POLICY_UNSET, gpu->dev->dev);
if (ret) {
goto fail;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c 
b/drivers/gpu/drm/nouveau/nouveau_sched.c
index 4c959dec42b3..c4e09d2e77f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sched.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
@@ -437,7 +437,8 @@ int nouveau_sched_init(struct nouveau_drm *drm)
 
return drm_sched_init(sched, &nouveau_sched_ops, NULL,
  NOUVEAU_SCHED_HW_SUBMISSIONS, 0, job_hang_limit,
- NULL, NULL, "nouveau_sched", drm->dev->dev);
+ NULL, NULL, "nouveau_sched",
+ DRM_SCHED_POLICY_UNSET, drm->dev->dev);
 }
 
 void nouveau_sched_fini(struct nouveau_drm *drm)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_

[PATCH v6 4/7] drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy

2023-10-17 Thread Matthew Brost
DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
scheduler and entity. No priorities or run queue used in this mode.
Intended for devices with firmware schedulers.

v2:
  - Drop sched / rq union (Luben)
v3:
  - Don't pick entity if stopped in drm_sched_select_entity (Danilo)
v4:
  - Rework if statement in drm_sched_entity_init (Luben)
  - Update comment for drm_sched_entity_to_scheduler (Luben)
  - Reword a few things in DOC comment (Luben)
  - Do not check sched policy in for statement (Luben)
v5:
  - Fix extra blank lines (Luben / Checkpatch)

Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/scheduler/sched_entity.c | 69 +++
 drivers/gpu/drm/scheduler/sched_fence.c  |  2 +-
 drivers/gpu/drm/scheduler/sched_main.c   | 87 ++--
 include/drm/gpu_scheduler.h  |  8 +++
 4 files changed, 130 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index cf42e2265d64..940f63dd6965 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -83,6 +83,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
memset(entity, 0, sizeof(struct drm_sched_entity));
INIT_LIST_HEAD(&entity->list);
entity->rq = NULL;
+   entity->single_sched = NULL;
entity->guilty = guilty;
entity->num_sched_list = num_sched_list;
entity->priority = priority;
@@ -90,8 +91,17 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
RCU_INIT_POINTER(entity->last_scheduled, NULL);
RB_CLEAR_NODE(&entity->rb_tree_node);
 
-   if(num_sched_list)
-   entity->rq = &sched_list[0]->sched_rq[entity->priority];
+   if (num_sched_list) {
+   if (sched_list[0]->sched_policy !=
+   DRM_SCHED_POLICY_SINGLE_ENTITY) {
+   entity->rq = &sched_list[0]->sched_rq[entity->priority];
+   } else if (num_sched_list == 1 && 
!sched_list[0]->single_entity) {
+   sched_list[0]->single_entity = entity;
+   entity->single_sched = sched_list[0];
+   } else {
+   return -EINVAL;
+   }
+   }
 
init_completion(&entity->entity_idle);
 
@@ -124,7 +134,8 @@ void drm_sched_entity_modify_sched(struct drm_sched_entity 
*entity,
struct drm_gpu_scheduler **sched_list,
unsigned int num_sched_list)
 {
-   WARN_ON(!num_sched_list || !sched_list);
+   WARN_ON(!num_sched_list || !sched_list ||
+   !!entity->single_sched);
 
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
@@ -231,13 +242,15 @@ static void drm_sched_entity_kill(struct drm_sched_entity 
*entity)
 {
struct drm_sched_job *job;
struct dma_fence *prev;
+   bool single_entity = !!entity->single_sched;
 
-   if (!entity->rq)
+   if (!entity->rq && !single_entity)
return;
 
spin_lock(&entity->rq_lock);
entity->stopped = true;
-   drm_sched_rq_remove_entity(entity->rq, entity);
+   if (!single_entity)
+   drm_sched_rq_remove_entity(entity->rq, entity);
spin_unlock(&entity->rq_lock);
 
/* Make sure this entity is not used by the scheduler at the moment */
@@ -259,6 +272,20 @@ static void drm_sched_entity_kill(struct drm_sched_entity 
*entity)
dma_fence_put(prev);
 }
 
+/**
+ * drm_sched_entity_to_scheduler - Schedule entity to GPU scheduler
+ * @entity: scheduler entity
+ *
+ * Returns GPU scheduler for the entity
+ */
+struct drm_gpu_scheduler *
+drm_sched_entity_to_scheduler(struct drm_sched_entity *entity)
+{
+   bool single_entity = !!entity->single_sched;
+
+   return single_entity ? entity->single_sched : entity->rq->sched;
+}
+
 /**
  * drm_sched_entity_flush - Flush a context entity
  *
@@ -276,11 +303,12 @@ long drm_sched_entity_flush(struct drm_sched_entity 
*entity, long timeout)
struct drm_gpu_scheduler *sched;
struct task_struct *last_user;
long ret = timeout;
+   bool single_entity = !!entity->single_sched;
 
-   if (!entity->rq)
+   if (!entity->rq && !single_entity)
return 0;
 
-   sched = entity->rq->sched;
+   sched = drm_sched_entity_to_scheduler(entity);
/**
 * The client will not queue more IBs during this fini, consume existing
 * queued IBs or discard them on SIGKILL
@@ -373,7 +401,7 @@ static void drm_sched_entity_wakeup(struct dma_fence *f,
container_of(cb, struct drm_sched_entity, cb);
 
drm_sched_entity_clear_dep(f, cb);
-   drm_sched_wakeup_if_can_queue(entity->rq->sched);
+   drm_sched_wakeup_if_can_queue(drm_sched_entity_to_scheduler(entity));
 }
 
 /**
@@ -387,6 +415,8 @@ static void drm_sched_entity_wakeup(struc

[PATCH v6 6/7] drm/sched: Add drm_sched_start_timeout_unlocked helper

2023-10-17 Thread Matthew Brost
Also add a lockdep assert to drm_sched_start_timeout.

Signed-off-by: Matthew Brost 
Reviewed-by: Luben Tuikov 
---
 drivers/gpu/drm/scheduler/sched_main.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index b1b8d9f96da5..ff2cfad54342 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -427,11 +427,20 @@ static void drm_sched_job_done_cb(struct dma_fence *f, 
struct dma_fence_cb *cb)
  */
 static void drm_sched_start_timeout(struct drm_gpu_scheduler *sched)
 {
+   lockdep_assert_held(&sched->job_list_lock);
+
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_empty(&sched->pending_list))
queue_delayed_work(sched->timeout_wq, &sched->work_tdr, 
sched->timeout);
 }
 
+static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
+{
+   spin_lock(&sched->job_list_lock);
+   drm_sched_start_timeout(sched);
+   spin_unlock(&sched->job_list_lock);
+}
+
 /**
  * drm_sched_fault - immediately start timeout handler
  *
@@ -544,11 +553,8 @@ static void drm_sched_job_timedout(struct work_struct 
*work)
spin_unlock(&sched->job_list_lock);
}
 
-   if (status != DRM_GPU_SCHED_STAT_ENODEV) {
-   spin_lock(&sched->job_list_lock);
-   drm_sched_start_timeout(sched);
-   spin_unlock(&sched->job_list_lock);
-   }
+   if (status != DRM_GPU_SCHED_STAT_ENODEV)
+   drm_sched_start_timeout_unlocked(sched);
 }
 
 /**
@@ -674,11 +680,8 @@ void drm_sched_start(struct drm_gpu_scheduler *sched, bool 
full_recovery)
drm_sched_job_done(s_job, -ECANCELED);
}
 
-   if (full_recovery) {
-   spin_lock(&sched->job_list_lock);
-   drm_sched_start_timeout(sched);
-   spin_unlock(&sched->job_list_lock);
-   }
+   if (full_recovery)
+   drm_sched_start_timeout_unlocked(sched);
 
drm_sched_wqueue_start(sched);
 }
-- 
2.34.1



[PATCH v6 7/7] drm/sched: Add a helper to queue TDR immediately

2023-10-17 Thread Matthew Brost
Add a helper whereby a driver can invoke TDR immediately.

v2:
 - Drop timeout args, rename function, use mod delayed work (Luben)
v3:
 - s/XE/Xe (Luben)
 - present tense in commit message (Luben)
 - Adjust comment for drm_sched_tdr_queue_imm (Luben)
v4:
 - Adjust commit message (Luben)

Cc: Luben Tuikov 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/scheduler/sched_main.c | 18 +-
 include/drm/gpu_scheduler.h|  1 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index ff2cfad54342..563a4f0f6956 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -431,7 +431,7 @@ static void drm_sched_start_timeout(struct 
drm_gpu_scheduler *sched)
 
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_empty(&sched->pending_list))
-   queue_delayed_work(sched->timeout_wq, &sched->work_tdr, 
sched->timeout);
+   mod_delayed_work(sched->timeout_wq, &sched->work_tdr, 
sched->timeout);
 }
 
 static void drm_sched_start_timeout_unlocked(struct drm_gpu_scheduler *sched)
@@ -441,6 +441,22 @@ static void drm_sched_start_timeout_unlocked(struct 
drm_gpu_scheduler *sched)
spin_unlock(&sched->job_list_lock);
 }
 
+/**
+ * drm_sched_tdr_queue_imm: - immediately start job timeout handler
+ *
+ * @sched: scheduler for which the timeout handling should be started.
+ *
+ * Start timeout handling immediately for the named scheduler.
+ */
+void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched)
+{
+   spin_lock(&sched->job_list_lock);
+   sched->timeout = 0;
+   drm_sched_start_timeout(sched);
+   spin_unlock(&sched->job_list_lock);
+}
+EXPORT_SYMBOL(drm_sched_tdr_queue_imm);
+
 /**
  * drm_sched_fault - immediately start timeout handler
  *
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 625ffe040de3..998b32b8d212 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -568,6 +568,7 @@ void drm_sched_entity_modify_sched(struct drm_sched_entity 
*entity,
struct drm_gpu_scheduler **sched_list,
unsigned int num_sched_list);
 
+void drm_sched_tdr_queue_imm(struct drm_gpu_scheduler *sched);
 void drm_sched_job_cleanup(struct drm_sched_job *job);
 void drm_sched_wakeup_if_can_queue(struct drm_gpu_scheduler *sched);
 bool drm_sched_wqueue_ready(struct drm_gpu_scheduler *sched);
-- 
2.34.1



[PATCH v6 5/7] drm/sched: Split free_job into own work item

2023-10-17 Thread Matthew Brost
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.

v2:
   - Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
 timestamp in free_job() work item (Danilo)
v3:
  - Drop forward dec of drm_sched_select_entity (Boris)
  - Return in drm_sched_run_job_work if entity NULL (Boris)
v4:
  - Replace dequeue with peek and invert logic (Luben)
  - Wrap to 100 lines (Luben)
  - Update comments for *_queue / *_queue_if_ready functions (Luben)

Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/scheduler/sched_main.c | 287 +++--
 include/drm/gpu_scheduler.h|   8 +-
 2 files changed, 178 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 273e0fbc4eab..b1b8d9f96da5 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -213,11 +213,12 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
  * drm_sched_rq_select_entity_rr - Select an entity which could provide a job 
to run
  *
  * @rq: scheduler run queue to check.
+ * @peek: Just find, don't set to current.
  *
  * Try to find a ready entity, returns NULL if none found.
  */
 static struct drm_sched_entity *
-drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
+drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq, bool peek)
 {
struct drm_sched_entity *entity;
 
@@ -227,8 +228,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
if (entity) {
list_for_each_entry_continue(entity, &rq->entities, list) {
if (drm_sched_entity_is_ready(entity)) {
-   rq->current_entity = entity;
-   reinit_completion(&entity->entity_idle);
+   if (!peek) {
+   rq->current_entity = entity;
+   reinit_completion(&entity->entity_idle);
+   }
spin_unlock(&rq->lock);
return entity;
}
@@ -238,8 +241,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
list_for_each_entry(entity, &rq->entities, list) {
 
if (drm_sched_entity_is_ready(entity)) {
-   rq->current_entity = entity;
-   reinit_completion(&entity->entity_idle);
+   if (!peek) {
+   rq->current_entity = entity;
+   reinit_completion(&entity->entity_idle);
+   }
spin_unlock(&rq->lock);
return entity;
}
@@ -257,11 +262,12 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
  * drm_sched_rq_select_entity_fifo - Select an entity which provides a job to 
run
  *
  * @rq: scheduler run queue to check.
+ * @peek: Just find, don't set to current.
  *
  * Find oldest waiting ready entity, returns NULL if none found.
  */
 static struct drm_sched_entity *
-drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
+drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq, bool peek)
 {
struct rb_node *rb;
 
@@ -271,8 +277,10 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
 
entity = rb_entry(rb, struct drm_sched_entity, rb_tree_node);
if (drm_sched_entity_is_ready(entity)) {
-   rq->current_entity = entity;
-   reinit_completion(&entity->entity_idle);
+   if (!peek) {
+   rq->current_entity = entity;
+   reinit_completion(&entity->entity_idle);
+   }
break;
}
}
@@ -282,13 +290,98 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
 }
 
 /**
- * drm_sched_wqueue_enqueue - enqueue scheduler submission
+ * drm_sched_run_job_queue - enqueue run-job work
+ * @sched: scheduler instance
+ */
+static void drm_sched_run_job_queue(struct drm_gpu_scheduler *sched)
+{
+   if (!READ_ONCE(sched->pause_submit))
+   queue_work(sched->submit_wq, &sched->work_run_job);
+}
+
+/**
+ * drm_sched_can_queue -- Can we queue more to the hardware?
+ * @sched: scheduler instance
+ *
+ * Return true if we can push more jobs to the hw, otherwise false.
+ */
+static bool drm_sched_can_queue(struct drm_gpu_scheduler *sched)
+{
+   return atomic_read(&sched->hw_rq_count) <
+   sched->hw_submission_limit;
+}
+
+/**
+ * drm_sched_select_entity - Select next entity to process
+ *
+ * @sched: scheduler instance
+ * @peek: Just find, don't set to current.
+ *
+ * Returns the entity to process or NULL if none are found.
+ */
+static struct drm_sched_entity *
+drm_sched_select_entity(s

Re: [PATCH 2/7] drm/msm/adreno: Add ZAP firmware name to A635

2023-10-17 Thread Konrad Dybcio




On 10/17/23 09:33, Rob Clark wrote:

On Mon, Oct 16, 2023 at 1:12 PM Akhil P Oommen  wrote:


On Tue, Sep 26, 2023 at 08:24:37PM +0200, Konrad Dybcio wrote:


Some (many?) devices with A635 expect a ZAP shader to be loaded.

Set the file name to allow for that.

Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index fa527935ffd4..16527fe8584d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -454,6 +454,7 @@ static const struct adreno_info gpulist[] = {
   .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
   ADRENO_QUIRK_HAS_HW_APRIV,
   .init = a6xx_gpu_init,
+ .zapfw = "a660_zap.mbn",


sc7280 doesn't have a TZ and so no zap shader support. Can we handle
this using "firmware-name" property in your top level platform dt? Zap
firmwares are signed with different keys for each OEMs. So there is
cross-compatibility anyway.


I think this ends up working out because the version of sc7280 that
doesn't have TZ also doesn't have the associated mem-region/etc..

Yes


but
maybe we should deprecate the zapfw field as in practice it isn't
useful (ie. always overriden by firmware-name).

Also yes, we've discussed that on IRC once



Fwiw there are windows laptops with sc7180/sc7280 which do use zap fw.

Correct, e.g. the SC7180 Acer Aspire 1 that is supported upstream.

Konrad

Konrad


  1   2   >