Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

[Joonas Lahtinen]

+ Tvrtko and Chris for comments

Code seems to be added in:

commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin 
Date:   Tue Nov 21 18:18:50 2017 +

drm/i915/pmu: Add interrupt count metric

I think later in the thread there was a suggestion to replace this with
simple counter increment in IRQ handler.

Regards, Joonas

Quoting Thomas Gleixner (2020-12-06 18:38:44)
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> 
> > Now that kstat_irqs is exported, get rid of count_interrupts in
> > i915_pmu.c
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer 
> > *hrtimer)
> >   return HRTIMER_RESTART;
> >  }
> >  
> > -static u64 count_interrupts(struct drm_i915_private *i915)
> > -{
> > - /* open-coded kstat_irqs() */
> > - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> > - u64 sum = 0;
> > - int cpu;
> > -
> > - if (!desc || !desc->kstat_irqs)
> > - return 0;
> > -
> > - for_each_possible_cpu(cpu)
> > - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> > -
> > - return sum;
> > -}
> 
> May I ask why this has been merged in the first place?
> 
> Nothing in a driver has ever to fiddle with the internals of an irq
> descriptor. We have functions for properly accessing them. Just because
> C allows to fiddle with everything is not a justification. If the
> required function is not exported then adding the export with a proper
> explanation is not asked too much.
> 
> Also this lacks protection or at least a comment why this can be called
> safely and is not subject to a concurrent removal of the irq descriptor.
> The same problem exists when calling kstat_irqs(). It's even documented
> at the top of the function.
> 
> Thanks,
> 
> tglx
> 
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Guido Günther]

Hi,
On Tue, Dec 08, 2020 at 06:03:05PM +0800, Liu Ying wrote:
> On Tue, 2020-12-08 at 10:24 +0100, Guido Günther wrote:
> > Hi Liu,
> > some minor comments inline:
> > 
> > On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> > > i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> > > either a MIPI DSI display or a LVDS display.  The PHY mode is controlled
> > > by SCU firmware and the driver would call a SCU firmware function to
> > > configure the PHY mode.  The single LVDS PHY has 4 data lanes to support
> > > a LVDS display.  Also, with a master LVDS PHY and a slave LVDS PHY, they
> > > may work together to support a LVDS display with 8 data lanes(usually, 
> > > dual
> > > LVDS link display).  Note that this patch supports the LVDS PHY mode only
> > > for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> > > supported, so for now error would be returned from ->set_mode() if MIPI
> > > DPHY mode is passed over to it for the combo PHY.
> > > 
> > > Cc: Guido Günther 
> > > Cc: Robert Chiras 
> > > Cc: Kishon Vijay Abraham I 
> > > Cc: Vinod Koul 
> > > Cc: Shawn Guo 
> > > Cc: Sascha Hauer 
> > > Cc: Pengutronix Kernel Team 
> > > Cc: Fabio Estevam 
> > > Cc: NXP Linux Team 
> > > Signed-off-by: Liu Ying 
> > > ---
> > >  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 
> > > -
> > >  1 file changed, 255 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c 
> > > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > index a95572b..37084a9 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > @@ -4,17 +4,31 @@
> > >   * Copyright 2019 Purism SPC
> > >   */
> > >  
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +
> > > +/* Control and Status Registers(CSR) */
> > > +#define PHY_CTRL 0x00
> > > +#define  CCM_MASKGENMASK(7, 5)
> > > +#define  CCM(n)  FIELD_PREP(CCM_MASK, (n))
> > > +#define  CA_MASK GENMASK(4, 2)
> > > +#define  CA(n)   FIELD_PREP(CA_MASK, (n))
> > > +#define  RFB BIT(1)
> > > +#define  LVDS_EN BIT(0)
> > >  
> > >  /* DPHY registers */
> > >  #define DPHY_PD_DPHY 0x00
> > > @@ -55,8 +69,15 @@
> > >  #define PWR_ON   0
> > >  #define PWR_OFF  1
> > >  
> > > +#define MIN_VCO_FREQ 64000
> > > +#define MAX_VCO_FREQ 15
> > > +
> > > +#define MIN_LVDS_REFCLK_FREQ 2400
> > > +#define MAX_LVDS_REFCLK_FREQ 15000
> > > +
> > >  enum mixel_dphy_devtype {
> > >   MIXEL_IMX8MQ,
> > > + MIXEL_IMX8QXP,
> > >  };
> > >  
> > >  struct mixel_dphy_devdata {
> > > @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> > >   u8 reg_rxlprp;
> > >   u8 reg_rxcdrp;
> > >   u8 reg_rxhs_settle;
> > > + bool is_combo;  /* MIPI DPHY and LVDS PHY combo */
> > >  };
> > >  
> > >  static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> > > @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata 
> > > mixel_dphy_devdata[] = {
> > >   .reg_rxlprp = 0x40,
> > >   .reg_rxcdrp = 0x44,
> > >   .reg_rxhs_settle = 0x48,
> > > + .is_combo = false,
> > > + },
> > > + [MIXEL_IMX8QXP] = {
> > > + .is_combo = true,
> > >   },
> > >  };
> > >  
> > > @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> > >  struct mixel_dphy_priv {
> > >   struct mixel_dphy_cfg cfg;
> > >   struct regmap *regmap;
> > > + struct regmap *lvds_regmap;
> > >   struct clk *phy_ref_clk;
> > >   const struct mixel_dphy_devdata *devdata;
> > > + struct imx_sc_ipc *ipc_handle;
> > > + bool is_slave;
> > > + int id;
> > >  };
> > >  
> > >  static const struct regmap_config mixel_dphy_regmap_config = {
> > > @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> > >   return 0;
> > >  }
> > >  
> > > -static int mixel_dphy_configure(struct phy *phy, union 
> > > phy_configure_opts *opts)
> > > +static int
> > > +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts 
> > > *opts)
> > >  {
> > >   struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> > >   struct mixel_dphy_cfg cfg = { 0 };
> > > @@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy, 
> > > union phy_configure_opts *opts)
> > >   return 0;
> > >  }
> > >  
> > > +static int
> > > +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts 
> > > *opts)
> > > +{
> > > + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> > > + struct phy_configure_opts_lvds *lvds_opts = &opts->lvds;
> > > + unsigned long data_rate;
> > > + unsigned long fvco;
> > > + u32 rsc;
> > > + u32

[PATCH v7 18/18] drm/i915/hdcp: Enable HDCP 2.2 MST support

[Anshuman Gupta]

Enable HDCP 2.2 over DP MST.
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.

Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream encryption is disabled,
disable the port HDCP encryption and deauthenticate the port.

v2:
- Add connector details in drm_err. [Ram]
- 's/port_auth/hdcp_auth_status'. [Ram]
- Added a debug print for stream enc.
v3:
- uniformity for connector detail in DMESG. [Ram]

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 53 ++-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 65dd39b44688..4b221c298835 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1700,6 +1700,36 @@ static int hdcp2_authenticate_sink(struct 
intel_connector *connector)
return ret;
 }
 
+static int hdcp2_enable_stream_encryption(struct intel_connector *connector)
+{
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_hdcp *hdcp = &connector->hdcp;
+   enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+   enum port port = dig_port->base.port;
+   int ret = 0;
+
+   if (!(intel_de_read(dev_priv, HDCP2_STATUS(dev_priv, cpu_transcoder, 
port)) &
+   LINK_ENCRYPTION_STATUS)) {
+   drm_err(&dev_priv->drm, "[%s:%d] HDCP 2.2 Link is not 
encrypted\n",
+   connector->base.name, connector->base.base.id);
+   return -EPERM;
+   }
+
+   if (hdcp->shim->stream_2_2_encryption) {
+   ret = hdcp->shim->stream_2_2_encryption(connector, true);
+   if (ret) {
+   drm_err(&dev_priv->drm, "[%s:%d] Failed to enable HDCP 
2.2 stream enc\n",
+   connector->base.name, connector->base.base.id);
+   return ret;
+   }
+   drm_dbg_kms(&dev_priv->drm, "HDCP 2.2 transcoder: %s stream 
encrypted\n",
+   transcoder_name(hdcp->stream_transcoder));
+   }
+
+   return ret;
+}
+
 static int hdcp2_enable_encryption(struct intel_connector *connector)
 {
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -1838,7 +1868,7 @@ static int hdcp2_authenticate_and_encrypt(struct 
intel_connector *connector)
drm_dbg_kms(&i915->drm, "Port deauth failed.\n");
}
 
-   if (!ret) {
+   if (!ret && !dig_port->hdcp_auth_status) {
/*
 * Ensuring the required 200mSec min time interval between
 * Session Key Exchange and encryption.
@@ -1853,6 +1883,8 @@ static int hdcp2_authenticate_and_encrypt(struct 
intel_connector *connector)
}
}
 
+   ret = hdcp2_enable_stream_encryption(connector);
+
return ret;
 }
 
@@ -1898,11 +1930,26 @@ static int _intel_hdcp2_disable(struct intel_connector 
*connector)
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+   struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
 
drm_dbg_kms(&i915->drm, "[%s:%d] HDCP2.2 is being Disabled\n",
connector->base.name, connector->base.base.id);
 
+   if (hdcp->shim->stream_2_2_encryption) {
+   ret = hdcp->shim->stream_2_2_encryption(connector, false);
+   if (ret) {
+   drm_err(&i915->drm, "[%s:%d] Failed to disable HDCP 2.2 
stream enc\n",
+   connector->base.name, connector->base.base.id);
+   return ret;
+   }
+   drm_dbg_kms(&i915->drm, "HDCP 2.2 transcoder: %s stream 
encryption disabled\n",
+   transcoder_name(hdcp->stream_transcoder));
+   }
+
+   if (dig_port->num_hdcp_streams > 0)
+   return ret;
+
ret = hdcp2_disable_encryption(connector);
 
if (hdcp2_deauthenticate_port(connector) < 0)
@@ -1926,6 +1973,7 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
int ret = 0;
 
mutex_lock(&hdcp->mutex);
+   mutex_lock(&dig_port->hdcp_mutex);
cpu_transcoder = hdcp->cpu_transcoder;
 
/* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
@@ -2003,6 +2051,7 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
}
 
 out:
+   mutex_unlock(&

[PATCH v7 17/18] drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks

[Anshuman Gupta]

Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.

v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redundant link check. [Ram]
v4:
- use pipe instead of port to access HDCP2_STREAM_STATUS

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 .../drm/i915/display/intel_display_types.h|  4 +
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 89 +--
 2 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 63de25b40eff..da91e3f4ff27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -378,6 +378,10 @@ struct intel_hdcp_shim {
int (*config_stream_type)(struct intel_digital_port *dig_port,
  bool is_repeater, u8 type);
 
+   /* Enable/Disable HDCP 2.2 stream encryption on DP MST Transport Link */
+   int (*stream_2_2_encryption)(struct intel_connector *connector,
+bool enable);
+
/* HDCP2.2 Link Integrity Check */
int (*check_2_2_link)(struct intel_digital_port *dig_port,
  struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 9ade1ad3a80c..f372e25edab4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -698,18 +698,14 @@ intel_dp_mst_hdcp_stream_encryption(struct 
intel_connector *connector,
return 0;
 }
 
-static
-bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
- struct intel_connector *connector)
+static bool intel_dp_mst_get_qses_status(struct intel_digital_port *dig_port,
+struct intel_connector *connector)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
-   struct intel_dp *intel_dp = &dig_port->dp;
struct drm_dp_query_stream_enc_status_ack_reply reply;
+   struct intel_dp *intel_dp = &dig_port->dp;
int ret;
 
-   if (!intel_dp_hdcp_check_link(dig_port, connector))
-   return false;
-
ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
  connector->port, &reply);
if (ret) {
@@ -726,6 +722,78 @@ bool intel_dp_mst_hdcp_check_link(struct 
intel_digital_port *dig_port,
return reply.auth_completed && reply.encryption_enabled;
 }
 
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
+{
+   if (!intel_dp_hdcp_check_link(dig_port, connector))
+   return false;
+
+   return intel_dp_mst_get_qses_status(dig_port, connector);
+}
+
+static int
+intel_dp_mst_hdcp2_stream_encryption(struct intel_connector *connector,
+bool enable)
+{
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+   struct intel_hdcp *hdcp = &connector->hdcp;
+   enum transcoder cpu_transcoder = hdcp->stream_transcoder;
+   enum pipe pipe = (enum pipe)cpu_transcoder;
+   enum port port = dig_port->base.port;
+   int ret;
+
+   drm_WARN_ON(&i915->drm, enable &&
+   !!(intel_de_read(i915, HDCP2_AUTH_STREAM(i915, 
cpu_transcoder, port))
+   & AUTH_STREAM_TYPE) != data->streams[0].stream_type);
+
+   ret = intel_dp_mst_toggle_hdcp_stream_select(connector, enable);
+   if (ret)
+   return ret;
+
+   /* Wait for encryption confirmation */
+   if (intel_de_wait_for_register(i915,
+  HDCP2_STREAM_STATUS(i915, 
cpu_transcoder, pipe),
+  STREAM_ENCRYPTION_STATUS,
+  enable ? STREAM_ENCRYPTION_STATUS : 0,
+  HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+   drm_err(&i915->drm, "Timed out waiting for transcoder: %s 
stream encryption %s\n",
+   transcoder_name(cpu_transcoder), enable ? "enabled" : 
"disabled");
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
+/*
+ * DP v2.0 I.3.3 ignore the stream signature L' in QSES reply msg reply.
+ * I.3.5 MST source device may use a QSES msg to query downstream status
+ * for a particular stream.
+ */
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digita

[PATCH v7 16/18] drm/i915/hdcp: Add HDCP 2.2 stream register

[Anshuman Gupta]

Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.

B.Spec: 21780
B.Spec: 14410
B.Spec: 50573

v2
- Modified naming convention of HDCP2_STREAM_STATUS
  for pre-gen12 platforms inline with B.Spec.

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/i915_reg.h | 39 +
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b448e507d41e..cade0a7a97b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9873,6 +9873,7 @@ enum skl_power_gate {
  _PORTD_HDCP2_BASE, \
  _PORTE_HDCP2_BASE, \
  _PORTF_HDCP2_BASE) + (x))
+
 #define PORT_HDCP2_AUTH(port)  _PORT_HDCP2_BASE(port, 0x98)
 #define _TRANSA_HDCP2_AUTH 0x66498
 #define _TRANSB_HDCP2_AUTH 0x66598
@@ -9912,6 +9913,44 @@ enum skl_power_gate {
 TRANS_HDCP2_STATUS(trans) : \
 PORT_HDCP2_STATUS(port))
 
+#define _PIPEA_HDCP2_STREAM_STATUS 0x668C0
+#define _PIPEB_HDCP2_STREAM_STATUS 0x665C0
+#define _PIPEC_HDCP2_STREAM_STATUS 0x666C0
+#define _PIPED_HDCP2_STREAM_STATUS 0x667C0
+#define PIPE_HDCP2_STREAM_STATUS(pipe) _MMIO(_PICK((pipe), \
+ 
_PIPEA_HDCP2_STREAM_STATUS, \
+ 
_PIPEB_HDCP2_STREAM_STATUS, \
+ 
_PIPEC_HDCP2_STREAM_STATUS, \
+ 
_PIPED_HDCP2_STREAM_STATUS))
+
+#define _TRANSA_HDCP2_STREAM_STATUS0x664C0
+#define _TRANSB_HDCP2_STREAM_STATUS0x665C0
+#define TRANS_HDCP2_STREAM_STATUS(trans)   _MMIO_TRANS(trans, \
+   
_TRANSA_HDCP2_STREAM_STATUS, \
+   _TRANSB_HDCP2_STREAM_STATUS)
+#define   STREAM_ENCRYPTION_STATUS BIT(31)
+#define   STREAM_TYPE_STATUS   BIT(30)
+#define HDCP2_STREAM_STATUS(dev_priv, trans, port) \
+   (INTEL_GEN(dev_priv) >= 12 ? \
+TRANS_HDCP2_STREAM_STATUS(trans) : \
+PIPE_HDCP2_STREAM_STATUS(pipe))
+
+#define _PORTA_HDCP2_AUTH_STREAM   0x66F00
+#define _PORTB_HDCP2_AUTH_STREAM   0x66F04
+#define PORT_HDCP2_AUTH_STREAM(port)   _MMIO_PORT(port, \
+  _PORTA_HDCP2_AUTH_STREAM, \
+  _PORTB_HDCP2_AUTH_STREAM)
+#define _TRANSA_HDCP2_AUTH_STREAM  0x66F00
+#define _TRANSB_HDCP2_AUTH_STREAM  0x66F04
+#define TRANS_HDCP2_AUTH_STREAM(trans) _MMIO_TRANS(trans, \
+   _TRANSA_HDCP2_AUTH_STREAM, \
+   _TRANSB_HDCP2_AUTH_STREAM)
+#define   AUTH_STREAM_TYPE BIT(31)
+#define HDCP2_AUTH_STREAM(dev_priv, trans, port) \
+   (INTEL_GEN(dev_priv) >= 12 ? \
+TRANS_HDCP2_AUTH_STREAM(trans) : \
+PORT_HDCP2_AUTH_STREAM(port))
+
 /* Per-pipe DDI Function Control */
 #define _TRANS_DDI_FUNC_CTL_A  0x60400
 #define _TRANS_DDI_FUNC_CTL_B  0x61400
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 15/18] drm/i915/hdcp: Pass connector to check_2_2_link

[Anshuman Gupta]

This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c   | 3 ++-
 drivers/gpu/drm/i915/display/intel_hdcp.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c  | 3 ++-
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b37a02a73de6..63de25b40eff 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -379,7 +379,8 @@ struct intel_hdcp_shim {
  bool is_repeater, u8 type);
 
/* HDCP2.2 Link Integrity Check */
-   int (*check_2_2_link)(struct intel_digital_port *dig_port);
+   int (*check_2_2_link)(struct intel_digital_port *dig_port,
+ struct intel_connector *connector);
 };
 
 struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 3f23f8b53dcd..9ade1ad3a80c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -585,7 +585,8 @@ int intel_dp_hdcp2_config_stream_type(struct 
intel_digital_port *dig_port,
 }
 
 static
-int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port)
+int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
 {
u8 rx_status;
int ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c21a6a6c545c..65dd39b44688 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1947,7 +1947,7 @@ static int intel_hdcp2_check_link(struct intel_connector 
*connector)
goto out;
}
 
-   ret = hdcp->shim->check_2_2_link(dig_port);
+   ret = hdcp->shim->check_2_2_link(dig_port, connector);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 25d76460f8f9..977e6b6c35c7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1733,7 +1733,8 @@ int intel_hdmi_hdcp2_read_msg(struct intel_digital_port 
*dig_port,
 }
 
 static
-int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port)
+int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port,
+   struct intel_connector *connector)
 {
u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
int ret;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 14/18] drm/i915/hdcp: MST streams support in hdcp port_data

[Anshuman Gupta]

Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.

Security f/w doesn't have any provision to mark the
stream_type for each stream separately, it just take
single input of stream_type while authenticating the
port. So driver mark each stream_type with common
highest supported content type for all streams in
DP MST Topology.

Security f/w supports RepeaterAuthStreamManage msg and m'
validation only once during port authentication and encryption.
Ideally it should support dynamic update of content_type
and should support RepeaterAuthStreamManage msg and m' validation
whenever required.

v2:
- Init the hdcp port data k for HDMI/DP SST stream.
v3:
- Cosmetic changes. [Uma]
v4:
- 's/port_auth/hdcp_port_auth'. [Ram]
- Commit log improvement.
v5:
- Comment and commit log improvement. [Ram]

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 .../drm/i915/display/intel_display_types.h|   4 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 113 +++---
 2 files changed, 102 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b74c10c8b01c..b37a02a73de6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1502,10 +1502,12 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
 
-   /* protects num_hdcp_streams reference count, hdcp_port_data */
+   /* protects num_hdcp_streams reference count, hdcp_port_data and 
hdcp_auth_status */
struct mutex hdcp_mutex;
/* the number of pipes using HDCP signalling out of this port */
unsigned int num_hdcp_streams;
+   /* port HDCP auth status */
+   bool hdcp_auth_status;
/* HDCP port data need to pass to security f/w */
struct hdcp_port_data hdcp_port_data;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2bec26123a05..c21a6a6c545c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -26,6 +26,74 @@
 #define KEY_LOAD_TRIES 5
 #define HDCP2_LC_RETRY_CNT 3
 
+static int intel_conn_to_vcpi(struct intel_connector *connector)
+{
+   /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+   return connector->port  ? connector->port->vcpi.vcpi : 0;
+}
+
+/*
+ * intel_hdcp_required_content_stream select most highest common possible HDCP
+ * content_type for all streams in DP MST topology because security f/w doesn't
+ * have any provision to mark content_type for each stream separately, it marks
+ * all available streams with the content_type proivided at the time of port
+ * authentication. This may prohibit the userspace to use type1 content on
+ * HDCP 2.2 capable sink because of other sink are not capable of HDCP 2.2 in
+ * DP MST topology. Ideally security f/w should change its policy to mark
+ * different content_type for different streams.
+ */
+static int
+intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+{
+   struct drm_connector_list_iter conn_iter;
+   struct intel_digital_port *conn_dig_port;
+   struct intel_connector *connector;
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+   bool enforce_type0 = false;
+   int k;
+
+   if (dig_port->hdcp_auth_status)
+   return 0;
+
+   drm_connector_list_iter_begin(&i915->drm, &conn_iter);
+   for_each_intel_connector_iter(connector, &conn_iter) {
+   if (!intel_encoder_is_mst(intel_attached_encoder(connector)))
+   continue;
+
+   conn_dig_port = intel_attached_dig_port(connector);
+   if (conn_dig_port != dig_port)
+   continue;
+
+   if (connector->base.status == connector_status_disconnected)
+   continue;
+
+   if (!enforce_type0 && !intel_hdcp2_capable(connector))
+   enforce_type0 = true;
+
+   data->streams[data->k].stream_id = 
intel_conn_to_vcpi(connector);
+   data->k++;
+
+   /* if there is only one active stream */
+   if (dig_port->dp.active_mst_links <= 1)
+   break;
+   }
+   drm_connector_list_iter_end(&conn_iter);
+
+   if (drm_WARN_ON(&i915->drm, data->k > INTEL_NUM_PIPES(i915) || data->k 
== 0))
+   return -EINVAL;
+
+   /*
+* Apply common protection level across all streams in DP MST Topology.
+* Use highest supported content type for all streams in DP MST 
Topology.
+*/
+   for (k = 0; k < data->k; k++)
+

[PATCH v7 13/18] drm/hdcp: Max MST content streams

[Anshuman Gupta]

Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.

Cc: Sean Paul 
Cc: Ramalingam C 
Acked-by: Maarten Lankhorst 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 include/drm/drm_hdcp.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index fe58dbb46962..ac22c246542a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -101,11 +101,11 @@
 
 /* Following Macros take a byte at a time for bit(s) masking */
 /*
- * TODO: This has to be changed for DP MST, as multiple stream on
- * same port is possible.
- * For HDCP2.2 on HDMI and DP SST this value is always 1.
+ * TODO: HDCP_2_2_MAX_CONTENT_STREAMS_CNT is based upon actual
+ * H/W MST streams capacity.
+ * This required to be moved out to platform specific header.
  */
-#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   1
+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   4
 #define HDCP_2_2_TXCAP_MASK_LEN2
 #define HDCP_2_2_RXCAPS_LEN3
 #define HDCP_2_2_RX_REPEATER(x)((x) & BIT(0))
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 12/18] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len

[Anshuman Gupta]

Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size.
It is based upon the actual number of MST streams and size
of wired_cmd_repeater_auth_stream_req_in.
Excluding the size of hdcp_cmd_header.

v2:
- hdcp_cmd_header size annotation nitpick. [Tomas]

Cc: Tomas Winkler 
Cc: Ramalingam C 
Acked-by: Tomas Winkler 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/misc/mei/hdcp/mei_hdcp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 9ae9669e46ea..3506a3534294 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -569,8 +569,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in->header.api_version = HDCP_API_VERSION;
verify_mprime_in->header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ;
verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS;
-   verify_mprime_in->header.buffer_len =
-   WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN;
+   verify_mprime_in->header.buffer_len = cmd_size  - 
sizeof(verify_mprime_in->header);
 
verify_mprime_in->port.integrated_port_type = data->port_type;
verify_mprime_in->port.physical_port = (u8)data->fw_ddi;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 11/18] drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port

[Anshuman Gupta]

hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.

v2:
- 's/port_data/hdcp_port_data'. [Ram]

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  2 +
 .../drm/i915/display/intel_display_types.h|  5 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 56 +++
 3 files changed, 39 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 046c49931b98..54418a6cc3d4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4965,6 +4965,8 @@ static void intel_ddi_encoder_destroy(struct drm_encoder 
*encoder)
intel_dp_encoder_flush_work(encoder);
 
