[Intel-gfx] [V11 1/4] drm/i915/dsi: Add details about TE in get_config

2020-09-15 Thread Vandita Kulkarni
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.

Signed-off-by: Vandita Kulkarni 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 30 +++---
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 520715b7d5b5..2789020e20db 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1447,6 +1447,18 @@ static bool gen11_dsi_is_periodic_cmd_mode(struct 
intel_dsi *intel_dsi)
return (val & DSI_PERIODIC_FRAME_UPDATE_ENABLE);
 }
 
+static void gen11_dsi_get_cmd_mode_config(struct intel_dsi *intel_dsi,
+ struct intel_crtc_state *pipe_config)
+{
+   if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1 |
+   I915_MODE_FLAG_DSI_USE_TE0;
+   else if (intel_dsi->ports == BIT(PORT_B))
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1;
+   else
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE0;
+}
+
 static void gen11_dsi_get_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
@@ -1468,6 +1480,10 @@ static void gen11_dsi_get_config(struct intel_encoder 
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
 
+   /* Get the details on which TE should be enabled */
+   if (is_cmd_mode(intel_dsi))
+   gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
+
if (gen11_dsi_is_periodic_cmd_mode(intel_dsi))
pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
 }
@@ -1562,18 +1578,8 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
 * receive TE from the slave if
 * dual link is enabled
 */
-   if (is_cmd_mode(intel_dsi)) {
-   if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE1 |
-   I915_MODE_FLAG_DSI_USE_TE0;
-   else if (intel_dsi->ports == BIT(PORT_B))
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE1;
-   else
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE0;
-   }
+   if (is_cmd_mode(intel_dsi))
+   gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
 
return 0;
 }
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V11 4/4] drm/i915/dsi: Initiate fame request in cmd mode

2020-09-15 Thread Vandita Kulkarni
In TE Gate mode or TE NO_GATE mode on every flip
we need to set the frame update request bit.
After this  bit is set transcoder hardware will
automatically send the frame data to the panel
in case of TE NO_GATE mode, where it sends after
it receives the TE event in case of TE_GATE mode.
Once the frame data is sent to the panel, we see
the frame counter updating.

v2: Use intel_de_read/write

v3: remove the usage of private_flags

v4: Use icl_dsi in func names if non static,
fix code formatting issues. (Jani)

Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
 drivers/gpu/drm/i915/display/intel_display.c | 10 
 drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2789020e20db..7d2abc7f6ba3 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host *host,
return 0;
 }
 
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   u32 tmp, flags;
+   enum port port;
+
+   flags = crtc->mode_flags;
+
+   /*
+* case 1 also covers dual link
+* In case of dual link, frame update should be set on
+* DSI_0
+*/
+   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
+   port = PORT_A;
+   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
+   port = PORT_B;
+   else
+   return;
+
+   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
+   tmp |= DSI_FRAME_UPDATE_REQUEST;
+   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp);
+}
+
 static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f862403388f6..11a20bf2255f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_set_cdclk_post_plane_update(state);
}
 
+   /*
+* Incase of mipi dsi command mode, we need to set frame update
+* for every commit
+*/
+   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
+   if (INTEL_GEN(dev_priv) >= 11 &&
+   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
+   if (new_crtc_state->hw.active)
+   icl_dsi_frame_update(new_crtc_state);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
 * already, but still need the state for the delayed optimization. To
 * fix this:
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h 
b/drivers/gpu/drm/i915/display/intel_dsi.h
index 19f78a4022d3..625f2f1ae061 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct 
intel_encoder *encoder)
 
 /* icl_dsi.c */
 void icl_dsi_init(struct drm_i915_private *dev_priv);
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
 
 /* intel_dsi.c */
 int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V11 0/4] Add support for mipi dsi cmd mode

2020-09-15 Thread Vandita Kulkarni
This series contain interrupt handling part of cmd mode.
Configuration patches were merged already.

v10: Address the review comments on patch 3 and 4
v11: fix compilation issue introduced in v10

Vandita Kulkarni (4):
  drm/i915/dsi: Add details about TE in get_config
  i915/dsi: Configure TE interrupt for cmd mode
  drm/i915/dsi: Add TE handler for dsi cmd mode.
  drm/i915/dsi: Initiate fame request in cmd mode

 drivers/gpu/drm/i915/display/icl_dsi.c   |  56 +++--
 drivers/gpu/drm/i915/display/intel_display.c |  10 ++
 drivers/gpu/drm/i915/display/intel_dsi.h |   1 +
 drivers/gpu/drm/i915/i915_irq.c  | 116 ++-
 4 files changed, 169 insertions(+), 14 deletions(-)

-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V11 3/4] drm/i915/dsi: Add TE handler for dsi cmd mode.

2020-09-15 Thread Vandita Kulkarni
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.

If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
immediately send the frame data to the panel.
We are not dealing with the periodic command mode here.

v2: Pass only relevant masked bits to the handler (Jani)

v3: Fix the check for cmd mode in TE handler function.

v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani)

v3: Use static on handler func (Jani)

Signed-off-by: Vandita Kulkarni 
Reported-by: kernel test robot 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_irq.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 913548addfba..4a1f13425108 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2237,6 +2237,64 @@ gen8_de_misc_irq_handler(struct drm_i915_private 
*dev_priv, u32 iir)
drm_err(_priv->drm, "Unexpected DE Misc interrupt\n");
 }
 
+static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
+   u32 te_trigger)
+{
+   enum pipe pipe = INVALID_PIPE;
+   enum transcoder dsi_trans;
+   enum port port;
+   u32 val, tmp;
+
+   /*
+* Incase of dual link, TE comes from DSI_1
+* this is to check if dual link is enabled
+*/
+   val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
+   val &= PORT_SYNC_MODE_ENABLE;
+
+   /*
+* if dual link is enabled, then read DSI_0
+* transcoder registers
+*/
+   port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
+ PORT_A : PORT_B;
+   dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
+
+   /* Check if DSI configured in command mode */
+   val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+   val = val & OP_MODE_MASK;
+
+   if ((val != CMD_MODE_NO_GATE) && (val != CMD_MODE_TE_GATE)) {
+   drm_err(_priv->drm, "DSI trancoder not configured in 
command mode\n");
+   return;
+   }
+
+   /* Get PIPE for handling VBLANK event */
+   val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
+   switch (val & TRANS_DDI_EDP_INPUT_MASK) {
+   case TRANS_DDI_EDP_INPUT_A_ON:
+   pipe = PIPE_A;
+   break;
+   case TRANS_DDI_EDP_INPUT_B_ONOFF:
+   pipe = PIPE_B;
+   break;
+   case TRANS_DDI_EDP_INPUT_C_ONOFF:
+   pipe = PIPE_C;
+   break;
+   default:
+   drm_err(_priv->drm, "Invalid PIPE\n");
+   return;
+   }
+
+   intel_handle_vblank(dev_priv, pipe);
+
+   /* clear TE in dsi IIR */
+   port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
+   tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+   I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+}
+
 static irqreturn_t
 gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
 {
@@ -2301,6 +2359,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
found = true;
}
 
+   if (INTEL_GEN(dev_priv) >= 11) {
+   tmp_mask = iir & (DSI0_TE | DSI1_TE);
+   if (tmp_mask) {
+   
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
+   found = true;
+   }
+   }
+
if (!found)
drm_err(_priv->drm,
"Unexpected DE Port interrupt\n");
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V11 2/4] i915/dsi: Configure TE interrupt for cmd mode

2020-09-15 Thread Vandita Kulkarni
Configure TE interrupt as part of the vblank
enable call flow.

v2: Hide the private flags check inside configure_te (Jani)

v3: Fix the position of masking de_port_masked for DSI_TE.

v4: Simplify the caller of configure_te (Jani)

v5: Clear IIR, remove the usage of private_flags

v6: including icl_dsi header is not needed

Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/i915_irq.c | 50 +++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..913548addfba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2631,12 +2631,47 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
return 0;
 }
 
+static bool gen11_dsi_configure_te(struct intel_crtc *intel_crtc,
+  bool enable)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+   enum port port;
+   u32 tmp;
+
+   if (!(intel_crtc->mode_flags &
+   (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0)))
+   return false;
+
+   /* for dual link cases we consider TE from slave */
+   if (intel_crtc->mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
+   port = PORT_B;
+   else
+   port = PORT_A;
+
+   tmp =  I915_READ(DSI_INTR_MASK_REG(port));
+   if (enable)
+   tmp &= ~DSI_TE_EVENT;
+   else
+   tmp |= DSI_TE_EVENT;
+
+   I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
+
+   tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+   I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+   return true;
+}
+
 int bdw_enable_vblank(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   enum pipe pipe = to_intel_crtc(crtc)->pipe;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
 
+   if (gen11_dsi_configure_te(intel_crtc, true))
+   return 0;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -2702,9 +2737,13 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
 void bdw_disable_vblank(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   enum pipe pipe = to_intel_crtc(crtc)->pipe;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
 
+   if (gen11_dsi_configure_te(intel_crtc, false))
+   return;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -3400,6 +3439,13 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
if (IS_GEN9_LP(dev_priv))
de_port_masked |= BXT_DE_PORT_GMBUS;
 
+   if (INTEL_GEN(dev_priv) >= 11) {
+   enum port port;
+
+   if (intel_bios_is_dsi_present(dev_priv, ))
+   de_port_masked |= DSI0_TE | DSI1_TE;
+   }
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add support for mipi dsi cmd mode (rev10)

2020-09-15 Thread Patchwork
== Series Details ==

Series: Add support for mipi dsi cmd mode (rev10)
URL   : https://patchwork.freedesktop.org/series/69290/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  MODPOST Module.symvers
ERROR: modpost: "icl_dsi_frame_update" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:111: recipe for target 'Module.symvers' failed
make[1]: *** [Module.symvers] Error 1
make[1]: *** Deleting file 'Module.symvers'
Makefile:1388: recipe for target 'modules' failed
make: *** [modules] Error 2


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V10 4/4] drm/i915/dsi: Initiate fame request in cmd mode

2020-09-15 Thread Vandita Kulkarni
In TE Gate mode or TE NO_GATE mode on every flip
we need to set the frame update request bit.
After this  bit is set transcoder hardware will
automatically send the frame data to the panel
in case of TE NO_GATE mode, where it sends after
it receives the TE event in case of TE_GATE mode.
Once the frame data is sent to the panel, we see
the frame counter updating.

v2: Use intel_de_read/write

v3: remove the usage of private_flags

v4: Use icl_dsi in func names if non static,
fix code formatting issues. (Jani)

Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/icl_dsi.c   | 26 
 drivers/gpu/drm/i915/display/intel_display.c | 10 
 drivers/gpu/drm/i915/display/intel_dsi.h |  1 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2789020e20db..8c8b5a195b75 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -205,6 +205,32 @@ static int dsi_send_pkt_payld(struct intel_dsi_host *host,
return 0;
 }
 
+void gen11_dsi_frame_update(struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   u32 tmp, flags;
+   enum port port;
+
+   flags = crtc->mode_flags;
+
+   /*
+* case 1 also covers dual link
+* In case of dual link, frame update should be set on
+* DSI_0
+*/
+   if (flags & I915_MODE_FLAG_DSI_USE_TE0)
+   port = PORT_A;
+   else if (flags & I915_MODE_FLAG_DSI_USE_TE1)
+   port = PORT_B;
+   else
+   return;
+
+   tmp = intel_de_read(dev_priv, DSI_CMD_FRMCTL(port));
+   tmp |= DSI_FRAME_UPDATE_REQUEST;
+   intel_de_write(dev_priv, DSI_CMD_FRMCTL(port), tmp);
+}
+
 static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f862403388f6..11a20bf2255f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15621,6 +15621,16 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_set_cdclk_post_plane_update(state);
}
 
+   /*
+* Incase of mipi dsi command mode, we need to set frame update
+* for every commit
+*/
+   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
+   if (INTEL_GEN(dev_priv) >= 11 &&
+   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI))
+   if (new_crtc_state->hw.active)
+   icl_dsi_frame_update(new_crtc_state);
+
/* FIXME: We should call drm_atomic_helper_commit_hw_done() here
 * already, but still need the state for the delayed optimization. To
 * fix this:
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h 
b/drivers/gpu/drm/i915/display/intel_dsi.h
index 19f78a4022d3..625f2f1ae061 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -167,6 +167,7 @@ static inline u16 intel_dsi_encoder_ports(struct 
intel_encoder *encoder)
 
 /* icl_dsi.c */
 void icl_dsi_init(struct drm_i915_private *dev_priv);
+void icl_dsi_frame_update(struct intel_crtc_state *crtc_state);
 
 /* intel_dsi.c */
 int intel_dsi_bitrate(const struct intel_dsi *intel_dsi);
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V10 0/4] Add support for mipi dsi cmd mode

2020-09-15 Thread Vandita Kulkarni
This series contain interrupt handling part of cmd mode.
Configuration patches were merged already.

v10: Address the review comments on patch 3 and 4

Vandita Kulkarni (4):
  drm/i915/dsi: Add details about TE in get_config
  i915/dsi: Configure TE interrupt for cmd mode
  drm/i915/dsi: Add TE handler for dsi cmd mode.
  drm/i915/dsi: Initiate fame request in cmd mode

 drivers/gpu/drm/i915/display/icl_dsi.c   |  56 +++--
 drivers/gpu/drm/i915/display/intel_display.c |  10 ++
 drivers/gpu/drm/i915/display/intel_dsi.h |   1 +
 drivers/gpu/drm/i915/i915_irq.c  | 116 ++-
 4 files changed, 169 insertions(+), 14 deletions(-)

-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V10 3/4] drm/i915/dsi: Add TE handler for dsi cmd mode.

2020-09-15 Thread Vandita Kulkarni
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.

If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
immediately send the frame data to the panel.
We are not dealing with the periodic command mode here.

v2: Pass only relevant masked bits to the handler (Jani)

v3: Fix the check for cmd mode in TE handler function.

v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani)

v3: Use handler func should be static (Jani),

Signed-off-by: Vandita Kulkarni 
Reported-by: kernel test robot 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_irq.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 913548addfba..4a1f13425108 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2237,6 +2237,64 @@ gen8_de_misc_irq_handler(struct drm_i915_private 
*dev_priv, u32 iir)
drm_err(_priv->drm, "Unexpected DE Misc interrupt\n");
 }
 
+static void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
+   u32 te_trigger)
+{
+   enum pipe pipe = INVALID_PIPE;
+   enum transcoder dsi_trans;
+   enum port port;
+   u32 val, tmp;
+
+   /*
+* Incase of dual link, TE comes from DSI_1
+* this is to check if dual link is enabled
+*/
+   val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
+   val &= PORT_SYNC_MODE_ENABLE;
+
+   /*
+* if dual link is enabled, then read DSI_0
+* transcoder registers
+*/
+   port = ((te_trigger & DSI1_TE && val) || (te_trigger & DSI0_TE)) ?
+ PORT_A : PORT_B;
+   dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
+
+   /* Check if DSI configured in command mode */
+   val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+   val = val & OP_MODE_MASK;
+
+   if ((val != CMD_MODE_NO_GATE) && (val != CMD_MODE_TE_GATE)) {
+   drm_err(_priv->drm, "DSI trancoder not configured in 
command mode\n");
+   return;
+   }
+
+   /* Get PIPE for handling VBLANK event */
+   val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
+   switch (val & TRANS_DDI_EDP_INPUT_MASK) {
+   case TRANS_DDI_EDP_INPUT_A_ON:
+   pipe = PIPE_A;
+   break;
+   case TRANS_DDI_EDP_INPUT_B_ONOFF:
+   pipe = PIPE_B;
+   break;
+   case TRANS_DDI_EDP_INPUT_C_ONOFF:
+   pipe = PIPE_C;
+   break;
+   default:
+   drm_err(_priv->drm, "Invalid PIPE\n");
+   return;
+   }
+
+   intel_handle_vblank(dev_priv, pipe);
+
+   /* clear TE in dsi IIR */
+   port = (te_trigger & DSI1_TE) ? PORT_B : PORT_A;
+   tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+   I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+}
+
 static irqreturn_t
 gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
 {
@@ -2301,6 +2359,14 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
found = true;
}
 
+   if (INTEL_GEN(dev_priv) >= 11) {
+   tmp_mask = iir & (DSI0_TE | DSI1_TE);
+   if (tmp_mask) {
+   
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
+   found = true;
+   }
+   }
+
if (!found)
drm_err(_priv->drm,
"Unexpected DE Port interrupt\n");
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V10 1/4] drm/i915/dsi: Add details about TE in get_config

2020-09-15 Thread Vandita Kulkarni
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.

Signed-off-by: Vandita Kulkarni 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 30 +++---
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 520715b7d5b5..2789020e20db 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1447,6 +1447,18 @@ static bool gen11_dsi_is_periodic_cmd_mode(struct 
intel_dsi *intel_dsi)
return (val & DSI_PERIODIC_FRAME_UPDATE_ENABLE);
 }
 
+static void gen11_dsi_get_cmd_mode_config(struct intel_dsi *intel_dsi,
+ struct intel_crtc_state *pipe_config)
+{
+   if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1 |
+   I915_MODE_FLAG_DSI_USE_TE0;
+   else if (intel_dsi->ports == BIT(PORT_B))
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE1;
+   else
+   pipe_config->mode_flags |= I915_MODE_FLAG_DSI_USE_TE0;
+}
+
 static void gen11_dsi_get_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
@@ -1468,6 +1480,10 @@ static void gen11_dsi_get_config(struct intel_encoder 
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
 
+   /* Get the details on which TE should be enabled */
+   if (is_cmd_mode(intel_dsi))
+   gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
+
if (gen11_dsi_is_periodic_cmd_mode(intel_dsi))
pipe_config->mode_flags |= I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE;
 }
@@ -1562,18 +1578,8 @@ static int gen11_dsi_compute_config(struct intel_encoder 
*encoder,
 * receive TE from the slave if
 * dual link is enabled
 */
-   if (is_cmd_mode(intel_dsi)) {
-   if (intel_dsi->ports == (BIT(PORT_B) | BIT(PORT_A)))
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE1 |
-   I915_MODE_FLAG_DSI_USE_TE0;
-   else if (intel_dsi->ports == BIT(PORT_B))
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE1;
-   else
-   pipe_config->mode_flags |=
-   I915_MODE_FLAG_DSI_USE_TE0;
-   }
+   if (is_cmd_mode(intel_dsi))
+   gen11_dsi_get_cmd_mode_config(intel_dsi, pipe_config);
 
return 0;
 }
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [V10 2/4] i915/dsi: Configure TE interrupt for cmd mode

2020-09-15 Thread Vandita Kulkarni
Configure TE interrupt as part of the vblank
enable call flow.

v2: Hide the private flags check inside configure_te (Jani)

v3: Fix the position of masking de_port_masked for DSI_TE.

v4: Simplify the caller of configure_te (Jani)

v5: Clear IIR, remove the usage of private_flags

v6: including icl_dsi header is not needed

Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/i915_irq.c | 50 +++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..913548addfba 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2631,12 +2631,47 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
return 0;
 }
 
