date:20210518



On 5/18/21 3:23 PM, Christoph Hellwig wrote:

On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:

Apart from the caching aliasing Mattew brought up, doesn't the
remap_pfn_range_xxx() family require the mmap_sem held in write mode since
it modifies the vma structure? remap_io_sg() is called from the fault
handler with the mmap_sem held in read mode only.

Only for vma->vm_flags, and remap_sg already asserts all the interesting
flags are set, although it does not assert VM_IO.

We could move the assignment out of remap_pfn_range_notrack and
into remap_pfn_range and just assert that the proper flags are set,
though.


That to me sounds like a way forward. It sound like in general a gpu 
prefaulting helper that in the long run also supports faulting huge ptes 
is desired also by TTM. Although it looks like that BUG_ON() I pointed 
out was hit anyway


/Thomas


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

Re: [Intel-gfx] [CI 5/5] drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h


On Tue, May 18, 2021 at 02:34:44PM -0700, Anusha Srivatsa wrote:

Finally, rename the header and source file from csr to dmc.

v2: Add file rename in Documentation.
- Place headers in orders. (Jani)

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
Documentation/gpu/i915.rst   | 12 ++--
drivers/gpu/drm/i915/Makefile|  2 +-
drivers/gpu/drm/i915/display/intel_display.c |  2 +-
drivers/gpu/drm/i915/display/intel_display_debugfs.c |  2 +-
drivers/gpu/drm/i915/display/intel_display_power.c   |  2 +-
.../drm/i915/display/{intel_csr.c => intel_dmc.c}|  4 ++--
.../drm/i915/display/{intel_csr.h => intel_dmc.h}|  6 +++---
drivers/gpu/drm/i915/i915_drv.c  |  2 +-
drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
9 files changed, 17 insertions(+), 17 deletions(-)
rename drivers/gpu/drm/i915/display/{intel_csr.c => intel_dmc.c} (99%)
rename drivers/gpu/drm/i915/display/{intel_csr.h => intel_dmc.h} (88%)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..42ce0196930a 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -210,13 +210,13 @@ DPIO
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
   :doc: DPIO

-CSR firmware support for DMC
-
+DMC Firmware Support
+

-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
-   :doc: csr support for dmc
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
+   :doc: DMC Firmware Support

-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
   :internal:

Video BIOS Table (VBT)
@@ -537,7 +537,7 @@ The HuC FW layout is the same as the GuC one, see `GuC 
Firmware Layout`_

DMC
---
-See `CSR firmware support for DMC`_
+See `DMC Firmware Support`_

Tracing
===
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137b..2da5bae8fa03 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -201,10 +201,10 @@ i915-y += \
display/intel_combo_phy.o \
display/intel_connector.o \
display/intel_crtc.o \
-   display/intel_csr.o \
display/intel_cursor.o \
display/intel_display.o \
display/intel_display_power.o \
+   display/intel_dmc.o \
display/intel_dpio_phy.o \
display/intel_dpll.o \
display/intel_dpll_mgr.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 39c9c49b378b..d98a314bb974 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -79,9 +79,9 @@
#include "intel_cdclk.h"
#include "intel_color.h"
#include "intel_crtc.h"
-#include "intel_csr.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_dmc.h"
#include "intel_dp_link_training.h"
#include "intel_fbc.h"
#include "intel_fdi.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index e43abdf0e3d9..94e5cbd86e77 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -7,11 +7,11 @@
#include 

#include "i915_debugfs.h"
-#include "intel_csr.h"
#include "intel_display_debugfs.h"
#include "intel_display_power.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_dmc.h"
#include "intel_dp.h"
#include "intel_fbc.h"
#include "intel_hdcp.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index cbba41d3e6cf..e8fcc3d02d01 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -9,10 +9,10 @@
#include "i915_irq.h"
#include "intel_cdclk.h"
#include "intel_combo_phy.h"
-#include "intel_csr.h"
#include "intel_display_power.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_dmc.h"
#include "intel_dpio_phy.h"
#include "intel_hotplug.h"
#include "intel_pm.h"
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
similarity index 99%
rename from drivers/gpu/drm/i915/display/intel_csr.c
rename to drivers/gpu/drm/i915/display/intel_dmc.c
index ae1dfafaff9a..560574dd929a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -26,11 +26,11 @@

#include "i915_drv.h"
#include "i915_reg.h"
-#include "intel_csr.h"
#include "intel_de.h"
+#include "intel_dmc.h"

/**
- * DOC: DMC firmware support
+ * DOC: DMC Firmware Support
 *
 * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
 * engine to save and restore the state of display engine when it enter into
diff --git a/drivers/gpu/drm/i915/display/intel_csr.h

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

2021-05-18 Thread Intel




On 5/18/21 5:00 PM, Matthew Auld wrote:

On Tue, 18 May 2021 at 14:21, Christoph Hellwig  wrote:

On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:

Looks like it is caused by the validation failure then.  Which means the
existing code is doing something wrong in its choice of the page
protection bit.  I really need help from the i915 maintainers here..

AFAIK there are two users of remap_io_sg, the first is our shmem
objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
mmap modes for userspace. The other user is device local-memory
objects(VRAM), and for this one we have an actual io_mapping which is
allocated as WC, and IIRC this should only be mapped as WC for the
mmap mode, but normal userspace can't hit this path yet.

The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
Is that device local?

The vm_fault_cpu covers both device local and shmem objects.


What do we need to do here? It sounds like shmem backed objects are
allocated as WB for the pages underneath, but i915 allows mapping them
as UC/WC which trips up this track_pfn thing?

To me the warnings looks like system memory is mapped with the wrong
permissions, yes.  If you want to map it as UC/WC the right set_memory_*
needs to be used on the kernel mapping as well to ensure that the
attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?


No, that won't work because there are active maps with conflicting 
caching attributes. I think the history here is that that was assumed to 
be OK for integrated graphics that ran only on Intel processors that 
promise to never write back unmodified cache lines resulting from 
prefetching, like some AMD processors did way back at least.


These conflicting mappings can obviously not be supported for discrete 
graphics, but for integrated they are part of the uAPI.


/Thomas






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

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

Re: [Intel-gfx] [CI 4/5] drm/i915/dmc: Rename functions names having "csr"


On Tue, May 18, 2021 at 02:34:43PM -0700, Anusha Srivatsa wrote:

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_csr.c  | 64 +--
drivers/gpu/drm/i915/display/intel_csr.h  | 10 +--
drivers/gpu/drm/i915/display/intel_display.c  | 14 ++--
.../drm/i915/display/intel_display_power.c| 14 ++--
drivers/gpu/drm/i915/i915_drv.c   |  6 +-
5 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index f2124796ce77..ae1dfafaff9a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -302,14 +302,14 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
}

/**
- * intel_csr_load_program() - write the firmware from memory to register.
+ * intel_dmc_load_program() - write the firmware from memory to register.
 * @dev_priv: i915 drm device.
 *
- * CSR firmware is read from a .bin file and kept in internal memory one time.
+ * DMC firmware is read from a .bin file and kept in internal memory one time.
 * Everytime display comes back from low power state this function is called to
 * copy the firmware from internal memory to registers.
 */
-void intel_csr_load_program(struct drm_i915_private *dev_priv)
+void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
@@ -391,9 +391,9 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
}

-static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
-   const struct intel_dmc_header_base *dmc_header,
-   size_t rem_size)
+static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
+  const struct intel_dmc_header_base *dmc_header,
+  size_t rem_size)
{
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
@@ -498,7 +498,7 @@ static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
}