drm_encoder_cleanup(encoder);
+   if (dig_port)
+   kfree(dig_port->hdcp_port_data.streams);
kfree(dig_port);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f0aeba9a222a..b74c10c8b01c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -406,7 +406,6 @@ struct intel_hdcp {
 * content can flow only through a link protected by HDCP2.2.
 */
u8 content_type;
-   struct hdcp_port_data port_data;
 
bool is_paired;
bool is_repeater;
@@ -1503,10 +1502,12 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
 
-   /* protects num_hdcp_streams reference count */
+   /* protects num_hdcp_streams reference count, hdcp_port_data */
struct mutex hdcp_mutex;
/* the number of pipes using HDCP signalling out of this port */
unsigned int num_hdcp_streams;
+   /* HDCP port data need to pass to security f/w */
+   struct hdcp_port_data hdcp_port_data;
 
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4ad086e7ec3c..2bec26123a05 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 
+#include "i915_drv.h"
 #include "i915_reg.h"
 #include "intel_display_power.h"
 #include "intel_display_types.h"
@@ -1025,7 +1026,8 @@ static int
 hdcp2_prepare_ake_init(struct intel_connector *connector,
   struct hdcp2_ake_init *ake_data)
 {
-   struct hdcp_port_data *data = &connector->hdcp.port_data;
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1054,7 +1056,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector 
*connector,
struct hdcp2_ake_no_stored_km *ek_pub_km,
size_t *msg_sz)
 {
-   struct hdcp_port_data *data = &connector->hdcp.port_data;
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1081,7 +1084,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector 
*connector,
 static int hdcp2_verify_hprime(struct intel_connector *connector,
   struct hdcp2_ake_send_hprime *rx_hprime)
 {
-   struct hdcp_port_data *data = &connector->hdcp.port_data;
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1106,7 +1110,8 @@ static int
 hdcp2_store_pairing_info(struct intel_connector *connector,
 struct hdcp2_ake_send_pairing_info *pairing_info)
 {
-   struct hdcp_port_data *data = &connector->hdcp.port_data;
+   struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
+   struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1132,7 +1137,8 @@ static int
 hdcp2_prepare_lc_init(struct intel_connector *connector,
  struct hdcp2_lc_init *lc_init)
 {
-   struct hdcp_port_data *data = &conn

[PATCH v7 10/18] drm/i915/hdcp: Pass dig_port to intel_hdcp_init

[Anshuman Gupta]

Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_hdcp.c| 12 +++-
 drivers/gpu/drm/i915/display/intel_hdcp.h|  4 +++-
 drivers/gpu/drm/i915/display/intel_hdmi.c|  2 +-
 4 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 94c5462fa037..3f23f8b53dcd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -755,10 +755,10 @@ int intel_dp_init_hdcp(struct intel_digital_port 
*dig_port,
return 0;
 
if (intel_connector->mst_port)
-   return intel_hdcp_init(intel_connector, port,
+   return intel_hdcp_init(intel_connector, dig_port,
   &intel_dp_mst_hdcp_shim);
else if (!intel_dp_is_edp(intel_dp))
-   return intel_hdcp_init(intel_connector, port,
+   return intel_hdcp_init(intel_connector, dig_port,
   &intel_dp_hdcp_shim);
 
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fce444d69521..4ad086e7ec3c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1979,12 +1979,13 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum 
transcoder cpu_transcoder)
 }
 
 static int initialize_hdcp_port_data(struct intel_connector *connector,
-enum port port,
+struct intel_digital_port *dig_port,
 const struct intel_hdcp_shim *shim)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
+   enum port port = dig_port->base.port;
 
if (INTEL_GEN(dev_priv) < 12)
data->fw_ddi = intel_get_mei_fw_ddi_index(port);
@@ -2057,14 +2058,15 @@ void intel_hdcp_component_init(struct drm_i915_private 
*dev_priv)
}
 }
 
-static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
+static void intel_hdcp2_init(struct intel_connector *connector,
+struct intel_digital_port *dig_port,
 const struct intel_hdcp_shim *shim)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
 
-   ret = initialize_hdcp_port_data(connector, port, shim);
+   ret = initialize_hdcp_port_data(connector, dig_port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2074,7 +2076,7 @@ static void intel_hdcp2_init(struct intel_connector 
*connector, enum port port,
 }
 
 int intel_hdcp_init(struct intel_connector *connector,
-   enum port port,
+   struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2085,7 +2087,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
 
if (is_hdcp2_supported(dev_priv) && !connector->mst_port)
-   intel_hdcp2_init(connector, port, shim);
+   intel_hdcp2_init(connector, dig_port, shim);
 
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index b912a3a0f5b8..8f53b0c7fe5c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -18,13 +18,15 @@ struct intel_connector;
 struct intel_crtc_state;
 struct intel_encoder;
 struct intel_hdcp_shim;
+struct intel_digital_port;
 enum port;
 enum transcoder;
 
 void intel_hdcp_atomic_check(struct drm_connector *connector,
 struct drm_connector_state *old_state,
 struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector, enum port port,
+int intel_hdcp_init(struct intel_connector *connector,
+   struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *hdcp_shim);
 int intel_hdcp_enable(struct intel_connector *connector,
  const struct intel_crtc_state *pipe_config, u8 
content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e072

[PATCH v7 09/18] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support

[Anshuman Gupta]

Enable HDCP 1.4 over DP MST for Gen12.

v2:
- Enable HDCP for <= Gen12 platforms. [Ram]

Cc: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 47beb442094f..ae24e1af49be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -829,12 +829,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
 
-
-   /* TODO: Figure out how to make HDCP work on GEN12+ */
-   if (INTEL_GEN(dev_priv) < 12) {
+   if (INTEL_GEN(dev_priv) <= 12) {
ret = intel_dp_init_hdcp(dig_port, intel_connector);
if (ret)
-   DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
+   drm_dbg_kms(&dev_priv->drm, "HDCP init failed, 
skipping.\n");
}
 
/*
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 08/18] drm/i915/hdcp: Enable HDCP 1.4 stream encryption

[Anshuman Gupta]

Enable HDCP 1.4 DP MST stream encryption.

Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.

Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the link.

v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
  encryption.
v3:
- Cosmetic change, removed the value less comment. [Uma]
v4:
- Split the Gen12 HDCP enablement patch. [Ram]
- Add connector details in drm_err.
v5:
- uniformity for connector detail in DMESG. [Ram]
- comments improvement. [Ram]

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 38 +++
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6e6465b4ecfa..fce444d69521 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -766,10 +766,17 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
return -ETIMEDOUT;
}
 
-   /*
-* XXX: If we have MST-connected devices, we need to enable encryption
-* on those as well.
-*/
+   /* DP MST Auth Part 1 Step 2.a and Step 2.b */
+   if (shim->stream_encryption) {
+   ret = shim->stream_encryption(connector, true);
+   if (ret) {
+   drm_err(&dev_priv->drm, "[%s:%d] Failed to enable HDCP 
1.4 stream enc\n",
+   connector->base.name, connector->base.base.id);
+   return ret;
+   }
+   drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream 
encrypted\n",
+   transcoder_name(hdcp->stream_transcoder));
+   }
 
if (repeater_present)
return intel_hdcp_auth_downstream(connector);
@@ -791,18 +798,23 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
 
+   if (hdcp->shim->stream_encryption) {
+   ret = hdcp->shim->stream_encryption(connector, false);
+   if (ret) {
+   drm_err(&dev_priv->drm, "[%s:%d] Failed to disable HDCP 
1.4 stream enc\n",
+   connector->base.name, connector->base.base.id);
+   return ret;
+   }
+   drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream 
encryption disabled\n",
+   transcoder_name(hdcp->stream_transcoder));
+   }
+
/*
-* If there are other connectors on this port using HDCP, don't disable
-* it. Instead, toggle the HDCP signalling off on that particular
-* connector/pipe and exit.
+* If there are other connectors on this port using HDCP, don't disable 
it
+* until it disabled HDCP encryption for all connectors in MST topology.
 */
-   if (dig_port->num_hdcp_streams > 0) {
-   ret = hdcp->shim->toggle_signalling(dig_port,
-   cpu_transcoder, false);
-   if (ret)
-   DRM_ERROR("Failed to disable HDCP signalling\n");
+   if (dig_port->num_hdcp_streams > 0)
return ret;
-   }
 
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 07/18] drm/i915/hdcp: HDCP stream encryption support

[Anshuman Gupta]

Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.

HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.

Both of above requirement are same for all Gen with respect to
B.Spec Documentation.

v2:
- Cosmetic changes function name, error msg print and
  stream typo fixes. [Uma]
v3:
- uniformity for connector detail in DMESG. [Ram]

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  | 10 +--
 drivers/gpu/drm/i915/display/intel_ddi.h  |  6 +-
 .../drm/i915/display/intel_display_types.h|  4 +
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 90 ---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 14 +--
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 6 files changed, 97 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 14c2c0a15464..046c49931b98 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2029,9 +2029,9 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
}
 }
 
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable)
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+  enum transcoder cpu_transcoder,
+  bool enable, u32 hdcp_mask)
 {
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2046,9 +2046,9 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder 
*intel_encoder,
 
tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
-   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   tmp |= hdcp_mask;
else
-   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   tmp &= ~hdcp_mask;
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h 
b/drivers/gpu/drm/i915/display/intel_ddi.h
index dcc711cfe4fe..a4dd815c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -50,9 +50,9 @@ u32 bxt_signal_levels(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state);
 u32 ddi_signal_levels(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state);
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable);
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+  enum transcoder cpu_transcoder,
+  bool enable, u32 hdcp_mask);
 void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
 
 #endif /* __INTEL_DDI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 729a9792051f..f0aeba9a222a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -343,6 +343,10 @@ struct intel_hdcp_shim {
 enum transcoder cpu_transcoder,
 bool enable);
 
+   /* Enable/Disable stream encryption on DP MST Transport Link */
+   int (*stream_encryption)(struct intel_connector *connector,
+bool enable);
+
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *dig_port,
   struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 03424d20e9f7..94c5462fa037 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -16,6 +16,30 @@
 #include "intel_dp.h"
 #include "intel_hdcp.h"
 
+static unsigned int transcoder_to_stream_enc_status(enum transcoder 
cpu_transcoder)
+{
+   u32 stream_enc_mask;
+
+   switch (cpu_transcoder) {
+   case TRANSCODER_A:
+   stream_enc_mask = HDCP_STATUS_STREAM_A_ENC;
+   break;
+   case TRANSCODER_B:
+   stream_enc_mask = HDCP_STATUS_STREAM_B_ENC;
+   break;
+   case TRAN

[PATCH v7 06/18] drm/i915/hdcp: Move HDCP enc status timeout to header

[Anshuman Gupta]

DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.

Related: 'commit 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 9 -
 drivers/gpu/drm/i915/display/intel_hdcp.h | 2 ++
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 293f72d1d215..6e6465b4ecfa 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,7 +23,6 @@
 #include "intel_connector.h"
 
 #define KEY_LOAD_TRIES 5
-#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS   50
 #define HDCP2_LC_RETRY_CNT 3
 
 static
@@ -762,7 +761,7 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
if (intel_de_wait_for_set(dev_priv,
  HDCP_STATUS(dev_priv, cpu_transcoder, port),
  HDCP_STATUS_ENC,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
drm_err(&dev_priv->drm, "Timed out waiting for encryption\n");
return -ETIMEDOUT;
}
@@ -809,7 +808,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
-   ~0, ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+   ~0, HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) 
{
drm_err(&dev_priv->drm,
"Failed to disable HDCP, timeout clearing status\n");
return -ETIMEDOUT;
@@ -1641,7 +1640,7 @@ static int hdcp2_enable_encryption(struct intel_connector 
*connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
 port),
LINK_ENCRYPTION_STATUS,
-   ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+   HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
 
return ret;
 }
@@ -1665,7 +1664,7 @@ static int hdcp2_disable_encryption(struct 
intel_connector *connector)
  HDCP2_STATUS(dev_priv, cpu_transcoder,
   port),
  LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
if (ret == -ETIMEDOUT)
drm_dbg_kms(&dev_priv->drm, "Disable Encryption Timedout");
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index bc51c1e9b481..b912a3a0f5b8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -8,6 +8,8 @@
 
 #include 
 
+#define HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS  50
+
 struct drm_connector;
 struct drm_connector_state;
 struct drm_i915_private;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 05/18] drm/i915/hdcp: DP MST transcoder for link and stream

[Anshuman Gupta]

Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.

This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.

This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.

Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  2 +-
 .../gpu/drm/i915/display/intel_display_types.h|  2 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +++
 drivers/gpu/drm/i915/display/intel_hdcp.h |  2 +-
 5 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6863236df1d0..14c2c0a15464 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4252,7 +4252,7 @@ static void intel_enable_ddi(struct intel_atomic_state 
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state->cpu_transcoder,
+ crtc_state,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..729a9792051f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -436,6 +436,8 @@ struct intel_hdcp {
 * Hence caching the transcoder here.
 */
enum transcoder cpu_transcoder;
+   /* Only used for DP MST stream encryption */
+   enum transcoder stream_transcoder;
 };
 
 struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 27f04aed8764..47beb442094f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -569,7 +569,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state 
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- pipe_config->cpu_transcoder,
+ pipe_config,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 7d63e9495956..293f72d1d215 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2095,7 +2095,7 @@ int intel_hdcp_init(struct intel_connector *connector,
 }
 
 int intel_hdcp_enable(struct intel_connector *connector,
- enum transcoder cpu_transcoder, u8 content_type)
+ const struct intel_crtc_state *pipe_config, u8 
content_type)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *dig_port = 
intel_attached_dig_port(connector);
@@ -2117,10 +2117,17 @@ int intel_hdcp_enable(struct intel_connector *connector,
drm_WARN_ON(&dev_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
hdcp->content_type = content_type;
-   hdcp->cpu_transcoder = cpu_transcoder;
+
+   if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+   hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+   hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+   } else {
+   hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+   hdcp->stream_transcoder = INVALID_TRANSCODER;
+   }
 
if (INTEL_GEN(dev_priv) >= 12)
-   hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+   hdcp->port_data.fw_tc = 
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
 
/*
 * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2240,7 +2247,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
 
if (desired_and_not_enabled || content_protection_type_changed)
intel_hdcp_enable(connector,
- crtc_state->cpu_transcoder,
+ crtc_state,
  (u8)conn_state->hdcp_content_type);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 1bbf5b67ed0a..bc51c1e9b481 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -25,7 +25,7 @@ 

[PATCH v7 04/18] drm/i915/hdcp: No HDCP when encoder is't initialized

[Anshuman Gupta]

There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.

Cc: Ramalingam C 
Cc: Juston Li 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b9d8825e2bb1..7d63e9495956 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2106,6 +2106,12 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
 
+   if (!connector->encoder) {
+   drm_err(&dev_priv->drm, "[%s:%d] encoder is not initialized\n",
+   connector->base.name, connector->base.base.id);
+   return -ENODEV;
+   }
+
mutex_lock(&hdcp->mutex);
mutex_lock(&dig_port->hdcp_mutex);
drm_WARN_ON(&dev_priv->drm,
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 03/18] drm/i915/hotplug: Handle CP_IRQ for DP-MST

[Anshuman Gupta]

Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.

Cc: "Ville Syrjälä" 
Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb5e42c3ecd5..463003ff0dd4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5775,6 +5775,17 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
"Could not write test response to sink\n");
 }
 
+static void
+intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, bool *handled)
+{
+   drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, handled);
+
+   if (esi[1] & DP_CP_IRQ) {
+   intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
+   *handled = true;
+   }
+}
+
 /**
  * intel_dp_check_mst_status - service any pending MST interrupts, check link 
status
  * @intel_dp: Intel DP struct
@@ -5819,7 +5830,8 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
 
drm_dbg_kms(&i915->drm, "got esi %3ph\n", esi);
 
-   drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, &handled);
+   intel_dp_mst_hpd_irq(intel_dp, esi, &handled);
+
if (!handled)
break;
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 00/18] HDCP 2.2 and HDCP 1.4 Gen12 DP MST support

[Anshuman Gupta]

This is v7 version has added some fixes to below pacthes related to
gen11 platform.
[PATCH v7 17/18] drm/i915/hdcp: Support for HDCP 2.2 MST shim
[PATCH v7 16/18] drm/i915/hdcp: Add HDCP 2.2 stream register
 
It has been tested manually with below IGT series on TGL and ICL.
https://patchwork.freedesktop.org/series/82987/

[PATCH v6 12/18] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
has an Ack from Tomas to merge it via drm-intel.

[PATCH v6 13/18] drm/hdcp: Max MST content streams
has an Ack from drm-misc maintainer to merge it via drm-intel.

Test-with: 20201126050320.2434-2-karthik@intel.com

Anshuman Gupta (18):
  drm/i915/hdcp: Update CP property in update_pipe
  drm/i915/hdcp: Get conn while content_type changed
  drm/i915/hotplug: Handle CP_IRQ for DP-MST
  drm/i915/hdcp: No HDCP when encoder is't initialized
  drm/i915/hdcp: DP MST transcoder for link and stream
  drm/i915/hdcp: Move HDCP enc status timeout to header
  drm/i915/hdcp: HDCP stream encryption support
  drm/i915/hdcp: Enable HDCP 1.4 stream encryption
  drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
  drm/i915/hdcp: Pass dig_port to intel_hdcp_init
  drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
  misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
  drm/hdcp: Max MST content streams
  drm/i915/hdcp: MST streams support in hdcp port_data
  drm/i915/hdcp: Pass connector to check_2_2_link
  drm/i915/hdcp: Add HDCP 2.2 stream register
  drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
  drm/i915/hdcp: Enable HDCP 2.2 MST support

 drivers/gpu/drm/i915/display/intel_ddi.c  |  14 +-
 drivers/gpu/drm/i915/display/intel_ddi.h  |   6 +-
 .../drm/i915/display/intel_display_types.h|  20 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  14 +-
 drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 186 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   8 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c | 303 ++
 drivers/gpu/drm/i915/display/intel_hdcp.h |   8 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  19 +-
 drivers/gpu/drm/i915/i915_reg.h   |  40 +++
 drivers/misc/mei/hdcp/mei_hdcp.c  |   3 +-
 include/drm/drm_hdcp.h|   8 +-
 12 files changed, 509 insertions(+), 120 deletions(-)

-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 02/18] drm/i915/hdcp: Get conn while content_type changed

[Anshuman Gupta]

Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.

Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing 
connectors")
Cc: Sean Paul 
Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eee8263405b9..b9d8825e2bb1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2210,6 +2210,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
if (content_protection_type_changed) {
mutex_lock(&hdcp->mutex);
hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+   drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
mutex_unlock(&hdcp->mutex);
}
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 01/18] drm/i915/hdcp: Update CP property in update_pipe

[Anshuman Gupta]

When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.

This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.

v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
  WARN_ON.

v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]

Fixes: 33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal 
state")
Cc: Ramalingam C 
Reviewed-by: Uma Shankar 
Reviewed-by: Ramalingam C 
Tested-by: Karthik B S 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b2a4bbcfdcd2..eee8263405b9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2221,6 +2221,14 @@ void intel_hdcp_update_pipe(struct intel_atomic_state 
*state,
desired_and_not_enabled =
hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED;
mutex_unlock(&hdcp->mutex);
+   /*
+* If HDCP already ENABLED and CP property is DESIRED, schedule
+* prop_work to update correct CP property to user space.
+*/
+   if (!desired_and_not_enabled && 
!content_protection_type_changed) {
+   drm_connector_get(&connector->base);
+   schedule_work(&hdcp->prop_work);
+   }
}
 
if (desired_and_not_enabled || content_protection_type_changed)
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-5.11

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.11.

The following changes since commit beaff108e1bf1e38c9def60dd09f7a4ed7910481:

  drm/amd/powerplay: fix spelling mistake "smu_state_memroy_block" -> 
"smu_state_memory_block" (2020-11-24 12:09:54 -0500)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.11-2020-12-09

for you to fetch changes up to f8aab60422c371425365d386dfd51e0c6c5b1041:

  drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs (2020-12-09 
23:17:03 -0500)


amd-drm-next-5.11-2020-12-09:

amdgpu:
- SR-IOV fixes
- Navy Flounder updates
- Sienna Cichlid updates
- Dimgrey Cavefish updates
- Vangogh updates
- Misc SMU fixes
- Misc display fixes
- Last big hunk of W=1 warning fixes
- Cursor validation fixes
- CI BACO updates


AMD\ramini (1):
  drm/amd/display: Set FixRate bit in VSIF V3

Alex Deucher (22):
  drm/amdgpu: default noretry=0 for navi1x and newer (v2)
  drm/amdgpu: enable AGP aperture on gmc10.x (v2)
  drm/amdgpu/swsmu/vangogh: return error if fetching metrics fails
  drm/amdgpu/powerplay/tonga: return an error if copying to smc fails
  drm/amdgpu/powerplay/ci: return an error if copying to smc fails
  drm/amdgpu/powerplay/iceland: return an error if copying to smc fails
  drm/amdgpu/powerplay/vega10: handle error in getting pptable
  drm/amdgpu/powerplay/psm: return an error in power state init
  drm/amdgpu/swsmu/navi1x: simplify sensor handling
  drm/amdgpu/swsmu/arcturus: simplify sensor handling
  drm/amdgpu/swsmu/sienna_cichlid: simplify sensor handling
  drm/amdgpu/swsmu: add metrics enums for voltage
  drm/amdgpu/swsmu/vangogh: simplify sensor handling
  drm/amdgpu/swsmu/vangogh: use metrics table for voltages (v2)
  drm/amdgpu/swsmu/renoir: simplify sensor handling (v2)
  drm/amdgpu/powerplay: parse fan table for CI asics
  drm/amdgpu/disply: set num_crtc earlier
  drm/amdgpu/cik: enable BACO reset on Bonaire
  drm/amdgpu: enable runtime pm using BACO on CI dGPUs
  drm/amdgpu: free the pre-OS console framebuffer after the first modeset
  drm/amdgpu: remove amdgpu_ttm_late_init  and amdgpu_bo_late_init
  drm/amdgpu: fix size calculation with stolen vga memory

Andrey Grodzovsky (1):
  drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs

Anthony Koo (2):
  drm/amd/display: [FW Promotion] Release 0.0.44
  drm/amd/display: [FW Promotion] Release 0.0.45

Aric Cyr (2):
  drm/amd/display: DC Release 3.2.114
  drm/amd/display: 3.2.115

Arnd Bergmann (2):
  drm/amdgpu: fix debugfs creation/removal, again
  drm/amdgpu: fw_attestation: fix unused function warning

Arunpravin (1):
  drm/amdgpu/pm/smu11: Fix fan set speed bug

Aurabindo Pillai (2):
  drm/amd/display: Clear dc remote sinks on MST disconnect
  drm/amd/display: turn DPMS off on connector unplug

Boyuan Zhang (2):
  drm/amdgpu/vcn3.0: stall DPG when WPTR/RPTR reset
  drm/amdgpu/vcn3.0: remove old DPG workaround

Brandon Syu (1):
  drm/amd/display: Init clock value by current vbios CLKs

Changfeng (1):
  drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven

Charlene Liu (1):
  drm/amd/display: Enable gpu_vm_support for dcn3.01

Chris Park (1):
  drm/amd/display: Prevent bandwidth overflow

Dmytro Laktyushkin (1):
  drm/amd/display: Expose clk_mgr functions for reuse

Eric Bernstein (1):
  drm/amd/display: Revert update clk_mgr for vg

Eryk Brol (1):
  drm/amd/display: Do full modeset when DSC debugfs is changed

Evan Quan (1):
  drm/amd/pm: invalidate hdp before CPU access the memory written by GPU

Felix Kuehling (1):
  drm/amdkfd: Fix leak in dmabuf import

Jacky Liao (2):
  drm/amd/display: Add HDR3DLUT and SHAPER memory shutdown support
  drm/amd/display: Add DSCL memory low power support

James Zhu (1):
  drm/amdgpu/vcn3.0: fix compilation warning

Jiansong Chen (1):
  drm/amd/pm: update driver if version for navy_flounder

Jing Zhou (1):
  drm/amd/display: Set default bits per channel

Jingwen Chen (1):
  drm/amdgpu: skip power profile switch in sriov

Jinzhou Su (1):
  drm/amdgpu: Set doorbell range for gfx ring

John Wu (1):
  drm/amd/display: Don't check seamless boot in power down HW by timeout

Joshua Aberback (1):
  drm/amd/display: Check link_active instead of lane_settings != unknown

Judy Cai (1):
  drm/amd/display: Change to IMMEDIATE mode from FRAME mode

Kevin Wang (2):
  drm/amdgpu: change trace event parameter name from 'direct' to 'immediate'
  drm/amdgpu/pm: add smc v2_1 printer in amdgpu_ucode_print_smc_hdr()

Lee Jones (69):
  drm/amd/amdgpu/gmc_v10_0: Suppy some missing function doc descriptions
  drm/amd/amdgpu/iceland_ih: Add missing function param descriptions for 
'ih' and 'entry'
 

Re: [PATCH v1 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings

[Rob Herring]

On Mon, 07 Dec 2020 22:50:25 +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> Adds MIPI DSI Controller
> support for Unisoc's display subsystem.
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 
> +
>  1 file changed, 107 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 3/6] dt-bindings: display: add Unisoc's dpu bindings

[Rob Herring]

On Mon, Dec 07, 2020 at 10:50:23PM +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> which transfers the image data from a video memory buffer to an internal
> LCD interface.
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 
> ++
>  1 file changed, 83 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml 
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
> new file mode 100644
> index 000..a9052e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc Sharkl3 Display Processor Unit (DPU)
> +
> +maintainers:
> +  - Kevin Tang 
> +
> +description: |
> +  DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
> +  which transfers the image data from a video memory buffer to an internal
> +  LCD interface.
> +
> +properties:
> +  compatible:
> +const: sprd,sharkl3-dpu
> +
> +  reg:
> +maxItems: 1
> +description:
> +  Physical base address and length of the DPU registers set

Drop. Nothing unique about this.

> +
> +  interrupts:
> +maxItems: 1
> +description:
> +  The interrupt signal from DPU

Drop.

> +
> +  clocks:
> +minItems: 2
> +
> +  clock-names:
> +items:
> +  - const: clk_src_128m
> +  - const: clk_src_384m
> +
> +  power-domains:
> +maxItems: 1
> +description: A phandle to DPU power domain node.

Drop.

> +
> +  iommus:
> +maxItems: 1
> +description: A phandle to DPU iommu node.

Drop.

With those,

Reviewed-by: Rob Herring 

> +
> +  port:
> +type: object
> +description:
> +  A port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  That port should be the output endpoint, usually output to
> +  the associated DSI.
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +dpu: dpu@6300 {
> +compatible = "sprd,sharkl3-dpu";
> +reg = <0x6300 0x1000>;
> +interrupts = ;
> +clock-names = "clk_src_128m", "clk_src_384m";
> +
> +clocks = <&pll CLK_TWPLL_128M>,
> +  <&pll CLK_TWPLL_384M>;
> +
> +dpu_port: port {
> +dpu_out: endpoint {
> +remote-endpoint = <&dsi_in>;
> +};
> +};
> +};
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd drm-fixes-5.10

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.10.

The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f:

  Linux 5.10-rc7 (2020-12-06 14:25:12 -0800)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-12-09

for you to fetch changes up to c5b58c8c860db330c0b8b891b69014ee9d470dab:

  drm/amd/pm: typo fix (CUSTOM -> COMPUTE) (2020-12-09 22:38:10 -0500)


amd-drm-fixes-5.10-2020-12-09:

amdgpu:
- Fan fix for CI asics
- Fix a warning in possible_crtcs
- Build fix for when debugfs is disabled
- Display overflow fix
- Display watermark fixes for Renoir
- SDMA 5.2 fix
- Stolen vga memory regression fix
- Power profile fixes
- Fix a regression from removal of GEM and PRIME callbacks

amdkfd:
- Fix a memory leak in dmabuf import


Alex Deucher (3):
  drm/amdgpu/powerplay: parse fan table for CI asics
  drm/amdgpu/disply: set num_crtc earlier
  drm/amdgpu: fix size calculation with stolen vga memory

Andrey Grodzovsky (1):
  drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs

Arnd Bergmann (1):
  drm/amdgpu: fix debugfs creation/removal, again

Changfeng (1):
  drm/amd/pm: update smu10.h WORKLOAD_PPLIB setting for raven

Chris Park (1):
  drm/amd/display: Prevent bandwidth overflow

Evan Quan (1):
  drm/amd/pm: typo fix (CUSTOM -> COMPUTE)

Felix Kuehling (1):
  drm/amdkfd: Fix leak in dmabuf import

Stanley.Yang (1):
  drm/amdgpu: fix sdma instance fw version and feature version init

Sung Lee (1):
  drm/amd/display: Add wm table for Renoir

 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  41 
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c|   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  13 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h|   6 --
 drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c |   2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   2 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   9 +-
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c  |  93 ++-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |   7 +-
 drivers/gpu/drm/amd/pm/inc/smu10.h |  14 ++-
 .../drm/amd/pm/powerplay/hwmgr/processpptables.c   | 103 -
 .../gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c   |   9 +-
 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c|   2 +-
 14 files changed, 250 insertions(+), 62 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/6] dt-bindings: display: add Unisoc's drm master bindings

[Rob Herring]

On Mon, 07 Dec 2020 22:50:21 +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
> 
> Unisoc's display pipeline have several components as below
> description, multi display controllers and corresponding physical interfaces.
> For different display scenarios, dpu0 and dpu1 maybe binding to
> different encoder.
> 
> E.g:
>   dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
>   dpu0 binding to DSI for primary display, and dpu1 binding to DP for 
> external display;
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../display/sprd/sprd,display-subsystem.yaml   | 64 
> ++
>  1 file changed, 64 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 3/8] dt-bindings: display: simple: Add Kyocera tcg070wvlq panel

[Rob Herring]

On Mon, 07 Dec 2020 15:09:34 +0100, Oleksij Rempel wrote:
> So far, this panel seems to be compatible with "lg,lb070wv8", on other
> hand it is better to set this compatible in the devicetree. So, let's
> add it for now only to the dt-binding documentation to fix the
> checkpatch warnings.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 2/8] dt-bindings: display: simple: add EDT compatibles already supported by the driver

[Rob Herring]

On Mon, 07 Dec 2020 15:09:33 +0100, Oleksij Rempel wrote:
> Some EDT compatibles are already supported by the driver but will fail
> on checkpatch script. Fix it by syncing dt-bindings documentation with the
> driver.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml| 3 +++
>  1 file changed, 3 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 1/8] dt-bindings: display: simple: fix alphabetical order for EDT compatibles

[Rob Herring]