+static bool gen11_dsi_configure_te(struct intel_crtc *intel_crtc,
+  bool enable)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+   enum port port;
+   u32 tmp;
+
+   if (!(intel_crtc->mode_flags &
+   (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0)))
+   return false;
+
+   /* for dual link cases we consider TE from slave */
+   if (intel_crtc->mode_flags & I915_MODE_FLAG_DSI_USE_TE1)
+   port = PORT_B;
+   else
+   port = PORT_A;
+
+   tmp =  I915_READ(DSI_INTR_MASK_REG(port));
+   if (enable)
+   tmp &= ~DSI_TE_EVENT;
+   else
+   tmp |= DSI_TE_EVENT;
+
+   I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
+
+   tmp = I915_READ(DSI_INTR_IDENT_REG(port));
+   I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
+
+   return true;
+}
+
 int bdw_enable_vblank(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   enum pipe pipe = to_intel_crtc(crtc)->pipe;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
 
+   if (gen11_dsi_configure_te(intel_crtc, true))
+   return 0;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -2702,9 +2737,13 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
 void bdw_disable_vblank(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   enum pipe pipe = to_intel_crtc(crtc)->pipe;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
unsigned long irqflags;
 
+   if (gen11_dsi_configure_te(intel_crtc, false))
+   return;
+
spin_lock_irqsave(_priv->irq_lock, irqflags);
bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
@@ -3400,6 +3439,13 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
if (IS_GEN9_LP(dev_priv))
de_port_masked |= BXT_DE_PORT_GMBUS;
 
+   if (INTEL_GEN(dev_priv) >= 11) {
+   enum port port;
+
+   if (intel_bios_is_dsi_present(dev_priv, ))
+   de_port_masked |= DSI0_TE | DSI1_TE;
+   }
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
-- 
2.21.0.5.gaeb582a

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev2)

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ 
platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/81609/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9016_full -> Patchwork_18505_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18505_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18505_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18505_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-hsw:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-idle.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-idle.html

  
Known issues


  Here are the changes found in Patchwork_18505_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@drm_import_export@flink:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#750])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-tglb3/igt@drm_import_exp...@flink.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-tglb6/igt@drm_import_exp...@flink.html

  * igt@gem_exec_schedule@pi-userfault@vecs0:
- shard-skl:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +13 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-skl10/igt@gem_exec_schedule@pi-userfa...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-skl1/igt@gem_exec_schedule@pi-userfa...@vecs0.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-glk:  [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-glk9/igt@i915_pm_rc6_reside...@rc6-idle.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-glk4/igt@i915_pm_rc6_reside...@rc6-idle.html

  * igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html

  * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#2122]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-skl10/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-skl1/igt@kms_flip@plain-flip-ts-check-interrupti...@c-edp1.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-kbl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-kbl6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#49])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-glk6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-glk9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-glk:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/shard-glk6/igt@kms_frontbuffer_track...@fbc-badstride.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/shard-glk7/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
- shard-tglb: [PASS][21] -> [DMESG-WARN][22] 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/display: Ignore 
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL   : https://patchwork.freedesktop.org/series/81718/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9016 -> Patchwork_18506


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18506 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18506, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18506:

### IGT changes ###

 Possible regressions 

  * igt@kms_psr@sprite_plane_onoff:
- fi-kbl-r:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-kbl-r/igt@kms_psr@sprite_plane_onoff.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-kbl-r/igt@kms_psr@sprite_plane_onoff.html

  
Known issues


  Here are the changes found in Patchwork_18506 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_flink_basic@double-flink:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-tgl-y/igt@gem_flink_ba...@double-flink.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-byt-j1900/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-byt-j1900/igt@i915_module_l...@reload.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  
 Possible fixes 

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@gem_s...@basic-each.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_module_load@reload:
- fi-tgl-y:   [DMESG-WARN][13] ([i915#1982] / [k.org#205379]) -> 
[PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@i915_module_l...@reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@kms_busy@basic@flip:
- fi-kbl-x1275:   [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) 
-> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-kbl-x1275/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +2 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][20] ([i915#62] / [i915#92])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18506/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
   [21]: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms (rev2)

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ 
platforms (rev2)
URL   : https://patchwork.freedesktop.org/series/81609/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9016 -> Patchwork_18505


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/index.html

Known issues


  Here are the changes found in Patchwork_18505 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2:  [PASS][1] -> [FAIL][2] ([i915#1888])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_flink_basic@double-flink:
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-tgl-y/igt@gem_flink_ba...@double-flink.html

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-byt-j1900/igt@i915_module_l...@reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-byt-j1900/igt@i915_module_l...@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-u2:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y:   [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_sync@basic-each:
- fi-tgl-y:   [DMESG-WARN][13] ([i915#402]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@gem_s...@basic-each.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-tgl-y/igt@gem_s...@basic-each.html

  * igt@i915_module_load@reload:
- fi-tgl-y:   [DMESG-WARN][15] ([i915#1982] / [k.org#205379]) -> 
[PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-tgl-y/igt@i915_module_l...@reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9016/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18505/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (47 -> 39)
--

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-kbl-x1275 fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_9016 -> Patchwork_18505

 

Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Fix state of PSR2 sub features

2020-09-15 Thread Souza, Jose
On Tue, 2020-09-15 at 14:50 +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 08:56:12PM +, Souza, Jose wrote:
> > On Mon, 2020-09-14 at 23:30 +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 07:57:34PM +, Souza, Jose wrote:
> > > > On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> > > > > On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > > > > > In case PSR2 is disabled by debugfs dc3co_enabled and
> > > > > > psr2_sel_fetch_enabled were still being set causing some code paths
> > > > > > to be executed were it should not.
> > > > > > We have tests for PSR1 and PSR2 so keep those features disabled when
> > > > > > PSR1 is active but PSR2 is supported is important.
> > > > > > 
> > > > > > Cc: Gwan-gyeong Mun <
> > > > > > gwan-gyeong@intel.com
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Cc: Ville Syrjälä <
> > > > > > ville.syrj...@linux.intel.com
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Signed-off-by: José Roberto de Souza <
> > > > > > jose.so...@intel.com
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_psr.c | 11 +++
> > > > > >  1 file changed, 7 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > index 4e09ae61d4aa..6698d0209879 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > > > @@ -962,12 +962,14 @@ static void intel_psr_enable_locked(struct 
> > > > > > drm_i915_private *dev_priv,
> > > > > > dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, 
> > > > > > crtc_state);
> > > > > > dev_priv->psr.busy_frontbuffer_bits = 0;
> > > > > > dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
> > > > > > -   dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
> > > > > > +   dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline &&
> > > > > > + dev_priv->psr.psr2_enabled;
> > > > > > dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
> > > > > > /* DC5/DC6 requires at least 6 idle frames */
> > > > > > val = usecs_to_jiffies(intel_get_frame_time_us(crtc_state) * 6);
> > > > > > dev_priv->psr.dc3co_exit_delay = val;
> > > > > > -   dev_priv->psr.psr2_sel_fetch_enabled = 
> > > > > > crtc_state->enable_psr2_sel_fetch;
> > > > > > +   dev_priv->psr.psr2_sel_fetch_enabled = 
> > > > > > crtc_state->enable_psr2_sel_fetch &&
> > > > > > +  
> > > > > > dev_priv->psr.psr2_enabled;
> > > > > >  
> > > > > > /*
> > > > > >  * If a PSR error happened and the driver is reloaded, the 
> > > > > > EDP_PSR_IIR
> > > > > > @@ -1178,7 +1180,7 @@ void 
> > > > > > intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state 
> > > > > > *crtc_st
> > > > > > struct i915_psr *psr = _priv->psr;
> > > > > >  
> > > > > > if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
> > > > > > -   !crtc_state->enable_psr2_sel_fetch)
> > > > > > +   !dev_priv->psr.psr2_sel_fetch_enabled)
> > > > > > return;
> > > > > >  
> > > > > > intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(psr->transcoder),
> > > > > > @@ -1189,8 +1191,9 @@ void intel_psr2_sel_fetch_update(struct 
> > > > > > intel_atomic_state *state,
> > > > > >  struct intel_crtc *crtc)
> > > > > >  {
> > > > > > struct intel_crtc_state *crtc_state = 
> > > > > > intel_atomic_get_new_crtc_state(state, crtc);
> > > > > > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > > >  
> > > > > > -   if (!crtc_state->enable_psr2_sel_fetch)
> > > > > > +   if (!dev_priv->psr.psr2_sel_fetch_enabled)
> > > > > 
> > > > > This looks rather sketchy. AFAICS this gets called during 
> > > > > atomic_check()
> > > > > so looking at stuff outside the crtc state is very suspicious.
> > > > 
> > > > This is called after the functions that change the PSR state so no 
> > > > issues, also we can't really on information in CRTC state, as PSR is 
> > > > only enabled
> > > > if supported by state, i915 PSR parameter and PSR debug fs value.
> > > 
> > > I see it getting called from intel_crtc_atomic_check(). Confused.
> > > Am I missing some other patches?
> > 
> > It is set from intel_psr_disable(), intel_psr_enable() and 
> > intel_psr_update() all executed before intel_psr2_sel_fetch_update()
> > 
> > intel_enable_ddi()
> > intel_enable_ddi_dp()
> > intel_psr_enable()
> > 
> > intel_update_crtc() {
> > if (!modeset) {
> > intel_encoders_update_pipe()
> > encoder->update_pipe() / intel_ddi_update_pipe()
> > intel_ddi_update_pipe_dp()
> > intel_psr_update()
> > }
> > 
> > ...
> > 
> > 

[Intel-gfx] [PATCH 1/2] drm/i915/display: Ignore IGNORE_PSR2_HW_TRACKING for platforms without sel fetch

2020-09-15 Thread José Roberto de Souza
For platforms without selective fetch this register is reserved so
do not write 0 to it.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8a9d0bdde1bf..4e09ae61d4aa 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -942,7 +942,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val);
}
 
-   if (HAS_PSR_HW_TRACKING(dev_priv))
+   if (HAS_PSR_HW_TRACKING(dev_priv) && HAS_PSR2_SEL_FETCH(dev_priv))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1, IGNORE_PSR2_HW_TRACKING,
 dev_priv->psr.psr2_sel_fetch_enabled ?
 IGNORE_PSR2_HW_TRACKING : 0);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/2] drm/i915/display: Check PSR parameter and flag only in state compute phase

2020-09-15 Thread José Roberto de Souza
Due to the debugfs flag, has_psr2 in CRTC state could have a different
value than psr.psr2_enabled and it was causing PSR2 subfeatures(DC3CO
and selective fetch) to be set to not a expected state.

So here only taking in consideration the parameter and debugfs flag
when computing PSR state, this way the CRTC state will also have
the correct state.

intel_psr_fastset_force() was already broken as
intel_psr_compute_config() was already only enabling PSR when
psr_global_enabled() and all other PSR requirements are met.
So some changes was required in this function, now it iterates over
all connectors, if it is a eDP connector and is active force a modeset
in the CRTC driving this connector, what will cause the new PSR state
to be set based on the debugfs flag.

Cc: Gwan-gyeong Mun 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 65 ++--
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 4e09ae61d4aa..383b66d9f2f2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -91,19 +91,14 @@ static bool psr_global_enabled(struct drm_i915_private 
*i915)
}
 }
 
-static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
-  const struct intel_crtc_state *crtc_state)
+static bool psr2_global_enabled(struct drm_i915_private *dev_priv)
 {
-   /* Cannot enable DSC and PSR2 simultaneously */
-   drm_WARN_ON(_priv->drm, crtc_state->dsc.compression_enable &&
-   crtc_state->has_psr2);
-
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
case I915_PSR_DEBUG_DISABLE:
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
default:
-   return crtc_state->has_psr2;
+   return true;
}
 }
 
@@ -729,6 +724,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (!psr2_global_enabled(dev_priv)) {
+   drm_dbg_kms(_priv->drm, "PSR2 disabled by flag\n");
+   return false;
+   }
+
/*
 * DSC and PSR2 cannot be enabled simultaneously. If a requested
 * resolution requires DSC to be enabled, priority is given to DSC
@@ -817,8 +817,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (intel_dp != dev_priv->psr.dp)
return;
 
-   if (!psr_global_enabled(dev_priv))
+   if (!psr_global_enabled(dev_priv)) {
+   drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
return;
+   }
+
/*
 * HSW spec explicitly says PSR is tied to port A.
 * BDW+ platforms have a instance of PSR registers per transcoder but
@@ -959,7 +962,7 @@ static void intel_psr_enable_locked(struct drm_i915_private 
*dev_priv,
 
drm_WARN_ON(_priv->drm, dev_priv->psr.enabled);
 
-   dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
+   dev_priv->psr.psr2_enabled = crtc_state->has_psr2;
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
dev_priv->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
@@ -1029,15 +1032,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
 
mutex_lock(_priv->psr.lock);
-
-   if (!psr_global_enabled(dev_priv)) {
-   drm_dbg_kms(_priv->drm, "PSR disabled by flag\n");
-   goto unlock;
-   }
-
intel_psr_enable_locked(dev_priv, crtc_state, conn_state);
-
-unlock:
mutex_unlock(_priv->psr.lock);
 }
 
@@ -1222,8 +1217,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
 
mutex_lock(_priv->psr.lock);
 
-   enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
-   psr2_enable = intel_psr2_enabled(dev_priv, crtc_state);
+   enable = crtc_state->has_psr;
+   psr2_enable = crtc_state->has_psr2;
 
if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
@@ -1320,10 +1315,11 @@ static bool __psr_wait_for_idle_locked(struct 
drm_i915_private *dev_priv)
 
 static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
 {
+   struct drm_connector_list_iter conn_iter;
struct drm_device *dev = _priv->drm;
struct drm_modeset_acquire_ctx ctx;
struct drm_atomic_state *state;
-   struct intel_crtc *crtc;
+   struct drm_connector *conn;
int err;
 
state = drm_atomic_state_alloc(dev);
@@ -1334,21 +1330,34 @@ static int intel_psr_fastset_force(struct 
drm_i915_private *dev_priv)
state->acquire_ctx = 
 
 retry:
-   for_each_intel_crtc(dev, crtc) {
-   struct 

[Intel-gfx] [PATCH v2] drm/i915/display: Add max plane width for NV12 AUX plane for Gen10+ platforms

2020-09-15 Thread Aditya Swarup
Gen 10+ and Gen11+ platforms specify different max plane width for
planar formats. Add max plane width for GLK and ICL based on
BSpec: 7666

Fixes: 372b9ffb5799 ("drm/i915: Fix skl+ max plane width")

Cc: Jani Nikula 
Cc: Matt Roper 
Cc: Ville Syrjälä 
Cc: Imre Deak 
Signed-off-by: Aditya Swarup 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f862403388f6..116fed1b7306 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3989,7 +3989,7 @@ static int skl_check_nv12_aux_surface(struct 
intel_plane_state *plane_state)
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
int uv_plane = 1;
-   int max_width = skl_max_plane_width(fb, uv_plane, rotation);
+   int max_width = 0;
int max_height = 4096;
int x = plane_state->uapi.src.x1 >> 17;
int y = plane_state->uapi.src.y1 >> 17;
@@ -3997,6 +3997,13 @@ static int skl_check_nv12_aux_surface(struct 
intel_plane_state *plane_state)
int h = drm_rect_height(_state->uapi.src) >> 17;
u32 offset;
 
+   if (INTEL_GEN(i915) >= 11)
+   max_width = icl_max_plane_width(fb, uv_plane, rotation);
+   else if (INTEL_GEN(i915) >= 10 || IS_GEMINILAKE(i915))
+   max_width = glk_max_plane_width(fb, uv_plane, rotation);
+   else
+   max_width = skl_max_plane_width(fb, uv_plane, rotation);
+
intel_add_fb_offsets(, , plane_state, uv_plane);
offset = intel_plane_compute_aligned_offset(, ,
plane_state, uv_plane);
-- 
2.27.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI] PR for new v49.0.1 GuC binaries

2020-09-15 Thread John . C . Harrison
The following changes since commit d5f9eea5a251d43412b07f5295d03e97b89ac4a5:

  wl18xx: update firmware file 8.9.0.0.83 (2020-09-01 08:07:59 -0400)

are available in the Git repository at:

  ssh://git.freedesktop.org/git/drm/drm-firmware guc_v49

for you to fetch changes up to a5beba43fb3a2b91f4b9de244455351cb2625b6c:

  i915: Add GuC firmware v49.0.1 for all platforms (2020-09-15 17:51:55 -0700)


John Harrison (2):
  i915: Remove duplicate KBL DMC entry
  i915: Add GuC firmware v49.0.1 for all platforms

 WHENCE  |  25 -
 i915/bxt_guc_49.0.1.bin | Bin 0 -> 196224 bytes
 i915/cml_guc_49.0.1.bin | Bin 0 -> 197184 bytes
 i915/ehl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
 i915/glk_guc_49.0.1.bin | Bin 0 -> 196672 bytes
 i915/icl_guc_49.0.1.bin | Bin 0 -> 324160 bytes
 i915/kbl_guc_49.0.1.bin | Bin 0 -> 197184 bytes
 i915/skl_guc_49.0.1.bin | Bin 0 -> 196288 bytes
 i915/tgl_guc_49.0.1.bin | Bin 0 -> 321792 bytes
 9 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 i915/bxt_guc_49.0.1.bin
 create mode 100644 i915/cml_guc_49.0.1.bin
 create mode 100644 i915/ehl_guc_49.0.1.bin
 create mode 100644 i915/glk_guc_49.0.1.bin
 create mode 100644 i915/icl_guc_49.0.1.bin
 create mode 100644 i915/kbl_guc_49.0.1.bin
 create mode 100644 i915/skl_guc_49.0.1.bin
 create mode 100644 i915/tgl_guc_49.0.1.bin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
On Tue, 2020-09-15 at 15:38 -0700, Navare, Manasi wrote:
> On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> > On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > > Since we're about to start adding support for Intel's magic HDR
> > > > backlight interface over DPCD, we need to ensure we're properly
> > > > programming this field so that Intel specific sink services are
> > > > exposed.
> > > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > > 
> > > > We also take care not to reprogram the source OUI if it already
> > > > matches
> > > > what we expect. This is just to be careful so that we don't
> > > > accidentally
> > > > take the panel out of any backlight control modes we found it in.
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: thay...@noraisin.net
> > > > Cc: Vasily Khoruzhick 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_dp.c | 32
> > > > +
> > > >  1 file changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 4bd10456ad188..b591672ec4eab 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -3428,6 +3428,7 @@ void
> > > > intel_dp_sink_set_decompression_state(struct
> > > > intel_dp *intel_dp,
> > > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > > >  {
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > > 
> > > what are these values?
> 
> We in i915 typically use the OUI number for adding any eDP specific
> quirks. I have seen these getting spit out in the dmesg log at thebeginning.
> AFAIK It is some kind of OEM identification number for a display panel.

Are you sure you're not confusing this with the sink OUI btw? We're setting
the source OUI (so, identifying ourselves to the display panel instead of the
other way around) here to tell the panel to expose the Intel specific
backlight controls. My assumption is the { 0x00, 0xaa, 0x01 } is some Intel
driver OUI, it's just I'm not really sure where it comes from other then the
patch I linked to down below

> 
> Manasi
> > I wish I knew, my assumption is this is the OUI that Intel's GPU driver
> > uses on
> > other platforms, but I don't have any documentation mentioning this (in
> > fact,
> > the few documents I do have on this backlight interface don't seem to make
> > any
> > mention of it). I only managed to find this when looking through the last
> > attempt someone did at adding support for this backlight interface:
> > 
> > https://patchwork.freedesktop.org/patch/334989/
> > 
> > I think it should be fairly safe to write, as I know nouveau always
> > programs a
> > source OUI (we don't do it from our driver, but nvidia hardware seems to
> > do it
> > automatically) and I don't believe I've seen it ever change any behavior
> > besides
> > making things appear in the 0x300-0x3ff register range.
> > 
> > AFAICT though, the backlight interface won't advertise itself without this
> > being
> > set early on. If you could find anyone from Intel who knows more about it
> > though
> > I'd definitely appreciate it (and just in general for the rest of the
> > patch
> > series as well)
> > 
> > > > int ret, i;
> > > >  
> > > > /* Should have a valid DPCD by this point */
> > > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > *intel_dp,
> > > > int mode)
> > > > } else {
> > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > > >  
> > > > +   /* Write the source OUI as early as possible */
> > > > +   if (intel_dp_is_edp(intel_dp)) {
> > > > +   ret = drm_dp_dpcd_write(_dp->aux,
> > > > DP_SOURCE_OUI,
> > > > edp_oui,
> > > > +   sizeof(edp_oui));
> > > > +   if (ret < 0)
> > > > +   drm_err(>drm, "Failed to write
> > > > eDP source
> > > > OUI\n");
> > > > +   }
> > > > +
> > > > /*
> > > >  * When turning on, we need to retry for 1ms to give
> > > > the sink
> > > >  * time to wake up.
> > > > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct
> > > > intel_dp
> > > > *intel_dp)
> > > > }
> > > >  }
> > > >  
> > > > +static void
> > > > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > > > +{
> > > > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> > > > +   u8 buf[3] = { 0 };
> > > > +
> > > > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> > > > sizeof(buf)) <
> > > > 0)
> > > > +   drm_err(>drm, "Failed to read source OUI\n");
> > > > +
> > > > +   

Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

2020-09-15 Thread Navare, Manasi
On Mon, Sep 14, 2020 at 10:47:56PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > > > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > > > From: Maarten Lankhorst 
> > > > > > 
> > > > > > Small changes to intel_dp_mode_valid(), allow listing modes that
> > > > > > can only be supported in the bigjoiner configuration, which is
> > > > > > not supported yet.
> > > > > > 
> > > > > > eDP does not support bigjoiner, so do not expose bigjoiner only
> > > > > > modes on the eDP port.
> > > > > > 
> > > > > > v5:
> > > > > > * Increase max plane width to support 8K with bigjoiner (Maarten)
> > > > > > v4:
> > > > > > * Rebase (Manasi)
> > > > > > 
> > > > > > Changes since v1:
> > > > > > - Disallow bigjoiner on eDP.
> > > > > > Changes since v2:
> > > > > > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock,
> > > > > >   and split off the downstream and source checking to its own 
> > > > > > function.
> > > > > >   (Ville)
> > > > > > v3:
> > > > > > * Rebase (Manasi)
> > > > > > 
> > > > > > Signed-off-by: Manasi Navare 
> > > > > > Signed-off-by: Maarten Lankhorst 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/display/intel_display.c |   2 +-
> > > > > >  drivers/gpu/drm/i915/display/intel_dp.c  | 119 
> > > > > > ++-
> > > > > >  2 files changed, 91 insertions(+), 30 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index 78cbfefbfa62..3ecb642805a6 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -17400,7 +17400,7 @@ intel_mode_valid_max_plane_size(struct 
> > > > > > drm_i915_private *dev_priv,
> > > > > >  * too big for that.
> > > > > >  */
> > > > > > if (INTEL_GEN(dev_priv) >= 11) {
> > > > > > -   plane_width_max = 5120;
> > > > > > +   plane_width_max = 7680;
> > > > > 
> > > > > This looks misplaced. Planes do no know whether bigjoiner can be used 
> > > > > or
> > > > > not. They should not care in fact. The caller should have that 
> > > > > knowledge
> > > > > and can deal with it properly.
> > > > 
> > > > Hmm, so the caller of intel_mode_valid_max_plane_size() should check on 
> > > > the bigjoiner
> > > > flag and perhaps if bigjoiner is true then increase the plane_width_max 
> > > > to 7680?
> > > > 
> > > > Am still not sure where this should happen? We need to have the plane 
> > > > max width to be 7680
> > > > before we prune the 8K mode in intel_mode_valid
> > > > 
> > > > Where should this be added according to you?
> > > 
> > > Hmm. I guess we do need to put it into this function given the way this
> > > is structured. However we still can't assume bigjoiner can be used since
> > > it can't be used on DDI A on icl. So we should probably just pass in a
> > > bool here to indicate whether bigjoiner can be used or not.
> > >
> > 
> > So in intel_dp_mode_valid() we set bigjoiner = true if not edp and higher 
> > clock.
> > I think here we need to do the platform check also, 1. because now we are 
> > enabling this for TGL+
> > where big joiner on all pipes. But we should still I think add GEN >=12 
> > check before setting bigjoiner
> > to true in intel_dp_mode_valid() and then pass that to 
> > intel_mode_valid_max_plane_size(..., book bigjoiner)
> 
> can_bigjoiner() {
>   return gen >= 12 || (gen==11 && port!=A);
> }

Hmm, gen check can be done but can the port check be done in 
intel_dp_mode_valid() since we dont have
an encoder yet?
Else we set the bigjoiner to true here based on gen check but add the port 
check later in compute_config at
what point if not supported then encoder config will fail.

or can this be sufficient check:

can_bigjoiner() {
return gen >= 12 || (gen == 11 && !intel_dp_is_edp())
}

Manasi

> 
> or something.
> 
> > 
> > Sounds good?
> > 
> > > Personally I'd just write the thing as something like:
> > > intel_mode_valid_max_plane_size(..., bool bigjoiner)
> > > {
> > >   ...
> > >   plane_width_max = 5120 << bigjoiner;
> > >   ...
> > > }
> > > 
> > > > 
> > > > Manasi
> > > > > 
> > > > > > plane_height_max = 4320;
> > > > > > } else {
> > > > > > plane_width_max = 5120;
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > > > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > index d6295eb20b63..fbfea99fd804 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > > > @@ -248,25 +248,37 @@ intel_dp_max_data_rate(int max_link_clock, 
> > > > > > int max_lanes)
> > > 

Re: [Intel-gfx] [PATCH v6 08/11] drm/i915: Link planes in a bigjoiner configuration, v3.

2020-09-15 Thread Navare, Manasi
On Mon, Sep 14, 2020 at 11:05:42PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:45:59PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:34:12PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> > > > On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > > > > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > > > > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > > > > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > > > > > From: Maarten Lankhorst 
> > > > > > > > 
> > > > > > > >  Make sure that when a plane is set in a bigjoiner mode, we 
> > > > > > > > will add
> > > > > > > >  their counterpart to the atomic state as well. This will allow 
> > > > > > > > us to
> > > > > > > >  make sure all state is available when planes are checked.
> > > > > > > > 
> > > > > > > > Because of the funny interactions with bigjoiner and planar YUV
> > > > > > > > formats, we may end up adding a lot of planes, so we have to 
> > > > > > > > keep
> > > > > > > > iterating until we no longer add any planes.
> > > > > > > > 
> > > > > > > > Also fix the atomic intel plane iterator, so things watermarks 
> > > > > > > > start
> > > > > > > > working automagically.
> > > > > > > > 
> > > > > > > > v5:
> > > > > > > > * Rebase after adding sagv support (Manasi)
> > > > > > > > v4:
> > > > > > > > * Manual rebase (Manasi)
> > > > > > > > Changes since v1:
> > > > > > > > - Rebase on top of plane_state split, cleaning up the code a 
> > > > > > > > lot.
> > > > > > > > - Make intel_atomic_crtc_state_for_each_plane_state() bigjoiner 
> > > > > > > > capable.
> > > > > > > > - Add iter macro to 
> > > > > > > > intel_atomic_crtc_state_for_each_plane_state() to
> > > > > > > >   keep iteration working.
> > > > > > > > Changes since v2:
> > > > > > > > - Add icl_(un)set_bigjoiner_plane_links, to make it more clear 
> > > > > > > > where
> > > > > > > >   links are made and broken.
> > > > > > > > 
> > > > > > > > Signed-off-by: Maarten Lankhorst 
> > > > > > > > 
> > > > > > > > Signed-off-by: Manasi Navare 
> > > > > > > > ---
> > > > > > > >  .../gpu/drm/i915/display/intel_atomic_plane.c |  52 -
> > > > > > > >  .../gpu/drm/i915/display/intel_atomic_plane.h |   3 +-
> > > > > > > >  drivers/gpu/drm/i915/display/intel_display.c  | 207 
> > > > > > > > --
> > > > > > > >  drivers/gpu/drm/i915/display/intel_display.h  |  20 +-
> > > > > > > >  .../drm/i915/display/intel_display_types.h|  11 +
> > > > > > > >  drivers/gpu/drm/i915/intel_pm.c   |  20 +-
> > > > > > > >  6 files changed, 274 insertions(+), 39 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> > > > > > > > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > > index 79032701873a..5c6e72063fac 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > > > > > > > @@ -246,11 +246,17 @@ static void 
> > > > > > > > intel_plane_clear_hw_state(struct intel_plane_state 
> > > > > > > > *plane_state)
> > > > > > > > memset(_state->hw, 0, sizeof(plane_state->hw));
> > > > > > > >  }
> > > > > > > >  
> > > > > > > > -void intel_plane_copy_uapi_to_hw_state(struct 
> > > > > > > > intel_plane_state *plane_state,
> > > > > > > > +void intel_plane_copy_uapi_to_hw_state(const struct 
> > > > > > > > intel_crtc_state *crtc_state,
> > > > > > > > +  struct intel_plane_state 
> > > > > > > > *plane_state,
> > > > > > > >const struct 
> > > > > > > > intel_plane_state *from_plane_state)
> > > > > > > >  {
> > > > > > > > intel_plane_clear_hw_state(plane_state);
> > > > > > > >  
> > > > > > > > +   if (from_plane_state->uapi.crtc)
> > > > > > > > +   plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > > > > +   else
> > > > > > > > +   plane_state->hw.crtc = NULL;
> > > > > > > > +
> > > > > > > > plane_state->hw.crtc = from_plane_state->uapi.crtc;
> > > > > > > 
> > > > > > > eh?
> > > > > > 
> > > > > > Hmm good catch here, this one definitely looks fishy probably got 
> > > > > > messed up in the rebase
> > > > > > so this should just be:
> > > > > > 
> > > > > >  if (from_plane_state->uapi.crtc)
> > > > > > plane_state->hw.crtc = crtc_state->uapi.crtc;
> > > > > > else
> > > > > >  plane_state->hw.crtc = NULL;
> > > > > > 
> > > > > > And the reassignmnet of plane_state->hw.crtc should be removed.
> > > > > > 
> > > > > > Good?
> > > > > 
> > > > > The if-else seems totally pointless.
> > > > >
> > > > 
> > > > Hmm yes so we assume that if from_plane_state->uapi.crtc is NULL then 
> > > > crtc_state->uapi.crtc is NULL?
> > > > Then just have  plane_state->hw.crtc = crtc_state->uapi.crtc; 

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Navare, Manasi
On Tue, Sep 15, 2020 at 03:47:01PM -0400, Lyude Paul wrote:
> On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> > On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > > Since we're about to start adding support for Intel's magic HDR
> > > backlight interface over DPCD, we need to ensure we're properly
> > > programming this field so that Intel specific sink services are exposed.
> > > Otherwise, 0x300-0x3ff will just read zeroes.
> > > 
> > > We also take care not to reprogram the source OUI if it already matches
> > > what we expect. This is just to be careful so that we don't accidentally
> > > take the panel out of any backlight control modes we found it in.
> > > 
> > > Signed-off-by: Lyude Paul 
> > > Cc: thay...@noraisin.net
> > > Cc: Vasily Khoruzhick 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> > >  1 file changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 4bd10456ad188..b591672ec4eab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > > intel_dp *intel_dp,
> > >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> > >  {
> > >   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> > 
> > what are these values?

We in i915 typically use the OUI number for adding any eDP specific
quirks. I have seen these getting spit out in the dmesg log at thebeginning.
AFAIK It is some kind of OEM identification number for a display panel.

Manasi
> 
> I wish I knew, my assumption is this is the OUI that Intel's GPU driver uses 
> on
> other platforms, but I don't have any documentation mentioning this (in fact,
> the few documents I do have on this backlight interface don't seem to make any
> mention of it). I only managed to find this when looking through the last
> attempt someone did at adding support for this backlight interface:
> 
> https://patchwork.freedesktop.org/patch/334989/
> 
> I think it should be fairly safe to write, as I know nouveau always programs a
> source OUI (we don't do it from our driver, but nvidia hardware seems to do it
> automatically) and I don't believe I've seen it ever change any behavior 
> besides
> making things appear in the 0x300-0x3ff register range.
> 
> AFAICT though, the backlight interface won't advertise itself without this 
> being
> set early on. If you could find anyone from Intel who knows more about it 
> though
> I'd definitely appreciate it (and just in general for the rest of the patch
> series as well)
> 
> > 
> > >   int ret, i;
> > >  
> > >   /* Should have a valid DPCD by this point */
> > > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > > int mode)
> > >   } else {
> > >   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > >  
> > > + /* Write the source OUI as early as possible */
> > > + if (intel_dp_is_edp(intel_dp)) {
> > > + ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > > edp_oui,
> > > + sizeof(edp_oui));
> > > + if (ret < 0)
> > > + drm_err(>drm, "Failed to write eDP source
> > > OUI\n");
> > > + }
> > > +
> > >   /*
> > >* When turning on, we need to retry for 1ms to give the sink
> > >* time to wake up.
> > > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct 
> > > intel_dp
> > > *intel_dp)
> > >   }
> > >  }
> > >  
> > > +static void
> > > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > > +{
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 oui[] = { 0x00, 0xaa, 0x01 };
> > > + u8 buf[3] = { 0 };
> > > +
> > > + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > > 0)
> > > + drm_err(>drm, "Failed to read source OUI\n");
> > > +
> > > + if (memcmp(oui, buf, sizeof(oui)) == 0)
> > > + return;
> > > +
> > > + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > > 0)
> > > + drm_err(>drm, "Failed to write source OUI\n");
> > > +}
> > > +
> > >  static bool
> > >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >  {
> > > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > >   intel_dp_get_dsc_sink_cap(intel_dp);
> > >  
> > > + /*
> > > +  * Program our source OUI so we can make various Intel-specific AUX
> > > +  * services available (such as HDR backlight controls)
> > > +  */
> > > + intel_edp_init_source_oui(intel_dp);
> > 
> > I believe we should restrict this to the supported platforms: cfl, whl, cml,
> > icl, tgl
> > no?
> > 
> > > +
> > >   return true;
> > >  }
> > >  
> > 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Add support for Intel's eDP backlight controls
URL   : https://patchwork.freedesktop.org/series/81702/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9013_full -> Patchwork_18504_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_18504_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@intel-bb-blit-y:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +9 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-skl1/igt@api_intel...@intel-bb-blit-y.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-skl5/igt@api_intel...@intel-bb-blit-y.html

  * igt@gem_exec_reloc@basic-many-active@vecs0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#2389]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-glk9/igt@gem_exec_reloc@basic-many-act...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-glk9/igt@gem_exec_reloc@basic-many-act...@vecs0.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / 
[i915#716])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-skl6/igt@gen9_exec_pa...@allowed-single.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-skl7/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-iclb2/igt@i915_pm...@dc6-psr.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-iclb4/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@mock@contexts:
- shard-apl:  [PASS][9] -> [INCOMPLETE][10] ([i915#1635] / 
[i915#2278])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-apl1/igt@i915_selftest@m...@contexts.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-apl4/igt@i915_selftest@m...@contexts.html

  * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-kbl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-kbl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html

  * igt@kms_flip_tiling@flip-x-tiled:
- shard-kbl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-kbl3/igt@kms_flip_til...@flip-x-tiled.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-kbl1/igt@kms_flip_til...@flip-x-tiled.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-tglb: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +2 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-tglb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-glk4/igt@kms_frontbuffer_track...@fbc-badstride.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-glk1/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20] ([i915#123])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-skl5/igt@kms_frontbuffer_track...@psr-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-skl1/igt@kms_frontbuffer_track...@psr-suspend.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][21] -> [FAIL][22] ([i915#1188]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-skl10/igt@kms_...@bpc-switch-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-skl8/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl:  [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html

  * igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][25] 

Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Program PSR2 selective fetch registers

2020-09-15 Thread Souza, Jose
On Tue, 2020-09-15 at 20:28 +0100, Mun, Gwan-gyeong wrote:
> On Mon, 2020-09-14 at 13:15 -0700, Souza, Jose wrote:
> > On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza
> > > wrote:
> > > > Another step towards PSR2 selective fetch, here programming plane
> > > > selective fetch registers and MAN_TRK_CTL enabling selective
> > > > fetch but
> > > > for now it is fetching the whole area of the planes.
> > > > The damaged area calculation will come as next and final step.
> > > > 
> > > > BSpec: 55229
> > > > Cc: Gwan-gyeong Mun <
> > > > gwan-gyeong@intel.com
> > > > 
> > > > Cc: Ville Syrjälä <
> > > > ville.syrj...@linux.intel.com
> > > > 
> > > > Signed-off-by: José Roberto de Souza <
> > > > jose.so...@intel.com
> > > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_display.c  |  10 +-
> > > >  .../drm/i915/display/intel_display_types.h|   2 +
> > > >  drivers/gpu/drm/i915/display/intel_psr.c  | 129
> > > > +-
> > > >  drivers/gpu/drm/i915/display/intel_psr.h  |  10 +-
> > > >  drivers/gpu/drm/i915/display/intel_sprite.c   |   3 +
> > > >  5 files changed, 145 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index c8b1dd1a9e46..865486e89915 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -11799,6 +11799,9 @@ static void i9xx_update_cursor(struct
> > > > intel_plane *plane,
> > > > if (INTEL_GEN(dev_priv) >= 9)
> > > > skl_write_cursor_wm(plane, crtc_state);
> > > >  
> > > > +   if (!needs_modeset(crtc_state))
> > > > +   intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > > plane_state, 0);
> > > > +
> > > > if (plane->cursor.base != base ||
> > > > plane->cursor.size != fbc_ctl ||
> > > > plane->cursor.cntl != cntl) {
> > > > @@ -12810,8 +12813,11 @@ static int
> > > > intel_crtc_atomic_check(struct intel_atomic_state *state,
> > > >  
> > > > }
> > > >  
> > > > -   if (!mode_changed)
> > > > -   intel_psr2_sel_fetch_update(state, crtc);
> > > > +   if (!mode_changed) {
> > > > +   ret = intel_psr2_sel_fetch_update(state, crtc);
> > > > +   if (ret)
> > > > +   return ret;
> > > > +   }
> > > >  
> > > > return 0;
> > > >  }
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index 9349b15afff6..2138bb0f1587 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -586,6 +586,8 @@ struct intel_plane_state {
> > > > u32 planar_slave;
> > > >  
> > > > struct drm_intel_sprite_colorkey ckey;
> > > > +
> > > > +   struct drm_rect psr2_sel_fetch_area;
> > > >  };
> > > >  
> > > >  struct intel_initial_plane_config {
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 6698d0209879..b60ea133a527 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -1173,6 +1173,46 @@ static void
> > > > psr_force_hw_tracking_exit(struct drm_i915_private *dev_priv)
> > > > intel_psr_exit(dev_priv);
> > > >  }
> > > >  
> > > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > > *plane,
> > > > +   const struct intel_crtc_state
> > > > *crtc_state,
> > > > +   const struct intel_plane_state
> > > > *plane_state,
> > > > +   int color_plane)
> > > > +{
> > > > +   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > > > +   const struct drm_rect *clip;
> > > > +   enum pipe pipe = plane->pipe;
> > > > +   u32 val;
> > > > +
> > > > +   if (!plane_state || !dev_priv->psr.psr2_sel_fetch_enabled)
> > > > +   return;
> > > > +
> > > > +   /*
> > > > +* skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for
> > > > gen11+, so
> > > > +* plane_state->ctl is the right value
> > > > +*/
> 
> As per Bspec 50420,  "SEL_FETCH_PLANE_CTL[31]: Selective Fetch Plane
> Enable bit" should be set.
> And when "PSR2_MAN_TRK_CTL[1] : SF Partial Frame Enable bit" is enabled
> selective fetch will be applied.

Bit 31 from PLANE_CTL is the enabled bit all the other fields are spare so we 
can program it without issues.

> 
> > > > +   intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > > > > id), plane_state->ctl);
> 
> As per 
> > > > +   if (!plane_state->ctl || plane->id == PLANE_CURSOR)
> > 

Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Thomas Gleixner
On Tue, Sep 15 2020 at 10:35, Linus Torvalds wrote:
> On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner  wrote:
>>
>> OTOH, having a working 'preemptible()' or maybe better named
>> 'can_schedule()' check makes tons of sense to make decisions about
>> allocation modes or other things.
>
> No. I think that those kinds of decisions about actual behavior are
> always simply fundamentally wrong.
>
> Note that this is very different from having warnings about invalid
> use. THAT is correct. It may not warn in all configurations, but that
> doesn't matter: what matters is that it warns in common enough
> configurations that developers will catch it.

You wish. I just found a 7 year old bug in a 10G network driver which
surely would have been found if people would enable debug configs and
not just run the crap on their PREEMPT_NONE, all debug off kernel. And
that driver is not subject to bitrot, it gets regular bug fixes from
people who seem to care (distro folks).

> So having a warning in "might_sleep()" that doesn't always trigger,
> because you have a limited configuration that can't even detect the
> situation, that's fine and dandy and intentional.

and lets people get away with their crap.

> But having code like
>
>if (can_schedule())
>.. do something different ..
>
> is fundamentally complete and utter garbage.
>
> It's one thing if you test for "am I in hardware interrupt context".
> Those tests aren't great either, but at least they make sense.

They make sense in limited situations like exception handlers and such
which really have to know from which context an exception was raised.

But with the above reasoning such checks do not make sense in any other
general code. 'in hard interrupt context' is just another context where
you can't do stuff which you can do when in preemptible task context.

Most tests are way broader than a single context. in_interrupt() is true
for hard interrupt, soft interrupt delivery and all BH disabled
contexts, which is completely ill defined.

> But a driver - or some library routine - making a difference based on
> some nebulous "can I schedule" is fundamentally and basically WRONG.
>
> If some code changes behavior, it needs to be explicit to the *caller*
> of that code.

I'm fine with that, but then we have to be consequent and ban _all_ of
these and not just declare can_schedule() to be a bad one.

Thanks,

tglx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81688/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9012_full -> Patchwork_18502_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18502_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18502_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18502_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_prime@basic-crc@second-to-first:
- shard-tglb: NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-tglb8/igt@kms_prime@basic-...@second-to-first.html

  
 Warnings 

  * igt@runner@aborted:
- shard-skl:  [FAIL][2] ([i915#1611] / [i915#2029]) -> ([FAIL][3], 
[FAIL][4]) ([i915#1436])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl5/igt@run...@aborted.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl8/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl3/igt@run...@aborted.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@core_hotunplug@hotrebind-lateclose}:
- shard-skl:  [FAIL][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl3/igt@core_hotunp...@hotrebind-lateclose.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl8/igt@core_hotunp...@hotrebind-lateclose.html

  
Known issues


  Here are the changes found in Patchwork_18502_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@intel-bb-blit-y:
- shard-skl:  [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +11 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl9/igt@api_intel...@intel-bb-blit-y.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl9/igt@api_intel...@intel-bb-blit-y.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][9] -> [DMESG-WARN][10] ([i915#1436] / 
[i915#716])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl3/igt@gen9_exec_pa...@allowed-single.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#300])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw:  [PASS][13] -> [FAIL][14] ([i915#2370])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-glk4/igt@kms_frontbuffer_track...@fbc-badstride.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-glk2/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-tglb3/igt@kms_frontbuffer_track...@fbc-shrfb-scaledprimary.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-tglb7/igt@kms_frontbuffer_track...@fbc-shrfb-scaledprimary.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl:  [PASS][19] -> [DMESG-FAIL][20] ([fdo#108145] / 
[i915#1982])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html

  * igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar 
issue
   [21]: 

Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
On Tue, 2020-09-15 at 15:06 -0400, Rodrigo Vivi wrote:
> On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> > Since we're about to start adding support for Intel's magic HDR
> > backlight interface over DPCD, we need to ensure we're properly
> > programming this field so that Intel specific sink services are exposed.
> > Otherwise, 0x300-0x3ff will just read zeroes.
> > 
> > We also take care not to reprogram the source OUI if it already matches
> > what we expect. This is just to be careful so that we don't accidentally
> > take the panel out of any backlight control modes we found it in.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4bd10456ad188..b591672ec4eab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct
> > intel_dp *intel_dp,
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> >  {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
> 
> what are these values?

I wish I knew, my assumption is this is the OUI that Intel's GPU driver uses on
other platforms, but I don't have any documentation mentioning this (in fact,
the few documents I do have on this backlight interface don't seem to make any
mention of it). I only managed to find this when looking through the last
attempt someone did at adding support for this backlight interface:

https://patchwork.freedesktop.org/patch/334989/

I think it should be fairly safe to write, as I know nouveau always programs a
source OUI (we don't do it from our driver, but nvidia hardware seems to do it
automatically) and I don't believe I've seen it ever change any behavior besides
making things appear in the 0x300-0x3ff register range.

AFAICT though, the backlight interface won't advertise itself without this being
set early on. If you could find anyone from Intel who knows more about it though
I'd definitely appreciate it (and just in general for the rest of the patch
series as well)

> 
> > int ret, i;
> >  
> > /* Should have a valid DPCD by this point */
> > @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > +   /* Write the source OUI as early as possible */
> > +   if (intel_dp_is_edp(intel_dp)) {
> > +   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI,
> > edp_oui,
> > +   sizeof(edp_oui));
> > +   if (ret < 0)
> > +   drm_err(>drm, "Failed to write eDP source
> > OUI\n");
> > +   }
> > +
> > /*
> >  * When turning on, we need to retry for 1ms to give the sink
> >  * time to wake up.
> > @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp
> > *intel_dp)
> > }
> >  }
> >  
> > +static void
> > +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +   u8 oui[] = { 0x00, 0xaa, 0x01 };
> > +   u8 buf[3] = { 0 };
> > +
> > +   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) <
> > 0)
> > +   drm_err(>drm, "Failed to read source OUI\n");
> > +
> > +   if (memcmp(oui, buf, sizeof(oui)) == 0)
> > +   return;
> > +
> > +   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
> > 0)
> > +   drm_err(>drm, "Failed to write source OUI\n");
> > +}
> > +
> >  static bool
> >  intel_edp_init_dpcd(struct intel_dp *intel_dp)
> >  {
> > @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > intel_dp_get_dsc_sink_cap(intel_dp);
> >  
> > +   /*
> > +* Program our source OUI so we can make various Intel-specific AUX
> > +* services available (such as HDR backlight controls)
> > +*/
> > +   intel_edp_init_source_oui(intel_dp);
> 
> I believe we should restrict this to the supported platforms: cfl, whl, cml,
> icl, tgl
> no?
> 
> > +
> > return true;
> >  }
> >  
> > -- 
> > 2.26.2
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Sincerely,
  Lyude Paul (she/her)
  Software Engineer at Red Hat

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Program PSR2 selective fetch registers

2020-09-15 Thread Mun, Gwan-gyeong
On Mon, 2020-09-14 at 13:15 -0700, Souza, Jose wrote:
> On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza
> > wrote:
> > > Another step towards PSR2 selective fetch, here programming plane
> > > selective fetch registers and MAN_TRK_CTL enabling selective
> > > fetch but
> > > for now it is fetching the whole area of the planes.
> > > The damaged area calculation will come as next and final step.
> > > 
> > > BSpec: 55229
> > > Cc: Gwan-gyeong Mun <
> > > gwan-gyeong@intel.com
> > > Cc: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > > Signed-off-by: José Roberto de Souza <
> > > jose.so...@intel.com
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_display.c  |  10 +-
> > >  .../drm/i915/display/intel_display_types.h|   2 +
> > >  drivers/gpu/drm/i915/display/intel_psr.c  | 129
> > > +-
> > >  drivers/gpu/drm/i915/display/intel_psr.h  |  10 +-
> > >  drivers/gpu/drm/i915/display/intel_sprite.c   |   3 +
> > >  5 files changed, 145 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index c8b1dd1a9e46..865486e89915 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -11799,6 +11799,9 @@ static void i9xx_update_cursor(struct
> > > intel_plane *plane,
> > >   if (INTEL_GEN(dev_priv) >= 9)
> > >   skl_write_cursor_wm(plane, crtc_state);
> > >  
> > > + if (!needs_modeset(crtc_state))
> > > + intel_psr2_program_plane_sel_fetch(plane, crtc_state,
> > > plane_state, 0);
> > > +
> > >   if (plane->cursor.base != base ||
> > >   plane->cursor.size != fbc_ctl ||
> > >   plane->cursor.cntl != cntl) {
> > > @@ -12810,8 +12813,11 @@ static int
> > > intel_crtc_atomic_check(struct intel_atomic_state *state,
> > >  
> > >   }
> > >  
> > > - if (!mode_changed)
> > > - intel_psr2_sel_fetch_update(state, crtc);
> > > + if (!mode_changed) {
> > > + ret = intel_psr2_sel_fetch_update(state, crtc);
> > > + if (ret)
> > > + return ret;
> > > + }
> > >  
> > >   return 0;
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 9349b15afff6..2138bb0f1587 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -586,6 +586,8 @@ struct intel_plane_state {
> > >   u32 planar_slave;
> > >  
> > >   struct drm_intel_sprite_colorkey ckey;
> > > +
> > > + struct drm_rect psr2_sel_fetch_area;
> > >  };
> > >  
> > >  struct intel_initial_plane_config {
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 6698d0209879..b60ea133a527 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -1173,6 +1173,46 @@ static void
> > > psr_force_hw_tracking_exit(struct drm_i915_private *dev_priv)
> > >   intel_psr_exit(dev_priv);
> > >  }
> > >  
> > > +void intel_psr2_program_plane_sel_fetch(struct intel_plane
> > > *plane,
> > > + const struct intel_crtc_state
> > > *crtc_state,
> > > + const struct intel_plane_state
> > > *plane_state,
> > > + int color_plane)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > > + const struct drm_rect *clip;
> > > + enum pipe pipe = plane->pipe;
> > > + u32 val;
> > > +
> > > + if (!plane_state || !dev_priv->psr.psr2_sel_fetch_enabled)
> > > + return;
> > > +
> > > + /*
> > > +  * skl_plane_ctl_crtc()/i9xx_cursor_ctl_crtc() return 0 for
> > > gen11+, so
> > > +  * plane_state->ctl is the right value
> > > +  */
As per Bspec 50420,  "SEL_FETCH_PLANE_CTL[31]: Selective Fetch Plane
Enable bit" should be set.
And when "PSR2_MAN_TRK_CTL[1] : SF Partial Frame Enable bit" is enabled
selective fetch will be applied.

> > > + intel_de_write_fw(dev_priv, PLANE_SEL_FETCH_CTL(pipe, plane-
> > > >id), plane_state->ctl);
As per 
> > > + if (!plane_state->ctl || plane->id == PLANE_CURSOR)
> > > + return;
> > > +
> > > + clip = _state->psr2_sel_fetch_area;
> > > +
> > > + val = (clip->y1 + plane_state->uapi.crtc_y) << 16;
> > 
> > crtc_x/y are the raw values usrspace gave us. That is definitely
> > not
> > what we should be looking at.
> 
> plane_state->uapi.dst then? but for what I found crtc_x/y is set from
> dst.
> 
> plane_state->uapi.dst is used in skl_program_plane()
> 
> skl_program_plane()
>   int crtc_x = plane_state->uapi.dst.x1;
>   int crtc_y = plane_state->uapi.dst.y1;
>   ...
>   intel_de_write_fw(dev_priv, PLANE_POS(pipe, plane_id), (crtc_y
> << 16) | crtc_x);
> 
> 
> > As the 

Re: [Intel-gfx] [RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:38PM -0400, Lyude Paul wrote:
> So-recently a bunch of laptops on the market have started using DPCD
> backlight controls instead of the traditional DDI backlight controls.
> Originally we thought we had this handled by adding VESA backlight
> control support to i915, but the story ended up being a lot more
> complicated then that.
> 
> Simply put-there's two main backlight interfaces Intel can see in the
> wild. Intel's proprietary HDR backlight interface, and the standard VESA
> backlight interface. Note that many panels have been observed to report
> support for both backlight interfaces, but testing has shown far more
> panels work with the Intel HDR backlight interface at the moment.
> Additionally, the VBT appears to be capable of reporting support for the
> VESA backlight interface but not the Intel HDR interface which needs to
> be probed by setting the right magic OUI.
> 
> On top of that however, there's also actually two different variants of
> the Intel HDR backlight interface. The first uses the AUX channel for
> controlling the brightness of the screen in both SDR and HDR mode, and
> the second only uses the AUX channel for setting the brightness level in
> HDR mode - relying on PWM for setting the brightness level in SDR mode.
> 
> For the time being we've been using EDIDs to maintain a list of quirks
> for panels that safely do support the VESA backlight interface. Adding
> support for Intel's HDR backlight interface in addition however, should
> finally allow us to auto-detect eDP backlight controls properly so long
> as we probe like so:
> 
> * If the panel's VBT reports VESA backlight support, assume it really
>   does support it
> * If the panel's VBT reports DDI backlight controls:
>   * First probe for Intel's HDR backlight interface
>   * If that fails, probe for VESA's backlight interface
>   * If that fails, assume no DPCD backlight control
> * If the panel's VBT reports any other backlight type: just assume it
>   doesn't have DPCD backlight controls
> 
> Note as well that in order for us to make Intel's HDR backlight
> interface appear, we need to start programming the appropriate source
> OUI on the eDP panel as early as possible in the probing process. Note
> that this technically could be done at any time before setting up
> backlight controls, but this way allows us to avoid re-writing it
> multiple times in case we need to use other source-OUI enabled features
> in the future.
> 
> Finally, we also make sure to document the registers for this backlight
> interface since eventually, we want to actually implement the full
> interface instead of keeping it in SDR mode.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  .../drm/i915/display/intel_display_types.h|   9 +-
>  .../drm/i915/display/intel_dp_aux_backlight.c | 384 +++---
>  drivers/gpu/drm/i915/display/intel_panel.c|  34 +-
>  drivers/gpu/drm/i915/display/intel_panel.h|   4 +
>  drivers/gpu/drm/i915/i915_params.c|   2 +-
>  5 files changed, 381 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 52a6543df842a..9d540368bac89 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -230,7 +230,14 @@ struct intel_panel {
>   struct pwm_state pwm_state;
>  
>   /* DPCD backlight */
> - u8 pwmgen_bit_count;
> + union {
> + struct {
> + u8 pwmgen_bit_count;
> + } vesa;
> + struct {
> + bool sdr_uses_aux;
> + } intel;
> + } edp;
>  
>   struct {
>   int (*setup)(struct intel_connector *connector, enum 
> pipe pipe);
> 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 acbd7eb66cbe3..aa1429302db70 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -22,10 +22,251 @@
>   *
>   */
>  
> +/*
> + * Laptops with Intel GPUs which have panels that support controlling the
> + * backlight through DP AUX can actually use two different interfaces: 
> Intel's
> + * proprietary DP AUX backlight interface, and the standard VESA backlight
> + * interface. Unfortunately, at the time of writing this a lot of laptops 
> will
> + * advertise support for the standard VESA backlight interface when they
> + * don't properly support it. However, on these systems the Intel backlight
> + * interface generally does work properly. Additionally, these systems will
> + * usually just indicate that they use PWM backlight controls in their VBIOS
> + * for some reason.
> + */
> +
>  

Re: [Intel-gfx] [RFC 2/5] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:36PM -0400, Lyude Paul wrote:
> Since we're going to need to add a set of lower-level PWM backlight
> control hooks to be shared by normal backlight controls and HDR
> backlight controls in SDR mode, let's add a prefix to the external PWM
> backlight functions so that the difference between them and the high
> level PWM-only backlight functions is a bit more obvious.

it looks like a good idea to me:

Reviewed-by: Rodrigo Vivi 

> 
> This introduces no functional changes.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 9f23bac0d7924..c0e36244bb07d 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
> *connector)
>BXT_BLC_PWM_DUTY(panel->backlight.controller));
>  }
>  
> -static u32 pwm_get_backlight(struct intel_connector *connector)
> +static u32 ext_pwm_get_backlight(struct intel_connector *connector)
>  {
>   struct intel_panel *panel = >panel;
>   struct pwm_state state;
> @@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
> drm_connector_state *conn_state, u32
>  BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
>  }
>  
> -static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
> u32 level)
> +static void ext_pwm_set_backlight(const struct drm_connector_state 
> *conn_state, u32 level)
>  {
>   struct intel_panel *panel = 
> _intel_connector(conn_state->connector)->panel;
>  
> @@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
> drm_connector_state *old_conn_sta
>  tmp & ~BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
> +static void ext_pwm_disable_backlight(const struct drm_connector_state 
> *old_conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(old_conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>  pwm_ctl | BXT_BLC_PWM_ENABLE);
>  }
>  
> -static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
> -  const struct drm_connector_state *conn_state)
> +static void ext_pwm_enable_backlight(const struct intel_crtc_state 
> *crtc_state,
> +  const struct drm_connector_state 
> *conn_state)
>  {
>   struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>   struct intel_panel *panel = >panel;
> @@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
> enum pipe unused)
>   return 0;
>  }
>  
> -static int pwm_setup_backlight(struct intel_connector *connector,
> -enum pipe pipe)
> +static int ext_pwm_setup_backlight(struct intel_connector *connector,
> +enum pipe pipe)
>  {
>   struct drm_device *dev = connector->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
> *panel)
>   panel->backlight.hz_to_pwm = pch_hz_to_pwm;
>   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
>   if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
> - panel->backlight.setup = pwm_setup_backlight;
> - panel->backlight.enable = pwm_enable_backlight;
> - panel->backlight.disable = pwm_disable_backlight;
> - panel->backlight.set = pwm_set_backlight;
> - panel->backlight.get = pwm_get_backlight;
> + panel->backlight.setup = ext_pwm_setup_backlight;
> + panel->backlight.enable = ext_pwm_enable_backlight;
> + panel->backlight.disable = ext_pwm_disable_backlight;
> + panel->backlight.set = ext_pwm_set_backlight;
> + panel->backlight.get = ext_pwm_get_backlight;
>   } else {
>   panel->backlight.setup = vlv_setup_backlight;
>   panel->backlight.enable = vlv_enable_backlight;
> -- 
> 2.26.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Rodrigo Vivi
On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
> 
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
> 
> Signed-off-by: Lyude Paul 
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 32 +
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..b591672ec4eab 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct 
> intel_dp *intel_dp,
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
>  {
>   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 edp_oui[] = { 0x00, 0xaa, 0x01 };

what are these values?

>   int ret, i;
>  
>   /* Should have a valid DPCD by this point */
> @@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
> mode)
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp)) {
> + ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, 
> edp_oui,
> + sizeof(edp_oui));
> + if (ret < 0)
> + drm_err(>drm, "Failed to write eDP source 
> OUI\n");
> + }
> +
>   /*
>* When turning on, we need to retry for 1ms to give the sink
>* time to wake up.
> @@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };
> + u8 buf[3] = { 0 };
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 
> 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
> < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
>  static bool
>  intel_edp_init_dpcd(struct intel_dp *intel_dp)
>  {
> @@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   intel_dp_get_dsc_sink_cap(intel_dp);
>  
> + /*
> +  * Program our source OUI so we can make various Intel-specific AUX
> +  * services available (such as HDR backlight controls)
> +  */
> + intel_edp_init_source_oui(intel_dp);

I believe we should restrict this to the supported platforms: cfl, whl, cml, 
icl, tgl
no?

> +
>   return true;
>  }
>  
> -- 
> 2.26.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Add support for Intel's eDP backlight controls
URL   : https://patchwork.freedesktop.org/series/81702/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9013 -> Patchwork_18504


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/index.html

Known issues


  Here are the changes found in Patchwork_18504 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_sync@basic-all:
- fi-tgl-y:   [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@gem_s...@basic-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@gem_s...@basic-all.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@execlists:
- fi-icl-y:   [PASS][5] -> [INCOMPLETE][6] ([i915#2276])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-icl-y/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-icl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-tgl-y:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@vgem_basic@unload:
- fi-skl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#2203])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-skl-guc/igt@vgem_ba...@unload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-skl-guc/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-tgl-y:   [INCOMPLETE][13] ([i915#2268]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@i915_selftest@l...@execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@i915_selftest@l...@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@vgem_basic@sysfs:
- fi-tgl-y:   [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@vgem_ba...@sysfs.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@vgem_ba...@sysfs.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s3:
- fi-tgl-y:   [DMESG-WARN][19] ([i915#2411] / [i915#402]) -> 
[DMESG-WARN][20] ([i915#2411])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-tgl-y:   [DMESG-WARN][21] ([i915#2411]) -> [DMESG-WARN][22] 
([i915#1982] / [i915#2411])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) 
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9013/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18504/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html

  * 

Re: [Intel-gfx] [patch 06/13] locking/bitspinlock: Clenaup PREEMPT_COUNT leftovers

2020-09-15 Thread Will Deacon
On Mon, Sep 14, 2020 at 10:42:15PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  include/linux/bit_spinlock.h |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> --- a/include/linux/bit_spinlock.h
> +++ b/include/linux/bit_spinlock.h
> @@ -90,10 +90,8 @@ static inline int bit_spin_is_locked(int
>  {
>  #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
>   return test_bit(bitnum, addr);
> -#elif defined CONFIG_PREEMPT_COUNT
> - return preempt_count();
>  #else
> - return 1;
> + return preempt_count();
>  #endif

Acked-by: Will Deacon 

Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [patch 04/13] lockdep: Clenaup PREEMPT_COUNT leftovers

2020-09-15 Thread Will Deacon
On Mon, Sep 14, 2020 at 10:42:13PM +0200, Thomas Gleixner wrote:
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Will Deacon 
> ---
>  include/linux/lockdep.h |6 ++
>  lib/Kconfig.debug   |1 -
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -585,16 +585,14 @@ do {
> \
>  
>  #define lockdep_assert_preemption_enabled()  \
>  do { \
> - WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
> -  debug_locks&&  \
> + WARN_ON_ONCE(debug_locks&&  \
>(preempt_count() != 0  ||  \
> !raw_cpu_read(hardirqs_enabled)));\
>  } while (0)
>  
>  #define lockdep_assert_preemption_disabled() \
>  do { \
> - WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
> -  debug_locks&&  \
> + WARN_ON_ONCE(debug_locks&&  \
>(preempt_count() == 0  &&  \
> raw_cpu_read(hardirqs_enabled))); \
>  } while (0)
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1161,7 +1161,6 @@ config PROVE_LOCKING
>   select DEBUG_RWSEMS
>   select DEBUG_WW_MUTEX_SLOWPATH
>   select DEBUG_LOCK_ALLOC
> - select PREEMPT_COUNT
>   select TRACE_IRQFLAGS
>   default n
>   help

Acked-by: Will Deacon 

Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Paul E. McKenney
On Mon, Sep 14, 2020 at 01:59:15PM -0700, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner  wrote:
> >
> > Recently merged code does:
> >
> >  gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
> >
> > Looks obviously correct, except for the fact that preemptible() is
> > unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in
> > that code use GFP_ATOMIC on such kernels.
> 
> I don't think this is a good reason to entirely get rid of the no-preempt 
> thing.
> 
> The above is just garbage. It's bogus. You can't do it.
> 
> Blaming the no-preempt code for this bug is extremely unfair, imho.
> 
> And the no-preempt code does help make for much better code generation
> for simple spinlocks.
> 
> Where is that horribly buggy recent code? It's not in that exact
> format, certainly, since 'grep' doesn't find it.

It would be convenient for that "gfp =" code to work, as this would
allow better cache locality while invoking RCU callbacks, and would
further provide better robustness to callback floods.  The full story
is quite long, but here are alternatives have not yet been proven to be
abject failures:

1.  Use workqueues to do the allocations in a clean context.
While waiting for the allocations, the callbacks are queued
in the old cache-busting manner.  This functions correctly,
but in the meantime (which on busy systems can be some time)
the cache locality and robustness are lost.

2.  Provide the ability to allocate memory in raw atomic context.
This is extremely effective, especially when used in combination
with #1 above, but as you might suspect, the MM guys don't like
it much.

In contrast, with Thomas's patch series, call_rcu() and kvfree_rcu()
could just look at preemptible() to see whether or not it was safe to
allocate memory, even in !PREEMPT kernels -- and in the common case,
it almost always would be safe.  It is quite possible that this approach
would work in isolation, or failing that, that adding #1 above would do
the trick.

I understand that this is all very hand-wavy, and I do apologize for that.
If you really want the full sad story with performance numbers and the
works, let me know!

Thanx, Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Linus Torvalds
On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner  wrote:
>
> OTOH, having a working 'preemptible()' or maybe better named
> 'can_schedule()' check makes tons of sense to make decisions about
> allocation modes or other things.

No. I think that those kinds of decisions about actual behavior are
always simply fundamentally wrong.

Note that this is very different from having warnings about invalid
use. THAT is correct. It may not warn in all configurations, but that
doesn't matter: what matters is that it warns in common enough
configurations that developers will catch it.

So having a warning in "might_sleep()" that doesn't always trigger,
because you have a limited configuration that can't even detect the
situation, that's fine and dandy and intentional.

But having code like

   if (can_schedule())
   .. do something different ..

is fundamentally complete and utter garbage.

It's one thing if you test for "am I in hardware interrupt context".
Those tests aren't great either, but at least they make sense.

But a driver - or some library routine - making a difference based on
some nebulous "can I schedule" is fundamentally and basically WRONG.

If some code changes behavior, it needs to be explicit to the *caller*
of that code.

So this is why GFP_ATOMIC is fine, but "if (!can_schedule())
do_something_atomic()" is pure shite.

And I am not IN THE LEAST interested in trying to help people doing
pure shite. We need to fix them. Like the crypto code is getting
fixed.

   Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915: Add support for Intel's eDP backlight controls
URL   : https://patchwork.freedesktop.org/series/81702/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d4faeb36f092 drm/i915/dp: Program source OUI on eDP panels
0debab180b3b drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
740d9664b33f drm/i915: Keep track of pwm-related backlight hooks separately
1363d7a69e3a drm/i915: Enable Intel's HDR backlight interface (only SDR for now)
-:210: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or 
return
#210: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:147:
+   return panel->backlight.max;
+   } else {

-:231: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u8' over 'uint8_t'
#231: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:168:
+   uint8_t buf[4] = { 0 };

-:250: WARNING:LINE_SPACING: Missing a blank line after declarations
#250: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c:187:
+   const u32 pwm_level = 
intel_panel_backlight_level_to_pwm(connector, level);
+   intel_panel_set_pwm_level(conn_state, pwm_level);

total: 0 errors, 2 warnings, 1 checks, 573 lines checked
e7a29d101ca4 drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
-:205: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#205: FILE: drivers/gpu/drm/i915/display/intel_dp.c:7467:
+   drm_connector_update_edid_property(connector,
+   edid);

total: 0 errors, 0 warnings, 1 checks, 220 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Linus Torvalds
On Tue, Sep 15, 2020 at 12:24 AM Thomas Gleixner  wrote:
>
> Alternatively we just make highmem a bit more expensive by making these
> maps preemptible. RT is doing this for a long time and it's not that
> horrible.

Ack.

In fact, I've wanted to start just removing kmap support entirely. At
some point it's not so much about "I have an old machine that wants
HIGHMEM" but about "I have an old CPU, and I'll just run an old
kernel".

It's not that 32-bit is irrelevant, it's that 32-bit with large
amounts of memory is irrelevant.

Last time this was discussed, iirc the main issue was some
questionable old ARM chips that were still very common in embedded
environments, even with large memory.

But we could definitely start de-emphasizing HIGHMEM.

 Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC 2/5] drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*

2020-09-15 Thread Lyude Paul
Since we're going to need to add a set of lower-level PWM backlight
control hooks to be shared by normal backlight controls and HDR
backlight controls in SDR mode, let's add a prefix to the external PWM
backlight functions so that the difference between them and the high
level PWM-only backlight functions is a bit more obvious.

This introduces no functional changes.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9f23bac0d7924..c0e36244bb07d 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -589,7 +589,7 @@ static u32 bxt_get_backlight(struct intel_connector 
*connector)
 BXT_BLC_PWM_DUTY(panel->backlight.controller));
 }
 
-static u32 pwm_get_backlight(struct intel_connector *connector)
+static u32 ext_pwm_get_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
struct pwm_state state;
@@ -666,7 +666,7 @@ static void bxt_set_backlight(const struct 
drm_connector_state *conn_state, u32
   BXT_BLC_PWM_DUTY(panel->backlight.controller), level);
 }
 
-static void pwm_set_backlight(const struct drm_connector_state *conn_state, 
u32 level)
+static void ext_pwm_set_backlight(const struct drm_connector_state 
*conn_state, u32 level)
 {
struct intel_panel *panel = 
_intel_connector(conn_state->connector)->panel;
 
@@ -835,7 +835,7 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
   tmp & ~BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
+static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1168,8 +1168,8 @@ static void cnp_enable_backlight(const struct 
intel_crtc_state *crtc_state,
   pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
-static void pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
-const struct drm_connector_state *conn_state)
+static void ext_pwm_enable_backlight(const struct intel_crtc_state *crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct intel_panel *panel = >panel;
@@ -1890,8 +1890,8 @@ cnp_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
-static int pwm_setup_backlight(struct intel_connector *connector,
-  enum pipe pipe)
+static int ext_pwm_setup_backlight(struct intel_connector *connector,
+  enum pipe pipe)
 {
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2065,11 +2065,11 @@ intel_panel_init_backlight_funcs(struct intel_panel 
*panel)
panel->backlight.hz_to_pwm = pch_hz_to_pwm;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) {
-   panel->backlight.setup = pwm_setup_backlight;
-   panel->backlight.enable = pwm_enable_backlight;
-   panel->backlight.disable = pwm_disable_backlight;
-   panel->backlight.set = pwm_set_backlight;
-   panel->backlight.get = pwm_get_backlight;
+   panel->backlight.setup = ext_pwm_setup_backlight;
+   panel->backlight.enable = ext_pwm_enable_backlight;
+   panel->backlight.disable = ext_pwm_disable_backlight;
+   panel->backlight.set = ext_pwm_set_backlight;
+   panel->backlight.get = ext_pwm_get_backlight;
} else {
panel->backlight.setup = vlv_setup_backlight;
panel->backlight.enable = vlv_enable_backlight;
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC 5/5] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

2020-09-15 Thread Lyude Paul
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.

At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.

As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/drm_dp_helper.c   | 82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |  3 +-
 .../drm/i915/display/intel_display_types.h|  1 -
 drivers/gpu/drm/i915/display/intel_dp.c   | 12 +--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  2 +-
 include/drm/drm_dp_helper.h   | 21 +
 7 files changed, 11 insertions(+), 113 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c82..7138655bfc9d0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -823,7 +823,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector 
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
-   !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+   !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
 }
 EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
 
@@ -1544,86 +1544,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, 
bool is_branch)
 #undef DEVICE_ID_ANY
 #undef DEVICE_ID
 
-struct edid_quirk {
-   u8 mfg_id[2];
-   u8 prod_id[2];
-   u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
-   /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
-   { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
-   { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-   { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41), 
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can be used to check the EDID and look
- * up any additional DP quirks. The bits returned by this function correspond
- * to the quirk bits in _dp_quirk.
- *
- * Returns: a bitmask of quirks, if any. The 

[Intel-gfx] [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

2020-09-15 Thread Lyude Paul
Since we're about to start adding support for Intel's magic HDR
backlight interface over DPCD, we need to ensure we're properly
programming this field so that Intel specific sink services are exposed.
Otherwise, 0x300-0x3ff will just read zeroes.

We also take care not to reprogram the source OUI if it already matches
what we expect. This is just to be careful so that we don't accidentally
take the panel out of any backlight control modes we found it in.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 32 +
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4bd10456ad188..b591672ec4eab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3428,6 +3428,7 @@ void intel_dp_sink_set_decompression_state(struct 
intel_dp *intel_dp,
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
 {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 edp_oui[] = { 0x00, 0xaa, 0x01 };
int ret, i;
 
/* Should have a valid DPCD by this point */
@@ -3443,6 +3444,14 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
+   /* Write the source OUI as early as possible */
+   if (intel_dp_is_edp(intel_dp)) {
+   ret = drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, 
edp_oui,
+   sizeof(edp_oui));
+   if (ret < 0)
+   drm_err(>drm, "Failed to write eDP source 
OUI\n");
+   }
+
/*
 * When turning on, we need to retry for 1ms to give the sink
 * time to wake up.
@@ -4530,6 +4539,23 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp 
*intel_dp)
}
 }
 
+static void
+intel_edp_init_source_oui(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+   u8 oui[] = { 0x00, 0xaa, 0x01 };
+   u8 buf[3] = { 0 };
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 
0)
+   drm_err(>drm, "Failed to read source OUI\n");
+
+   if (memcmp(oui, buf, sizeof(oui)) == 0)
+   return;
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) 
< 0)
+   drm_err(>drm, "Failed to write source OUI\n");
+}
+
 static bool
 intel_edp_init_dpcd(struct intel_dp *intel_dp)
 {
@@ -4607,6 +4633,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
intel_dp_get_dsc_sink_cap(intel_dp);
 
+   /*
+* Program our source OUI so we can make various Intel-specific AUX
+* services available (such as HDR backlight controls)
+*/
+   intel_edp_init_source_oui(intel_dp);
+
return true;
 }
 
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [RFC 3/5] drm/i915: Keep track of pwm-related backlight hooks separately

2020-09-15 Thread Lyude Paul
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.

HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.

So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:

* We now keep track of two separate backlight level ranges, one for the
  high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
  enablement separately
* Since the currently set backlight level might not be the same as the
  currently programmed PWM backlight level, we stop setting
  panel->backlight.level with the currently programmed PWM backlight
  level in panel->backlight.pwm_funcs.setup(). Instead, we rely
  on the higher level backlight control functions to retrieve the
  current PWM backlight level (in this case, intel_pwm_get_backlight()).
  Note that there are still a few PWM backlight setup callbacks that
  do actually need to retrieve the current PWM backlight level, although
  we no longer save this value in panel->backlight.level like before.
* panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
  brightness level, unlike their siblings
  panel->backlight.enable()/disable(). This is so we can calculate the
  actual PWM brightness level we want to set on disable/enable in the
  higher level backlight enable()/disable() functions, since this value
  might be scaled from a brightness level that doesn't come from PWM.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
 2 files changed, 246 insertions(+), 204 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b2d0edacc58c9..52a6543df842a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -221,6 +221,9 @@ struct intel_panel {
bool alternate_pwm_increment;   /* lpt+ */
 
/* PWM chip */
+   u32 pwm_min;
+   u32 pwm_max;
+   bool pwm_enabled;
bool util_pin_active_low;   /* bxt+ */
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
@@ -229,6 +232,16 @@ struct intel_panel {
/* DPCD backlight */
u8 pwmgen_bit_count;
 
+   struct {
+   int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
+   u32 (*get)(struct intel_connector *connector);
+   void (*set)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*disable)(const struct drm_connector_state 
*conn_state, u32 level);
+   void (*enable)(const struct intel_crtc_state 
*crtc_state,
+  const struct drm_connector_state 
*conn_state, u32 level);
+   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 
hz);
+   } pwm_funcs;
+
struct backlight_device *device;
 
/* Connector and platform specific backlight functions */
@@ -238,7 +251,6 @@ struct intel_panel {
void (*disable)(const struct drm_connector_state *conn_state);
void (*enable)(const struct intel_crtc_state *crtc_state,
   const struct drm_connector_state *conn_state);
-   u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
void (*power)(struct intel_connector *, bool enable);
} backlight;
 };
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index c0e36244bb07d..6d3e9d51d069c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector 
*connector,
 0, user_max);
 }
 
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector, 
u32 val)
 {
struct 

[Intel-gfx] [RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

2020-09-15 Thread Lyude Paul
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.

Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.

On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.

For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:

* If the panel's VBT reports VESA backlight support, assume it really
  does support it
* If the panel's VBT reports DDI backlight controls:
  * First probe for Intel's HDR backlight interface
  * If that fails, probe for VESA's backlight interface
  * If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
  doesn't have DPCD backlight controls

Note as well that in order for us to make Intel's HDR backlight
interface appear, we need to start programming the appropriate source
OUI on the eDP panel as early as possible in the probing process. Note
that this technically could be done at any time before setting up
backlight controls, but this way allows us to avoid re-writing it
multiple times in case we need to use other source-OUI enabled features
in the future.

Finally, we also make sure to document the registers for this backlight
interface since eventually, we want to actually implement the full
interface instead of keeping it in SDR mode.

Signed-off-by: Lyude Paul 
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick 
---
 .../drm/i915/display/intel_display_types.h|   9 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 +++---
 drivers/gpu/drm/i915/display/intel_panel.c|  34 +-
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 5 files changed, 381 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 52a6543df842a..9d540368bac89 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -230,7 +230,14 @@ struct intel_panel {
struct pwm_state pwm_state;
 
/* DPCD backlight */
-   u8 pwmgen_bit_count;
+   union {
+   struct {
+   u8 pwmgen_bit_count;
+   } vesa;
+   struct {
+   bool sdr_uses_aux;
+   } intel;
+   } edp;
 
struct {
int (*setup)(struct intel_connector *connector, enum 
pipe pipe);
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 acbd7eb66cbe3..aa1429302db70 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,10 +22,251 @@
  *
  */
 
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
 #include "intel_display_types.h"
 #include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us 
back into SDR mode so we
+ * can make people's backlights 

[Intel-gfx] [RFC 0/5] drm/i915: Add support for Intel's eDP backlight controls

2020-09-15 Thread Lyude Paul
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an Intel-specific DPCD backlight control interface as the
VESA interface is broken on many laptop panels. For lack of a better
name, we just call this the Intel HDR backlight interface.

While this only adds support for the SDR backlight mode (I think), this
will fix a lot of user's laptop panels that we weren't able to properly
automatically detect DPCD backlight controls on previously.

Lyude Paul (5):
  drm/i915/dp: Program source OUI on eDP panels
  drm/i915: Rename pwm_* backlight callbacks to ext_pwm_*
  drm/i915: Keep track of pwm-related backlight hooks separately
  drm/i915: Enable Intel's HDR backlight interface (only SDR for now)
  drm/dp: Revert "drm/dp: Introduce EDID-based quirks"

 drivers/gpu/drm/drm_dp_helper.c   |  82 +--
 drivers/gpu/drm/drm_dp_mst_topology.c |   3 +-
 .../drm/i915/display/intel_display_types.h|  24 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  44 +-
 .../drm/i915/display/intel_dp_aux_backlight.c | 384 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_panel.c| 476 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   4 +
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 include/drm/drm_dp_helper.h   |  21 +-
 11 files changed, 673 insertions(+), 372 deletions(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81687/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9011_full -> Patchwork_18501_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18501_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18501_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_18501_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_persistence@processes:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-iclb7/igt@gem_ctx_persiste...@processes.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-iclb3/igt@gem_ctx_persiste...@processes.html

  
Known issues


  Here are the changes found in Patchwork_18501_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-snb:  [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-snb7/igt@gem_...@kms.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-snb4/igt@gem_...@kms.html

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-glk7/igt@gem_exec_whis...@basic-queues-priority-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-glk4/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl:  [PASS][7] -> [TIMEOUT][8] ([i915#1958] / [i915#2424])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-skl3/igt@gem_userptr_bl...@sync-unmap-cycles.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-skl4/igt@gem_userptr_bl...@sync-unmap-cycles.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-kbl1/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-kbl6/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-hsw:  [PASS][11] -> [FAIL][12] ([i915#2370])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html

  * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-ytiled:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-tglb7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-ytiled.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-tglb8/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-ytiled.html

  * igt@kms_draw_crc@draw-method-xrgb-blt-untiled:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-glk8/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-glk4/igt@kms_draw_...@draw-method-xrgb-blt-untiled.html

  * igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- shard-skl:  [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-skl10/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-skl5/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html

  * igt@kms_flip@flip-vs-blocking-wf-vblank@a-edp1:
- shard-skl:  [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +5 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-skl8/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/shard-skl2/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html

  * igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl:  [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 
similar issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/shard-kbl4/igt@kms_flip@flip-vs-susp...@c-dp1.html
   [22]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Convert all remaining drivers to GEM object functions (rev2)

2020-09-15 Thread Patchwork
== Series Details ==

Series: Convert all remaining drivers to GEM object functions (rev2)
URL   : https://patchwork.freedesktop.org/series/80593/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9012 -> Patchwork_18503


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_18503 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18503, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_18503:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@basic-busy@rcs0:
- fi-blb-e6850:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html
- fi-pnv-d510:[PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html

  * igt@gem_exec_fence@basic-busy@vcs0:
- fi-ivb-3770:[PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-elk-e7500:   [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-ilk-650: [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-byt-j1900:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-byt-j1900/igt@gem_exec_fence@basic-b...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-byt-j1900/igt@gem_exec_fence@basic-b...@vcs0.html

  * igt@gem_exec_fence@basic-busy@vecs0:
- fi-hsw-4770:[PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-hsw-4770/igt@gem_exec_fence@basic-b...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-hsw-4770/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-icl-u2:  [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-icl-u2/igt@gem_exec_fence@basic-b...@vecs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-icl-u2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-cml-u2:  [PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-cml-u2/igt@gem_exec_fence@basic-b...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-cml-u2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-skl-6700k2:  [PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-cfl-8700k:   [PASS][21] -> [DMESG-WARN][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-tgl-u2:  [PASS][23] -> [DMESG-WARN][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-tgl-u2/igt@gem_exec_fence@basic-b...@vecs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-tgl-u2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-bsw-n3050:   [PASS][25] -> [DMESG-WARN][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-bsw-n3050/igt@gem_exec_fence@basic-b...@vecs0.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18503/fi-bsw-n3050/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-skl-lmem:[PASS][27] -> [DMESG-WARN][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-skl-lmem/igt@gem_exec_fence@basic-b...@vecs0.html
   [28]: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Convert all remaining drivers to GEM object functions (rev2)

2020-09-15 Thread Patchwork
== Series Details ==

Series: Convert all remaining drivers to GEM object functions (rev2)
URL   : https://patchwork.freedesktop.org/series/80593/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:expected unsigned int 
[addressable] [usertype] ulClockParams
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47:got restricted __le32 
[usertype]
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1019:47: warning: incorrect type 
in assignment (different base types)
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1028:50: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1029:49: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1037:47: warning: too many 
warnings
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:184:44: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:283:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:320:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:323:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:326:14: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:329:18: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:330:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:338:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:340:38: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:342:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:346:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:348:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:353:33: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:367:43: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:369:38: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:374:67: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:375:53: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:378:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:389:80: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:395:57: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:402:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:403:53: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:406:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:414:66: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:423:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:424:69: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:473:30: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:476:45: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:477:45: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:484:54: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:52:28: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:531:35: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:53:29: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:533:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:54:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:55:27: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:56:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:57:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:577:21: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:581:25: warning: cast to 
restricted __le32
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:58:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:583:21: warning: cast to 
restricted __le32
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:586:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:590:25: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:59:26: warning: cast to 
restricted __le16
+drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:598:21: warning: cast 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Convert all remaining drivers to GEM object functions (rev2)

2020-09-15 Thread Patchwork
== Series Details ==

Series: Convert all remaining drivers to GEM object functions (rev2)
URL   : https://patchwork.freedesktop.org/series/80593/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3975f25bdb58 drm/amdgpu: Introduce GEM object functions
c6ad3a511161 drm/armada: Introduce GEM object functions
c8098f5d6e95 drm/etnaviv: Introduce GEM object functions
a81e48db00e5 drm/exynos: Introduce GEM object functions
53210f7f0722 drm/gma500: Introduce GEM object functions
dbfefd13964e drm/i915: Introduce GEM object functions
ba32f8dd23b5 drm/mediatek: Introduce GEM object functions
504106e74ccc drm/msm: Introduce GEM object funcs
324848fd8dc0 drm/nouveau: Introduce GEM object functions
a37cb8db61ac drm/omapdrm: Introduce GEM object functions
a40c13d7fe1c drm/pl111: Introduce GEM object functions
8cfbfcdfaf7b drm/radeon: Introduce GEM object functions
-:97: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#97: FILE: drivers/gpu/drm/radeon/radeon_gem.c:41:
+int radeon_gem_prime_pin(struct drm_gem_object *obj);

-:98: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#98: FILE: drivers/gpu/drm/radeon/radeon_gem.c:42:
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);

-:100: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#100: FILE: drivers/gpu/drm/radeon/radeon_gem.c:44:
+void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);

total: 0 errors, 3 warnings, 0 checks, 118 lines checked
376266125805 drm/rockchip: Convert to drm_gem_object_funcs
4b77e1b2c5a8 drm/tegra: Introduce GEM object functions
cd6d5c4922a9 drm/vc4: Introduce GEM object functions
716d7874560f drm/vgem: Introduce GEM object functions
8bbc5ccb9b19 drm/virtgpu: Set PRIME export function in struct 
drm_gem_object_funcs
ac18c0a1f4e6 drm/vkms: Introduce GEM object functions
0e96620ce337 drm/xen: Introduce GEM object functions
308dcf21fda5 drm/xlnx: Initialize DRM driver instance with CMA helper macro
cab017216e88 drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Tvrtko Ursulin



On 15/09/2020 15:59, Thomas Zimmermann wrote:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.

v2:
* move object-function instance to i915_gem_object.c (Jani)

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 ---
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 ---
  drivers/gpu/drm/i915/i915_drv.c   |  4 
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 ---
  4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index c8421fd9d2dc..3389ac972d16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -39,9 +39,18 @@ static struct i915_global_object {
struct kmem_cache *slab_objects;
  } global;
  
+static const struct drm_gem_object_funcs i915_gem_object_funcs;

+
  struct drm_i915_gem_object *i915_gem_object_alloc(void)
  {
-   return kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   struct drm_i915_gem_object *obj;
+
+   obj = kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   if (!obj)
+   return NULL;
+   obj->base.funcs = _gem_object_funcs;
+
+   return obj;
  }
  
  void i915_gem_object_free(struct drm_i915_gem_object *obj)

@@ -101,7 +110,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
  }
  
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)

+static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
*file)
  {
struct drm_i915_gem_object *obj = to_intel_bo(gem);
struct drm_i915_file_private *fpriv = file->driver_priv;
@@ -264,7 +273,7 @@ static void __i915_gem_free_work(struct work_struct *work)
i915_gem_flush_free_objects(i915);
  }
  
-void i915_gem_free_object(struct drm_gem_object *gem_obj)

+static void i915_gem_free_object(struct drm_gem_object *gem_obj)
  {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -403,6 +412,12 @@ int __init i915_global_objects_init(void)
return 0;
  }
  
+static const struct drm_gem_object_funcs i915_gem_object_funcs = {

+   .free = i915_gem_free_object,
+   .close = i915_gem_close_object,
+   .export = i915_gem_prime_export,
+};
+
  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
  #include "selftests/huge_gem_object.c"
  #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d46db8d8f38e..eaf3d4147be0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -38,9 +38,6 @@ void __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
  
  int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align);
  
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);

-void i915_gem_free_object(struct drm_gem_object *obj);
-
  void i915_gem_flush_free_objects(struct drm_i915_private *i915);
  
  struct sg_table *

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 94e00e450683..011a3fb41ece 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1750,12 +1750,8 @@ static struct drm_driver driver = {
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
  
-	.gem_close_object = i915_gem_close_object,

-   .gem_free_object_unlocked = i915_gem_free_object,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = i915_gem_prime_export,
.gem_prime_import = i915_gem_prime_import,
  
  	.dumb_create = i915_gem_dumb_create,

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index f127e633f7ca..9244b5d6fb01 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -87,9 +87,6 @@ static struct drm_driver mock_driver = {
.name = "mock",
.driver_features = DRIVER_GEM,
.release = mock_device_release,
-
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
  };
  
  static void release_dev(struct device *dev)




Looks obviously fine.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Laurent Pinchart
Hi Thomas,

Thank you for the patch.

On Tue, Sep 15, 2020 at 04:59:57PM +0200, Thomas Zimmermann wrote:
> The xlnx driver uses CMA helpers with default callback functions.
> Initialize the driver structure with the rsp CMA helper macro. The
> driver is being converted to use GEM object functions as part of
> this change.
> 
> Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
> to their default implementations, so they are just kept empty now.
> 
> v2:
>   * initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
> 
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
> b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> index 8e69303aad3f..f3ffc3703a0e 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
> @@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_GEM |
> DRIVER_ATOMIC,
>  
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = drm_gem_prime_export,
> - .gem_prime_import   = drm_gem_prime_import,
> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
> - .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
> - .gem_free_object_unlocked   = drm_gem_cma_free_object,
> - .gem_vm_ops = _gem_cma_vm_ops,
> - .dumb_create= zynqmp_dpsub_dumb_create,
> - .dumb_destroy   = drm_gem_dumb_destroy,
> + DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
>  
>   .fops   = _dpsub_drm_fops,
>  

-- 
Regards,

Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81688/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9012 -> Patchwork_18502


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/index.html

Known issues


  Here are the changes found in Patchwork_18502 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  
 Possible fixes 

  * {igt@core_hotunplug@unbind-rebind}:
- {fi-tgl-dsi}:   [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-tgl-dsi/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2:  [INCOMPLETE][7] ([i915#2045]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_pm:
- fi-cml-s:   [DMESG-FAIL][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-cml-s/igt@i915_selftest@live@gt_pm.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-cml-s/igt@i915_selftest@live@gt_pm.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900:   [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-tgl-y:   [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-tgl-y/igt@kms_frontbuffer_track...@basic.html

  * igt@vgem_basic@dmabuf-fence:
- fi-tgl-y:   [DMESG-WARN][15] ([i915#402]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-tgl-y/igt@vgem_ba...@dmabuf-fence.html

  * igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-skl-guc/igt@vgem_ba...@unload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-skl-guc/igt@vgem_ba...@unload.html

  
 Warnings 

  * igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275:   [DMESG-WARN][19] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275:   [DMESG-WARN][21] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][22] ([i915#1982] / [i915#62] / [i915#92])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html

  * igt@kms_flip@basic-flip-vs-dpms@a-dp1:
- fi-kbl-x1275:   [DMESG-WARN][23] ([i915#62] / [i915#92]) -> 
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9012/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18502/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-d...@a-dp1.html


Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements

2020-09-15 Thread Vudum, Lakshminarayana
Hi Janusz,

I have filed https://gitlab.freedesktop.org/drm/intel/-/issues/2469 for 
igt@core_hotunplug@hotrebind-lateclose failure. 
Is it GUC issue?

Thanks,
Lakshmi


-Original Message-
From: Janusz Krzysztofik  
Sent: Tuesday, September 15, 2020 12:47 AM
To: Vudum, Lakshminarayana ; Winiarski, Michal 
; igt-...@lists.freedesktop.org
Cc: Michał Winiarski ; intel-gfx@lists.freedesktop.org; 
Latvala, Petri 
Subject: Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and 
enhancements

Hi Lakshmi,

On Mon, 2020-09-14 at 20:43 +, Vudum, Lakshminarayana wrote:
> igt@core_hotunplug@hotrebind-lateclose test is not yet in CI bug log.

Here is a fresh evidence:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9008/shard-tglb5/igt@core_hotunp...@hotrebind-lateclose.html

Thanks,
Janusz

>  Otherwise I filed the issue 
> https://gitlab.freedesktop.org/drm/intel/-/issues/2464
> 
> Thanks,
> Lakshmi.
> 
> -Original Message-
> From: Janusz Krzysztofik 
> Sent: Monday, September 14, 2020 12:31 PM
> To: Winiarski, Michal ; 
> igt-...@lists.freedesktop.org
> Cc: Michał Winiarski ; 
> intel-gfx@lists.freedesktop.org; Latvala, Petri 
> ; Vudum, Lakshminarayana 
> 
> Subject: Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: 
> Fixes and enhancements
> 
> On Mon, 2020-09-14 at 20:18 +0200, Michał Winiarski wrote:
> > Quoting Janusz Krzysztofik (2020-09-11 12:30:15)
> > > Clean up the test code, add some new basic subtests, then unblock 
> > > unbind test variants.
> > > 
> > > No incompletes / aborts nor subsequently run test issues have been 
> > > reported by Trybot.  The hotrebind-lateclose subtest fails on a so 
> > > far unidentified driver sysfs issue but the device is fully 
> > > recovered and left in a usable state.  Perceived Haswell/Broadwell 
> > > issue with audio power management has been worked around and its 
> > > potential occurrence is reported as an IGT warning.
> > > 
> > > Series changelog:
> > > v2: New patch "Un-blocklist *bind* subtests added.
> > > v3: Patch "Follow failed subtests with healthcheck" renamed to "Recover
> > > from subtest failures".
> > >   - a new patche "Clean up device open error handling" added, an old
> > > patch "Fix missing newline" obsoleted by the new one dropped,
> > >   - other new patches added:
> > > - "Let the driver time out essential sysfs operations",
> > > - "More thorough i915 healthcheck and recovery",
> > >   - a patch "Add 'lateclose before restore' variants" from another
> > > series included.
> > > v4: Optional patch "Duplicate debug messages in dmesg" from another
> > > series included.
> > > v5: New patch added with Haswell audio related kernel warning worked
> > > around and replaced with an IGT warning to preserve visibility of
> > > the issue.
> > > v6: New patch added for also checking health of render device nodes,
> > >   - new patch added with proper handling of health check before late
> > > close,
> > >   - inclusion of unbind-rebind scenario to BAT scope proposed.
> > > 
> > > @Michał: Since some patch updates are trivial, I've preserved your
> > > v1/v2 Reviewd-by: except for patches with non-trivial changes, 
> > > where I marked your R-b as v1/v2 applicable.  Please have a look 
> > > and confirm if you are still OK with them.
> > 
> > Feel free to add:
> > Reviewed-by: Michał Winiarski 
> > 
> > For the whole series (with the exception of intel-ci part).
> 
> Pushed.
> 
> @Petri, @Michał - thank you for review.
> 
> @Lakshmi:
> - please open a new bug for the issue reported by the igt@core 
> _hotunplug@hotrebind-lateclose subtest failing on all platforms,
> - IGT warning reported by igt@core_hotunplug@*bind* on Haswell and Broadwell 
> platofrms is caused by the same issue as the one reported now in a similar 
> way on Haswell by igt@device_reset@unbind-reset-rebind - please update the 
> associated filter so it covers all those tests.
> 
> Thanks,
> Janusz
> 
> 
> > -Michał
> > 
> > > @Tvrtko: As I already asked before, please support my attempt to 
> > > remove the unbind test variants from the blocklist.
> > > 
> > > @Petri, @Martin: Assuming CI results will be as good as those 
> > > obtained on Trybot, please give me your green light for merging 
> > > this series if you have no objections.
> > > 
> > > Thanks,
> > > Janusz
> > > 
> > > Janusz Krzysztofik (24):
> > >   tests/core_hotunplug: Use igt_assert_fd()
> > >   tests/core_hotunplug: Constify dev_bus_addr string
> > >   tests/core_hotunplug: Clean up device open error handling
> > >   tests/core_hotunplug: Consolidate duplicated debug messages
> > >   tests/core_hotunplug: Assert successful device filter application
> > >   tests/core_hotunplug: Maintain a single data structure instance
> > >   tests/core_hotunplug: Pass errors via a data structure field
> > >   tests/core_hotunplug: Handle device close errors
> > >   tests/core_hotunplug: Prepare invariant data once per test run
> > >   

Re: [Intel-gfx] [PATCH v2 0/8] Return head pages from find_*_entry

2020-09-15 Thread Naresh Kamboju
On Tue, 15 Sep 2020 at 13:56, Hugh Dickins  wrote:
>
> On Thu, 10 Sep 2020, Matthew Wilcox (Oracle) wrote:
>
> > This patch series started out as part of the THP patch set, but it has
> > some nice effects along the way and it seems worth splitting it out and
> > submitting separately.
> >
> > Currently find_get_entry() and find_lock_entry() return the page
> > corresponding to the requested index, but the first thing most callers do
> > is find the head page, which we just threw away.  As part of auditing
> > all the callers, I found some misuses of the APIs and some plain
> > inefficiencies that I've fixed.
> >
> > The diffstat is unflattering, but I added more kernel-doc and a new wrapper.
> >
> > v2:
> >  - Rework how shmem_getpage_gfp() handles getting a head page back from
> >find_lock_entry()
> >  - Renamed find_get_swap_page() to find_get_incore_page()
> >  - Make sure find_get_incore_page() doesn't return a head page
> >  - Fix the missing include of linux/shmem_fs.h
> >  - Move find_get_entry and find_lock_entry prototypes to mm/internal.h
> >  - Rename thp_valid_index() to thp_contains()
> >  - Fix thp_contains() for hugetlbfs and swapcache
> >  - Add find_lock_head() wrapper around pagecache_get_page()
> >
> > Matthew Wilcox (Oracle) (8):
> >   mm: Factor find_get_incore_page out of mincore_page
> >   mm: Use find_get_incore_page in memcontrol
> >   mm: Optimise madvise WILLNEED
> >   proc: Optimise smaps for shmem entries
> >   i915: Use find_lock_page instead of find_lock_entry
> >   mm: Convert find_get_entry to return the head page
> >   mm/shmem: Return head page from find_lock_entry
> >   mm: Add find_lock_head

While running kselftest mincore tests the following kernel BUG reported on the
linux next-20200915 tag on x86_64, i386 and arm64.

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
  git commit: 6b02addb1d1748d21dd1261e46029b264be4e5a0
  git describe: next-20200915
  make_kernelversion: 5.9.0-rc5
  kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-next/860/config

Test case:
---

 * Tests the user interface. This test triggers most of the documented
 * error conditions in mincore().
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/plain/tools/testing/selftests/mincore/mincore_selftest.c

kernel BUG:
-
[  710.472860] kselftest: Running tests in mincore
[  710.554790] BUG: kernel NULL pointer dereference, address: 
[  710.561765] #PF: supervisor read access in kernel mode
[  710.566920] #PF: error_code(0x) - not-present page
[  710.572065] PGD 8003fd5b9067 P4D 8003fd5b9067 PUD 45903f067 PMD 0
[  710.578957] Oops:  [#1] SMP PTI
[  710.582450] CPU: 0 PID: 19025 Comm: mincore_selftes Tainted: G
  W K   5.9.0-rc5-next-20200915 #1
[  710.592094] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[  710.599574] RIP: 0010:PageHuge+0x6/0x40
[  710.603411] Code: c3 0f 1f 00 0f 1f 44 00 00 55 48 89 d6 48 89 e5
e8 ef fe ff ff 5d c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44
00 00 55 <48> 8b 07 48 89 e5 a9 00 00 01 00 75 09 48 8b 47 08 83 e0 01
74 17
[  710.622149] RSP: 0018:b0e2002bfcc0 EFLAGS: 00010246
[  710.627373] RAX:  RBX:  RCX: 
[  710.634498] RDX: 9f231b2518c0 RSI: a272b340 RDI: 
[  710.641620] RBP: b0e2002bfce8 R08: 0002 R09: 
[  710.648747] R10: b0e2002bfb20 R11: a272b340 R12: 9f23193c5e68
[  710.655876] R13:  R14: 0001 R15: 0001
[  710.663003] FS:  7fa4c9ea24c0() GS:9f231fc0()
knlGS:
[  710.671088] CS:  0010 DS:  ES:  CR0: 80050033
[  710.676824] CR2:  CR3: 0004044d0004 CR4: 003706f0
[  710.683949] DR0:  DR1:  DR2: 
[  710.691073] DR3:  DR6: fffe0ff0 DR7: 0400
[  710.698196] Call Trace:
[  710.700644]  ? find_get_incore_page+0xc6/0x120
[  710.705089]  mincore_page+0x12/0x60
[  710.708580]  __mincore_unmapped_range+0x78/0xc0
[  710.713105]  mincore_pte_range+0x269/0x300
[  710.717206]  __walk_page_range+0x5ab/0xb60
[  710.721308]  walk_page_range+0xab/0x150
[  710.725152]  __x64_sys_mincore+0x13c/0x330
[  710.729251]  do_syscall_64+0x37/0x50
[  710.732831]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  710.737882] RIP: 0033:0x7fa4c99be2d7
[  710.741462] Code: 73 01 c3 48 8b 0d c1 fb 2b 00 f7 d8 64 89 01 48
83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 1b 00 00
00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91

Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional

2020-09-15 Thread Ard Biesheuvel
On Tue, 15 Sep 2020 at 01:43, Linus Torvalds
 wrote:
>
> On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds
>  wrote:
> >
> > Ard and Herbert added to participants: see
> > chacha20poly1305_crypt_sg_inplace(), which does
> >
> > flags = SG_MITER_TO_SG;
> > if (!preemptible())
> > flags |= SG_MITER_ATOMIC;
> >
> > introduced in commit d95312a3ccc0 ("crypto: lib/chacha20poly1305 -
> > reimplement crypt_from_sg() routine").
>
> As far as I can tell, the only reason for this all is to try to use
> "kmap()" rather than "kmap_atomic()".
>
> And kmap() actually has the much more complex "might_sleep()" tests,
> and apparently the "preemptible()" check wasn't even the proper full
> debug check, it was just a complete hack to catch the one that
> triggered.
>

This was not driven by a failing check.

The documentation of kmap_atomic() states the following:

 * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
 * gives a more generic (and caching) interface. But kmap_atomic can
 * be used in IRQ contexts, so in some (very limited) cases we need
 * it.

so if this is no longer accurate, perhaps we should fix it?

But another reason I tried to avoid kmap_atomic() is that it disables
preemption unconditionally, even on 64-bit architectures where HIGHMEM
is irrelevant. So using kmap_atomic() here means that the bulk of
WireGuard packet encryption runs with preemption disabled, essentially
for legacy reasons.


> From a quick look, that code should probably just get rid of
> SG_MITER_ATOMIC entirely, and alwayse use kmap_atomic().
>
> kmap_atomic() is actually the faster and proper interface to use
> anyway (never mind that any of this matters on any sane hardware). The
> old kmap() and kunmap() interfaces should generally be avoided like
> the plague - yes, they allow sleeping in the middle and that is
> sometimes required, but if you don't need that, you should never ever
> use them.
>
> We used to have a very nasty kmap_atomic() that required people to be
> very careful and know exactly which atomic entry to use, and that was
> admitedly quite nasty.
>
> So it _looks_ like this code started using kmap() - probably back when
> kmap_atomic() was so cumbersome to use - and was then converted
> (conditionally) to kmap_atomic() rather than just changed whole-sale.
> Is there actually something that wants to use those sg_miter functions
> and sleep?
>
> Because if there is, that choice should come from the outside, not
> from inside lib/scatterlist.c trying to make some bad guess based on
> the wrong thing entirely.
>
>  Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] Haswell Regression in 5.9-rcX and lower 5.7.x, 5.8.x #2024 - Revert 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") ?

2020-09-15 Thread Dirk Neukirchen
Hi David, Chris and lists

I am inquiring about the current status of #2024 [1]

Problem: Kernels 5.7.x , 5.8.x, current 5.9-rcs and drm-tip have a large 
regression on (some?) Haswell (HSW)

This is verified by _multiple people_ using different methods.
All his is documented in [1]  , Kernel 5.6.19 was fine
Result: no output, no usable desktop due to gpu crashes

Hardware : 2x Acer C720 Chromebooks and potentially others

Methods:
- running mpv with vaapi enabled
- glxgears
- automatic desktop environment start (probably with acceleration)

There is atm no fix in drm-tip integrated (5.9.0_rc5bisect_g30b3e38bd6d5 for 
example still errors)
 and no activity from Intel in the bug report beside the "working" suggested 
patches / hacks there

There should be enough bisection info an there.
Nobody asked there to get more info or different bisects/trees.

So - the ticket is still open.

Because Fedora uses newish Kernels I would like to use it "normally" without
going for 5.4 LTS or waiting an unknown amount of time - as 5.9.x currently 
seems to have the
same regression.

Affected Hardware at my end:
- C720 with a Intel Celeron 2955U
- UEFI Bios instead of original Bios (mrchromebox.tech) if thats relevant for 
hardware init related bugs;
But the Kernel should take care of the correct initialization anyway

Feel free to comment which trees, branches, tags or patches we should try to 
help
and what _more_ to report for "Report-By" , "Tested-By", "Verified-By"
tagging so that [1] can be closed.

Greetings, Dirk

[1]https://gitlab.freedesktop.org/drm/intel/-/issues/2024

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-15 Thread Miquel Raynal
Hi Joe,

For MTD:

>  drivers/mtd/nand/raw/nandsim.c|  2 +-

Reviewed-by: Miquel Raynal 


Thanks,
Miquèl
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Christian König

Added my rb to the amdgpu and radeon patches.

Should we pick those up through the amd branches or do you want to push 
everything to drm-misc-next?


I think the later since this should result in much merge clash.

Christian.

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.

Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions,
one by one. Each patch moves existing callbacks from struct drm_driver to an
instance of struct drm_gem_object_funcs, and sets these funcs when the GEM
object is initialized. The expection is .gem_prime_mmap. There are different
ways of how drivers implement the callback, and moving it to GEM object
functions requires a closer review for each.

Patch #17 fixes virtgpu to use GEM object functions where possible. The
driver recently introduced a function for one of the deprecated callbacks.

Patch #20 converts xlnx to CMA helper macros. There's no apparent reason
why the driver does the GEM setup on it's own. Using CMA helper macros
adds GEM object functions implicitly.

With most of the GEM and PRIME moved to GEM object functions, related code
in struct drm_driver and in the DRM core/helpers is being removed by patch
#21.

Further testing is welcome. I tested the drivers for which I have HW
available. These are gma500, i915, nouveau, radeon and vc4. The console,
Weston and Xorg apparently work with the patches applied.

v2:
* moved code in amdgpu and radeon
* made several functions static in various drivers
* updated TODO-list item
* fix virtgpu

Thomas Zimmermann (21):
   drm/amdgpu: Introduce GEM object functions
   drm/armada: Introduce GEM object functions
   drm/etnaviv: Introduce GEM object functions
   drm/exynos: Introduce GEM object functions
   drm/gma500: Introduce GEM object functions
   drm/i915: Introduce GEM object functions
   drm/mediatek: Introduce GEM object functions
   drm/msm: Introduce GEM object funcs
   drm/nouveau: Introduce GEM object functions
   drm/omapdrm: Introduce GEM object functions
   drm/pl111: Introduce GEM object functions
   drm/radeon: Introduce GEM object functions
   drm/rockchip: Convert to drm_gem_object_funcs
   drm/tegra: Introduce GEM object functions
   drm/vc4: Introduce GEM object functions
   drm/vgem: Introduce GEM object functions
   drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
   drm/vkms: Introduce GEM object functions
   drm/xen: Introduce GEM object functions
   drm/xlnx: Initialize DRM driver instance with CMA helper macro
   drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

  Documentation/gpu/todo.rst|  7 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 23 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h   |  5 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  1 +
  drivers/gpu/drm/armada/armada_drv.c   |  3 -
  drivers/gpu/drm/armada/armada_gem.c   | 12 ++-
  drivers/gpu/drm/armada/armada_gem.h   |  2 -
  drivers/gpu/drm/drm_gem.c | 35 ++--
  drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
  drivers/gpu/drm/drm_prime.c   | 17 ++--
  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 ---
  drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 -
  drivers/gpu/drm/exynos/exynos_drm_drv.c   | 10 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 
  drivers/gpu/drm/gma500/framebuffer.c  |  2 +
  drivers/gpu/drm/gma500/gem.c  | 18 +++-
  drivers/gpu/drm/gma500/gem.h  |  3 +
  drivers/gpu/drm/gma500/psb_drv.c  |  9 --
  drivers/gpu/drm/gma500/psb_drv.h  |  2 -
  drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 -
  drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 -
  drivers/gpu/drm/i915/i915_drv.c   |  4 -
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 -
  drivers/gpu/drm/mediatek/mtk_drm_drv.c|  5 --
  drivers/gpu/drm/mediatek/mtk_drm_gem.c| 11 +++
  drivers/gpu/drm/msm/msm_drv.c | 13 ---
  drivers/gpu/drm/msm/msm_drv.h |  1 -
  drivers/gpu/drm/msm/msm_gem.c | 19 -
  drivers/gpu/drm/nouveau/nouveau_drm.c |  9 --
  drivers/gpu/drm/nouveau/nouveau_gem.c | 13 +++
  drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
  drivers/gpu/drm/nouveau/nouveau_prime.c   |  2 +
  drivers/gpu/drm/omapdrm/omap_drv.c|  9 --
  drivers/gpu/drm/omapdrm/omap_gem.c| 18 +++-
  drivers/gpu/drm/omapdrm/omap_gem.h|  2 -
  drivers/gpu/drm/pl111/pl111_drv.c |  5 +-
  

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81688/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 
279040
+./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81688/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
0479f6ad75dc drm/i915/gt: Widen CSB pointer to u64 for the parsers
f495c988d0c6 drm/i915/gt: Wait for CSB entries on Tigerlake
-:24: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl: 
Forcibly evict stale csb entries")'
#24: 
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")

-:52: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#52: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2509:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))

total: 2 errors, 0 warnings, 0 checks, 33 lines checked
53ad42fb5853 drm/i915/gt: Apply the CSB w/a for all
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl: 
Forcibly evict stale csb entries")'
#12: 
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")

-:82: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#82: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2536:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))

total: 2 errors, 0 warnings, 0 checks, 123 lines checked
f9b252d2da73 drm/i915/gt: Use a mmio read of the CSB in case of failure
-:42: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#42: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2546:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 10)) {

total: 1 errors, 0 warnings, 0 checks, 69 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Russell King - ARM Linux admin
On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in armada.
> 
> Signed-off-by: Thomas Zimmermann 

Acked-by: Russell King 

Thanks.

> ---
>  drivers/gpu/drm/armada/armada_drv.c |  3 ---
>  drivers/gpu/drm/armada/armada_gem.c | 12 +++-
>  drivers/gpu/drm/armada/armada_gem.h |  2 --
>  3 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 980d3f1f8f16..22247cfce80b 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -37,13 +37,10 @@ DEFINE_DRM_GEM_FOPS(armada_drm_fops);
>  
>  static struct drm_driver armada_drm_driver = {
>   .lastclose  = drm_fb_helper_lastclose,
> - .gem_free_object_unlocked = armada_gem_free_object,
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export   = armada_gem_prime_export,
>   .gem_prime_import   = armada_gem_prime_import,
>   .dumb_create= armada_gem_dumb_create,
> - .gem_vm_ops = _gem_vm_ops,
>   .major  = 1,
>   .minor  = 0,
>   .name   = "armada-drm",
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index ecf8a55e93d9..c343fbefe47c 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -25,7 +25,7 @@ static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
>   return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
>  }
>  
> -const struct vm_operations_struct armada_gem_vm_ops = {
> +static const struct vm_operations_struct armada_gem_vm_ops = {
>   .fault  = armada_gem_vm_fault,
>   .open   = drm_gem_vm_open,
>   .close  = drm_gem_vm_close,
> @@ -184,6 +184,12 @@ armada_gem_map_object(struct drm_device *dev, struct 
> armada_gem_object *dobj)
>   return dobj->addr;
>  }
>  
> +static const struct drm_gem_object_funcs armada_gem_object_funcs = {
> + .free = armada_gem_free_object,
> + .export = armada_gem_prime_export,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  struct armada_gem_object *
>  armada_gem_alloc_private_object(struct drm_device *dev, size_t size)
>  {
> @@ -195,6 +201,8 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
> size_t size)
>   if (!obj)
>   return NULL;
>  
> + obj->obj.funcs = _gem_object_funcs;
> +
>   drm_gem_private_object_init(dev, >obj, size);
>  
>   DRM_DEBUG_DRIVER("alloc private obj %p size %zu\n", obj, size);
> @@ -214,6 +222,8 @@ static struct armada_gem_object 
> *armada_gem_alloc_object(struct drm_device *dev,
>   if (!obj)
>   return NULL;
>  
> + obj->obj.funcs = _gem_object_funcs;
> +
>   if (drm_gem_object_init(dev, >obj, size)) {
>   kfree(obj);
>   return NULL;
> diff --git a/drivers/gpu/drm/armada/armada_gem.h 
> b/drivers/gpu/drm/armada/armada_gem.h
> index de04cc2c8f0e..ffcc7e8dd351 100644
> --- a/drivers/gpu/drm/armada/armada_gem.h
> +++ b/drivers/gpu/drm/armada/armada_gem.h
> @@ -21,8 +21,6 @@ struct armada_gem_object {
>   void*update_data;
>  };
>  
> -extern const struct vm_operations_struct armada_gem_vm_ops;
> -
>  #define drm_to_armada_gem(o) container_of(o, struct armada_gem_object, obj)
>  
>  void armada_gem_free_object(struct drm_gem_object *);
> -- 
> 2.28.0
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Christian König

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.

v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/radeon_drv.c | 23 +
  drivers/gpu/drm/radeon/radeon_gem.c | 31 +
  2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4cd30613fa1d..65061c949aee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -124,13 +124,6 @@ void radeon_driver_irq_preinstall_kms(struct drm_device 
*dev);
  int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
  void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
  irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg);
-void radeon_gem_object_free(struct drm_gem_object *obj);
-int radeon_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void radeon_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
-   int flags);
  extern int radeon_get_crtc_scanoutpos(struct drm_device *dev, unsigned int 
crtc,
  unsigned int flags, int *vpos, int *hpos,
  ktime_t *stime, ktime_t *etime,
@@ -145,14 +138,9 @@ int radeon_mode_dumb_mmap(struct drm_file *filp,
  int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
  struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device 
*dev,
struct 
dma_buf_attachment *,
struct sg_table *sg);
-int radeon_gem_prime_pin(struct drm_gem_object *obj);
-void radeon_gem_prime_unpin(struct drm_gem_object *obj);
-void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
-void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
  
  /* atpx handler */

  #if defined(CONFIG_VGA_SWITCHEROO)
@@ -550,7 +538,7 @@ long radeon_drm_ioctl(struct file *filp,
}
  
  	ret = drm_ioctl(filp, cmd, arg);

-   
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
return ret;
@@ -609,22 +597,13 @@ static struct drm_driver kms_driver = {
.irq_uninstall = radeon_driver_irq_uninstall_kms,
.irq_handler = radeon_driver_irq_handler_kms,
.ioctls = radeon_ioctls_kms,
-   .gem_free_object_unlocked = radeon_gem_object_free,
-   .gem_open_object = radeon_gem_object_open,
-   .gem_close_object = radeon_gem_object_close,
.dumb_create = radeon_mode_dumb_create,
.dumb_map_offset = radeon_mode_dumb_mmap,
.fops = _driver_kms_fops,
  
  	.prime_handle_to_fd = drm_gem_prime_handle_to_fd,

.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = radeon_gem_prime_export,
-   .gem_prime_pin = radeon_gem_prime_pin,
-   .gem_prime_unpin = radeon_gem_prime_unpin,
-   .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
-   .gem_prime_vmap = radeon_gem_prime_vmap,
-   .gem_prime_vunmap = radeon_gem_prime_vunmap,
  
  	.name = DRIVER_NAME,

.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index e5c4271e64ed..0ccd7213e41f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -35,7 +35,17 @@
  
  #include "radeon.h"
  
-void radeon_gem_object_free(struct drm_gem_object *gobj)

+struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
+   int flags);
+struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
+int radeon_gem_prime_pin(struct drm_gem_object *obj);
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);
+void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
+void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+
+static const struct drm_gem_object_funcs radeon_gem_object_funcs;
+
+static void radeon_gem_object_free(struct drm_gem_object *gobj)
  {
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
  
@@ -85,6 +95,7 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,

 

Re: [Intel-gfx] [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Christian König

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:

GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* move object-function instance to amdgpu_gem.c (Christian)
* set callbacks in amdgpu_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 23 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h|  5 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
  4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6edde2b9e402..840ca8f9c1e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
-   .gem_free_object_unlocked = amdgpu_gem_object_free,
-   .gem_open_object = amdgpu_gem_object_open,
-   .gem_close_object = amdgpu_gem_object_close,
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
  
  	.prime_handle_to_fd = drm_gem_prime_handle_to_fd,

.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_vmap = amdgpu_gem_prime_vmap,
-   .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
  
  	.name = DRIVER_NAME,

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index aa7f230c71bf..aeecd5dc3ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -36,9 +36,12 @@
  
  #include "amdgpu.h"

  #include "amdgpu_display.h"
+#include "amdgpu_dma_buf.h"
  #include "amdgpu_xgmi.h"
  
-void amdgpu_gem_object_free(struct drm_gem_object *gobj)

+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+
+static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
  {
struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
  
@@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size,

return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = _gem_object_funcs;
  
  	return 0;

  }
@@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device *adev)
   * Call from drm_gem_handle_create which appear in both new and open ioctl
   * case.
   */
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-  struct drm_file *file_priv)
+static int amdgpu_gem_object_open(struct drm_gem_object *obj,
+ struct drm_file *file_priv)
  {
struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
@@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
return 0;
  }
  
-void amdgpu_gem_object_close(struct drm_gem_object *obj,

-struct drm_file *file_priv)
+static void amdgpu_gem_object_close(struct drm_gem_object *obj,
+   struct drm_file *file_priv)
  {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
@@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
ttm_eu_backoff_reservation(, );
  }
  
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {

+   .free = amdgpu_gem_object_free,
+   .open = amdgpu_gem_object_open,
+   .close = amdgpu_gem_object_close,
+   .export = amdgpu_gem_prime_export,
+   .vmap = amdgpu_gem_prime_vmap,
+   .vunmap = amdgpu_gem_prime_vunmap,
+};
+
  /*
   * GEM ioctls.
   */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index e0f025dd1b14..637bf51dbf06 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -33,11 +33,6 @@
  #define AMDGPU_GEM_DOMAIN_MAX 0x3
  #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, 
tbo.base)
  
-void amdgpu_gem_object_free(struct drm_gem_object *obj);

-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
  unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
  
  /*

diff --git 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Check for a registered driver with IPS

2020-09-15 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Check for a registered driver with IPS
URL   : https://patchwork.freedesktop.org/series/81684/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9010_full -> Patchwork_18500_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_18500_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2] ([i915#155])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-kbl2/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-kbl2/igt@gem_exec_susp...@basic-s3.html
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([i915#198])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-skl4/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-skl9/igt@gem_exec_susp...@basic-s3.html

  * igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-skl:  [PASS][5] -> [TIMEOUT][6] ([i915#1958])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-skl3/igt@gem_userptr_bl...@unsync-unmap-cycles.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-kbl1/igt@i915_susp...@forcewake.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-kbl4/igt@i915_susp...@forcewake.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([i915#2370])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-skl4/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-skl9/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-glk9/igt@kms_flip@2x-dpms-vs-vblank-r...@ab-hdmi-a1-hdmi-a2.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-glk6/igt@kms_flip@2x-dpms-vs-vblank-r...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- shard-kbl:  [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-kbl6/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-kbl3/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html

  * igt@kms_frontbuffer_tracking@fbcpsr-shrfb-scaledprimary:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-tglb3/igt@kms_frontbuffer_track...@fbcpsr-shrfb-scaledprimary.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-shrfb-scaledprimary.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- shard-skl:  [PASS][19] -> [FAIL][20] ([i915#53])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-skl10/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-skl7/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-iclb8/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9010/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18500/shard-iclb8/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
- shard-hsw:  [PASS][25] -> [FAIL][26] ([i915#31])
   

[Intel-gfx] [PATCH v2 10/21] drm/omapdrm: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in omapdrm.

v2:
* make omap_gem_free_object() static (Tomi)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c |  9 -
 drivers/gpu/drm/omapdrm/omap_gem.c | 18 --
 drivers/gpu/drm/omapdrm/omap_gem.h |  2 --
 3 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 53d5e184ee77..2e598b8b72af 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -521,12 +521,6 @@ static int dev_open(struct drm_device *dev, struct 
drm_file *file)
return 0;
 }
 
-static const struct vm_operations_struct omap_gem_vm_ops = {
-   .fault = omap_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations omapdriver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -549,10 +543,7 @@ static struct drm_driver omap_drm_driver = {
 #endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = omap_gem_prime_export,
.gem_prime_import = omap_gem_prime_import,
-   .gem_free_object_unlocked = omap_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
.dumb_create = omap_gem_dumb_create,
.dumb_map_offset = omap_gem_dumb_map_offset,
.ioctls = ioctls,
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index d0d12d5dd76c..979d53a93c2b 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -487,7 +487,7 @@ static vm_fault_t omap_gem_fault_2d(struct drm_gem_object 
*obj,
  * vma->vm_private_data points to the GEM object that is backing this
  * mapping.
  */
-vm_fault_t omap_gem_fault(struct vm_fault *vmf)
+static vm_fault_t omap_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -1089,7 +1089,7 @@ void omap_gem_describe_objects(struct list_head *list, 
struct seq_file *m)
  * Constructor & Destructor
  */
 
-void omap_gem_free_object(struct drm_gem_object *obj)
+static void omap_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_device *dev = obj->dev;
struct omap_drm_private *priv = dev->dev_private;
@@ -1169,6 +1169,18 @@ static bool omap_gem_validate_flags(struct drm_device 
*dev, u32 flags)
return true;
 }
 
+static const struct vm_operations_struct omap_gem_vm_ops = {
+   .fault = omap_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs omap_gem_object_funcs = {
+   .free = omap_gem_free_object,
+   .export = omap_gem_prime_export,
+   .vm_ops = _gem_vm_ops,
+};
+
 /* GEM buffer object constructor */
 struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
@@ -1236,6 +1248,8 @@ struct drm_gem_object *omap_gem_new(struct drm_device 
*dev,
size = PAGE_ALIGN(gsize.bytes);
}
 
+   obj->funcs = _gem_object_funcs;
+
/* Initialize the GEM object. */
if (!(flags & OMAP_BO_MEM_SHMEM)) {
drm_gem_private_object_init(dev, obj, size);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h 
b/drivers/gpu/drm/omapdrm/omap_gem.h
index 729b7812a815..eda9b4839c30 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.h
+++ b/drivers/gpu/drm/omapdrm/omap_gem.h
@@ -48,7 +48,6 @@ struct drm_gem_object *omap_gem_new_dmabuf(struct drm_device 
*dev, size_t size,
struct sg_table *sgt);
 int omap_gem_new_handle(struct drm_device *dev, struct drm_file *file,
union omap_gem_size gsize, u32 flags, u32 *handle);
-void omap_gem_free_object(struct drm_gem_object *obj);
 void *omap_gem_vaddr(struct drm_gem_object *obj);
 
 /* Dumb Buffers Interface */
@@ -69,7 +68,6 @@ struct dma_buf *omap_gem_prime_export(struct drm_gem_object 
*obj, int flags);
 struct drm_gem_object *omap_gem_prime_import(struct drm_device *dev,
struct dma_buf *buffer);
 
-vm_fault_t omap_gem_fault(struct vm_fault *vmf);
 int omap_gem_roll(struct drm_gem_object *obj, u32 roll);
 void omap_gem_cpu_sync_page(struct drm_gem_object *obj, int pgoff);
 void omap_gem_dma_sync_buffer(struct drm_gem_object *obj,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 17/21] drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
 drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b039f493bda9..1f8d6ed11d21 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -203,7 +203,6 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_mmap = drm_gem_prime_mmap,
-   .gem_prime_export = virtgpu_gem_prime_export,
.gem_prime_import = virtgpu_gem_prime_import,
.gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 842f8b61aa89..4f7d7ea8194c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -108,6 +108,7 @@ static const struct drm_gem_object_funcs 
virtio_gpu_shmem_funcs = {
.close = virtio_gpu_gem_object_close,
 
.print_info = drm_gem_shmem_print_info,
+   .export = virtgpu_gem_prime_export,
.pin = drm_gem_shmem_pin,
.unpin = drm_gem_shmem_unpin,
.get_sg_table = drm_gem_shmem_get_sg_table,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 12/21] drm/radeon: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.

v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 23 +
 drivers/gpu/drm/radeon/radeon_gem.c | 31 +
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 4cd30613fa1d..65061c949aee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -124,13 +124,6 @@ void radeon_driver_irq_preinstall_kms(struct drm_device 
*dev);
 int radeon_driver_irq_postinstall_kms(struct drm_device *dev);
 void radeon_driver_irq_uninstall_kms(struct drm_device *dev);
 irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg);
-void radeon_gem_object_free(struct drm_gem_object *obj);
-int radeon_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void radeon_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
-   int flags);
 extern int radeon_get_crtc_scanoutpos(struct drm_device *dev, unsigned int 
crtc,
  unsigned int flags, int *vpos, int *hpos,
  ktime_t *stime, ktime_t *etime,
@@ -145,14 +138,9 @@ int radeon_mode_dumb_mmap(struct drm_file *filp,
 int radeon_mode_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device *dev,
struct 
dma_buf_attachment *,
struct sg_table *sg);
-int radeon_gem_prime_pin(struct drm_gem_object *obj);
-void radeon_gem_prime_unpin(struct drm_gem_object *obj);
-void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
-void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 
 /* atpx handler */
 #if defined(CONFIG_VGA_SWITCHEROO)
@@ -550,7 +538,7 @@ long radeon_drm_ioctl(struct file *filp,
}
 
ret = drm_ioctl(filp, cmd, arg);
-   
+
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
return ret;
@@ -609,22 +597,13 @@ static struct drm_driver kms_driver = {
.irq_uninstall = radeon_driver_irq_uninstall_kms,
.irq_handler = radeon_driver_irq_handler_kms,
.ioctls = radeon_ioctls_kms,
-   .gem_free_object_unlocked = radeon_gem_object_free,
-   .gem_open_object = radeon_gem_object_open,
-   .gem_close_object = radeon_gem_object_close,
.dumb_create = radeon_mode_dumb_create,
.dumb_map_offset = radeon_mode_dumb_mmap,
.fops = _driver_kms_fops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = radeon_gem_prime_export,
-   .gem_prime_pin = radeon_gem_prime_pin,
-   .gem_prime_unpin = radeon_gem_prime_unpin,
-   .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
-   .gem_prime_vmap = radeon_gem_prime_vmap,
-   .gem_prime_vunmap = radeon_gem_prime_vunmap,
 
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index e5c4271e64ed..0ccd7213e41f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -35,7 +35,17 @@
 
 #include "radeon.h"
 
-void radeon_gem_object_free(struct drm_gem_object *gobj)
+struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
+   int flags);
+struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
+int radeon_gem_prime_pin(struct drm_gem_object *obj);
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);
+void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
+void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+
+static const struct drm_gem_object_funcs radeon_gem_object_funcs;
+
+static void radeon_gem_object_free(struct drm_gem_object *gobj)
 {
struct radeon_bo *robj = gem_to_radeon_bo(gobj);
 
@@ -85,6 +95,7 @@ int radeon_gem_object_create(struct radeon_device *rdev, 
unsigned long size,
return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = 

[Intel-gfx] [PATCH v2 21/21] drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

2020-09-15 Thread Thomas Zimmermann
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.

What is also gone is gem_vm_ops in struct drm_driver. All drivers now
use struct drm_gem_object_funcs.vm_ops instead.

While at it, the patch also improves error handling around calls
to .free and .get_sg_table callbacks.

v2:
* update related TODO item (Sam)

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/todo.rst   |  7 +--
 drivers/gpu/drm/drm_gem.c| 35 +++-
 drivers/gpu/drm/drm_gem_cma_helper.c |  6 +-
 drivers/gpu/drm/drm_prime.c  | 17 +++---
 include/drm/drm_drv.h| 85 ++--
 5 files changed, 25 insertions(+), 125 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index b0ea17da8ff6..0fc6bc222392 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -289,11 +289,8 @@ struct drm_gem_object_funcs
 ---
 
 GEM objects can now have a function table instead of having the callbacks on 
the
-DRM driver struct. This is now the preferred way and drivers can be moved over.
-
-We also need a 2nd version of the CMA define that doesn't require the
-vmapping to be present (different hook for prime importing). Plus this needs to
-be rolled out to all drivers using their own implementations, too.
+DRM driver struct. This is now the preferred way. Callbacks in drivers have 
been
+converted, except for struct drm_driver.gem_prime_mmap.
 
 Level: Intermediate
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 19d73868490e..96945bed8291 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -247,12 +247,9 @@ drm_gem_object_release_handle(int id, void *ptr, void 
*data)
 {
struct drm_file *file_priv = data;
struct drm_gem_object *obj = ptr;
-   struct drm_device *dev = obj->dev;
 
if (obj->funcs && obj->funcs->close)
obj->funcs->close(obj, file_priv);
-   else if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, file_priv);
 
drm_gem_remove_prime_handles(obj, file_priv);
drm_vma_node_revoke(>vma_node, file_priv);
@@ -407,10 +404,6 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
ret = obj->funcs->open(obj, file_priv);
if (ret)
goto err_revoke;
-   } else if (dev->driver->gem_open_object) {
-   ret = dev->driver->gem_open_object(obj, file_priv);
-   if (ret)
-   goto err_revoke;
}
 
*handlep = handle;
@@ -982,12 +975,11 @@ drm_gem_object_free(struct kref *kref)
 {
struct drm_gem_object *obj =
container_of(kref, struct drm_gem_object, refcount);
-   struct drm_device *dev = obj->dev;
 
-   if (obj->funcs)
-   obj->funcs->free(obj);
-   else if (dev->driver->gem_free_object_unlocked)
-   dev->driver->gem_free_object_unlocked(obj);
+   if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free))
+   return;
+
+   obj->funcs->free(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_free);
 
@@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * @obj_size: the object size to be mapped, in bytes
  * @vma: VMA for the area to be mapped
  *
- * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops
- * provided by the driver. Depending on their requirements, drivers can either
- * provide a fault handler in their gem_vm_ops (in which case any accesses to
+ * Set up the VMA to prepare mapping of the GEM object using the GEM object's
+ * vm_ops. Depending on their requirements, GEM objects can either
+ * provide a fault handler in their vm_ops (in which case any accesses to
  * the object will be trapped, to perform migration, GTT binding, surface
  * register allocation, or performance monitoring), or mmap the buffer memory
  * synchronously after calling drm_gem_mmap_obj.
@@ -1065,12 +1057,11 @@ EXPORT_SYMBOL(drm_gem_vm_close);
  * callers must verify access restrictions before calling this helper.
  *
  * Return 0 or success or -EINVAL if the object size is smaller than the VMA
- * size, or if no gem_vm_ops are provided.
+ * size, or if no vm_ops are provided.
  */
 int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
 struct vm_area_struct *vma)
 {
-   struct drm_device *dev = obj->dev;
int ret;
 
/* Check for valid size. */
@@ -1095,8 +1086,6 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
long obj_size,
} else {
if (obj->funcs && obj->funcs->vm_ops)
vma->vm_ops = obj->funcs->vm_ops;
-   else if (dev->driver->gem_vm_ops)
-   

[Intel-gfx] [PATCH v2 20/21] drm/xlnx: Initialize DRM driver instance with CMA helper macro

2020-09-15 Thread Thomas Zimmermann
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.

Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default implementations, so they are just kept empty now.

v2:
* initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
index 8e69303aad3f..f3ffc3703a0e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -80,19 +80,7 @@ static struct drm_driver zynqmp_dpsub_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM |
  DRIVER_ATOMIC,
 
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = drm_gem_prime_export,
-   .gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
-   .gem_prime_import_sg_table  = drm_gem_cma_prime_import_sg_table,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
-   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
-   .gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .gem_free_object_unlocked   = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .dumb_create= zynqmp_dpsub_dumb_create,
-   .dumb_destroy   = drm_gem_dumb_destroy,
+   DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE(zynqmp_dpsub_dumb_create),
 
.fops   = _dpsub_drm_fops,
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 03/21] drm/etnaviv: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 ++-
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index a9a3afaef9a1..aa270b79e585 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -468,12 +468,6 @@ static const struct drm_ioctl_desc etnaviv_ioctls[] = {
ETNA_IOCTL(PM_QUERY_SIG, pm_query_sig, DRM_RENDER_ALLOW),
 };
 
-static const struct vm_operations_struct vm_ops = {
-   .fault = etnaviv_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations fops = {
.owner  = THIS_MODULE,
.open   = drm_open,
@@ -490,16 +484,9 @@ static struct drm_driver etnaviv_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
.open   = etnaviv_open,
.postclose   = etnaviv_postclose,
-   .gem_free_object_unlocked = etnaviv_gem_free_object,
-   .gem_vm_ops = _ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin  = etnaviv_gem_prime_pin,
-   .gem_prime_unpin= etnaviv_gem_prime_unpin,
-   .gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
.gem_prime_import_sg_table = etnaviv_gem_prime_import_sg_table,
-   .gem_prime_vmap = etnaviv_gem_prime_vmap,
-   .gem_prime_vunmap   = etnaviv_gem_prime_vunmap,
.gem_prime_mmap = etnaviv_gem_prime_mmap,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = etnaviv_debugfs_init,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 4d8dc9236e5f..914f0867ff71 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -49,7 +49,6 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void 
*data,
struct drm_file *file);
 
 int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf);
 int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
 struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
 void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index ea19f1d27275..312e9d58d5a7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -171,7 +171,7 @@ int etnaviv_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return obj->ops->mmap(obj, vma);
 }
 
-vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
+static vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -561,6 +561,22 @@ void etnaviv_gem_obj_add(struct drm_device *dev, struct 
drm_gem_object *obj)
mutex_unlock(>gem_lock);
 }
 
+static const struct vm_operations_struct vm_ops = {
+   .fault = etnaviv_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs etnaviv_gem_object_funcs = {
+   .free = etnaviv_gem_free_object,
+   .pin = etnaviv_gem_prime_pin,
+   .unpin = etnaviv_gem_prime_unpin,
+   .get_sg_table = etnaviv_gem_prime_get_sg_table,
+   .vmap = etnaviv_gem_prime_vmap,
+   .vunmap = etnaviv_gem_prime_vunmap,
+   .vm_ops = _ops,
+};
+
 static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
 {
@@ -595,6 +611,7 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, u32 
size, u32 flags,
INIT_LIST_HEAD(_obj->vram_list);
 
*obj = _obj->base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 16/21] drm/vgem: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb884c890065..fa54a6d1403d 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -50,6 +50,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+static const struct drm_gem_object_funcs vgem_gem_object_funcs;
+
 static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
@@ -167,6 +169,8 @@ static struct drm_vgem_gem_object *__vgem_gem_create(struct 
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
 
+   obj->base.funcs = _gem_object_funcs;
+
ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
if (ret) {
kfree(obj);
@@ -401,12 +405,20 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
 }
 
+static const struct drm_gem_object_funcs vgem_gem_object_funcs = {
+   .free = vgem_gem_free_object,
+   .pin = vgem_prime_pin,
+   .unpin = vgem_prime_unpin,
+   .get_sg_table = vgem_prime_get_sg_table,
+   .vmap = vgem_prime_vmap,
+   .vunmap = vgem_prime_vunmap,
+   .vm_ops = _gem_vm_ops,
+};
+
 static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_RENDER,
.open   = vgem_open,
.postclose  = vgem_postclose,
-   .gem_free_object_unlocked   = vgem_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
.ioctls = vgem_ioctls,
.num_ioctls = ARRAY_SIZE(vgem_ioctls),
.fops   = _driver_fops,
@@ -415,13 +427,8 @@ static struct drm_driver vgem_driver = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin = vgem_prime_pin,
-   .gem_prime_unpin = vgem_prime_unpin,
.gem_prime_import = vgem_prime_import,
.gem_prime_import_sg_table = vgem_prime_import_sg_table,
-   .gem_prime_get_sg_table = vgem_prime_get_sg_table,
-   .gem_prime_vmap = vgem_prime_vmap,
-   .gem_prime_vunmap = vgem_prime_vunmap,
.gem_prime_mmap = vgem_prime_mmap,
 
.name   = DRIVER_NAME,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 14/21] drm/tegra: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tegra/drm.c | 4 
 drivers/gpu/drm/tegra/gem.c | 8 
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index ba9d1c3e7cac..f0f581cd345e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -858,12 +858,8 @@ static struct drm_driver tegra_drm_driver = {
.debugfs_init = tegra_debugfs_init,
 #endif
 
-   .gem_free_object_unlocked = tegra_bo_free_object,
-   .gem_vm_ops = _bo_vm_ops,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = tegra_gem_prime_export,
.gem_prime_import = tegra_gem_prime_import,
 
.dumb_create = tegra_bo_dumb_create,
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 47e2935b8c68..d481dea4738d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -231,6 +231,12 @@ static int tegra_bo_iommu_unmap(struct tegra_drm *tegra, 
struct tegra_bo *bo)
return 0;
 }
 
+static const struct drm_gem_object_funcs tegra_gem_object_funcs = {
+   .free = tegra_bo_free_object,
+   .export = tegra_gem_prime_export,
+   .vm_ops = _bo_vm_ops,
+};
+
 static struct tegra_bo *tegra_bo_alloc_object(struct drm_device *drm,
  size_t size)
 {
@@ -241,6 +247,8 @@ static struct tegra_bo *tegra_bo_alloc_object(struct 
drm_device *drm,
if (!bo)
return ERR_PTR(-ENOMEM);
 
+   bo->gem.funcs = _gem_object_funcs;
+
host1x_bo_init(>base, _bo_ops);
size = round_up(size, PAGE_SIZE);
 
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 06/21] drm/i915: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.

v2:
* move object-function instance to i915_gem_object.c (Jani)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 ---
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 ---
 drivers/gpu/drm/i915/i915_drv.c   |  4 
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 ---
 4 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index c8421fd9d2dc..3389ac972d16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -39,9 +39,18 @@ static struct i915_global_object {
struct kmem_cache *slab_objects;
 } global;
 
+static const struct drm_gem_object_funcs i915_gem_object_funcs;
+
 struct drm_i915_gem_object *i915_gem_object_alloc(void)
 {
-   return kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   struct drm_i915_gem_object *obj;
+
+   obj = kmem_cache_zalloc(global.slab_objects, GFP_KERNEL);
+   if (!obj)
+   return NULL;
+   obj->base.funcs = _gem_object_funcs;
+
+   return obj;
 }
 
 void i915_gem_object_free(struct drm_i915_gem_object *obj)
@@ -101,7 +110,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
 }
 
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
+static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
*file)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem);
struct drm_i915_file_private *fpriv = file->driver_priv;
@@ -264,7 +273,7 @@ static void __i915_gem_free_work(struct work_struct *work)
i915_gem_flush_free_objects(i915);
 }
 
-void i915_gem_free_object(struct drm_gem_object *gem_obj)
+static void i915_gem_free_object(struct drm_gem_object *gem_obj)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
@@ -403,6 +412,12 @@ int __init i915_global_objects_init(void)
return 0;
 }
 
+static const struct drm_gem_object_funcs i915_gem_object_funcs = {
+   .free = i915_gem_free_object,
+   .close = i915_gem_close_object,
+   .export = i915_gem_prime_export,
+};
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
 #include "selftests/huge_pages.c"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d46db8d8f38e..eaf3d4147be0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -38,9 +38,6 @@ void __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
 
 int i915_gem_object_attach_phys(struct drm_i915_gem_object *obj, int align);
 
-void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
-void i915_gem_free_object(struct drm_gem_object *obj);
-
 void i915_gem_flush_free_objects(struct drm_i915_private *i915);
 
 struct sg_table *
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 94e00e450683..011a3fb41ece 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1750,12 +1750,8 @@ static struct drm_driver driver = {
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
 
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
-
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = i915_gem_prime_export,
.gem_prime_import = i915_gem_prime_import,
 
.dumb_create = i915_gem_dumb_create,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index f127e633f7ca..9244b5d6fb01 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -87,9 +87,6 @@ static struct drm_driver mock_driver = {
.name = "mock",
.driver_features = DRIVER_GEM,
.release = mock_device_release,
-
-   .gem_close_object = i915_gem_close_object,
-   .gem_free_object_unlocked = i915_gem_free_object,
 };
 
 static void release_dev(struct device *dev)
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 15/21] drm/vc4: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 21 -
 drivers/gpu/drm/vc4/vc4_drv.c | 12 
 drivers/gpu/drm/vc4/vc4_drv.h |  1 -
 3 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 74ceebd62fbc..f432278173cd 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -21,6 +21,8 @@
 #include "vc4_drv.h"
 #include "uapi/drm/vc4_drm.h"
 
+static vm_fault_t vc4_fault(struct vm_fault *vmf);
+
 static const char * const bo_type_names[] = {
"kernel",
"V3D",
@@ -374,6 +376,21 @@ static struct vc4_bo *vc4_bo_get_from_cache(struct 
drm_device *dev,
return bo;
 }
 
+static const struct vm_operations_struct vc4_vm_ops = {
+   .fault = vc4_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vc4_gem_object_funcs = {
+   .free = vc4_free_object,
+   .export = vc4_prime_export,
+   .get_sg_table = drm_gem_cma_prime_get_sg_table,
+   .vmap = vc4_prime_vmap,
+   .vunmap = drm_gem_cma_prime_vunmap,
+   .vm_ops = _vm_ops,
+};
+
 /**
  * vc4_gem_create_object - Implementation of driver->gem_create_object.
  * @dev: DRM device
@@ -400,6 +417,8 @@ struct drm_gem_object *vc4_create_object(struct drm_device 
*dev, size_t size)
vc4->bo_labels[VC4_BO_TYPE_KERNEL].size_allocated += size;
mutex_unlock(>bo_lock);
 
+   bo->base.base.funcs = _gem_object_funcs;
+
return >base.base;
 }
 
@@ -684,7 +703,7 @@ struct dma_buf * vc4_prime_export(struct drm_gem_object 
*obj, int flags)
return dmabuf;
 }
 
-vm_fault_t vc4_fault(struct vm_fault *vmf)
+static vm_fault_t vc4_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f1a5fd5dab6f..d27eaa2d0cfe 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -140,12 +140,6 @@ static void vc4_close(struct drm_device *dev, struct 
drm_file *file)
kfree(vc4file);
 }
 
-static const struct vm_operations_struct vc4_vm_ops = {
-   .fault = vc4_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -195,16 +189,10 @@ static struct drm_driver vc4_drm_driver = {
 #endif
 
.gem_create_object = vc4_create_object,
-   .gem_free_object_unlocked = vc4_free_object,
-   .gem_vm_ops = _vm_ops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = vc4_prime_export,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
-   .gem_prime_vmap = vc4_prime_vmap,
-   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = vc4_prime_mmap,
 
.dumb_create = vc4_dumb_create,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 8c8d96b6289f..a22478a35199 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -799,7 +799,6 @@ int vc4_get_hang_state_ioctl(struct drm_device *dev, void 
*data,
 struct drm_file *file_priv);
 int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
-vm_fault_t vc4_fault(struct vm_fault *vmf);
 int vc4_mmap(struct file *filp, struct vm_area_struct *vma);
 int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 08/21] drm/msm: Introduce GEM object funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/msm/msm_drv.c | 13 -
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 drivers/gpu/drm/msm/msm_gem.c | 19 ++-
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 79333842f70a..5952767ea478 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -978,12 +978,6 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
 };
 
-static const struct vm_operations_struct vm_ops = {
-   .fault = msm_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations fops = {
.owner  = THIS_MODULE,
.open   = drm_open,
@@ -1009,18 +1003,11 @@ static struct drm_driver msm_driver = {
.irq_preinstall = msm_irq_preinstall,
.irq_postinstall= msm_irq_postinstall,
.irq_uninstall  = msm_irq_uninstall,
-   .gem_free_object_unlocked = msm_gem_free_object,
-   .gem_vm_ops = _ops,
.dumb_create= msm_gem_dumb_create,
.dumb_map_offset= msm_gem_dumb_map_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin  = msm_gem_prime_pin,
-   .gem_prime_unpin= msm_gem_prime_unpin,
-   .gem_prime_get_sg_table = msm_gem_prime_get_sg_table,
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
-   .gem_prime_vmap = msm_gem_prime_vmap,
-   .gem_prime_vunmap   = msm_gem_prime_vunmap,
.gem_prime_mmap = msm_gem_prime_mmap,
 #ifdef CONFIG_DEBUG_FS
.debugfs_init   = msm_debugfs_init,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index af259b0573ea..7bcea10be81f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -269,7 +269,6 @@ void msm_gem_shrinker_cleanup(struct drm_device *dev);
 int msm_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
 int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-vm_fault_t msm_gem_fault(struct vm_fault *vmf);
 uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj);
 int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index b4553caaa196..de915ff6f4b4 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -247,7 +247,7 @@ int msm_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
return msm_gem_mmap_obj(vma->vm_private_data, vma);
 }
 
-vm_fault_t msm_gem_fault(struct vm_fault *vmf)
+static vm_fault_t msm_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
@@ -994,6 +994,22 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
return ret;
 }
 
+static const struct vm_operations_struct vm_ops = {
+   .fault = msm_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs msm_gem_object_funcs = {
+   .free = msm_gem_free_object,
+   .pin = msm_gem_prime_pin,
+   .unpin = msm_gem_prime_unpin,
+   .get_sg_table = msm_gem_prime_get_sg_table,
+   .vmap = msm_gem_prime_vmap,
+   .vunmap = msm_gem_prime_vunmap,
+   .vm_ops = _ops,
+};
+
 static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
struct drm_gem_object **obj)
@@ -1024,6 +1040,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
INIT_LIST_HEAD(_obj->vmas);
 
*obj = _obj->base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 05/21] drm/gma500: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in gma500.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/gma500/framebuffer.c |  2 ++
 drivers/gpu/drm/gma500/gem.c | 18 --
 drivers/gpu/drm/gma500/gem.h |  3 +++
 drivers/gpu/drm/gma500/psb_drv.c |  9 -
 drivers/gpu/drm/gma500/psb_drv.h |  2 --
 5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 54d9876b5305..5ede24fb44ae 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "framebuffer.h"
+#include "gem.h"
 #include "gtt.h"
 #include "psb_drv.h"
 #include "psb_intel_drv.h"
@@ -285,6 +286,7 @@ static struct gtt_range *psbfb_alloc(struct drm_device 
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1, PAGE_SIZE);
if (backing) {
+   backing->gem.funcs = _gem_object_funcs;
drm_gem_private_object_init(dev, >gem, aligned_size);
return backing;
}
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index f9c4b1d76f56..8f07de83b6fb 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -18,7 +18,9 @@
 
 #include "psb_drv.h"
 
-void psb_gem_free_object(struct drm_gem_object *obj)
+static vm_fault_t psb_gem_fault(struct vm_fault *vmf);
+
+static void psb_gem_free_object(struct drm_gem_object *obj)
 {
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
 
@@ -36,6 +38,17 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
return -EINVAL;
 }
 
+static const struct vm_operations_struct psb_gem_vm_ops = {
+   .fault = psb_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+const struct drm_gem_object_funcs psb_gem_object_funcs = {
+   .free = psb_gem_free_object,
+   .vm_ops = _gem_vm_ops,
+};
+
 /**
  * psb_gem_create  -   create a mappable object
  * @file: the DRM file of the client
@@ -63,6 +76,7 @@ int psb_gem_create(struct drm_file *file, struct drm_device 
*dev, u64 size,
dev_err(dev->dev, "no memory for %lld byte GEM object\n", size);
return -ENOSPC;
}
+   r->gem.funcs = _gem_object_funcs;
/* Initialize the extra goodies GEM needs to do all the hard work */
if (drm_gem_object_init(dev, >gem, size) != 0) {
psb_gtt_free_range(dev, r);
@@ -123,7 +137,7 @@ int psb_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
  * vma->vm_private_data points to the GEM object that is backing this
  * mapping.
  */
-vm_fault_t psb_gem_fault(struct vm_fault *vmf)
+static vm_fault_t psb_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj;
diff --git a/drivers/gpu/drm/gma500/gem.h b/drivers/gpu/drm/gma500/gem.h
index 4a74dc623b6b..3741a711b9fd 100644
--- a/drivers/gpu/drm/gma500/gem.h
+++ b/drivers/gpu/drm/gma500/gem.h
@@ -8,6 +8,9 @@
 #ifndef _GEM_H
 #define _GEM_H
 
+extern const struct drm_gem_object_funcs psb_gem_object_funcs;
+
 extern int psb_gem_create(struct drm_file *file, struct drm_device *dev,
  u64 size, u32 *handlep, int stolen, u32 align);
+
 #endif
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 34b4aae9a15e..b13376a6fb91 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -480,12 +480,6 @@ static const struct dev_pm_ops psb_pm_ops = {
.runtime_idle = psb_runtime_idle,
 };
 
-static const struct vm_operations_struct psb_gem_vm_ops = {
-   .fault = psb_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct file_operations psb_gem_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -507,9 +501,6 @@ static struct drm_driver driver = {
.irq_uninstall = psb_irq_uninstall,
.irq_handler = psb_irq_handler,
 
-   .gem_free_object_unlocked = psb_gem_free_object,
-   .gem_vm_ops = _gem_vm_ops,
-
.dumb_create = psb_gem_dumb_create,
.ioctls = psb_ioctls,
.fops = _gem_fops,
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 956926341316..c71a5a4e912c 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -735,12 +735,10 @@ extern const struct drm_connector_helper_funcs
 extern const struct drm_connector_funcs psb_intel_lvds_connector_funcs;
 
 /* gem.c */
-extern void psb_gem_free_object(struct drm_gem_object *obj);
 extern int psb_gem_get_aperture(struct drm_device *dev, void *data,

[Intel-gfx] [PATCH v2 13/21] drm/rockchip: Convert to drm_gem_object_funcs

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |  5 -
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 10 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 0f3eb392fe39..b7654f5e4225 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -212,15 +212,10 @@ static const struct file_operations 
rockchip_drm_driver_fops = {
 static struct drm_driver rockchip_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
.lastclose  = drm_fb_helper_lastclose,
-   .gem_vm_ops = _gem_cma_vm_ops,
-   .gem_free_object_unlocked = rockchip_gem_free_object,
.dumb_create= rockchip_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = rockchip_gem_prime_import_sg_table,
-   .gem_prime_vmap = rockchip_gem_prime_vmap,
-   .gem_prime_vunmap   = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
.fops   = _drm_driver_fops,
.name   = DRIVER_NAME,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0055d86576f7..bddc7d99efe3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -296,6 +296,14 @@ static void rockchip_gem_release_object(struct 
rockchip_gem_object *rk_obj)
kfree(rk_obj);
 }
 
+static const struct drm_gem_object_funcs rockchip_gem_object_funcs = {
+   .free = rockchip_gem_free_object,
+   .get_sg_table = rockchip_gem_prime_get_sg_table,
+   .vmap = rockchip_gem_prime_vmap,
+   .vunmap = rockchip_gem_prime_vunmap,
+   .vm_ops = _gem_cma_vm_ops,
+};
+
 static struct rockchip_gem_object *
rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
 {
@@ -310,6 +318,8 @@ static struct rockchip_gem_object *
 
obj = _obj->base;
 
+   obj->funcs = _gem_object_funcs;
+
drm_gem_object_init(drm, obj, size);
 
return rk_obj;
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 11/21] drm/pl111: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in pl111. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* use drm_gem_cma_create_object_default_funcs() (Eric)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 46b0d1c4a16c..ecef8a2383d2 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -224,15 +224,12 @@ static struct drm_driver pl111_drm_driver = {
.major = 1,
.minor = 0,
.patchlevel = 0,
+   .gem_create_object = drm_gem_cma_create_object_default_funcs,
.dumb_create = drm_gem_cma_dumb_create,
-   .gem_free_object_unlocked = drm_gem_cma_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
-   .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .gem_prime_vmap = drm_gem_cma_prime_vmap,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 18/21] drm/vkms: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vkms/vkms_drv.c |  8 
 drivers/gpu/drm/vkms/vkms_gem.c | 13 +
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index cb0b6230c22c..726801ab44d4 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
.release= drm_release,
 };
 
-static const struct vm_operations_struct vkms_gem_vm_ops = {
-   .fault = vkms_gem_fault,
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static void vkms_release(struct drm_device *dev)
 {
struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
@@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
.release= vkms_release,
.fops   = _driver_fops,
.dumb_create= vkms_dumb_create,
-   .gem_vm_ops = _gem_vm_ops,
-   .gem_free_object_unlocked = vkms_gem_free_object,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = vkms_prime_import_sg_table,
 
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index a017fc59905e..19a0e260a4df 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -7,6 +7,17 @@
 
 #include "vkms_drv.h"
 
+static const struct vm_operations_struct vkms_gem_vm_ops = {
+   .fault = vkms_gem_fault,
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
+   .free = vkms_gem_free_object,
+   .vm_ops = _gem_vm_ops,
+};
+
 static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
 u64 size)
 {
@@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct 
drm_device *dev,
if (!obj)
return ERR_PTR(-ENOMEM);
 
+   obj->gem.funcs = _gem_object_funcs;
+
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(dev, >gem, size);
if (ret) {
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 07/21] drm/mediatek: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  5 -
 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 11 +++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 040a8f393fe2..2f8d0043fca7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -301,18 +301,13 @@ struct drm_gem_object *mtk_drm_gem_prime_import(struct 
drm_device *dev,
 static struct drm_driver mtk_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
 
-   .gem_free_object_unlocked = mtk_drm_gem_free_object,
-   .gem_vm_ops = _gem_cma_vm_ops,
.dumb_create = mtk_drm_gem_dumb_create,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = mtk_drm_gem_prime_import,
-   .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,
-   .gem_prime_vmap = mtk_drm_gem_prime_vmap,
-   .gem_prime_vunmap = mtk_drm_gem_prime_vunmap,
.fops = _drm_fops,
 
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c 
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 6190cc3b7b0d..591b90410e4a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -8,11 +8,20 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mtk_drm_drv.h"
 #include "mtk_drm_gem.h"
 
+static const struct drm_gem_object_funcs mtk_drm_gem_object_funcs = {
+   .free = mtk_drm_gem_free_object,
+   .get_sg_table = mtk_gem_prime_get_sg_table,
+   .vmap = mtk_drm_gem_prime_vmap,
+   .vunmap = mtk_drm_gem_prime_vunmap,
+   .vm_ops = _gem_cma_vm_ops,
+};
+
 static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
unsigned long size)
 {
@@ -25,6 +34,8 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct 
drm_device *dev,
if (!mtk_gem_obj)
return ERR_PTR(-ENOMEM);
 
+   mtk_gem_obj->base.funcs = _drm_gem_object_funcs;
+
ret = drm_gem_object_init(dev, _gem_obj->base, size);
if (ret < 0) {
DRM_ERROR("failed to initialize gem object\n");
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 19/21] drm/xen: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* convert xen_drm_drv_free_object_unlocked() to static
  callback (Oleksandr)

Signed-off-by: Thomas Zimmermann 
Acked-by: Oleksandr Andrushchenko 
---
 drivers/gpu/drm/xen/xen_drm_front.c | 44 ++---
 drivers/gpu/drm/xen/xen_drm_front.h |  2 ++
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 15 +
 3 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index cc93a8c9547b..98b6d2ba088a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -381,6 +381,23 @@ void xen_drm_front_on_frame_done(struct xen_drm_front_info 
*front_info,
fb_cookie);
 }
 
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj)
+{
+   struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
+   int idx;
+
+   if (drm_dev_enter(obj->dev, )) {
+   xen_drm_front_dbuf_destroy(drm_info->front_info,
+  xen_drm_front_dbuf_to_cookie(obj));
+   drm_dev_exit(idx);
+   } else {
+   dbuf_free(_info->front_info->dbuf_list,
+ xen_drm_front_dbuf_to_cookie(obj));
+   }
+
+   xen_drm_front_gem_free_object_unlocked(obj);
+}
+
 static int xen_drm_drv_dumb_create(struct drm_file *filp,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args)
@@ -435,23 +452,6 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
return ret;
 }
 
-static void xen_drm_drv_free_object_unlocked(struct drm_gem_object *obj)
-{
-   struct xen_drm_front_drm_info *drm_info = obj->dev->dev_private;
-   int idx;
-
-   if (drm_dev_enter(obj->dev, )) {
-   xen_drm_front_dbuf_destroy(drm_info->front_info,
-  xen_drm_front_dbuf_to_cookie(obj));
-   drm_dev_exit(idx);
-   } else {
-   dbuf_free(_info->front_info->dbuf_list,
- xen_drm_front_dbuf_to_cookie(obj));
-   }
-
-   xen_drm_front_gem_free_object_unlocked(obj);
-}
-
 static void xen_drm_drv_release(struct drm_device *dev)
 {
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
@@ -483,22 +483,12 @@ static const struct file_operations xen_drm_dev_fops = {
.mmap   = xen_drm_front_gem_mmap,
 };
 
-static const struct vm_operations_struct xen_drm_drv_vm_ops = {
-   .open   = drm_gem_vm_open,
-   .close  = drm_gem_vm_close,
-};
-
 static struct drm_driver xen_drm_driver = {
.driver_features   = DRIVER_GEM | DRIVER_MODESET | 
DRIVER_ATOMIC,
.release   = xen_drm_drv_release,
-   .gem_vm_ops= _drm_drv_vm_ops,
-   .gem_free_object_unlocked  = xen_drm_drv_free_object_unlocked,
.prime_handle_to_fd= drm_gem_prime_handle_to_fd,
.prime_fd_to_handle= drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = xen_drm_front_gem_import_sg_table,
-   .gem_prime_get_sg_table= xen_drm_front_gem_get_sg_table,
-   .gem_prime_vmap= xen_drm_front_gem_prime_vmap,
-   .gem_prime_vunmap  = xen_drm_front_gem_prime_vunmap,
.gem_prime_mmap= xen_drm_front_gem_prime_mmap,
.dumb_create   = xen_drm_drv_dumb_create,
.fops  = _drm_dev_fops,
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h 
b/drivers/gpu/drm/xen/xen_drm_front.h
index 54486d89650e..cefafe859aba 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -160,4 +160,6 @@ int xen_drm_front_page_flip(struct xen_drm_front_info 
*front_info,
 void xen_drm_front_on_frame_done(struct xen_drm_front_info *front_info,
 int conn_idx, u64 fb_cookie);
 
+void xen_drm_front_gem_object_free(struct drm_gem_object *obj);
+
 #endif /* __XEN_DRM_FRONT_H_ */
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index a8aefaa38bd3..f3830a0d1808 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -57,6 +57,19 @@ static void gem_free_pages_array(struct xen_gem_object 
*xen_obj)
xen_obj->pages = NULL;
 }
 
+static const struct vm_operations_struct xen_drm_drv_vm_ops = {
+   .open   = drm_gem_vm_open,
+   .close  = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs xen_drm_front_gem_object_funcs = {
+   .free = xen_drm_front_gem_object_free,
+   .get_sg_table = 

[Intel-gfx] [PATCH v2 09/21] drm/nouveau: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in nouveau.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  9 -
 drivers/gpu/drm/nouveau/nouveau_gem.c   | 13 +
 drivers/gpu/drm/nouveau/nouveau_gem.h   |  2 ++
 drivers/gpu/drm/nouveau/nouveau_prime.c |  2 ++
 4 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 42fc5c813a9b..72640bca1617 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1207,16 +1207,7 @@ driver_stub = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_pin = nouveau_gem_prime_pin,
-   .gem_prime_unpin = nouveau_gem_prime_unpin,
-   .gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
-   .gem_prime_vmap = nouveau_gem_prime_vmap,
-   .gem_prime_vunmap = nouveau_gem_prime_vunmap,
-
-   .gem_free_object_unlocked = nouveau_gem_object_del,
-   .gem_open_object = nouveau_gem_object_open,
-   .gem_close_object = nouveau_gem_object_close,
 
.dumb_create = nouveau_display_dumb_create,
.dumb_map_offset = nouveau_display_dumb_map_offset,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 89adadf4706b..28e0cbb00876 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -169,6 +169,17 @@ nouveau_gem_object_close(struct drm_gem_object *gem, 
struct drm_file *file_priv)
ttm_bo_unreserve(>bo);
 }
 
+const struct drm_gem_object_funcs nouveau_gem_object_funcs = {
+   .free = nouveau_gem_object_del,
+   .open = nouveau_gem_object_open,
+   .close = nouveau_gem_object_close,
+   .pin = nouveau_gem_prime_pin,
+   .unpin = nouveau_gem_prime_unpin,
+   .get_sg_table = nouveau_gem_prime_get_sg_table,
+   .vmap = nouveau_gem_prime_vmap,
+   .vunmap = nouveau_gem_prime_vunmap,
+};
+
 int
 nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain,
uint32_t tile_mode, uint32_t tile_flags,
@@ -186,6 +197,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int 
align, uint32_t domain,
if (IS_ERR(nvbo))
return PTR_ERR(nvbo);
 
+   nvbo->bo.base.funcs = _gem_object_funcs;
+
/* Initialize the embedded gem-object. We return a single gem-reference
 * to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(drm->dev, >bo.base, size);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index 978e07591990..b35c180322e2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -5,6 +5,8 @@
 #include "nouveau_drv.h"
 #include "nouveau_bo.h"
 
+extern const struct drm_gem_object_funcs nouveau_gem_object_funcs;
+
 static inline struct nouveau_bo *
 nouveau_gem_object(struct drm_gem_object *gem)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index b2ecb91f8ddc..a8264aebf3d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -77,6 +77,8 @@ struct drm_gem_object 
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
 
nvbo->valid_domains = NOUVEAU_GEM_DOMAIN_GART;
 
+   nvbo->bo.base.funcs = _gem_object_funcs;
+
/* Initialize the embedded gem-object. We return a single gem-reference
 * to the caller, instead of a normal nouveau_bo ttm reference. */
ret = drm_gem_object_init(dev, >bo.base, size);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 04/21] drm/exynos: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in exynos. The only exception is gem_prime_mmap,
which is non-trivial to convert.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 +++
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index dbd80f1e4c78..fe46680ca208 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -75,11 +75,6 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
file->driver_priv = NULL;
 }
 
-static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
-   .open = drm_gem_vm_open,
-   .close = drm_gem_vm_close,
-};
-
 static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_RENDER_ALLOW),
@@ -124,16 +119,11 @@ static struct drm_driver exynos_drm_driver = {
.open   = exynos_drm_open,
.lastclose  = drm_fb_helper_lastclose,
.postclose  = exynos_drm_postclose,
-   .gem_free_object_unlocked = exynos_drm_gem_free_object,
-   .gem_vm_ops = _drm_gem_vm_ops,
.dumb_create= exynos_drm_gem_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import   = exynos_drm_gem_prime_import,
-   .gem_prime_get_sg_table = exynos_drm_gem_prime_get_sg_table,
.gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
-   .gem_prime_vmap = exynos_drm_gem_prime_vmap,
-   .gem_prime_vunmap   = exynos_drm_gem_prime_vunmap,
.gem_prime_mmap = exynos_drm_gem_prime_mmap,
.ioctls = exynos_ioctls,
.num_ioctls = ARRAY_SIZE(exynos_ioctls),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index efa476858db5..69a5cf28b4ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -129,6 +129,19 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem 
*exynos_gem)
kfree(exynos_gem);
 }
 
+static const struct vm_operations_struct exynos_drm_gem_vm_ops = {
+   .open = drm_gem_vm_open,
+   .close = drm_gem_vm_close,
+};
+
+static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
+   .free = exynos_drm_gem_free_object,
+   .get_sg_table = exynos_drm_gem_prime_get_sg_table,
+   .vmap = exynos_drm_gem_prime_vmap,
+   .vunmap = exynos_drm_gem_prime_vunmap,
+   .vm_ops = _drm_gem_vm_ops,
+};
+
 static struct exynos_drm_gem *exynos_drm_gem_init(struct drm_device *dev,
  unsigned long size)
 {
@@ -143,6 +156,8 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct 
drm_device *dev,
exynos_gem->size = size;
obj = _gem->base;
 
+   obj->funcs = _drm_gem_object_funcs;
+
ret = drm_gem_object_init(dev, obj, size);
if (ret < 0) {
DRM_DEV_ERROR(dev->dev, "failed to initialize gem object\n");
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.

v2:
* move object-function instance to amdgpu_gem.c (Christian)
* set callbacks in amdgpu_gem_object_create() (Christian)

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 23 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h|  5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6edde2b9e402..840ca8f9c1e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
.lastclose = amdgpu_driver_lastclose_kms,
.irq_handler = amdgpu_irq_handler,
.ioctls = amdgpu_ioctls_kms,
-   .gem_free_object_unlocked = amdgpu_gem_object_free,
-   .gem_open_object = amdgpu_gem_object_open,
-   .gem_close_object = amdgpu_gem_object_close,
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
-   .gem_prime_vmap = amdgpu_gem_prime_vmap,
-   .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
.gem_prime_mmap = amdgpu_gem_prime_mmap,
 
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index aa7f230c71bf..aeecd5dc3ce4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -36,9 +36,12 @@
 
 #include "amdgpu.h"
 #include "amdgpu_display.h"
+#include "amdgpu_dma_buf.h"
 #include "amdgpu_xgmi.h"
 
-void amdgpu_gem_object_free(struct drm_gem_object *gobj)
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
+
+static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
 {
struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
 
@@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
return r;
}
*obj = >tbo.base;
+   (*obj)->funcs = _gem_object_funcs;
 
return 0;
 }
@@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device *adev)
  * Call from drm_gem_handle_create which appear in both new and open ioctl
  * case.
  */
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-  struct drm_file *file_priv)
+static int amdgpu_gem_object_open(struct drm_gem_object *obj,
+ struct drm_file *file_priv)
 {
struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
@@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
return 0;
 }
 
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-struct drm_file *file_priv)
+static void amdgpu_gem_object_close(struct drm_gem_object *obj,
+   struct drm_file *file_priv)
 {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
@@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
ttm_eu_backoff_reservation(, );
 }
 
+static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
+   .free = amdgpu_gem_object_free,
+   .open = amdgpu_gem_object_open,
+   .close = amdgpu_gem_object_close,
+   .export = amdgpu_gem_prime_export,
+   .vmap = amdgpu_gem_prime_vmap,
+   .vunmap = amdgpu_gem_prime_vunmap,
+};
+
 /*
  * GEM ioctls.
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index e0f025dd1b14..637bf51dbf06 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -33,11 +33,6 @@
 #define AMDGPU_GEM_DOMAIN_MAX  0x3
 #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, tbo.base)
 
-void amdgpu_gem_object_free(struct drm_gem_object *obj);
-int amdgpu_gem_object_open(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
-void amdgpu_gem_object_close(struct drm_gem_object *obj,
-   struct drm_file *file_priv);
 unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
 
 /*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 

[Intel-gfx] [PATCH v2 02/21] drm/armada: Introduce GEM object functions

2020-09-15 Thread Thomas Zimmermann
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in armada.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/armada/armada_drv.c |  3 ---
 drivers/gpu/drm/armada/armada_gem.c | 12 +++-
 drivers/gpu/drm/armada/armada_gem.h |  2 --
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 980d3f1f8f16..22247cfce80b 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -37,13 +37,10 @@ DEFINE_DRM_GEM_FOPS(armada_drm_fops);
 
 static struct drm_driver armada_drm_driver = {
.lastclose  = drm_fb_helper_lastclose,
-   .gem_free_object_unlocked = armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export   = armada_gem_prime_export,
.gem_prime_import   = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
-   .gem_vm_ops = _gem_vm_ops,
.major  = 1,
.minor  = 0,
.name   = "armada-drm",
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index ecf8a55e93d9..c343fbefe47c 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -25,7 +25,7 @@ static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
 }
 
-const struct vm_operations_struct armada_gem_vm_ops = {
+static const struct vm_operations_struct armada_gem_vm_ops = {
.fault  = armada_gem_vm_fault,
.open   = drm_gem_vm_open,
.close  = drm_gem_vm_close,
@@ -184,6 +184,12 @@ armada_gem_map_object(struct drm_device *dev, struct 
armada_gem_object *dobj)
return dobj->addr;
 }
 
+static const struct drm_gem_object_funcs armada_gem_object_funcs = {
+   .free = armada_gem_free_object,
+   .export = armada_gem_prime_export,
+   .vm_ops = _gem_vm_ops,
+};
+
 struct armada_gem_object *
 armada_gem_alloc_private_object(struct drm_device *dev, size_t size)
 {
@@ -195,6 +201,8 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
size_t size)
if (!obj)
return NULL;
 
+   obj->obj.funcs = _gem_object_funcs;
+
drm_gem_private_object_init(dev, >obj, size);
 
DRM_DEBUG_DRIVER("alloc private obj %p size %zu\n", obj, size);
@@ -214,6 +222,8 @@ static struct armada_gem_object 
*armada_gem_alloc_object(struct drm_device *dev,
if (!obj)
return NULL;
 
+   obj->obj.funcs = _gem_object_funcs;
+
if (drm_gem_object_init(dev, >obj, size)) {
kfree(obj);
return NULL;
diff --git a/drivers/gpu/drm/armada/armada_gem.h 
b/drivers/gpu/drm/armada/armada_gem.h
index de04cc2c8f0e..ffcc7e8dd351 100644
--- a/drivers/gpu/drm/armada/armada_gem.h
+++ b/drivers/gpu/drm/armada/armada_gem.h
@@ -21,8 +21,6 @@ struct armada_gem_object {
void*update_data;
 };
 
-extern const struct vm_operations_struct armada_gem_vm_ops;
-
 #define drm_to_armada_gem(o) container_of(o, struct armada_gem_object, obj)
 
 void armada_gem_free_object(struct drm_gem_object *);
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 00/21] Convert all remaining drivers to GEM object functions

2020-09-15 Thread Thomas Zimmermann
The GEM and PRIME related callbacks in struct drm_driver are deprecated in
favor of GEM object functions in struct drm_gem_object_funcs. This patchset
converts the remaining drivers to object functions and removes most of the
obsolete interfaces.

Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions,
one by one. Each patch moves existing callbacks from struct drm_driver to an
instance of struct drm_gem_object_funcs, and sets these funcs when the GEM
object is initialized. The expection is .gem_prime_mmap. There are different
ways of how drivers implement the callback, and moving it to GEM object
functions requires a closer review for each.

Patch #17 fixes virtgpu to use GEM object functions where possible. The
driver recently introduced a function for one of the deprecated callbacks.

Patch #20 converts xlnx to CMA helper macros. There's no apparent reason
why the driver does the GEM setup on it's own. Using CMA helper macros
adds GEM object functions implicitly.

With most of the GEM and PRIME moved to GEM object functions, related code
in struct drm_driver and in the DRM core/helpers is being removed by patch
#21.

Further testing is welcome. I tested the drivers for which I have HW
available. These are gma500, i915, nouveau, radeon and vc4. The console,
Weston and Xorg apparently work with the patches applied.

v2:
* moved code in amdgpu and radeon
* made several functions static in various drivers
* updated TODO-list item
* fix virtgpu

Thomas Zimmermann (21):
  drm/amdgpu: Introduce GEM object functions
  drm/armada: Introduce GEM object functions
  drm/etnaviv: Introduce GEM object functions
  drm/exynos: Introduce GEM object functions
  drm/gma500: Introduce GEM object functions
  drm/i915: Introduce GEM object functions
  drm/mediatek: Introduce GEM object functions
  drm/msm: Introduce GEM object funcs
  drm/nouveau: Introduce GEM object functions
  drm/omapdrm: Introduce GEM object functions
  drm/pl111: Introduce GEM object functions
  drm/radeon: Introduce GEM object functions
  drm/rockchip: Convert to drm_gem_object_funcs
  drm/tegra: Introduce GEM object functions
  drm/vc4: Introduce GEM object functions
  drm/vgem: Introduce GEM object functions
  drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
  drm/vkms: Introduce GEM object functions
  drm/xen: Introduce GEM object functions
  drm/xlnx: Initialize DRM driver instance with CMA helper macro
  drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver

 Documentation/gpu/todo.rst|  7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  6 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 23 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h   |  5 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  1 +
 drivers/gpu/drm/armada/armada_drv.c   |  3 -
 drivers/gpu/drm/armada/armada_gem.c   | 12 ++-
 drivers/gpu/drm/armada/armada_gem.h   |  2 -
 drivers/gpu/drm/drm_gem.c | 35 ++--
 drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
 drivers/gpu/drm/drm_prime.c   | 17 ++--
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 ---
 drivers/gpu/drm/etnaviv/etnaviv_drv.h |  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 10 ---
 drivers/gpu/drm/exynos/exynos_drm_gem.c   | 15 
 drivers/gpu/drm/gma500/framebuffer.c  |  2 +
 drivers/gpu/drm/gma500/gem.c  | 18 +++-
 drivers/gpu/drm/gma500/gem.h  |  3 +
 drivers/gpu/drm/gma500/psb_drv.c  |  9 --
 drivers/gpu/drm/gma500/psb_drv.h  |  2 -
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 -
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 -
 drivers/gpu/drm/i915/i915_drv.c   |  4 -
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  3 -
 drivers/gpu/drm/mediatek/mtk_drm_drv.c|  5 --
 drivers/gpu/drm/mediatek/mtk_drm_gem.c| 11 +++
 drivers/gpu/drm/msm/msm_drv.c | 13 ---
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 drivers/gpu/drm/msm/msm_gem.c | 19 -
 drivers/gpu/drm/nouveau/nouveau_drm.c |  9 --
 drivers/gpu/drm/nouveau/nouveau_gem.c | 13 +++
 drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
 drivers/gpu/drm/nouveau/nouveau_prime.c   |  2 +
 drivers/gpu/drm/omapdrm/omap_drv.c|  9 --
 drivers/gpu/drm/omapdrm/omap_gem.c| 18 +++-
 drivers/gpu/drm/omapdrm/omap_gem.h|  2 -
 drivers/gpu/drm/pl111/pl111_drv.c |  5 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 23 +
 drivers/gpu/drm/radeon/radeon_gem.c   | 31 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  5 --
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   | 10 +++
 drivers/gpu/drm/tegra/drm.c   |  4 -
 drivers/gpu/drm/tegra/gem.c   |  8 ++
 

Re: [Intel-gfx] [PATCH v8 5/8] drm/i915: Add dedicated plane hook for async flip case

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
> 
> v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
> -Add a vfunc for skl_program_async_surface_address
>  and call it from intel_update_plane. (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  7 ++
>  .../drm/i915/display/intel_display_types.h|  3 +++
>  drivers/gpu/drm/i915/display/intel_sprite.c   | 24 +++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 79032701873a..fdc633020255 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -408,6 +408,13 @@ void intel_update_plane(struct intel_plane *plane,
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
>   trace_intel_update_plane(>base, crtc);
> +
> + if (crtc_state->uapi.async_flip) {

Hmm. Now I'm starting to wonder how this is actually going to interact
with legacy cursor updates. The crtc_state we use there I think comes
from the previous update and so will have this flag set it if was an
async flip. Which means the cursor ioctl will oops.

We may want the igt to check this particular combination of ioctls
actually.

> + plane->program_async_surface_address(plane,
> +  crtc_state, plane_state);
> + return;
> + }
> +
>   plane->update_plane(plane, crtc_state, plane_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b2d0edacc58c..d2ae781e4d81 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1190,6 +1190,9 @@ struct intel_plane {
>  struct intel_plane_state *plane_state);
>   int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
>const struct intel_plane_state *plane_state);
> + void (*program_async_surface_address)(struct intel_plane *plane,
> +   const struct intel_crtc_state 
> *crtc_state,
> +   const struct intel_plane_state 
> *plane_state);
>  };
>  
>  struct intel_watermark_params {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index f0c89418d2e1..69407dfcebf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
>  }
>  
> +static void
> +skl_program_async_surface_address(struct intel_plane *plane,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct intel_plane_state *plane_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + unsigned long irqflags;
> + enum plane_id plane_id = plane->id;
> + enum pipe pipe = plane->pipe;
> + u32 surf_addr = plane_state->color_plane[0].offset;
> + u32 plane_ctl = plane_state->ctl;
> +
> + plane_ctl |= skl_plane_ctl_crtc(crtc_state);
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> +   intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> +}
> +
>  static void
>  skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -3096,6 +3119,7 @@ skl_universal_plane_create(struct drm_i915_private 
> *dev_priv,
>   plane->get_hw_state = skl_plane_get_hw_state;
>   plane->check_plane = skl_plane_check;
>   plane->min_cdclk = skl_plane_min_cdclk;
> + plane->program_async_surface_address = 
> skl_program_async_surface_address;
>  
>   if (INTEL_GEN(dev_priv) >= 11)
>   formats = icl_get_plane_formats(dev_priv, pipe,
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81687/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9011 -> Patchwork_18501


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/index.html

Known issues


  Here are the changes found in Patchwork_18501 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload:
- fi-byt-j1900:   [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-byt-j1900/igt@i915_module_l...@reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-tgl-y:   [PASS][3] -> [DMESG-WARN][4] ([i915#1982] / 
[k.org#205379])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-tgl-y/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-tgl-y/igt@i915_module_l...@reload.html

  * igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050:   [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar 
issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-bsw-n3050/igt@i915_pm_...@module-reload.html

  * igt@kms_busy@basic@flip:
- fi-tgl-y:   [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar 
issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-tgl-y/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-tgl-y/igt@kms_busy@ba...@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka:   [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2:  [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@prime_vgem@basic-fence-flip:
- fi-tgl-y:   [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-tgl-y/igt@prime_v...@basic-fence-flip.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-tgl-y/igt@prime_v...@basic-fence-flip.html

  * igt@vgem_basic@unload:
- fi-kbl-x1275:   [PASS][15] -> [DMESG-WARN][16] ([i915#62] / [i915#92] 
/ [i915#95])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-kbl-x1275/igt@vgem_ba...@unload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-kbl-x1275/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@gem_exec_store@basic:
- fi-bsw-nick:[INCOMPLETE][17] -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-bsw-nick/igt@gem_exec_st...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-bsw-nick/igt@gem_exec_st...@basic.html

  * igt@gem_mmap_gtt@basic:
- fi-tgl-y:   [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-tgl-y/igt@gem_mmap_...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-tgl-y/igt@gem_mmap_...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900:   [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rpm@module-reload:
- fi-bxt-dsi: [DMESG-WARN][23] ([i915#1635] / [i915#1982]) -> 
[PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9011/fi-bxt-dsi/igt@i915_pm_...@module-reload.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18501/fi-bxt-dsi/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2:  [INCOMPLETE][25] ([i915#2045]) -> [PASS][26]
   [25]: 

Re: [Intel-gfx] [PATCH v8 6/8] drm/i915: WA for platforms with double buffered adress update enable bit

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:31AM +0530, Karthik B S wrote:
> In Gen 9 and Gen 10 platforms, async address update enable bit is
> double buffered. Due to this, during the transition from async flip
> to sync flip we have to wait until this bit is updated before continuing
> with the normal commit for sync flip.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a0c17d94daf3..b7e24dff0772 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15360,6 +15360,42 @@ static void intel_enable_crtc(struct 
> intel_atomic_state *state,
>   intel_crtc_enable_pipe_crc(crtc);
>  }
>  
> +static void skl_toggle_async_sync(struct intel_atomic_state *state,

skl_disable_async_flip_wa() maybe?

> +   struct intel_crtc *crtc,
> +   struct intel_crtc_state *new_crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_plane *plane;
> + struct intel_plane_state *new_plane_state;
> + u32 update_mask = new_crtc_state->update_planes;
> + u32 plane_ctl, surf_addr;
> + enum plane_id plane_id;
> + unsigned long irqflags;
> + enum pipe pipe;

Most of these things are only needed within the loop, so that's where
the declarations should be.

> + int i;
> +
> + for_each_new_intel_plane_in_state(state, plane, new_plane_state, i) {
> + if (crtc->pipe != plane->pipe ||
> + !(update_mask & BIT(plane->id)))
> + continue;
> +
> + plane_id = plane->id;
> + pipe = plane->pipe;
> +

I'd take the lock here so the rmw is fully protected.

> + plane_ctl = intel_de_read_fw(dev_priv, PLANE_CTL(pipe, 
> plane_id));
> + surf_addr = intel_de_read_fw(dev_priv, PLANE_SURF(pipe, 
> plane_id));
> +
> + plane_ctl &= ~PLANE_CTL_ASYNC_FLIP;
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 
> plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), 
> surf_addr);
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> + }
> +
> + intel_wait_for_vblank(dev_priv, crtc->pipe);
> +}
> +
>  static void intel_update_crtc(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
>  {
> @@ -15387,6 +15423,14 @@ static void intel_update_crtc(struct 
> intel_atomic_state *state,
>   else
>   intel_fbc_enable(state, crtc);
>  
> + /* WA for older platforms where async address update enable bit

s/older//

> +  * is double buffered.

"is double buffered and only latched at start of vblank" or
something. Otherwise one is left wondering what the fuss is about.

> +  */

Multiline comment format should be
/*
 * blah
 * blah
 */

> + if (old_crtc_state->uapi.async_flip &&
> + !new_crtc_state->uapi.async_flip &&
> + INTEL_GEN(dev_priv) <= 10 && INTEL_GEN(dev_priv) >= 9)

IS_GEN_RANGE(9, 10) or whatever it's called.

I guess we might want to put this call into intel_pre_plane_update()
since that's where all kinds of similar wait_for_vblank w/as live.

> + skl_toggle_async_sync(state, crtc, new_crtc_state);
> +
>   /* Perform vblank evasion around commit operation */
>   intel_pipe_update_start(new_crtc_state);
>  
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v8 5/8] drm/i915: Add dedicated plane hook for async flip case

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:30AM +0530, Karthik B S wrote:
> This hook is added to avoid writing other plane registers in case of
> async flips, so that we do not write the double buffered registers
> during async surface address update.
> 
> v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
> -Add a vfunc for skl_program_async_surface_address
>  and call it from intel_update_plane. (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  .../gpu/drm/i915/display/intel_atomic_plane.c |  7 ++
>  .../drm/i915/display/intel_display_types.h|  3 +++
>  drivers/gpu/drm/i915/display/intel_sprite.c   | 24 +++
>  3 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 79032701873a..fdc633020255 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -408,6 +408,13 @@ void intel_update_plane(struct intel_plane *plane,
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
>   trace_intel_update_plane(>base, crtc);
> +
> + if (crtc_state->uapi.async_flip) {
> + plane->program_async_surface_address(plane,
> +  crtc_state, plane_state);
> + return;
> + }

if
.async_flip()
else
.update_plane()

should do

> +
>   plane->update_plane(plane, crtc_state, plane_state);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b2d0edacc58c..d2ae781e4d81 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1190,6 +1190,9 @@ struct intel_plane {
>  struct intel_plane_state *plane_state);
>   int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
>const struct intel_plane_state *plane_state);
> + void (*program_async_surface_address)(struct intel_plane *plane,

That's a mouthful. I'd simplify it to eg. just .async_flip().

> +   const struct intel_crtc_state 
> *crtc_state,
> +   const struct intel_plane_state 
> *plane_state);
>  };
>  
>  struct intel_watermark_params {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index f0c89418d2e1..69407dfcebf6 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
>  }
>  
> +static void
> +skl_program_async_surface_address(struct intel_plane *plane,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct intel_plane_state *plane_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + unsigned long irqflags;
> + enum plane_id plane_id = plane->id;
> + enum pipe pipe = plane->pipe;
> + u32 surf_addr = plane_state->color_plane[0].offset;
> + u32 plane_ctl = plane_state->ctl;
> +
> + plane_ctl |= skl_plane_ctl_crtc(crtc_state);
> +
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> +   intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> +}
> +
>  static void
>  skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -3096,6 +3119,7 @@ skl_universal_plane_create(struct drm_i915_private 
> *dev_priv,
>   plane->get_hw_state = skl_plane_get_hw_state;
>   plane->check_plane = skl_plane_check;
>   plane->min_cdclk = skl_plane_min_cdclk;
> + plane->program_async_surface_address = 
> skl_program_async_surface_address;
>  
>   if (INTEL_GEN(dev_priv) >= 11)
>   formats = icl_get_plane_formats(dev_priv, pipe,
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v8 4/8] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:29AM +0530, Karthik B S wrote:
> Since the flip done event will be sent in the flip_done_handler,
> no need to add the event to the list and delay it for later.
> 
> v2: -Moved the async check above vblank_get as it
>  was causing issues for PSR.
> 
> v3: -No need to wait for vblank to pass, as this wait was causing a
>  16ms delay once every few flips.
> 
> v4: -Rebased.
> 
> v5: -Rebased.
> 
> v6: -Rebased.
> 
> v7: -No need of irq disable if we are not doing vblank evade. (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 5ac0dbf0e03d..f0c89418d2e1 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state 
> *new_crtc_state)
>   DEFINE_WAIT(wait);
>   u32 psr_status;
>  
> + if (new_crtc_state->uapi.async_flip)
> + return;
> +
>   vblank_start = adjusted_mode->crtc_vblank_start;
>   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   vblank_start = DIV_ROUND_UP(vblank_start, 2);
> @@ -202,6 +205,9 @@ void intel_pipe_update_end(struct intel_crtc_state 
> *new_crtc_state)
>  
>   trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
>  
> + if (new_crtc_state->uapi.async_flip)
> + return;

The pipe update tracepoints will be inconsistent if you put this here.
I guess we don't really need the pipe update tracepoints for async
flips. We might want to add a separate tracepoint for async flip itself,
or perhaps convey the sync vs. async information via the current
plane update tracepoint.

With this moved to before the tracepoint
Reviewed-by: Ville Syrjälä 

> +
>   /* We're still in the vblank-evade critical section, this can't race.
>* Would be slightly nice to just grab the vblank count and arm the
>* event outside of the critical section - the spinlock might spin for a
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v8 3/8] drm/i915: Add checks specific to async flips

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:28AM +0530, Karthik B S wrote:
> If flip is requested on any other plane, reject it.
> 
> Make sure there is no change in fbc, offset and framebuffer modifiers
> when async flip is requested.
> 
> If any of these are modified, reject async flip.
> 
> v2: -Replace DRM_ERROR (Paulo)
> -Add check for changes in OFFSET, FBC, RC(Paulo)
> 
> v3: -Removed TODO as benchmarking tests have been run now.
> 
> v4: -Added more state checks for async flip (Ville)
> -Moved intel_atomic_check_async to the end of intel_atomic_check
>  as the plane checks needs to pass before this. (Ville)
> -Removed crtc_state->enable_fbc check. (Ville)
> -Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
>  flip case as scanline counter is not reliable here.
> 
> v5: -Fix typo and other check patch errors seen in CI
>  in 'intel_atomic_check_async' function.
> 
> v6: -Don't call intel_atomic_check_async multiple times. (Ville)
> -Remove the check for n_planes in intel_atomic_check_async
> -Added documentation for async flips. (Paulo)
> 
> v7: -Replace 'intel_plane' with 'plane'. (Ville)
> -Replace all uapi.foo as hw.foo. (Ville)
> -Do not use intel_wm_need_update function. (Ville)
> -Add destination coordinate check. (Ville)
> -Do not allow async flip with linear buffer
>  on older hw as it has issues with this. (Ville)
> -Remove break after intel_atomic_check_async. (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 143 +++
>  1 file changed, 143 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2902fefd217f..a0c17d94daf3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14876,6 +14876,142 @@ static bool 
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
>   return false;
>  }
>  
> +/**
> + * DOC: asynchronous flip implementation
> + *
> + * Asynchronous page flip is the implementation for the 
> DRM_MODE_PAGE_FLIP_ASYNC
> + * flag. Currently async flip is only supported via the drmModePageFlip 
> IOCTL.
> + * Correspondingly, support is currently added for primary plane only.
> + *
> + * Async flip can only change the plane surface address, so anything else
> + * changing is rejected from the intel_atomic_check_async() function.
> + * Once this check is cleared, flip done interrupt is enabled using
> + * the skl_enable_flip_done() function.
> + *
> + * As soon as the surface address register is written, flip done interrupt is
> + * generated and the requested events are sent to the usersapce in the 
> interrupt
> + * handler itself. The timestamp and sequence sent during the flip done event
> + * correspond to the last vblank and have no relation to the actual time when
> + * the flip done event was sent.
> + */
> +
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_plane_state *new_plane_state, *old_plane_state;
> + struct intel_crtc *crtc;
> + struct intel_plane *plane;
> + int i;
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (needs_modeset(new_crtc_state)) {
> + DRM_DEBUG_KMS("Modeset Required. Async flip not 
> supported\n");

Per-device debugs pls. drm_dbg_kms() etc.

> + return -EINVAL;
> + }
> +
> + if (!new_crtc_state->hw.active) {
> + DRM_DEBUG_KMS("CRTC inactive\n");
> + return -EINVAL;
> + }
> + if (old_crtc_state->active_planes != 
> new_crtc_state->active_planes) {
> + DRM_DEBUG_KMS("Active planes cannot be changed during 
> async flip\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
> +  new_plane_state, i) {
> + /*TODO: Async flip is only supported through the page flip IOCTL

Comment formatting is wrong.

> +  * as of now. So support currently added for primary plane only.
> +  * Support for other planes should be added when async flip is
> +  * enabled in the atomic IOCTL path.

Obviously only for hw that actually supports it. Which I think
means vlv/chv and icl+.

> +  */
> + if (plane->id != PLANE_PRIMARY)
> + return -EINVAL;
> +
> + /*FIXME: This check is kept generic for all gen <= 10 platforms.

More bad formatting.

> +   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81687/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 
279040
+./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31
+./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - 
different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' 
- different lock contexts for basic block


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Widen CSB pointer to u64 for 
the parsers
URL   : https://patchwork.freedesktop.org/series/81687/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4ad31c2c30ca drm/i915/gt: Widen CSB pointer to u64 for the parsers
b75249b85d56 drm/i915/gt: Wait for CSB entries on Tigerlake
-:24: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl: 
Forcibly evict stale csb entries")'
#24: 
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")

-:51: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#51: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2509:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))

total: 2 errors, 0 warnings, 0 checks, 33 lines checked
aa0bee81790f drm/i915/gt: Apply the CSB w/a for all
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit d8f505311717 ("drm/i915/icl: 
Forcibly evict stale csb entries")'
#12: 
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")

-:82: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#82: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2536:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))

total: 2 errors, 0 warnings, 0 checks, 123 lines checked
d7c623ca7daa drm/i915/gt: Use a mmio read of the CSB in case of failure
-:32: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#32: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2537:
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50)) {

total: 1 errors, 0 warnings, 0 checks, 60 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 4/4] drm/i915/gt: Use a mmio read of the CSB in case of failure

2020-09-15 Thread Chris Wilson
If we find the GPU didn't update the CSB within 50us, we currently fail
and eventually reset the GPU. Lets report the value from the mmio space
as a last resort, it may just stave off an unnecessary GPU reset.

References: HSDES#22011327657
Suggested-by: Mika Kuoppala 
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 35 -
 drivers/gpu/drm/i915/gt/intel_lrc_reg.h |  3 +++
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fcb6ec3d55f4..0d57b54e5a69 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2528,19 +2528,42 @@ static inline bool gen8_csb_parse(const u64 csb)
return csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
 }
 
-static noinline u64 wa_csb_read(u64 * const csb)
+static noinline u64
+wa_csb_read(const struct intel_engine_cs *engine, u64 * const csb)
 {
u64 entry;
 
+   /*
+* Reading from the HWSP has one particular advantage: we can detect
+* a stale entry. Since the write into HWSP is broken, we have no reason
+* to trust the HW at all, the mmio entry may equally be unordered, so
+* we prefer the path that is self-checking and as a last resort,
+* return the mmio value.
+*
+* tgl,dg1:HSDES#22011327657
+*/
preempt_disable();
-   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
-   GEM_WARN_ON("50us CSB timeout");
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 10)) {
+   int idx = csb - engine->execlists.csb_status;
+   int status;
+
+   status = GEN8_EXECLISTS_STATUS_BUF;
+   if (idx >= 6) {
+   status = GEN11_EXECLISTS_STATUS_BUF2;
+   idx -= 6;
+   }
+   status += sizeof(u64) * idx;
+
+   entry = intel_uncore_read64(engine->uncore,
+   _MMIO(engine->mmio_base + status));
+   }
preempt_enable();
 
return entry;
 }
 
-static inline u64 csb_read(u64 * const csb)
+static inline u64
+csb_read(const struct intel_engine_cs *engine, u64 * const csb)
 {
u64 entry = READ_ONCE(*csb);
 
@@ -2556,7 +2579,7 @@ static inline u64 csb_read(u64 * const csb)
 * tgl:HSDES#22011248461
 */
if (unlikely(entry == -1))
-   entry = wa_csb_read(csb);
+   entry = wa_csb_read(engine, csb);
 
/* Consume this entry so that we can spot its future reuse. */
WRITE_ONCE(*csb, -1);
@@ -2649,7 +2672,7 @@ static void process_csb(struct intel_engine_cs *engine)
 * status notifier.
 */
 
-   csb = csb_read(buf + head);
+   csb = csb_read(engine, buf + head);
ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
 head, upper_32_bits(csb), lower_32_bits(csb));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
index 93cb6c460508..1b51f7b9a5c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
@@ -49,4 +49,7 @@
 #define GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x1A
 #define GEN12_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0xD
 
+#define GEN8_EXECLISTS_STATUS_BUF 0x370
+#define GEN11_EXECLISTS_STATUS_BUF2 0x3c0
+
 #endif /* _INTEL_LRC_REG_H_ */
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 3/4] drm/i915/gt: Apply the CSB w/a for all

2020-09-15 Thread Chris Wilson
Since we expect to inline the csb_parse() routines, the w/a for the
stale CSB data on Tigerlake will be pulled into process_csb(), and so we
might as well simply reuse the logic for all, and so will hopefully
avoid any strange behaviour on Icelake that was not covered by our
previous w/a.

References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Bruce Chang 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 79 +++--
 1 file changed, 51 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d75712a503b7..fcb6ec3d55f4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2496,25 +2496,11 @@ invalidate_csb_entries(const u64 *first, const u64 
*last)
  * bits 47-57: sw context id of the lrc the GT switched away from
  * bits 58-63: sw counter of the lrc the GT switched away from
  */
-static inline bool gen12_csb_parse(const u64 *csb)
+static inline bool gen12_csb_parse(const u64 csb)
 {
-   bool ctx_away_valid;
-   bool new_queue;
-   u64 entry;
-
-   /* HSD#22011248461 */
-   entry = READ_ONCE(*csb);
-   if (unlikely(entry == -1)) {
-   preempt_disable();
-   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
-   GEM_WARN_ON("50us CSB timeout");
-   preempt_enable();
-   }
-   WRITE_ONCE(*(u64 *)csb, -1);
-
-   ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
-   new_queue =
-   lower_32_bits(entry) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
+   bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(csb));
+   bool new_queue =
+   lower_32_bits(csb) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
 
/*
 * The context switch detail is not guaranteed to be 5 when a preemption
@@ -2524,7 +2510,7 @@ static inline bool gen12_csb_parse(const u64 *csb)
 * would require some extra handling, but we don't support that.
 */
if (!ctx_away_valid || new_queue) {
-   GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(entry)));
+   GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(csb)));
return true;
}
 
@@ -2533,19 +2519,56 @@ static inline bool gen12_csb_parse(const u64 *csb)
 * context switch on an unsuccessful wait instruction since we always
 * use polling mode.
 */
-   GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(entry)));
+   GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(csb)));
return false;
 }
 
-static inline bool gen8_csb_parse(const u64 *csb)
+static inline bool gen8_csb_parse(const u64 csb)
+{
+   return csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
+}
+
+static noinline u64 wa_csb_read(u64 * const csb)
 {
-   return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
+   u64 entry;
+
+   preempt_disable();
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
+   GEM_WARN_ON("50us CSB timeout");
+   preempt_enable();
+
+   return entry;
+}
+
+static inline u64 csb_read(u64 * const csb)
+{
+   u64 entry = READ_ONCE(*csb);
+
+   /*
+* Unfortunately, the GPU does not always serialise its write
+* of the CSB entries before its write of the CSB pointer, at least
+* from the perspective of the CPU, using what is known as a Global
+* Observation Point. We may read a new CSB tail pointer, but then
+* read the stale CSB entries, causing us to misinterpret the
+* context-switch events, and eventually declare the GPU hung.
+*
+* icl:HSDES#1806554093
+* tgl:HSDES#22011248461
+*/
+   if (unlikely(entry == -1))
+   entry = wa_csb_read(csb);
+
+   /* Consume this entry so that we can spot its future reuse. */
+   WRITE_ONCE(*csb, -1);
+
+   /* ELSP is an implicit wmb() before the GPU wraps and overwrites csb */
+   return entry;
 }
 
 static void process_csb(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
-   const u64 * const buf = execlists->csb_status;
+   u64 * const buf = execlists->csb_status;
const u8 num_entries = execlists->csb_size;
u8 head, tail;
 
@@ -2603,6 +2626,7 @@ static void process_csb(struct intel_engine_cs *engine)
rmb();
do {
bool promote;
+   u64 csb;
 
if (++head == num_entries)
head = 0;
@@ -2625,15 +2649,14 @@ static void process_csb(struct intel_engine_cs *engine)
 * status notifier.
 */
 
+   csb = csb_read(buf + head);
ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
- 

[Intel-gfx] [CI 2/4] drm/i915/gt: Wait for CSB entries on Tigerlake

2020-09-15 Thread Chris Wilson
On Tigerlake, we are seeing a repeat of commit d8f505311717 ("drm/i915/icl:
Forcibly evict stale csb entries") where, presumably, due to a missing
Global Observation Point synchronisation, the write pointer of the CSB
ringbuffer is updated _prior_ to the contents of the ringbuffer. That is
we see the GPU report more context-switch entries for us to parse, but
those entries have not been written, leading us to process stale events,
and eventually report a hung GPU.

However, this effect appears to be much more severe than we previously
saw on Icelake (though it might be best if we try the same approach
there as well and measure), and Bruce suggested the good idea of resetting
the CSB entry after use so that we can detect when it has been updated by
the GPU. By instrumenting how long that may be, we can set a reliable
upper bound for how long we should wait for:

513 late, avg of 61 retries (590 ns), max of 1061 retries (10099 ns)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2045
References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
References: HSDES#22011327657, HSDES#1508287568
Suggested-by: Bruce Chang 
Signed-off-by: Chris Wilson 
Cc: Bruce Chang 
Cc: Mika Kuoppala 
Cc: sta...@vger.kernel.org # v5.4
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d6e0f62337b4..d75712a503b7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2498,9 +2498,22 @@ invalidate_csb_entries(const u64 *first, const u64 *last)
  */
 static inline bool gen12_csb_parse(const u64 *csb)
 {
-   u64 entry = READ_ONCE(*csb);
-   bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
-   bool new_queue =
+   bool ctx_away_valid;
+   bool new_queue;
+   u64 entry;
+
+   /* HSD#22011248461 */
+   entry = READ_ONCE(*csb);
+   if (unlikely(entry == -1)) {
+   preempt_disable();
+   if (wait_for_atomic_us((entry = READ_ONCE(*csb)) != -1, 50))
+   GEM_WARN_ON("50us CSB timeout");
+   preempt_enable();
+   }
+   WRITE_ONCE(*(u64 *)csb, -1);
+
+   ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
+   new_queue =
lower_32_bits(entry) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
 
/*
@@ -4004,6 +4017,8 @@ static void reset_csb_pointers(struct intel_engine_cs 
*engine)
WRITE_ONCE(*execlists->csb_write, reset_value);
wmb(); /* Make sure this is visible to HW (paranoia?) */
 
+   /* Check that the GPU does indeed update the CSB entries! */
+   memset(execlists->csb_status, -1, (reset_value + 1) * sizeof(u64));
invalidate_csb_entries(>csb_status[0],
   >csb_status[reset_value]);
 
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [CI 1/4] drm/i915/gt: Widen CSB pointer to u64 for the parsers

2020-09-15 Thread Chris Wilson
A CSB entry is 64b, and it is simpler for us to treat it as an array of
64b entries than as an array of pairs of 32b entries.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h |  2 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c  | 33 ++--
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c400aaa2287b..ee6312601c56 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -278,7 +278,7 @@ struct intel_engine_execlists {
 *
 * Note these register may be either mmio or HWSP shadow.
 */
-   u32 *csb_status;
+   u64 *csb_status;
 
/**
 * @csb_size: context status buffer FIFO size
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0412a44f25f2..d6e0f62337b4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2464,7 +2464,7 @@ cancel_port_requests(struct intel_engine_execlists * 
const execlists)
 }
 
 static inline void
-invalidate_csb_entries(const u32 *first, const u32 *last)
+invalidate_csb_entries(const u64 *first, const u64 *last)
 {
clflush((void *)first);
clflush((void *)last);
@@ -2496,14 +2496,12 @@ invalidate_csb_entries(const u32 *first, const u32 
*last)
  * bits 47-57: sw context id of the lrc the GT switched away from
  * bits 58-63: sw counter of the lrc the GT switched away from
  */
-static inline bool
-gen12_csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
+static inline bool gen12_csb_parse(const u64 *csb)
 {
-   u32 lower_dw = csb[0];
-   u32 upper_dw = csb[1];
-   bool ctx_to_valid = GEN12_CSB_CTX_VALID(lower_dw);
-   bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_dw);
-   bool new_queue = lower_dw & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
+   u64 entry = READ_ONCE(*csb);
+   bool ctx_away_valid = GEN12_CSB_CTX_VALID(upper_32_bits(entry));
+   bool new_queue =
+   lower_32_bits(entry) & GEN12_CTX_STATUS_SWITCHED_TO_NEW_QUEUE;
 
/*
 * The context switch detail is not guaranteed to be 5 when a preemption
@@ -2513,7 +2511,7 @@ gen12_csb_parse(const struct intel_engine_execlists 
*execlists, const u32 *csb)
 * would require some extra handling, but we don't support that.
 */
if (!ctx_away_valid || new_queue) {
-   GEM_BUG_ON(!ctx_to_valid);
+   GEM_BUG_ON(!GEN12_CSB_CTX_VALID(lower_32_bits(entry)));
return true;
}
 
@@ -2522,12 +2520,11 @@ gen12_csb_parse(const struct intel_engine_execlists 
*execlists, const u32 *csb)
 * context switch on an unsuccessful wait instruction since we always
 * use polling mode.
 */
-   GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_dw));
+   GEM_BUG_ON(GEN12_CTX_SWITCH_DETAIL(upper_32_bits(entry)));
return false;
 }
 
-static inline bool
-gen8_csb_parse(const struct intel_engine_execlists *execlists, const u32 *csb)
+static inline bool gen8_csb_parse(const u64 *csb)
 {
return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
 }
@@ -2535,7 +2532,7 @@ gen8_csb_parse(const struct intel_engine_execlists 
*execlists, const u32 *csb)
 static void process_csb(struct intel_engine_cs *engine)
 {
struct intel_engine_execlists * const execlists = >execlists;
-   const u32 * const buf = execlists->csb_status;
+   const u64 * const buf = execlists->csb_status;
const u8 num_entries = execlists->csb_size;
u8 head, tail;
 
@@ -2616,12 +2613,14 @@ static void process_csb(struct intel_engine_cs *engine)
 */
 
ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
-head, buf[2 * head + 0], buf[2 * head + 1]);
+head,
+upper_32_bits(buf[head]),
+lower_32_bits(buf[head]));
 
if (INTEL_GEN(engine->i915) >= 12)
-   promote = gen12_csb_parse(execlists, buf + 2 * head);
+   promote = gen12_csb_parse(buf + head);
else
-   promote = gen8_csb_parse(execlists, buf + 2 * head);
+   promote = gen8_csb_parse(buf + head);
if (promote) {
struct i915_request * const *old = execlists->active;
 
@@ -5157,7 +5156,7 @@ int intel_execlists_submission_setup(struct 
intel_engine_cs *engine)
}
 
execlists->csb_status =
-   >status_page.addr[I915_HWS_CSB_BUF0_INDEX];
+   (u64 *)>status_page.addr[I915_HWS_CSB_BUF0_INDEX];
 
execlists->csb_write =
>status_page.addr[intel_hws_csb_write_index(i915)];

Re: [Intel-gfx] [PATCH v8 1/8] drm/i915: Add enable/disable flip done and flip done handler

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:26AM +0530, Karthik B S wrote:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
> 
> Enable the flip done interrupt in IER.
> 
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
> 
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
> 
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
>  flips without pageflip events.
> 
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
>  flip_done_handler to remove sporadic WARN_ON that is seen.
> 
> v4: -Calculate timestamps using flip done time stamp and current
>  timestamp for async flips (Ville)
> 
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
>  static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
> 
> v6: -Revert back to old time stamping code.
> -Remove the break while calling skl_enable_flip_done. (Paulo)
> 
> v7: -Rebased.
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  8 +++
>  drivers/gpu/drm/i915/i915_irq.c  | 52 
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  3 files changed, 62 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ec148a8da2c2..48712fb0a251 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15606,6 +15606,11 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>  
>   intel_dbuf_pre_plane_update(state);
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_enable_flip_done(>base);
> + }
> +
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>   dev_priv->display.commit_modeset_enables(state);
>  
> @@ -15627,6 +15632,9 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   drm_atomic_helper_wait_for_flip_done(dev, >base);
>  
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(>base);
> +
>   if (new_crtc_state->hw.active &&
>   !needs_modeset(new_crtc_state) &&
>   !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f113fe44572b..6cc129b031d3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1296,6 +1296,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private 
> *dev_priv,
>u32 crc4) {}
>  #endif
>  
> +static void flip_done_handler(struct drm_i915_private *dev_priv,

Pls use
struct drm_i915_private *i915
in new code.

> +   unsigned int pipe)

enum pipe pipe

> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = _priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>event_lock, irqflags);
> +
> + crtc_state->event = NULL;
> +
> + drm_crtc_send_vblank_event(>base, e);
> +
> + spin_unlock_irqrestore(>event_lock, irqflags);
> +}
>  
>  static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2390,6 +2407,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   if (iir & GEN8_PIPE_VBLANK)
>   intel_handle_vblank(dev_priv, pipe);
>  
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
>   if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
>   hsw_pipe_crc_irq_handler(dev_priv, pipe);
>  
> @@ -2711,6 +2731,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> +void skl_enable_flip_done(struct drm_crtc *crtc)

Pls use
struct intel_crtc *crtc
instead

> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> +   

Re: [Intel-gfx] [PATCH v8 2/8] drm/i915: Add support for async flips in I915

2020-09-15 Thread Ville Syrjälä
On Mon, Sep 14, 2020 at 11:26:27AM +0530, Karthik B S wrote:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
> 
> v2: -Move the Async flip enablement to individual patch (Paulo)
> 
> v3: -Rebased.
> 
> v4: -Add separate plane hook for async flip case (Ville)
> 
> v5: -Rebased.
> 
> v6: -Move the plane hook to separate patch. (Paulo)
> -Remove the early return in skl_plane_ctl. (Paulo)
> 
> v7: -Move async address update enable to skl_plane_ctl_crtc() (Ville)
> 
> v8: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 3 +++
>  drivers/gpu/drm/i915/i915_reg.h  | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 48712fb0a251..2902fefd217f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4785,6 +4785,9 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state 
> *crtc_state)
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>   u32 plane_ctl = 0;
>  
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
> +
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>   return plane_ctl;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 90a05e37ba2f..1c4ddd4deba0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6923,6 +6923,7 @@ enum {
>  #define   PLANE_CTL_TILED_X  (1 << 10)
>  #define   PLANE_CTL_TILED_Y  (4 << 10)
>  #define   PLANE_CTL_TILED_YF (5 << 10)
> +#define   PLANE_CTL_ASYNC_FLIP   (1 << 9)
>  #define   PLANE_CTL_FLIP_HORIZONTAL  (1 << 8)
>  #define   PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE   (1 << 4) /* TGL+ */
>  #define   PLANE_CTL_ALPHA_MASK   (0x3 << 4) /* Pre-GLK */
> -- 
> 2.22.0

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   >