static u32
-parse_csr_fw_package(struct intel_dmc *dmc,
+parse_dmc_fw_package(struct intel_dmc *dmc,
 const struct intel_package_header *package_header,
 const struct stepping_info *si,
 size_t rem_size)
@@ -557,7 +557,7 @@ parse_csr_fw_package(struct intel_dmc *dmc,
}

/* Return number of bytes parsed or 0 on error */
-static u32 parse_csr_fw_css(struct intel_dmc *dmc,
+static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
struct intel_css_header *css_header,
size_t rem_size)
{
@@ -590,7 +590,7 @@ static u32 parse_csr_fw_css(struct intel_dmc *dmc,
return sizeof(struct intel_css_header);
}

-static void parse_csr_fw(struct drm_i915_private *dev_priv,
+static void parse_dmc_fw(struct drm_i915_private *dev_priv,
 const struct firmware *fw)
{
struct intel_css_header *css_header;
@@ -606,7 +606,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,

/* Extract CSS Header information */
css_header = (struct intel_css_header *)fw->data;
-   r = parse_csr_fw_css(dmc, css_header, fw->size);
+   r = parse_dmc_fw_css(dmc, css_header, fw->size);
if (!r)
return;

@@ -614,7 +614,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,

/* Extract Package Header information */
package_header = (struct intel_package_header *)>data[readcount];
-   r = parse_csr_fw_package(dmc, package_header, si, fw->size - readcount);
+   r = parse_dmc_fw_package(dmc, package_header, si, fw->size - readcount);
if (!r)
return;

@@ -622,17 +622,17 @@ static void parse_csr_fw(struct drm_i915_private 
*dev_priv,

/* Extract dmc_header information */
dmc_header = (struct intel_dmc_header_base *)>data[readcount];
-   parse_csr_fw_dmc(dmc, dmc_header, fw->size - readcount);
+   parse_dmc_fw_header(dmc, dmc_header, fw->size - readcount);
}

-static void intel_csr_runtime_pm_get(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_get(struct drm_i915_private *dev_priv)
{
drm_WARN_ON(_priv->drm, dev_priv->dmc.wakeref);
dev_priv->dmc.wakeref =
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
}

-static void intel_csr_runtime_pm_put(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_put(struct drm_i915_private *dev_priv)
{
intel_wakeref_t wakeref __maybe_unused =
fetch_and_zero(_priv->dmc.wakeref);
@@ -640,7 +640,7 @@ static void intel_csr_runtime_pm_put(struct 
drm_i915_private *dev_priv)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
}

-static void

Re: [Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr


On Tue, May 18, 2021 at 02:34:42PM -0700, Anusha Srivatsa wrote:

Rename all occurences of CSR_* with DMC_*

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_csr.c  | 167 +-
drivers/gpu/drm/i915/display/intel_csr.h  |   6 +-
.../drm/i915/display/intel_display_debugfs.c  |  16 +-
.../drm/i915/display/intel_display_power.c|  14 +-
drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
drivers/gpu/drm/i915/i915_reg.h   |  28 +--
6 files changed, 117 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 5ed286dc6720..f2124796ce77 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -30,10 +30,9 @@
#include "intel_de.h"

/**
- * DOC: csr support for dmc
+ * DOC: DMC firmware support
 *
- * Display Context Save and Restore (CSR) firmware support added from gen9
- * onwards to drive newly added DMC (Display microcontroller) in display
+ * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
 * engine to save and restore the state of display engine when it enter into
 * low-power state and comes back to normal.
 */
@@ -44,55 +43,55 @@
__stringify(major) "_" \
__stringify(minor) ".bin"

-#define GEN12_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
+#define GEN12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE

-#define ADLS_CSR_PATH  DMC_PATH(adls, 2, 01)
-#define ADLS_CSR_VERSION_REQUIRED  CSR_VERSION(2, 1)
-MODULE_FIRMWARE(ADLS_CSR_PATH);
+#define ADLS_DMC_PATH  DMC_PATH(adls, 2, 01)
+#define ADLS_DMC_VERSION_REQUIRED  DMC_VERSION(2, 1)
+MODULE_FIRMWARE(ADLS_DMC_PATH);

-#define DG1_CSR_PATH   DMC_PATH(dg1, 2, 02)
-#define DG1_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(DG1_CSR_PATH);
+#define DG1_DMC_PATH   DMC_PATH(dg1, 2, 02)
+#define DG1_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(DG1_DMC_PATH);

-#define RKL_CSR_PATH   DMC_PATH(rkl, 2, 02)
-#define RKL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(RKL_CSR_PATH);
+#define RKL_DMC_PATH   DMC_PATH(rkl, 2, 02)
+#define RKL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(RKL_DMC_PATH);

-#define TGL_CSR_PATH   DMC_PATH(tgl, 2, 08)
-#define TGL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 8)
-MODULE_FIRMWARE(TGL_CSR_PATH);
+#define TGL_DMC_PATH   DMC_PATH(tgl, 2, 08)
+#define TGL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 8)
+MODULE_FIRMWARE(TGL_DMC_PATH);

-#define ICL_CSR_PATH   DMC_PATH(icl, 1, 09)
-#define ICL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 9)
-#define ICL_CSR_MAX_FW_SIZE0x6000
-MODULE_FIRMWARE(ICL_CSR_PATH);
+#define ICL_DMC_PATH   DMC_PATH(icl, 1, 09)
+#define ICL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 9)
+#define ICL_DMC_MAX_FW_SIZE0x6000
+MODULE_FIRMWARE(ICL_DMC_PATH);

-#define CNL_CSR_PATH   DMC_PATH(cnl, 1, 07)
-#define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define CNL_CSR_MAX_FW_SIZEGLK_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(CNL_CSR_PATH);
+#define CNL_DMC_PATH   DMC_PATH(cnl, 1, 07)
+#define CNL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 7)
+#define CNL_DMC_MAX_FW_SIZEGLK_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(CNL_DMC_PATH);

-#define GLK_CSR_PATH   DMC_PATH(glk, 1, 04)
-#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define GLK_CSR_MAX_FW_SIZE0x4000
-MODULE_FIRMWARE(GLK_CSR_PATH);
+#define GLK_DMC_PATH   DMC_PATH(glk, 1, 04)
+#define GLK_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define GLK_DMC_MAX_FW_SIZE0x4000
+MODULE_FIRMWARE(GLK_DMC_PATH);

-#define KBL_CSR_PATH   DMC_PATH(kbl, 1, 04)
-#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define KBL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(KBL_CSR_PATH);
+#define KBL_DMC_PATH   DMC_PATH(kbl, 1, 04)
+#define KBL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define KBL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(KBL_DMC_PATH);

-#define SKL_CSR_PATH   DMC_PATH(skl, 1, 27)
-#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 27)
-#define SKL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(SKL_CSR_PATH);
+#define SKL_DMC_PATH   DMC_PATH(skl, 1, 27)
+#define SKL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 27)
+#define SKL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(SKL_DMC_PATH);

-#define BXT_CSR_PATH   DMC_PATH(bxt, 1, 07)
-#define BXT_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define BXT_CSR_MAX_FW_SIZE0x3000

Re: [Intel-gfx] [CI 2/5] drm/i915/dmc: s/HAS_CSR/HAS_DMC


On Tue, May 18, 2021 at 02:34:41PM -0700, Anusha Srivatsa wrote:

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_csr.c | 12 ++--
drivers/gpu/drm/i915/display/intel_display_debugfs.c |  2 +-
drivers/gpu/drm/i915/i915_drv.h  |  2 +-
drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
drivers/gpu/drm/i915/i915_pci.c  |  4 ++--
drivers/gpu/drm/i915/intel_device_info.c |  2 +-
drivers/gpu/drm/i915/intel_device_info.h |  2 +-
7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index a22339ebdffd..5ed286dc6720 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -315,9 +315,9 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;

-   if (!HAS_CSR(dev_priv)) {
+   if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
-   "No CSR support available for this platform\n");
+   "No DMC support available for this platform\n");
return;
}

@@ -686,7 +686,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)

INIT_WORK(_priv->dmc.work, csr_load_work_fn);

-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;

/*
@@ -776,7 +776,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
 */
void intel_csr_ucode_suspend(struct drm_i915_private *dev_priv)
{
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;

flush_work(_priv->dmc.work);
@@ -795,7 +795,7 @@ void intel_csr_ucode_suspend(struct drm_i915_private 
*dev_priv)
 */
void intel_csr_ucode_resume(struct drm_i915_private *dev_priv)
{
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;

/*
@@ -815,7 +815,7 @@ void intel_csr_ucode_resume(struct drm_i915_private 
*dev_priv)
 */
void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
{
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;

intel_csr_ucode_suspend(dev_priv);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index a875f3c9b358..6cd7f8c1724f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -535,7 +535,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
struct intel_dmc *dmc;
i915_reg_t dc5_reg, dc6_reg = {};

-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return -ENODEV;

dmc = _priv->dmc;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c9f6bbb5dd7..469783003309 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1662,7 +1662,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,

#define HAS_RPS(dev_priv)   (INTEL_INFO(dev_priv)->has_rps)

-#define HAS_CSR(dev_priv)  (INTEL_INFO(dev_priv)->display.has_csr)
+#define HAS_DMC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_dmc)

#define HAS_MSO(i915)   (INTEL_GEN(i915) >= 12)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 03d1221de13b..06828ff90ccf 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -788,7 +788,7 @@ static void __err_print_to_sgl(struct 
drm_i915_error_state_buf *m,

err_printf(m, "IOMMU enabled?: %d\n", error->iommu);

-   if (HAS_CSR(m->i915)) {
+   if (HAS_DMC(m->i915)) {
struct intel_dmc *dmc = >i915->dmc;

err_printf(m, "DMC loaded: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 574881c0e339..97c98f4fb265 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,7 @@ static const struct intel_device_info chv_info = {
GEN8_FEATURES, \
GEN(9), \
GEN9_DEFAULT_PAGE_SIZES, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_gt_uc = 1, \
.display.has_hdcp = 1, \
.display.has_ipc = 1, \
@@ -698,7 +698,7 @@ static const struct intel_device_info skl_gt4_info = {
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.has_runtime_pm = 1, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_rc6 = 1, \
.has_rps = true, \
.display.has_dp_mst = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index

Re: [Intel-gfx] [CI 1/5] drm/i915/dmc: s/intel_csr/intel_dmc


On Tue, May 18, 2021 at 02:34:40PM -0700, Anusha Srivatsa wrote:

No functional change.

v2: Chchpatch fixes.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

`git show -U0 --word-diff=color` really helps here. Not sure if I would
split the patch per struct/functions/macro like was done, but I'm ok
with it.

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_csr.c  | 170 +-
.../drm/i915/display/intel_display_debugfs.c  |  14 +-
.../drm/i915/display/intel_display_power.c|  52 +++---
drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
drivers/gpu/drm/i915/i915_drv.h   |   4 +-
drivers/gpu/drm/i915/i915_gpu_error.c |   8 +-
6 files changed, 125 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 26a922d34263..a22339ebdffd 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -312,7 +312,7 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
 */
void intel_csr_load_program(struct drm_i915_private *dev_priv)
{
-   u32 *payload = dev_priv->csr.dmc_payload;
+   u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;

if (!HAS_CSR(dev_priv)) {
@@ -321,13 +321,13 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
return;
}

-   if (!dev_priv->csr.dmc_payload) {
+   if (!dev_priv->dmc.dmc_payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}

-   fw_size = dev_priv->csr.dmc_fw_size;
+   fw_size = dev_priv->dmc.dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);

preempt_disable();
@@ -338,12 +338,12 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)

preempt_enable();

-   for (i = 0; i < dev_priv->csr.mmio_count; i++) {
-   intel_de_write(dev_priv, dev_priv->csr.mmioaddr[i],
-  dev_priv->csr.mmiodata[i]);
+   for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
+   intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
+  dev_priv->dmc.mmiodata[i]);
}

-   dev_priv->csr.dc_state = 0;
+   dev_priv->dmc.dc_state = 0;

gen9_set_dc_state_debugmask(dev_priv);
}
@@ -392,7 +392,7 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
}

-static u32 parse_csr_fw_dmc(struct intel_csr *csr,
+static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size)
{
@@ -401,8 +401,8 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
u32 mmio_count, mmio_count_max;
u8 *payload;

-   BUILD_BUG_ON(ARRAY_SIZE(csr->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(csr->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);

/*
 * Check if we can access common fields, we will checkc again below
@@ -464,10 +464,10 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
  mmioaddr[i]);
return 0;
}
-   csr->mmioaddr[i] = _MMIO(mmioaddr[i]);
-   csr->mmiodata[i] = mmiodata[i];
+   dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
+   dmc->mmiodata[i] = mmiodata[i];
}
-   csr->mmio_count = mmio_count;
+   dmc->mmio_count = mmio_count;

rem_size -= header_len_bytes;

@@ -476,20 +476,20 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
if (rem_size < payload_size)
goto error_truncated;

-   if (payload_size > csr->max_fw_size) {
+   if (payload_size > dmc->max_fw_size) {
DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
return 0;
}
-   csr->dmc_fw_size = dmc_header->fw_size;
+   dmc->dmc_fw_size = dmc_header->fw_size;

-   csr->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
-   if (!csr->dmc_payload) {
+   dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
+   if (!dmc->dmc_payload) {
DRM_ERROR("Memory allocation failed for dmc payload\n");
return 0;
}

payload = (u8 *)(dmc_header) + header_len_bytes;
-   memcpy(csr->dmc_payload, payload, payload_size);
+   memcpy(dmc->dmc_payload, payload, payload_size);

return header_len_bytes + payload_size;

@@ -499,7 +499,7 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
}

static u32
-parse_csr_fw_package(struct intel_csr *csr,
+parse_csr_fw_package(struct intel_dmc *dmc,
 const

Re: [Intel-gfx] [RFC PATCH 03/97] drm/i915/gt: Move CS interrupt handler to the backend

On Thu, May 06, 2021 at 12:13:17PM -0700, Matthew Brost wrote:
> From: Chris Wilson 
> 
> The different submission backends each have their own preferred
> behaviour and interrupt setup. Let each handle their own interrupts.
> 
> This becomes more useful later as we to extract the use of auxiliary
> state in the interrupt handler that is backend specific.
> 
> Signed-off-by: Matthew Brost 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  7 ++
>  drivers/gpu/drm/i915/gt/intel_engine_types.h  | 14 +---
>  .../drm/i915/gt/intel_execlists_submission.c  | 41 ++
>  drivers/gpu/drm/i915/gt/intel_gt_irq.c| 82 ++-
>  drivers/gpu/drm/i915/gt/intel_gt_irq.h| 23 ++
>  .../gpu/drm/i915/gt/intel_ring_submission.c   |  8 ++
>  drivers/gpu/drm/i915/gt/intel_rps.c   |  2 +-
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 ++-
>  drivers/gpu/drm/i915/i915_irq.c   | 10 ++-
>  9 files changed, 124 insertions(+), 74 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 0618379b68ca..828e1669f92c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -255,6 +255,11 @@ static void intel_engine_sanitize_mmio(struct 
> intel_engine_cs *engine)
>   intel_engine_set_hwsp_writemask(engine, ~0u);
>  }
>  
> +static void nop_irq_handler(struct intel_engine_cs *engine, u16 iir)
> +{
> + GEM_DEBUG_WARN_ON(iir);
> +}
> +
>  static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id id)
>  {
>   const struct engine_info *info = _engines[id];
> @@ -292,6 +297,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
> intel_engine_id id)
>   engine->hw_id = info->hw_id;
>   engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
>  
> + engine->irq_handler = nop_irq_handler;
> +
>   engine->class = info->class;
>   engine->instance = info->instance;
>   __sprint_engine_name(engine);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 883bafc44902..9ef349cd5cea 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -402,6 +402,7 @@ struct intel_engine_cs {
>   u32 irq_enable_mask; /* bitmask to enable ring interrupt */
>   void(*irq_enable)(struct intel_engine_cs *engine);
>   void(*irq_disable)(struct intel_engine_cs *engine);
> + void(*irq_handler)(struct intel_engine_cs *engine, u16 iir);
>  
>   void(*sanitize)(struct intel_engine_cs *engine);
>   int (*resume)(struct intel_engine_cs *engine);
> @@ -481,10 +482,9 @@ struct intel_engine_cs {
>  #define I915_ENGINE_HAS_PREEMPTION   BIT(2)
>  #define I915_ENGINE_HAS_SEMAPHORES   BIT(3)
>  #define I915_ENGINE_HAS_TIMESLICES   BIT(4)
> -#define I915_ENGINE_NEEDS_BREADCRUMB_TASKLET BIT(5)
> -#define I915_ENGINE_IS_VIRTUAL   BIT(6)
> -#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(7)
> -#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(8)
> +#define I915_ENGINE_IS_VIRTUAL   BIT(5)
> +#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6)
> +#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
>   unsigned int flags;
>  
>   /*
> @@ -593,12 +593,6 @@ intel_engine_has_timeslices(const struct intel_engine_cs 
> *engine)
>   return engine->flags & I915_ENGINE_HAS_TIMESLICES;
>  }
>  
> -static inline bool
> -intel_engine_needs_breadcrumb_tasklet(const struct intel_engine_cs *engine)
> -{
> - return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
> -}
> -
>  static inline bool
>  intel_engine_is_virtual(const struct intel_engine_cs *engine)
>  {
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 9d2da5ccaef6..8db200422950 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -118,6 +118,7 @@
>  #include "intel_engine_stats.h"
>  #include "intel_execlists_submission.h"
>  #include "intel_gt.h"
> +#include "intel_gt_irq.h"
>  #include "intel_gt_pm.h"
>  #include "intel_gt_requests.h"
>  #include "intel_lrc.h"
> @@ -2384,6 +2385,45 @@ static void execlists_submission_tasklet(struct 
> tasklet_struct *t)
>   rcu_read_unlock();
>  }
>  
> +static void execlists_irq_handler(struct intel_engine_cs *engine, u16 iir)
> +{
> + bool tasklet = false;
> +
> + if (unlikely(iir & GT_CS_MASTER_ERROR_INTERRUPT)) {
> + u32 eir;
> +
> + /* Upper 16b are the enabling mask, rsvd for internal errors */
> + eir = ENGINE_READ(engine, RING_EIR) & GENMASK(15, 0);
> + ENGINE_TRACE(engine, "CS error: %x\n", eir);
> +
> + /*

Re: [Intel-gfx] [RFC PATCH 02/97] drm/i915/gt: Move submission_method into intel_gt

On Thu, May 06, 2021 at 12:13:16PM -0700, Matthew Brost wrote:
> From: Chris Wilson 
> 
> Since we setup the submission method for the engines once, it is easy to
> assign an enum and use that instead of probing into the backends.
> 
> Signed-off-by: Matthew Brost 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Matthew Brost 

> ---
>  drivers/gpu/drm/i915/gt/intel_engine.h   |  8 +++-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c| 12 
>  drivers/gpu/drm/i915/gt/intel_execlists_submission.c |  8 
>  drivers/gpu/drm/i915/gt/intel_execlists_submission.h |  3 ---
>  drivers/gpu/drm/i915/gt/intel_gt_types.h |  7 +++
>  drivers/gpu/drm/i915/gt/intel_reset.c|  7 +++
>  drivers/gpu/drm/i915/gt/selftest_execlists.c |  2 +-
>  drivers/gpu/drm/i915/gt/selftest_ring_submission.c   |  2 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c|  5 -
>  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h|  1 -
>  drivers/gpu/drm/i915/i915_perf.c | 10 +-
>  11 files changed, 32 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 47ee8578e511..8d9184920c51 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -13,8 +13,9 @@
>  #include "i915_reg.h"
>  #include "i915_request.h"
>  #include "i915_selftest.h"
> -#include "gt/intel_timeline.h"
>  #include "intel_engine_types.h"
> +#include "intel_gt_types.h"
> +#include "intel_timeline.h"
>  #include "intel_workarounds.h"
>  
>  struct drm_printer;
> @@ -262,6 +263,11 @@ void intel_engine_init_active(struct intel_engine_cs 
> *engine,
>  #define ENGINE_MOCK  1
>  #define ENGINE_VIRTUAL   2
>  
> +static inline bool intel_engine_uses_guc(const struct intel_engine_cs 
> *engine)
> +{
> + return engine->gt->submission_method >= INTEL_SUBMISSION_GUC;
> +}
> +
>  static inline bool
>  intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
>  {
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 6dbdbde00f14..0618379b68ca 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -909,12 +909,16 @@ int intel_engines_init(struct intel_gt *gt)
>   enum intel_engine_id id;
>   int err;
>  
> - if (intel_uc_uses_guc_submission(>uc))
> + if (intel_uc_uses_guc_submission(>uc)) {
> + gt->submission_method = INTEL_SUBMISSION_GUC;
>   setup = intel_guc_submission_setup;
> - else if (HAS_EXECLISTS(gt->i915))
> + } else if (HAS_EXECLISTS(gt->i915)) {
> + gt->submission_method = INTEL_SUBMISSION_ELSP;
>   setup = intel_execlists_submission_setup;
> - else
> + } else {
> + gt->submission_method = INTEL_SUBMISSION_RING;
>   setup = intel_ring_submission_setup;
> + }
>  
>   for_each_engine(engine, gt, id) {
>   err = engine_setup_common(engine);
> @@ -1479,7 +1483,7 @@ static void intel_engine_print_registers(struct 
> intel_engine_cs *engine,
>   drm_printf(m, "\tIPEHR: 0x%08x\n", ENGINE_READ(engine, IPEHR));
>   }
>  
> - if (intel_engine_in_guc_submission_mode(engine)) {
> + if (intel_engine_uses_guc(engine)) {
>   /* nothing to print yet */
>   } else if (HAS_EXECLISTS(dev_priv)) {
>   struct i915_request * const *port, *rq;
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 1108c193ab65..9d2da5ccaef6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1768,7 +1768,6 @@ process_csb(struct intel_engine_cs *engine, struct 
> i915_request **inactive)
>*/
>   GEM_BUG_ON(!tasklet_is_locked(>tasklet) &&
>  !reset_in_progress(execlists));
> - GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
>  
>   /*
>* Note that csb_write, csb_status may be either in HWSP or mmio.
> @@ -3884,13 +3883,6 @@ void intel_execlists_show_requests(struct 
> intel_engine_cs *engine,
>   spin_unlock_irqrestore(>active.lock, flags);
>  }
>  
> -bool
> -intel_engine_in_execlists_submission_mode(const struct intel_engine_cs 
> *engine)
> -{
> - return engine->set_default_submission ==
> -execlists_set_default_submission;
> -}
> -
>  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
>  #include "selftest_execlists.c"
>  #endif
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
> index fd61dae820e9..4ca9b475e252 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
> +++

Re: [Intel-gfx] [PATCH] drm/i915/gvt: remove local storage of debugfs file

2021-05-18 Thread Zhenyu Wang

On 2021.05.18 18:17:05 +0200, Greg Kroah-Hartman wrote:
> There is no need to keep the dentry around for the debugfs kvmgt cache
> file, as we can just look it up when we want to remove it later on.
> Simplify the structure by removing the dentry and relying on debugfs
> to find the dentry to remove when we want to.
> 
> By doing this change, we remove the last in-kernel user that was storing
> the result of debugfs_create_long(), so that api can be cleaned up.
> 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 65ff43cfc0f7..433c2a448f2d 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -88,6 +88,7 @@ struct kvmgt_pgfn {
>   struct hlist_node hnode;
>  };
>  
> +#define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
>  struct kvmgt_guest_info {
>   struct kvm *kvm;
>   struct intel_vgpu *vgpu;
> @@ -95,7 +96,6 @@ struct kvmgt_guest_info {
>  #define NR_BKT (1 << 18)
>   struct hlist_head ptable[NR_BKT];
>  #undef NR_BKT
> - struct dentry *debugfs_cache_entries;
>  };
>  
>  struct gvt_dma {
> @@ -1843,16 +1843,15 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
>   info->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
>   kvm_page_track_register_notifier(kvm, >track_node);
>  
> - info->debugfs_cache_entries = debugfs_create_ulong(
> - "kvmgt_nr_cache_entries",
> - 0444, vgpu->debugfs,
> - >nr_cache_entries);
> + debugfs_create_ulong(KVMGT_DEBUGFS_FILENAME, 0444, vgpu->debugfs,
> +  >nr_cache_entries);
>   return 0;
>  }
>  
>  static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
>  {
> - debugfs_remove(info->debugfs_cache_entries);
> + debugfs_remove(debugfs_lookup(KVMGT_DEBUGFS_FILENAME,
> +   info->vgpu->debugfs));
>  
>   kvm_page_track_unregister_notifier(info->kvm, >track_node);
>   kvm_put_kvm(info->kvm);
> -- 

Reviewed-by: Zhenyu Wang 

Thanks!


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

[Intel-gfx] ✓ Fi.CI.BAT: success for ADL-P: more reviewed patches

== Series Details ==

Series: ADL-P: more reviewed patches
URL   : https://patchwork.freedesktop.org/series/90305/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10100 -> Patchwork_20151


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-n3050:   [PASS][2] -> [FAIL][3] ([i915#3457])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vecs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@bcs0:
- fi-bsw-nick:[PASS][4] -> [FAIL][5] ([i915#3457]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html

  * igt@gem_wait@wait@all:
- fi-bwr-2160:[PASS][6] -> [FAIL][7] ([i915#3457])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bwr-2160/igt@gem_wait@w...@all.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bwr-2160/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   NOTRUN -> [DMESG-FAIL][8] ([i915#3457])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-elk-e7500:   [PASS][9] -> [FAIL][10] ([i915#53])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-n3050:   [FAIL][11] ([i915#3457]) -> [PASS][12] +2 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-kefka:   [FAIL][13] ([i915#3457]) -> [PASS][14] +2 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_wait@busy@all:
- fi-bwr-2160:[FAIL][15] ([i915#3457]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bwr-2160/igt@gem_wait@b...@all.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bwr-2160/igt@gem_wait@b...@all.html

  * igt@gem_wait@wait@all:
- fi-bsw-nick:[FAIL][17] ([i915#3457]) -> [PASS][18] +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_wait@w...@all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-nick/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@hangcheck:
- {fi-tgl-dsi}:   [DMESG-FAIL][19] ([i915#2927]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-tgl-dsi/igt@i915_selftest@l...@hangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-tgl-dsi/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@sanitycheck:
- fi-elk-e7500:   [SKIP][21] ([fdo#109271]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@i915_selftest@l...@sanitycheck.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-elk-e7500/igt@i915_selftest@l...@sanitycheck.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-bsw-kefka:   [FAIL][23] ([i915#53]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20151/fi-bsw-kefka/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bwr-2160:[FAIL][25] ([i915#53]) -> [PASS][26]
   [25]:

Re: [Intel-gfx] [RFC PATCH 01/97] drm/i915/gt: Move engine setup out of set_default_submission

On Thu, May 06, 2021 at 12:13:15PM -0700, Matthew Brost wrote:
> From: Chris Wilson 
> 
> Now that we no longer switch back and forth between guc and execlists,
> we no longer need to restore the backend's vfunc and can leave them set
> after initialisation. The only catch is that we lose the submission on
> wedging and still need to reset the submit_request vfunc on unwedging.
> 
> Signed-off-by: Matthew Brost 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

Reviewed-by: Matthew Brost 

> ---
>  .../drm/i915/gt/intel_execlists_submission.c  | 46 -
>  .../gpu/drm/i915/gt/intel_ring_submission.c   |  4 --
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 50 ---
>  3 files changed, 44 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index de124870af44..1108c193ab65 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3076,29 +3076,6 @@ static void execlists_set_default_submission(struct 
> intel_engine_cs *engine)
>   engine->submit_request = execlists_submit_request;
>   engine->schedule = i915_schedule;
>   engine->execlists.tasklet.callback = execlists_submission_tasklet;
> -
> - engine->reset.prepare = execlists_reset_prepare;
> - engine->reset.rewind = execlists_reset_rewind;
> - engine->reset.cancel = execlists_reset_cancel;
> - engine->reset.finish = execlists_reset_finish;
> -
> - engine->park = execlists_park;
> - engine->unpark = NULL;
> -
> - engine->flags |= I915_ENGINE_SUPPORTS_STATS;
> - if (!intel_vgpu_active(engine->i915)) {
> - engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
> - if (can_preempt(engine)) {
> - engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> - if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
> - engine->flags |= I915_ENGINE_HAS_TIMESLICES;
> - }
> - }
> -
> - if (intel_engine_has_preemption(engine))
> - engine->emit_bb_start = gen8_emit_bb_start;
> - else
> - engine->emit_bb_start = gen8_emit_bb_start_noarb;
>  }
>  
>  static void execlists_shutdown(struct intel_engine_cs *engine)
> @@ -3129,6 +3106,14 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
> *engine)
>   engine->cops = _context_ops;
>   engine->request_alloc = execlists_request_alloc;
>  
> + engine->reset.prepare = execlists_reset_prepare;
> + engine->reset.rewind = execlists_reset_rewind;
> + engine->reset.cancel = execlists_reset_cancel;
> + engine->reset.finish = execlists_reset_finish;
> +
> + engine->park = execlists_park;
> + engine->unpark = NULL;
> +
>   engine->emit_flush = gen8_emit_flush_xcs;
>   engine->emit_init_breadcrumb = gen8_emit_init_breadcrumb;
>   engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_xcs;
> @@ -3149,6 +3134,21 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
> *engine)
>* until a more refined solution exists.
>*/
>   }
> +
> + engine->flags |= I915_ENGINE_SUPPORTS_STATS;
> + if (!intel_vgpu_active(engine->i915)) {
> + engine->flags |= I915_ENGINE_HAS_SEMAPHORES;
> + if (can_preempt(engine)) {
> + engine->flags |= I915_ENGINE_HAS_PREEMPTION;
> + if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
> + engine->flags |= I915_ENGINE_HAS_TIMESLICES;
> + }
> + }
> +
> + if (intel_engine_has_preemption(engine))
> + engine->emit_bb_start = gen8_emit_bb_start;
> + else
> + engine->emit_bb_start = gen8_emit_bb_start_noarb;
>  }
>  
>  static void logical_ring_default_irqs(struct intel_engine_cs *engine)
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 9585546556ee..5f4f7f1df48f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -989,14 +989,10 @@ static void gen6_bsd_submit_request(struct i915_request 
> *request)
>  static void i9xx_set_default_submission(struct intel_engine_cs *engine)
>  {
>   engine->submit_request = i9xx_submit_request;
> -
> - engine->park = NULL;
> - engine->unpark = NULL;
>  }
>  
>  static void gen6_bsd_set_default_submission(struct intel_engine_cs *engine)
>  {
> - i9xx_set_default_submission(engine);
>   engine->submit_request = gen6_bsd_submit_request;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 92688a9b6717..f72faa0b8339 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -608,35

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for ADL-P: more reviewed patches

== Series Details ==

Series: ADL-P: more reviewed patches
URL   : https://patchwork.freedesktop.org/series/90305/
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/display/intel_display.c:1887:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1887:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1887:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1203:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ADL-P: more reviewed patches

== Series Details ==

Series: ADL-P: more reviewed patches
URL   : https://patchwork.freedesktop.org/series/90305/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a03b363a26c6 drm/i915/xelpd: Calculate VDSC RC parameters
7961852577ed drm/i915/xelpd: Add rc_qp_table for rcparams calculation
-:37: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#37: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 359 lines checked
562ee7cedb86 drm/i915/adl_p: Add dedicated SAGV watermarks
-:70: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#70: FILE: drivers/gpu/drm/i915/i915_drv.h:592:
+#define HAS_HW_SAGV_WM(i915) (DISPLAY_VER(i915) >= 13 && !IS_DGFX(i915))

-:134: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#134: FILE: drivers/gpu/drm/i915/i915_reg.h:6463:
+#define _PLANE_WM_BASE(pipe, plane) \
+   _PLANE(plane, _PLANE_WM_1(pipe), _PLANE_WM_2(pipe))

-:142: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#142: FILE: drivers/gpu/drm/i915/i915_reg.h:6471:
+#define PLANE_WM_SAGV(pipe, plane) \
+   _MMIO(_PLANE(plane, _PLANE_WM_SAGV_1(pipe), _PLANE_WM_SAGV_2(pipe)))

-:148: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#148: FILE: drivers/gpu/drm/i915/i915_reg.h:6477:
+#define PLANE_WM_SAGV_TRANS(pipe, plane) \
+   _MMIO(_PLANE(plane, _PLANE_WM_SAGV_TRANS_1(pipe), 
_PLANE_WM_SAGV_TRANS_2(pipe)))

-:154: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible 
side-effects?
#154: FILE: drivers/gpu/drm/i915/i915_reg.h:6483:
+#define PLANE_WM_TRANS(pipe, plane) \
_MMIO(_PLANE(plane, _PLANE_WM_TRANS_1(pipe), _PLANE_WM_TRANS_2(pipe)))

total: 0 errors, 0 warnings, 5 checks, 213 lines checked
78d955cdad9a drm/i915/adl_p: Setup ports/phys
22aacfaef99f drm/i915/adl_p: Implement TC sequences
37650f010f1a drm/i915/adl_p: Don't config MBUS and DBUF during display 
initialization
9457bdb14040 drm/i915/adl_p: Add ddb allocation support
-:28: WARNING:LONG_LINE_COMMENT: line length of 102 exceeds 100 columns
#28: FILE: drivers/gpu/drm/i915/i915_reg.h:7302:
+#define  DDB_ENTRY_MASK0xFFF /* skl+: 10 bits, 
icl+ 11 bits, adlp+ 12 bits */

total: 0 errors, 1 warnings, 0 checks, 172 lines checked
803762341a7f drm/i915: Introduce MBUS relative dbuf offsets
f44d5b32fffc drm/i915/adl_p: MBUS programming
-:103: WARNING:LONG_LINE: line length of 123 exceeds 100 columns
#103: FILE: drivers/gpu/drm/i915/i915_reg.h:8168:
+#define  DBUF_MIN_TRACKER_STATE_SERVICE(x) 
REG_FIELD_PREP(DBUF_MIN_TRACKER_STATE_SERVICE_MASK, x) /* ADL-P+ */

total: 0 errors, 1 warnings, 0 checks, 236 lines checked
7b42bcdfc6e2 drm/i915/adl_p: Tx escape clock with DSI
f49882fb1151 drm/i915/display: Replace dc3co_enabled with dc3co_exitline on 
intel_psr struct
5298406b00ba drm/i915/display: Add PSR interrupt error check function
43accd9c0cbd drm/i915/adl_p: Define and use ADL-P specific DP translation tables
cbd6b11c9335 drm/i915/adl_p: Add PLL Support
c23f7e3c4d9d drm/i915/adl_p: Program DP/HDMI link rate to DDI_BUF_CTL
98e0e0a9fbe9 drm/i915/adlp: Add PIPE_MISC2 programming
7c81ddee3062 drm/i915/adl_p: Update memory bandwidth parameters


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

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC submission / DRM scheduler integration plan + new uAPI (rev2)

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI (rev2)
URL   : https://patchwork.freedesktop.org/series/89840/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10100 -> Patchwork_20150


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-nick:[PASS][3] -> [FAIL][4] ([i915#3457])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-n3050:   [PASS][5] -> [FAIL][6] ([i915#3457])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-bsw-kefka:   [PASS][7] -> [FAIL][8] ([i915#3457])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@busy@all:
- fi-bsw-nick:[PASS][9] -> [FAIL][10] ([i915#3177] / [i915#3457])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_wait@b...@all.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-nick/igt@gem_wait@b...@all.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   NOTRUN -> [DMESG-FAIL][11] ([i915#3457])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_busy@basic@modeset:
- fi-ilk-650: [PASS][12] -> [INCOMPLETE][13] ([i915#3457])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-ilk-650/igt@kms_busy@ba...@modeset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-ilk-650/igt@kms_busy@ba...@modeset.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-elk-e7500:   [PASS][14] -> [FAIL][15] ([i915#53])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-n3050:   [FAIL][16] ([i915#3457]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-kefka:   [FAIL][18] ([i915#3457]) -> [PASS][19] +2 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_wait@wait@all:
- fi-bsw-nick:[FAIL][20] ([i915#3457]) -> [PASS][21] +2 similar 
issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_wait@w...@all.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-bsw-nick/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@hangcheck:
- {fi-tgl-dsi}:   [DMESG-FAIL][22] ([i915#2927]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-tgl-dsi/igt@i915_selftest@l...@hangcheck.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20150/fi-tgl-dsi/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][24] ([i915#2782]) -> [PASS][25]
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [25]:

[Intel-gfx] [CI 09/17] drm/i915/adl_p: MBUS programming

From: Vandita Kulkarni 

Update MBUS_CTL register if the 2 mbus can be joined as per the current
DDB allocation and active pipes, also update hashing mode and pipe
select bits as  per the sequence mentioned in the bspec.

Cc: Stanislav Lisovskiy 
Cc: José Roberto de Souza 
Signed-off-by: Vandita Kulkarni 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_atomic.c  | 20 +
 drivers/gpu/drm/i915/display/intel_atomic.h  |  1 +
 drivers/gpu/drm/i915/display/intel_display.c |  3 +
 drivers/gpu/drm/i915/i915_reg.h  | 11 +++
 drivers/gpu/drm/i915/intel_pm.c  | 92 ++--
 drivers/gpu/drm/i915/intel_pm.h  |  2 +-
 6 files changed, 120 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 88f424020a5f..b4e7ac51aa31 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -187,6 +187,26 @@ intel_connector_needs_modeset(struct intel_atomic_state 
*state,

new_conn_state->crtc)));
 }
 
+/**
+ * intel_any_crtc_needs_modeset - check if any CRTC needs a modeset
+ * @state: the atomic state corresponding to this modeset
+ *
+ * Returns true if any CRTC in @state needs a modeset.
+ */
+bool intel_any_crtc_needs_modeset(struct intel_atomic_state *state)
+{
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *crtc_state;
+   int i;
+
+   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+   if (intel_crtc_needs_modeset(crtc_state))
+   return true;
+   }
+
+   return false;
+}
+
 struct intel_digital_connector_state *
 intel_atomic_get_digital_connector_state(struct intel_atomic_state *state,
 struct intel_connector *connector)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h 
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 62a3365ed5e6..d2700c74c9da 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -35,6 +35,7 @@ struct drm_connector_state *
 intel_digital_connector_duplicate_state(struct drm_connector *connector);
 bool intel_connector_needs_modeset(struct intel_atomic_state *state,
   struct drm_connector *connector);
+bool intel_any_crtc_needs_modeset(struct intel_atomic_state *state);
 struct intel_digital_connector_state *
 intel_atomic_get_digital_connector_state(struct intel_atomic_state *state,
 struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 953d363d9702..adc001351ad3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9957,6 +9957,9 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+   if (intel_any_crtc_needs_modeset(state))
+   any_ms = true;
+
if (any_ms) {
ret = intel_modeset_checks(state);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5cf5e5d7deee..3e567ee6285e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2935,6 +2935,15 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define MBUS_BBOX_CTL_S1   _MMIO(0x45040)
 #define MBUS_BBOX_CTL_S2   _MMIO(0x45044)
 
+#define MBUS_CTL   _MMIO(0x4438C)
+#define MBUS_JOIN  REG_BIT(31)
+#define MBUS_HASHING_MODE_MASK REG_BIT(30)
+#define MBUS_HASHING_MODE_2x2  REG_FIELD_PREP(MBUS_HASHING_MODE_MASK, 
0)
+#define MBUS_HASHING_MODE_1x4  REG_FIELD_PREP(MBUS_HASHING_MODE_MASK, 
1)
+#define MBUS_JOIN_PIPE_SELECT_MASK REG_GENMASK(28, 26)
+#define MBUS_JOIN_PIPE_SELECT(pipe)
REG_FIELD_PREP(MBUS_JOIN_PIPE_SELECT_MASK, pipe)
+#define MBUS_JOIN_PIPE_SELECT_NONE MBUS_JOIN_PIPE_SELECT(7)
+
 #define HDPORT_STATE   _MMIO(0x45050)
 #define   HDPORT_DPLL_USED_MASKREG_GENMASK(15, 12)
 #define   HDPORT_DDI_USED(phy) REG_BIT(2 * (phy) + 1)
@@ -8155,6 +8164,8 @@ enum {
 #define  DBUF_POWER_STATE  REG_BIT(30)
 #define  DBUF_TRACKER_STATE_SERVICE_MASK   REG_GENMASK(23, 19)
 #define  DBUF_TRACKER_STATE_SERVICE(x) 
REG_FIELD_PREP(DBUF_TRACKER_STATE_SERVICE_MASK, x)
+#define  DBUF_MIN_TRACKER_STATE_SERVICE_MASK   REG_GENMASK(18, 16) /* ADL-P+ */
+#define  DBUF_MIN_TRACKER_STATE_SERVICE(x) 
REG_FIELD_PREP(DBUF_MIN_TRACKER_STATE_SERVICE_MASK, x) /* ADL-P+ */
 
 #define GEN7_MSG_CTL   _MMIO(0x45010)
 #define  WAIT_FOR_PCH_RESET_ACK

[Intel-gfx] [CI 08/17] drm/i915: Introduce MBUS relative dbuf offsets

From: Ville Syrjälä 

The dbuf slices are going to be split across several MBUS units.
The actual dbuf programming will use offsets relative to the
MBUS unit. To accommodate that we shall store the MBUS relative
offsets into the dbuf_state->ddb[] and crtc_state->plane_ddb*[].

For crtc_state->wm.skl.ddb however we want to stick to global
offsets as we use this to sanity check that the ddb allocations
don't overlap between pipes.

Cc: Clint Taylor 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_pm.c | 40 -
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 411ec468d02a..cbbd966f710e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4057,6 +4057,20 @@ skl_ddb_entry_for_slices(struct drm_i915_private 
*dev_priv, u8 slice_mask,
WARN_ON(ddb->end > INTEL_INFO(dev_priv)->dbuf.size);
 }
 
+static unsigned int mbus_ddb_offset(struct drm_i915_private *i915, u8 
slice_mask)
+{
+   struct skl_ddb_entry ddb;
+
+   if (slice_mask & (BIT(DBUF_S1) | BIT(DBUF_S2)))
+   slice_mask = BIT(DBUF_S1);
+   else if (slice_mask & (BIT(DBUF_S3) | BIT(DBUF_S4)))
+   slice_mask = BIT(DBUF_S3);
+
+   skl_ddb_entry_for_slices(i915, slice_mask, );
+
+   return ddb.start;
+}
+
 u32 skl_ddb_dbuf_slice_mask(struct drm_i915_private *dev_priv,
const struct skl_ddb_entry *entry)
 {
@@ -4149,6 +4163,7 @@ skl_crtc_allocate_ddb(struct intel_atomic_state *state, 
struct intel_crtc *crtc)
struct intel_crtc_state *crtc_state;
struct skl_ddb_entry ddb_slices;
enum pipe pipe = crtc->pipe;
+   unsigned int mbus_offset;
u32 ddb_range_size;
u32 dbuf_slice_mask;
u32 start, end;
@@ -4163,6 +4178,7 @@ skl_crtc_allocate_ddb(struct intel_atomic_state *state, 
struct intel_crtc *crtc)
dbuf_slice_mask = new_dbuf_state->slices[pipe];
 
skl_ddb_entry_for_slices(dev_priv, dbuf_slice_mask, _slices);
+   mbus_offset = mbus_ddb_offset(dev_priv, dbuf_slice_mask);
ddb_range_size = skl_ddb_entry_size(_slices);
 
intel_crtc_dbuf_weights(new_dbuf_state, pipe,
@@ -4171,11 +4187,11 @@ skl_crtc_allocate_ddb(struct intel_atomic_state *state, 
struct intel_crtc *crtc)
start = ddb_range_size * weight_start / weight_total;
end = ddb_range_size * weight_end / weight_total;
 
-   new_dbuf_state->ddb[pipe].start = ddb_slices.start + start;
-   new_dbuf_state->ddb[pipe].end = ddb_slices.start + end;
-
+   new_dbuf_state->ddb[pipe].start = ddb_slices.start - mbus_offset + 
start;
+   new_dbuf_state->ddb[pipe].end = ddb_slices.start - mbus_offset + end;
 out:
-   if (skl_ddb_entry_equal(_dbuf_state->ddb[pipe],
+   if (old_dbuf_state->slices[pipe] == new_dbuf_state->slices[pipe] &&
+   skl_ddb_entry_equal(_dbuf_state->ddb[pipe],
_dbuf_state->ddb[pipe]))
return 0;
 
@@ -4187,7 +4203,12 @@ skl_crtc_allocate_ddb(struct intel_atomic_state *state, 
struct intel_crtc *crtc)
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
 
-   crtc_state->wm.skl.ddb = new_dbuf_state->ddb[pipe];
+   /*
+* Used for checking overlaps, so we need absolute
+* offsets instead of MBUS relative offsets.
+*/
+   crtc_state->wm.skl.ddb.start = mbus_offset + 
new_dbuf_state->ddb[pipe].start;
+   crtc_state->wm.skl.ddb.end = mbus_offset + 
new_dbuf_state->ddb[pipe].end;
 
drm_dbg_kms(_priv->drm,
"[CRTC:%d:%s] dbuf slices 0x%x -> 0x%x, ddb (%d - %d) -> 
(%d - %d), active pipes 0x%x -> 0x%x\n",
@@ -6416,6 +6437,7 @@ void skl_wm_get_hw_state(struct drm_i915_private 
*dev_priv)
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
enum pipe pipe = crtc->pipe;
+   unsigned int mbus_offset;
enum plane_id plane_id;
 
skl_pipe_wm_get_hw_state(crtc, _state->wm.skl.optimal);
@@ -6441,7 +6463,13 @@ void skl_wm_get_hw_state(struct drm_i915_private 
*dev_priv)
 
dbuf_state->weight[pipe] = intel_crtc_ddb_weight(crtc_state);
 
-   crtc_state->wm.skl.ddb = dbuf_state->ddb[pipe];
+   /*
+* Used for checking overlaps, so we need absolute
+* offsets instead of MBUS relative offsets.
+*/
+   mbus_offset = mbus_ddb_offset(dev_priv, 
dbuf_state->slices[pipe]);
+   crtc_state->wm.skl.ddb.start = mbus_offset + 
dbuf_state->ddb[pipe].start;
+   crtc_state->wm.skl.ddb.end = mbus_offset + 
dbuf_state->ddb[pipe].end;
 
drm_dbg_kms(_priv->drm,

[Intel-gfx] [CI 12/17] drm/i915/display: Add PSR interrupt error check function

From: Gwan-gyeong Mun 

In order to reuse code of PSR interrupt error check on other PSR functions,
it adds psr_interrupt_error_check() function.

Cc: José Roberto de Souza 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 47 +++-
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 5bafd0de6ad9..de509a73ea71 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1030,27 +1030,11 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 IGNORE_PSR2_HW_TRACKING : 0);
 }
 
-static void intel_psr_enable_locked(struct intel_dp *intel_dp,
-   const struct intel_crtc_state *crtc_state,
-   const struct drm_connector_state 
*conn_state)
+static bool psr_interrupt_error_check(struct intel_dp *intel_dp)
 {
-   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-   struct intel_encoder *encoder = _port->base;
u32 val;
 
-   drm_WARN_ON(_priv->drm, intel_dp->psr.enabled);
-
-   intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
-   intel_dp->psr.busy_frontbuffer_bits = 0;
-   intel_dp->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
-   intel_dp->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);
-   intel_dp->psr.dc3co_exit_delay = val;
-   intel_dp->psr.dc3co_exitline = crtc_state->dc3co_exitline;
-   intel_dp->psr.psr2_sel_fetch_enabled = 
crtc_state->enable_psr2_sel_fetch;
-
/*
 * If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
 * will still keep the error set even after the reset done in the
@@ -1071,9 +1055,36 @@ static void intel_psr_enable_locked(struct intel_dp 
*intel_dp,
intel_dp->psr.sink_not_reliable = true;
drm_dbg_kms(_priv->drm,
"PSR interruption error set, not enabling PSR\n");
-   return;
+   return false;
}
 
+   return true;
+}
+
+static void intel_psr_enable_locked(struct intel_dp *intel_dp,
+   const struct intel_crtc_state *crtc_state,
+   const struct drm_connector_state 
*conn_state)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct intel_encoder *encoder = _port->base;
+   u32 val;
+
+   drm_WARN_ON(_priv->drm, intel_dp->psr.enabled);
+
+   intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
+   intel_dp->psr.busy_frontbuffer_bits = 0;
+   intel_dp->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
+   intel_dp->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);
+   intel_dp->psr.dc3co_exit_delay = val;
+   intel_dp->psr.dc3co_exitline = crtc_state->dc3co_exitline;
+   intel_dp->psr.psr2_sel_fetch_enabled = 
crtc_state->enable_psr2_sel_fetch;
+
+   if (!psr_interrupt_error_check(intel_dp))
+   return;
+
drm_dbg_kms(_priv->drm, "Enabling PSR%s\n",
intel_dp->psr.psr2_enabled ? "2" : "1");
intel_dp_compute_psr_vsc_sdp(intel_dp, crtc_state, conn_state,
-- 
2.31.1

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

[Intel-gfx] [CI 02/17] drm/i915/xelpd: Add rc_qp_table for rcparams calculation

From: Vandita Kulkarni 

Add the qp table for 444 formats, for 8bpc, 10bpc and 12bpc, as given by
the VESA C model for DSC 1.1

v2:
 - Add include guard to header (Jani)
 - Move the big tables to a .c file (Chris, Jani, Lucas)
v3:
 - Make tables 'static const' and add lookup functions to index into
   them.  (Jani)
v3.1:
 - Include missing .h file.

Cc: Manasi Navare 
Signed-off-by: Vandita Kulkarni 
Signed-off-by: Matt Roper 
Reviewed-by: Lucas De Marchi 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/display/intel_qp_tables.c| 309 ++
 .../gpu/drm/i915/display/intel_qp_tables.h|  14 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
 4 files changed, 333 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_qp_tables.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_qp_tables.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137b..4a4d30d8a10a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -263,6 +263,7 @@ i915-y += \
display/intel_lvds.o \
display/intel_panel.o \
display/intel_pps.o \
+   display/intel_qp_tables.o \
display/intel_sdvo.o \
display/intel_tv.o \
display/intel_vdsc.o \
diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c 
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
new file mode 100644
index ..c626a24fe98f
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+
+#include "i915_utils.h"
+#include "intel_qp_tables.h"
+
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP444_8BPC_MAX_NUM_BPP37
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP444_10BPC_MAX_NUM_BPP   49
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP444_12BPC_MAX_NUM_BPP   61
+
+/*
+ * These qp tables are as per the C model
+ * and it has the rows pointing to bpps which increment
+ * in steps of 0.5
+ * We do not support fractional bpps as of today,
+ * hence we would skip the fractional bpps during
+ * our references for qp calclulations.
+ */
+static const u8 
rc_range_minqp444_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_8BPC_MAX_NUM_BPP] = {
+   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 3, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 1,
+ 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 4, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1,
+ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 5, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 1, 1,
+ 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0 },
+   { 5, 5, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2,
+ 2, 2, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 5, 5, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2,
+ 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 6, 5, 5, 4, 4, 4, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
+ 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+   { 6, 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4, 3,
+ 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 0 },
+   { 6, 6, 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4,
+ 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 1, 1, 1, 0 },
+   { 6, 6, 6, 6, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4,
+ 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 1, 1, 1, 0 },
+   { 9, 9, 9, 9, 8, 8, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 5,
+ 5, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 1, 1, 1 },
+   { 14, 14, 13, 13, 12, 12, 12, 12, 11, 11, 10, 10, 10, 10, 9, 9, 9, 8, 8,
+ 8, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 3, 3, 3 }
+};
+
+static const u8 
rc_range_maxqp444_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_8BPC_MAX_NUM_BPP] = {
+   { 4, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+   { 6, 6, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1,
+ 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 8, 7, 7, 6, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 1,
+ 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+   { 8, 8, 7, 7, 6, 6, 6, 6, 6, 6, 6, 6, 5, 5, 5, 4, 3, 3, 2,

[Intel-gfx] [CI 07/17] drm/i915/adl_p: Add ddb allocation support

From: Vandita Kulkarni 

On adlp the two mbuses have two display pipes and
two DBUFS, Pipe A and D on Mbus1 and Pipe B and C on
Mbus2. The Mbus can be joined and all the DBUFS can be
used on Pipe A or B.

Bspec: 49255
Cc: Anusha Srivatsa 
Signed-off-by: Vandita Kulkarni 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_reg.h |  22 --
 drivers/gpu/drm/i915/intel_pm.c | 121 +++-
 2 files changed, 138 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bd6c36837aa..5cf5e5d7deee 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7299,7 +7299,7 @@ enum {
 
 #define _PLANE_BUF_CFG_1_B 0x7127c
 #define _PLANE_BUF_CFG_2_B 0x7137c
-#define  DDB_ENTRY_MASK0x7FF /* skl+: 10 bits, 
icl+ 11 bits */
+#define  DDB_ENTRY_MASK0xFFF /* skl+: 10 bits, 
icl+ 11 bits, adlp+ 12 bits */
 #define  DDB_ENTRY_END_SHIFT   16
 #define _PLANE_BUF_CFG_1(pipe) \
_PIPE(pipe, _PLANE_BUF_CFG_1_A, _PLANE_BUF_CFG_1_B)
@@ -8134,9 +8134,23 @@ enum {
 #define  DISP_DATA_PARTITION_5_6   (1 << 6)
 #define  DISP_IPC_ENABLE   (1 << 3)
 
-#define _DBUF_CTL_S1   0x45008
-#define _DBUF_CTL_S2   0x44FE8
-#define DBUF_CTL_S(slice)  _MMIO(_PICK_EVEN(slice, 
_DBUF_CTL_S1, _DBUF_CTL_S2))
+/*
+ * The below are numbered starting from "S1" on gen11/gen12, but starting
+ * with gen13 display, the bspec switches to a 0-based numbering scheme
+ * (although the addresses stay the same so new S0 = old S1, new S1 = old S2).
+ * We'll just use the 0-based numbering here for all platforms since it's the
+ * way things will be named by the hardware team going forward, plus it's more
+ * consistent with how most of the rest of our registers are named.
+ */
+#define _DBUF_CTL_S0   0x45008
+#define _DBUF_CTL_S1   0x44FE8
+#define _DBUF_CTL_S2   0x44300
+#define _DBUF_CTL_S3   0x44304
+#define DBUF_CTL_S(slice)  _MMIO(_PICK(slice, \
+   _DBUF_CTL_S0, \
+   _DBUF_CTL_S1, \
+   _DBUF_CTL_S2, \
+   _DBUF_CTL_S3))
 #define  DBUF_POWER_REQUESTREG_BIT(31)
 #define  DBUF_POWER_STATE  REG_BIT(30)
 #define  DBUF_TRACKER_STATE_SERVICE_MASK   REG_GENMASK(23, 19)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 95fda20d5547..411ec468d02a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4558,6 +4558,118 @@ static const struct dbuf_slice_conf_entry 
tgl_allowed_dbufs[] =
{}
 };
 
+static const struct dbuf_slice_conf_entry adlp_allowed_dbufs[] = {
+   {
+   .active_pipes = BIT(PIPE_A),
+   .dbuf_mask = {
+   [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_B),
+   .dbuf_mask = {
+   [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_A) | BIT(PIPE_B),
+   .dbuf_mask = {
+   [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+   [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_C),
+   .dbuf_mask = {
+   [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_A) | BIT(PIPE_C),
+   .dbuf_mask = {
+   [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+   [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_B) | BIT(PIPE_C),
+   .dbuf_mask = {
+   [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
+   .dbuf_mask = {
+   [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+   [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
+   },
+   },
+   {
+   .active_pipes = BIT(PIPE_D),
+   .dbuf_mask = {
+   [PIPE_D] =

[Intel-gfx] [CI 15/17] drm/i915/adl_p: Program DP/HDMI link rate to DDI_BUF_CTL

From: Imre Deak 

On ADL_P besides programming the PLL accordingly the DP/HDMI link rate
should be also programmed to the DDI_BUF_CTL register, do that.

Cc: José Roberto de Souza 
Signed-off-by: Imre Deak 
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 36 ++--
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e0adb14ecd0d..3d8918674153 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -249,6 +249,31 @@ static u32 icl_pll_to_ddi_clk_sel(struct intel_encoder 
*encoder,
}
 }
 
+static u32 ddi_buf_phy_link_rate(int port_clock)
+{
+   switch (port_clock) {
+   case 162000:
+   return DDI_BUF_PHY_LINK_RATE(0);
+   case 216000:
+   return DDI_BUF_PHY_LINK_RATE(4);
+   case 243000:
+   return DDI_BUF_PHY_LINK_RATE(5);
+   case 27:
+   return DDI_BUF_PHY_LINK_RATE(1);
+   case 324000:
+   return DDI_BUF_PHY_LINK_RATE(6);
+   case 432000:
+   return DDI_BUF_PHY_LINK_RATE(7);
+   case 54:
+   return DDI_BUF_PHY_LINK_RATE(2);
+   case 81:
+   return DDI_BUF_PHY_LINK_RATE(3);
+   default:
+   MISSING_CASE(port_clock);
+   return DDI_BUF_PHY_LINK_RATE(0);
+   }
+}
+
 static void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state)
 {
@@ -261,9 +286,11 @@ static void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder,
DDI_BUF_CTL_ENABLE | DDI_BUF_TRANS_SELECT(0);
intel_dp->DP |= DDI_PORT_WIDTH(crtc_state->lane_count);
 
-   if (IS_ALDERLAKE_P(i915) &&
-   intel_phy_is_tc(i915, phy) && dig_port->tc_mode != TC_PORT_TBT_ALT)
-   intel_dp->DP |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+   if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
+   intel_dp->DP |= ddi_buf_phy_link_rate(crtc_state->port_clock);
+   if (dig_port->tc_mode != TC_PORT_TBT_ALT)
+   intel_dp->DP |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
+   }
 }
 
 static int icl_calc_tbt_pll_link(struct drm_i915_private *dev_priv,
@@ -3168,6 +3195,9 @@ static void intel_enable_ddi_hdmi(struct 
intel_atomic_state *state,
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
+*
+* On ADL_P the PHY link rate and lane count must be programmed but
+* these are both 0 for HDMI.
 */
intel_de_write(dev_priv, DDI_BUF_CTL(port),
   dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e3e1725b95c..2e4f420a0c9a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10172,6 +10172,7 @@ enum skl_power_gate {
 #define  DDI_BUF_CTL_ENABLE(1 << 31)
 #define  DDI_BUF_TRANS_SELECT(n)   ((n) << 24)
 #define  DDI_BUF_EMP_MASK  (0xf << 24)
+#define  DDI_BUF_PHY_LINK_RATE(r)  ((r) << 20)
 #define  DDI_BUF_PORT_REVERSAL (1 << 16)
 #define  DDI_BUF_IS_IDLE   (1 << 7)
 #define  DDI_BUF_CTL_TC_PHY_OWNERSHIP  REG_BIT(6)
-- 
2.31.1

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

[Intel-gfx] [CI 10/17] drm/i915/adl_p: Tx escape clock with DSI

From: Mika Kahola 

Today when the DSI controller is paired with the Combo-PHY it
uses the high-speed (HS) Word clock for its low power (LP)
transmit PPI communication to the DPHY. The interface signaling
only changes state at an Escape clock frequency (i.e. its
effectively running on a virtual Tx Escape clock that is controlled
by counters w/in the controller), but all the interface flops are
running off the HS clock.

This has the following drawbacks:

 * It is a deviation from the PPI spec which assumes signaling is
   running on a physical Escape clock
 * The PV timings are over constrained (HS timed to 312.5MHz vs.
   an Escape clock of 20MHz max)

This feature is proposing to change the LP Tx communication between
the controller and the DPHY from a virtual Tx Escape clock to a physical
clock.

To do this we need to program two "M" divisors. One for the usual
DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV register and one for MIPIO_DWORD8.

For DSI_ESC_CLK_DIV and DPHY_ESC_CLK_DIV registers the "M" is calculated
as following

Nt = ceil(f_link/160) (theoretical word clock)
Nact = max[3, Nt + (Nt + 1)%2] (actual word clock)
M = Nact * 8

For MIPIO_DWORD8 register, the divisor "M" is calculated as following

M = (Nact - 1)/2

BSpec: 55171

Cc: Vandita Kulkarni 
Signed-off-by: Mika Kahola 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Vandita Kulkarni 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/icl_dsi.c | 21 +++--
 drivers/gpu/drm/i915/i915_reg.h|  6 ++
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ce544e20f35c..16812488c5dd 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -363,10 +363,19 @@ static void gen11_dsi_program_esc_clk_div(struct 
intel_encoder *encoder,
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
enum port port;
int afe_clk_khz;
-   u32 esc_clk_div_m;
+   int theo_word_clk, act_word_clk;
+   u32 esc_clk_div_m, esc_clk_div_m_phy;
 
afe_clk_khz = afe_clk(encoder, crtc_state);
-   esc_clk_div_m = DIV_ROUND_UP(afe_clk_khz, DSI_MAX_ESC_CLK);
+
+   if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv)) {
+   theo_word_clk = DIV_ROUND_UP(afe_clk_khz, 8 * DSI_MAX_ESC_CLK);
+   act_word_clk = max(3, theo_word_clk + (theo_word_clk + 1) % 2);
+   esc_clk_div_m = act_word_clk * 8;
+   esc_clk_div_m_phy = (act_word_clk - 1) / 2;
+   } else {
+   esc_clk_div_m = DIV_ROUND_UP(afe_clk_khz, DSI_MAX_ESC_CLK);
+   }
 
for_each_dsi_port(port, intel_dsi->ports) {
intel_de_write(dev_priv, ICL_DSI_ESC_CLK_DIV(port),
@@ -379,6 +388,14 @@ static void gen11_dsi_program_esc_clk_div(struct 
intel_encoder *encoder,
   esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
intel_de_posting_read(dev_priv, ICL_DPHY_ESC_CLK_DIV(port));
}
+
+   if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv)) {
+   for_each_dsi_port(port, intel_dsi->ports) {
+   intel_de_write(dev_priv, ADL_MIPIO_DW(port, 8),
+  esc_clk_div_m_phy & TX_ESC_CLK_DIV_PHY);
+   intel_de_posting_read(dev_priv, ADL_MIPIO_DW(port, 8));
+   }
+   }
 }
 
 static void get_dsi_io_power_domains(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3e567ee6285e..242c3a3c116c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11325,6 +11325,12 @@ enum skl_power_gate {
 #define  ICL_ESC_CLK_DIV_SHIFT 0
 #define DSI_MAX_ESC_CLK2   /* in KHz */
 
+#define _ADL_MIPIO_REG 0x180
+#define ADL_MIPIO_DW(port, dw) _MMIO(_ICL_COMBOPHY(port) + 
_ADL_MIPIO_REG + 4 * (dw))
+#define   TX_ESC_CLK_DIV_PHY_SEL   REGBIT(16)
+#define   TX_ESC_CLK_DIV_PHY_MASK  REG_GENMASK(23, 16)
+#define   TX_ESC_CLK_DIV_PHY   REG_FIELD_PREP(TX_ESC_CLK_DIV_PHY_MASK, 
0x7f)
+
 #define _DSI_CMD_FRMCTL_0  0x6b034
 #define _DSI_CMD_FRMCTL_1  0x6b834
 #define DSI_CMD_FRMCTL(port)   _MMIO_PORT(port,\
-- 
2.31.1

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

[Intel-gfx] [CI 05/17] drm/i915/adl_p: Implement TC sequences

From: José Roberto de Souza 

ADL-P have basically the same TC connection and disconnection
sequences as ICL and TGL, the major difference is the new registers.

So here adding functions without the icl prefix in the name and
making the new functions call the platform specific function to access
the correct register.

v2:
 - Retain DDI TC PHY ownership flag during modesetting.

BSpec: 55480
Cc: Imre Deak 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Imre Deak 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |   6 ++
 drivers/gpu/drm/i915/display/intel_tc.c  | 132 +--
 drivers/gpu/drm/i915/i915_reg.h  |  10 ++
 3 files changed, 137 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index eccbdd42d223..38a4f251b9c9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -252,12 +252,18 @@ static u32 icl_pll_to_ddi_clk_sel(struct intel_encoder 
*encoder,
 static void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder,
  const struct intel_crtc_state *crtc_state)
 {
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
 
intel_dp->DP = dig_port->saved_port_bits |
DDI_BUF_CTL_ENABLE | DDI_BUF_TRANS_SELECT(0);
intel_dp->DP |= DDI_PORT_WIDTH(crtc_state->lane_count);
+
+   if (IS_ALDERLAKE_P(i915) &&
+   intel_phy_is_tc(i915, phy) && dig_port->tc_mode != TC_PORT_TBT_ALT)
+   intel_dp->DP |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
 }
 
 static int icl_calc_tbt_pll_link(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index e325463acddd..5f03215a03e4 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -205,7 +205,7 @@ static void tc_port_fixup_legacy_flag(struct 
intel_digital_port *dig_port,
dig_port->tc_legacy_port = !dig_port->tc_legacy_port;
 }
 
-static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
+static u32 icl_tc_port_live_status_mask(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_uncore *uncore = >uncore;
@@ -238,6 +238,40 @@ static u32 tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
return mask;
 }
 
+static u32 adl_tc_port_live_status_mask(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
+   u32 isr_bit = i915->hotplug.pch_hpd[dig_port->base.hpd_pin];
+   struct intel_uncore *uncore = >uncore;
+   u32 val, mask = 0;
+
+   val = intel_uncore_read(uncore, TCSS_DDI_STATUS(tc_port));
+   if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_ALT)
+   mask |= BIT(TC_PORT_DP_ALT);
+   if (val & TCSS_DDI_STATUS_HPD_LIVE_STATUS_TBT)
+   mask |= BIT(TC_PORT_TBT_ALT);
+
+   if (intel_uncore_read(uncore, SDEISR) & isr_bit)
+   mask |= BIT(TC_PORT_LEGACY);
+
+   /* The sink can be connected only in a single mode. */
+   if (!drm_WARN_ON(>drm, hweight32(mask) > 1))
+   tc_port_fixup_legacy_flag(dig_port, mask);
+
+   return mask;
+}
+
+static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+   if (IS_ALDERLAKE_P(i915))
+   return adl_tc_port_live_status_mask(dig_port);
+
+   return icl_tc_port_live_status_mask(dig_port);
+}
+
 static bool icl_tc_phy_status_complete(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -256,6 +290,33 @@ static bool icl_tc_phy_status_complete(struct 
intel_digital_port *dig_port)
return val & DP_PHY_MODE_STATUS_COMPLETED(dig_port->tc_phy_fia_idx);
 }
 
+static bool adl_tc_phy_status_complete(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   struct intel_uncore *uncore = >uncore;
+   u32 val;
+
+   val = intel_uncore_read(uncore, 
TCSS_DDI_STATUS(dig_port->tc_phy_fia_idx));
+   if (val == 0x) {
+   drm_dbg_kms(>drm,
+   "Port %s: PHY in TCCOLD, assuming not complete\n",
+   dig_port->tc_port_name);
+   return false;
+   }
+
+   return val & TCSS_DDI_STATUS_READY;
+}
+
+static bool tc_phy_status_complete(struct

[Intel-gfx] [CI 03/17] drm/i915/adl_p: Add dedicated SAGV watermarks

From: Matt Roper 

XE_LPD reduces the number of regular watermark latency levels from 8
to 6 on non-dgfx platforms.  However the hardware also adds a special
purpose SAGV wateramrk (and an accompanying transition watermark) that
will be used by the hardware in place of the level 0 values during SAGV
transitions.

Bspec: 49325, 49326, 50419
Cc: Matt Atwood 
Signed-off-by: Matt Roper 
Signed-off-by: Clinton Taylor 
Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display.c | 32 +++
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/i915_reg.h  | 59 ++--
 drivers/gpu/drm/i915/intel_pm.c  | 54 --
 4 files changed, 126 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 422b59ebf6dc..47251b2bc8a4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8750,6 +8750,38 @@ static void verify_wm_state(struct intel_crtc *crtc,
hw_wm_level->lines);
}
 
+   hw_wm_level = >wm.planes[plane->id].sagv.wm0;
+   sw_wm_level = _wm->planes[plane->id].sagv.wm0;
+
+   if (HAS_HW_SAGV_WM(dev_priv) &&
+   !skl_wm_level_equals(hw_wm_level, sw_wm_level)) {
+   drm_err(_priv->drm,
+   "[PLANE:%d:%s] mismatch in SAGV WM (expected 
e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
+   plane->base.base.id, plane->base.name,
+   sw_wm_level->enable,
+   sw_wm_level->blocks,
+   sw_wm_level->lines,
+   hw_wm_level->enable,
+   hw_wm_level->blocks,
+   hw_wm_level->lines);
+   }
+
+   hw_wm_level = >wm.planes[plane->id].sagv.trans_wm;
+   sw_wm_level = _wm->planes[plane->id].sagv.trans_wm;
+
+   if (HAS_HW_SAGV_WM(dev_priv) &&
+   !skl_wm_level_equals(hw_wm_level, sw_wm_level)) {
+   drm_err(_priv->drm,
+   "[PLANE:%d:%s] mismatch in SAGV trans WM 
(expected e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
+   plane->base.base.id, plane->base.name,
+   sw_wm_level->enable,
+   sw_wm_level->blocks,
+   sw_wm_level->lines,
+   hw_wm_level->enable,
+   hw_wm_level->blocks,
+   hw_wm_level->lines);
+   }
+
/* DDB */
hw_ddb_entry = >ddb_y[plane->id];
sw_ddb_entry = _crtc_state->wm.skl.plane_ddb_y[plane->id];
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9aee6a045590..702841e3f899 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -589,6 +589,8 @@ i915_fence_timeout(const struct drm_i915_private *i915)
 /* Amount of SAGV/QGV points, BSpec precisely defines this */
 #define I915_NUM_QGV_POINTS 8
 
+#define HAS_HW_SAGV_WM(i915) (DISPLAY_VER(i915) >= 13 && !IS_DGFX(i915))
+
 struct ddi_vbt_port_info {
/* Non-NULL if port present. */
struct intel_bios_encoder_data *devdata;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 089b5a59bed3..2e5826860b40 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6426,16 +6426,28 @@ enum {
 /* Watermark register definitions for SKL */
 #define _CUR_WM_A_00x70140
 #define _CUR_WM_B_00x71140
+#define _CUR_WM_SAGV_A 0x70158
+#define _CUR_WM_SAGV_B 0x71158
+#define _CUR_WM_SAGV_TRANS_A   0x7015C
+#define _CUR_WM_SAGV_TRANS_B   0x7115C
+#define _CUR_WM_TRANS_A0x70168
+#define _CUR_WM_TRANS_B0x71168
 #define _PLANE_WM_1_A_00x70240
 #define _PLANE_WM_1_B_00x71240
 #define _PLANE_WM_2_A_00x70340
 #define _PLANE_WM_2_B_00x71340
-#define _PLANE_WM_TRANS_1_A_0  0x70268
-#define _PLANE_WM_TRANS_1_B_0  0x71268
-#define _PLANE_WM_TRANS_2_A_0  0x70368
-#define _PLANE_WM_TRANS_2_B_0  0x71368
-#define _CUR_WM_TRANS_A_0  0x70168
-#define _CUR_WM_TRANS_B_0  0x71168
+#define _PLANE_WM_SAGV_1_A 0x70258
+#define _PLANE_WM_SAGV_1_B 0x71258
+#define _PLANE_WM_SAGV_2_A 0x70358
+#define _PLANE_WM_SAGV_2_B 0x71358
+#define _PLANE_WM_SAGV_TRANS_1_A   0x7025C
+#define _PLANE_WM_SAGV_TRANS_1_B   0x7125C
+#define _PLANE_WM_SAGV_TRANS_2_A   0x7035C
+#define _PLANE_WM_SAGV_TRANS_2_B   0x7135C
+#define _PLANE_WM_TRANS_1_A0x70268
+#define

[Intel-gfx] [CI 06/17] drm/i915/adl_p: Don't config MBUS and DBUF during display initialization

From: José Roberto de Souza 

Alderlake-P don't have programing sequences for MBUS or DBUF during
display initializaiton, instead it requires programing to those
registers during modeset because it to depend on the pipes left
enabled.

Bspec: 49213
Cc: Matt Roper 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Stanislav Lisovskiy 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 54c6d65011ee..ca3d31c318fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5245,6 +5245,9 @@ static void gen12_dbuf_slices_config(struct 
drm_i915_private *dev_priv)
 {
enum dbuf_slice slice;
 
+   if (IS_ALDERLAKE_P(dev_priv))
+   return;
+
for_each_dbuf_slice(dev_priv, slice)
intel_de_rmw(dev_priv, DBUF_CTL_S(slice),
 DBUF_TRACKER_STATE_SERVICE_MASK,
@@ -5256,6 +5259,9 @@ static void icl_mbus_init(struct drm_i915_private 
*dev_priv)
unsigned long abox_regs = INTEL_INFO(dev_priv)->abox_mask;
u32 mask, val, i;
 
+   if (IS_ALDERLAKE_P(dev_priv))
+   return;
+
mask = MBUS_ABOX_BT_CREDIT_POOL1_MASK |
MBUS_ABOX_BT_CREDIT_POOL2_MASK |
MBUS_ABOX_B_CREDIT_MASK |
-- 
2.31.1

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

[Intel-gfx] [CI 01/17] drm/i915/xelpd: Calculate VDSC RC parameters

From: Vandita Kulkarni 

Add methods to calculate rc parameters for all bpps, against the fixed
arrays that we already have for 8,10,12 valid o/p bpps, to cover RGB 444
formats.  Our hw doesn't support YUV compression yet.  The calculations
used here are from VESA C model for DSC 1.1

v2:
 - Checkpatch fixes

Cc: Manasi Navare 
Cc: Juha-Pekka Heikkil 
Signed-off-by: Vandita Kulkarni 
Signed-off-by: Mohammed Khajapasha 
Signed-off-by: Matt Roper 
Reviewed-by: Manasi Navare 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 97 ---
 1 file changed, 87 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index efc3184d8315..02e86d2be395 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -5,7 +5,7 @@
  * Author: Gaurav K Singh 
  * Manasi Navare 
  */
-
+#include 
 #include "i915_drv.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
@@ -373,12 +373,74 @@ static bool is_pipe_dsc(const struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static void
+calculate_rc_params(struct rc_parameters *rc,
+   struct drm_dsc_config *vdsc_cfg)
+{
+   int bpc = vdsc_cfg->bits_per_component;
+   int bpp = vdsc_cfg->bits_per_pixel >> 4;
+   int ofs_und6[] = { 0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, 
-12, -12, -12 };
+   int ofs_und8[] = { 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, 
-12, -12 };
+   int ofs_und12[] = { 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, 
-12, -12, -12 };
+   int ofs_und15[] = { 10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, 
-12, -12 };
+   int qp_bpc_modifier = (bpc - 8) * 2;
+   u32 res, buf_i;
+
+   if (vdsc_cfg->slice_height >= 8)
+   rc->first_line_bpg_offset =
+   12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height - 
8)), 100);
+   else
+   rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+
+   /* Our hw supports only 444 modes as of today */
+   if (bpp >= 12)
+   rc->initial_offset = 2048;
+   else if (bpp >= 10)
+   rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584), 
2);
+   else if (bpp >= 8)
+   rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+   else
+   rc->initial_offset = 6144;
+
+   /* initial_xmit_delay = rc_model_size/2/compression_bpp */
+   rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+
+   rc->flatness_min_qp = 3 + qp_bpc_modifier;
+   rc->flatness_max_qp = 12 + qp_bpc_modifier;
+
+   rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+   rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+
+   for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+   /* Calculate range_bgp_offset */
+   if (bpp <= 6) {
+   rc->rc_range_params[buf_i].range_bpg_offset = 
ofs_und6[buf_i];
+   } else if (bpp <= 8) {
+   res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
ofs_und6[buf_i])), 2);
+   rc->rc_range_params[buf_i].range_bpg_offset =
+   ofs_und6[buf_i] 
+ res;
+   } else if (bpp <= 12) {
+   rc->rc_range_params[buf_i].range_bpg_offset =
+   ofs_und8[buf_i];
+   } else if (bpp <= 15) {
+   res = DIV_ROUND_UP(((bpp - 12) * (ofs_und15[buf_i] - 
ofs_und12[buf_i])), 3);
+   rc->rc_range_params[buf_i].range_bpg_offset =
+   
ofs_und12[buf_i] + res;
+   } else {
+   rc->rc_range_params[buf_i].range_bpg_offset =
+   
ofs_und15[buf_i];
+   }
+   }
+}
+
 int intel_dsc_compute_params(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_dsc_config *vdsc_cfg = _config->dsc.config;
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
const struct rc_parameters *rc_params;
+   struct rc_parameters *rc = NULL;
u8 i = 0;
 
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
@@ -413,9 +475,24 @@ int intel_dsc_compute_params(struct intel_encoder *encoder,
vdsc_cfg->rc_buf_thresh[13] = 0x7D;
}
 
-   rc_params = get_rc_params(compressed_bpp, vdsc_cfg->bits_per_component);
-   if (!rc_params)
-   return -EINVAL;
+   /*
+* From XE_LPD onwards we supports compression bpps in steps of 1
+* upto uncompressed

[Intel-gfx] [CI 11/17] drm/i915/display: Replace dc3co_enabled with dc3co_exitline on intel_psr struct

From: Gwan-gyeong Mun 

It replaces dc3co_enabled with dc3co_exitline on intel_psr struct.  And
it saves dc3co_exitline, not dc3co_enabled, so we can use dc3co_exitline
without intel_crtc_state on other psr internal function like as
intel_psr_enable_source().

Cc: Ville Syrjälä 
Cc: José Roberto de Souza 
Cc: Anshuman Gupta 
Signed-off-by: Gwan-gyeong Mun 
Signed-off-by: Matt Roper 
Reviewed-by: Anshuman Gupta 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display_types.h |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c   | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9c0adfc60c6f..ce05475ad560 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1498,7 +1498,7 @@ struct intel_psr {
bool sink_not_reliable;
bool irq_aux_error;
u16 su_x_granularity;
-   bool dc3co_enabled;
+   u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
struct drm_dp_vsc_sdp vsc;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index acaf3d459821..5bafd0de6ad9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -638,7 +638,7 @@ static void tgl_dc3co_disable_work(struct work_struct *work)
 
 static void tgl_disallow_dc3co_on_psr2_exit(struct intel_dp *intel_dp)
 {
-   if (!intel_dp->psr.dc3co_enabled)
+   if (!intel_dp->psr.dc3co_exitline)
return;
 
cancel_delayed_work(_dp->psr.dc3co_work);
@@ -1010,7 +1010,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 
psr_irq_control(intel_dp);
 
-   if (crtc_state->dc3co_exitline) {
+   if (intel_dp->psr.dc3co_exitline) {
u32 val;
 
/*
@@ -1019,7 +1019,7 @@ static void intel_psr_enable_source(struct intel_dp 
*intel_dp,
 */
val = intel_de_read(dev_priv, EXITLINE(cpu_transcoder));
val &= ~EXITLINE_MASK;
-   val |= crtc_state->dc3co_exitline << EXITLINE_SHIFT;
+   val |= intel_dp->psr.dc3co_exitline << EXITLINE_SHIFT;
val |= EXITLINE_ENABLE;
intel_de_write(dev_priv, EXITLINE(cpu_transcoder), val);
}
@@ -1044,11 +1044,11 @@ static void intel_psr_enable_locked(struct intel_dp 
*intel_dp,
intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
intel_dp->psr.busy_frontbuffer_bits = 0;
intel_dp->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
-   intel_dp->psr.dc3co_enabled = !!crtc_state->dc3co_exitline;
intel_dp->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);
intel_dp->psr.dc3co_exit_delay = val;
+   intel_dp->psr.dc3co_exitline = crtc_state->dc3co_exitline;
intel_dp->psr.psr2_sel_fetch_enabled = 
crtc_state->enable_psr2_sel_fetch;
 
/*
@@ -1818,7 +1818,7 @@ tgl_dc3co_flush(struct intel_dp *intel_dp, unsigned int 
frontbuffer_bits,
 {
mutex_lock(_dp->psr.lock);
 
-   if (!intel_dp->psr.dc3co_enabled)
+   if (!intel_dp->psr.dc3co_exitline)
goto unlock;
 
if (!intel_dp->psr.psr2_enabled || !intel_dp->psr.active)
-- 
2.31.1

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

[Intel-gfx] [CI 04/17] drm/i915/adl_p: Setup ports/phys

From: Anusha Srivatsa 

The SoC has 6 DDI ports(DDI A,DDI B and DDI TC1-4.
The first two are connected to combo phys while
the rest are connected to TC phys.

Cc: Matt Roper 
Cc: Clinton Taylor 
Cc: Lucas De Marchi 
Cc: Swathi Dhanavanthri 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Imre Deak 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 47251b2bc8a4..953d363d9702 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3675,7 +3675,9 @@ bool intel_phy_is_combo(struct drm_i915_private 
*dev_priv, enum phy phy)
 
 bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
 {
-   if (IS_TIGERLAKE(dev_priv))
+   if (IS_ALDERLAKE_P(dev_priv))
+   return phy >= PHY_F && phy <= PHY_I;
+   else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
else if (IS_ICELAKE(dev_priv))
return phy >= PHY_C && phy <= PHY_F;
@@ -11251,7 +11253,14 @@ static void intel_setup_outputs(struct 
drm_i915_private *dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (IS_ALDERLAKE_S(dev_priv)) {
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   intel_ddi_init(dev_priv, PORT_A);
+   intel_ddi_init(dev_priv, PORT_B);
+   intel_ddi_init(dev_priv, PORT_TC1);
+   intel_ddi_init(dev_priv, PORT_TC2);
+   intel_ddi_init(dev_priv, PORT_TC3);
+   intel_ddi_init(dev_priv, PORT_TC4);
+   } else if (IS_ALDERLAKE_S(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_TC1);
intel_ddi_init(dev_priv, PORT_TC2);
-- 
2.31.1

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

[Intel-gfx] [CI 13/17] drm/i915/adl_p: Define and use ADL-P specific DP translation tables

From: Mika Kahola 

Define and use DP voltage swing and pre-emphasis translation tables
for ADL-P.

v2:
 - Update according to recent bspec updates; there are now separate
   tables for RBR/HBR and HBR2/HBR3.  (Anusha)

BSpec: 54956
Cc: Imre Deak 
Signed-off-by: Mika Kahola 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Clint Taylor 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  7 ++-
 .../drm/i915/display/intel_ddi_buf_trans.c| 53 +++
 .../drm/i915/display/intel_ddi_buf_trans.h|  4 ++
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 38a4f251b9c9..e0adb14ecd0d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -985,6 +985,8 @@ static u8 intel_ddi_dp_voltage_max(struct intel_dp 
*intel_dp,
if (DISPLAY_VER(dev_priv) >= 12) {
if (intel_phy_is_combo(dev_priv, phy))
tgl_get_combo_buf_trans(encoder, crtc_state, 
_entries);
+   else if (IS_ALDERLAKE_P(dev_priv))
+   adlp_get_dkl_buf_trans(encoder, crtc_state, _entries);
else
tgl_get_dkl_buf_trans(encoder, crtc_state, _entries);
} else if (DISPLAY_VER(dev_priv) == 11) {
@@ -1431,7 +1433,10 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder 
*encoder,
if (enc_to_dig_port(encoder)->tc_mode == TC_PORT_TBT_ALT)
return;
 
-   ddi_translations = tgl_get_dkl_buf_trans(encoder, crtc_state, 
_entries);
+   if (IS_ALDERLAKE_P(dev_priv))
+   ddi_translations = adlp_get_dkl_buf_trans(encoder, crtc_state, 
_entries);
+   else
+   ddi_translations = tgl_get_dkl_buf_trans(encoder, crtc_state, 
_entries);
 
if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
return;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index 7bcdd5c12028..ce5d5d13b7c1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -735,6 +735,34 @@ static const struct cnl_ddi_buf_trans 
rkl_combo_phy_ddi_translations_dp_hbr2_hbr
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900   900  0.0   */
 };
 
+static const struct tgl_dkl_phy_ddi_buf_trans adlp_dkl_phy_dp_ddi_trans_hbr[] 
= {
+   /* VS   pre-emp Non-trans mVPre-emph dB */
+   { 0x7, 0x0, 0x01 }, /* 00   400mV   0 dB */
+   { 0x5, 0x0, 0x06 }, /* 01   400mV   3.5 dB */
+   { 0x2, 0x0, 0x0B }, /* 02   400mV   6 dB */
+   { 0x0, 0x0, 0x17 }, /* 03   400mV   9.5 dB */
+   { 0x5, 0x0, 0x00 }, /* 10   600mV   0 dB */
+   { 0x2, 0x0, 0x08 }, /* 11   600mV   3.5 dB */
+   { 0x0, 0x0, 0x14 }, /* 12   600mV   6 dB */
+   { 0x2, 0x0, 0x00 }, /* 20   800mV   0 dB */
+   { 0x0, 0x0, 0x0B }, /* 21   800mV   3.5 dB */
+   { 0x0, 0x0, 0x00 }, /* 30   1200mV  0 dB */
+};
+
+static const struct tgl_dkl_phy_ddi_buf_trans 
adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3[] = {
+   /* VS   pre-emp Non-trans mVPre-emph dB */
+   { 0x7, 0x0, 0x00 }, /* 00   400mV   0 dB */
+   { 0x5, 0x0, 0x04 }, /* 01   400mV   3.5 dB */
+   { 0x2, 0x0, 0x0A }, /* 02   400mV   6 dB */
+   { 0x0, 0x0, 0x18 }, /* 03   400mV   9.5 dB */
+   { 0x5, 0x0, 0x00 }, /* 10   600mV   0 dB */
+   { 0x2, 0x0, 0x06 }, /* 11   600mV   3.5 dB */
+   { 0x0, 0x0, 0x14 }, /* 12   600mV   6 dB */
+   { 0x2, 0x0, 0x00 }, /* 20   800mV   0 dB */
+   { 0x0, 0x0, 0x09 }, /* 21   800mV   3.5 dB */
+   { 0x0, 0x0, 0x00 }, /* 30   1200mV  0 dB */
+};
+
 bool is_hobl_buf_trans(const struct cnl_ddi_buf_trans *table)
 {
return table == tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
@@ -1348,6 +1376,31 @@ tgl_get_dkl_buf_trans(struct intel_encoder *encoder,
return tgl_get_dkl_buf_trans_dp(encoder, crtc_state, n_entries);
 }
 
+static const struct tgl_dkl_phy_ddi_buf_trans *
+adlp_get_dkl_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+   if (crtc_state->port_clock > 27) {
+   *n_entries = ARRAY_SIZE(adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3);
+   return adlp_dkl_phy_dp_ddi_trans_hbr;
+   }
+
+   *n_entries =

[Intel-gfx] [CI 14/17] drm/i915/adl_p: Add PLL Support

From: Anusha Srivatsa 

The clocks in ALD_P is similar to that of TGL.
The combo PLLs  use the same DPLL0, DPLL1 and TBT_PLL.

This patch adds the helper function intel_mg_pll_enable_reg()
which is similar to intel_combo_pll_enable_reg() for being lookup
place for PLL_ENABLE register in combo phy cases.

Bspec: 55409,55316
Cc: Matt Roper 
Cc: Clinton Taylor 
Cc: Lucas De Marchi 
Cc: José Roberto de Souza 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Clint Taylor 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 69 ++-
 drivers/gpu/drm/i915/i915_reg.h   |  8 +++
 2 files changed, 60 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 18bfe8d09277..71ac57670043 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -149,6 +149,16 @@ void assert_shared_dpll(struct drm_i915_private *dev_priv,
pll->info->name, onoff(state), onoff(cur_state));
 }
 
+static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
+{
+   return TC_PORT_1 + id - DPLL_ID_ICL_MGPLL1;
+}
+
+enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port tc_port)
+{
+   return tc_port - TC_PORT_1 + DPLL_ID_ICL_MGPLL1;
+}
+
 static i915_reg_t
 intel_combo_pll_enable_reg(struct drm_i915_private *i915,
   struct intel_shared_dpll *pll)
@@ -161,6 +171,19 @@ intel_combo_pll_enable_reg(struct drm_i915_private *i915,
return CNL_DPLL_ENABLE(pll->info->id);
 }
 
+static i915_reg_t
+intel_tc_pll_enable_reg(struct drm_i915_private *i915,
+   struct intel_shared_dpll *pll)
+{
+   const enum intel_dpll_id id = pll->info->id;
+   enum tc_port tc_port = icl_pll_id_to_tc_port(id);
+
+   if (IS_ALDERLAKE_P(i915))
+   return ADLP_PORTTC_PLL_ENABLE(tc_port);
+
+   return MG_PLL_ENABLE(tc_port);
+}
+
 /**
  * intel_prepare_shared_dpll - call a dpll's prepare hook
  * @crtc_state: CRTC, and its state, which has a shared dpll
@@ -3120,16 +3143,6 @@ static void icl_calc_dpll_state(struct drm_i915_private 
*i915,
pll_state->cfgcr1 |= DPLL_CFGCR1_CENTRAL_FREQ_8400;
 }
 
-static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
-{
-   return id - DPLL_ID_ICL_MGPLL1;
-}
-
-enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port tc_port)
-{
-   return tc_port + DPLL_ID_ICL_MGPLL1;
-}
-
 static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
 u32 *target_dco_khz,
 struct intel_dpll_hw_state *state,
@@ -3728,12 +3741,14 @@ static bool mg_pll_get_hw_state(struct drm_i915_private 
*dev_priv,
bool ret = false;
u32 val;
 
+   i915_reg_t enable_reg = intel_tc_pll_enable_reg(dev_priv, pll);
+
wakeref = intel_display_power_get_if_enabled(dev_priv,
 POWER_DOMAIN_DISPLAY_CORE);
if (!wakeref)
return false;
 
-   val = intel_de_read(dev_priv, MG_PLL_ENABLE(tc_port));
+   val = intel_de_read(dev_priv, enable_reg);
if (!(val & PLL_ENABLE))
goto out;
 
@@ -3797,7 +3812,7 @@ static bool dkl_pll_get_hw_state(struct drm_i915_private 
*dev_priv,
if (!wakeref)
return false;
 
-   val = intel_de_read(dev_priv, MG_PLL_ENABLE(tc_port));
+   val = intel_de_read(dev_priv, intel_tc_pll_enable_reg(dev_priv, pll));
if (!(val & PLL_ENABLE))
goto out;
 
@@ -4169,8 +4184,7 @@ static void tbt_pll_enable(struct drm_i915_private 
*dev_priv,
 static void mg_pll_enable(struct drm_i915_private *dev_priv,
  struct intel_shared_dpll *pll)
 {
-   i915_reg_t enable_reg =
-   MG_PLL_ENABLE(icl_pll_id_to_tc_port(pll->info->id));
+   i915_reg_t enable_reg = intel_tc_pll_enable_reg(dev_priv, pll);
 
icl_pll_power_enable(dev_priv, pll, enable_reg);
 
@@ -4249,8 +4263,7 @@ static void tbt_pll_disable(struct drm_i915_private 
*dev_priv,
 static void mg_pll_disable(struct drm_i915_private *dev_priv,
   struct intel_shared_dpll *pll)
 {
-   i915_reg_t enable_reg =
-   MG_PLL_ENABLE(icl_pll_id_to_tc_port(pll->info->id));
+   i915_reg_t enable_reg = intel_tc_pll_enable_reg(dev_priv, pll);
 
icl_pll_disable(dev_priv, pll, enable_reg);
 }
@@ -4416,6 +4429,26 @@ static const struct intel_dpll_mgr adls_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
 };
 
+static const struct dpll_info adlp_plls[] = {
+   { "DPLL 0", _pll_funcs, DPLL_ID_ICL_DPLL0,  0 },
+   { "DPLL 1", _pll_funcs, DPLL_ID_ICL_DPLL1,  0 },
+   { "TBT PLL",  _pll_funcs, DPLL_ID_ICL_TBTPLL, 0 },
+   { "TC PLL 1", _pll_funcs, DPLL_ID_ICL_MGPLL1, 0

[Intel-gfx] [CI 16/17] drm/i915/adlp: Add PIPE_MISC2 programming

From: Anusha Srivatsa 

When scalers are enabled, we need to program underrun
bubble counter to 0x50 to avoid Soft Pipe A underruns.
Make sure other bits dont get overwritten.

Cc: Matt Roper 
Cc: Clint Taylor 
Cc: José Roberto de Souza 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: Clint Taylor 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display.c | 21 
 drivers/gpu/drm/i915/i915_reg.h  |  7 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index adc001351ad3..87a3158c042a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5716,8 +5716,12 @@ static void hsw_set_pipeconf(const struct 
intel_crtc_state *crtc_state)
 static void bdw_set_pipemisc(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+   const struct intel_crtc_scaler_state *scaler_state =
+   _state->scaler_state;
+
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
u32 val = 0;
+   int i;
 
switch (crtc_state->pipe_bpp) {
case 18:
@@ -5756,6 +5760,23 @@ static void bdw_set_pipemisc(const struct 
intel_crtc_state *crtc_state)
if (DISPLAY_VER(dev_priv) >= 12)
val |= PIPEMISC_PIXEL_ROUNDING_TRUNC;
 
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   bool scaler_in_use = false;
+
+   for (i = 0; i < crtc->num_scalers; i++) {
+   if (!scaler_state->scalers[i].in_use)
+   continue;
+
+   scaler_in_use = true;
+   break;
+   }
+
+   intel_de_rmw(dev_priv, PIPE_MISC2(crtc->pipe),
+PIPE_MISC2_UNDERRUN_BUBBLE_COUNTER_MASK,
+scaler_in_use ? 
PIPE_MISC2_BUBBLE_COUNTER_SCALER_EN :
+PIPE_MISC2_BUBBLE_COUNTER_SCALER_DIS);
+   }
+
intel_de_write(dev_priv, PIPEMISC(crtc->pipe), val);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2e4f420a0c9a..1d892b0f3067 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6161,6 +6161,13 @@ enum {
 #define   PIPEMISC_DITHER_TYPE_SP  (0 << 2)
 #define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
 
+#define _PIPE_MISC2_A  0x7002C
+#define _PIPE_MISC2_B  0x7102C
+#define   PIPE_MISC2_BUBBLE_COUNTER_SCALER_EN  (0x50 << 24)
+#define   PIPE_MISC2_BUBBLE_COUNTER_SCALER_DIS (0x14 << 24)
+#define   PIPE_MISC2_UNDERRUN_BUBBLE_COUNTER_MASK  (0xff << 24)
+#define PIPE_MISC2(pipe)   
_MMIO_PIPE2(pipe, _PIPE_MISC2_A)
+
 /* Skylake+ pipe bottom (background) color */
 #define _SKL_BOTTOM_COLOR_A0x70034
 #define   SKL_BOTTOM_COLOR_GAMMA_ENABLE(1 << 31)
-- 
2.31.1

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

[Intel-gfx] [CI 17/17] drm/i915/adl_p: Update memory bandwidth parameters

From: Anusha Srivatsa 

ADL_P has same memory characteristics as ADL_S platform.

Bspec: 64631

Cc: José Roberto de Souza 
Cc: Clint Taylor 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Clinton Taylor 
Signed-off-by: Matt Roper 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_bw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a35435083b60..3a1ba52266a7 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -267,7 +267,7 @@ void intel_bw_init_hw(struct drm_i915_private *dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (IS_ALDERLAKE_S(dev_priv))
+   if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
icl_get_bw_info(dev_priv, _sa_info);
else if (IS_ROCKETLAKE(dev_priv))
icl_get_bw_info(dev_priv, _sa_info);
-- 
2.31.1

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

[Intel-gfx] [CI 00/17] ADL-P: more reviewed patches

Now just a few remaining from the original batch of patches to support
ADL-P.

Anusha Srivatsa (4):
  drm/i915/adl_p: Setup ports/phys
  drm/i915/adl_p: Add PLL Support
  drm/i915/adlp: Add PIPE_MISC2 programming
  drm/i915/adl_p: Update memory bandwidth parameters

Gwan-gyeong Mun (2):
  drm/i915/display: Replace dc3co_enabled with dc3co_exitline on
intel_psr struct
  drm/i915/display: Add PSR interrupt error check function

Imre Deak (1):
  drm/i915/adl_p: Program DP/HDMI link rate to DDI_BUF_CTL

José Roberto de Souza (2):
  drm/i915/adl_p: Implement TC sequences
  drm/i915/adl_p: Don't config MBUS and DBUF during display
initialization

Matt Roper (1):
  drm/i915/adl_p: Add dedicated SAGV watermarks

Mika Kahola (2):
  drm/i915/adl_p: Tx escape clock with DSI
  drm/i915/adl_p: Define and use ADL-P specific DP translation tables

Vandita Kulkarni (4):
  drm/i915/xelpd: Calculate VDSC RC parameters
  drm/i915/xelpd: Add rc_qp_table for rcparams calculation
  drm/i915/adl_p: Add ddb allocation support
  drm/i915/adl_p: MBUS programming

Ville Syrjälä (1):
  drm/i915: Introduce MBUS relative dbuf offsets

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/icl_dsi.c|  21 +-
 drivers/gpu/drm/i915/display/intel_atomic.c   |  20 ++
 drivers/gpu/drm/i915/display/intel_atomic.h   |   1 +
 drivers/gpu/drm/i915/display/intel_bw.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |  43 ++-
 .../drm/i915/display/intel_ddi_buf_trans.c|  53 +++
 .../drm/i915/display/intel_ddi_buf_trans.h|   4 +
 drivers/gpu/drm/i915/display/intel_display.c  |  69 +++-
 .../drm/i915/display/intel_display_power.c|   6 +
 .../drm/i915/display/intel_display_types.h|   2 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  69 +++-
 drivers/gpu/drm/i915/display/intel_psr.c  |  55 ++--
 .../gpu/drm/i915/display/intel_qp_tables.c| 309 ++
 .../gpu/drm/i915/display/intel_qp_tables.h|  14 +
 drivers/gpu/drm/i915/display/intel_tc.c   | 132 +++-
 drivers/gpu/drm/i915/display/intel_vdsc.c | 105 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_reg.h   | 124 +--
 drivers/gpu/drm/i915/intel_pm.c   | 303 -
 drivers/gpu/drm/i915/intel_pm.h   |   2 +-
 21 files changed, 1231 insertions(+), 106 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_qp_tables.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_qp_tables.h

-- 
2.31.1

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

[Intel-gfx] ✗ Fi.CI.DOCS: warning for GuC submission / DRM scheduler integration plan + new uAPI (rev2)

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI (rev2)
URL   : https://patchwork.freedesktop.org/series/89840/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
/home/cidrm/kernel/Documentation/gpu/rfc/i915_scheduler.rst:43: WARNING: 
Unexpected indentation.


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC submission / DRM scheduler integration plan + new uAPI (rev2)

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI (rev2)
URL   : https://patchwork.freedesktop.org/series/89840/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fe3698660450 drm/doc/rfc: i915 GuC submission / DRM scheduler
-:30: WARNING:BAD_SIGN_OFF: Duplicate signature
#30: 
Cc: Jason Ekstrand 

-:35: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#35: 
new file mode 100644

-:40: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#40: FILE: Documentation/gpu/rfc/i915_scheduler.rst:1:
+=

-:65: ERROR:TRAILING_WHITESPACE: trailing whitespace
#65: FILE: Documentation/gpu/rfc/i915_scheduler.rst:26:
+^I  which configures a slot with N contexts $

total: 1 errors, 3 warnings, 0 checks, 92 lines checked
011aea469596 drm/doc/rfc: i915 new parallel submission uAPI plan
-:23: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#23: 
new file mode 100644

-:28: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#28: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:1:
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */

-:51: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#51: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:24:
+ * inteface.


-:152: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#152: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:125:
+#define I915_PARALLEL_IMPLICT_BONDS(1<<0)
  ^

-:160: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#160: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:133:
+#define I915_PARALLEL_NO_PREEMPT_MID_BATCH (1<<1)
  ^

-:170: WARNING:PREFER_DEFINED_ATTRIBUTE_MACRO: Prefer __packed over 
__attribute__((packed))
#170: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:143:
+} __attribute__ ((packed));

-:184: WARNING:TYPO_SPELLING: 'explictly' may be misspelled - perhaps 
'explicitly'?
#184: FILE: Documentation/gpu/rfc/i915_scheduler.rst:88:
+contexts in parallel with the GuC the context must be explictly registered with
   ^

total: 0 errors, 5 warnings, 2 checks, 200 lines checked


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

[Intel-gfx] [RFC 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler

Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.

v2:
 (Daniel Vetter)
  - Expand explaination of why bonding isn't supported for GuC
submission
  - CC some of the DRM scheduler maintainers
  - Add priority inheritance / boosting use case
  - Add reasoning for removing in order assumptions
 (Daniel Stone)
  - Add links to priority spec

Cc: Christian König 
Cc: Luben Tuikov 
Cc: Alex Deucher 
Cc: Steven Price 
Cc: Jon Bloomfield 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matthew Brost 
---
 Documentation/gpu/rfc/i915_scheduler.rst | 85 
 Documentation/gpu/rfc/index.rst  |  4 ++
 2 files changed, 89 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst

diff --git a/Documentation/gpu/rfc/i915_scheduler.rst 
b/Documentation/gpu/rfc/i915_scheduler.rst
new file mode 100644
index ..7faa46cde088
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -0,0 +1,85 @@
+=
+I915 GuC Submission/DRM Scheduler Section
+=
+
+Upstream plan
+=
+For upstream the overall plan for landing GuC submission and integrating the
+i915 with the DRM scheduler is:
+
+* Merge basic GuC submission
+   * Basic submission support for all gen11+ platforms
+   * Not enabled by default on any current platforms but can be enabled via
+ modparam enable_guc
+   * Lots of rework will need to be done to integrate with DRM scheduler so
+ no need to nit pick everything in the code, it just should be
+ functional, no major coding style / layering errors, and not regress
+ execlists
+   * Update IGTs / selftests as needed to work with GuC submission
+   * Enable CI on supported platforms for a baseline
+   * Rework / get CI heathly for GuC submission in place as needed
+* Merge new parallel submission uAPI
+   * Bonding uAPI completely incompatible with GuC submission, plus it has
+ severe design issues in general, which is why we want to retire it no
+ matter what
+   * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step
+ which configures a slot with N contexts 
+   * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
+ a slot in a single execbuf IOCTL and the batches run on the GPU in
+ paralllel
+   * Initially only for GuC submission but execlists can be supported if
+ needed
+* Convert the i915 to use the DRM scheduler
+   * GuC submission backend fully integrated with DRM scheduler
+   * All request queues removed from backend (e.g. all backpressure
+ handled in DRM scheduler)
+   * Resets / cancels hook in DRM scheduler
+   * Watchdog hooks into DRM scheduler
+   * Lots of complexity of the GuC backend can be pulled out once
+ integrated with DRM scheduler (e.g. state machine gets
+ simplier, locking gets simplier, etc...)
+   * Execlist backend will do the minimum required to hook in the DRM
+ scheduler so it can live next to the fully integrated GuC backend
+   * Legacy interface
+   * Features like timeslicing / preemption / virtual engines would
+ be difficult to integrate with the DRM scheduler and these
+ features are not required for GuC submission as the GuC does
+ these things for us
+   * ROI low on fully integrating into DRM scheduler
+   * Fully integrating would add lots of complexity to DRM
+ scheduler
+   * Port i915 priority inheritance / boosting feature in DRM scheduler
+   * Used for i915 page flip, may be useful to other DRM drivers as
+ well
+   * Will be an optional feature in the DRM scheduler
+   * Remove in-order completion assumptions from DRM scheduler
+   * Even when using the DRM scheduler the backends will handle
+ preemption, timeslicing, etc... so it is possible for jobs to
+ finish out of order
+   * Pull out i915 priority levels and use DRM priority levels
+   * Optimize DRM scheduler as needed
+
+New uAPI for basic GuC submission
+=
+No major changes are required to the uAPI for basic GuC submission. The only
+change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
+This attribute indicates the 2k i915 user priority levels are statically mapped
+into 3 levels as follows:
+
+* -1k to -1 Low priority
+* 0 Medium priority
+* 1 to 1k High priority
+
+This is needed because the GuC only has 4 priority bands. The highest priority
+band is reserved with the

[Intel-gfx] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

Add entry fpr i915 new parallel submission uAPI plan.

v2:
 (Daniel Vetter):
  - Expand logical order explaination
  - Add dummy header
  - Only allow N BBs in execbuf IOCTL
  - Configure parallel submission per slot not per gem context

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
---
 Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
 Documentation/gpu/rfc/i915_scheduler.rst  |  53 ++-
 2 files changed, 196 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8c64b983ccad
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,144 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/*
+ * i915_context_engines_parallel_submit:
+ *
+ * Setup a slot to allow multiple BBs to be submitted in a single execbuf 
IOCTL.
+ * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
+ * hardware contexts are created internally in the i915 run these BBs. Once a
+ * slot is configured for N BBs only N BBs can be submitted in each execbuf
+ * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
+ * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are based 
on
+ * the slots configuration).
+ *
+ * Their are two currently defined ways to control the placement of the
+ * hardware contexts on physical engines: default behavior (no flags) and
+ * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
+ * future as new hardware / use cases arise. Details of how to use this
+ * interface below above the flags.
+ *
+ * Returns -EINVAL if hardware context placement configuration invalid or if 
the
+ * placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ */
+struct i915_context_engines_parallel_submit {
+   struct i915_user_extension base;
+
+   __u16 engine_index; /* slot for parallel engine */
+   __u16 width;/* number of contexts per parallel engine */
+   __u16 num_siblings; /* number of siblings per context */
+   __u16 mbz16;
+/*
+ * Default placement behvavior (currently unsupported):
+ *
+ * Rather than restricting parallel submission to a single class with a
+ * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode 
that
+ * enables parallel submission across multiple engine classes. In this case 
each
+ * context's logical engine mask indicates where that context can placed. It is
+ * implied in this mode that all contexts have mutual exclusive placement (e.g.
+ * if one context is running CS0 no other contexts can run on CS0).
+ *
+ * Example 1 pseudo code:
+ * CSX[Y] = engine class X, logical instance Y
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS0[0],CS0[1],CS1[0],CS1[1])
+ *
+ * Results in the following valid placements:
+ * CS0[0], CS1[0]
+ * CS0[0], CS1[1]
+ * CS0[1], CS1[0]
+ * CS0[1], CS1[1]
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS0[0], CS0[1]
+ * VE[1] = CS1[0], CS1[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=3,
+ * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[0], CS[2]
+ * CS[1], CS[0]
+ * CS[1], CS[2]
+ * CS[2], CS[0]
+ * CS[2], CS[1]
+ *
+ *
+ * This can also be though of as 2 virtual engines:
+ * VE[0] = CS[0], CS[1], CS[2]
+ * VE[1] = CS[0], CS[1], CS[2]
+
+ * This enables a use case where all engines are created equally, we don't care
+ * where they are scheduled, we just want a certain number of resources, for
+ * those resources to be scheduled in parallel, and possibly across multiple
+ * engine classes.
+ */
+
+/*
+ * I915_PARALLEL_IMPLICT_BONDS - Create implict bonds between each context.
+ * Each context must have the same number sibling and bonds are implictly 
create
+ * of the siblings.
+ *
+ * All of the below examples are in logical space.
+ *
+ * Example 1 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=1,
+ * engines=CS[0],CS[1], flags=I915_PARALLEL_IMPLICT_BONDS)
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ *
+ *

[Intel-gfx] [RFC 0/2] GuC submission / DRM scheduler integration plan + new uAPI

Subject and patches say it all.

v2: Address comments, patches has details of changes

Signed-off-by: Matthew Brost 

Matthew Brost (2):
  drm/doc/rfc: i915 GuC submission / DRM scheduler
  drm/doc/rfc: i915 new parallel submission uAPI plan

 Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
 Documentation/gpu/rfc/i915_scheduler.rst  | 136 +
 Documentation/gpu/rfc/index.rst   |   4 +
 3 files changed, 284 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
 create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst

-- 
2.28.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Rename all CSR references to DMC (rev5)

== Series Details ==

Series: Rename all CSR references to DMC (rev5)
URL   : https://patchwork.freedesktop.org/series/90043/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10100 -> Patchwork_20149


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_20149 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20149, 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_20149/index.html

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-kefka:   [INCOMPLETE][1] ([i915#2782] / [i915#2940]) -> 
[DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@gem_busy@busy@all:
- fi-bsw-nick:[PASS][4] -> [FAIL][5] ([i915#3457]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_busy@b...@all.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-nick/igt@gem_busy@b...@all.html

  * igt@gem_exec_fence@basic-await@bcs0:
- fi-bsw-n3050:   [PASS][6] -> [FAIL][7] ([i915#3457]) +2 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html

  * igt@gem_wait@busy@all:
- fi-bsw-nick:[PASS][8] -> [FAIL][9] ([i915#3177] / [i915#3457])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_wait@b...@all.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-nick/igt@gem_wait@b...@all.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   NOTRUN -> [DMESG-FAIL][10] ([i915#3457])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-pnv-d510:[PASS][11] -> [FAIL][12] ([i915#53]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-pnv-d510/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-pnv-d510/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-elk-e7500:   [PASS][13] -> [FAIL][14] ([i915#53])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-kefka:   [PASS][15] -> [FAIL][16] ([i915#53])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@rcs0:
- fi-elk-e7500:   [FAIL][17] ([i915#3457]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-kefka:   [FAIL][19] ([i915#3457]) -> [PASS][20] +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20149/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-bsw-n3050:   [FAIL][21] ([i915#3457]) -> [PASS][22] +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vcs0.html
   [22]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Rename all CSR references to DMC (rev5)

== Series Details ==

Series: Rename all CSR references to DMC (rev5)
URL   : https://patchwork.freedesktop.org/series/90043/
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_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1203:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./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' -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Rename all CSR references to DMC (rev5)

== Series Details ==

Series: Rename all CSR references to DMC (rev5)
URL   : https://patchwork.freedesktop.org/series/90043/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
c95595fe6606 drm/i915/dmc: s/intel_csr/intel_dmc
dcf0abc59e2e drm/i915/dmc: s/HAS_CSR/HAS_DMC
533a65622dfe drm/i915/dmc: Rename macro names containing csr
cf0a044aa3a8 drm/i915/dmc: Rename functions names having "csr"
7ffe49e365bd drm/i915/dmc: s/intel_csr.c/intel_dmc.c and 
s/intel_csr.h/intel_dmc.h
-:113: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#113: 
rename from drivers/gpu/drm/i915/display/intel_csr.c

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


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

[Intel-gfx] [CI 1/5] drm/i915/dmc: s/intel_csr/intel_dmc

No functional change.

v2: Chchpatch fixes.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 170 +-
 .../drm/i915/display/intel_display_debugfs.c  |  14 +-
 .../drm/i915/display/intel_display_power.c|  52 +++---
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   8 +-
 6 files changed, 125 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 26a922d34263..a22339ebdffd 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -312,7 +312,7 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
  */
 void intel_csr_load_program(struct drm_i915_private *dev_priv)
 {
-   u32 *payload = dev_priv->csr.dmc_payload;
+   u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
 
if (!HAS_CSR(dev_priv)) {
@@ -321,13 +321,13 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
return;
}
 
-   if (!dev_priv->csr.dmc_payload) {
+   if (!dev_priv->dmc.dmc_payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
 
-   fw_size = dev_priv->csr.dmc_fw_size;
+   fw_size = dev_priv->dmc.dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
 
preempt_disable();
@@ -338,12 +338,12 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
 
preempt_enable();
 
-   for (i = 0; i < dev_priv->csr.mmio_count; i++) {
-   intel_de_write(dev_priv, dev_priv->csr.mmioaddr[i],
-  dev_priv->csr.mmiodata[i]);
+   for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
+   intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
+  dev_priv->dmc.mmiodata[i]);
}
 
-   dev_priv->csr.dc_state = 0;
+   dev_priv->dmc.dc_state = 0;
 
gen9_set_dc_state_debugmask(dev_priv);
 }
@@ -392,7 +392,7 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
 }
 
-static u32 parse_csr_fw_dmc(struct intel_csr *csr,
+static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size)
 {
@@ -401,8 +401,8 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
u32 mmio_count, mmio_count_max;
u8 *payload;
 
-   BUILD_BUG_ON(ARRAY_SIZE(csr->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(csr->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
 
/*
 * Check if we can access common fields, we will checkc again below
@@ -464,10 +464,10 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
  mmioaddr[i]);
return 0;
}
-   csr->mmioaddr[i] = _MMIO(mmioaddr[i]);
-   csr->mmiodata[i] = mmiodata[i];
+   dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
+   dmc->mmiodata[i] = mmiodata[i];
}
-   csr->mmio_count = mmio_count;
+   dmc->mmio_count = mmio_count;
 
rem_size -= header_len_bytes;
 
@@ -476,20 +476,20 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
if (rem_size < payload_size)
goto error_truncated;
 
-   if (payload_size > csr->max_fw_size) {
+   if (payload_size > dmc->max_fw_size) {
DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
return 0;
}
-   csr->dmc_fw_size = dmc_header->fw_size;
+   dmc->dmc_fw_size = dmc_header->fw_size;
 
-   csr->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
-   if (!csr->dmc_payload) {
+   dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
+   if (!dmc->dmc_payload) {
DRM_ERROR("Memory allocation failed for dmc payload\n");
return 0;
}
 
payload = (u8 *)(dmc_header) + header_len_bytes;
-   memcpy(csr->dmc_payload, payload, payload_size);
+   memcpy(dmc->dmc_payload, payload, payload_size);
 
return header_len_bytes + payload_size;
 
@@ -499,7 +499,7 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
 }
 
 static u32
-parse_csr_fw_package(struct intel_csr *csr,
+parse_csr_fw_package(struct intel_dmc *dmc,
 const struct intel_package_header *package_header,
 const struct stepping_info *si,
 size_t rem_size)
@@ -558,7 +558,7 @@ parse_csr_fw_package(struct intel_csr *csr,
 }
 
 /* Return number of bytes parsed

[Intel-gfx] [CI 0/5] Rename all CSR references to DMC

Currently in our driver we use both CSR and DMC interchangeably.
Even though the spec mentions both, we do not follow that convention
in the driver.

Renaming all references of CSR to just be DMC. This hopefully makes
the driver of this part a litlle less confusing.

Suggested-by: Jani Nikula 

Acked-by: Jani Nikula 

Anusha Srivatsa (5):
  drm/i915/dmc: s/intel_csr/intel_dmc
  drm/i915/dmc: s/HAS_CSR/HAS_DMC
  drm/i915/dmc: Rename macro names containing csr
  drm/i915/dmc: Rename functions names having "csr"
  drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h

 Documentation/gpu/i915.rst|  12 +-
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/display/intel_csr.h  |  21 --
 drivers/gpu/drm/i915/display/intel_display.c  |  16 +-
 .../drm/i915/display/intel_display_debugfs.c  |  30 +-
 .../drm/i915/display/intel_display_power.c|  82 ++---
 .../i915/display/{intel_csr.c => intel_dmc.c} | 333 +-
 drivers/gpu/drm/i915/display/intel_dmc.h  |  21 ++
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.c   |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  12 +-
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/i915_reg.h   |  28 +-
 drivers/gpu/drm/i915/intel_device_info.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   2 +-
 16 files changed, 290 insertions(+), 291 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/display/intel_csr.h
 rename drivers/gpu/drm/i915/display/{intel_csr.c => intel_dmc.c} (66%)
 create mode 100644 drivers/gpu/drm/i915/display/intel_dmc.h

-- 
2.25.0

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

[Intel-gfx] [CI 4/5] drm/i915/dmc: Rename functions names having "csr"

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 64 +--
 drivers/gpu/drm/i915/display/intel_csr.h  | 10 +--
 drivers/gpu/drm/i915/display/intel_display.c  | 14 ++--
 .../drm/i915/display/intel_display_power.c| 14 ++--
 drivers/gpu/drm/i915/i915_drv.c   |  6 +-
 5 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index f2124796ce77..ae1dfafaff9a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -302,14 +302,14 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
 }
 
 /**
- * intel_csr_load_program() - write the firmware from memory to register.
+ * intel_dmc_load_program() - write the firmware from memory to register.
  * @dev_priv: i915 drm device.
  *
- * CSR firmware is read from a .bin file and kept in internal memory one time.
+ * DMC firmware is read from a .bin file and kept in internal memory one time.
  * Everytime display comes back from low power state this function is called to
  * copy the firmware from internal memory to registers.
  */
-void intel_csr_load_program(struct drm_i915_private *dev_priv)
+void intel_dmc_load_program(struct drm_i915_private *dev_priv)
 {
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
@@ -391,9 +391,9 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
 }
 
-static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
-   const struct intel_dmc_header_base *dmc_header,
-   size_t rem_size)
+static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
+  const struct intel_dmc_header_base *dmc_header,
+  size_t rem_size)
 {
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
@@ -498,7 +498,7 @@ static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
 }
 
 static u32
-parse_csr_fw_package(struct intel_dmc *dmc,
+parse_dmc_fw_package(struct intel_dmc *dmc,
 const struct intel_package_header *package_header,
 const struct stepping_info *si,
 size_t rem_size)
@@ -557,7 +557,7 @@ parse_csr_fw_package(struct intel_dmc *dmc,
 }
 
 /* Return number of bytes parsed or 0 on error */
-static u32 parse_csr_fw_css(struct intel_dmc *dmc,
+static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
struct intel_css_header *css_header,
size_t rem_size)
 {
@@ -590,7 +590,7 @@ static u32 parse_csr_fw_css(struct intel_dmc *dmc,
return sizeof(struct intel_css_header);
 }
 
-static void parse_csr_fw(struct drm_i915_private *dev_priv,
+static void parse_dmc_fw(struct drm_i915_private *dev_priv,
 const struct firmware *fw)
 {
struct intel_css_header *css_header;
@@ -606,7 +606,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,
 
/* Extract CSS Header information */
css_header = (struct intel_css_header *)fw->data;
-   r = parse_csr_fw_css(dmc, css_header, fw->size);
+   r = parse_dmc_fw_css(dmc, css_header, fw->size);
if (!r)
return;
 
@@ -614,7 +614,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,
 
/* Extract Package Header information */
package_header = (struct intel_package_header *)>data[readcount];
-   r = parse_csr_fw_package(dmc, package_header, si, fw->size - readcount);
+   r = parse_dmc_fw_package(dmc, package_header, si, fw->size - readcount);
if (!r)
return;
 
@@ -622,17 +622,17 @@ static void parse_csr_fw(struct drm_i915_private 
*dev_priv,
 
/* Extract dmc_header information */
dmc_header = (struct intel_dmc_header_base *)>data[readcount];
-   parse_csr_fw_dmc(dmc, dmc_header, fw->size - readcount);
+   parse_dmc_fw_header(dmc, dmc_header, fw->size - readcount);
 }
 
-static void intel_csr_runtime_pm_get(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_get(struct drm_i915_private *dev_priv)
 {
drm_WARN_ON(_priv->drm, dev_priv->dmc.wakeref);
dev_priv->dmc.wakeref =
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 }
 
-static void intel_csr_runtime_pm_put(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_put(struct drm_i915_private *dev_priv)
 {
intel_wakeref_t wakeref __maybe_unused =
fetch_and_zero(_priv->dmc.wakeref);
@@ -640,7 +640,7 @@ static void intel_csr_runtime_pm_put(struct 
drm_i915_private *dev_priv)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
 }
 
-static void csr_load_work_fn(struct work_struct *work)
+static void dmc_load_work_fn(struct

[Intel-gfx] [CI 5/5] drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h

Finally, rename the header and source file from csr to dmc.

v2: Add file rename in Documentation.
- Place headers in orders. (Jani)

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 Documentation/gpu/i915.rst   | 12 ++--
 drivers/gpu/drm/i915/Makefile|  2 +-
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display_debugfs.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display_power.c   |  2 +-
 .../drm/i915/display/{intel_csr.c => intel_dmc.c}|  4 ++--
 .../drm/i915/display/{intel_csr.h => intel_dmc.h}|  6 +++---
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
 9 files changed, 17 insertions(+), 17 deletions(-)
 rename drivers/gpu/drm/i915/display/{intel_csr.c => intel_dmc.c} (99%)
 rename drivers/gpu/drm/i915/display/{intel_csr.h => intel_dmc.h} (88%)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..42ce0196930a 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -210,13 +210,13 @@ DPIO
 .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
:doc: DPIO
 
-CSR firmware support for DMC
-
+DMC Firmware Support
+
 
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
-   :doc: csr support for dmc
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
+   :doc: DMC Firmware Support
 
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
:internal:
 
 Video BIOS Table (VBT)
@@ -537,7 +537,7 @@ The HuC FW layout is the same as the GuC one, see `GuC 
Firmware Layout`_
 
 DMC
 ---
-See `CSR firmware support for DMC`_
+See `DMC Firmware Support`_
 
 Tracing
 ===
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137b..2da5bae8fa03 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -201,10 +201,10 @@ i915-y += \
display/intel_combo_phy.o \
display/intel_connector.o \
display/intel_crtc.o \
-   display/intel_csr.o \
display/intel_cursor.o \
display/intel_display.o \
display/intel_display_power.o \
+   display/intel_dmc.o \
display/intel_dpio_phy.o \
display/intel_dpll.o \
display/intel_dpll_mgr.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 39c9c49b378b..d98a314bb974 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -79,9 +79,9 @@
 #include "intel_cdclk.h"
 #include "intel_color.h"
 #include "intel_crtc.h"
-#include "intel_csr.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dp_link_training.h"
 #include "intel_fbc.h"
 #include "intel_fdi.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index e43abdf0e3d9..94e5cbd86e77 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -7,11 +7,11 @@
 #include 
 
 #include "i915_debugfs.h"
-#include "intel_csr.h"
 #include "intel_display_debugfs.h"
 #include "intel_display_power.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dp.h"
 #include "intel_fbc.h"
 #include "intel_hdcp.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index cbba41d3e6cf..e8fcc3d02d01 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -9,10 +9,10 @@
 #include "i915_irq.h"
 #include "intel_cdclk.h"
 #include "intel_combo_phy.h"
-#include "intel_csr.h"
 #include "intel_display_power.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dpio_phy.h"
 #include "intel_hotplug.h"
 #include "intel_pm.h"
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
similarity index 99%
rename from drivers/gpu/drm/i915/display/intel_csr.c
rename to drivers/gpu/drm/i915/display/intel_dmc.c
index ae1dfafaff9a..560574dd929a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -26,11 +26,11 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
-#include "intel_csr.h"
 #include "intel_de.h"
+#include "intel_dmc.h"
 
 /**
- * DOC: DMC firmware support
+ * DOC: DMC Firmware Support
  *
  * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
  * engine to save and restore the state of display engine when it enter into
diff --git a/drivers/gpu/drm/i915/display/intel_csr.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h

[Intel-gfx] [CI 2/5] drm/i915/dmc: s/HAS_CSR/HAS_DMC

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c | 12 ++--
 drivers/gpu/drm/i915/display/intel_display_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
 drivers/gpu/drm/i915/i915_pci.c  |  4 ++--
 drivers/gpu/drm/i915/intel_device_info.c |  2 +-
 drivers/gpu/drm/i915/intel_device_info.h |  2 +-
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index a22339ebdffd..5ed286dc6720 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -315,9 +315,9 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
 
-   if (!HAS_CSR(dev_priv)) {
+   if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
-   "No CSR support available for this platform\n");
+   "No DMC support available for this platform\n");
return;
}
 
@@ -686,7 +686,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
 
INIT_WORK(_priv->dmc.work, csr_load_work_fn);
 
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
/*
@@ -776,7 +776,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
  */
 void intel_csr_ucode_suspend(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
flush_work(_priv->dmc.work);
@@ -795,7 +795,7 @@ void intel_csr_ucode_suspend(struct drm_i915_private 
*dev_priv)
  */
 void intel_csr_ucode_resume(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
/*
@@ -815,7 +815,7 @@ void intel_csr_ucode_resume(struct drm_i915_private 
*dev_priv)
  */
 void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
intel_csr_ucode_suspend(dev_priv);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index a875f3c9b358..6cd7f8c1724f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -535,7 +535,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
struct intel_dmc *dmc;
i915_reg_t dc5_reg, dc6_reg = {};
 
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return -ENODEV;
 
dmc = _priv->dmc;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c9f6bbb5dd7..469783003309 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1662,7 +1662,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_RPS(dev_priv)  (INTEL_INFO(dev_priv)->has_rps)
 
-#define HAS_CSR(dev_priv)  (INTEL_INFO(dev_priv)->display.has_csr)
+#define HAS_DMC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_dmc)
 
 #define HAS_MSO(i915)  (INTEL_GEN(i915) >= 12)
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 03d1221de13b..06828ff90ccf 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -788,7 +788,7 @@ static void __err_print_to_sgl(struct 
drm_i915_error_state_buf *m,
 
err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
 
-   if (HAS_CSR(m->i915)) {
+   if (HAS_DMC(m->i915)) {
struct intel_dmc *dmc = >i915->dmc;
 
err_printf(m, "DMC loaded: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 574881c0e339..97c98f4fb265 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,7 @@ static const struct intel_device_info chv_info = {
GEN8_FEATURES, \
GEN(9), \
GEN9_DEFAULT_PAGE_SIZES, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_gt_uc = 1, \
.display.has_hdcp = 1, \
.display.has_ipc = 1, \
@@ -698,7 +698,7 @@ static const struct intel_device_info skl_gt4_info = {
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.has_runtime_pm = 1, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_rc6 = 1, \
.has_rps = true, \
.display.has_dp_mst = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 8cb58a238c68..e16599b67b83 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++

[Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr

Rename all occurences of CSR_* with DMC_*

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 167 +-
 drivers/gpu/drm/i915/display/intel_csr.h  |   6 +-
 .../drm/i915/display/intel_display_debugfs.c  |  16 +-
 .../drm/i915/display/intel_display_power.c|  14 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_reg.h   |  28 +--
 6 files changed, 117 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 5ed286dc6720..f2124796ce77 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -30,10 +30,9 @@
 #include "intel_de.h"
 
 /**
- * DOC: csr support for dmc
+ * DOC: DMC firmware support
  *
- * Display Context Save and Restore (CSR) firmware support added from gen9
- * onwards to drive newly added DMC (Display microcontroller) in display
+ * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
  * engine to save and restore the state of display engine when it enter into
  * low-power state and comes back to normal.
  */
@@ -44,55 +43,55 @@
__stringify(major) "_"   \
__stringify(minor) ".bin"
 
-#define GEN12_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
+#define GEN12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
 
-#define ADLS_CSR_PATH  DMC_PATH(adls, 2, 01)
-#define ADLS_CSR_VERSION_REQUIRED  CSR_VERSION(2, 1)
-MODULE_FIRMWARE(ADLS_CSR_PATH);
+#define ADLS_DMC_PATH  DMC_PATH(adls, 2, 01)
+#define ADLS_DMC_VERSION_REQUIRED  DMC_VERSION(2, 1)
+MODULE_FIRMWARE(ADLS_DMC_PATH);
 
-#define DG1_CSR_PATH   DMC_PATH(dg1, 2, 02)
-#define DG1_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(DG1_CSR_PATH);
+#define DG1_DMC_PATH   DMC_PATH(dg1, 2, 02)
+#define DG1_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(DG1_DMC_PATH);
 
-#define RKL_CSR_PATH   DMC_PATH(rkl, 2, 02)
-#define RKL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(RKL_CSR_PATH);
+#define RKL_DMC_PATH   DMC_PATH(rkl, 2, 02)
+#define RKL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(RKL_DMC_PATH);
 
-#define TGL_CSR_PATH   DMC_PATH(tgl, 2, 08)
-#define TGL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 8)
-MODULE_FIRMWARE(TGL_CSR_PATH);
+#define TGL_DMC_PATH   DMC_PATH(tgl, 2, 08)
+#define TGL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 8)
+MODULE_FIRMWARE(TGL_DMC_PATH);
 
-#define ICL_CSR_PATH   DMC_PATH(icl, 1, 09)
-#define ICL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 9)
-#define ICL_CSR_MAX_FW_SIZE0x6000
-MODULE_FIRMWARE(ICL_CSR_PATH);
+#define ICL_DMC_PATH   DMC_PATH(icl, 1, 09)
+#define ICL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 9)
+#define ICL_DMC_MAX_FW_SIZE0x6000
+MODULE_FIRMWARE(ICL_DMC_PATH);
 
-#define CNL_CSR_PATH   DMC_PATH(cnl, 1, 07)
-#define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define CNL_CSR_MAX_FW_SIZEGLK_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(CNL_CSR_PATH);
+#define CNL_DMC_PATH   DMC_PATH(cnl, 1, 07)
+#define CNL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 7)
+#define CNL_DMC_MAX_FW_SIZEGLK_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(CNL_DMC_PATH);
 
-#define GLK_CSR_PATH   DMC_PATH(glk, 1, 04)
-#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define GLK_CSR_MAX_FW_SIZE0x4000
-MODULE_FIRMWARE(GLK_CSR_PATH);
+#define GLK_DMC_PATH   DMC_PATH(glk, 1, 04)
+#define GLK_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define GLK_DMC_MAX_FW_SIZE0x4000
+MODULE_FIRMWARE(GLK_DMC_PATH);
 
-#define KBL_CSR_PATH   DMC_PATH(kbl, 1, 04)
-#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define KBL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(KBL_CSR_PATH);
+#define KBL_DMC_PATH   DMC_PATH(kbl, 1, 04)
+#define KBL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define KBL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(KBL_DMC_PATH);
 
-#define SKL_CSR_PATH   DMC_PATH(skl, 1, 27)
-#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 27)
-#define SKL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(SKL_CSR_PATH);
+#define SKL_DMC_PATH   DMC_PATH(skl, 1, 27)
+#define SKL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 27)
+#define SKL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(SKL_DMC_PATH);
 
-#define BXT_CSR_PATH   DMC_PATH(bxt, 1, 07)
-#define BXT_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define BXT_CSR_MAX_FW_SIZE0x3000
-MODULE_FIRMWARE(BXT_CSR_PATH);
+#define BXT_DMC_PATH   DMC_PATH(bxt, 1, 07)
+#define

[Intel-gfx] ✓ Fi.CI.BAT: success for Rename all CSR references to DMC (rev4)

== Series Details ==

Series: Rename all CSR references to DMC (rev4)
URL   : https://patchwork.freedesktop.org/series/90043/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10100 -> Patchwork_20148


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@gem_exec_fence@basic-await@bcs0:
- fi-bsw-n3050:   [PASS][2] -> [FAIL][3] ([i915#3457]) +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html

  * igt@gem_exec_fence@nb-await@bcs0:
- fi-bsw-nick:[PASS][4] -> [FAIL][5] ([i915#3457]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-bsw-kefka:   [PASS][6] -> [FAIL][7] ([i915#3457])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@wait@all:
- fi-bwr-2160:[PASS][8] -> [FAIL][9] ([i915#3457])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bwr-2160/igt@gem_wait@w...@all.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bwr-2160/igt@gem_wait@w...@all.html
- fi-pnv-d510:[PASS][10] -> [FAIL][11] ([i915#3457])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-pnv-d510/igt@gem_wait@w...@all.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-pnv-d510/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   NOTRUN -> [DMESG-FAIL][12] ([i915#3457])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][13] -> [DMESG-WARN][14] ([i915#2203] / 
[i915#2868])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-bsw-kefka:   [PASS][15] -> [FAIL][16] ([i915#53])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-kefka/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-elk-e7500:   [PASS][17] -> [FAIL][18] ([i915#53])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-glk-dsi: [FAIL][19] ([i915#3457]) -> [PASS][20] +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-nick:[FAIL][21] ([i915#3457]) -> [PASS][22] +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-kefka:   [FAIL][23] ([i915#3457]) -> [PASS][24] +2 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20148/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-bsw-n3050:   [FAIL][25] ([i915#3457]) -> [PASS][26] +1 similar 
issue
   [25]:

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Rename all CSR references to DMC (rev4)

== Series Details ==

Series: Rename all CSR references to DMC (rev4)
URL   : https://patchwork.freedesktop.org/series/90043/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
/home/cidrm/kernel/Documentation/gpu/i915.rst:540: WARNING: Unknown target 
name: "csr firmware support for dmc".


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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Rename all CSR references to DMC (rev4)

== Series Details ==

Series: Rename all CSR references to DMC (rev4)
URL   : https://patchwork.freedesktop.org/series/90043/
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_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1329:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1203:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./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' -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Rename all CSR references to DMC (rev4)

== Series Details ==

Series: Rename all CSR references to DMC (rev4)
URL   : https://patchwork.freedesktop.org/series/90043/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
843f8bd30dfb drm/i915/dmc: s/intel_csr/intel_dmc
c583faac1a4b drm/i915/dmc: s/HAS_CSR/HAS_DMC
b2dab106272a drm/i915/dmc: Rename macro names containing csr
b8a6211bf2da drm/i915/dmc: Rename functions names having "csr"
674033f899dd drm/i915/dmc: s/intel_csr.c/intel_dmc.c and 
s/intel_csr.h/intel_dmc.h
-:104: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#104: 
rename from drivers/gpu/drm/i915/display/intel_csr.c

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


___
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: Extract DPCD backlight helpers from i915, add support in nouveau (rev10)

== Series Details ==

Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau 
(rev10)
URL   : https://patchwork.freedesktop.org/series/84754/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10100 -> Patchwork_20147


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-elk-e7500:   NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-elk-e7500/igt@amdgpu/amd_ba...@cs-compute.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-kefka:   [PASS][2] -> [FAIL][3] ([i915#3457])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@gem_exec_fence@basic-aw...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-kefka/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@rcs0:
- fi-bsw-nick:[PASS][4] -> [FAIL][5] ([i915#3457]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@rcs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-bsw-n3050:   [PASS][6] -> [FAIL][7] ([i915#3457]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@busy@all:
- fi-apl-guc: [PASS][8] -> [FAIL][9] ([i915#3457])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-apl-guc/igt@gem_wait@b...@all.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-apl-guc/igt@gem_wait@b...@all.html

  * igt@gem_wait@wait@all:
- fi-pnv-d510:[PASS][10] -> [FAIL][11] ([i915#3457])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-pnv-d510/igt@gem_wait@w...@all.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-pnv-d510/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@mman:
- fi-elk-e7500:   NOTRUN -> [DMESG-FAIL][12] ([i915#3457])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-elk-e7500/igt@i915_selftest@l...@mman.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][13] -> [FAIL][14] ([i915#1372])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
- fi-bwr-2160:[PASS][15] -> [FAIL][16] ([i915#53])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bwr-2160/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bwr-2160/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-elk-e7500:   [PASS][17] -> [FAIL][18] ([i915#53])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-kefka:   [PASS][19] -> [FAIL][20] ([i915#53])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-kefka/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-n3050:   [FAIL][21] ([i915#3457]) -> [PASS][22] +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-nick:[FAIL][23] ([i915#3457]) -> [PASS][24] +1 similar 
issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10100/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20147/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
-

[Intel-gfx] [CI 4/5] drm/i915/dmc: Rename functions names having "csr"

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 64 +--
 drivers/gpu/drm/i915/display/intel_csr.h  | 10 +--
 drivers/gpu/drm/i915/display/intel_display.c  | 14 ++--
 .../drm/i915/display/intel_display_power.c| 14 ++--
 drivers/gpu/drm/i915/i915_drv.c   |  6 +-
 5 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index f2124796ce77..ae1dfafaff9a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -302,14 +302,14 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
 }
 
 /**
- * intel_csr_load_program() - write the firmware from memory to register.
+ * intel_dmc_load_program() - write the firmware from memory to register.
  * @dev_priv: i915 drm device.
  *
- * CSR firmware is read from a .bin file and kept in internal memory one time.
+ * DMC firmware is read from a .bin file and kept in internal memory one time.
  * Everytime display comes back from low power state this function is called to
  * copy the firmware from internal memory to registers.
  */
-void intel_csr_load_program(struct drm_i915_private *dev_priv)
+void intel_dmc_load_program(struct drm_i915_private *dev_priv)
 {
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
@@ -391,9 +391,9 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
 }
 
-static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
-   const struct intel_dmc_header_base *dmc_header,
-   size_t rem_size)
+static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
+  const struct intel_dmc_header_base *dmc_header,
+  size_t rem_size)
 {
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
@@ -498,7 +498,7 @@ static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
 }
 
 static u32
-parse_csr_fw_package(struct intel_dmc *dmc,
+parse_dmc_fw_package(struct intel_dmc *dmc,
 const struct intel_package_header *package_header,
 const struct stepping_info *si,
 size_t rem_size)
@@ -557,7 +557,7 @@ parse_csr_fw_package(struct intel_dmc *dmc,
 }
 
 /* Return number of bytes parsed or 0 on error */
-static u32 parse_csr_fw_css(struct intel_dmc *dmc,
+static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
struct intel_css_header *css_header,
size_t rem_size)
 {
@@ -590,7 +590,7 @@ static u32 parse_csr_fw_css(struct intel_dmc *dmc,
return sizeof(struct intel_css_header);
 }
 
-static void parse_csr_fw(struct drm_i915_private *dev_priv,
+static void parse_dmc_fw(struct drm_i915_private *dev_priv,
 const struct firmware *fw)
 {
struct intel_css_header *css_header;
@@ -606,7 +606,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,
 
/* Extract CSS Header information */
css_header = (struct intel_css_header *)fw->data;
-   r = parse_csr_fw_css(dmc, css_header, fw->size);
+   r = parse_dmc_fw_css(dmc, css_header, fw->size);
if (!r)
return;
 
@@ -614,7 +614,7 @@ static void parse_csr_fw(struct drm_i915_private *dev_priv,
 
/* Extract Package Header information */
package_header = (struct intel_package_header *)>data[readcount];
-   r = parse_csr_fw_package(dmc, package_header, si, fw->size - readcount);
+   r = parse_dmc_fw_package(dmc, package_header, si, fw->size - readcount);
if (!r)
return;
 
@@ -622,17 +622,17 @@ static void parse_csr_fw(struct drm_i915_private 
*dev_priv,
 
/* Extract dmc_header information */
dmc_header = (struct intel_dmc_header_base *)>data[readcount];
-   parse_csr_fw_dmc(dmc, dmc_header, fw->size - readcount);
+   parse_dmc_fw_header(dmc, dmc_header, fw->size - readcount);
 }
 
-static void intel_csr_runtime_pm_get(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_get(struct drm_i915_private *dev_priv)
 {
drm_WARN_ON(_priv->drm, dev_priv->dmc.wakeref);
dev_priv->dmc.wakeref =
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 }
 
-static void intel_csr_runtime_pm_put(struct drm_i915_private *dev_priv)
+static void intel_dmc_runtime_pm_put(struct drm_i915_private *dev_priv)
 {
intel_wakeref_t wakeref __maybe_unused =
fetch_and_zero(_priv->dmc.wakeref);
@@ -640,7 +640,7 @@ static void intel_csr_runtime_pm_put(struct 
drm_i915_private *dev_priv)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
 }
 
-static void csr_load_work_fn(struct work_struct *work)
+static void dmc_load_work_fn(struct

[Intel-gfx] [CI 2/5] drm/i915/dmc: s/HAS_CSR/HAS_DMC

No functional change.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c | 12 ++--
 drivers/gpu/drm/i915/display/intel_display_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c|  2 +-
 drivers/gpu/drm/i915/i915_pci.c  |  4 ++--
 drivers/gpu/drm/i915/intel_device_info.c |  2 +-
 drivers/gpu/drm/i915/intel_device_info.h |  2 +-
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index a22339ebdffd..5ed286dc6720 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -315,9 +315,9 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
 
-   if (!HAS_CSR(dev_priv)) {
+   if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
-   "No CSR support available for this platform\n");
+   "No DMC support available for this platform\n");
return;
}
 
@@ -686,7 +686,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
 
INIT_WORK(_priv->dmc.work, csr_load_work_fn);
 
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
/*
@@ -776,7 +776,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
  */
 void intel_csr_ucode_suspend(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
flush_work(_priv->dmc.work);
@@ -795,7 +795,7 @@ void intel_csr_ucode_suspend(struct drm_i915_private 
*dev_priv)
  */
 void intel_csr_ucode_resume(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
/*
@@ -815,7 +815,7 @@ void intel_csr_ucode_resume(struct drm_i915_private 
*dev_priv)
  */
 void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return;
 
intel_csr_ucode_suspend(dev_priv);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index a875f3c9b358..6cd7f8c1724f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -535,7 +535,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
struct intel_dmc *dmc;
i915_reg_t dc5_reg, dc6_reg = {};
 
-   if (!HAS_CSR(dev_priv))
+   if (!HAS_DMC(dev_priv))
return -ENODEV;
 
dmc = _priv->dmc;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c9f6bbb5dd7..469783003309 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1662,7 +1662,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_RPS(dev_priv)  (INTEL_INFO(dev_priv)->has_rps)
 
-#define HAS_CSR(dev_priv)  (INTEL_INFO(dev_priv)->display.has_csr)
+#define HAS_DMC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_dmc)
 
 #define HAS_MSO(i915)  (INTEL_GEN(i915) >= 12)
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 03d1221de13b..06828ff90ccf 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -788,7 +788,7 @@ static void __err_print_to_sgl(struct 
drm_i915_error_state_buf *m,
 
err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
 
-   if (HAS_CSR(m->i915)) {
+   if (HAS_DMC(m->i915)) {
struct intel_dmc *dmc = >i915->dmc;
 
err_printf(m, "DMC loaded: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 574881c0e339..97c98f4fb265 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -643,7 +643,7 @@ static const struct intel_device_info chv_info = {
GEN8_FEATURES, \
GEN(9), \
GEN9_DEFAULT_PAGE_SIZES, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_gt_uc = 1, \
.display.has_hdcp = 1, \
.display.has_ipc = 1, \
@@ -698,7 +698,7 @@ static const struct intel_device_info skl_gt4_info = {
.display.has_psr = 1, \
.display.has_psr_hw_tracking = 1, \
.has_runtime_pm = 1, \
-   .display.has_csr = 1, \
+   .display.has_dmc = 1, \
.has_rc6 = 1, \
.has_rps = true, \
.display.has_dp_mst = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 8cb58a238c68..e16599b67b83 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++

[Intel-gfx] [CI 3/5] drm/i915/dmc: Rename macro names containing csr

Rename all occurences of CSR_* with DMC_*

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 167 +-
 drivers/gpu/drm/i915/display/intel_csr.h  |   6 +-
 .../drm/i915/display/intel_display_debugfs.c  |  16 +-
 .../drm/i915/display/intel_display_power.c|  14 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_reg.h   |  28 +--
 6 files changed, 117 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 5ed286dc6720..f2124796ce77 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -30,10 +30,9 @@
 #include "intel_de.h"
 
 /**
- * DOC: csr support for dmc
+ * DOC: DMC firmware support
  *
- * Display Context Save and Restore (CSR) firmware support added from gen9
- * onwards to drive newly added DMC (Display microcontroller) in display
+ * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
  * engine to save and restore the state of display engine when it enter into
  * low-power state and comes back to normal.
  */
@@ -44,55 +43,55 @@
__stringify(major) "_"   \
__stringify(minor) ".bin"
 
-#define GEN12_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
+#define GEN12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
 
-#define ADLS_CSR_PATH  DMC_PATH(adls, 2, 01)
-#define ADLS_CSR_VERSION_REQUIRED  CSR_VERSION(2, 1)
-MODULE_FIRMWARE(ADLS_CSR_PATH);
+#define ADLS_DMC_PATH  DMC_PATH(adls, 2, 01)
+#define ADLS_DMC_VERSION_REQUIRED  DMC_VERSION(2, 1)
+MODULE_FIRMWARE(ADLS_DMC_PATH);
 
-#define DG1_CSR_PATH   DMC_PATH(dg1, 2, 02)
-#define DG1_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(DG1_CSR_PATH);
+#define DG1_DMC_PATH   DMC_PATH(dg1, 2, 02)
+#define DG1_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(DG1_DMC_PATH);
 
-#define RKL_CSR_PATH   DMC_PATH(rkl, 2, 02)
-#define RKL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
-MODULE_FIRMWARE(RKL_CSR_PATH);
+#define RKL_DMC_PATH   DMC_PATH(rkl, 2, 02)
+#define RKL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 2)
+MODULE_FIRMWARE(RKL_DMC_PATH);
 
-#define TGL_CSR_PATH   DMC_PATH(tgl, 2, 08)
-#define TGL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 8)
-MODULE_FIRMWARE(TGL_CSR_PATH);
+#define TGL_DMC_PATH   DMC_PATH(tgl, 2, 08)
+#define TGL_DMC_VERSION_REQUIRED   DMC_VERSION(2, 8)
+MODULE_FIRMWARE(TGL_DMC_PATH);
 
-#define ICL_CSR_PATH   DMC_PATH(icl, 1, 09)
-#define ICL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 9)
-#define ICL_CSR_MAX_FW_SIZE0x6000
-MODULE_FIRMWARE(ICL_CSR_PATH);
+#define ICL_DMC_PATH   DMC_PATH(icl, 1, 09)
+#define ICL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 9)
+#define ICL_DMC_MAX_FW_SIZE0x6000
+MODULE_FIRMWARE(ICL_DMC_PATH);
 
-#define CNL_CSR_PATH   DMC_PATH(cnl, 1, 07)
-#define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define CNL_CSR_MAX_FW_SIZEGLK_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(CNL_CSR_PATH);
+#define CNL_DMC_PATH   DMC_PATH(cnl, 1, 07)
+#define CNL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 7)
+#define CNL_DMC_MAX_FW_SIZEGLK_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(CNL_DMC_PATH);
 
-#define GLK_CSR_PATH   DMC_PATH(glk, 1, 04)
-#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define GLK_CSR_MAX_FW_SIZE0x4000
-MODULE_FIRMWARE(GLK_CSR_PATH);
+#define GLK_DMC_PATH   DMC_PATH(glk, 1, 04)
+#define GLK_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define GLK_DMC_MAX_FW_SIZE0x4000
+MODULE_FIRMWARE(GLK_DMC_PATH);
 
-#define KBL_CSR_PATH   DMC_PATH(kbl, 1, 04)
-#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
-#define KBL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(KBL_CSR_PATH);
+#define KBL_DMC_PATH   DMC_PATH(kbl, 1, 04)
+#define KBL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 4)
+#define KBL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(KBL_DMC_PATH);
 
-#define SKL_CSR_PATH   DMC_PATH(skl, 1, 27)
-#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 27)
-#define SKL_CSR_MAX_FW_SIZEBXT_CSR_MAX_FW_SIZE
-MODULE_FIRMWARE(SKL_CSR_PATH);
+#define SKL_DMC_PATH   DMC_PATH(skl, 1, 27)
+#define SKL_DMC_VERSION_REQUIRED   DMC_VERSION(1, 27)
+#define SKL_DMC_MAX_FW_SIZEBXT_DMC_MAX_FW_SIZE
+MODULE_FIRMWARE(SKL_DMC_PATH);
 
-#define BXT_CSR_PATH   DMC_PATH(bxt, 1, 07)
-#define BXT_CSR_VERSION_REQUIRED   CSR_VERSION(1, 7)
-#define BXT_CSR_MAX_FW_SIZE0x3000
-MODULE_FIRMWARE(BXT_CSR_PATH);
+#define BXT_DMC_PATH   DMC_PATH(bxt, 1, 07)
+#define

[Intel-gfx] [CI 0/5] Rename all CSR references to DMC

Currently in our driver we use both CSR and DMC interchangeably.
Even though the spec mentions both, we do not follow that convention
in the driver.

Renaming all references of CSR to just be DMC. This hopefully makes
the driver of this part a litlle less confusing.

Suggested-by: Jani Nikula 

Acked-by: Jani Nikula 

Anusha Srivatsa (5):
  drm/i915/dmc: s/intel_csr/intel_dmc
  drm/i915/dmc: s/HAS_CSR/HAS_DMC
  drm/i915/dmc: Rename macro names containing csr
  drm/i915/dmc: Rename functions names having "csr"
  drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h

 Documentation/gpu/i915.rst|  10 +-
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/display/intel_csr.h  |  21 --
 drivers/gpu/drm/i915/display/intel_display.c  |  16 +-
 .../drm/i915/display/intel_display_debugfs.c  |  30 +-
 .../drm/i915/display/intel_display_power.c|  82 ++---
 .../i915/display/{intel_csr.c => intel_dmc.c} | 333 +-
 drivers/gpu/drm/i915/display/intel_dmc.h  |  21 ++
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.c   |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  12 +-
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/i915_reg.h   |  28 +-
 drivers/gpu/drm/i915/intel_device_info.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   2 +-
 16 files changed, 289 insertions(+), 290 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/display/intel_csr.h
 rename drivers/gpu/drm/i915/display/{intel_csr.c => intel_dmc.c} (66%)
 create mode 100644 drivers/gpu/drm/i915/display/intel_dmc.h

-- 
2.25.0

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

[Intel-gfx] [CI 1/5] drm/i915/dmc: s/intel_csr/intel_dmc

No functional change.

v2: Chchpatch fixes.

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_csr.c  | 170 +-
 .../drm/i915/display/intel_display_debugfs.c  |  14 +-
 .../drm/i915/display/intel_display_power.c|  52 +++---
 drivers/gpu/drm/i915/display/intel_psr.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |   8 +-
 6 files changed, 125 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 26a922d34263..a22339ebdffd 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -312,7 +312,7 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
  */
 void intel_csr_load_program(struct drm_i915_private *dev_priv)
 {
-   u32 *payload = dev_priv->csr.dmc_payload;
+   u32 *payload = dev_priv->dmc.dmc_payload;
u32 i, fw_size;
 
if (!HAS_CSR(dev_priv)) {
@@ -321,13 +321,13 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
return;
}
 
-   if (!dev_priv->csr.dmc_payload) {
+   if (!dev_priv->dmc.dmc_payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
 
-   fw_size = dev_priv->csr.dmc_fw_size;
+   fw_size = dev_priv->dmc.dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
 
preempt_disable();
@@ -338,12 +338,12 @@ void intel_csr_load_program(struct drm_i915_private 
*dev_priv)
 
preempt_enable();
 
-   for (i = 0; i < dev_priv->csr.mmio_count; i++) {
-   intel_de_write(dev_priv, dev_priv->csr.mmioaddr[i],
-  dev_priv->csr.mmiodata[i]);
+   for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
+   intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
+  dev_priv->dmc.mmiodata[i]);
}
 
-   dev_priv->csr.dc_state = 0;
+   dev_priv->dmc.dc_state = 0;
 
gen9_set_dc_state_debugmask(dev_priv);
 }
@@ -392,7 +392,7 @@ static u32 find_dmc_fw_offset(const struct intel_fw_info 
*fw_info,
return dmc_offset;
 }
 
-static u32 parse_csr_fw_dmc(struct intel_csr *csr,
+static u32 parse_csr_fw_dmc(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size)
 {
@@ -401,8 +401,8 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
u32 mmio_count, mmio_count_max;
u8 *payload;
 
-   BUILD_BUG_ON(ARRAY_SIZE(csr->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(csr->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
 
/*
 * Check if we can access common fields, we will checkc again below
@@ -464,10 +464,10 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
  mmioaddr[i]);
return 0;
}
-   csr->mmioaddr[i] = _MMIO(mmioaddr[i]);
-   csr->mmiodata[i] = mmiodata[i];
+   dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
+   dmc->mmiodata[i] = mmiodata[i];
}
-   csr->mmio_count = mmio_count;
+   dmc->mmio_count = mmio_count;
 
rem_size -= header_len_bytes;
 
@@ -476,20 +476,20 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
if (rem_size < payload_size)
goto error_truncated;
 
-   if (payload_size > csr->max_fw_size) {
+   if (payload_size > dmc->max_fw_size) {
DRM_ERROR("DMC FW too big (%u bytes)\n", payload_size);
return 0;
}
-   csr->dmc_fw_size = dmc_header->fw_size;
+   dmc->dmc_fw_size = dmc_header->fw_size;
 
-   csr->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
-   if (!csr->dmc_payload) {
+   dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
+   if (!dmc->dmc_payload) {
DRM_ERROR("Memory allocation failed for dmc payload\n");
return 0;
}
 
payload = (u8 *)(dmc_header) + header_len_bytes;
-   memcpy(csr->dmc_payload, payload, payload_size);
+   memcpy(dmc->dmc_payload, payload, payload_size);
 
return header_len_bytes + payload_size;
 
@@ -499,7 +499,7 @@ static u32 parse_csr_fw_dmc(struct intel_csr *csr,
 }
 
 static u32
-parse_csr_fw_package(struct intel_csr *csr,
+parse_csr_fw_package(struct intel_dmc *dmc,
 const struct intel_package_header *package_header,
 const struct stepping_info *si,
 size_t rem_size)
@@ -558,7 +558,7 @@ parse_csr_fw_package(struct intel_csr *csr,
 }
 
 /* Return number of bytes parsed

[Intel-gfx] [CI 5/5] drm/i915/dmc: s/intel_csr.c/intel_dmc.c and s/intel_csr.h/intel_dmc.h

Finally, rename the header and source file from csr to dmc.

v2: Add file rename in Documentation.
- Place headers in orders. (Jani)

Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 Documentation/gpu/i915.rst | 10 +-
 drivers/gpu/drm/i915/Makefile  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_display_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_display_power.c |  2 +-
 .../gpu/drm/i915/display/{intel_csr.c => intel_dmc.c}  |  4 ++--
 .../gpu/drm/i915/display/{intel_csr.h => intel_dmc.h}  |  6 +++---
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 9 files changed, 16 insertions(+), 16 deletions(-)
 rename drivers/gpu/drm/i915/display/{intel_csr.c => intel_dmc.c} (99%)
 rename drivers/gpu/drm/i915/display/{intel_csr.h => intel_dmc.h} (88%)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 486c720f3890..308bb283f468 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -210,13 +210,13 @@ DPIO
 .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c
:doc: DPIO
 
-CSR firmware support for DMC
-
+DMC Firmware Support
+
 
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
-   :doc: csr support for dmc
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
+   :doc: DMC Firmware Support
 
-.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c
:internal:
 
 Video BIOS Table (VBT)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d0d936d9137b..2da5bae8fa03 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -201,10 +201,10 @@ i915-y += \
display/intel_combo_phy.o \
display/intel_connector.o \
display/intel_crtc.o \
-   display/intel_csr.o \
display/intel_cursor.o \
display/intel_display.o \
display/intel_display_power.o \
+   display/intel_dmc.o \
display/intel_dpio_phy.o \
display/intel_dpll.o \
display/intel_dpll_mgr.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 39c9c49b378b..d98a314bb974 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -79,9 +79,9 @@
 #include "intel_cdclk.h"
 #include "intel_color.h"
 #include "intel_crtc.h"
-#include "intel_csr.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dp_link_training.h"
 #include "intel_fbc.h"
 #include "intel_fdi.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index e43abdf0e3d9..94e5cbd86e77 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -7,11 +7,11 @@
 #include 
 
 #include "i915_debugfs.h"
-#include "intel_csr.h"
 #include "intel_display_debugfs.h"
 #include "intel_display_power.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dp.h"
 #include "intel_fbc.h"
 #include "intel_hdcp.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index cbba41d3e6cf..e8fcc3d02d01 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -9,10 +9,10 @@
 #include "i915_irq.h"
 #include "intel_cdclk.h"
 #include "intel_combo_phy.h"
-#include "intel_csr.h"
 #include "intel_display_power.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
+#include "intel_dmc.h"
 #include "intel_dpio_phy.h"
 #include "intel_hotplug.h"
 #include "intel_pm.h"
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
similarity index 99%
rename from drivers/gpu/drm/i915/display/intel_csr.c
rename to drivers/gpu/drm/i915/display/intel_dmc.c
index ae1dfafaff9a..560574dd929a 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -26,11 +26,11 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
-#include "intel_csr.h"
 #include "intel_de.h"
+#include "intel_dmc.h"
 
 /**
- * DOC: DMC firmware support
+ * DOC: DMC Firmware Support
  *
  * From gen9 onwards we have newly added DMC (Display microcontroller) in 
display
  * engine to save and restore the state of display engine when it enter into
diff --git a/drivers/gpu/drm/i915/display/intel_csr.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h
similarity index 88%
rename from drivers/gpu/drm/i915/display/intel_csr.h
rename to drivers/gpu/drm/i915/display/intel_dmc.h
index fc4960b91686..57dd99da0ced 100644
---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev10)

== Series Details ==

Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau 
(rev10)
URL   : https://patchwork.freedesktop.org/series/84754/
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/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
+./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:270:49: error: static 
assertion failed: "amd_sriov_msg_vf2pf_info must

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Extract DPCD backlight helpers from i915, add support in nouveau (rev10)

== Series Details ==

Series: drm: Extract DPCD backlight helpers from i915, add support in nouveau 
(rev10)
URL   : https://patchwork.freedesktop.org/series/84754/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
634883ae67b3 drm/i915/dpcd_bl: Remove redundant AUX backlight frequency 
calculations
2f6dd64b21d7 drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values 
correctly
59188c6d0d55 drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a 
bit
221bebf6b8c3 drm/i915/dpcd_bl: Cache some backlight capabilities in 
intel_panel.backlight
48f8c1dcc3bd drm/i915/dpcd_bl: Move VESA backlight enabling code closer together
131869b89b71 drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we 
can't read PWMGEN_BIT_COUNT
a7cc151a9942 drm/i915/dpcd_bl: Print return codes for VESA backlight failures
428307dfe083 drm/dp: Extract i915's eDP backlight code into DRM helpers
65a3d8889dfd drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau
-:238: CHECK:CAMELCASE: Avoid CamelCase: 
#238: FILE: drivers/gpu/drm/nouveau/nouveau_backlight.c:300:
+   if (nv_conn->type == DCB_CONNECTOR_eDP) {

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


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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Initialize err in remap_io_sg()

2021-05-18 Thread Souza, Jose

On Tue, 2021-05-18 at 05:56 +, Patchwork wrote:
Patch Details
Series: drm/i915: Initialize err in remap_io_sg()
URL:https://patchwork.freedesktop.org/series/90258/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20139/index.html
CI Bug Log - changes from CI_DRM_10093_full -> Patchwork_20139_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_20139_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20139_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_20139_full:

IGT changes
Possible regressions

  *   igt@api_intel_bb@destroy-bb:

 *   shard-glk: 
PASS
 -> 
TIMEOUT
 +3 similar issues
  *   igt@gem_ppgtt@blt-vs-render-ctx0:

 *   shard-apl: NOTRUN -> 
FAIL
  *   igt@kms_atomic_interruptible@legacy-setmode:

 *   shard-glk: NOTRUN -> 
TIMEOUT
 +1 similar issue
  *   igt@prime_mmap_coherency@read:

 *   shard-snb: NOTRUN -> 
INCOMPLETE

Regressions not related.
Patch pushed, thanks Christoph, Rodrigo and Jani.

Warnings

  *   igt@gem_ctx_freq@sysfs:
 *   shard-glk: 
FAIL
 ([i915#3457]) -> 
TIMEOUT

Known issues

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

IGT changes
Issues hit

  *   igt@feature_discovery@display-3x:

 *   shard-tglb: NOTRUN -> 
SKIP
 ([i915#1839])
  *   igt@gem_create@create-clear:

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#3160])
  *   igt@gem_create@create-massive:

 *   shard-kbl: NOTRUN -> 
DMESG-WARN
 ([i915#3002])

 *   shard-skl: NOTRUN -> 
DMESG-WARN
 ([i915#3002])

  *   igt@gem_ctx_persistence@engines-mixed:

 *   shard-snb: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +4 similar issues
  *   igt@gem_ctx_persistence@heartbeat-many:

 *   shard-glk: 
PASS
 -> 
FAIL
 ([i915#3457]) +30 similar issues
  *   igt@gem_ctx_persistence@many-contexts:

 *   shard-tglb: 
PASS
 -> 
FAIL
 ([i915#2410] / [i915#3457])
  *   igt@gem_ctx_ringsize@active@bcs0:

 *   shard-skl: NOTRUN -> 
INCOMPLETE
 ([i915#3316] / [i915#3457])
  *   igt@gem_exec_fair@basic-none@vcs1:

 *   shard-iclb: NOTRUN -> 
FAIL
 ([i915#2842] / [i915#3457]) +4 similar issues
  *   igt@gem_exec_fair@basic-pace@rcs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842] / [i915#3457])
  *   igt@gem_exec_fair@basic-pace@vcs0:

 *   shard-iclb: 
PASS
 ->

Re: [Intel-gfx] [PATCH v4 03/23] drm/i915/xelpd: Calculate VDSC RC parameters

2021-05-18 Thread Navare, Manasi

On Fri, May 14, 2021 at 08:10:15PM -0700, Matt Roper wrote:
> From: Vandita Kulkarni 
> 
> Add methods to calculate rc parameters for all bpps, against the fixed
> arrays that we already have for 8,10,12 valid o/p bpps, to cover RGB 444
> formats.  Our hw doesn't support YUV compression yet.  The calculations
> used here are from VESA C model for DSC 1.1
> 
> v2:
>  - Checkpatch fixes
> 
> Cc: Manasi Navare 
> Cc: Juha-Pekka Heikkil 
> Signed-off-by: Vandita Kulkarni 
> Signed-off-by: Mohammed Khajapasha 
> Signed-off-by: Matt Roper 

The new RC calculations look good to me and have been verified

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 97 ---
>  1 file changed, 87 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index efc3184d8315..02e86d2be395 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -5,7 +5,7 @@
>   * Author: Gaurav K Singh 
>   * Manasi Navare 
>   */
> -
> +#include 
>  #include "i915_drv.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
> @@ -373,12 +373,74 @@ static bool is_pipe_dsc(const struct intel_crtc_state 
> *crtc_state)
>   return true;
>  }
>  
> +static void
> +calculate_rc_params(struct rc_parameters *rc,
> + struct drm_dsc_config *vdsc_cfg)
> +{
> + int bpc = vdsc_cfg->bits_per_component;
> + int bpp = vdsc_cfg->bits_per_pixel >> 4;
> + int ofs_und6[] = { 0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, 
> -12, -12, -12 };
> + int ofs_und8[] = { 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, 
> -12, -12 };
> + int ofs_und12[] = { 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, 
> -12, -12, -12 };
> + int ofs_und15[] = { 10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, 
> -12, -12 };
> + int qp_bpc_modifier = (bpc - 8) * 2;
> + u32 res, buf_i;
> +
> + if (vdsc_cfg->slice_height >= 8)
> + rc->first_line_bpg_offset =
> + 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height - 
> 8)), 100);
> + else
> + rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
> +
> + /* Our hw supports only 444 modes as of today */
> + if (bpp >= 12)
> + rc->initial_offset = 2048;
> + else if (bpp >= 10)
> + rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584), 
> 2);
> + else if (bpp >= 8)
> + rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
> + else
> + rc->initial_offset = 6144;
> +
> + /* initial_xmit_delay = rc_model_size/2/compression_bpp */
> + rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
> +
> + rc->flatness_min_qp = 3 + qp_bpc_modifier;
> + rc->flatness_max_qp = 12 + qp_bpc_modifier;
> +
> + rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
> + rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
> +
> + for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
> + /* Calculate range_bgp_offset */
> + if (bpp <= 6) {
> + rc->rc_range_params[buf_i].range_bpg_offset = 
> ofs_und6[buf_i];
> + } else if (bpp <= 8) {
> + res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
> ofs_und6[buf_i])), 2);
> + rc->rc_range_params[buf_i].range_bpg_offset =
> + ofs_und6[buf_i] 
> + res;
> + } else if (bpp <= 12) {
> + rc->rc_range_params[buf_i].range_bpg_offset =
> + ofs_und8[buf_i];
> + } else if (bpp <= 15) {
> + res = DIV_ROUND_UP(((bpp - 12) * (ofs_und15[buf_i] - 
> ofs_und12[buf_i])), 3);
> + rc->rc_range_params[buf_i].range_bpg_offset =
> + 
> ofs_und12[buf_i] + res;
> + } else {
> + rc->rc_range_params[buf_i].range_bpg_offset =
> + 
> ofs_und15[buf_i];
> + }
> + }
> +}
> +
>  int intel_dsc_compute_params(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct drm_dsc_config *vdsc_cfg = _config->dsc.config;
>   u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
>   const struct rc_parameters *rc_params;
> + struct rc_parameters *rc = NULL;
>   u8 i = 0;
>  
>   vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> @@ -413,9 +475,24 @@ int intel_dsc_compute_params(struct intel_encoder 
> *encoder,
>   vdsc_cfg->rc_buf_thresh[13] = 0x7D;
>   }
>  
> - rc_params =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: remove local storage of debugfs file

== Series Details ==

Series: drm/i915/gvt: remove local storage of debugfs file
URL   : https://patchwork.freedesktop.org/series/90294/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10098 -> Patchwork_20146


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-await@rcs0:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#3457])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@rcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-nick:[PASS][3] -> [FAIL][4] ([i915#3457])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-nick/igt@gem_exec_fence@basic-aw...@vecs0.html
- fi-glk-dsi: [PASS][5] -> [FAIL][6] ([i915#3457])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-kefka:   [PASS][7] -> [FAIL][8] ([i915#3457])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#2868])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-nick:[FAIL][11] ([i915#3457]) -> [PASS][12] +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-apl-guc: [FAIL][13] ([i915#3457]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-bsw-kefka:   [FAIL][15] ([i915#3457]) -> [PASS][16] +3 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
- fi-bsw-n3050:   [FAIL][17] ([i915#3457]) -> [PASS][18] +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@busy@all:
- fi-bsw-nick:[FAIL][19] ([i915#3177] / [i915#3457]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_wait@b...@all.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-nick/igt@gem_wait@b...@all.html
- fi-bsw-kefka:   [FAIL][21] ([i915#3177] / [i915#3457]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_wait@b...@all.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bsw-kefka/igt@gem_wait@b...@all.html

  * igt@gem_wait@wait@all:
- fi-bwr-2160:[FAIL][23] ([i915#3457]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bwr-2160/igt@gem_wait@w...@all.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-bwr-2160/igt@gem_wait@w...@all.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-elk-e7500:   [FAIL][25] ([i915#53]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20146/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-bsw-kefka:   [FAIL][27] ([i915#53]) -> [PASS][28] +1 similar issue
   [27]:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move LMEM (VRAM) management over to TTM (rev2)

== Series Details ==

Series: drm/i915: Move LMEM (VRAM) management over to TTM (rev2)
URL   : https://patchwork.freedesktop.org/series/90022/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10094_full -> Patchwork_20142_full


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_20142_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20142_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_20142_full:

### IGT changes ###

 Warnings 

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl:  [DMESG-WARN][1] ([i915#180] / [i915#295]) -> 
[INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10094/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_allocator@execbuf-with-allocator:
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#3457])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-kbl2/igt@api_intel_alloca...@execbuf-with-allocator.html

  * igt@api_intel_bb@intel-bb-blit-y:
- shard-glk:  NOTRUN -> [FAIL][4] ([i915#3471])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-glk5/igt@api_intel...@intel-bb-blit-y.html

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#1888] / [i915#3160])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10094/shard-glk4/igt@gem_cre...@create-clear.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-glk1/igt@gem_cre...@create-clear.html

  * igt@gem_ctx_engines@invalid-engines:
- shard-kbl:  NOTRUN -> [INCOMPLETE][7] ([i915#3468])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-kbl7/igt@gem_ctx_engi...@invalid-engines.html

  * igt@gem_ctx_persistence@legacy-engines-cleanup:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-cleanup.html

  * igt@gem_ctx_ringsize@active@bcs0:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([i915#3316] / 
[i915#3457])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10094/shard-skl3/igt@gem_ctx_ringsize@act...@bcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-skl2/igt@gem_ctx_ringsize@act...@bcs0.html

  * igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842] / [i915#3457]) 
+1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10094/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-tglb8/igt@gem_exec_fair@basic-p...@bcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271]) +185 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][14] ([i915#2389] / [i915#3457]) +3 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-apl6/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_exec_schedule@independent@rcs0:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#3457]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-glk5/igt@gem_exec_schedule@independ...@rcs0.html

  * igt@gem_exec_schedule@preempt-hang@vcs0:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#3457]) +33 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10094/shard-glk7/igt@gem_exec_schedule@preempt-h...@vcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-glk6/igt@gem_exec_schedule@preempt-h...@vcs0.html

  * igt@gem_exec_schedule@u-submit-golden-slice@vecs0:
- shard-apl:  NOTRUN -> [FAIL][18] ([i915#3457]) +10 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20142/shard-apl7/igt@gem_exec_schedule@u-submit-golden-sl...@vecs0.html

  * igt@gem_exec_schedule@u-submit-late-slice@vecs0:
- shard-apl:  [PASS][19] -> [FAIL][20] ([i915#3457])
   [19]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/plane: add intel_plane_helper_add() helper

== Series Details ==

Series: drm/i915/plane: add intel_plane_helper_add() helper
URL   : https://patchwork.freedesktop.org/series/90287/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10098 -> Patchwork_20145


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-n3050:   [PASS][2] -> [FAIL][3] ([i915#3457])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-glk-dsi: [PASS][4] -> [FAIL][5] ([i915#3457])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vecs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@bcs0:
- fi-bsw-nick:[PASS][6] -> [FAIL][7] ([i915#3457])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@bcs0.html

  * igt@kms_busy@basic@flip:
- fi-ilk-650: [PASS][8] -> [INCOMPLETE][9] ([i915#3457])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-ilk-650/igt@kms_busy@ba...@flip.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-ilk-650/igt@kms_busy@ba...@flip.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-elk-e7500:   [PASS][10] -> [FAIL][11] ([i915#53])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  * igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][12] ([i915#3475])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-ilk-650/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_fence@nb-await@rcs0:
- fi-glk-dsi: [FAIL][13] ([i915#3457]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-glk-dsi/igt@gem_exec_fence@nb-aw...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-glk-dsi/igt@gem_exec_fence@nb-aw...@rcs0.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-nick:[FAIL][15] ([i915#3457]) -> [PASS][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-apl-guc: [FAIL][17] ([i915#3457]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-bsw-kefka:   [FAIL][19] ([i915#3457]) -> [PASS][20] +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@vecs0.html
- fi-bsw-n3050:   [FAIL][21] ([i915#3457]) -> [PASS][22] +3 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bsw-n3050/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@wait@all:
- fi-bwr-2160:[FAIL][23] ([i915#3457]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bwr-2160/igt@gem_wait@w...@all.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20145/fi-bwr-2160/igt@gem_wait@w...@all.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][25] ([i915#2782]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [26]:

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping


Am 18.05.21 um 18:07 schrieb Thomas Hellström:


On 5/18/21 5:42 PM, Christian König wrote:

Am 18.05.21 um 17:38 schrieb Thomas Hellström:


On 5/18/21 5:28 PM, Christian König wrote:

Am 18.05.21 um 17:20 schrieb Thomas Hellström:


On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at 
eviction time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for 
swapout,

and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to 
keep the
current behaviour for all drivers by returning true if the 
buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour 
for the
case where a buffer object is in a TT backed placement when 
swapped out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to 
do that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any 
place to put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.


That sounds like a design bug to me since you should never need to 
do this.


When you want to destroy the backing store of a buffer during 
eviction you should just do this by returning an empty placement 
from the evict_flags callback.


So this is for the functionality where the user has indicated that 
the contents is no longer of value, but the buffer itself
is cached until evicted or swapped out for performance reasons. So 
the above would work for eviction, but what about swapout. Could we 
add some similar functionality there?


Amdgpu has the same functionality and you don't need to handle swap 
at all.


Just return from the evict_flags that you want to drop the backing 
store as soon as the BO leaves the GTT domain.


Hmm, the pipeline_gutting function seems ok, but overly complex if the 
bo is already idle, Am I allowed to optimize it slightly for the 
latter case?


Yeah, sure. We just never hat that use case so far.

Christian.



/Thomas




Christian.



/Thomas



Regards,
Christian.



/Thomas







Thanks,

Thomas










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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: remove local storage of debugfs file

2021-05-18 Thread Greg Kroah-Hartman

On Tue, May 18, 2021 at 06:17:05PM +0200, Greg Kroah-Hartman wrote:
> There is no need to keep the dentry around for the debugfs kvmgt cache
> file, as we can just look it up when we want to remove it later on.
> Simplify the structure by removing the dentry and relying on debugfs
> to find the dentry to remove when we want to.
> 
> By doing this change, we remove the last in-kernel user that was storing
> the result of debugfs_create_long(), so that api can be cleaned up.
> 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)

Note, I can take this through my debugfs tree if wanted, that way I can
clean up the debugfs_create_long() api at the same time.  Otherwise it's
fine, I can wait until next -rc1 for that to happen.

thanks,

greg k-h
___
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/reg: replace BIT() usage with REG_BIT() (rev2)

== Series Details ==

Series: drm/i915/reg: replace BIT() usage with REG_BIT() (rev2)
URL   : https://patchwork.freedesktop.org/series/90270/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10098 -> Patchwork_20144


Summary
---

  **WARNING**

  Minor unknown changes coming with Patchwork_20144 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20144, 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_20144/index.html

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][1] ([i915#2782] / [i915#2940]) -> 
[DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-bsw-n3050:   [PASS][4] -> [FAIL][5] ([i915#3457])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@rcs0:
- fi-bsw-kefka:   [PASS][6] -> [FAIL][7] ([i915#3457])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-kefka/igt@gem_exec_fence@nb-aw...@rcs0.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-bsw-kefka:   [PASS][8] -> [FAIL][9] ([i915#53]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-kefka/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-ilk-650: [PASS][10] -> [FAIL][11] ([i915#53])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-ilk-650/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-ilk-650/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
- fi-elk-e7500:   [PASS][12] -> [FAIL][13] ([i915#53])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-elk-e7500/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  
 Possible fixes 

  * igt@gem_busy@busy@all:
- fi-bsw-kefka:   [FAIL][14] ([i915#3457]) -> [PASS][15] +3 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-kefka/igt@gem_busy@b...@all.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-kefka/igt@gem_busy@b...@all.html
- fi-bsw-n3050:   [FAIL][16] ([i915#3457]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-n3050/igt@gem_busy@b...@all.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-n3050/igt@gem_busy@b...@all.html

  * igt@gem_exec_fence@nb-await@vcs0:
- fi-bsw-nick:[FAIL][18] ([i915#3457]) -> [PASS][19] +1 similar 
issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-bsw-nick/igt@gem_exec_fence@nb-aw...@vcs0.html
- fi-apl-guc: [FAIL][20] ([i915#3457]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20144/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vcs0.html

  * igt@gem_wait@wait@all:
- fi-bwr-2160:[FAIL][22] ([i915#3457]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10098/fi-bwr-2160/igt@gem_wait@w...@all.html
   [23]:

[Intel-gfx] [PATCH] drm/i915/gvt: remove local storage of debugfs file

2021-05-18 Thread Greg Kroah-Hartman

There is no need to keep the dentry around for the debugfs kvmgt cache
file, as we can just look it up when we want to remove it later on.
Simplify the structure by removing the dentry and relying on debugfs
to find the dentry to remove when we want to.

By doing this change, we remove the last in-kernel user that was storing
the result of debugfs_create_long(), so that api can be cleaned up.

Cc: Zhenyu Wang 
Cc: Zhi Wang 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: intel-gvt-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 65ff43cfc0f7..433c2a448f2d 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -88,6 +88,7 @@ struct kvmgt_pgfn {
struct hlist_node hnode;
 };
 
+#define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
 struct kvmgt_guest_info {
struct kvm *kvm;
struct intel_vgpu *vgpu;
@@ -95,7 +96,6 @@ struct kvmgt_guest_info {
 #define NR_BKT (1 << 18)
struct hlist_head ptable[NR_BKT];
 #undef NR_BKT
-   struct dentry *debugfs_cache_entries;
 };
 
 struct gvt_dma {
@@ -1843,16 +1843,15 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
info->track_node.track_flush_slot = kvmgt_page_track_flush_slot;
kvm_page_track_register_notifier(kvm, >track_node);
 
-   info->debugfs_cache_entries = debugfs_create_ulong(
-   "kvmgt_nr_cache_entries",
-   0444, vgpu->debugfs,
-   >nr_cache_entries);
+   debugfs_create_ulong(KVMGT_DEBUGFS_FILENAME, 0444, vgpu->debugfs,
+>nr_cache_entries);
return 0;
 }
 
 static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
 {
-   debugfs_remove(info->debugfs_cache_entries);
+   debugfs_remove(debugfs_lookup(KVMGT_DEBUGFS_FILENAME,
+ info->vgpu->debugfs));
 
kvm_page_track_unregister_notifier(info->kvm, >track_node);
kvm_put_kvm(info->kvm);
-- 
2.31.1

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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping



On 5/18/21 5:42 PM, Christian König wrote:

Am 18.05.21 um 17:38 schrieb Thomas Hellström:


On 5/18/21 5:28 PM, Christian König wrote:

Am 18.05.21 um 17:20 schrieb Thomas Hellström:


On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction 
time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for 
swapout,

and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to 
keep the
current behaviour for all drivers by returning true if the 
buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour 
for the
case where a buffer object is in a TT backed placement when 
swapped out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to do 
that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any 
place to put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.


That sounds like a design bug to me since you should never need to 
do this.


When you want to destroy the backing store of a buffer during 
eviction you should just do this by returning an empty placement 
from the evict_flags callback.


So this is for the functionality where the user has indicated that 
the contents is no longer of value, but the buffer itself
is cached until evicted or swapped out for performance reasons. So 
the above would work for eviction, but what about swapout. Could we 
add some similar functionality there?


Amdgpu has the same functionality and you don't need to handle swap at 
all.


Just return from the evict_flags that you want to drop the backing 
store as soon as the BO leaves the GTT domain.


Hmm, the pipeline_gutting function seems ok, but overly complex if the 
bo is already idle, Am I allowed to optimize it slightly for the latter 
case?


/Thomas




Christian.



/Thomas



Regards,
Christian.



/Thomas







Thanks,

Thomas









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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping


Am 18.05.21 um 17:38 schrieb Thomas Hellström:


On 5/18/21 5:28 PM, Christian König wrote:

Am 18.05.21 um 17:20 schrieb Thomas Hellström:


On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction 
time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for 
swapout,

and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to 
keep the
current behaviour for all drivers by returning true if the buffer 
object
is already in the TTM_PL_SYSTEM placement. We change behaviour 
for the
case where a buffer object is in a TT backed placement when 
swapped out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to do 
that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any place 
to put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.


That sounds like a design bug to me since you should never need to do 
this.


When you want to destroy the backing store of a buffer during 
eviction you should just do this by returning an empty placement from 
the evict_flags callback.


So this is for the functionality where the user has indicated that the 
contents is no longer of value, but the buffer itself
is cached until evicted or swapped out for performance reasons. So the 
above would work for eviction, but what about swapout. Could we add 
some similar functionality there?


Amdgpu has the same functionality and you don't need to handle swap at all.

Just return from the evict_flags that you want to drop the backing store 
as soon as the BO leaves the GTT domain.


Christian.



/Thomas



Regards,
Christian.



/Thomas







Thanks,

Thomas








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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping



On 5/18/21 5:28 PM, Christian König wrote:

Am 18.05.21 um 17:20 schrieb Thomas Hellström:


On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction 
time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for 
swapout,

and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to 
keep the
current behaviour for all drivers by returning true if the buffer 
object
is already in the TTM_PL_SYSTEM placement. We change behaviour for 
the
case where a buffer object is in a TT backed placement when 
swapped out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to do 
that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any place 
to put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.


That sounds like a design bug to me since you should never need to do 
this.


When you want to destroy the backing store of a buffer during eviction 
you should just do this by returning an empty placement from the 
evict_flags callback.


So this is for the functionality where the user has indicated that the 
contents is no longer of value, but the buffer itself
is cached until evicted or swapped out for performance reasons. So the 
above would work for eviction, but what about swapout. Could we add some 
similar functionality there?


/Thomas



Regards,
Christian.



/Thomas







Thanks,

Thomas







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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping


Am 18.05.21 um 17:20 schrieb Thomas Hellström:


On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction 
time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for 
swapout,

and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to keep 
the
current behaviour for all drivers by returning true if the buffer 
object

is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped 
out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to do 
that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any place 
to put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.


That sounds like a design bug to me since you should never need to do this.

When you want to destroy the backing store of a buffer during eviction 
you should just do this by returning an empty placement from the 
evict_flags callback.


It is TTMs job to deal with the buffer placement and drivers are no 
longer allowed to mess with that.


Regards,
Christian.



/Thomas







Thanks,

Thomas






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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping



On 5/18/21 5:18 PM, Christian König wrote:



Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction 
time to

determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer 
object

is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped 
out,

in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I 
figure you will push back on that one. What we really need is a 
functionality to just drop the bo contents and end up in system 
memory unpopulated. Should I perhaps add a utility function to do 
that instead? like ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any place to 
put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.


OK, so is that reentrant from the move() or swap_notify() callback.

/Thomas







Thanks,

Thomas





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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping




Am 18.05.21 um 17:15 schrieb Thomas Hellström:


On 5/18/21 10:26 AM, Thomas Hellström wrote:

We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I figure 
you will push back on that one. What we really need is a functionality 
to just drop the bo contents and end up in system memory unpopulated. 
Should I perhaps add a utility function to do that instead? like 
ttm_bo_purge()?


We already have that. Just call ttm_bo_validate() without any place to 
put the buffer.


See how ttm_bo_pipeline_gutting() is used.

Christian.



Thanks,

Thomas




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

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping



On 5/18/21 10:26 AM, Thomas Hellström wrote:

We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.

Add an eviction_valuable call also in the swapout path. Try to keep the
current behaviour for all drivers by returning true if the buffer object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped out,
in which case the drivers normal eviction_valuable path is run.

Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.

Cc: Christian König 
Signed-off-by: Thomas Hellström 


Christian,

Here we have a ttm_tt_unpopulate() export as well at the end. I figure 
you will push back on that one. What we really need is a functionality 
to just drop the bo contents and end up in system memory unpopulated. 
Should I perhaps add a utility function to do that instead? like 
ttm_bo_purge()?


Thanks,

Thomas


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

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

2021-05-18 Thread Matthew Auld

On Tue, 18 May 2021 at 14:21, Christoph Hellwig  wrote:
>
> On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > > Looks like it is caused by the validation failure then.  Which means the
> > > existing code is doing something wrong in its choice of the page
> > > protection bit.  I really need help from the i915 maintainers here..
> >
> > AFAIK there are two users of remap_io_sg, the first is our shmem
> > objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> > mmap modes for userspace. The other user is device local-memory
> > objects(VRAM), and for this one we have an actual io_mapping which is
> > allocated as WC, and IIRC this should only be mapped as WC for the
> > mmap mode, but normal userspace can't hit this path yet.
>
> The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
> Is that device local?

The vm_fault_cpu covers both device local and shmem objects.

>
> > What do we need to do here? It sounds like shmem backed objects are
> > allocated as WB for the pages underneath, but i915 allows mapping them
> > as UC/WC which trips up this track_pfn thing?
>
> To me the warnings looks like system memory is mapped with the wrong
> permissions, yes.  If you want to map it as UC/WC the right set_memory_*
> needs to be used on the kernel mapping as well to ensure that the
> attributes don't conflict.

AFAIK mmap_offset also supports multiple active mmap modes for a given
object, so set_memory_* should still work here?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 13/15] drm/ttm: Add BO and offset arguments for vm_access and vm_fault ttm handlers.



On 5/18/21 1:59 PM, Christian König wrote:

Can you send me the patch directly and not just on CC?

Thanks,
Christian.


Original patch sent. Pls remember to CC lists on reply, though.

The reason we need this is because of i915's strange mmap functionality 
which allows a bo to be mapped at multiple offsets and  the vma->private 
is not a bo...


Thanks,

Thomas






Am 18.05.21 um 10:59 schrieb Thomas Hellström:

+ Christian König

On 5/18/21 10:26 AM, Thomas Hellström wrote:

From: Maarten Lankhorst 

This allows other drivers that may not setup the vma in the same way
to use the ttm bo helpers.

Also clarify the documentation a bit, especially related to 
VM_FAULT_RETRY.


Signed-off-by: Maarten Lankhorst 


Lgtm. Reviewed-by: Thomas Hellström 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c    |  4 +-
  drivers/gpu/drm/nouveau/nouveau_ttm.c  |  4 +-
  drivers/gpu/drm/radeon/radeon_ttm.c    |  4 +-
  drivers/gpu/drm/ttm/ttm_bo_vm.c    | 84 
+-

  drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c |  8 ++-
  include/drm/ttm/ttm_bo_api.h   |  9 ++-
  6 files changed, 75 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index d5a9d7a88315..89dafe14f828 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1919,7 +1919,9 @@ static vm_fault_t amdgpu_ttm_fault(struct 
vm_fault *vmf)

  if (ret)
  goto unlock;
  -    ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+    ret = ttm_bo_vm_fault_reserved(bo, vmf,
+ drm_vma_node_start(>base.vma_node),
+   vmf->vma->vm_page_prot,
 TTM_BO_VM_NUM_PREFAULT, 1);
  if (ret == VM_FAULT_RETRY && !(vmf->flags & 
FAULT_FLAG_RETRY_NOWAIT))

  return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c

index b81ae90b8449..555fb6d8be8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -144,7 +144,9 @@ static vm_fault_t nouveau_ttm_fault(struct 
vm_fault *vmf)

    nouveau_bo_del_io_reserve_lru(bo);
  prot = vm_get_page_prot(vma->vm_flags);
-    ret = ttm_bo_vm_fault_reserved(vmf, prot, 
TTM_BO_VM_NUM_PREFAULT, 1);

+    ret = ttm_bo_vm_fault_reserved(bo, vmf,
+ drm_vma_node_start(>base.vma_node),
+   prot, TTM_BO_VM_NUM_PREFAULT, 1);
  nouveau_bo_add_io_reserve_lru(bo);
  if (ret == VM_FAULT_RETRY && !(vmf->flags & 
FAULT_FLAG_RETRY_NOWAIT))

  return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c

index 3361d11769a2..ba48a2acdef0 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -816,7 +816,9 @@ static vm_fault_t radeon_ttm_fault(struct 
vm_fault *vmf)

  if (ret)
  goto unlock_resv;
  -    ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
+    ret = ttm_bo_vm_fault_reserved(bo, vmf,
+ drm_vma_node_start(>base.vma_node),
+   vmf->vma->vm_page_prot,
 TTM_BO_VM_NUM_PREFAULT, 1);
  if (ret == VM_FAULT_RETRY && !(vmf->flags & 
FAULT_FLAG_RETRY_NOWAIT))

  goto unlock_mclk;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
b/drivers/gpu/drm/ttm/ttm_bo_vm.c

index b31b18058965..ed00ccf1376e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -42,7 +42,7 @@
  #include 
    static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object 
*bo,

-    struct vm_fault *vmf)
+   struct vm_fault *vmf)
  {
  vm_fault_t ret = 0;
  int err = 0;
@@ -122,7 +122,8 @@ static unsigned long ttm_bo_io_mem_pfn(struct 
ttm_buffer_object *bo,

   * Return:
   *    0 on success and the bo was reserved.
   *    VM_FAULT_RETRY if blocking wait.
- *    VM_FAULT_NOPAGE if blocking wait and retrying was not allowed.
+ *    VM_FAULT_NOPAGE if blocking wait and retrying was not 
allowed, or wait interrupted.
+ *    VM_FAULT_SIGBUS if wait on bo->moving failed for reason other 
than a signal.

   */
  vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
   struct vm_fault *vmf)
@@ -254,7 +255,9 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct 
vm_fault *vmf,

    /**
   * ttm_bo_vm_fault_reserved - TTM fault helper
+ * @bo: The buffer object
   * @vmf: The struct vm_fault given as argument to the fault callback
+ * @mmap_base: The base of the mmap, to which the @vmf fault is 
relative to.

   * @prot: The page protection to be used for this memory area.
   * @num_prefault: Maximum number of prefault pages. The caller may 
want to
   * specify this based on madvice settings and the size of the GPU 
object
@@ -265,19 +268,28 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct 
vm_fault *vmf,

   * memory backing the buffer object, and then returns a return code
   * instructing

Re: [Intel-gfx] [PATCH] drm/i915/plane: add intel_plane_helper_add() helper

2021-05-18 Thread Ville Syrjälä

On Tue, May 18, 2021 at 04:24:26PM +0300, Jani Nikula wrote:
> Add a small helper to keep intel_plane_helper_funcs static.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/i9xx_plane.c  | 2 +-
>  drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 7 ++-
>  drivers/gpu/drm/i915/display/intel_atomic_plane.h  | 3 +--
>  drivers/gpu/drm/i915/display/intel_cursor.c| 2 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c| 2 +-
>  drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
>  6 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
> b/drivers/gpu/drm/i915/display/i9xx_plane.c
> index 9643c45a2209..b1439ba78f67 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> @@ -912,7 +912,7 @@ intel_primary_plane_create(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   zpos = 0;
>   drm_plane_create_zpos_immutable_property(>base, zpos);
>  
> - drm_plane_helper_add(>base, _plane_helper_funcs);
> + intel_plane_helper_add(plane);
>  
>   return plane;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 36f52a1d7552..47234d898549 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -601,7 +601,12 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
>   return 0;
>  }
>  
> -const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
> +static const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
>   .prepare_fb = intel_prepare_plane_fb,
>   .cleanup_fb = intel_cleanup_plane_fb,
>  };
> +
> +void intel_plane_helper_add(struct intel_plane *plane)
> +{
> + drm_plane_helper_add(>base, _plane_helper_funcs);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h 
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index dc4d05e75e1c..62e5a2a77fd4 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -17,8 +17,6 @@ struct intel_crtc_state;
>  struct intel_plane;
>  struct intel_plane_state;
>  
> -extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
> -
>  unsigned int intel_adjusted_rate(const struct drm_rect *src,
>const struct drm_rect *dst,
>unsigned int rate);
> @@ -65,5 +63,6 @@ int intel_atomic_plane_check_clipping(struct 
> intel_plane_state *plane_state,
> bool can_position);
>  void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
>  struct intel_plane_state *plane_state);
> +void intel_plane_helper_add(struct intel_plane *plane);
>  
>  #endif /* __INTEL_ATOMIC_PLANE_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index 2ab389b38694..08fa844e1342 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -797,7 +797,7 @@ intel_cursor_plane_create(struct drm_i915_private 
> *dev_priv,
>   if (DISPLAY_VER(dev_priv) >= 12)
>   drm_plane_enable_fb_damage_clips(>base);
>  
> - drm_plane_helper_add(>base, _plane_helper_funcs);
> + intel_plane_helper_add(cursor);
>  
>   return cursor;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 4ae9a7455b23..08116f41da26 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -1856,7 +1856,7 @@ intel_sprite_plane_create(struct drm_i915_private 
> *dev_priv,
>   zpos = sprite + 1;
>   drm_plane_create_zpos_immutable_property(>base, zpos);
>  
> - drm_plane_helper_add(>base, _plane_helper_funcs);
> + intel_plane_helper_add(plane);
>  
>   return plane;
>  
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 59e032f3687a..e9ad050c8a06 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -2152,7 +2152,7 @@ skl_universal_plane_create(struct drm_i915_private 
> *dev_priv,
>   BIT(DRM_SCALING_FILTER_DEFAULT) 
> |
>   
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
>  
> - drm_plane_helper_add(>base, _plane_helper_funcs);
> + intel_plane_helper_add(plane);
>  
>   return plane;
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot



On 5/18/21 3:24 PM, Christoph Hellwig wrote:

On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:

And worse, if we prefault a user-space buffer object map using
remap_io_sg() and then zap some ptes using madvise(), the next time those
ptes are accessed, we'd trigger a new call to remap_io_sg() which would now
find already populated ptes. While the old code looks to just silently
overwrite those, it looks like the new code would BUG in remap_pte_range()?

How can you zap the PTEs using madvise?


Hmm, that's not possible with VM_PFNMAP. My bad. Should be OK then.

/Thomas


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

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

2021-05-18 Thread Nieto, David M

[AMD Official Use Only]

The format is simple:

:  %

we also have entries for the memory mapped:
mem  :  KiB

On my submission 
https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a 
python script to print out the info. It has a CPU usage lower that top, for 
example.

To be absolutely honest, I agree that there is an overhead, but It might not be 
as much as you fear.

From: Tvrtko Ursulin 
Sent: Monday, May 17, 2021 9:00 AM
To: Nieto, David M ; Daniel Vetter ; 
Koenig, Christian 
Cc: Alex Deucher ; Intel Graphics Development 
; Maling list - DRI developers 

Subject: Re: [PATCH 0/7] Per client engine busyness

On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
>
>
> Maybe we could try to standardize how the different submission ring
>   usage gets exposed in the fdinfo? We went the simple way of just
> adding name and index, but if someone has a suggestion on how else we
> could format them so there is commonality across vendors we could just
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage
> regardless of what vendor is installed.

Definitely.

Regards,

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

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

2021-05-18 Thread Nieto, David M

[Public]

Cycling some of the Nvidia/nouveau guys here too.

I think there is a benefit on trying to estandarize how fdinfo can be used to 
expose per engine and device memory utilization.

Another of the advantages of going the /proc/ way instead of the sysfs debugfs 
approach is that you inherit the access lists directly from the distribution 
and you don't need to start messing with ownership and group access. By default 
an user can monitor its own processes as long as /proc is mounted.

I am not saying that fdinfo or the way we implemented is 100% the way to go, 
but I'd rather have a solution within the confines of proc first.

David

From: Nieto, David M 
Sent: Monday, May 17, 2021 11:02 AM
To: Tvrtko Ursulin ; Daniel Vetter 
; Koenig, Christian 
Cc: Alex Deucher ; Intel Graphics Development 
; Maling list - DRI developers 

Subject: Re: [PATCH 0/7] Per client engine busyness

The format is simple:

:  %

we also have entries for the memory mapped:
mem  :  KiB

On my submission 
https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a 
python script to print out the info. It has a CPU usage lower that top, for 
example.

To be absolutely honest, I agree that there is an overhead, but It might not be 
as much as you fear.

From: Tvrtko Ursulin 
Sent: Monday, May 17, 2021 9:00 AM
To: Nieto, David M ; Daniel Vetter ; 
Koenig, Christian 
Cc: Alex Deucher ; Intel Graphics Development 
; Maling list - DRI developers 

Subject: Re: [PATCH 0/7] Per client engine busyness

On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
>
>
> Maybe we could try to standardize how the different submission ring
>   usage gets exposed in the fdinfo? We went the simple way of just
> adding name and index, but if someone has a suggestion on how else we
> could format them so there is commonality across vendors we could just
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage
> regardless of what vendor is installed.

Definitely.

Regards,

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

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem


Am 18.05.21 um 15:24 schrieb Thomas Hellström:


On 5/18/21 3:08 PM, Christian König wrote:

Am 18.05.21 um 14:52 schrieb Thomas Hellström:


On 5/18/21 2:09 PM, Christian König wrote:

Am 18.05.21 um 14:04 schrieb Thomas Hellström:


On 5/18/21 1:55 PM, Christian König wrote:



Am 18.05.21 um 10:26 schrieb Thomas Hellström:
The internal ttm_bo_util memcpy uses vmap functionality, and 
while it

probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / 
io_mem_free()

callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional 
global
TLB flushes of vmap() and consuming vmap space, elimination of a 
critical
point of failure and with a slight change of semantics we could 
also push
the memcpy out async for testing and async driver develpment 
purposes.
Pushing out async can be done since there is no memory 
allocation going on

that could violate the dma_fence lockdep rules.

For copies from iomem, use the WC prefetching memcpy variant for
additional speed.

Note that drivers that don't want to use struct io_mapping but 
relies on

memremap functionality, and that don't want to use scatterlists for
VRAM may well define specialized (hopefully reusable) iterators 
for their

particular environment.


In general yes please since I have that as TODO for TTM for a 
very long time.


But I would prefer to fix the implementation in TTM instead and 
give it proper cursor handling.


Amdgpu is also using page based iomem and we are having similar 
workarounds in place there as well.


I think it makes sense to unify this inside TTM and remove the 
old memcpy util function when done.


Regards,
Christian.


Christian,

I was thinking when we replace the bo.mem with a pointer (and 
perhaps have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all 
mapping in one way or another). That would mean perhaps land this 
is i915 now and sort out the unification once the struct 
ttm_resource, struct ttm_buffer_object separation has landed?


That stuff is ready, reviewed and I'm just waiting for some amdgpu 
changes to land in drm-misc-next to push it.


But yes in general an iterator for the resource object sounds like 
the right plan to me as well.


Christian.


OK, so then are you OK with landing this in i915 for now? That would 
also ofc mean the export you NAK'd but strictly for this memcpy use 
until we merge it with TTM?


Well you can of course prototype that in i915, but I really don't 
want to export the TT functions upstream.


I understand, I once had the same thoughts trying to avoid that as far 
as possible, so this function was actually then added to the ttm_bo 
interface, (hence the awkward naming) as a helper for drivers 
implementing move(), essentially a very special case of 
ttm_bo_move_accel_cleanup(), but anyway, see below:




Can we cleanly move that functionality into TTM instead?


I'll take a look at that, but I think we'd initially be having 
iterators mimicing the current move_memcpy() for the

linear iomem !WC cases, hope that's OK.


Yeah, that's peefectly fine with me. I can tackle cleaning up all 
drivers and move over to the new implementation when that is fully complete.


As I said we already have the same problem in amdgpu and only solved it 
by avoiding memcpy all together.


Christian.



/Thomas




Christian.




/Thomas





/Thomas








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

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem



On 5/18/21 3:08 PM, Christian König wrote:

Am 18.05.21 um 14:52 schrieb Thomas Hellström:


On 5/18/21 2:09 PM, Christian König wrote:

Am 18.05.21 um 14:04 schrieb Thomas Hellström:


On 5/18/21 1:55 PM, Christian König wrote:



Am 18.05.21 um 10:26 schrieb Thomas Hellström:
The internal ttm_bo_util memcpy uses vmap functionality, and 
while it

probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional 
global
TLB flushes of vmap() and consuming vmap space, elimination of a 
critical
point of failure and with a slight change of semantics we could 
also push
the memcpy out async for testing and async driver develpment 
purposes.
Pushing out async can be done since there is no memory allocation 
going on

that could violate the dma_fence lockdep rules.

For copies from iomem, use the WC prefetching memcpy variant for
additional speed.

Note that drivers that don't want to use struct io_mapping but 
relies on

memremap functionality, and that don't want to use scatterlists for
VRAM may well define specialized (hopefully reusable) iterators 
for their

particular environment.


In general yes please since I have that as TODO for TTM for a very 
long time.


But I would prefer to fix the implementation in TTM instead and 
give it proper cursor handling.


Amdgpu is also using page based iomem and we are having similar 
workarounds in place there as well.


I think it makes sense to unify this inside TTM and remove the old 
memcpy util function when done.


Regards,
Christian.


Christian,

I was thinking when we replace the bo.mem with a pointer (and 
perhaps have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all 
mapping in one way or another). That would mean perhaps land this 
is i915 now and sort out the unification once the struct 
ttm_resource, struct ttm_buffer_object separation has landed?


That stuff is ready, reviewed and I'm just waiting for some amdgpu 
changes to land in drm-misc-next to push it.


But yes in general an iterator for the resource object sounds like 
the right plan to me as well.


Christian.


OK, so then are you OK with landing this in i915 for now? That would 
also ofc mean the export you NAK'd but strictly for this memcpy use 
until we merge it with TTM?


Well you can of course prototype that in i915, but I really don't want 
to export the TT functions upstream.


I understand, I once had the same thoughts trying to avoid that as far 
as possible, so this function was actually then added to the ttm_bo 
interface, (hence the awkward naming) as a helper for drivers 
implementing move(), essentially a very special case of 
ttm_bo_move_accel_cleanup(), but anyway, see below:




Can we cleanly move that functionality into TTM instead?


I'll take a look at that, but I think we'd initially be having iterators 
mimicing the current move_memcpy() for the

linear iomem !WC cases, hope that's OK.

/Thomas




Christian.




/Thomas





/Thomas







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

[Intel-gfx] [PATCH] drm/i915/plane: add intel_plane_helper_add() helper

2021-05-18 Thread Jani Nikula

Add a small helper to keep intel_plane_helper_funcs static.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c  | 2 +-
 drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 7 ++-
 drivers/gpu/drm/i915/display/intel_atomic_plane.h  | 3 +--
 drivers/gpu/drm/i915/display/intel_cursor.c| 2 +-
 drivers/gpu/drm/i915/display/intel_sprite.c| 2 +-
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
 6 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 9643c45a2209..b1439ba78f67 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -912,7 +912,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
zpos = 0;
drm_plane_create_zpos_immutable_property(>base, zpos);
 
-   drm_plane_helper_add(>base, _plane_helper_funcs);
+   intel_plane_helper_add(plane);
 
return plane;
 
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 36f52a1d7552..47234d898549 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -601,7 +601,12 @@ int intel_atomic_plane_check_clipping(struct 
intel_plane_state *plane_state,
return 0;
 }
 
-const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
+static const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
 };
+
+void intel_plane_helper_add(struct intel_plane *plane)
+{
+   drm_plane_helper_add(>base, _plane_helper_funcs);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index dc4d05e75e1c..62e5a2a77fd4 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -17,8 +17,6 @@ struct intel_crtc_state;
 struct intel_plane;
 struct intel_plane_state;
 
-extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
-
 unsigned int intel_adjusted_rate(const struct drm_rect *src,
 const struct drm_rect *dst,
 unsigned int rate);
@@ -65,5 +63,6 @@ int intel_atomic_plane_check_clipping(struct 
intel_plane_state *plane_state,
  bool can_position);
 void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
   struct intel_plane_state *plane_state);
+void intel_plane_helper_add(struct intel_plane *plane);
 
 #endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 2ab389b38694..08fa844e1342 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -797,7 +797,7 @@ intel_cursor_plane_create(struct drm_i915_private *dev_priv,
if (DISPLAY_VER(dev_priv) >= 12)
drm_plane_enable_fb_damage_clips(>base);
 
-   drm_plane_helper_add(>base, _plane_helper_funcs);
+   intel_plane_helper_add(cursor);
 
return cursor;
 
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 4ae9a7455b23..08116f41da26 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -1856,7 +1856,7 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
zpos = sprite + 1;
drm_plane_create_zpos_immutable_property(>base, zpos);
 
-   drm_plane_helper_add(>base, _plane_helper_funcs);
+   intel_plane_helper_add(plane);
 
return plane;
 
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c 
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 59e032f3687a..e9ad050c8a06 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2152,7 +2152,7 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
BIT(DRM_SCALING_FILTER_DEFAULT) 
|

BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
 
-   drm_plane_helper_add(>base, _plane_helper_funcs);
+   intel_plane_helper_add(plane);
 
return plane;
 
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

2021-05-18 Thread Christoph Hellwig

On Tue, May 18, 2021 at 08:46:44AM +0200, Thomas Hellström wrote:
> And worse, if we prefault a user-space buffer object map using 
> remap_io_sg() and then zap some ptes using madvise(), the next time those 
> ptes are accessed, we'd trigger a new call to remap_io_sg() which would now 
> find already populated ptes. While the old code looks to just silently 
> overwrite those, it looks like the new code would BUG in remap_pte_range()?

How can you zap the PTEs using madvise?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

2021-05-18 Thread Christoph Hellwig

On Mon, May 17, 2021 at 11:46:35PM +0200, Thomas Hellström wrote:
> Apart from the caching aliasing Mattew brought up, doesn't the 
> remap_pfn_range_xxx() family require the mmap_sem held in write mode since 
> it modifies the vma structure? remap_io_sg() is called from the fault 
> handler with the mmap_sem held in read mode only.

Only for vma->vm_flags, and remap_sg already asserts all the interesting
flags are set, although it does not assert VM_IO.

We could move the assignment out of remap_pfn_range_notrack and
into remap_pfn_range and just assert that the proper flags are set,
though.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

2021-05-18 Thread Christoph Hellwig

On Mon, May 17, 2021 at 06:06:44PM +0100, Matthew Auld wrote:
> > Looks like it is caused by the validation failure then.  Which means the
> > existing code is doing something wrong in its choice of the page
> > protection bit.  I really need help from the i915 maintainers here..
> 
> AFAIK there are two users of remap_io_sg, the first is our shmem
> objects(see i915_gem_shmem.c), and for these we support UC, WC, and WB
> mmap modes for userspace. The other user is device local-memory
> objects(VRAM), and for this one we have an actual io_mapping which is
> allocated as WC, and IIRC this should only be mapped as WC for the
> mmap mode, but normal userspace can't hit this path yet.

The only caller in current mainline is vm_fault_cpu in i915_gem_mman.c.
Is that device local?

> What do we need to do here? It sounds like shmem backed objects are
> allocated as WB for the pages underneath, but i915 allows mapping them
> as UC/WC which trips up this track_pfn thing?

To me the warnings looks like system memory is mapped with the wrong
permissions, yes.  If you want to map it as UC/WC the right set_memory_*
needs to be used on the kernel mapping as well to ensure that the
attributes don't conflict.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 04/15] drm/ttm: Export functions to initialize and finalize the ttm range manager standalone




Am 18.05.21 um 15:06 schrieb Thomas Hellström:


On 5/18/21 1:51 PM, Christian König wrote:

Am 18.05.21 um 10:26 schrieb Thomas Hellström:
i915 mock selftests are run without the device set up. In order to 
be able
to run the region related mock selftests, export functions in order 
for the

TTM range manager to be set up without a device to attach it to.


From the code it looks good, but to be honest I don't think that this 
makes much sense from the organizational point of view.


If a self test exercises internals of TTM it should be moved into TTM 
as well.


This particular selftest actually exercises i915 memory regions which 
is a level above TTM, but the memory regions are backed by TTM. Since 
they are mock selftests they don't have a TTM device. For the buddy 
allocator the situation would be the same, but there we have selftests 
that exercise the allocator standalone, and those would probably fit 
best into a TTM selftest infrastructure.


Although in this particular case, we could of course add a mock TTM 
device and be done. Pls let me know what you think.


Well if you can do that with a dummy device then that would certainly be 
the preferred option.


Christian.



/Thomas




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

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem


Am 18.05.21 um 14:52 schrieb Thomas Hellström:


On 5/18/21 2:09 PM, Christian König wrote:

Am 18.05.21 um 14:04 schrieb Thomas Hellström:


On 5/18/21 1:55 PM, Christian König wrote:



Am 18.05.21 um 10:26 schrieb Thomas Hellström:

The internal ttm_bo_util memcpy uses vmap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional 
global
TLB flushes of vmap() and consuming vmap space, elimination of a 
critical
point of failure and with a slight change of semantics we could 
also push
the memcpy out async for testing and async driver develpment 
purposes.
Pushing out async can be done since there is no memory allocation 
going on

that could violate the dma_fence lockdep rules.

For copies from iomem, use the WC prefetching memcpy variant for
additional speed.

Note that drivers that don't want to use struct io_mapping but 
relies on

memremap functionality, and that don't want to use scatterlists for
VRAM may well define specialized (hopefully reusable) iterators 
for their

particular environment.


In general yes please since I have that as TODO for TTM for a very 
long time.


But I would prefer to fix the implementation in TTM instead and 
give it proper cursor handling.


Amdgpu is also using page based iomem and we are having similar 
workarounds in place there as well.


I think it makes sense to unify this inside TTM and remove the old 
memcpy util function when done.


Regards,
Christian.


Christian,

I was thinking when we replace the bo.mem with a pointer (and 
perhaps have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all 
mapping in one way or another). That would mean perhaps land this is 
i915 now and sort out the unification once the struct ttm_resource, 
struct ttm_buffer_object separation has landed?


That stuff is ready, reviewed and I'm just waiting for some amdgpu 
changes to land in drm-misc-next to push it.


But yes in general an iterator for the resource object sounds like 
the right plan to me as well.


Christian.


OK, so then are you OK with landing this in i915 for now? That would 
also ofc mean the export you NAK'd but strictly for this memcpy use 
until we merge it with TTM?


Well you can of course prototype that in i915, but I really don't want 
to export the TT functions upstream.


Can we cleanly move that functionality into TTM instead?

Christian.




/Thomas





/Thomas






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

Re: [Intel-gfx] [PATCH v2 04/15] drm/ttm: Export functions to initialize and finalize the ttm range manager standalone



On 5/18/21 1:51 PM, Christian König wrote:

Am 18.05.21 um 10:26 schrieb Thomas Hellström:
i915 mock selftests are run without the device set up. In order to be 
able
to run the region related mock selftests, export functions in order 
for the

TTM range manager to be set up without a device to attach it to.


From the code it looks good, but to be honest I don't think that this 
makes much sense from the organizational point of view.


If a self test exercises internals of TTM it should be moved into TTM 
as well.


This particular selftest actually exercises i915 memory regions which is 
a level above TTM, but the memory regions are backed by TTM. Since they 
are mock selftests they don't have a TTM device. For the buddy allocator 
the situation would be the same, but there we have selftests that 
exercise the allocator standalone, and those would probably fit best 
into a TTM selftest infrastructure.


Although in this particular case, we could of course add a mock TTM 
device and be done. Pls let me know what you think.


/Thomas


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

Re: [Intel-gfx] [PATCH] drm/i915/gt: Disable HiZ Raw Stall Optimization on broken gen7

2021-05-18 Thread Rodrigo Vivi

On Tue, May 18, 2021 at 10:30:25AM +0200, Simon Rettberg wrote:
> Am Thu, 13 May 2021 07:30:17 -0400
> schrieb Rodrigo Vivi :
> 
> > On Thu, May 13, 2021 at 10:18:49AM +1000, Dave Airlie wrote:
> > > Reviewed-by: Dave Airlie 
> > > 
> > > Can we get this fix in, having a regression spanning 3 kernels
> > > isn't a good look, we can work out why it matters later in life if
> > > anyone cares.  
> > 
> > Agreed and pushed do drm-intel-next.
> 
> What's the status here? I can't seem to find the fix in drm-intel-next.

ouch! face-palm for myself.

I hit the push and never looked back:

$ dim push-queued
dim: 153dfcd6b299 ("drm/i915/gt: Disable HiZ Raw Stall Optimization on broken 
gen7"): SHA1 in fixes line not found:
dim: 520d05a77b28 ("drm/i915/gt: Clear CACHE_MODE prior to clearing 
residuals")
dim: ERROR: issues in commits detected, aborting

now I removed the invalid fixes line and pushed...

Thank you so much for noticing this.

Sorry,
Rodrigo.

> 
> - Simon
> 
> > 
> > This triggered me to do an archeology work here and I found a possible
> > alternative for ILK:
> > 
> > +#define   HIZ_UNIT_CLOCK_GATE_DISABLE  REG_BIT(5)
> >  
> >  #define FDI_PLL_FREQ_CTL_MMIO(0x46030)
> >  #define  FDI_PLL_FREQ_CHANGE_REQUEST(1 << 24)
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c index 06d5b7cc8b62..6316b70978f7
> > 100644 --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6892,8 +6892,11 @@ static void ilk_init_clock_gating(struct
> > drm_i915_private *dev_priv) intel_uncore_write(_priv->uncore,
> > PCH_3DCGDIS0, MARIUNIT_CLOCK_GATE_DISABLE |
> >SVSMUNIT_CLOCK_GATE_DISABLE);
> > +
> > +   /* WaDisableHizUnitClockGating:ilk */
> > intel_uncore_write(_priv->uncore, PCH_3DCGDIS1,
> > -  VFMUNIT_CLOCK_GATE_DISABLE);
> > +  VFMUNIT_CLOCK_GATE_DISABLE |
> > +  HIZ_UNIT_CLOCK_GATE_DISABLE);
> > 
> > however I couldn't find anything for Baytrail, so let's move with this
> > one for now.
> > 
> > > 
> > > Dave.
> > > 
> > > On Tue, 27 Apr 2021 at 00:31, Simon Rettberg
> > >  wrote:  
> > > >
> > > > When resetting CACHE_MODE registers, don't enable HiZ Raw Stall
> > > > Optimization on Ivybridge GT1 and Baytrail, as it causes severe
> > > > glitches when rendering any kind of 3D accelerated content.
> > > > This optimization is disabled on these platforms by default
> > > > according to official documentation from 01.org.
> > > >
> > > > Fixes: ef99a60ffd9b ("drm/i915/gt: Clear CACHE_MODE prior to
> > > > clearing residuals") Fixes: 520d05a77b28 ("drm/i915/gt: Clear
> > > > CACHE_MODE prior to clearing residuals") BugLink:
> > > > https://gitlab.freedesktop.org/drm/intel/-/issues/3081 BugLink:
> > > > https://gitlab.freedesktop.org/drm/intel/-/issues/3404 BugLink:
> > > > https://gitlab.freedesktop.org/drm/intel/-/issues/3071
> > > > Reviewed-By: Manuel Bentele 
> > > > Signed-off-by: Simon Rettberg 
> > > > --- drivers/gpu/drm/i915/gt/gen7_renderclear.c | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> > > > b/drivers/gpu/drm/i915/gt/gen7_renderclear.c index
> > > > de575fdb0..21f08e538 100644 ---
> > > > a/drivers/gpu/drm/i915/gt/gen7_renderclear.c +++
> > > > b/drivers/gpu/drm/i915/gt/gen7_renderclear.c @@ -397,7 +397,10 @@
> > > > static void emit_batch(struct i915_vma * const vma,
> > > > gen7_emit_pipeline_invalidate(); batch_add(,
> > > > MI_LOAD_REGISTER_IMM(2)); batch_add(,
> > > > i915_mmio_reg_offset(CACHE_MODE_0_GEN7));
> > > > -   batch_add(, 0x);
> > > > +   batch_add(, 0x |
> > > > +   ((IS_IVB_GT1(i915) ||
> > > > IS_VALLEYVIEW(i915)) ?
> > > > +HIZ_RAW_STALL_OPT_DISABLE :
> > > > +0));
> > > > batch_add(, i915_mmio_reg_offset(CACHE_MODE_1));
> > > > batch_add(, 0x |
> > > > PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
> > > > gen7_emit_pipeline_invalidate(); --
> > > > 2.25.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx  
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx  
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem



On 5/18/21 2:09 PM, Christian König wrote:

Am 18.05.21 um 14:04 schrieb Thomas Hellström:


On 5/18/21 1:55 PM, Christian König wrote:



Am 18.05.21 um 10:26 schrieb Thomas Hellström:

The internal ttm_bo_util memcpy uses vmap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional 
global
TLB flushes of vmap() and consuming vmap space, elimination of a 
critical
point of failure and with a slight change of semantics we could 
also push

the memcpy out async for testing and async driver develpment purposes.
Pushing out async can be done since there is no memory allocation 
going on

that could violate the dma_fence lockdep rules.

For copies from iomem, use the WC prefetching memcpy variant for
additional speed.

Note that drivers that don't want to use struct io_mapping but 
relies on

memremap functionality, and that don't want to use scatterlists for
VRAM may well define specialized (hopefully reusable) iterators for 
their

particular environment.


In general yes please since I have that as TODO for TTM for a very 
long time.


But I would prefer to fix the implementation in TTM instead and give 
it proper cursor handling.


Amdgpu is also using page based iomem and we are having similar 
workarounds in place there as well.


I think it makes sense to unify this inside TTM and remove the old 
memcpy util function when done.


Regards,
Christian.


Christian,

I was thinking when we replace the bo.mem with a pointer (and perhaps 
have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all 
mapping in one way or another). That would mean perhaps land this is 
i915 now and sort out the unification once the struct ttm_resource, 
struct ttm_buffer_object separation has landed?


That stuff is ready, reviewed and I'm just waiting for some amdgpu 
changes to land in drm-misc-next to push it.


But yes in general an iterator for the resource object sounds like the 
right plan to me as well.


Christian.


OK, so then are you OK with landing this in i915 for now? That would 
also ofc mean the export you NAK'd but strictly for this memcpy use 
until we merge it with TTM?


/Thomas





/Thomas





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

Re: [Intel-gfx] [PATCH] drm/i915: only disable default vga device

2021-05-18 Thread Emil Velikov

On Tue, 18 May 2021 at 12:17, Ville Syrjälä
 wrote:
>
> On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote:
> > Hi Ville,
> >
> > On Mon, 17 May 2021 at 18:24, Ville Syrjälä
> >  wrote:
> > >
> > > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote:
> > > > From: Vivek Das Mohapatra 
> > > >
> > > > This patch is to do with seamless handover, eg when the sequence is
> > > > bootloader → plymouth → desktop.
> > > >
> > > > It switches the vga arbiter from the "other" GPU to the default one
> > > > (intel in this case), so the driver can issue some io().
> > >
> > > I don't understand what this commit message is trying to say.
> > >
> > Bunch of context is lost due to the patch age, so I'm not 100% sure of
> > the actual hardware setup where this occurs.
> > Does the following make sense?
> >
> > Currently on dual GPU systems, we do not get seamless handover as the
> > output flickers during the transition bootloader -> plymouth ->
> > desktop.
> > This happens as a result of switching (via the VGA arbiter) from the
> > "other" GPU back to the default i915 one and issuing io() commands.
>
> Hmm. Does this work?
>
Thanks I'll it give it a try. Might need a few days to find the right
hardware/software combination.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/reg: replace BIT() usage with REG_BIT()

== Series Details ==

Series: drm/i915/reg: replace BIT() usage with REG_BIT()
URL   : https://patchwork.freedesktop.org/series/90270/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10095 -> Patchwork_20143


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20143 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20143, 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_20143/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3:
- fi-snb-2600:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fence@basic-await@rcs0:
- fi-elk-e7500:   [PASS][3] -> [FAIL][4] ([i915#3457])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@rcs0.html
- fi-bsw-n3050:   [PASS][5] -> [FAIL][6] ([i915#3457])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@rcs0.html

  * igt@gem_exec_fence@basic-await@vecs0:
- fi-bsw-kefka:   [PASS][7] -> [FAIL][8] ([i915#3457]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-bsw-kefka/igt@gem_exec_fence@basic-aw...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-bsw-kefka/igt@gem_exec_fence@basic-aw...@vecs0.html

  * igt@gem_exec_fence@nb-await@vecs0:
- fi-apl-guc: [PASS][9] -> [FAIL][10] ([i915#3457]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-apl-guc/igt@gem_exec_fence@nb-aw...@vecs0.html

  * igt@gem_wait@busy@all:
- fi-bsw-kefka:   [PASS][11] -> [FAIL][12] ([i915#3177] / [i915#3457])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-bsw-kefka/igt@gem_wait@b...@all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-bsw-kefka/igt@gem_wait@b...@all.html

  * igt@kms_busy@basic@modeset:
- fi-ilk-650: [PASS][13] -> [INCOMPLETE][14] ([i915#3457])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-ilk-650/igt@kms_busy@ba...@modeset.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-ilk-650/igt@kms_busy@ba...@modeset.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][15] -> [FAIL][16] ([i915#49])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-bwr-2160:[PASS][17] -> [FAIL][18] ([i915#53])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-bwr-2160/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-bwr-2160/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html

  
 Possible fixes 

  * igt@gem_exec_fence@basic-await@bcs0:
- fi-bsw-n3050:   [FAIL][19] ([i915#3457]) -> [PASS][20] +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-bsw-n3050/igt@gem_exec_fence@basic-aw...@bcs0.html

  * igt@gem_exec_fence@basic-await@vcs0:
- fi-glk-dsi: [FAIL][21] ([i915#3457]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10095/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20143/fi-glk-dsi/igt@gem_exec_fence@basic-aw...@vcs0.html

  * igt@gem_exec_fence@nb-await@bcs0:
- fi-bsw-nick:[FAIL][23] ([i915#3457]) -> [PASS][24] +2 similar 
issues
   [23]:

Re: [Intel-gfx] [PATCH v4 11/23] drm/i915/adl_p: Add ddb allocation support

2021-05-18 Thread Lisovskiy, Stanislav

On Fri, May 14, 2021 at 08:10:23PM -0700, Matt Roper wrote:
> From: Vandita Kulkarni 
> 
> On adlp the two mbuses have two display pipes and
> two DBUFS, Pipe A and D on Mbus1 and Pipe B and C on
> Mbus2. The Mbus can be joined and all the DBUFS can be
> used on Pipe A or B.

Reviewed-by: Stanislav Lisovskiy 

> 
> Bspec: 49255
> Cc: Anusha Srivatsa 
> Signed-off-by: Vandita Kulkarni 
> Signed-off-by: Clinton Taylor 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  22 --
>  drivers/gpu/drm/i915/intel_pm.c | 121 +++-
>  2 files changed, 138 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 65af0d84d75b..47be6054d480 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7308,7 +7308,7 @@ enum {
>  
>  #define _PLANE_BUF_CFG_1_B   0x7127c
>  #define _PLANE_BUF_CFG_2_B   0x7137c
> -#define  DDB_ENTRY_MASK  0x7FF /* skl+: 10 bits, 
> icl+ 11 bits */
> +#define  DDB_ENTRY_MASK  0xFFF /* skl+: 10 bits, 
> icl+ 11 bits, adlp+ 12 bits */
>  #define  DDB_ENTRY_END_SHIFT 16
>  #define _PLANE_BUF_CFG_1(pipe)   \
>   _PIPE(pipe, _PLANE_BUF_CFG_1_A, _PLANE_BUF_CFG_1_B)
> @@ -8145,9 +8145,23 @@ enum {
>  #define  DISP_DATA_PARTITION_5_6 (1 << 6)
>  #define  DISP_IPC_ENABLE (1 << 3)
>  
> -#define _DBUF_CTL_S1 0x45008
> -#define _DBUF_CTL_S2 0x44FE8
> -#define DBUF_CTL_S(slice)_MMIO(_PICK_EVEN(slice, 
> _DBUF_CTL_S1, _DBUF_CTL_S2))
> +/*
> + * The below are numbered starting from "S1" on gen11/gen12, but starting
> + * with gen13 display, the bspec switches to a 0-based numbering scheme
> + * (although the addresses stay the same so new S0 = old S1, new S1 = old 
> S2).
> + * We'll just use the 0-based numbering here for all platforms since it's the
> + * way things will be named by the hardware team going forward, plus it's 
> more
> + * consistent with how most of the rest of our registers are named.
> + */
> +#define _DBUF_CTL_S0 0x45008
> +#define _DBUF_CTL_S1 0x44FE8
> +#define _DBUF_CTL_S2 0x44300
> +#define _DBUF_CTL_S3 0x44304
> +#define DBUF_CTL_S(slice)_MMIO(_PICK(slice, \
> + _DBUF_CTL_S0, \
> + _DBUF_CTL_S1, \
> + _DBUF_CTL_S2, \
> + _DBUF_CTL_S3))
>  #define  DBUF_POWER_REQUEST  REG_BIT(31)
>  #define  DBUF_POWER_STATEREG_BIT(30)
>  #define  DBUF_TRACKER_STATE_SERVICE_MASK REG_GENMASK(23, 19)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 95fda20d5547..411ec468d02a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4558,6 +4558,118 @@ static const struct dbuf_slice_conf_entry 
> tgl_allowed_dbufs[] =
>   {}
>  };
>  
> +static const struct dbuf_slice_conf_entry adlp_allowed_dbufs[] = {
> + {
> + .active_pipes = BIT(PIPE_A),
> + .dbuf_mask = {
> + [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_B),
> + .dbuf_mask = {
> + [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_A) | BIT(PIPE_B),
> + .dbuf_mask = {
> + [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
> + [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_C),
> + .dbuf_mask = {
> + [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_A) | BIT(PIPE_C),
> + .dbuf_mask = {
> + [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
> + [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_B) | BIT(PIPE_C),
> + .dbuf_mask = {
> + [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },
> + },
> + {
> + .active_pipes = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
> + .dbuf_mask = {
> + [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
> + [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + [PIPE_C] = BIT(DBUF_S3) | BIT(DBUF_S4),
> + },

Re: [Intel-gfx] [PATCH v2 09/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping

2021-05-18 Thread Maarten Lankhorst

Op 18-05-2021 om 10:26 schreef Thomas Hellström:
> We are calling the eviction_valuable driver callback at eviction time to
> determine whether we actually can evict a buffer object.
> The upcoming i915 TTM backend needs the same functionality for swapout,
> and that might actually be beneficial to other drivers as well.
>
> Add an eviction_valuable call also in the swapout path. Try to keep the
> current behaviour for all drivers by returning true if the buffer object
> is already in the TTM_PL_SYSTEM placement. We change behaviour for the
> case where a buffer object is in a TT backed placement when swapped out,
> in which case the drivers normal eviction_valuable path is run.
>
> Finally export ttm_tt_unpopulate() and don't swap out bos
> that are not populated. This allows a driver to purge a bo at
> swapout time if its content is no longer valuable rather than to
> have TTM swap the contents out.
>
> Cc: Christian König 
> Signed-off-by: Thomas Hellström 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  4 +++
>  drivers/gpu/drm/ttm/ttm_bo.c| 41 +++--
>  drivers/gpu/drm/ttm/ttm_tt.c|  4 +++
>  3 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 8c7ec09eb1a4..d5a9d7a88315 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1399,6 +1399,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct 
> ttm_buffer_object *bo,
>   struct dma_fence *f;
>   int i;
>  
> + /* Swapout? */
> + if (bo->mem.mem_type == TTM_PL_SYSTEM)
> + return true;
> +
>   if (bo->type == ttm_bo_type_kernel &&
>   !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo)))
>   return false;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 4479c55aaa1d..6a3f3112f62a 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -531,6 +531,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
>  bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> const struct ttm_place *place)
>  {
> + dma_resv_assert_held(bo->base.resv);
> + if (bo->mem.mem_type == TTM_PL_SYSTEM)
> + return true;
> +
>   /* Don't evict this BO if it's outside of the
>* requested placement range
>*/
> @@ -553,7 +557,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>   * b. Otherwise, trylock it.
>   */
>  static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
> +struct ttm_operation_ctx *ctx,
> +const struct ttm_place *place,
> +bool *locked, bool *busy)
>  {
>   bool ret = false;
>  
> @@ -571,6 +577,12 @@ static bool ttm_bo_evict_swapout_allowable(struct 
> ttm_buffer_object *bo,
>   *busy = !ret;
>   }
>  
> + if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) {
> + ret = false;
> + if (locked)
> + dma_resv_unlock(bo->base.resv);
> + }

Probably meant to check and clear *locked here?

With that fixed:

Reviewed-by: Maarten Lankhorst 

> +
>   return ret;
>  }
>  
> @@ -625,20 +637,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
>   list_for_each_entry(bo, >lru[i], lru) {
>   bool busy;
>  
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
> - )) {
> + if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
> + , )) {
>   if (busy && !busy_bo && ticket !=
>   dma_resv_locking_ctx(bo->base.resv))
>   busy_bo = bo;
>   continue;
>   }
>  
> - if (place && !bdev->funcs->eviction_valuable(bo,
> -   place)) {
> - if (locked)
> - dma_resv_unlock(bo->base.resv);
> - continue;
> - }
>   if (!ttm_bo_get_unless_zero(bo)) {
>   if (locked)
>   dma_resv_unlock(bo->base.resv);
> @@ -1138,10 +1144,18 @@ EXPORT_SYMBOL(ttm_bo_wait);
>  int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx 
> *ctx,
>  gfp_t gfp_flags)
>  {
> + struct ttm_place place = {};
>   bool locked;
>   int ret;
>  
> - if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem


Am 18.05.21 um 14:04 schrieb Thomas Hellström:


On 5/18/21 1:55 PM, Christian König wrote:



Am 18.05.21 um 10:26 schrieb Thomas Hellström:

The internal ttm_bo_util memcpy uses vmap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-by-page using kmap_local()
semantics. As an additional benefit we then avoid the occasional global
TLB flushes of vmap() and consuming vmap space, elimination of a 
critical
point of failure and with a slight change of semantics we could also 
push

the memcpy out async for testing and async driver develpment purposes.
Pushing out async can be done since there is no memory allocation 
going on

that could violate the dma_fence lockdep rules.

For copies from iomem, use the WC prefetching memcpy variant for
additional speed.

Note that drivers that don't want to use struct io_mapping but 
relies on

memremap functionality, and that don't want to use scatterlists for
VRAM may well define specialized (hopefully reusable) iterators for 
their

particular environment.


In general yes please since I have that as TODO for TTM for a very 
long time.


But I would prefer to fix the implementation in TTM instead and give 
it proper cursor handling.


Amdgpu is also using page based iomem and we are having similar 
workarounds in place there as well.


I think it makes sense to unify this inside TTM and remove the old 
memcpy util function when done.


Regards,
Christian.


Christian,

I was thinking when we replace the bo.mem with a pointer (and perhaps 
have a driver callback to allocate the bo->mem,
we could perhaps embed a struct ttm_kmap_iter and use it for all 
mapping in one way or another). That would mean perhaps land this is 
i915 now and sort out the unification once the struct ttm_resource, 
struct ttm_buffer_object separation has landed?


That stuff is ready, reviewed and I'm just waiting for some amdgpu 
changes to land in drm-misc-next to push it.


But yes in general an iterator for the resource object sounds like the 
right plan to me as well.


Christian.



/Thomas




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

Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness

Am 18.05.21 um 11:35 schrieb Tvrtko Ursulin:

On 17/05/2021 19:02, Nieto, David M wrote:

[AMD Official Use Only]

The format is simple:

: %

Hm what time period does the percent relate to?

The i915 implementation uses accumulated nanoseconds active. That way
who reads the file can calculate the percentage relative to the time
period between two reads of the file.

That sounds much saner to me as well. The percentage calculation inside
the kernel looks suspiciously misplaced.

we also have entries for the memory mapped:
mem : KiB

Okay so in general key values per line in text format. Colon as
delimiter.

What common fields could be useful between different drivers and what
common naming scheme, in order to enable as easy as possible creation
of a generic top-like tool?

driver:
pdev:
ring-: N
...
mem-: N
...

What else?
Is ring a good common name? We actually more use engine in i915 but I
am not really bothered about it.

I would prefer engine as well. We are currently in the process of moving
away from kernel rings, so that notion doesn't make much sense to keep
forward.

Christian.

Aggregated GPU usage could be easily and generically done by userspace
by adding all rings and normalizing.

On my submission
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Famd-gfx%2F2021-May%2F063149.htmldata=04%7C01%7CChristian.Koenig%40amd.com%7Cbad72cde9a7248b20c7f08d919e03deb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637569273164210285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TW3HaPkqyr6jwhTUVRue3fGTyRfV4KnhEuRtTTI5fMY%3Dreserved=0
I
added a python script to print out the info. It has a CPU usage lower
that top, for example.

To be absolutely honest, I agree that there is an overhead, but It
might not be as much as you fear.

For me more the issue is that the extra number of operations grows
with the number of open files on the system, which has no relation to
the number of drm clients.

Extra so if the monitoring tool wants to show _only_ DRM processes.
Then the cost scales with total number of processes time total number
of files on the server.

This design inefficiency bothers me yes. This is somewhat alleviated
by the proposal from Chris
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F419042%2F%3Fseries%3D86692%26rev%3D1data=04%7C01%7CChristian.Koenig%40amd.com%7Cbad72cde9a7248b20c7f08d919e03deb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637569273164210285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jNfe8h2BalOOc1Y0Idcs3wxnNOi74XhulkRlebmpgJM%3Dreserved=0)
although there are downsides there as well. Like needing to keep a map
of pids to drm files in drivers.

Btw what do you do in that tool for same fd in a multi-threaded process
or so? Do you show duplicate entries or detect and ignore? I guess I
did not figure out if you show by pid/tgid or by fd.

Regards,

Tvrtko

*From:* Tvrtko Ursulin
*Sent:* Monday, May 17, 2021 9:00 AM
*To:* Nieto, David M ; Daniel Vetter
; Koenig, Christian
*Cc:* Alex Deucher ; Intel Graphics
Development ; Maling list - DRI
developers

*Subject:* Re: [PATCH 0/7] Per client engine busyness

On 17/05/2021 15:39, Nieto, David M wrote:

[AMD Official Use Only]

Maybe we could try to standardize how the different submission ring
usage gets exposed in the fdinfo? We went the simple way of just
adding name and index, but if someone has a suggestion on how else
we could format them so there is commonality across vendors we could
just amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
- link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM
devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

I’d really like to have the process managers tools display GPU usage
regardless of what vendor is

Re: [Intel-gfx] [PATCH v2 08/15] drm/i915/ttm Add a generic TTM memcpy move for page-based iomem