On Mon, 07 Dec 2020 15:09:32 +0100, Oleksij Rempel wrote:
> Reorder it alphabetically and remove one double entry.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../bindings/display/panel/panel-simple.yaml   | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/5] dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi

[Rob Herring]

On Sun, 06 Dec 2020 14:33:51 +0100, Johan Jonker wrote:
> '#sound-dai-cells' is required to properly interpret
> the list of DAI specified in the 'sound-dai' property.
> Add it to rockchip,rk3066-hdmi.yaml to document that the
> rk3066 HDMI TX also can be used to transmit some audio.
> 
> Signed-off-by: Johan Jonker 
> ---
>  .../devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml| 4 
> 
>  1 file changed, 4 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm/scheduler: Job timeout handler returns status (v2)

[Luben Tuikov]

This patch does not change current behaviour.

The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.

Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.

All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.

In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.

A more involved driver's solutions can be had
in subequent patches.

v2: Use enum as the status of a driver's job
timeout callback method.

Cc: Alexander Deucher 
Cc: Andrey Grodzovsky 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: Qiang Yu 
Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Cc: Alyssa Rosenzweig 
Cc: Eric Anholt 
Reported-by: kernel test robot 
Signed-off-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  6 +++--
 drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
 drivers/gpu/drm/lima/lima_sched.c   |  4 +++-
 drivers/gpu/drm/panfrost/panfrost_job.c |  9 ---
 drivers/gpu/drm/scheduler/sched_main.c  |  4 +---
 drivers/gpu/drm/v3d/v3d_sched.c | 32 +
 include/drm/gpu_scheduler.h | 20 +---
 7 files changed, 57 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
 {
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) 
{
DRM_ERROR("ring %s timeout, but soft recovered\n",
  s_job->sched->name);
-   return;
+   return DRM_TASK_STATUS_ALIVE;
}
 
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
 
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+   return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+   return DRM_TASK_STATUS_ALIVE;
}
 }
 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct 
drm_sched_job *sched_job)
return fence;
 }
 
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct drm_sched_job
+  *sched_job)
 {
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *gpu = submit->gpu;
@@ -120,9 +121,16 @@ static void etnaviv_sched_timedout_job(struct 
drm_sched_job *sched_job)
 
drm_sched_resubmit_jobs(&gpu->sched);
 
+   /* Tell the DRM scheduler that this task needs
+* more time.
+*/
+   drm_sched_start(&gpu->sched, true);
+   return DRM_TASK_STATUS_ALIVE;
+
 out_no_timeout:
/* restart scheduler after GPU is usable again */
drm_sched_start(&gpu->sched, true);
+   return DRM_TASK_STATUS_ALIVE;
 }
 
 static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 63b4c5643f9c..66d9236b8760 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -415,7 +415,7 @@ static void lima_sched_build_error_task_list(struct 
lima_sched_task *task)
mutex_unlock(&dev->error_task_list_lock);
 }
 
-static v

[PATCH 0/1] Timeout handler now returns a value

[Luben Tuikov]

The driver's timeout handler now returns a value back up to DRM.

This patch doesn't change current behaviour. I request it'd be applied
so that Andrey G. can take advantage of the value sent back up to DRM
from the GPU driver.

I'm still working on the last patch which takes advantage of this
patch, and as such they are separate works.

This patch can be applied safely without changing the current DRM
behaviour.

Luben Tuikov (1):
  drm/scheduler: Job timeout handler returns status (v2)

 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  6 +++--
 drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
 drivers/gpu/drm/lima/lima_sched.c   |  4 +++-
 drivers/gpu/drm/panfrost/panfrost_job.c |  9 ---
 drivers/gpu/drm/scheduler/sched_main.c  |  4 +---
 drivers/gpu/drm/v3d/v3d_sched.c | 32 +
 include/drm/gpu_scheduler.h | 20 +---
 7 files changed, 57 insertions(+), 28 deletions(-)

-- 
2.29.2.404.ge67fbf927d

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement the pwm_chip

[Shawn Guo]

On Mon, Dec 07, 2020 at 10:40:22PM -0600, Bjorn Andersson wrote:
> The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> with the primary purpose of controlling the backlight of the attached
> panel. Add an implementation that exposes this using the standard PWM
> framework, to allow e.g. pwm-backlight to expose this to the user.
> 
> Special thanks to Doug Anderson for suggestions related to the involved
> math.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 202 ++
>  1 file changed, 202 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f27306c51e4d..43c0acba57ab 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -4,6 +4,7 @@
>   * datasheet: https://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -14,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -89,6 +91,11 @@
>  #define SN_ML_TX_MODE_REG0x96
>  #define  ML_TX_MAIN_LINK_OFF 0
>  #define  ML_TX_NORMAL_MODE   BIT(0)
> +#define SN_PWM_PRE_DIV_REG   0xA0
> +#define SN_BACKLIGHT_SCALE_REG   0xA1
> +#define  BACKLIGHT_SCALE_MAX 0x
> +#define SN_BACKLIGHT_REG 0xA3
> +#define SN_PWM_EN_INV_REG0xA5
>  #define SN_AUX_CMD_STATUS_REG0xF4
>  #define  AUX_IRQ_STATUS_AUX_RPLY_TOUTBIT(3)
>  #define  AUX_IRQ_STATUS_AUX_SHORTBIT(5)
> @@ -111,6 +118,8 @@
>  
>  #define SN_LINK_TRAINING_TRIES   10
>  
> +#define SN_PWM_GPIO  3

So this maps to the GPIO4 described in sn65dsi86 datasheet.  I'm
wondering if it's more readable to define the following SHIFT constants
(your code), and use GPIO_MUX_GPIO4_SHIFT >> 2 where you need GPIO
offset?

#define  GPIO_MUX_GPIO1_SHIFT   0
#define  GPIO_MUX_GPIO2_SHIFT   2
#define  GPIO_MUX_GPIO3_SHIFT   4
#define  GPIO_MUX_GPIO4_SHIFT   6

If you agree, you may consider to integrate this patch beforehand:

https://github.com/shawnguo2/linux/commit/7cde887ffb3b27a36e77a08bee3666d14968b586


Shawn

> +
>  /**
>   * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
>   * @dev:  Pointer to our device.
> @@ -162,6 +171,12 @@ struct ti_sn_bridge {
>   struct gpio_chipgchip;
>   DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
>  #endif
> +#if defined(CONFIG_PWM)
> + struct pwm_chip pchip;
> + boolpwm_enabled;
> + unsigned intpwm_refclk;
> + atomic_tpwm_pin_busy;
> +#endif
>  };
>  
>  static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> @@ -499,6 +514,14 @@ static void ti_sn_bridge_set_refclk_freq(struct 
> ti_sn_bridge *pdata)
>  
>   regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
>  REFCLK_FREQ(i));
> +
> +#if defined(CONFIG_PWM)
> + /*
> +  * The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
> +  * regardless of its actual sourcing.
> +  */
> + pdata->pwm_refclk = ti_sn_bridge_refclk_lut[i];
> +#endif
>  }
>  
>  static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge *pdata)
> @@ -981,6 +1004,161 @@ static int ti_sn_bridge_parse_dsi_host(struct 
> ti_sn_bridge *pdata)
>   return 0;
>  }
>  
> +#if defined(CONFIG_PWM)
> +static int ti_sn_pwm_pin_request(struct ti_sn_bridge *pdata)
> +{
> + return atomic_xchg(&pdata->pwm_pin_busy, 1) ? -EBUSY : 0;
> +}
> +
> +static void ti_sn_pwm_pin_release(struct ti_sn_bridge *pdata)
> +{
> + atomic_set(&pdata->pwm_pin_busy, 0);
> +}
> +
> +static struct ti_sn_bridge *
> +pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct ti_sn_bridge, pchip);
> +}
> +
> +static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
> +
> + return ti_sn_pwm_pin_request(pdata);
> +}
> +
> +static void ti_sn_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
> +
> + ti_sn_pwm_pin_release(pdata);
> +}
> +
> +static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> +const struct pwm_state *state)
> +{
> + struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
> + unsigned int pwm_en_inv;
> + unsigned int backlight;
> + unsigned int pwm_freq;
> + unsigned int pre_div;
> + unsigned int scale;
> + int ret;
> +
> + if (!pdata->pwm_enabled) {
> + ret = pm_runtime_get_sync(pdata->dev);
> + if (ret < 0)
> + retu

[RFC 5/5] drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau

[Lyude Paul]

This adds support for controlling panel backlights over eDP using VESA's
standard backlight control interface. Luckily, Nvidia was cool enough to
never come up with their own proprietary backlight control interface (at
least, not any that I or the laptop manufacturers I've talked to are aware
of), so this should work for any laptop panels which support the VESA
backlight control interface.

Note that we don't yet provide the panel backlight frequency to the DRM DP
backlight helpers. This should be fine for the time being, since it's not
required to get basic backlight controls working.

For reference: there's some mentions of PWM backlight values in
nouveau_reg.h, but I'm not sure these are the values we would want to use.
If we figure out how to get this information in the future, we'll have the
benefit of more granular backlight control.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  30 +++-
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 166 ++--
 drivers/gpu/drm/nouveau/nouveau_connector.h |   9 +-
 drivers/gpu/drm/nouveau/nouveau_encoder.h   |   1 +
 4 files changed, 187 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 33fff388dd83..fbc1665afc68 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1615,23 +1616,38 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8 
head,
core->func->sor->ctrl(core, nv_encoder->or, nv_encoder->ctrl, asyh);
 }
 
+/* TODO: Should we extend this to PWM-only backlights?
+ * As well, should we add a DRM helper for waiting for the backlight to 
acknowledge
+ * the panel backlight has been shut off? Intel doesn't seem to do this, and 
uses a
+ * fixed time delay from the vbios…
+ */
 static void
 nv50_sor_disable(struct drm_encoder *encoder,
 struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
+   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(nv_encoder, state);
+   int ret;
 
nv_encoder->crtc = NULL;
 
if (nv_crtc) {
struct drm_dp_aux *aux = &nv_connector->aux;
+   struct nouveau_backlight *backlight = nv_connector->backlight;
u8 pwr;
 
+   if (backlight && backlight->uses_dpcd) {
+   ret = drm_edp_backlight_disable(aux, 
&backlight->edp_info);
+   if (ret < 0)
+   NV_ERROR(drm, "Failed to disable backlight on 
[CONNECTOR:%d:%s]: %d\n",
+nv_connector->base.base.id, 
nv_connector->base.name, ret);
+   }
+
if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
-   int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
+   ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, &pwr);
 
if (ret == 0) {
pwr &= ~DP_SET_POWER_MASK;
@@ -1667,6 +1683,9 @@ nv50_sor_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
struct drm_device *dev = encoder->dev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_connector *nv_connector;
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+   struct nouveau_backlight *backlight;
+#endif
struct nvbios *bios = &drm->vbios;
bool hda = false;
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
@@ -1741,6 +1760,14 @@ nv50_sor_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
proto = NV887D_SOR_SET_CONTROL_PROTOCOL_DP_B;
 
nv50_audio_enable(encoder, state, mode);
+
+#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
+   backlight = nv_connector->backlight;
+   if (backlight && backlight->uses_dpcd)
+   drm_edp_backlight_enable(&nv_connector->aux, 
&backlight->edp_info,
+
(u16)backlight->dev->props.brightness);
+#endif
+
break;
default:
BUG();
@@ -2263,6 +2290,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state 
*state)
nv50_crc_atomic_start_reporting(state);
if (!flushed)
nv50_crc_atomic_release_notifier_contexts(state);
+
drm_atomic_helper_commit_hw_done(state);
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_helper_commit_cleanup_done(state);
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 4acc5be5e9aa..be1669e60

[RFC 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers

[Lyude Paul]

Since we're about to implement eDP backlight support in nouveau using the
standard protocol from VESA, we might as well just take the code that's
already written for this and move it into a set of shared DRM helpers.

Note that these helpers are intended to handle DPCD related backlight
control bits such as setting the brightness level over AUX, probing the
backlight's TCON, enabling/disabling the backlight over AUX if supported,
etc. Any PWM-related portions of backlight control are explicitly left up
to the driver, as these will vary from platform to platform.

The only exception to this is the calculation of the PWM frequency
pre-divider value. This is because the only platform-specific information
required for this is the PWM frequency of the panel, which the driver is
expected to provide if available. The actual algorithm for calculating this
value is standard and is defined in the eDP specification from VESA.

Note that these helpers do not yet implement the full range of features
the VESA backlight interface provides, and only provide the following
functionality (all of which was already present in i915's DPCD backlight
support):

* Basic control of brightness levels
* Basic probing of backlight capabilities
* Helpers for enabling and disabling the backlight

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/drm_dp_helper.c   | 332 ++
 .../drm/i915/display/intel_display_types.h|   5 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 304 ++--
 include/drm/drm_dp_helper.h   |  48 +++
 4 files changed, 419 insertions(+), 270 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..06fdddf44e54 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,335 @@ void drm_dp_vsc_sdp_log(const char *level, struct 
device *dev,
 #undef DP_SDP_LOG
 }
 EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel via 
AUX
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The brightness level to set
+ *
+ * Sets the brightness level of an eDP panel's backlight. Note that the 
panel's backlight must
+ * already have been enabled by the driver by calling 
drm_edp_backlight_enable().
+ *
+ * Returns: %0 on success, negative error code on failure
+ */
+int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct 
drm_edp_backlight_info *bl,
+   u16 level)
+{
+   int ret;
+   u8 buf[2] = { 0 };
+
+   if (bl->lsb_reg_used) {
+   buf[0] = (level & 0xFF00) >> 8;
+   buf[1] = (level & 0x00FF);
+   } else {
+   buf[0] = level;
+   }
+
+   ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf, 
sizeof(buf));
+   if (ret != sizeof(buf)) {
+   DRM_ERROR("%s: Failed to write aux backlight level: %d\n", 
aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_edp_backlight_set_level);
+
+static int
+drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct 
drm_edp_backlight_info *bl,
+bool enable)
+{
+   int ret;
+   u8 buf;
+
+   /* The panel uses something other then DPCD for enabling it's backlight 
*/
+   if (!bl->aux_enable)
+   return 0;
+
+   ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to read eDP display control register: 
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+   if (enable)
+   buf |= DP_EDP_BACKLIGHT_ENABLE;
+   else
+   buf &= ~DP_EDP_BACKLIGHT_ENABLE;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
+   if (ret != 1) {
+   DRM_ERROR("%s: Failed to write eDP display control register: 
%d\n", aux->name, ret);
+   return ret < 0 ? ret : -EIO;
+   }
+
+   return 0;
+}
+
+/**
+ * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
+ * @aux: The DP AUX channel to use
+ * @bl: Backlight capability info from drm_edp_backlight_init()
+ * @level: The initial backlight level to set via AUX, if there is one
+ *
+ * This function handles enabling DPCD backlight controls on a panel over 
DPCD, while additionally
+ * restoring any important backlight state such as the given backlight level, 
the brightness byte
+ * count, backlight frequency, etc.
+ *
+ * Note that certain panels, while supporting brightness level controls over 
DPCD, may not support
+ * having their backlights enabled via the standard 
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
+ * &drm_edp_backlight_info.aux_enable will be set to %false,

[RFC 3/5] drm/i915/dp: Remove redundant AUX backlight frequency calculations

[Lyude Paul]

Noticed this while moving all of the VESA backlight code in i915 over to
DRM helpers: it would appear that we calculate the frequency value we want
to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
actually changes during runtime. So, let's simplify things by just caching
this value in intel_panel.backlight, and re-writing it as-needed.

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 .../drm/i915/display/intel_display_types.h|  1 +
 .../drm/i915/display/intel_dp_aux_backlight.c | 64 ++-
 2 files changed, 19 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..133c9cb742a7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -259,6 +259,7 @@ struct intel_panel {
 
/* DPCD backlight */
u8 pwmgen_bit_count;
+   u8 pwm_freq_pre_divider;
 
struct backlight_device *device;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 4fd536801b14..94ce5ca1affa 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -129,50 +129,6 @@ intel_dp_aux_set_backlight(const struct 
drm_connector_state *conn_state, u32 lev
}
 }
 
-/*
- * Set PWM Frequency divider to match desired frequency in vbt.
- * The PWM Frequency is calculated as 27Mhz / (F x P).
- * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
- * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
- * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
- * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
- */
-static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
-{
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-   struct intel_dp *intel_dp = intel_attached_dp(connector);
-   const u8 pn = connector->panel.backlight.pwmgen_bit_count;
-   int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
-
-   freq = dev_priv->vbt.backlight.pwm_freq_hz;
-   if (!freq) {
-   drm_dbg_kms(&dev_priv->drm,
-   "Use panel default backlight frequency\n");
-   return false;
-   }
-
-   fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
-   f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
-   fxp_actual = f << pn;
-
-   /* Ensure frequency is within 25% of desired value */
-   fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
-   fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-
-   if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
-   drm_dbg_kms(&dev_priv->drm, "Actual frequency out of range\n");
-   return false;
-   }
-
-   if (drm_dp_dpcd_writeb(&intel_dp->aux,
-  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
-   drm_dbg_kms(&dev_priv->drm,
-   "Failed to write aux backlight freq\n");
-   return false;
-   }
-   return true;
-}
-
 static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
*crtc_state,
  const struct drm_connector_state 
*conn_state)
 {
@@ -213,9 +169,13 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
break;
}
 
-   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
-   if (intel_dp_aux_set_pwm_freq(connector))
+   if (panel->backlight.pwm_freq_pre_divider) {
+   if (drm_dp_dpcd_writeb(&intel_dp->aux, 
DP_EDP_BACKLIGHT_FREQ_SET,
+  panel->backlight.pwm_freq_pre_divider) 
== 1)
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+   else
+   drm_dbg_kms(&i915->drm, "Failed to write aux backlight 
frequency\n");
+   }
 
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
@@ -236,6 +196,14 @@ static void intel_dp_aux_disable_backlight(const struct 
drm_connector_state *old
 false);
 }
 
+/*
+ * Compute PWM frequency divider value based off the frequency provided to us 
by the vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
 static u32 intel_dp_aux_calc_max_backlight(struct intel_connector *connector)
 {
struct drm_i915_pr

[RFC 2/5] drm/nouveau/kms: Don't probe eDP connectors more then once

[Lyude Paul]

eDP doesn't do hotplugging, so there's no reason for us to reprobe it (unless a
connection status change is being forced, of course).

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..398fee9b7ae9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -554,6 +554,12 @@ nouveau_connector_detect(struct drm_connector *connector, 
bool force)
int ret;
enum drm_connector_status conn_status = connector_status_disconnected;
 
+   /* eDP doesn't do hotplugging, never probe more then once */
+   if (nv_connector->type == DCB_CONNECTOR_eDP &&
+   connector->force == DRM_FORCE_UNSPECIFIED &&
+   connector->status != connector_status_unknown)
+   return connector->status;
+
/* Outputs are only polled while runtime active, so resuming the
 * device here is unnecessary (and would deadlock upon runtime suspend
 * because it waits for polling to finish). We do however, want to
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 1/5] drm/nouveau/kms/nv40-/backlight: Assign prop type once

[Lyude Paul]

Signed-off-by: Lyude Paul 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index c7a94c94dbf3..4acc5be5e9aa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -106,7 +106,6 @@ nv40_backlight_init(struct nouveau_encoder *encoder,
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return -ENODEV;
 
-   props->type = BACKLIGHT_RAW;
props->max_brightness = 31;
*ops = &nv40_bl_ops;
return 0;
@@ -212,7 +211,6 @@ nv50_backlight_init(struct nouveau_encoder *nv_encoder,
else
*ops = &nva3_bl_ops;
 
-   props->type = BACKLIGHT_RAW;
props->max_brightness = 100;
 
return 0;
@@ -226,7 +224,7 @@ nouveau_backlight_init(struct drm_connector *connector)
struct nouveau_encoder *nv_encoder = NULL;
struct nvif_device *device = &drm->client.device;
char backlight_name[BL_NAME_SIZE];
-   struct backlight_properties props = {0};
+   struct backlight_properties props = { .type = BACKLIGHT_RAW, 0 };
const struct backlight_ops *ops;
int ret;
 
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/5] drm: Extract DPCD backlight helpers from i915, add support in nouveau

[Lyude Paul]

This series:
* Cleans up i915's DPCD backlight code a little bit
* Extracts i915's DPCD backlight code into a set of shared DRM helpers
* Starts using those helpers in nouveau to add support to nouveau for
  DPCD backlight control

Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: greg.depo...@gmail.com

Lyude Paul (5):
  drm/nouveau/kms/nv40-/backlight: Assign prop type once
  drm/nouveau/kms: Don't probe eDP connectors more then once
  drm/i915/dp: Remove redundant AUX backlight frequency calculations
  drm/dp: Extract i915's eDP backlight code into DRM helpers
  drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau

 drivers/gpu/drm/drm_dp_helper.c   | 332 ++
 .../drm/i915/display/intel_display_types.h|   4 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 332 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c   |  30 +-
 drivers/gpu/drm/nouveau/nouveau_backlight.c   | 170 +++--
 drivers/gpu/drm/nouveau/nouveau_connector.c   |   6 +
 drivers/gpu/drm/nouveau/nouveau_connector.h   |   9 +-
 drivers/gpu/drm/nouveau/nouveau_encoder.h |   1 +
 include/drm/drm_dp_helper.h   |  48 +++
 9 files changed, 613 insertions(+), 319 deletions(-)

-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/display/tc: Only WARN once for bogus tc port flag

[Rodrigo Vivi]

On Wed, Dec 09, 2020 at 04:16:36PM -0500, Sean Paul wrote:
> From: Sean Paul 
> 
> No need to spam syslog/console when we can ignore/fix the flag.

besides that we are calling from multiple places anyway..

> 
> Signed-off-by: Sean Paul 


Reviewed-by: Rodrigo Vivi 



> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 4346bc1a747a..27dc2dad6809 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -262,7 +262,7 @@ static u32 tc_port_live_status_mask(struct 
> intel_digital_port *dig_port)
>   mask |= BIT(TC_PORT_LEGACY);
>  
>   /* The sink can be connected only in a single mode. */
> - if (!drm_WARN_ON(&i915->drm, hweight32(mask) > 1))
> + if (!drm_WARN_ON_ONCE(&i915->drm, hweight32(mask) > 1))
>   tc_port_fixup_legacy_flag(dig_port, mask);
>  
>   return mask;
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave and Daniel,

The commit 7c5c15dffe1e ("drm/i915/gt: Declare gen9 has 64 mocs entries!")
should actually be sent last week along with the commit
777a7717d60c ("drm/i915/gt: Program mocs:63 for cache eviction on gen9"),
but I had missed that and dim didn't cope with fixes for fixes.

Here goes drm-intel-fixes-2020-12-09:

Fixes for VDSC/DP, selftests, shmem_utils, preemption, submission, and gt reset:

- Check the correct variable in selftest (Dan)
- Propagate error from canceled submit due to context closure (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Cancel the preemption timeout on responding to it (Chris)
- Fix unsigned compared against 0 (Colin)
- Compute the correct slice count for VDSC on DP (Manasi)
- Declar gen9 has 64 mocs entries (Chris)

Thanks,
Rodrigo.

The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f:

  Linux 5.10-rc7 (2020-12-06 14:25:12 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-12-09

for you to fetch changes up to 7c5c15dffe1e3c42f44735ce9552afb7207f1584:

  drm/i915/gt: Declare gen9 has 64 mocs entries! (2020-12-08 07:09:58 -0800)


Fixes for VDSC/DP, selftests, shmem_utils, preemption, submission, and gt reset:

- Check the correct variable in selftest (Dan)
- Propagate error from canceled submit due to context closure (Chris)
- Ignore repeated attempts to suspend request flow across reset (Chris)
- Cancel the preemption timeout on responding to it (Chris)
- Fix unsigned compared against 0 (Colin)
- Compute the correct slice count for VDSC on DP (Manasi)
- Declar gen9 has 64 mocs entries (Chris)


Chris Wilson (4):
  drm/i915/gem: Propagate error from cancelled submit due to context closure
  drm/i915/gt: Ignore repeated attempts to suspend request flow across reset
  drm/i915/gt: Cancel the preemption timeout on responding to it
  drm/i915/gt: Declare gen9 has 64 mocs entries!

Colin Ian King (1):
  drm/i915: fix size_t greater or equal to zero comparison

Dan Carpenter (1):
  drm/i915/gem: Check the correct variable in selftest

Manasi Navare (1):
  drm/i915/display/dp: Compute the correct slice count for VDSC on DP

 drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +--
 drivers/gpu/drm/i915/gt/intel_lrc.c| 7 ++-
 drivers/gpu/drm/i915/gt/intel_mocs.c   | 7 +++
 drivers/gpu/drm/i915/gt/shmem_utils.c  | 2 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c  | 4 ++--
 6 files changed, 18 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sched: Add missing structure comment

[Luben Tuikov]

Add a missing structure comment for the recently
added @list member.

Cc: Stephen Rothwell 
Cc: Daniel Vetter 
Cc: Christian König 
Fixes:  8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
Reported-by: Stephen Rothwell 
Signed-off-by: Luben Tuikov 
---
 include/drm/gpu_scheduler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 2e0c368e19f6..975e8a67947f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -171,10 +171,10 @@ struct drm_sched_fence *to_drm_sched_fence(struct 
dma_fence *f);
  * struct drm_sched_job - A job to be run by an entity.
  *
  * @queue_node: used to append this struct to the queue of jobs in an entity.
+ * @list: a job participates in a "pending" and "done" lists.
  * @sched: the scheduler instance on which this job is scheduled.
  * @s_fence: contains the fences for the scheduling of job.
  * @finish_cb: the callback for the finished fence.
- * @node: used to append this struct to the @drm_gpu_scheduler.pending_list.
  * @id: a unique id assigned to each job scheduled on the scheduler.
  * @karma: increment on every hang caused by this job. If this exceeds the hang
  * limit of the scheduler then the job is marked guilty and will not
-- 
2.29.2.404.ge67fbf927d

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sched: Add missing structure comment

[Luben Tuikov]

On 2020-12-09 5:24 p.m., Stephen Rothwell wrote:
> Hi Luben,
> 
> On Wed,  9 Dec 2020 16:58:07 -0500 Luben Tuikov  wrote:
>>
>> Add a missing structure comment for the recently
>> added @list member.
>>
>> Signed-off-by: Luben Tuikov 
>>
>> Cc: Stephen Rothwell 
>> Cc: Daniel Vetter 
>> Cc: Christian König 
> 
> The commit message tags should all be together at the end of the commit
> message (probably with your SoB last).  Also:
> 
> Fixes:  8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
> Reported-by: Stephen Rothwell 

Right! I was just looking into this as the empty
line up there didn't look good.

I'll resubmit.

Regards,
Luben
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sched: Add missing structure comment

[Stephen Rothwell]

Hi Luben,

On Wed,  9 Dec 2020 16:58:07 -0500 Luben Tuikov  wrote:
>
> Add a missing structure comment for the recently
> added @list member.
> 
> Signed-off-by: Luben Tuikov 
> 
> Cc: Stephen Rothwell 
> Cc: Daniel Vetter 
> Cc: Christian König 

The commit message tags should all be together at the end of the commit
message (probably with your SoB last).  Also:

Fixes:  8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
Reported-by: Stephen Rothwell 

Thanks
-- 
Cheers,
Stephen Rothwell


pgpKxMuehBTcp.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/vkms: Add setup and testing information

[Daniel Vetter]

On Thu, Dec 10, 2020 at 12:34:53AM +0530, Sumera Priyadarsini wrote:
> Update the vkms documentation to contain steps to:
> 
>  - setup the vkms driver
>  - run tests using igt
> 
> Signed-off-by: Sumera Priyadarsini 
> ___
> Changes in v2:
>  - Change heading to title case (Daniel)
>  - Add examples to run tests directly (Daniel)
>  - Add examples to run subtests (Melissa)
> 
> Changes in v3:
>  - Add example using run-tests.sh script(Daniel)

Reviewed-by: Daniel Vetter 

> ---
>  Documentation/gpu/vkms.rst | 70 ++
>  1 file changed, 70 insertions(+)
> 
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 13bab1d93bb3..9e030c74a82e 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -7,6 +7,76 @@
>  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> :doc: vkms (Virtual Kernel Modesetting)
>  
> +Setup
> +=
> +
> +The VKMS driver can be setup with the following steps:
> +
> +To check if VKMS is loaded, run::
> +
> +  lsmod | grep vkms
> +
> +This should list the VKMS driver. If no output is obtained, then
> +you need to enable and/or load the VKMS driver.
> +Ensure that the VKMS driver has been set as a loadable module in your
> +kernel config file. Do::
> +
> +  make nconfig
> +
> +  Go to `Device Drivers> Graphics support`
> +
> +  Enable `Virtual KMS (EXPERIMENTAL)`
> +
> +Compile and build the kernel for the changes to get reflected.
> +Now, to load the driver, use::
> +
> +  sudo modprobe vkms
> +
> +On running the lsmod command now, the VKMS driver will appear listed.
> +You can also observe the driver being loaded in the dmesg logs.
> +
> +To disable the driver, use ::
> +
> +  sudo modprobe -r vkms
> +
> +Testing With IGT
> +
> +
> +The IGT GPU Tools is a test suite used specifically for debugging and
> +development of the DRM drivers.
> +The IGT Tools can be installed from
> +`here `_ .
> +
> +The tests need to be run without a compositor, so you need to switch to text
> +only mode. You can do this by::
> +
> +  sudo systemctl isolate multi-user.target
> +
> +To return to graphical mode, do::
> +
> +  sudo systemctl isolate graphical.target
> +
> +Once you are in text only mode, you can run tests using the --device switch
> +or IGT_DEVICE variable to specify the device filter for the driver we want
> +to test. IGT_DEVICE can also be used with the run-test.sh script to run the
> +tests for a specific driver::
> +
> +  sudo ./build/tests/ --device "sys:/sys/devices/platform/vkms"
> +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/ test>
> +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t 
> 
> +
> +For example, to test the functionality of the writeback library,
> +we can run the kms_writeback test::
> +
> +  sudo ./build/tests/kms_writeback --device "sys:/sys/devices/platform/vkms"
> +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" 
> ./build/tests/kms_writeback
> +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t 
> kms_writeback
> +
> +You can also run subtests if you do not want to run the entire test::
> +
> +  sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device 
> "sys:/sys/devices/platform/vkms"
> +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip 
> --run-subtest basic-plain-flip
> +
>  TODO
>  
>  
> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sched: Add missing structure comment

[Luben Tuikov]

Add a missing structure comment for the recently
added @list member.

Signed-off-by: Luben Tuikov 

Cc: Stephen Rothwell 
Cc: Daniel Vetter 
Cc: Christian König 
---
 include/drm/gpu_scheduler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 2e0c368e19f6..975e8a67947f 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -171,10 +171,10 @@ struct drm_sched_fence *to_drm_sched_fence(struct 
dma_fence *f);
  * struct drm_sched_job - A job to be run by an entity.
  *
  * @queue_node: used to append this struct to the queue of jobs in an entity.
+ * @list: a job participates in a "pending" and "done" lists.
  * @sched: the scheduler instance on which this job is scheduled.
  * @s_fence: contains the fences for the scheduling of job.
  * @finish_cb: the callback for the finished fence.
- * @node: used to append this struct to the @drm_gpu_scheduler.pending_list.
  * @id: a unique id assigned to each job scheduled on the scheduler.
  * @karma: increment on every hang caused by this job. If this exceeds the hang
  * limit of the scheduler then the job is marked guilty and will not
-- 
2.29.2.404.ge67fbf927d

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/display/tc: Only WARN once for bogus tc port flag

[Sean Paul]

From: Sean Paul 

No need to spam syslog/console when we can ignore/fix the flag.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 4346bc1a747a..27dc2dad6809 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -262,7 +262,7 @@ static u32 tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
mask |= BIT(TC_PORT_LEGACY);
 
/* The sink can be connected only in a single mode. */
-   if (!drm_WARN_ON(&i915->drm, hweight32(mask) > 1))
+   if (!drm_WARN_ON_ONCE(&i915->drm, hweight32(mask) > 1))
tc_port_fixup_legacy_flag(dig_port, mask);
 
return mask;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/19] drm: managed encoder/plane/crtc allocation

[Daniel Vetter]

On Wed, Dec 09, 2020 at 10:10:47PM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 04:59:16PM +0100, Philipp Zabel wrote:
> > On Tue, 2020-12-08 at 16:54 +0100, Philipp Zabel wrote:
> > > Hi,
> > > 
> > > this is an update of the drmm_(simple_)encoder_alloc(),
> > > drmm_universal_plane_alloc(), and drmm_crtc_alloc_with_plane()
> > > functions in v3 [1] together with the imx-drm managed allocation
> > > conversion from [2] as an example usage.
> > > a bit.
> >   ^^
> > this is a left-over of ", reordered an squashed a bit." before I decided
> > to move it into the list of changes below.
> > 
> > > 
> > > Changes since v3:
> > [...]
> > >  - Reorder and squash the imx-drm managed allocation conversion patches
> > >to use the new functions directly.
> 
> imx parts all look good. One thing I spotted is that you could use
> devm_drm_dev_alloc instead of drm_dev_alloc, at least my tree here doesn't
> have that one yet. Feel free to add a-b: me on top of the imx patches too,
> but probably not worth much :-)

Oh also for merging, ack for merging through whatever tree you feel like.
Since 5.11 merge window is done already if you go through imx please make
sure to send a feature pull soon after -rc1 so it's not holding up
Laurent. Or coordinate with Laurent (and maybe others).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/19] drm: managed encoder/plane/crtc allocation

[Daniel Vetter]

On Tue, Dec 08, 2020 at 04:59:16PM +0100, Philipp Zabel wrote:
> On Tue, 2020-12-08 at 16:54 +0100, Philipp Zabel wrote:
> > Hi,
> > 
> > this is an update of the drmm_(simple_)encoder_alloc(),
> > drmm_universal_plane_alloc(), and drmm_crtc_alloc_with_plane()
> > functions in v3 [1] together with the imx-drm managed allocation
> > conversion from [2] as an example usage.
> > a bit.
>   ^^
> this is a left-over of ", reordered an squashed a bit." before I decided
> to move it into the list of changes below.
> 
> > 
> > Changes since v3:
> [...]
> >  - Reorder and squash the imx-drm managed allocation conversion patches
> >to use the new functions directly.

imx parts all look good. One thing I spotted is that you could use
devm_drm_dev_alloc instead of drm_dev_alloc, at least my tree here doesn't
have that one yet. Feel free to add a-b: me on top of the imx patches too,
but probably not worth much :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 05/19] drm/crtc: add drmm_crtc_alloc_with_planes()

[Daniel Vetter]

On Tue, Dec 08, 2020 at 04:54:37PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_crtc_init_with_planes() that allocates
> and initializes a crtc and registers drm_crtc_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Laurent Pinchart 

Same bikesheds as with the others, imo important one is to point at the
new drmm_ version from the old kerneldoc. The others just make sure you
roll them out consistently (or not, if you don't like my suggestions).

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c | 116 -
>  include/drm/drm_crtc.h |  33 +++
>  2 files changed, 121 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f927976eca50..668c31332230 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -240,30 +241,12 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc 
> *crtc)
>   *
>   */
>  
> -/**
> - * drm_crtc_init_with_planes - Initialise a new CRTC object with
> - *specified primary and cursor planes.
> - * @dev: DRM device
> - * @crtc: CRTC object to init
> - * @primary: Primary plane for CRTC
> - * @cursor: Cursor plane for CRTC
> - * @funcs: callbacks for the new CRTC
> - * @name: printf style format string for the CRTC name, or NULL for default 
> name
> - *
> - * Inits a new object created as base part of a driver crtc object. Drivers
> - * should use this function instead of drm_crtc_init(), which is only 
> provided
> - * for backwards compatibility with drivers which do not yet support 
> universal
> - * planes). For really simple hardware which has only 1 plane look at
> - * drm_simple_display_pipe_init() instead.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> -   struct drm_plane *primary,
> -   struct drm_plane *cursor,
> -   const struct drm_crtc_funcs *funcs,
> -   const char *name, ...)
> +__printf(6, 0)
> +static int __drm_crtc_init_with_planes(struct drm_device *dev, struct 
> drm_crtc *crtc,
> +struct drm_plane *primary,
> +struct drm_plane *cursor,
> +const struct drm_crtc_funcs *funcs,
> +const char *name, va_list ap)
>  {
>   struct drm_mode_config *config = &dev->mode_config;
>   int ret;
> @@ -291,11 +274,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   return ret;
>  
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   crtc->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",
>  drm_num_crtcs(dev));
> @@ -339,8 +318,89 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>  
>   return 0;
>  }
> +
> +/**
> + * drm_crtc_init_with_planes - Initialise a new CRTC object with
> + *specified primary and cursor planes.
> + * @dev: DRM device
> + * @crtc: CRTC object to init
> + * @primary: Primary plane for CRTC
> + * @cursor: Cursor plane for CRTC
> + * @funcs: callbacks for the new CRTC
> + * @name: printf style format string for the CRTC name, or NULL for default 
> name
> + *
> + * Inits a new object created as base part of a driver crtc object. Drivers
> + * should use this function instead of drm_crtc_init(), which is only 
> provided
> + * for backwards compatibility with drivers which do not yet support 
> universal
> + * planes). For really simple hardware which has only 1 plane look at
> + * drm_simple_display_pipe_init() instead.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> +   struct drm_plane *primary,
> +   struct drm_plane *cursor,
> +   const struct drm_crtc_funcs *funcs,
> +   const char *name, ...)
> +{
> + va_list ap;
> + int ret;
> +
> + va_start(ap, name);
> + ret = __drm_crtc_init_with_planes(dev, crtc, primary, cursor, funcs,
> +   name, ap);
> + va_end(ap);
> +
> + return ret;
> +}
>  EXPORT_SYMBOL(drm_crtc_init_with_planes);
>  
> +static void drmm_crtc_alloc_with_planes_cleanup(struct drm_device *dev,
> + void *ptr)
> +{
> + struct drm_crtc *crtc = ptr;
> +
> + drm_crtc_cleanup(crtc);
> +}
> +
> +void *__drmm_c

Re: [PATCH v11 01/10] dt-bindings: memory: tegra20: emc: Document opp-supported-hw property

[Rob Herring]

On Thu, 03 Dec 2020 22:24:30 +0300, Dmitry Osipenko wrote:
> Document opp-supported-hw property, which is not strictly necessary to
> have on Tegra20, but it's very convenient to have because all other SoC
> core devices will use hardware versioning, and thus, it's good to maintain
> the consistency.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 6 ++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/19] drm/plane: add drmm_universal_plane_alloc()

[Daniel Vetter]

On Tue, Dec 08, 2020 at 04:54:36PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_universal_plane_init() that allocates
> and initializes a plane and registers drm_plane_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_plane.c | 126 +++-
>  include/drm/drm_plane.h |  42 
>  2 files changed, 139 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index e6231947f987..6b1261fe09fb 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -152,31 +153,16 @@ static int create_in_format_blob(struct drm_device 
> *dev, struct drm_plane *plane
>   return 0;
>  }
>  
> -/**
> - * drm_universal_plane_init - Initialize a new universal plane object
> - * @dev: DRM device
> - * @plane: plane object to init
> - * @possible_crtcs: bitmask of possible CRTCs
> - * @funcs: callbacks for the new plane
> - * @formats: array of supported formats (DRM_FORMAT\_\*)
> - * @format_count: number of elements in @formats
> - * @format_modifiers: array of struct drm_format modifiers terminated by
> - *DRM_FORMAT_MOD_INVALID
> - * @type: type of plane (overlay, primary, cursor)
> - * @name: printf style format string for the plane name, or NULL for default 
> name
> - *
> - * Initializes a plane object of type @type.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> -  uint32_t possible_crtcs,
> -  const struct drm_plane_funcs *funcs,
> -  const uint32_t *formats, unsigned int format_count,
> -  const uint64_t *format_modifiers,
> -  enum drm_plane_type type,
> -  const char *name, ...)
> +__printf(9, 0)
> +static int __drm_universal_plane_init(struct drm_device *dev,
> +   struct drm_plane *plane,
> +   uint32_t possible_crtcs,
> +   const struct drm_plane_funcs *funcs,
> +   const uint32_t *formats,
> +   unsigned int format_count,
> +   const uint64_t *format_modifiers,
> +   enum drm_plane_type type,
> +   const char *name, va_list ap)
>  {
>   struct drm_mode_config *config = &dev->mode_config;
>   unsigned int format_modifier_count = 0;
> @@ -237,11 +223,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   }
>  
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   plane->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   plane->name = kasprintf(GFP_KERNEL, "plane-%d",
>   drm_num_planes(dev));
> @@ -286,8 +268,94 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  
>   return 0;
>  }
> +
> +/**
> + * drm_universal_plane_init - Initialize a new universal plane object
> + * @dev: DRM device
> + * @plane: plane object to init
> + * @possible_crtcs: bitmask of possible CRTCs
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (DRM_FORMAT\_\*)
> + * @format_count: number of elements in @formats
> + * @format_modifiers: array of struct drm_format modifiers terminated by
> + *DRM_FORMAT_MOD_INVALID
> + * @type: type of plane (overlay, primary, cursor)
> + * @name: printf style format string for the plane name, or NULL for default 
> name
> + *
> + * Initializes a plane object of type @type.
> + *

Same as with the others, please include a note that funcs->destroy must
clean stuff up and call kfree(), and that drivers should consider the new
drmm_ version instead.

> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
> +  uint32_t possible_crtcs,
> +  const struct drm_plane_funcs *funcs,
> +  const uint32_t *formats, unsigned int format_count,
> +  const uint64_t *format_modifiers,
> +  enum drm_plane_type type,
> +  const char *name, ...)
> +{
> + va_list ap;
> + int ret;

I think WARN_ON(!funcs.destroy); maybe.

> +
> + va_start(ap, name);
> + ret = __drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
> + 

Re: [PATCH v4 03/19] drm/simple_kms_helper: add drmm_simple_encoder_alloc()

[Daniel Vetter]

On Tue, Dec 08, 2020 at 04:54:35PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_simple_encoder_init() that allocates and
> initializes a simple encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Laurent Pinchart 
> ---
> Changes since v3:
>  - drop drmm_simple_encoder_funcs_empty, now that encoder control
>functions are optional
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c |  9 +
>  include/drm/drm_simple_kms_helper.h | 24 
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 743e57c1b44f..ccf0908eb82e 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -71,6 +72,14 @@ int drm_simple_encoder_init(struct drm_device *dev,

Please also address the FIXME in the kerneldoc for drm_simple_encoder_init
and replace it with a recommendation to use this new function you're
adding here.

>  }
>  EXPORT_SYMBOL(drm_simple_encoder_init);
>  
> +void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
> +   size_t offset, int encoder_type)
> +{
> + return __drmm_encoder_alloc(dev, size, offset, NULL, encoder_type,
> + NULL);
> +}
> +EXPORT_SYMBOL(__drmm_simple_encoder_alloc);
> +
>  static enum drm_mode_status
>  drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
>  const struct drm_display_mode *mode)
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index a026375464ff..e6dbf3161c2f 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -185,4 +185,28 @@ int drm_simple_encoder_init(struct drm_device *dev,
>   struct drm_encoder *encoder,
>   int encoder_type);
>  
> +void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size,
> +   size_t offset, int encoder_type);
> +
> +/**
> + * drmm_simple_encoder_alloc - Allocate and initialize an encoder with basic
> + * functionality.
> + * @dev: drm device
> + * @type: the type of the struct which contains struct &drm_encoder
> + * @member: the name of the &drm_encoder within @type.
> + * @encoder_type: user visible type of the encoder
> + *
> + * Allocates and initializes an encoder that has no further functionality.
> + * Settings for possible CRTC and clones are left to their initial values.
> + * Cleanup is automatically handled through registering drm_encoder_cleanup()
> + * with drmm_add_action().
> + *
> + * Returns:
> + * Pointer to new encoder, or ERR_PTR on failure.
> + */
> +#define drmm_simple_encoder_alloc(dev, type, member, encoder_type) \
> + ((type *)__drmm_simple_encoder_alloc(dev, sizeof(type), \

Same comment about container_of. Also, since this is a dummy encoder, do
we really need the subclassing support here? I guess it makes sense for
consistency at least, which is always good.

With the nits addressed:

Reviewed-by: Daniel Vetter 

> +  offsetof(type, member), \
> +  encoder_type))
> +
>  #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm/dsc, drm/dp, and /drm/i915: rc model size updates

[Daniel Vetter]

On Wed, Dec 09, 2020 at 11:34:44AM +0200, Jani Nikula wrote:
> On Tue, 08 Dec 2020, Jani Nikula  wrote:
> > For whatever reason this old series was never merged. Please let's get
> > this done.
> 
> Daniel, Maarten, may I have an ack to merge patches 1 and 4 via
> drm-intel?

Ack.
-Daniel

> 
> BR,
> Jani.
> 
> 
> >
> > For i915 DP this still needs a patch to start using the model size from
> > DPCD.
> >
> > BR,
> > Jani.
> >
> > Jani Nikula (6):
> >   drm/dsc: use rc_model_size from DSC config for PPS
> >   drm/i915/dsc: configure hardware using specified rc_model_size
> >   drm/i915/dsc: make rc_model_size an encoder defined value
> >   drm/dsc: add helper for calculating rc buffer size from DPCD
> >   drm/i915/bios: fill in DSC rc_model_size from VBT
> >   drm/i915/dsi: use VBT data for rc_model_size
> >
> >  drivers/gpu/drm/drm_dsc.c | 30 +--
> >  drivers/gpu/drm/i915/display/intel_bios.c | 11 +++--
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  8 ++
> >  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 +--
> >  include/drm/drm_dsc.h |  1 +
> >  5 files changed, 41 insertions(+), 13 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rework description of primary and cursor planes

[Daniel Vetter]

On Wed, Dec 09, 2020 at 04:35:31PM +, Simon Ser wrote:
> On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter  
> wrote:
> 
> > On Wed, 9 Dec 2020 01:42:23 +0100
> > Daniel Vetter  wrote:
> >
> > > On Sun, Dec 06, 2020 at 04:34:15PM +, Simon Ser wrote:
> > > > The previous wording could be understood by user-space evelopers as "a
> > > > primary/cursor plane is only compatible with a single CRTC" [1].
> > > >
> > > > Reword the planes description to make it clear the DRM-internal
> > > > drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
> > > >
> > > > [1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057
> > > >
> > > > Signed-off-by: Simon Ser 
> > > > Cc: Daniel Vetter 
> > > > Cc: Pekka Paalanen 
> > > > ---
> > > >  drivers/gpu/drm/drm_crtc.c  |  3 +++
> > > >  drivers/gpu/drm/drm_plane.c | 16 +---
> > > >  2 files changed, 12 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > > index 74090fc3aa55..c71b134d663a 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -256,6 +256,9 @@ struct dma_fence *drm_crtc_create_fence(struct 
> > > > drm_crtc *crtc)
> > > >   * planes). For really simple hardware which has only 1 plane look at
> > > >   * drm_simple_display_pipe_init() instead.
> > > >   *
> > > > + * The @primary and @cursor planes are only relevant for legacy uAPI, 
> > > > see
> > > > + * &drm_crtc.primary and &drm_crtc.cursor.
> > > > + *
> > > >   * Returns:
> > > >   * Zero on success, error code on failure.
> > > >   */
> > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > > index e6231947f987..7a5697bc9e04 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -49,14 +49,16 @@
> > > >   * &struct drm_plane (possibly as part of a larger structure) and 
> > > > registers it
> > > >   * with a call to drm_universal_plane_init().
> > > >   *
> > > > - * Cursor and overlay planes are optional. All drivers should provide 
> > > > one
> > > > - * primary plane per CRTC to avoid surprising userspace too much. See 
> > > > enum
> > > > - * drm_plane_type for a more in-depth discussion of these special 
> > > > uapi-relevant
> > > > - * plane types. Special planes are associated with their CRTC by 
> > > > calling
> > > > - * drm_crtc_init_with_planes().
> > > > - *
> > > >   * The type of a plane is exposed in the immutable "type" enumeration 
> > > > property,
> > > > - * which has one of the following values: "Overlay", "Primary", 
> > > > "Cursor".
> > > > + * which has one of the following values: "Overlay", "Primary", 
> > > > "Cursor" (see
> > > > + * enum drm_plane_type). A plane can be compatible with multiple 
> > > > CRTCs, see
> > > > + * &drm_plane.possible_crtcs.
> > > > + *
> > > > + * Legacy uAPI doesn't expose the primary and cursor planes directly. 
> > > > DRM core
> > > > + * relies on the driver to set the primary and optionally the cursor 
> > > > plane used
> > > > + * for legacy IOCTLs. This is done by calling 
> > > > drm_crtc_init_with_planes(). All
> > > > + * drivers should provide one primary plane per CRTC to avoid 
> > > > surprising legacy
> >
> > s/should/must/?
> 
> Unsure about this. Do we really want to WARN_ON(!crtc->primary)?

Lack of crtc->primary breaks the world: fbdev stops working, most boot
splashes and simplistic userspace stops working, the entire legacy uapi
stops working.

If the hw can at all do it, we'll require it. So I really think we should
require the MUST here (and the warning on top perhaps, or the more
elaborate validation I proposed).

> > > > + * userspace too much.
> >
> > I think it would also be useful for atomic userspace. Sure, atomic
> > userspace can be expected handle failures, but if there is not at least
> > one primary type KMS plane available for a CRTC, then userspace
> > probably never uses that CRTC which means the end user could be left
> > without an output they wanted.
> 
> The reason why I explicitly mentionned legacy user-space here is that the 
> whole
> paragraph is about the internal legacy primary/cursor pointers. I don't want 
> to
> mix in requirements for atomic user-space in here.
> 
> But yes some atomic user-space will misbehave if it finds a CRTC without any
> candidate primary plane. I guess we could add a new paragraph among those
> lines:
> 
> Each CRTC should be compatible with at least one primary plane to avoid
> surprising userspace too much.
> 
> But it's not enough, can't have a single primary plane for two CRTCs.
> 
> Each CRTC should be compatible with at least one primary plane, and there
> should be as many primary planes as there are CRTCs to avoid suprising
> userspace too much.
> 
> But it's not enough, can't have two CRTCs with the same primary plane. Well,
> I give up, it's just simpler to use Daniel's criteria.

Yeah, also with

[PATCH v3] drm/vkms: Add setup and testing information

[Sumera Priyadarsini]

Update the vkms documentation to contain steps to:

 - setup the vkms driver
 - run tests using igt

Signed-off-by: Sumera Priyadarsini 
___
Changes in v2:
 - Change heading to title case (Daniel)
 - Add examples to run tests directly (Daniel)
 - Add examples to run subtests (Melissa)

Changes in v3:
 - Add example using run-tests.sh script(Daniel)
---
 Documentation/gpu/vkms.rst | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 13bab1d93bb3..9e030c74a82e 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -7,6 +7,76 @@
 .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
:doc: vkms (Virtual Kernel Modesetting)
 
+Setup
+=
+
+The VKMS driver can be setup with the following steps:
+
+To check if VKMS is loaded, run::
+
+  lsmod | grep vkms
+
+This should list the VKMS driver. If no output is obtained, then
+you need to enable and/or load the VKMS driver.
+Ensure that the VKMS driver has been set as a loadable module in your
+kernel config file. Do::
+
+  make nconfig
+
+  Go to `Device Drivers> Graphics support`
+
+  Enable `Virtual KMS (EXPERIMENTAL)`
+
+Compile and build the kernel for the changes to get reflected.
+Now, to load the driver, use::
+
+  sudo modprobe vkms
+
+On running the lsmod command now, the VKMS driver will appear listed.
+You can also observe the driver being loaded in the dmesg logs.
+
+To disable the driver, use ::
+
+  sudo modprobe -r vkms
+
+Testing With IGT
+
+
+The IGT GPU Tools is a test suite used specifically for debugging and
+development of the DRM drivers.
+The IGT Tools can be installed from
+`here `_ .
+
+The tests need to be run without a compositor, so you need to switch to text
+only mode. You can do this by::
+
+  sudo systemctl isolate multi-user.target
+
+To return to graphical mode, do::
+
+  sudo systemctl isolate graphical.target
+
+Once you are in text only mode, you can run tests using the --device switch
+or IGT_DEVICE variable to specify the device filter for the driver we want
+to test. IGT_DEVICE can also be used with the run-test.sh script to run the
+tests for a specific driver::
+
+  sudo ./build/tests/ --device "sys:/sys/devices/platform/vkms"
+  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/
+  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t 

+
+For example, to test the functionality of the writeback library,
+we can run the kms_writeback test::
+
+  sudo ./build/tests/kms_writeback --device "sys:/sys/devices/platform/vkms"
+  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_writeback
+  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t 
kms_writeback
+
+You can also run subtests if you do not want to run the entire test::
+
+  sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device 
"sys:/sys/devices/platform/vkms"
+  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip 
--run-subtest basic-plain-flip
+
 TODO
 
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v14 4/4] RDMA/mlx5: Support dma-buf based userspace memory region

[Xiong, Jianxin]

> -Original Message-
> From: Leon Romanovsky 
> Sent: Tuesday, December 08, 2020 10:45 PM
> To: Xiong, Jianxin 
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford 
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig 
> ; Vetter, Daniel 
> Subject: Re: [PATCH v14 4/4] RDMA/mlx5: Support dma-buf based userspace 
> memory region
> 
> On Tue, Dec 08, 2020 at 02:39:15PM -0800, Jianxin Xiong wrote:
> > Implement the new driver method 'reg_user_mr_dmabuf'.  Utilize the
> > core functions to import dma-buf based memory region and update the 
> > mappings.
> >
> > Add code to handle dma-buf related page fault.
> >
> > Signed-off-by: Jianxin Xiong 
> > Reviewed-by: Sean Hefty 
> > Acked-by: Michael J. Ruhl 
> > Acked-by: Christian Koenig 
> > Acked-by: Daniel Vetter 
> > ---
> >  drivers/infiniband/hw/mlx5/main.c|   2 +
> >  drivers/infiniband/hw/mlx5/mlx5_ib.h |  18 +
> >  drivers/infiniband/hw/mlx5/mr.c  | 128 
> > +--
> >  drivers/infiniband/hw/mlx5/odp.c |  86 +--
> >  4 files changed, 225 insertions(+), 9 deletions(-)
> 
> <...>
> 
> >
> > +
> > +   umem = ib_umem_dmabuf_get(&dev->ib_dev, offset, length, fd, 
> > access_flags,
> > + &mlx5_ib_dmabuf_attach_ops);
> > +   if (IS_ERR(umem)) {
> > +   mlx5_ib_dbg(dev, "umem get failed (%ld)\n", PTR_ERR(umem));
> > +   return ERR_PTR(PTR_ERR(umem));
> 
> return ERR_CAST(umem);
> 
> > +   }
> 
> <...>
> 
> > +   dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> > +   err = ib_umem_dmabuf_map_pages(umem_dmabuf);
> > +   if (!err) {
> > +   page_size = mlx5_umem_find_best_pgsz(&umem_dmabuf->umem, mkc,
> > +log_page_size, 0,
> > +umem_dmabuf->umem.iova);
> > +   if (unlikely(page_size < PAGE_SIZE)) {
> > +   ib_umem_dmabuf_unmap_pages(umem_dmabuf);
> > +   err = -EINVAL;
> > +   } else {
> > +   err = mlx5_ib_update_mr_pas(mr, xlt_flags);
> > +   }
> > +   }
> > +   dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> 
> Let's write this section in kernel coding style, please
> 
> dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL); err = 
> ib_umem_dmabuf_map_pages(umem_dmabuf);
> if (err) {
>   dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
>   return err;
> }
> .
> 

Thanks a lot. Will fix these.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v14 4/4] RDMA/mlx5: Support dma-buf based userspace memory region

[Xiong, Jianxin]

> -Original Message-
> From: Yishai Hadas 
> Sent: Tuesday, December 08, 2020 11:13 PM
> To: Xiong, Jianxin 
> Cc: Doug Ledford ; Jason Gunthorpe ; Leon 
> Romanovsky ; Sumit Semwal
> ; Christian Koenig ; 
> Vetter, Daniel ; linux-
> r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Yishai Hadas 
> 
> Subject: Re: [PATCH v14 4/4] RDMA/mlx5: Support dma-buf based userspace 
> memory region
> 
> On 12/9/2020 12:39 AM, Jianxin Xiong wrote:
> > Implement the new driver method 'reg_user_mr_dmabuf'.  Utilize the
> > core functions to import dma-buf based memory region and update the 
> > mappings.
> >
> > Add code to handle dma-buf related page fault.
> >
> > Signed-off-by: Jianxin Xiong 
> > Reviewed-by: Sean Hefty 
> > Acked-by: Michael J. Ruhl 
> > Acked-by: Christian Koenig 
> > Acked-by: Daniel Vetter 
> > ---
> >   drivers/infiniband/hw/mlx5/main.c|   2 +
> >   drivers/infiniband/hw/mlx5/mlx5_ib.h |  18 +
> >   drivers/infiniband/hw/mlx5/mr.c  | 128 
> > +--
> >   drivers/infiniband/hw/mlx5/odp.c |  86 +--
> >   4 files changed, 225 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/main.c
> > b/drivers/infiniband/hw/mlx5/main.c
> > index 4a054eb..c025746 100644
> > --- a/drivers/infiniband/hw/mlx5/main.c
> > +++ b/drivers/infiniband/hw/mlx5/main.c
> > @@ -1,6 +1,7 @@
> >   // SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
> >   /*
> >* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights 
> > reserved.
> > + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> >*/
> >
> >   #include 
> > @@ -4069,6 +4070,7 @@ static int mlx5_ib_enable_driver(struct ib_device 
> > *dev)
> > .query_srq = mlx5_ib_query_srq,
> > .query_ucontext = mlx5_ib_query_ucontext,
> > .reg_user_mr = mlx5_ib_reg_user_mr,
> > +   .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
> > .req_notify_cq = mlx5_ib_arm_cq,
> > .rereg_user_mr = mlx5_ib_rereg_user_mr,
> > .resize_cq = mlx5_ib_resize_cq,
> > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > index 718e59f..6f4d1b4 100644
> > --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > @@ -1,6 +1,7 @@
> >   /* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
> >   /*
> >* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights 
> > reserved.
> > + * Copyright (c) 2020, Intel Corporation. All rights reserved.
> >*/
> >
> >   #ifndef MLX5_IB_H
> > @@ -704,6 +705,12 @@ static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
> >mr->umem->is_odp;
> >   }
> >
> > +static inline bool is_dmabuf_mr(struct mlx5_ib_mr *mr) {
> > +   return IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING) && mr->umem &&
> > +  mr->umem->is_dmabuf;
> > +}
> > +
> 
> 
> Didn't we agree that IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING)
> should be checked earlier
> 
> upon mlx5_ib_reg_user_mr_dmabuf () to fully prevent the functionality when 
> ODP is not supported  ? see note on previous versions.

Yes, it's now checked at the entry point of the uverbs command for registering 
dmabuf mr
 (see the following lines extracted from patch 0003 in this set). The check is 
on the device's
on-demand paging cap, which is reset when CONFIG_INFINIBAND_ON_DEMAND_PAGING
is not enabled.
 
+   if (!(pd->device->attrs.device_cap_flags & IB_DEVICE_ON_DEMAND_PAGING))
+   return -EOPNOTSUPP;

> 
> 
> >   struct mlx5_ib_mw {
> > struct ib_mwibmw;
> > struct mlx5_core_mkey   mmkey;
> > @@ -1239,6 +1246,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const 
> > struct ib_cq_init_attr *attr,
> >   struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
> >   u64 virt_addr, int access_flags,
> >   struct ib_udata *udata);
> > +struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
> > +u64 length, u64 virt_addr,
> > +int fd, int access_flags,
> > +struct ib_udata *udata);
> >   int mlx5_ib_advise_mr(struct ib_pd *pd,
> >   enum ib_uverbs_advise_mr_advice advice,
> >   u32 flags,
> > @@ -1249,11 +1260,13 @@ int mlx5_ib_advise_mr(struct ib_pd *pd,
> >   int mlx5_ib_dealloc_mw(struct ib_mw *mw);
> >   int mlx5_ib_update_xlt(struct mlx5_ib_mr *mr, u64 idx, int npages,
> >int page_shift, int flags);
> > +int mlx5_ib_update_mr_pas(struct mlx5_ib_mr *mr, unsigned int flags);
> >   struct mlx5_ib_mr *mlx5_ib_alloc_implicit_mr(struct mlx5_ib_pd *pd,
> >  struct ib_udata *udata,
> >  int access_flags);
> >   void mlx5_ib_free_implicit_mr(struct mlx5_ib_mr *mr);
> >   void mlx5_ib_fence_odp_mr(struct mlx5_ib_mr *mr);
> 

Re: [PATCH] drm/ttm: cleanup BO size handling v2

[kernel test robot]

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20201209]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-cleanup-BO-size-handling-v2/20201209-221144
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/d00372c14267d592b785c5d0c72ec167d48ade73
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/drm-ttm-cleanup-BO-size-handling-v2/20201209-221144
git checkout d00372c14267d592b785c5d0c72ec167d48ade73
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm/nouveau/nouveau_drv.h:54,
from drivers/gpu/drm/nouveau/nouveau_display.h:5,
from drivers/gpu/drm/nouveau/nouveau_fbcon.h:32,
from drivers/gpu/drm/nouveau/nouveau_display.c:38:
   drivers/gpu/drm/nouveau/nouveau_display.c: In function 
'nouveau_check_bl_size':
>> drivers/gpu/drm/nouveau/nouveau_display.c:289:16: warning: format '%lu' 
>> expects argument of type 'long unsigned int', but argument 11 has type 
>> 'size_t' {aka 'unsigned int'} [-Wformat=]
 289 |  DRM_DEBUG_KMS("offset=%u stride=%u h=%u tile_mode=0x%02x bw=%u 
bh=%u gob_size=%u bl_size=%llu size=%lu\n",
 |
^~~
 290 | offset, stride, h, tile_mode, bw, bh, gob_size, bl_size,
 291 | nvbo->bo.base.size);
 | ~~
 |  |
 |  size_t {aka unsigned int}
   include/drm/drm_print.h:510:24: note: in definition of macro 'DRM_DEBUG_KMS'
 510 |  __drm_dbg(DRM_UT_KMS, fmt, ##__VA_ARGS__)
 |^~~
   drivers/gpu/drm/nouveau/nouveau_display.c:289:103: note: format string is 
defined here
 289 |  DRM_DEBUG_KMS("offset=%u stride=%u h=%u tile_mode=0x%02x bw=%u 
bh=%u gob_size=%u bl_size=%llu size=%lu\n",
 |  
   ~~^
 |  
 |
 |  
 long unsigned int
 |  
   %u
   drivers/gpu/drm/nouveau/nouveau_display.c: In function 
'nouveau_framebuffer_new':
   drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable 'width' 
set but not used [-Wunused-but-set-variable]
 309 |  unsigned int width, height, i;
 |   ^

vim +289 drivers/gpu/drm/nouveau/nouveau_display.c

4f5746c863db1a9 James Jones 2020-02-10  259  
4f5746c863db1a9 James Jones 2020-02-10  260  static int
4f5746c863db1a9 James Jones 2020-02-10  261  nouveau_check_bl_size(struct 
nouveau_drm *drm, struct nouveau_bo *nvbo,
4f5746c863db1a9 James Jones 2020-02-10  262   uint32_t 
offset, uint32_t stride, uint32_t h,
4f5746c863db1a9 James Jones 2020-02-10  263   uint32_t 
tile_mode)
4f5746c863db1a9 James Jones 2020-02-10  264  {
4f5746c863db1a9 James Jones 2020-02-10  265 uint32_t gob_size, bw, 
bh;
4f5746c863db1a9 James Jones 2020-02-10  266 uint64_t bl_size;
4f5746c863db1a9 James Jones 2020-02-10  267  
4f5746c863db1a9 James Jones 2020-02-10  268 
BUG_ON(drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA);
4f5746c863db1a9 James Jones 2020-02-10  269  
4f5746c863db1a9 James Jones 2020-02-10  270 if 
(drm->client.device.info.chipset >= 0xc0) {
4f5746c863db1a9 James Jones 2020-02-10  271 if (

RE: [PATCH v14 1/4] RDMA/umem: Support importing dma-buf as user memory region

[Xiong, Jianxin]

> -Original Message-
> From: Leon Romanovsky 
> Sent: Tuesday, December 08, 2020 10:31 PM
> To: Xiong, Jianxin 
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford 
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig 
> ; Vetter, Daniel 
> Subject: Re: [PATCH v14 1/4] RDMA/umem: Support importing dma-buf as user 
> memory region
> 
> On Tue, Dec 08, 2020 at 02:39:12PM -0800, Jianxin Xiong wrote:
> > Dma-buf is a standard cross-driver buffer sharing mechanism that can
> > be used to support peer-to-peer access from RDMA devices.
> >
> > Device memory exported via dma-buf is associated with a file descriptor.
> > This is passed to the user space as a property associated with the
> > buffer allocation. When the buffer is registered as a memory region,
> > the file descriptor is passed to the RDMA driver along with other
> > parameters.
> >
> > Implement the common code for importing dma-buf object and mapping
> > dma-buf pages.
> >
> > Signed-off-by: Jianxin Xiong 
> > Reviewed-by: Sean Hefty 
> > Acked-by: Michael J. Ruhl 
> > Acked-by: Christian Koenig 
> > Acked-by: Daniel Vetter 
> > ---
> >  drivers/infiniband/core/Makefile  |   2 +-
> >  drivers/infiniband/core/umem.c|   3 +
> >  drivers/infiniband/core/umem_dmabuf.c | 174 
> > ++
> >  include/rdma/ib_umem.h|  47 -
> >  4 files changed, 222 insertions(+), 4 deletions(-)  create mode
> > 100644 drivers/infiniband/core/umem_dmabuf.c
> 
> <...>
> 
> > +int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) {
> > +   struct sg_table *sgt;
> > +   struct scatterlist *sg;
> > +   struct dma_fence *fence;
> > +   unsigned long start, end, cur = 0;
> > +   unsigned int nmap = 0;
> > +   int i;
> > +
> > +   dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > +
> > +   if (umem_dmabuf->sgt)
> > +   goto wait_fence;
> > +
> > +   sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
> > +   if (IS_ERR(sgt))
> > +   return PTR_ERR(sgt);
> > +
> > +   /* modify the sg list in-place to match umem address and length */
> > +
> > +   start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
> > +   end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
> > +   PAGE_SIZE);
> > +   for_each_sgtable_dma_sg(sgt, sg, i) {
> > +   if (start < cur + sg_dma_len(sg) && cur < end)
> > +   nmap++;
> > +   if (cur <= start && start < cur + sg_dma_len(sg)) {
> > +   unsigned long offset = start - cur;
> > +
> > +   umem_dmabuf->first_sg = sg;
> > +   umem_dmabuf->first_sg_offset = offset;
> > +   sg_dma_address(sg) += offset;
> > +   sg_dma_len(sg) -= offset;
> > +   cur += offset;
> > +   }
> > +   if (cur < end && end <= cur + sg_dma_len(sg)) {
> > +   unsigned long trim = cur + sg_dma_len(sg) - end;
> > +
> > +   umem_dmabuf->last_sg = sg;
> > +   umem_dmabuf->last_sg_trim = trim;
> > +   sg_dma_len(sg) -= trim;
> > +   break;
> > +   }
> > +   cur += sg_dma_len(sg);
> > +   }
> > +
> > +   umem_dmabuf->umem.sg_head.sgl = umem_dmabuf->first_sg;
> > +   umem_dmabuf->umem.sg_head.nents = nmap;
> > +   umem_dmabuf->umem.nmap = nmap;
> > +   umem_dmabuf->sgt = sgt;
> > +
> > +wait_fence:
> > +   /*
> > +* Although the sg list is valid now, the content of the pages
> > +* may be not up-to-date. Wait for the exporter to finish
> > +* the migration.
> > +*/
> > +   fence = dma_resv_get_excl(umem_dmabuf->attach->dmabuf->resv);
> > +   if (fence)
> > +   return dma_fence_wait(fence, false);
> 
> You called to dma_buf_map_attachment() earlier in this function, so if you 
> return an error here, the dma_buf won't be unmapped in
> pagefault_dmabuf_mr()

Yes, that's by design. Next time ib_unen_dmabuf_map_pages() is called, 
dma_buf_map_attachment() will be skipped and dma_fence_wait() is retried.

> 
> Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 13/20] drm/nouveau: Remove references to struct drm_device.pdev

[Jeremy Cline]

Hi,

On Tue, Dec 01, 2020 at 11:35:35AM +0100, Thomas Zimmermann wrote:
> Using struct drm_device.pdev is deprecated. Convert nouveau to struct
> drm_device.dev. No functional changes.
> 
> Signed-off-by: Thomas Zimmermann 
> Cc: Ben Skeggs 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/arb.c  | 12 +++-
>  drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
>  drivers/gpu/drm/nouveau/dispnv04/hw.c   | 10 ++
>  drivers/gpu/drm/nouveau/nouveau_abi16.c |  7 ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c  |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_bios.c  | 11 ---
>  drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 ++---
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  6 --
>  drivers/gpu/drm/nouveau/nouveau_vga.c   | 20 
>  10 files changed, 58 insertions(+), 39 deletions(-)
> 

I believe there's a use of drm_device.pdev in
drivers/gpu/drm/nouveau/dispnv04/dfp.c in the
nv04_dfp_update_backlight() function.

Other than that, this looks good to me.

> diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c 
> b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> index 9d4a2d97507e..1d3542d6006b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
> @@ -200,16 +200,17 @@ nv04_update_arb(struct drm_device *dev, int VClk, int 
> bpp,
>   int MClk = nouveau_hw_get_clock(dev, PLL_MEMORY);
>   int NVClk = nouveau_hw_get_clock(dev, PLL_CORE);
>   uint32_t cfg1 = nvif_rd32(device, NV04_PFB_CFG1);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
>  
>   sim_data.pclk_khz = VClk;
>   sim_data.mclk_khz = MClk;
>   sim_data.nvclk_khz = NVClk;
>   sim_data.bpp = bpp;
>   sim_data.two_heads = nv_two_heads(dev);
> - if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
> - (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
> + if ((pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
> + (pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
>   uint32_t type;
> - int domain = pci_domain_nr(dev->pdev->bus);
> + int domain = pci_domain_nr(pdev->bus);
>  
>   pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
> 0x7c, &type);
> @@ -251,11 +252,12 @@ void
>  nouveau_calc_arb(struct drm_device *dev, int vclk, int bpp, int *burst, int 
> *lwm)
>  {
>   struct nouveau_drm *drm = nouveau_drm(dev);
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
>  
>   if (drm->client.device.info.family < NV_DEVICE_INFO_V0_KELVIN)
>   nv04_update_arb(dev, vclk, bpp, burst, lwm);
> - else if ((dev->pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
> -  (dev->pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
> + else if ((pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
> +  (pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
>   *burst = 128;
>   *lwm = 0x0480;
>   } else
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h 
> b/drivers/gpu/drm/nouveau/dispnv04/disp.h
> index 5ace5e906949..f0a24126641a 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
> @@ -130,7 +130,7 @@ static inline bool
>  nv_two_heads(struct drm_device *dev)
>  {
>   struct nouveau_drm *drm = nouveau_drm(dev);
> - const int impl = dev->pdev->device & 0x0ff0;
> + const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
>  
>   if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_CELSIUS && impl 
> != 0x0100 &&
>   impl != 0x0150 && impl != 0x01a0 && impl != 0x0200)
> @@ -142,14 +142,14 @@ nv_two_heads(struct drm_device *dev)
>  static inline bool
>  nv_gf4_disp_arch(struct drm_device *dev)
>  {
> - return nv_two_heads(dev) && (dev->pdev->device & 0x0ff0) != 0x0110;
> + return nv_two_heads(dev) && (to_pci_dev(dev->dev)->device & 0x0ff0) != 
> 0x0110;
>  }
>  
>  static inline bool
>  nv_two_reg_pll(struct drm_device *dev)
>  {
>   struct nouveau_drm *drm = nouveau_drm(dev);
> - const int impl = dev->pdev->device & 0x0ff0;
> + const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
>  
>   if (impl == 0x0310 || impl == 0x0340 || drm->client.device.info.family 
> >= NV_DEVICE_INFO_V0_CURIE)
>   return true;
> @@ -160,9 +160,11 @@ static inline bool
>  nv_match_device(struct drm_device *dev, unsigned device,
>   unsigned sub_vendor, unsigned sub_device)
>  {
> - return dev->pdev->device == device &&
> - dev->pdev->subsystem_vendor == sub_vendor &&
> - dev->pdev->subsystem_device == sub_device;
> + struct pci_dev *pdev = to_pci_dev(dev->dev);
> +
> + return pdev->device == device &&
> + pdev->subsystem_vendor == sub_vendor &&
> + pdev->subsystem_dev

Re: [PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion

[Dan Carpenter]

Hi Ankit,

url:
https://github.com/0day-ci/linux/commits/Ankit-Nautiyal/Add-support-for-DP-HDMI2-1-PCON/20201208-160027
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-20201209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

smatch warnings:
drivers/gpu/drm/drm_dp_helper.c:3185 drm_dp_pcon_convert_rgb_to_ycbcr() warn: 
was && intended here instead of ||?

vim +3185 drivers/gpu/drm/drm_dp_helper.c

+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc)
+{
+   int ret;
+   u8 buf;
+
+   if (color_spc != DP_CONVERSION_BT601_RGB_YCBCR_ENABLE ||
+   color_spc != DP_CONVERSION_BT709_RGB_YCBCR_ENABLE ||
+   color_spc != DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE)
+   return -EINVAL;

"color_spc" cannot possibly be equal to three different values so this
function will always return -EINVAL.

+
+   ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, &buf);
+   if (ret < 0)
+   return ret;
+
+   buf |= color_spc;
+   ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}


---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: cleanup BO size handling v2

[kernel test robot]

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20201209]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-cleanup-BO-size-handling-v2/20201209-221144
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a012-20201209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/d00372c14267d592b785c5d0c72ec167d48ade73
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/drm-ttm-cleanup-BO-size-handling-v2/20201209-221144
git checkout d00372c14267d592b785c5d0c72ec167d48ade73
# save the attached .config to linux build tree
make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/ttm/ttm_bo.c: In function 'ttm_bo_mem_space_debug':
>> drivers/gpu/drm/ttm/ttm_bo.c:75:48: warning: format '%lu' expects argument 
>> of type 'long unsigned int', but argument 5 has type 'size_t' {aka 'unsigned 
>> int'} [-Wformat=]
  75 |  drm_printf(&p, "No space for %p (%lu pages, %luK, %luM)\n",
 |  ~~^
 ||
 |long unsigned int
 |  %u
  76 |  bo, bo->mem.num_pages, bo->base.size >> 10,
 | ~~~ 
 |   |
 |   size_t {aka unsigned int}
   drivers/gpu/drm/ttm/ttm_bo.c:75:54: warning: format '%lu' expects argument 
of type 'long unsigned int', but argument 6 has type 'size_t' {aka 'unsigned 
int'} [-Wformat=]
  75 |  drm_printf(&p, "No space for %p (%lu pages, %luK, %luM)\n",
 |~~^
 |  |
 |  long unsigned 
int
 |%u
  76 |  bo, bo->mem.num_pages, bo->base.size >> 10,
  77 |  bo->base.size >> 20);
 |  ~~~  
 ||
 |size_t {aka unsigned int}

vim +75 drivers/gpu/drm/ttm/ttm_bo.c

420457acfb3060 Tom St Denis2018-01-24  67  
fb53f8621a3fab Jerome Glisse   2009-12-09  68  static void 
ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
fb53f8621a3fab Jerome Glisse   2009-12-09  69   
struct ttm_placement *placement)
fb53f8621a3fab Jerome Glisse   2009-12-09  70  {
0f6be2c09af65a Michel Dänzer   2018-11-30  71   struct drm_printer p = 
drm_debug_printer(TTM_PFX);
9de59bc201496f Dave Airlie 2020-08-04  72   struct ttm_resource_manager 
*man;
48e07c23cbeba2 Christian König 2020-09-10  73   int i, mem_type;
fb53f8621a3fab Jerome Glisse   2009-12-09  74  
0f6be2c09af65a Michel Dänzer   2018-11-30 @75   drm_printf(&p, "No space for %p 
(%lu pages, %luK, %luM)\n",
d00372c14267d5 Christian König 2020-12-09  76  bo, 
bo->mem.num_pages, bo->base.size >> 10,
d00372c14267d5 Christian König 2020-12-09  77  bo->base.size >> 20);
fb53f8621a3fab Jerome Glisse   2009-12-09  78   for (i = 0; i < 
placement->num_placement; i++) {
48e07c23cbeba2 Christian König 2020-09-10  79   mem_type = 
placement->placement[i].mem_type;
0f6be2c09af65a Michel Dänzer   2018-11-30  80   drm_printf(&p, "  
placement[%d]=0x%08X (%d)\n",
f1217ed09f827e Christian König 2014-08-27  81  i, 
placement->placement[i].flags, mem_type);
9eca33f4a13919 Dave Airlie 2020-08-04  82   man = 
ttm_manager_type(bo->bdev, mem_type);
9de59bc201496f Dave Airlie 2020-08-04  83   
ttm_resource_manager_debug(man, &p);
fb53f8621a3fab Jerome Glisse   2009-12-09  84   }
fb53f8621a3fab Jerome Glisse   2009-12-09  85  }
fb53f8621a3fab Jerome Glisse   2009-12-09  86  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-intel-fixes v2

[Vivi, Rodrigo]

On Wed, 2020-12-09 at 14:11 +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2020 at 05:47:05AM -0800, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> > 
> > Please ignore the pull request I had sent yesterday and use only
> > this one.
> > 
> > I had missed one patch: 14d1eaf08845 ("drm/i915/gt: Protect context
> > lifetime with RCU").
> > 
> > Also, please notice that the commit 6db58901c2aa
> > ("drm/i915/display: return earlier from
> > +intel_modeset_init() without display") was not actually a crucial
> > fix, but it
> > +allowed a clean pick of the use-after-free one.
> > 
> > Here goes drm-intel-fixes-2020-12-03:
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > Thanks,
> > Rodrigo.
> > 
> > The following changes since commit
> > b65054597872ce3aefbc6a666385eabdf9e288da:
> > 
> >   Linux 5.10-rc6 (2020-11-29 15:50:50 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-
> > 2020-12-03
> > 
> > for you to fetch changes up to
> > ccc9e67ab26feda7e62749bb54c05d7abe07dca9:
> > 
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised (2020-12-02 17:05:58 -0800)
> > 
> > 
> > Fixes for GPU hang, null dereference, suspend-resume, power
> > consumption, and use-after-free.
> > 
> > - Program mocs:63 for cache eviction on gen9 (Chris)
> > - Protect context lifetime with RCU (Chris)
> > - Split the breadcrumb spinlock between global and contexts (Chris)
> > - Retain default context state across shrinking (Venkata)
> > - Limit frequency drop to RPe on parking (Chris)
> > - Return earlier from intel_modeset_init() without display (Jani)
> > - Defer initial modeset until after GGTT is initialized (Chris)
> > 
> > 
> > Chris Wilson (5):
> >   drm/i915/gt: Program mocs:63 for cache eviction on gen9
> 
> That also needs
> commit 444fbf5d7058 ("drm/i915/gt: Declare gen9 has 64 mocs
> entries!")
> which seems to have not made it into this pull.

yeap, I'm sorry I have missed that one.
dim doesn't deal very well with fixes for fixes and I end up missing
that.

It is now on dif and will be part of this week's pull request.

Thanks for the heads up,
Rodrigo.

> 
> >   drm/i915/gt: Protect context lifetime with RCU
> >   drm/i915/gt: Split the breadcrumb spinlock between global and
> > contexts
> >   drm/i915/gt: Limit frequency drop to RPe on parking
> >   drm/i915/display: Defer initial modeset until after GGTT is
> > initialised
> > 
> > Jani Nikula (1):
> >   drm/i915/display: return earlier from intel_modeset_init()
> > without display
> > 
> > Venkata Ramana Nayana (1):
> >   drm/i915/gt: Retain default context state across shrinking
> > 
> >  drivers/gpu/drm/i915/display/intel_display.c  |  24 ++--
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs.c   | 168
> > ++
> >  drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h |   6 +-
> >  drivers/gpu/drm/i915/gt/intel_context.c   |  15 +-
> >  drivers/gpu/drm/i915/gt/intel_context_types.h |  23 ++-
> >  drivers/gpu/drm/i915/gt/intel_mocs.c  |  14 +-
> >  drivers/gpu/drm/i915/gt/intel_rps.c   |   4 +
> >  drivers/gpu/drm/i915/gt/shmem_utils.c |   7 +-
> >  drivers/gpu/drm/i915/i915_request.h   |   6 +-
> >  9 files changed, 143 insertions(+), 124 deletions(-)
> > ___
> > dim-tools mailing list
> > dim-to...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dim-tools
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Fence wait in mmu_interval_notifier_ops::invalidate

[Intel]

On 12/9/20 5:37 PM, Jason Gunthorpe wrote:

On Wed, Dec 09, 2020 at 05:36:16PM +0100, Thomas Hellström (Intel) wrote:

Jason, Christian

In most implementations of the callback mentioned in the subject there's a
fence wait.
What exactly is it needed for?

Invalidate must stop DMA before returning, so presumably drivers using
a dma fence are relying on a dma fence mechanism to stop DMA.


Yes, so far I follow, but what's the reason drivers need to stop DMA?

Is it for invlidation before breaking COW after fork or something related?

Thanks,

Thomas



Jason

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Fence wait in mmu_interval_notifier_ops::invalidate

[Intel]

Jason, Christian

In most implementations of the callback mentioned in the subject there's 
a fence wait.

What exactly is it needed for?

Thanks,

Thomas




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tidss: Use the new api devm_drm_irq_install

[Tomi Valkeinen]

On 09/12/2020 14:08, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 1:06 PM Tomi Valkeinen  wrote:
>>
>> On 09/12/2020 13:56, Daniel Vetter wrote:
>>> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen  
>>> wrote:

 On 09/12/2020 02:48, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
>> Use devm_drm_irq_install to register interrupts so that
>> drm_irq_uninstall is not needed to be called.
>>
>> Signed-off-by: Tian Tao 
>
> There's another drm_irq_install in the error path. But I'm not sure this
> is safe since you're chaning the order in which things get cleaned up now.
> So leaving this up to Tomi.

 Right, I don't think this works. tidss irq_uninstall uses runtime_get/put, 
 which needs to happen
 before pm_runtime_disable. With devm_drm_irq_install that's not the case.
>>>
>>> Hm I don't spot devm_ versions of these, surely we're not the only
>>> ones with this problem?
>>
>> drm-misc-next has these. hisilicon uses it, but doesn't have an 
>> irq_uninstall hook, so possibly late
>> uninstall is fine there.
> 
> I meant a devm_ version of pm_runtime_enable. Or some other way to
> make this just work.

I see. No, I don't think we have.

Also, I feel a bit uncomfortable with devm'ified irq request/free. devm is fine 
for allocs and
reserving stuff, but this one affects the HW state, and your irq handler could 
get called until devm
frees the irq at some late point of time.

Well, it can be made to work, but just need to be careful. I've had my irq 
handlers getting called
too early or too late so many times that I'm a bit paranoid about it =).

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rework description of primary and cursor planes

[Simon Ser]

On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter  
wrote:

> On Wed, 9 Dec 2020 01:42:23 +0100
> Daniel Vetter  wrote:
>
> > On Sun, Dec 06, 2020 at 04:34:15PM +, Simon Ser wrote:
> > > The previous wording could be understood by user-space evelopers as "a
> > > primary/cursor plane is only compatible with a single CRTC" [1].
> > >
> > > Reword the planes description to make it clear the DRM-internal
> > > drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
> > >
> > > [1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057
> > >
> > > Signed-off-by: Simon Ser 
> > > Cc: Daniel Vetter 
> > > Cc: Pekka Paalanen 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c  |  3 +++
> > >  drivers/gpu/drm/drm_plane.c | 16 +---
> > >  2 files changed, 12 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 74090fc3aa55..c71b134d663a 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -256,6 +256,9 @@ struct dma_fence *drm_crtc_create_fence(struct 
> > > drm_crtc *crtc)
> > >   * planes). For really simple hardware which has only 1 plane look at
> > >   * drm_simple_display_pipe_init() instead.
> > >   *
> > > + * The @primary and @cursor planes are only relevant for legacy uAPI, see
> > > + * &drm_crtc.primary and &drm_crtc.cursor.
> > > + *
> > >   * Returns:
> > >   * Zero on success, error code on failure.
> > >   */
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index e6231947f987..7a5697bc9e04 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -49,14 +49,16 @@
> > >   * &struct drm_plane (possibly as part of a larger structure) and 
> > > registers it
> > >   * with a call to drm_universal_plane_init().
> > >   *
> > > - * Cursor and overlay planes are optional. All drivers should provide one
> > > - * primary plane per CRTC to avoid surprising userspace too much. See 
> > > enum
> > > - * drm_plane_type for a more in-depth discussion of these special 
> > > uapi-relevant
> > > - * plane types. Special planes are associated with their CRTC by calling
> > > - * drm_crtc_init_with_planes().
> > > - *
> > >   * The type of a plane is exposed in the immutable "type" enumeration 
> > > property,
> > > - * which has one of the following values: "Overlay", "Primary", "Cursor".
> > > + * which has one of the following values: "Overlay", "Primary", "Cursor" 
> > > (see
> > > + * enum drm_plane_type). A plane can be compatible with multiple CRTCs, 
> > > see
> > > + * &drm_plane.possible_crtcs.
> > > + *
> > > + * Legacy uAPI doesn't expose the primary and cursor planes directly. 
> > > DRM core
> > > + * relies on the driver to set the primary and optionally the cursor 
> > > plane used
> > > + * for legacy IOCTLs. This is done by calling 
> > > drm_crtc_init_with_planes(). All
> > > + * drivers should provide one primary plane per CRTC to avoid surprising 
> > > legacy
>
> s/should/must/?

Unsure about this. Do we really want to WARN_ON(!crtc->primary)?

> > > + * userspace too much.
>
> I think it would also be useful for atomic userspace. Sure, atomic
> userspace can be expected handle failures, but if there is not at least
> one primary type KMS plane available for a CRTC, then userspace
> probably never uses that CRTC which means the end user could be left
> without an output they wanted.

The reason why I explicitly mentionned legacy user-space here is that the whole
paragraph is about the internal legacy primary/cursor pointers. I don't want to
mix in requirements for atomic user-space in here.

But yes some atomic user-space will misbehave if it finds a CRTC without any
candidate primary plane. I guess we could add a new paragraph among those
lines:

Each CRTC should be compatible with at least one primary plane to avoid
surprising userspace too much.

But it's not enough, can't have a single primary plane for two CRTCs.

Each CRTC should be compatible with at least one primary plane, and there
should be as many primary planes as there are CRTCs to avoid suprising
userspace too much.

But it's not enough, can't have two CRTCs with the same primary plane. Well,
I give up, it's just simpler to use Daniel's criteria.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rework description of primary and cursor planes

[Simon Ser]

On Wednesday, December 9th, 2020 at 5:02 PM, Daniel Vetter  
wrote:

> On Wed, Dec 09, 2020 at 03:58:17PM +, Simon Ser wrote:
> > Thanks for the review!
> >
> > On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter 
> >  wrote:
> >
> > > I think maybe a follow up patch should document how userspace should
> > > figure out how to line up the primary planes with the right crtcs (if it
> > > wishes to know that information, it's not super useful aside from probably
> > > good choice for a fullscreen fallback plane). See my reply on the old
> > > thread.
> >
> > Yeah, as I've already replied, I won't volunteer to document legacy bits,
> > documenting atomic is already enough. :P
>
> This is also somewhat useful as a hint for atomic userspace.

How so? Atomic can just pick the first compatible primary plane for CRTC 1,
the first available primary plane from the rest for CRTC 2, and so on.

> > > And that patch should also add the code to drm_mode_config_validate() to
> > > validate the possible_crtc masks for these. Something like
> > >
> > >   num_primary = 0; num_cursor = 0;
> > >
> > >   for_each_plane(plane) {
> > >   if (plane->type == primary) {
> > >   WARN_ON(!(plane->possible_crtcs & BIT(num_primary)));
> > >   num_primary++;
> > >   }
> > >
> > >   /* same for cursor */
> > >   }
> > >
> > >   WARN_ON(num_primary != dev->mode_config.num_crtcs);
> > > }
> >
> > Thanks for the suggestion. However I don't see why a driver should ensure
> > this. Isn't it perfectly fine for a driver to use primary plane 2 for CRTC 
> > 1,
> > and primary plane 1 for CRTC 2, for the purposes of legacy uAPI?
>
> Yeah but it's a mess. Messes don't make good uapi.
>
> > If we're trying here to invent a new uAPI to let user-space discover the
> > internal legacy primary/cursor pointers, I'm not signing up for this. The
> > requirement you're describing seems like something current drivers ensure
> > "by chance", not an established uAPI. In other words, writing a new driver
> > that doesn't do the same wouldn't break uAPI contracts.
>
> I'm more seeing this as general uapi lock-down. "Everything goes" doesn't
> work great. And it's all the same topic really. Like if your userspace
> really doesn't care about what the primary plane is (like you seem to
> imply), then ofc none of this matters to you, but then also your doc patch
> here doesn't matter.

My patch makes it clear the "one primary plane per CRTC" requirement is just
for legacy uAPI. See the commit message.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build warning after merge of the drm-misc tree

[Luben Tuikov]

On 2020-12-09 05:02, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> include/drm/gpu_scheduler.h:201: warning: Function parameter or member 'list' 
> not described in 'drm_sched_job'
> 
> Introduced by commit
> 
>   8935ff00e3b1 ("drm/scheduler: "node" --> "list"")
> 

Thanks for the notification.

I'll send out a patch to fix this.

Regards,
Luben
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tidss: Use the new api devm_drm_irq_install

[Tomi Valkeinen]

On 09/12/2020 13:56, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 12:29 PM Tomi Valkeinen  wrote:
>>
>> On 09/12/2020 02:48, Daniel Vetter wrote:
>>> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
 Use devm_drm_irq_install to register interrupts so that
 drm_irq_uninstall is not needed to be called.

 Signed-off-by: Tian Tao 
>>>
>>> There's another drm_irq_install in the error path. But I'm not sure this
>>> is safe since you're chaning the order in which things get cleaned up now.
>>> So leaving this up to Tomi.
>>
>> Right, I don't think this works. tidss irq_uninstall uses runtime_get/put, 
>> which needs to happen
>> before pm_runtime_disable. With devm_drm_irq_install that's not the case.
> 
> Hm I don't spot devm_ versions of these, surely we're not the only
> ones with this problem?

drm-misc-next has these. hisilicon uses it, but doesn't have an irq_uninstall 
hook, so possibly late
uninstall is fine there.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 02/19] drm: add drmm_encoder_alloc()

[Daniel Vetter]

On Tue, Dec 08, 2020 at 04:54:34PM +0100, Philipp Zabel wrote:
> Add an alternative to drm_encoder_init() that allocates and initializes
> an encoder and registers drm_encoder_cleanup() with
> drmm_add_action_or_reset().
> 
> Signed-off-by: Philipp Zabel 
> Reviewed-by: Laurent Pinchart 
> ---
> Changes since v3:
>  - allow the funcs parameter to __drmm_encoder_alloc() to be NULL
> ---
>  drivers/gpu/drm/drm_encoder.c | 101 ++
>  include/drm/drm_encoder.h |  30 ++
>  2 files changed, 108 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index b0b86a3c08f5..cc0edb8361e8 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -91,25 +92,11 @@ void drm_encoder_unregister_all(struct drm_device *dev)
>   }
>  }
>  
> -/**
> - * drm_encoder_init - Init a preallocated encoder
> - * @dev: drm device
> - * @encoder: the encoder to init
> - * @funcs: callbacks for this encoder
> - * @encoder_type: user visible type of the encoder
> - * @name: printf style format string for the encoder name, or NULL for 
> default name
> - *
> - * Initialises a preallocated encoder. Encoder should be subclassed as part 
> of
> - * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> should be
> - * called from the driver's &drm_encoder_funcs.destroy hook.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int drm_encoder_init(struct drm_device *dev,
> -  struct drm_encoder *encoder,
> -  const struct drm_encoder_funcs *funcs,
> -  int encoder_type, const char *name, ...)
> +__printf(5, 0)
> +static int __drm_encoder_init(struct drm_device *dev,
> +   struct drm_encoder *encoder,
> +   const struct drm_encoder_funcs *funcs,
> +   int encoder_type, const char *name, va_list ap)
>  {
>   int ret;
>  
> @@ -125,11 +112,7 @@ int drm_encoder_init(struct drm_device *dev,
>   encoder->encoder_type = encoder_type;
>   encoder->funcs = funcs;
>   if (name) {
> - va_list ap;
> -
> - va_start(ap, name);
>   encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> - va_end(ap);
>   } else {
>   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> 
> drm_encoder_enum_list[encoder_type].name,
> @@ -150,6 +133,36 @@ int drm_encoder_init(struct drm_device *dev,
>  
>   return ret;
>  }
> +
> +/**
> + * drm_encoder_init - Init a preallocated encoder
> + * @dev: drm device
> + * @encoder: the encoder to init
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + * @name: printf style format string for the encoder name, or NULL for 
> default name
> + *
> + * Initializes a preallocated encoder. Encoder should be subclassed as part 
> of
> + * driver encoder objects. At driver unload time drm_encoder_cleanup() 
> should be
> + * called from the driver's &drm_encoder_funcs.destroy hook.

I think this should also mention that ->destroy should kfree() the encoder
structure, and it should not be allocated with devm_kzalloc.

Also a hint to use drmm_encoder_alloc instead would be good to point
people in the right direction.

> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_encoder_init(struct drm_device *dev,
> +  struct drm_encoder *encoder,
> +  const struct drm_encoder_funcs *funcs,
> +  int encoder_type, const char *name, ...)
> +{
> + va_list ap;
> + int ret;

WARN_ON(!funcs->destroy);

WARN_ON(!funcs->destroy);


> +
> + va_start(ap, name);
> + ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
> + va_end(ap);
> +
> + return ret;
> +}
>  EXPORT_SYMBOL(drm_encoder_init);
>  
>  /**
> @@ -181,6 +194,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
>  
> +static void drmm_encoder_alloc_release(struct drm_device *dev, void *ptr)
> +{
> + struct drm_encoder *encoder = ptr;
> +
> + if (WARN_ON(!encoder->dev))
> + return;
> +
> + drm_encoder_cleanup(encoder);
> +}
> +
> +void *__drmm_encoder_alloc(struct drm_device *dev, size_t size, size_t 
> offset,
> +const struct drm_encoder_funcs *funcs,
> +int encoder_type, const char *name, ...)
> +{
> + void *container;
> + struct drm_encoder *encoder;
> + va_list ap;
> + int ret;
> +
> + if (WARN_ON(funcs && funcs->destroy))
> + return ERR_PTR(-EINVAL);
> +
> + container = drmm_kzalloc(dev, size, GFP_KERNEL);
> + if (!container)
> + return ERR_PTR(

Re: [PATCH] drm: rework description of primary and cursor planes

[Daniel Vetter]

On Wed, Dec 09, 2020 at 03:58:17PM +, Simon Ser wrote:
> Thanks for the review!
> 
> On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter  
> wrote:
> 
> > I think maybe a follow up patch should document how userspace should
> > figure out how to line up the primary planes with the right crtcs (if it
> > wishes to know that information, it's not super useful aside from probably
> > good choice for a fullscreen fallback plane). See my reply on the old
> > thread.
> 
> Yeah, as I've already replied, I won't volunteer to document legacy bits,
> documenting atomic is already enough. :P

This is also somewhat useful as a hint for atomic userspace.

> > And that patch should also add the code to drm_mode_config_validate() to
> > validate the possible_crtc masks for these. Something like
> >
> > num_primary = 0; num_cursor = 0;
> >
> > for_each_plane(plane) {
> > if (plane->type == primary) {
> > WARN_ON(!(plane->possible_crtcs & BIT(num_primary)));
> > num_primary++;
> > }
> >
> > /* same for cursor */
> > }
> >
> > WARN_ON(num_primary != dev->mode_config.num_crtcs);
> > }
> 
> Thanks for the suggestion. However I don't see why a driver should ensure
> this. Isn't it perfectly fine for a driver to use primary plane 2 for CRTC 1,
> and primary plane 1 for CRTC 2, for the purposes of legacy uAPI?

Yeah but it's a mess. Messes don't make good uapi.

> If we're trying here to invent a new uAPI to let user-space discover the
> internal legacy primary/cursor pointers, I'm not signing up for this. The
> requirement you're describing seems like something current drivers ensure
> "by chance", not an established uAPI. In other words, writing a new driver
> that doesn't do the same wouldn't break uAPI contracts.

I'm more seeing this as general uapi lock-down. "Everything goes" doesn't
work great. And it's all the same topic really. Like if your userspace
really doesn't care about what the primary plane is (like you seem to
imply), then ofc none of this matters to you, but then also your doc patch
here doesn't matter.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 01/19] drm/encoder: make encoder control functions optional

[Daniel Vetter]

On Wed, Dec 09, 2020 at 04:58:05PM +0100, Daniel Vetter wrote:
> On Wed, Dec 09, 2020 at 11:58:44AM +0100, Philipp Zabel wrote:
> > Hi Sam,
> > 
> > On Tue, 2020-12-08 at 19:48 +0100, Sam Ravnborg wrote:
> > > Hi Philipp,
> > > On Tue, Dec 08, 2020 at 04:54:33PM +0100, Philipp Zabel wrote:
> > > > Simple managed encoders do not require the .destroy callback,
> > > > make the whole funcs structure optional.
> > > > 
> > > > Signed-off-by: Philipp Zabel 
> > > > Reviewed-by: Laurent Pinchart 
> > > > ---
> > > > New in v4.
> > > > ---
> > > >  drivers/gpu/drm/drm_encoder.c | 4 ++--
> > > >  drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > > >  include/drm/drm_encoder.h | 2 +-
> > > >  3 files changed, 6 insertions(+), 5 deletions(-)
> > > > 
> > [...]
> > > > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > index f1affc1bb679..87e144155456 100644
> > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > [...]
> > > > @@ -487,7 +487,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> > > >  
> > > > list_for_each_entry_safe(encoder, enct, 
> > > > &dev->mode_config.encoder_list,
> > > >  head) {
> > > > -   encoder->funcs->destroy(encoder);
> > > > +   if (encoder->funcs)
> > > > +   encoder->funcs->destroy(encoder);
> > > 
> > > So late_register and early_unregister are both optional.
> > > But if encoder->funcs is set then the destroy callback is mandatory.
> > 
> > For encoders that are kept on the mode_config.encoder_list until
> > drm_mode_config_cleanup() is called, the destroy callback is still
> > mandatory.
> > 
> > Encoders allocated with drmm_encoder_alloc() on the other hand should
> > have the destroy callback set to NULL, if encoder->funcs is set.
> > These encoders are removed from the mode_config.encoder_list by the drmm
> > cleanup code, before drm_mode_config_cleanup is called.
> > 
> > > I am just wondering if this is intended.
> > > Reding the documnetation of drm_encoder_funcs thist matches the
> > > documentation but anyway..
> > >
> > > With this comment considered,
> > > Reviewed-by: Sam Ravnborg 
> > 
> > Thank you for bringing this up, should we just leave
> > drm_mode_config_cleanup() as-is?
> 
> Yup, not having a funcs->destroy there is a bug. Maybe should even warn
> about the lack of that in the traditional non-drmm_ encoder init function.

Forgot to add: With that Reviewed-by: Daniel Vetter 

> -Daniel
> 
> > 
> > regards
> > Philipp
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: rework description of primary and cursor planes

[Simon Ser]

Thanks for the review!

On Wednesday, December 9th, 2020 at 1:42 AM, Daniel Vetter  
wrote:

> I think maybe a follow up patch should document how userspace should
> figure out how to line up the primary planes with the right crtcs (if it
> wishes to know that information, it's not super useful aside from probably
> good choice for a fullscreen fallback plane). See my reply on the old
> thread.

Yeah, as I've already replied, I won't volunteer to document legacy bits,
documenting atomic is already enough. :P

> And that patch should also add the code to drm_mode_config_validate() to
> validate the possible_crtc masks for these. Something like
>
>   num_primary = 0; num_cursor = 0;
>
>   for_each_plane(plane) {
>   if (plane->type == primary) {
>   WARN_ON(!(plane->possible_crtcs & BIT(num_primary)));
>   num_primary++;
>   }
>
>   /* same for cursor */
>   }
>
>   WARN_ON(num_primary != dev->mode_config.num_crtcs);
> }

Thanks for the suggestion. However I don't see why a driver should ensure
this. Isn't it perfectly fine for a driver to use primary plane 2 for CRTC 1,
and primary plane 1 for CRTC 2, for the purposes of legacy uAPI?

If we're trying here to invent a new uAPI to let user-space discover the
internal legacy primary/cursor pointers, I'm not signing up for this. The
requirement you're describing seems like something current drivers ensure
"by chance", not an established uAPI. In other words, writing a new driver
that doesn't do the same wouldn't break uAPI contracts.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 01/19] drm/encoder: make encoder control functions optional

[Daniel Vetter]

On Wed, Dec 09, 2020 at 11:58:44AM +0100, Philipp Zabel wrote:
> Hi Sam,
> 
> On Tue, 2020-12-08 at 19:48 +0100, Sam Ravnborg wrote:
> > Hi Philipp,
> > On Tue, Dec 08, 2020 at 04:54:33PM +0100, Philipp Zabel wrote:
> > > Simple managed encoders do not require the .destroy callback,
> > > make the whole funcs structure optional.
> > > 
> > > Signed-off-by: Philipp Zabel 
> > > Reviewed-by: Laurent Pinchart 
> > > ---
> > > New in v4.
> > > ---
> > >  drivers/gpu/drm/drm_encoder.c | 4 ++--
> > >  drivers/gpu/drm/drm_mode_config.c | 5 +++--
> > >  include/drm/drm_encoder.h | 2 +-
> > >  3 files changed, 6 insertions(+), 5 deletions(-)
> > > 
> [...]
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index f1affc1bb679..87e144155456 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> [...]
> > > @@ -487,7 +487,8 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> > >  
> > >   list_for_each_entry_safe(encoder, enct, &dev->mode_config.encoder_list,
> > >head) {
> > > - encoder->funcs->destroy(encoder);
> > > + if (encoder->funcs)
> > > + encoder->funcs->destroy(encoder);
> > 
> > So late_register and early_unregister are both optional.
> > But if encoder->funcs is set then the destroy callback is mandatory.
> 
> For encoders that are kept on the mode_config.encoder_list until
> drm_mode_config_cleanup() is called, the destroy callback is still
> mandatory.
> 
> Encoders allocated with drmm_encoder_alloc() on the other hand should
> have the destroy callback set to NULL, if encoder->funcs is set.
> These encoders are removed from the mode_config.encoder_list by the drmm
> cleanup code, before drm_mode_config_cleanup is called.
> 
> > I am just wondering if this is intended.
> > Reding the documnetation of drm_encoder_funcs thist matches the
> > documentation but anyway..
> >
> > With this comment considered,
> > Reviewed-by: Sam Ravnborg 
> 
> Thank you for bringing this up, should we just leave
> drm_mode_config_cleanup() as-is?

Yup, not having a funcs->destroy there is a bug. Maybe should even warn
about the lack of that in the traditional non-drmm_ encoder init function.
-Daniel

> 
> regards
> Philipp
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/9] drm/vc4: hdmi: Store pixel frequency in the connector state

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> The pixel rate is for now quite simple to compute, but with more features
> (30 and 36 bits output, YUV output, etc.) will depend on a bunch of
> connectors properties.
>
> Let's store the rate we have to run the pixel clock at in our custom
> connector state, and compute it in atomic_check.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 744396c8dcb9..83699105c7a5 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector 
> *connector)
> if (!new_state)
> return NULL;
>
> +   new_state->pixel_rate = vc4_state->pixel_rate;
> __drm_atomic_helper_connector_duplicate_state(connector, 
> &new_state->base);
>
> return &new_state->base;
> @@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi 
> *vc4_hdmi)
>   "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
>  }
>
> +static struct drm_connector_state *
> +vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
> +struct drm_atomic_state *state)
> +{
> +   struct drm_connector_state *conn_state;
> +   struct drm_connector *connector;
> +   unsigned int i;
> +
> +   for_each_new_connector_in_state(state, connector, conn_state, i) {
> +   if (conn_state->best_encoder == encoder)
> +   return conn_state;
> +   }
> +
> +   return NULL;
> +}
> +
>  static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
> struct drm_atomic_state 
> *state)
>  {
> +   struct drm_connector_state *conn_state =
> +   vc4_hdmi_encoder_get_connector_state(encoder, state);
> +   struct vc4_hdmi_connector_state *vc4_conn_state =
> +   conn_state_to_vc4_hdmi_conn_state(conn_state);
> struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long pixel_rate, hsm_rate;
> @@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
> drm_encoder *encoder,
> return;
> }
>
> -   pixel_rate = mode->clock * 1000 * ((mode->flags & 
> DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
> +   pixel_rate = vc4_conn_state->pixel_rate;
> ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
> @@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct 
> drm_encoder *encoder,
>  struct drm_crtc_state *crtc_state,
>  struct drm_connector_state 
> *conn_state)
>  {
> +   struct vc4_hdmi_connector_state *vc4_state = 
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
> @@ -827,6 +849,8 @@ static int vc4_hdmi_encoder_atomic_check(struct 
> drm_encoder *encoder,
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> +   vc4_state->pixel_rate = pixel_rate;
> +
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 2cf5362052e2..bca6943de884 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
>
>  struct vc4_hdmi_connector_state {
> struct drm_connector_state  base;
> +   unsigned long long  pixel_rate;
>  };
>
>  static inline struct vc4_hdmi_connector_state *
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tidss: Use the new api devm_drm_irq_install

[Tomi Valkeinen]

On 09/12/2020 02:48, Daniel Vetter wrote:
> On Tue, Dec 08, 2020 at 03:50:59PM +0800, Tian Tao wrote:
>> Use devm_drm_irq_install to register interrupts so that
>> drm_irq_uninstall is not needed to be called.
>>
>> Signed-off-by: Tian Tao 
> 
> There's another drm_irq_install in the error path. But I'm not sure this
> is safe since you're chaning the order in which things get cleaned up now.
> So leaving this up to Tomi.

Right, I don't think this works. tidss irq_uninstall uses runtime_get/put, 
which needs to happen
before pm_runtime_disable. With devm_drm_irq_install that's not the case.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 3/9] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> Reported-by: Thomas Zimmermann 
> Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within 
> limits")
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 5a608ed1d75e..a88aa20beeb6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -796,6 +796,9 @@ static int vc4_hdmi_encoder_atomic_check(struct 
> drm_encoder *encoder,
> pixel_rate = mode->clock * 1000;
> }
>
> +   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +   pixel_rate = pixel_rate * 2;
> +
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 9/9] drm/vc4: hdmi: Enable 10/12 bpc output

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c  | 71 -
>  drivers/gpu/drm/vc4/vc4_hdmi.h  |  1 +
>  drivers/gpu/drm/vc4/vc4_hdmi_regs.h |  9 
>  3 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index f4ff6b5db484..fb30ddd842b1 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
>  #define VC5_HDMI_VERTB_VSPO_SHIFT  16
>  #define VC5_HDMI_VERTB_VSPO_MASK   VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK  VC4_MASK(10, 
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK  VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK  VC4_MASK(15, 8)
> +
>  # define VC4_HD_M_SW_RST   BIT(2)
>  # define VC4_HD_M_ENABLE   BIT(0)
>
> @@ -179,6 +190,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector 
> *connector)
>
> kfree(connector->state);
>
> +   conn_state->base.max_bpc = 8;
> +   conn_state->base.max_requested_bpc = 8;
> +

Having added protection from the kzalloc failing in 4/9, this adds
back in dereferencing conn_state without having checked it succeeded
first :(

Otherwise this looks fine.

  Dave

> __drm_atomic_helper_connector_reset(connector, &conn_state->base);
>
> if (connector->state)
> @@ -228,12 +242,20 @@ static int vc4_hdmi_connector_init(struct drm_device 
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
>
> +   /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset 
> helper.
> +*/
> +   if (connector->funcs->reset)
> +   connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> +   drm_connector_attach_max_bpc_property(connector, 8, 12);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
>  DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -499,6 +521,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi, 
> bool enable)
>  }
>
>  static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
>  struct drm_display_mode *mode)
>  {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -542,7 +565,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi 
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
>  }
> +
>  static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
>  struct drm_display_mode *mode)
>  {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -562,6 +587,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> +   unsigned char gcp;
> +   bool gcp_en;
> +   u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
> HDMI_WRITE(HDMI_HORZA,
> @@ -587,6 +615,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi 
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
>
> +   switch (state->max_bpc) {
> +   case 12:
> +   gcp = 6;
> +   gcp_en = true;
> +   break;
> +   case 10:
> +   gcp = 5;
> +   gcp_en = true;
> +   break;
> +   case 8:
> +   default:
> +   gcp = 4;
> +   gcp_en = false;
> +   break;
> +   }
> +
> +   reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
> +   reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
> +VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
> +   reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) 
> |
> +  VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFI

Re: [PATCH v5 8/9] drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> Unlike the previous generations, the HSM clock limitation is way above
> what we can reach without scrambling, so let's move the maximum
> frequency we support to the maximum clock frequency without scrambling.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 5310e06efc82..f4ff6b5db484 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -82,6 +82,8 @@
>  #define CEC_CLOCK_FREQ 4
>  #define VC4_HSM_MID_CLOCK 149985000
>
> +#define HDMI_14_MAX_TMDS_CLK   (340 * 1000 * 1000)
> +
>  static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>  {
> struct drm_info_node *node = (struct drm_info_node *)m->private;
> @@ -1911,7 +1913,7 @@ static const struct vc4_hdmi_variant 
> bcm2711_hdmi0_variant = {
> .encoder_type   = VC4_ENCODER_TYPE_HDMI0,
> .debugfs_name   = "hdmi0_regs",
> .card_name  = "vc4-hdmi-0",
> -   .max_pixel_clock= 29700,
> +   .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
> .registers  = vc5_hdmi_hdmi0_fields,
> .num_registers  = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
> .phy_lane_mapping   = {
> @@ -1937,7 +1939,7 @@ static const struct vc4_hdmi_variant 
> bcm2711_hdmi1_variant = {
> .encoder_type   = VC4_ENCODER_TYPE_HDMI1,
> .debugfs_name   = "hdmi1_regs",
> .card_name  = "vc4-hdmi-1",
> -   .max_pixel_clock= 29700,
> +   .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
> .registers  = vc5_hdmi_hdmi1_fields,
> .num_registers  = ARRAY_SIZE(vc5_hdmi_hdmi1_fields),
> .phy_lane_mapping   = {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 7/9] drm/vc4: hdmi: Use the connector state pixel rate for the PHY

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> The PHY initialisation parameters are not based on the pixel clock but
> the TMDS clock rate which can be the pixel clock in the standard case,
> but could be adjusted based on some parameters like the bits per color.
>
> Since the TMDS clock rate is stored in our custom connector state
> already, let's reuse it from there instead of computing it again.
>
> Acked-by: Thomas Zimmermann 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.h | 11 +--
>  drivers/gpu/drm/vc4/vc4_hdmi_phy.c |  8 +---
>  3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 83699105c7a5..5310e06efc82 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
> drm_encoder *encoder,
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> if (vc4_hdmi->variant->phy_init)
> -   vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
> +   vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
>
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
>HDMI_READ(HDMI_SCHEDULER_CONTROL) |
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index bca6943de884..60c53d7c9bad 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
> return container_of(encoder, struct vc4_hdmi_encoder, base.base);
>  }
>
> -struct drm_display_mode;
> -
>  struct vc4_hdmi;
>  struct vc4_hdmi_register;
> +struct vc4_hdmi_connector_state;
>
>  enum vc4_hdmi_phy_channel {
> PHY_LANE_0 = 0,
> @@ -80,9 +79,9 @@ struct vc4_hdmi_variant {
> void (*set_timings)(struct vc4_hdmi *vc4_hdmi,
> struct drm_display_mode *mode);
>
> -   /* Callback to initialize the PHY according to the mode */
> +   /* Callback to initialize the PHY according to the connector state */
> void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
> -struct drm_display_mode *mode);
> +struct vc4_hdmi_connector_state *vc4_conn_state);
>
> /* Callback to disable the PHY */
> void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
> @@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct 
> drm_connector_state *conn_state)
>  }
>
>  void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> -  struct drm_display_mode *mode);
> +  struct vc4_hdmi_connector_state *vc4_conn_state);
>  void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
>  void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
>  void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
>
>  void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> -  struct drm_display_mode *mode);
> +  struct vc4_hdmi_connector_state *vc4_conn_state);
>  void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
>  void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
>  void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c 
> b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> index 057796b54c51..36535480f8e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> @@ -127,7 +127,8 @@
>
>  #define OSCILLATOR_FREQUENCY   5400
>
> -void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode 
> *mode)
> +void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> +  struct vc4_hdmi_connector_state *conn_state)
>  {
> /* PHY should be in reset, like
>  * vc4_hdmi_encoder_disable() does.
> @@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi 
> *vc4_hdmi)
> HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
>  }
>
> -void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode 
> *mode)
> +void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> +  struct vc4_hdmi_connector_state *conn_state)
>  {
> const struct phy_lane_settings *chan0_settings, *chan1_settings, 
> *chan2_settings, *clock_settings;
> const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
> -   unsigned long long pixel_freq = mode->clock * 1000;
> +   unsigned long long pixel_freq = conn_state->pixel_rate;
> unsigned long long vco_freq;
> unsigned char word_sel;
> u8 vco_sel, vco_div;
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm/vc4: hdmi: Create a custom connector state

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to the state.
>
> Acked-by: Thomas Zimmermann 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
>  drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
>  2 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 61039cc89d9d..744396c8dcb9 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>
>  static void vc4_hdmi_connector_reset(struct drm_connector *connector)
>  {
> -   drm_atomic_helper_connector_reset(connector);
> +   struct vc4_hdmi_connector_state *conn_state = 
> kzalloc(sizeof(*conn_state), GFP_KERNEL);
> +
> +   if (connector->state)
> +   __drm_atomic_helper_connector_destroy_state(connector->state);
> +
> +   kfree(connector->state);
> +
> +   __drm_atomic_helper_connector_reset(connector, &conn_state->base);
>
> if (connector->state)
> drm_atomic_helper_connector_tv_reset(connector);
>  }
>
> +static struct drm_connector_state *
> +vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
> +{
> +   struct drm_connector_state *conn_state = connector->state;
> +   struct vc4_hdmi_connector_state *vc4_state = 
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> +   struct vc4_hdmi_connector_state *new_state;
> +
> +   new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
> +   if (!new_state)
> +   return NULL;
> +
> +   __drm_atomic_helper_connector_duplicate_state(connector, 
> &new_state->base);
> +
> +   return &new_state->base;
> +}
> +
>  static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> .detect = vc4_hdmi_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = vc4_hdmi_connector_destroy,
> .reset = vc4_hdmi_connector_reset,
> -   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +   .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0526a9cf608a..2cf5362052e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> return container_of(_encoder, struct vc4_hdmi, encoder);
>  }
>
> +struct vc4_hdmi_connector_state {
> +   struct drm_connector_state  base;
> +};
> +
> +static inline struct vc4_hdmi_connector_state *
> +conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
> +{
> +   return container_of(conn_state, struct vc4_hdmi_connector_state, 
> base);
> +}
> +
>  void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
>struct drm_display_mode *mode);
>  void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/9] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails

[Dave Stevenson]

Hi Maxime

On Mon, 7 Dec 2020 at 15:57, Maxime Ripard  wrote:
>
> drm_atomic_helper_connector_reset uses kmalloc which, from an API
> standpoint, can fail, and thus setting connector->state to NULL.
> However, our reset hook then calls drm_atomic_helper_connector_tv_reset
> that will access connector->state without checking if it's a valid
> pointer or not.
>
> Make sure we don't end up accessing a NULL pointer.
>
> Acked-by: Thomas Zimmermann 
> Suggested-by: Dave Stevenson 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a88aa20beeb6..61039cc89d9d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>  static void vc4_hdmi_connector_reset(struct drm_connector *connector)
>  {
> drm_atomic_helper_connector_reset(connector);
> -   drm_atomic_helper_connector_tv_reset(connector);
> +
> +   if (connector->state)
> +   drm_atomic_helper_connector_tv_reset(connector);
>  }
>
>  static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm: add legacy support for using degamma for gamma

[Tomi Valkeinen]

Hi Daniel,

On 09/12/2020 02:51, Daniel Vetter wrote:

>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index ba839e5e357d..4d9e217e5040 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -1084,6 +1084,9 @@ struct drm_crtc {
>>>  */
>>> uint16_t *gamma_store;
>>>  
>>> +   bool has_gamma_prop : 1;
>>> +   bool has_degamma_prop : 1;
> 
> I'm a bit behind on patches, but in case this got missed please remove
> this and replace with the (obj, prop) lookup function thing or something
> like that. Makes sure everything stays in sync, plus like I said atomic
> uses this a ton. So not a problem here.

The drm_mode_obj_find_prop_id() is in core drm.ko, and not exported, but I need 
it also from
drm_kms_helper.ko.

drm_mode_obj_find_prop_id() is declared in drm_crtc_internal.h. Are those 
functions supposed to be
not exported from drm.ko?

So, is it fine to just export drm_mode_obj_find_prop_id? If I export, should I 
move it to
drm_mode_object.h?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 3/3] tests/etnaviv_2d_test: check whether the rendering is correct

[Christian Gmeiner]

Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Instead of always dumping the rendered picture, check whether it matches
> the expectations. This makes more sense for automated testing.
>
> Retain the ability to dump the picture instead of checking it when a
> file name is given as an argument. This also removes use of a hardcoded
> file name in a world writable directory, which is an unsafe thing to
> do anyway.
>
> Signed-off-by: Lubomir Rintel 

Reviewed-by: Christian Gmeiner 

> ---
>  tests/etnaviv/etnaviv_2d_test.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/tests/etnaviv/etnaviv_2d_test.c b/tests/etnaviv/etnaviv_2d_test.c
> index a75a4a89..9fcdae18 100644
> --- a/tests/etnaviv/etnaviv_2d_test.c
> +++ b/tests/etnaviv/etnaviv_2d_test.c
> @@ -147,6 +147,27 @@ static void gen_cmd_stream(struct etna_cmd_stream 
> *stream, struct etna_bo *bmp,
> etna_set_state(stream, VIVS_GL_FLUSH_CACHE, VIVS_GL_FLUSH_CACHE_PE2D);
>  }
>
> +int etna_check_image(uint32_t *p, int width, int height)
> +{
> +   int i;
> +   uint32_t expected;
> +
> +   for (i = 0; i < width * height; i++) {
> +   if (i%8 < 4 && i%(width*8) < width*4 && i%width < 8*16 && i < 
> width*8*16)
> +   expected = 0xff40ff40;
> +   else
> +   expected = 0x;
> +
> +   if (p[i] != expected) {
> +   fprintf(stderr, "Offset %d: expected: 0x%08x, got: 
> 0x%08x\n",
> +   i, expected, p[i]);
> +   return -1;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
>  int main(int argc, char *argv[])
>  {
> const int width = 256;
> @@ -165,7 +186,7 @@ int main(int argc, char *argv[])
> int core = 0;
>
> if (argc < 2) {
> -   fprintf(stderr, "Usage: %s /dev/dri/\n", argv[0]);
> +   fprintf(stderr, "Usage: %s /dev/dri/ []\n", 
> argv[0]);
> return 1;
> }
>
> @@ -242,7 +263,11 @@ int main(int argc, char *argv[])
>
> etna_cmd_stream_finish(stream);
>
> -   bmp_dump32(etna_bo_map(bmp), width, height, false, "/tmp/etna.bmp");
> +   if (argc > 2)
> +   bmp_dump32(etna_bo_map(bmp), width, height, false, argv[2]);
> +
> +   if (etna_check_image(etna_bo_map(bmp), width, height))
> +   ret = 7;
>
> etna_cmd_stream_del(stream);
>
> --
> 2.28.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/3] tests/etnaviv_2d_test: pick the 2D core

[Christian Gmeiner]

Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Run the test on a core capable of 2D rendering instead of hardcoding to
> core zero.
>

Thanks - I should have done this before landing this test :)

> Signed-off-by: Lubomir Rintel 

Reviewed-by: Christian Gmeiner 

> ---
>  tests/etnaviv/etnaviv_2d_test.c | 31 ---
>  1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/tests/etnaviv/etnaviv_2d_test.c b/tests/etnaviv/etnaviv_2d_test.c
> index eb9dfa59..a75a4a89 100644
> --- a/tests/etnaviv/etnaviv_2d_test.c
> +++ b/tests/etnaviv/etnaviv_2d_test.c
> @@ -161,6 +161,8 @@ int main(int argc, char *argv[])
>
> drmVersionPtr version;
> int fd, ret = 0;
> +   uint64_t feat;
> +   int core = 0;
>
> if (argc < 2) {
> fprintf(stderr, "Usage: %s /dev/dri/\n", argv[0]);
> @@ -190,13 +192,28 @@ int main(int argc, char *argv[])
> goto out;
> }
>
> -   /* TODO: we assume that core 0 is a 2D capable one */
> -   gpu = etna_gpu_new(dev, 0);
> -   if (!gpu) {
> -   perror("etna_gpu_new");
> -   ret = 3;
> -   goto out_device;
> -   }
> +   do {
> +   gpu = etna_gpu_new(dev, core);
> +   if (!gpu) {
> +   perror("etna_gpu_new");
> +   ret = 3;
> +   goto out_device;
> +   }
> +
> +   if (etna_gpu_get_param(gpu, ETNA_GPU_FEATURES_0, &feat)) {
> +   perror("etna_gpu_get_param");
> +   ret = 4;
> +   goto out_device;
> +   }
> +
> +   if ((feat & (1 << 9)) == 0) {
> +   /* GPU not 2D capable. */
> +   etna_gpu_del(gpu);
> +   gpu = NULL;
> +   }
> +
> +   core++;
> +   } while (!gpu);
>
> pipe = etna_pipe_new(gpu, ETNA_PIPE_2D);
> if (!pipe) {
> --
> 2.28.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/3] tests/etnaviv_2d_test: explain the errors

[Christian Gmeiner]

Am Di., 1. Dez. 2020 um 21:38 Uhr schrieb Lubomir Rintel :
>
> Just so that it's obvious what failed and why.
>
> Signed-off-by: Lubomir Rintel 

Reviewed-by: Christian Gmeiner 

> ---
>  tests/etnaviv/etnaviv_2d_test.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/tests/etnaviv/etnaviv_2d_test.c b/tests/etnaviv/etnaviv_2d_test.c
> index 8dd77b66..eb9dfa59 100644
> --- a/tests/etnaviv/etnaviv_2d_test.c
> +++ b/tests/etnaviv/etnaviv_2d_test.c
> @@ -162,9 +162,16 @@ int main(int argc, char *argv[])
> drmVersionPtr version;
> int fd, ret = 0;
>
> -   fd = open(argv[1], O_RDWR);
> -   if (fd < 0)
> +   if (argc < 2) {
> +   fprintf(stderr, "Usage: %s /dev/dri/\n", argv[0]);
> return 1;
> +   }
> +
> +   fd = open(argv[1], O_RDWR);
> +   if (fd < 0) {
> +   perror(argv[1]);
> +   return 1;
> +   }
>
> version = drmGetVersion(fd);
> if (version) {
> @@ -178,6 +185,7 @@ int main(int argc, char *argv[])
>
> dev = etna_device_new(fd);
> if (!dev) {
> +   perror("etna_device_new");
> ret = 2;
> goto out;
> }
> @@ -185,18 +193,21 @@ int main(int argc, char *argv[])
> /* TODO: we assume that core 0 is a 2D capable one */
> gpu = etna_gpu_new(dev, 0);
> if (!gpu) {
> +   perror("etna_gpu_new");
> ret = 3;
> goto out_device;
> }
>
> pipe = etna_pipe_new(gpu, ETNA_PIPE_2D);
> if (!pipe) {
> +   perror("etna_pipe_new");
> ret = 4;
> goto out_gpu;
> }
>
> bmp = etna_bo_new(dev, bmp_size, ETNA_BO_UNCACHED);
> if (!bmp) {
> +   perror("etna_bo_new");
> ret = 5;
> goto out_pipe;
> }
> @@ -204,6 +215,7 @@ int main(int argc, char *argv[])
>
> stream = etna_cmd_stream_new(pipe, 0x300, NULL, NULL);
> if (!stream) {
> +   perror("etna_cmd_stream_new");
> ret = 6;
> goto out_bo;
> }
> --
> 2.28.0
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations

[Thomas Zimmermann]

Hi

Am 09.12.20 um 15:25 schrieb Thomas Zimmermann:

The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
allowed to pin the buffer or acquire the buffer's reservation object
lock.

This is a problem for callers that only require a short-term mapping
of the buffer without the pinning, or callers that have special locking
requirements. These may suffer from unnecessary overhead or interfere
with regular pin operations.

The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
their rsp callbacks in struct dma_buf_ops provide an alternative without
pinning or reservation locking. Callers are responsible for these
operations.

Signed-off-by: Thomas Zimmermann 


Before merging, this patch would get a Suggested-by tag to give Daniel 
credit. I only notices after hitting the send button.


Best regards
Thomas


---
  drivers/dma-buf/dma-buf.c | 80 +++
  include/linux/dma-buf.h   | 34 +
  2 files changed, 114 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e63684d4cd90..be9f80190a66 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1265,6 +1265,86 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct 
dma_buf_map *map)
  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
  
+/**

+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into 
kernel
+ * address space.
+ * @dmabuf:[in]buffer to vmap
+ * @map:   [out]   returns the vmap pointer
+ *
+ * This call may fail due to lack of virtual mapping address space.
+ * These calls are optional in drivers. The intended use for them
+ * is for mapping objects linear in kernel space for high use objects.
+ * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+   struct dma_buf_map ptr;
+   int ret = 0;
+
+   dma_buf_map_clear(map);
+
+   if (WARN_ON(!dmabuf))
+   return -EINVAL;
+
+   dma_resv_assert_held(dmabuf->resv);
+
+   if (!dmabuf->ops->vmap_local)
+   return -EINVAL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+   *map = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
+
+   ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
+   if (WARN_ON_ONCE(ret))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+   *map = dmabuf->vmap_ptr;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
+
+/**
+ * dma_buf_vunmap_local - Unmap a vmap obtained by dma_buf_vmap_local.
+ * @dmabuf:[in]buffer to vunmap
+ * @map:   [in]vmap pointer to vunmap
+ */
+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+   if (WARN_ON(!dmabuf))
+   return;
+
+   dma_resv_assert_held(dmabuf->resv);
+
+   BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+   BUG_ON(dmabuf->vmapping_counter == 0);
+   BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap_local)
+   dmabuf->ops->vunmap_local(dmabuf, map);
+   dma_buf_map_clear(&dmabuf->vmap_ptr);
+   }
+   mutex_unlock(&dmabuf->lock);
+}
+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
+
  #ifdef CONFIG_DEBUG_FS
  static int dma_buf_debug_show(struct seq_file *s, void *unused)
  {
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cf72699cb2bc..f66580d23a9b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -269,6 +269,38 @@ struct dma_buf_ops {
  
  	int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);

void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+   /**
+* @vmap_local:
+*
+* Creates a virtual mapping for the buffer into kernel address space.
+*
+* This callback establishes short-term mappings for situations where
+* callers only use the buffer for a bounded amount of time; such as
+* updates to the framebuffer or reading back contained information.
+* In contrast to the regular @vmap callback, vmap_local does never pin
+* the buffer to a specific domain or acquire the buffer's reservation
+* lock.
+*
+* This is called with the dmabuf->resv object locked. Callers must hold
+* the lock until after removing the mapping with @vunmap_local.
+*
+* This callback is optional.
+*
+* Returns:
+

[PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings

[Thomas Zimmermann]

Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private SHMEM buffers, but may happen
with imported ones.

Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
operations. Callers have to hold the reservation lock while the mapping
persists.

The affected callers are display updates in cirrus, gm12u320, mgag200
and udl. All are being changed to the new interface.

This patch also connects GEM SHMEM helpers to GEM object functions with
equivalent functionality.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 71 +-
 drivers/gpu/drm/mgag200/mgag200_mode.c | 16 --
 drivers/gpu/drm/tiny/cirrus.c  | 10 +++-
 drivers/gpu/drm/tiny/gm12u320.c| 14 +++--
 drivers/gpu/drm/udl/udl_modeset.c  | 18 ---
 include/drm/drm_gem_shmem_helper.h |  2 +
 6 files changed, 115 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 9825c378dfa6..41663f48d46a 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs 
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
+   .vmap_local = drm_gem_shmem_vmap_local,
+   .vunmap_local = drm_gem_shmem_vunmap_local,
.mmap = drm_gem_shmem_mmap,
 };
 
@@ -313,7 +315,7 @@ static int drm_gem_shmem_vmap_locked(struct 
drm_gem_shmem_object *shmem, struct
return ret;
 }
 
-/*
+/**
  * drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
  * @shmem: shmem GEM object
  * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
@@ -346,6 +348,44 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL(drm_gem_shmem_vmap);
 
+/**
+ * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
+ *   store.
+ *
+ * This function makes sure that a contiguous kernel virtual address mapping
+ * exists for the buffer backing the shmem GEM object.
+ *
+ * The function is called with the BO's reservation object locked. Callers must
+ * hold the lock until after unmapping the buffer.
+ *
+ * This function can be used to implement &drm_gem_object_funcs.vmap_local. But
+ * it can also be called by drivers directly, in which case it will hide the
+ * differences between dma-buf imported and natively allocated objects.
+ *
+ * Acquired mappings should be cleaned up by calling 
drm_gem_shmem_vunmap_local().
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map 
*map)
+{
+   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+   int ret;
+
+   dma_resv_assert_held(obj->resv);
+
+   ret = mutex_lock_interruptible(&shmem->vmap_lock);
+   if (ret)
+   return ret;
+   ret = drm_gem_shmem_vmap_locked(shmem, map);
+   mutex_unlock(&shmem->vmap_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
+
 static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map)
 {
@@ -366,7 +406,7 @@ static void drm_gem_shmem_vunmap_locked(struct 
drm_gem_shmem_object *shmem,
drm_gem_shmem_put_pages(shmem);
 }
 
-/*
+/**
  * drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object
  * @shmem: shmem GEM object
  * @map: Kernel virtual address where the SHMEM GEM object was mapped
@@ -389,6 +429,33 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj, 
struct dma_buf_map *map)
 }
 EXPORT_SYMBOL(drm_gem_shmem_vunmap);
 
+/**
+ * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Kernel virtual address where the SHMEM GEM object was mapped
+ *
+ * This function cleans up a kernel virtual address mapping acquired by
+ * drm_gem_shmem_vmap_local(). The mapping is only removed when the use count
+ * drops to zero.
+ *
+ * The function is called with the BO's reservation object locked.
+ *
+ * This function can be used to implement &drm_gem_object_funcs.vmap_local.
+ * But it can also be called by drivers directly, in which case it will hide
+ * the differences between dma-buf imported and natively allocated objects.
+ */
+void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map 
*map

[PATCH v3 7/8] drm/vram-helper: Provide a vmap function for short-term mappings

[Thomas Zimmermann]

Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
It's somewhat inconvenient to callers that simply require a mapping of
the contained memory; and also ipmplies a certain overhead.

Therefore provide drm_gem_vram_vmap_local() drm_gem_vram_vunmap_local(),
which only perform the vmap/vunmap operations. Callers have to hold the
reservation lock while the mapping persists; or have to pin the BO by
themselves.

The affected callers are cursor updates in ast and vboxvideo. Both
are being changed to the new interface.

This patch connects GEM VRAM helpers to GEM object functions with
equivalent functionality.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c  |  37 +--
 drivers/gpu/drm/drm_gem_vram_helper.c | 142 +-
 drivers/gpu/drm/vboxvideo/vbox_mode.c |  15 +--
 include/drm/drm_gem_vram_helper.h |   2 +
 4 files changed, 132 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index fac1ee79c372..c38f435bcde2 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -159,6 +159,8 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *dst_gbo = 
ast->cursor.gbo[ast->cursor.next_index];
struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+   struct drm_gem_object *objs[] = {&src_gbo->bo.base, &dst_gbo->bo.base};
+   struct ww_acquire_ctx ctx;
struct dma_buf_map src_map, dst_map;
void __iomem *dst;
void *src;
@@ -168,26 +170,34 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
 
-   ret = drm_gem_vram_vmap(src_gbo, &src_map);
+   ret = drm_gem_lock_reservations(objs, ARRAY_SIZE(objs), &ctx);
if (ret)
return ret;
+
+   ret = drm_gem_vram_vmap_local(src_gbo, &src_map);
+   if (ret)
+   goto err_drm_gem_unlock_reservations;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
 
-   ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
+   ret = drm_gem_vram_vmap_local(dst_gbo, &dst_map);
if (ret)
-   goto err_drm_gem_vram_vunmap;
+   goto err_drm_gem_vram_vunmap_local;
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
 
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
 
-   drm_gem_vram_vunmap(dst_gbo, &dst_map);
-   drm_gem_vram_vunmap(src_gbo, &src_map);
+   drm_gem_vram_vunmap_local(dst_gbo, &dst_map);
+   drm_gem_vram_vunmap_local(src_gbo, &src_map);
+
+   drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
 
return 0;
 
-err_drm_gem_vram_vunmap:
-   drm_gem_vram_vunmap(src_gbo, &src_map);
+err_drm_gem_vram_vunmap_local:
+   drm_gem_vram_vunmap_local(src_gbo, &src_map);
+err_drm_gem_unlock_reservations:
+   drm_gem_unlock_reservations(objs, ARRAY_SIZE(objs), &ctx);
return ret;
 }
 
@@ -241,6 +251,7 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
 {
struct drm_device *dev = &ast->base;
struct drm_gem_vram_object *gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct drm_gem_object *obj = &gbo->bo.base;
struct dma_buf_map map;
u8 x_offset, y_offset;
u8 __iomem *dst;
@@ -248,16 +259,22 @@ void ast_cursor_show(struct ast_private *ast, int x, int 
y,
u8 jreg;
int ret;
 
-   ret = drm_gem_vram_vmap(gbo, &map);
-   if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n", 
ret))
+   ret = dma_resv_lock(obj->resv, NULL);
+   if (ret)
+   return;
+   ret = drm_gem_vram_vmap_local(gbo, &map);
+   if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap_local() failed, 
ret=%d\n", ret)) {
+   dma_resv_unlock(obj->resv);
return;
+   }
dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
 
sig = dst + AST_HWC_SIZE;
writel(x, sig + AST_HWC_SIGNATURE_X);
writel(y, sig + AST_HWC_SIGNATURE_Y);
 
-   drm_gem_vram_vunmap(gbo, &map);
+   drm_gem_vram_vunmap_local(gbo, &map);
+   dma_resv_unlock(obj->resv);
 
if (x < 0) {
x_offset = (-x) + offset_x;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 02ca22e90290..08a713993896 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -379,47 +379,6 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
 }
 EXPORT_SYMBOL(drm_gem_vram_unpin);
 
-static int drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
-

[PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker

[Thomas Zimmermann]

Fbdev emulation has to lock the BO into place while flushing the shadow
buffer into the BO's memory. Remove any interference with pinning by
using vmap_local functionality (instead of full vmap). This requires
BO reservation locking in fbdev's damage worker.

The new DRM client functions for locking and vmap_local functionality
are added for consistency with the existing style.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_client.c| 91 +
 drivers/gpu/drm/drm_fb_helper.c | 41 +++
 include/drm/drm_client.h|  4 ++
 3 files changed, 116 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ce45e380f4a2..795f5cb052ba 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -288,6 +288,37 @@ drm_client_buffer_create(struct drm_client_dev *client, 
u32 width, u32 height, u
return ERR_PTR(ret);
 }
 
+/**
+ * drm_client_buffer_lock - Locks the DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function locks the client buffer by acquiring the buffer
+ * object's reservation lock.
+ *
+ * Unlock the buffer with drm_client_buffer_unlock().
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_lock(struct drm_client_buffer *buffer)
+{
+   return dma_resv_lock(buffer->gem->resv, NULL);
+}
+EXPORT_SYMBOL(drm_client_buffer_lock);
+
+/**
+ * drm_client_buffer_unlock - Unlock DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * Unlocks a client buffer. See drm_client_buffer_lock().
+ */
+void drm_client_buffer_unlock(struct drm_client_buffer *buffer)
+{
+   dma_resv_unlock(buffer->gem->resv);
+}
+EXPORT_SYMBOL(drm_client_buffer_unlock);
+
 /**
  * drm_client_buffer_vmap - Map DRM client buffer into address space
  * @buffer: DRM client buffer
@@ -348,6 +379,66 @@ void drm_client_buffer_vunmap(struct drm_client_buffer 
*buffer)
 }
 EXPORT_SYMBOL(drm_client_buffer_vunmap);
 
+/**
+ * drm_client_buffer_vmap_local - Map DRM client buffer into address space
+ * @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
+ *
+ * This function maps a client buffer into kernel address space. If the
+ * buffer is already mapped, it returns the existing mapping's address.
+ *
+ * Client buffer mappings are not ref'counted. Each call to
+ * drm_client_buffer_vmap_local() should be followed by a call to
+ * drm_client_buffer_vunmap_local(); or the client buffer should be mapped
+ * throughout its lifetime.
+ *
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int
+drm_client_buffer_vmap_local(struct drm_client_buffer *buffer, struct 
dma_buf_map *map_copy)
+{
+   struct dma_buf_map *map = &buffer->map;
+   int ret;
+
+   /*
+* FIXME: The dependency on GEM here isn't required, we could
+* convert the driver handle to a dma-buf instead and use the
+* backend-agnostic dma-buf vmap_local support instead. This would
+* require that the handle2fd prime ioctl is reworked to pull the
+* fd_install step out of the driver backend hooks, to make that
+* final step optional for internal users.
+*/
+   ret = drm_gem_vmap_local(buffer->gem, map);
+   if (ret)
+   return ret;
+
+   *map_copy = *map;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_client_buffer_vmap_local);
+
+/**
+ * drm_client_buffer_vunmap_local - Unmap DRM client buffer
+ * @buffer: DRM client buffer
+ *
+ * This function removes a client buffer's memory mapping. Calling this
+ * function is only required by clients that manage their buffer mappings
+ * by themselves.
+ */
+void drm_client_buffer_vunmap_local(struct drm_client_buffer *buffer)
+{
+   struct dma_buf_map *map = &buffer->map;
+
+   drm_gem_vunmap_local(buffer->gem, map);
+}
+EXPORT_SYMBOL(drm_client_buffer_vunmap_local);
+
 static void drm_client_buffer_rmfb(struct drm_client_buffer *buffer)
 {
int ret;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e82db0f4e771..a56a7d9f7e35 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -399,28 +399,34 @@ static int drm_fb_helper_damage_blit(struct drm_fb_helper 
*fb_helper,
int ret;
 
/*
-* We have to pin the client buffer to its current location while
-* flushing the shadow buffer. In the general case, concurrent
-* modesetting operations could try to move the buffer and would
-* fail. The modeset has to be serialized by acquiring the reservation
-* object of the underlying BO here.
-*
 * For fbdev emulation, we only have to protect against fbde

[PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations

[Thomas Zimmermann]

The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
allowed to pin the buffer or acquire the buffer's reservation object
lock.

This is a problem for callers that only require a short-term mapping
of the buffer without the pinning, or callers that have special locking
requirements. These may suffer from unnecessary overhead or interfere
with regular pin operations.

The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
their rsp callbacks in struct dma_buf_ops provide an alternative without
pinning or reservation locking. Callers are responsible for these
operations.

Signed-off-by: Thomas Zimmermann 
---
 drivers/dma-buf/dma-buf.c | 80 +++
 include/linux/dma-buf.h   | 34 +
 2 files changed, 114 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e63684d4cd90..be9f80190a66 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1265,6 +1265,86 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 
+/**
+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into 
kernel
+ * address space.
+ * @dmabuf:[in]buffer to vmap
+ * @map:   [out]   returns the vmap pointer
+ *
+ * This call may fail due to lack of virtual mapping address space.
+ * These calls are optional in drivers. The intended use for them
+ * is for mapping objects linear in kernel space for high use objects.
+ * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+   struct dma_buf_map ptr;
+   int ret = 0;
+
+   dma_buf_map_clear(map);
+
+   if (WARN_ON(!dmabuf))
+   return -EINVAL;
+
+   dma_resv_assert_held(dmabuf->resv);
+
+   if (!dmabuf->ops->vmap_local)
+   return -EINVAL;
+
+   mutex_lock(&dmabuf->lock);
+   if (dmabuf->vmapping_counter) {
+   dmabuf->vmapping_counter++;
+   BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+   *map = dmabuf->vmap_ptr;
+   goto out_unlock;
+   }
+
+   BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
+
+   ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
+   if (WARN_ON_ONCE(ret))
+   goto out_unlock;
+
+   dmabuf->vmap_ptr = ptr;
+   dmabuf->vmapping_counter = 1;
+
+   *map = dmabuf->vmap_ptr;
+
+out_unlock:
+   mutex_unlock(&dmabuf->lock);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
+
+/**
+ * dma_buf_vunmap_local - Unmap a vmap obtained by dma_buf_vmap_local.
+ * @dmabuf:[in]buffer to vunmap
+ * @map:   [in]vmap pointer to vunmap
+ */
+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct dma_buf_map *map)
+{
+   if (WARN_ON(!dmabuf))
+   return;
+
+   dma_resv_assert_held(dmabuf->resv);
+
+   BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
+   BUG_ON(dmabuf->vmapping_counter == 0);
+   BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
+
+   mutex_lock(&dmabuf->lock);
+   if (--dmabuf->vmapping_counter == 0) {
+   if (dmabuf->ops->vunmap_local)
+   dmabuf->ops->vunmap_local(dmabuf, map);
+   dma_buf_map_clear(&dmabuf->vmap_ptr);
+   }
+   mutex_unlock(&dmabuf->lock);
+}
+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
+
 #ifdef CONFIG_DEBUG_FS
 static int dma_buf_debug_show(struct seq_file *s, void *unused)
 {
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cf72699cb2bc..f66580d23a9b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -269,6 +269,38 @@ struct dma_buf_ops {
 
int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+   /**
+* @vmap_local:
+*
+* Creates a virtual mapping for the buffer into kernel address space.
+*
+* This callback establishes short-term mappings for situations where
+* callers only use the buffer for a bounded amount of time; such as
+* updates to the framebuffer or reading back contained information.
+* In contrast to the regular @vmap callback, vmap_local does never pin
+* the buffer to a specific domain or acquire the buffer's reservation
+* lock.
+*
+* This is called with the dmabuf->resv object locked. Callers must hold
+* the lock until after removing the mapping with @vunmap_local.
+*
+* This callback is optional.
+*
+* Returns:
+*
+* 0 on success or a negative error code on failure.
+*/
+   int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map);
+
+   /**
+* @vunmap_local:
+*
+* 

[PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings

[Thomas Zimmermann]

Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private CMA buffers, but may happen
with imported ones.

Therefore provide the new interface drm_gem_cma_vmap_local(), which only
performs the vmap operations. Callers have to hold the reservation lock
while the mapping persists.

This patch also connects GEM CMA helpers to the GEM object function with
equivalent functionality.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 35 
 drivers/gpu/drm/vc4/vc4_bo.c | 13 +++
 drivers/gpu/drm/vc4/vc4_drv.h|  1 +
 include/drm/drm_gem_cma_helper.h |  1 +
 4 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..40b3e8e3fc42 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -38,6 +38,7 @@ static const struct drm_gem_object_funcs 
drm_gem_cma_default_funcs = {
.print_info = drm_gem_cma_print_info,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = drm_gem_cma_vmap,
+   .vmap_local = drm_gem_cma_vmap_local,
.mmap = drm_gem_cma_mmap,
.vm_ops = &drm_gem_cma_vm_ops,
 };
@@ -471,6 +472,40 @@ int drm_gem_cma_vmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL_GPL(drm_gem_cma_vmap);
 
+/**
+ * drm_gem_cma_vmap_local - map a CMA GEM object into the kernel's virtual
+ * address space
+ * @obj: GEM object
+ * @map: Returns the kernel virtual address of the CMA GEM object's backing
+ *   store.
+ *
+ * This function maps a buffer into the kernel's
+ * virtual address space. Since the CMA buffers are already mapped into the
+ * kernel virtual address space this simply returns the cached virtual
+ * address. Drivers using the CMA helpers should set this as their DRM
+ * driver's &drm_gem_object_funcs.vmap_local callback.
+ *
+ * Returns:
+ * 0 on success, or a negative error code otherwise.
+ */
+int drm_gem_cma_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+   struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+   /*
+* TODO: The code in drm_gem_cma_prime_import_sg_table_vmap()
+*   establishes this mapping. The correct solution would
+*   be to call dma_buf_vmap_local() here.
+*
+*   If we find a case where we absolutely have to call
+*   dma_buf_vmap_local(), the code needs to be restructured.
+*/
+   dma_buf_map_set_vaddr(map, cma_obj->vaddr);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(drm_gem_cma_vmap_local);
+
 /**
  * drm_gem_cma_mmap - memory-map an exported CMA GEM object
  * @obj: GEM object
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index dc316cb79e00..ec57326c69c4 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,6 +387,7 @@ static const struct drm_gem_object_funcs 
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_get_sg_table,
.vmap = vc4_prime_vmap,
+   .vmap_local = vc4_prime_vmap_local,
.vm_ops = &vc4_vm_ops,
 };
 
@@ -797,6 +798,18 @@ int vc4_prime_vmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
return drm_gem_cma_vmap(obj, map);
 }
 
+int vc4_prime_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+   struct vc4_bo *bo = to_vc4_bo(obj);
+
+   if (bo->validated_shader) {
+   DRM_DEBUG("mmaping of shader BOs not allowed.\n");
+   return -EINVAL;
+   }
+
+   return drm_gem_cma_vmap_local(obj, map);
+}
+
 struct drm_gem_object *
 vc4_prime_import_sg_table(struct drm_device *dev,
  struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 43a1af110b3e..efb6c47d318f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -812,6 +812,7 @@ struct drm_gem_object *vc4_prime_import_sg_table(struct 
drm_device *dev,
 struct dma_buf_attachment 
*attach,
 struct sg_table *sgt);
 int vc4_prime_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+int vc4_prime_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map);
 int vc4_bo_cache_init(struct drm_device *dev);
 int vc4_bo_inc_usecnt(struct vc4_bo *bo);
 void vc4_bo_dec_usecnt(struct vc4_bo *bo);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 0a9711caa3e8..05122e71bc6d 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -99,6

[PATCH v3 2/8] drm/ast: Only map cursor BOs during updates

[Thomas Zimmermann]

The HW cursor's BO used to be mapped permanently into the kernel's
address space. GEM's vmap operation will be protected by locks, and
we don't want to lock the BO's for an indefinate period of time.

Change the cursor code to map the HW BOs only during updates. The
vmap operation in VRAM helpers is cheap, as a once estabished mapping
is being reused until the BO actually moves. As the HW cursor BOs are
permanently pinned, they never move at all.

v2:
* fix typos in commit description

Signed-off-by: Thomas Zimmermann 
Acked-by: Christian König 
---
 drivers/gpu/drm/ast/ast_cursor.c | 51 ++--
 drivers/gpu/drm/ast/ast_drv.h|  2 --
 2 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 68bf3d33f1ed..fac1ee79c372 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -39,7 +39,6 @@ static void ast_cursor_fini(struct ast_private *ast)
 
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
gbo = ast->cursor.gbo[i];
-   drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -53,14 +52,13 @@ static void ast_cursor_release(struct drm_device *dev, void 
*ptr)
 }
 
 /*
- * Allocate cursor BOs and pins them at the end of VRAM.
+ * Allocate cursor BOs and pin them at the end of VRAM.
  */
 int ast_cursor_init(struct ast_private *ast)
 {
struct drm_device *dev = &ast->base;
size_t size, i;
struct drm_gem_vram_object *gbo;
-   struct dma_buf_map map;
int ret;
 
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
@@ -77,15 +75,7 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_put(gbo);
goto err_drm_gem_vram_put;
}
-   ret = drm_gem_vram_vmap(gbo, &map);
-   if (ret) {
-   drm_gem_vram_unpin(gbo);
-   drm_gem_vram_put(gbo);
-   goto err_drm_gem_vram_put;
-   }
-
ast->cursor.gbo[i] = gbo;
-   ast->cursor.map[i] = map;
}
 
return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
@@ -94,7 +84,6 @@ int ast_cursor_init(struct ast_private *ast)
while (i) {
--i;
gbo = ast->cursor.gbo[i];
-   drm_gem_vram_vunmap(gbo, &ast->cursor.map[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -168,31 +157,38 @@ static void update_cursor_image(u8 __iomem *dst, const u8 
*src, int width, int h
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
 {
struct drm_device *dev = &ast->base;
-   struct drm_gem_vram_object *gbo;
-   struct dma_buf_map map;
-   int ret;
-   void *src;
+   struct drm_gem_vram_object *dst_gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct drm_gem_vram_object *src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+   struct dma_buf_map src_map, dst_map;
void __iomem *dst;
+   void *src;
+   int ret;
 
if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
return -EINVAL;
 
-   gbo = drm_gem_vram_of_gem(fb->obj[0]);
-
-   ret = drm_gem_vram_vmap(gbo, &map);
+   ret = drm_gem_vram_vmap(src_gbo, &src_map);
if (ret)
return ret;
-   src = map.vaddr; /* TODO: Use mapping abstraction properly */
+   src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
 
-   dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
+   ret = drm_gem_vram_vmap(dst_gbo, &dst_map);
+   if (ret)
+   goto err_drm_gem_vram_vunmap;
+   dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
 
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
 
-   drm_gem_vram_vunmap(gbo, &map);
+   drm_gem_vram_vunmap(dst_gbo, &dst_map);
+   drm_gem_vram_vunmap(src_gbo, &src_map);
 
return 0;
+
+err_drm_gem_vram_vunmap:
+   drm_gem_vram_vunmap(src_gbo, &src_map);
+   return ret;
 }
 
 static void ast_cursor_set_base(struct ast_private *ast, u64 address)
@@ -243,17 +239,26 @@ static void ast_cursor_set_location(struct ast_private 
*ast, u16 x, u16 y,
 void ast_cursor_show(struct ast_private *ast, int x, int y,
 unsigned int offset_x, unsigned int offset_y)
 {
+   struct drm_device *dev = &ast->base;
+   struct drm_gem_vram_object *gbo = 
ast->cursor.gbo[ast->cursor.next_index];
+   struct dma_buf_map map;
u8 x_offset, y_offset;
u8 __iomem *dst;
u8 __iomem *sig;
u8 jreg;
+   int ret;
 
-   dst = ast->curs

[PATCH v3 1/8] drm/ast: Don't pin cursor source BO explicitly during update

[Thomas Zimmermann]

Vmapping the cursor source BO contains an implicit pin operation,
so there's no need to do this manually.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 742d43a7edf4..68bf3d33f1ed 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -180,12 +180,9 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
 
gbo = drm_gem_vram_of_gem(fb->obj[0]);
 
-   ret = drm_gem_vram_pin(gbo, 0);
-   if (ret)
-   return ret;
ret = drm_gem_vram_vmap(gbo, &map);
if (ret)
-   goto err_drm_gem_vram_unpin;
+   return ret;
src = map.vaddr; /* TODO: Use mapping abstraction properly */
 
dst = ast->cursor.map[ast->cursor.next_index].vaddr_iomem;
@@ -194,13 +191,8 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
update_cursor_image(dst, src, fb->width, fb->height);
 
drm_gem_vram_vunmap(gbo, &map);
-   drm_gem_vram_unpin(gbo);
 
return 0;
-
-err_drm_gem_vram_unpin:
-   drm_gem_vram_unpin(gbo);
-   return ret;
 }
 
 static void ast_cursor_set_base(struct ast_private *ast, u64 address)
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/8] drm/gem: Create infrastructure for GEM vmap_local

[Thomas Zimmermann]

This patch adds vmap_local and vunmap_local to struct drm_gem_object_funcs;
including the PRIME helpers to connect with dma-buf's related interfaces.

Besides the generic DRM core, this will become relevant for fbdev emulation
with virtio, so we update it as well.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem.c  | 28 ++
 drivers/gpu/drm/drm_internal.h |  2 ++
 drivers/gpu/drm/drm_prime.c| 39 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c |  2 ++
 include/drm/drm_gem.h  | 20 +
 include/drm/drm_prime.h|  2 ++
 6 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 92f89cee213e..6e131d9bb7bd 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1234,6 +1234,34 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct 
dma_buf_map *map)
dma_buf_map_clear(map);
 }
 
+int drm_gem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+   int ret;
+
+   if (!obj->funcs->vmap_local)
+   return -EOPNOTSUPP;
+
+   ret = obj->funcs->vmap_local(obj, map);
+   if (ret)
+   return ret;
+   else if (dma_buf_map_is_null(map))
+   return -ENOMEM;
+
+   return 0;
+}
+
+void drm_gem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map)
+{
+   if (dma_buf_map_is_null(map))
+   return;
+
+   if (obj->funcs->vunmap_local)
+   obj->funcs->vunmap_local(obj, map);
+
+   /* Always set the mapping to NULL. Callers may rely on this. */
+   dma_buf_map_clear(map);
+}
+
 /**
  * drm_gem_lock_reservations - Sets up the ww context and acquires
  * the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 81d386b5b92a..b0bf6aba763a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_gem_pin(struct drm_gem_object *obj);
 void drm_gem_unpin(struct drm_gem_object *obj);
 int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
 void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+int drm_gem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map *map);
+void drm_gem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map *map);
 
 /* drm_debugfs.c drm_debugfs_crc.c */
 #if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 683aa29ecd3b..633edea76985 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -695,6 +695,43 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, struct 
dma_buf_map *map)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
+/**
+ * drm_gem_dmabuf_vmap_local - dma_buf vmap_local implementation for GEM
+ * @dma_buf: buffer to be mapped
+ * @map: the virtual address of the buffer
+ *
+ * Sets up a kernel virtual mapping. This can be used as the 
&dma_buf_ops.vmap_local
+ * callback. Calls into &drm_gem_object_funcs.vmap_local for device specific 
handling.
+ * The kernel virtual address is returned in map.
+ *
+ * Returns:
+ * 0 on success or a negative errno code otherwise.
+ */
+int drm_gem_dmabuf_vmap_local(struct dma_buf *dma_buf, struct dma_buf_map *map)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+
+   return drm_gem_vmap_local(obj, map);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_vmap_local);
+
+/**
+ * drm_gem_dmabuf_vunmap_local - dma_buf vunmap_local implementation for GEM
+ * @dma_buf: buffer to be unmapped
+ * @map: the virtual address of the buffer
+ *
+ * Releases a kernel virtual mapping. This can be used as the
+ * &dma_buf_ops.vunmap_local callback. Calls into 
&drm_gem_object_funcs.vunmap_local
+ * for device specific handling.
+ */
+void drm_gem_dmabuf_vunmap_local(struct dma_buf *dma_buf, struct dma_buf_map 
*map)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+
+   drm_gem_vunmap_local(obj, map);
+}
+EXPORT_SYMBOL(drm_gem_dmabuf_vunmap_local);
+
 /**
  * drm_gem_prime_mmap - PRIME mmap function for GEM drivers
  * @obj: GEM object
@@ -787,6 +824,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
+   .vmap_local = drm_gem_dmabuf_vmap_local,
+   .vunmap_local = drm_gem_dmabuf_vunmap_local,
 };
 
 /**
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 807a27a16365..fea11a53d8fc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -54,6 +54,8 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops =  {
.mmap = drm_gem_dmabuf_mmap,
.vmap = drm_gem_dmabuf_vmap,
.vunmap = drm_gem_dmabuf_vunmap,
+   .vmap = drm_gem_dmabuf_vmap_local,
+  

[PATCH v3 0/8] drm: Support short-term vmap via vmap_local

[Thomas Zimmermann]

(was: drm/vram-helper: Lock GEM BOs while they are mapped)

GEM VRAM helpers used to pin the BO in their implementation of vmap, so
that they could not be relocated. In recent discussions, [1][2] it became
clear that this is incorrect for in-kernel use cases, such as fbdev
emulation; which should rather depend on the reservation lock to prevent
relocation.

This patchset addresses the issue by introducing the new interfaces
vmap_local and vunmap_local throughout dma-buf and GEM. It further adds
support to DRM's CMA, SHMEM and VRAM helpers and finally converts fbdev
emulation to the new interface.

Patches 1 and 2 prepare the ast cursor code for the later changes.

Patches 3 and 4 add the vmap_local infrastructure throughout dma-buf,
GEM and PRIME.

Patches 5 to 7 add implementations of vmap_local to DRM's various GEM
helper libraries. Due to the simple nature of these libraries, existing
vmap code can be reused easily. Several drivers are updateed as well to
use the new interfaces.

Patch 8 converts generic fbdev emulation to use vmap_local. Only DRM
drivers that use GEM helpers currently use fbdev emulation, so patches
5 to 7 covered all necessary instances.

I smoke-tested the patchset with ast (VRAM helpers), mgag200 (SHMEM) and
vc4 (CMA). I also tested with a version of radeon (raw TTM) that has been
converted to generic fbdev emulation.

v3:
* rewrite patchset around vmap_local
v2:
* make importers acquire resv locks by themselves
* document dma-buf vamp/vunmap ops

[1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1
[2] https://patchwork.freedesktop.org/patch/405407/?series=84401&rev=2

Thomas Zimmermann (8):
  drm/ast: Don't pin cursor source BO explicitly during update
  drm/ast: Only map cursor BOs during updates
  dma-buf: Add vmap_local and vnumap_local operations
  drm/gem: Create infrastructure for GEM vmap_local
  drm/cma-helper: Provide a vmap function for short-term mappings
  drm/shmem-helper: Provide a vmap function for short-term mappings
  drm/vram-helper: Provide a vmap function for short-term mappings
  drm/fb-helper: Move BO locking from DRM client to fbdev damage worker

 drivers/dma-buf/dma-buf.c  |  80 ++
 drivers/gpu/drm/ast/ast_cursor.c   |  70 +++-
 drivers/gpu/drm/ast/ast_drv.h  |   2 -
 drivers/gpu/drm/drm_client.c   |  91 
 drivers/gpu/drm/drm_fb_helper.c|  41 +++
 drivers/gpu/drm/drm_gem.c  |  28 +
 drivers/gpu/drm/drm_gem_cma_helper.c   |  35 ++
 drivers/gpu/drm/drm_gem_shmem_helper.c |  71 -
 drivers/gpu/drm/drm_gem_vram_helper.c  | 142 -
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_prime.c|  39 +++
 drivers/gpu/drm/mgag200/mgag200_mode.c |  16 ++-
 drivers/gpu/drm/tiny/cirrus.c  |  10 +-
 drivers/gpu/drm/tiny/gm12u320.c|  14 ++-
 drivers/gpu/drm/udl/udl_modeset.c  |  18 ++--
 drivers/gpu/drm/vboxvideo/vbox_mode.c  |  15 +--
 drivers/gpu/drm/vc4/vc4_bo.c   |  13 +++
 drivers/gpu/drm/vc4/vc4_drv.h  |   1 +
 drivers/gpu/drm/virtio/virtgpu_prime.c |   2 +
 include/drm/drm_client.h   |   4 +
 include/drm/drm_gem.h  |  20 
 include/drm/drm_gem_cma_helper.h   |   1 +
 include/drm/drm_gem_shmem_helper.h |   2 +
 include/drm/drm_gem_vram_helper.h  |   2 +
 include/drm/drm_prime.h|   2 +
 include/linux/dma-buf.h|  34 ++
 26 files changed, 635 insertions(+), 120 deletions(-)

--
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: cleanup BO size handling v2

[Daniel Vetter]

On Wed, Dec 9, 2020 at 3:10 PM Christian König
 wrote:
>
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->base.size is the original size of the BO in
> arbitrary units, usually bytes.
>
> bo->mem.num_pages is the size in number of pages in the
> resource domain of bo->mem.mem_type.
>
> v2: use the GEM object size instead of the BO size
>
> Signed-off-by: Christian König 
> Reviewed-by: Huang Rui  (v1)

Since Huang checked it already I've just done a cursory lock:

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/mes_v10_1.c|  2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c  | 10 +++---
>  drivers/gpu/drm/nouveau/nouveau_display.c |  6 ++--
>  drivers/gpu/drm/nouveau/nouveau_prime.c   |  4 +--
>  drivers/gpu/drm/nouveau/nv17_fence.c  |  2 +-
>  drivers/gpu/drm/nouveau/nv50_fence.c  |  2 +-
>  drivers/gpu/drm/qxl/qxl_object.h  |  2 +-
>  drivers/gpu/drm/radeon/radeon_cs.c|  3 +-
>  drivers/gpu/drm/radeon/radeon_object.c| 13 
>  drivers/gpu/drm/radeon/radeon_object.h|  4 +--
>  drivers/gpu/drm/radeon/radeon_prime.c |  4 +--
>  drivers/gpu/drm/radeon/radeon_trace.h |  2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c   |  2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c  | 33 ++-
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++
>  drivers/gpu/drm/ttm/ttm_bo_vm.c   |  6 ++--
>  drivers/gpu/drm/ttm/ttm_tt.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_blit.c  |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|  6 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  5 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c|  8 ++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c|  3 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c  |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c   |  7 ++--
>  include/drm/ttm/ttm_bo_api.h  |  9 ++---
>  include/drm/ttm/ttm_resource.h|  1 -
>  36 files changed, 82 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index e5919efca870..c4c93f19d273 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
> dma_buf_attachment *attach,
> case TTM_PL_TT:
> sgt = drm_prime_pages_to_sg(obj->dev,
> bo->tbo.ttm->pages,
> -   bo->tbo.num_pages);
> +   bo->tbo.ttm->num_pages);
> if (IS_ERR(sgt))
> return sgt;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 056cb87d09ea..52bcd1b5582f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
>  {
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
>
> -   if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> +   if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
> return AMDGPU_BO_INVALID_OFFSET;
>
> if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index c6c9723d3d8a..381ecc4788d5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
> if (r < 0)
> return r;
>
> -   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
> +   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
> if (r)
> return r;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index ed47cbac4f75..a99a5cde42dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(str

[PATCH] drm/ttm: cleanup BO size handling v2

[Christian König]

Based on an idea from Dave, but cleaned up a bit.

We had multiple fields for essentially the same thing.

Now bo->base.size is the original size of the BO in
arbitrary units, usually bytes.

bo->mem.num_pages is the size in number of pages in the
resource domain of bo->mem.mem_type.

v2: use the GEM object size instead of the BO size

Signed-off-by: Christian König 
Reviewed-by: Huang Rui  (v1)
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|  4 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  6 ++--
 drivers/gpu/drm/amd/amdgpu/mes_v10_1.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 10 +++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  6 ++--
 drivers/gpu/drm/nouveau/nouveau_prime.c   |  4 +--
 drivers/gpu/drm/nouveau/nv17_fence.c  |  2 +-
 drivers/gpu/drm/nouveau/nv50_fence.c  |  2 +-
 drivers/gpu/drm/qxl/qxl_object.h  |  2 +-
 drivers/gpu/drm/radeon/radeon_cs.c|  3 +-
 drivers/gpu/drm/radeon/radeon_object.c| 13 
 drivers/gpu/drm/radeon/radeon_object.h|  4 +--
 drivers/gpu/drm/radeon/radeon_prime.c |  4 +--
 drivers/gpu/drm/radeon/radeon_trace.h |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c  | 33 ++-
 drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++
 drivers/gpu/drm/ttm/ttm_bo_vm.c   |  6 ++--
 drivers/gpu/drm/ttm/ttm_tt.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c  |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|  6 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  5 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c|  8 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c|  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c  |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c   |  7 ++--
 include/drm/ttm/ttm_bo_api.h  |  9 ++---
 include/drm/ttm/ttm_resource.h|  1 -
 36 files changed, 82 insertions(+), 102 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e5919efca870..c4c93f19d273 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
case TTM_PL_TT:
sgt = drm_prime_pages_to_sg(obj->dev,
bo->tbo.ttm->pages,
-   bo->tbo.num_pages);
+   bo->tbo.ttm->num_pages);
if (IS_ERR(sgt))
return sgt;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 056cb87d09ea..52bcd1b5582f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
 
-   if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
+   if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
 
if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..381ecc4788d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
if (r < 0)
return r;
 
-   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
+   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index ed47cbac4f75..a99a5cde42dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(struct amdgpu_bo 
*bo)
 
 static inline unsigned long amdgpu_bo_size(struct amdgpu_bo *bo)
 {
-   return bo->tbo.num_pages << PAGE_SHIFT;
+   return bo->tbo.base.size;
 }
 
 static inline unsigned amdgpu_bo_ngpu_pages(struct amdgpu_bo *bo)
 {
-   return (bo->tbo.num_pages << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
+   return