Re: [Intel-gfx] [PATCH 4/4] drm/i915/hwmon: Add HWMON energy support

2022-06-20 Thread Dixit, Ashutosh
On Mon, 20 Jun 2022 14:04:53 -0700, Guenter Roeck wrote:
>
> > @@ -141,9 +282,12 @@ i915_power1_max_default_show(struct device *dev, 
> > struct device_attribute *attr,
> > static SENSOR_DEVICE_ATTR(power1_max_default, 0444,
> >   i915_power1_max_default_show, NULL, 0);
> > +static SENSOR_DEVICE_ATTR(energy1_input, 0444,
> > + i915_energy1_input_show, NULL, 0);
> > static struct attribute *hwmon_attributes[] = {
> > &sensor_dev_attr_power1_max_default.dev_attr.attr,
> > +   &sensor_dev_attr_energy1_input.dev_attr.attr,
>
> Why not use HWMON_E_INPUT ?

Agreed, we will investigate switching to this. I also had a similar comment
about this here:

https://patchwork.freedesktop.org/patch/487020/?series=104278&rev=1

Thanks.
--
Ashutosh


Re: [Intel-gfx] [PATCH 3/4] drm/i915/hwmon: Add HWMON power sensor support

2022-06-20 Thread Dixit, Ashutosh
On Mon, 20 Jun 2022 13:58:49 -0700, Guenter Roeck wrote:
>

Hi Guenter, Thanks for taking a look.

> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
> > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > index 24c4b7477d51..945f472dd4a2 100644
> > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > @@ -5,3 +5,23 @@ Contact:   dri-de...@lists.freedesktop.org
> >   Description:  RO. Current Voltage in millivolt.
> > Only supported for particular Intel i915 graphics
> > platforms.
> > +
> > +What:  /sys/devices/.../hwmon/hwmon/power1_max
> > +Date:  June 2022
> > +KernelVersion: 5.19
> > +Contact:   dri-de...@lists.freedesktop.org
> > +Description:   RW. Card reactive sustained  (PL1/Tau) power limit in 
> > microwatts.
> > +
> > +   The power controller will throttle the operating frequency
> > +   if the power averaged over a window (typically seconds)
> > +   exceeds this limit.
> > +
> > +   Only supported for particular Intel i915 graphics platforms.
> > +
> > +What:  /sys/devices/.../hwmon/hwmon/power1_max_default
>
> I don't immediately see the reason for not using the standard power1_cap
> attribute, which is described as
>
>   If power use rises above this limit, the
> system should take action to reduce power use.
>
> and pretty much matches the description above.

Sorry I believe you are referring to the description above which is for the
standard power1_max attribute (as we have used it). The non-standard
attribute is power1_max_default the description for which is below ("Card
default power limit (default TDP setting)").

> > +Date:  June 2022
> > +KernelVersion: 5.19
> > +Contact:   dri-de...@lists.freedesktop.org
> > +Description:   RO. Card default power limit (default TDP setting).

Actually we do not want to use custom hwmon attributes as far as
possible and are looking for some guidance on which standard attributes
which we should use instead.

These are the power attributes we are interested in: the two above and
another one which will come in a future patch:

1. PL1 (RW)

   
https://www.hardwaretimes.com/intel-10th-gen-cpu-power-consumption-explained-pl1-pl2-and-tau/

2. TDP (RO)

   https://en.wikipedia.org/wiki/Thermal_design_power

3. Tau (RW)

   
https://www.hardwaretimes.com/intel-10th-gen-cpu-power-consumption-explained-pl1-pl2-and-tau/

Would you be able to suggest if there are standard hwmon attributes which
we would be able to use for these three? We also want to use the read/write
permissions as shown above.

Thanks.
--
Ashutosh


Re: [Intel-gfx] [PATCH 09/15] drm/i915/pxp: add huc authentication and loading command

2022-06-20 Thread Teres Alexis, Alan Previn

Reviewed-by: Alan Previn 

On 6/9/2022 4:19 PM, Ceraolo Spurio, Daniele wrote:

From: Tomas Winkler 

Add support for loading HuC via a pxp stream command.

Signed-off-by: Tomas Winkler 
Signed-off-by: Vitaly Lubart 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
---
  drivers/gpu/drm/i915/Makefile |  3 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  | 69 +++
  drivers/gpu/drm/i915/pxp/intel_pxp_huc.h  | 15 
  .../drm/i915/pxp/intel_pxp_tee_interface.h| 21 ++
  4 files changed, 107 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
  create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_huc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5d3aa4807def..8d90e653958c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -306,7 +306,8 @@ i915-y += i915_perf.o
  # Protected execution platform (PXP) support. Base support is required for HuC
  i915-y += \
pxp/intel_pxp.o \
-   pxp/intel_pxp_tee.o
+   pxp/intel_pxp_tee.o \
+   pxp/intel_pxp_huc.o
  
  i915-$(CONFIG_DRM_I915_PXP) += \

pxp/intel_pxp_cmd.o \
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
new file mode 100644
index ..6d25f436f329
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#include "drm/i915_drm.h"
+#include "i915_drv.h"
+
+#include "gem/i915_gem_region.h"
+#include "gt/intel_gt.h"
+
+#include "intel_pxp.h"
+#include "intel_pxp_huc.h"
+#include "intel_pxp_tee.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_tee_interface.h"
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp)
+{
+   struct intel_gt *gt = pxp_to_gt(pxp);
+   struct intel_huc *huc = >->uc.huc;
+   struct pxp_tee_start_huc_auth_in huc_in = {0};
+   struct pxp_tee_start_huc_auth_out huc_out = {0};
+   dma_addr_t huc_phys_addr;
+   u8 client_id = 0;
+   u8 fence_id = 0;
+   int err;
+
+   if (!pxp->pxp_component)
+   return -ENODEV;
+
+   huc_phys_addr = i915_gem_object_get_dma_address(huc->fw.obj, 0);
+
+   /* write the PXP message into the lmem (the sg list) */
+   huc_in.header.api_version = PXP_TEE_43_APIVER;
+   huc_in.header.command_id  = PXP_TEE_43_START_HUC_AUTH;
+   huc_in.header.status  = 0;
+   huc_in.header.buffer_len  = sizeof(huc_in.huc_base_address);
+   huc_in.huc_base_address   = huc_phys_addr;
+
+   err = intel_pxp_tee_stream_message(pxp, client_id, fence_id,
+  &huc_in, sizeof(huc_in),
+  &huc_out, sizeof(huc_out));
+   if (err < 0) {
+   drm_err(>->i915->drm,
+   "Failed to send HuC load and auth command to GSC 
[%d]!\n",
+   err);
+   return err;
+   }
+
+   /*
+* HuC does sometimes survive suspend/resume (it depends on how "deep"
+* a sleep state the device reaches) so we can end up here on resume
+* with HuC already loaded, in which case the GSC will return
+* PXP_STATUS_OP_NOT_PERMITTED. We can therefore consider the GuC
+* correctly transferred in this scenario; if the same error is ever
+* returned with HuC not loaded we'll still catch it when we check the
+* authentication bit later.
+*/
+   if (huc_out.header.status != PXP_STATUS_SUCCESS &&
+   huc_out.header.status != PXP_STATUS_OP_NOT_PERMITTED) {
+   drm_err(>->i915->drm,
+   "HuC load failed with GSC error = 0x%x\n",
+   huc_out.header.status);
+   return -EPROTO;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
new file mode 100644
index ..6cf2d00548c0
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2021, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_HUC_H__
+#define __INTEL_PXP_HUC_H__
+
+#include 
+
+struct intel_pxp;
+
+int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp);
+
+#endif /* __INTEL_PXP_HUC_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h 
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
index 36e9b0868f5c..1de98959a89d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h
@@ -9,8 +9,20 @@
  #include 
  
  #define PXP_TEE_APIVER 0x40002

+#define PXP_TEE_43_APIVER 0x00040003
  #define PXP_TEE_ARB_CMDID 0x1e
  #define PXP_TEE_ARB_PROTECTION_MODE 0x2
+#define PXP_TEE_43_START_HUC_AUTH   0x003A
+
+/*
+ * there are a lot of sta

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915/rpm: d3cold Policy

2022-06-20 Thread Gupta, Anshuman



> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, June 16, 2022 7:58 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Vivi, Rodrigo 
> Subject: Re: [Intel-gfx] [PATCH v2 9/9] drm/i915/rpm: d3cold Policy
> 
> On Thu, 16 Jun 2022, Anshuman Gupta  wrote:
> > Add d3cold_sr_lmem_threshold modparam to choose between d3cold-off
> > zero watt and d3cold-VRAM Self Refresh.
> > i915 requires to evict the lmem objects to smem in order to support
> > d3cold-Off.
> >
> > If gfx root port is not capable of sending PME from d3cold then i915
> > don't need to program d3cold-off/d3cold-vram_sr sequence.
> >
> > FIXME: Eviction of lmem objects in case of D3Cold off is wip.
> >
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/i915_driver.c | 27 ---
> > drivers/gpu/drm/i915/i915_params.c |  4 
> > drivers/gpu/drm/i915/i915_params.h |  3 ++-
> >  3 files changed, 30 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index fcff5f3fe05e..aef4b17efdbe 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1560,15 +1560,36 @@ static int i915_pm_restore(struct device
> > *kdev)  static int intel_runtime_idle(struct device *kdev)  {
> > struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > +   struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> > +   u64 lmem_total = to_gt(dev_priv)->lmem->total;
> > +   u64 lmem_avail = to_gt(dev_priv)->lmem->avail;
> > +   u64 lmem_used = lmem_total - lmem_avail;
> > +   struct pci_dev *root_pdev;
> > int ret = 1;
> >
> > -   if (!HAS_LMEM_SR(dev_priv)) {
> > -   /*TODO: Prepare for D3Cold-Off */
> > +   root_pdev = pcie_find_root_port(pdev);
> > +   if (!root_pdev)
> > +   goto out;
> > +
> > +   if (!pci_pme_capable(root_pdev, PCI_D3cold))
> > goto out;
> > -   }
> >
> > disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> >
> > +   if (lmem_used < dev_priv->params.d3cold_sr_lmem_threshold  * 1024 *
> 1024) {
> > +   drm_dbg(&dev_priv->drm, "Prepare for D3Cold off\n");
> > +   pci_d3cold_enable(root_pdev);
> > +   /* FIXME: Eviction of lmem objects and guc reset is wip */
> > +   intel_pm_vram_sr(dev_priv, false);
> > +   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > +   goto out;
> > +   } else if (!HAS_LMEM_SR(dev_priv)) {
> > +   /* Disable D3Cold to reduce the eviction latency */
> > +   pci_d3cold_disable(root_pdev);
> > +   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > +   goto out;
> > +   }
> 
> This is *way* too low level code for such high level function. This needs to 
> be
> abstracted better.
> 
> > +
> > ret = intel_pm_vram_sr(dev_priv, true);
> > if (!ret)
> > drm_dbg(&dev_priv->drm, "VRAM Self Refresh enabled\n"); diff
> --git
> > a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 701fbc98afa0..6c6b3c372d4d 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -197,6 +197,10 @@ i915_param_named(enable_gvt, bool, 0400,
> > "Enable support for Intel GVT-g graphics virtualization host
> > support(default:false)");  #endif
> >
> > +i915_param_named_unsafe(d3cold_sr_lmem_threshold, int, 0400,
> > +   "Enable Vidoe RAM Self refresh when size of lmem is greater to this
> threshold. "
> > +   "It helps to optimize the suspend/resume latecy. (default: 300mb)");
> > +
> >  #if CONFIG_DRM_I915_REQUEST_TIMEOUT
> >  i915_param_named_unsafe(request_timeout_ms, uint, 0600,
> > "Default request/fence/batch buffer expiration
> timeout."); diff
> > --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index b5e7ea45d191..28f20ebaf41f 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -83,7 +83,8 @@ struct drm_printer;
> > param(bool, verbose_state_checks, true, 0) \
> > param(bool, nuclear_pageflip, false, 0400) \
> > param(bool, enable_dp_mst, true, 0600) \
> > -   param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ?
> 0400 : 0)
> > +   param(bool, enable_gvt, false, IS_ENABLED(CONFIG_DRM_I915_GVT) ?
> 0400 : 0) \
> > +   param(int, d3cold_sr_lmem_threshold, 300, 0600) \
> 
> What's the point of the parameter?
We want a configurable option to choose an optimum lmem usages threshold on 
which, i915
can choose lmem self-refresh. This threshold value would require some profiling 
as well. 
That is the reason this threshold kept as module param.  
> 
> Also, please read the comment /* leave bools at the end to not create holes */
> above.
Thanks for review comment , I will re order the module param.
Regards ,
Anshuman Gupta.
> 
> 
> BR,
> Jani.
> 

[Intel-gfx] intel-gfx mailing list subscription

2022-06-20 Thread Borah, Chaitanya Kumar
Hello Team,

Could you please add me to the intel-gfx mailing list?

My details are as follows:

Name: Chaitanya Kumar Borah
E-mail: chaitanya.kumar.bo...@intel.com
Team: OSGC Bangalore

I have already raised a request through 
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Regards,

Chaitanya



Re: [Intel-gfx] [RFC PATCH 4/5] drm/i915/display: prepend connector name to the backlight

2022-06-20 Thread Murthy, Arun R
> On Fri, 03 Jun 2022, "Murthy, Arun R"  wrote:
> >> On Thu, 02 Jun 2022, Animesh Manna 
> wrote:
> >> > From: Arun R Murthy 
> >> >
> >> > With the enablement of dual eDP, there will have to exist two
> >> > entries of backlight sysfs file. In order to avoid sysfs file name
> >> > duplication, the file names are prepended with the connector name.
> >>
> >> Fixed by 20f85ef89d94 ("drm/i915/backlight: use unique backlight
> >> device
> >> names") about a year ago.
> >>
> > This patches checks if the return value is -EEXIST and then acts 
> > accordingly,
> but -EEXIST is not returned.
> > struct kernfs_node *__kernfs_create_file(struct kernfs_node *parent,
> >  const char *name,
> >  umode_t mode, kuid_t uid, kgid_t 
> > gid,
> >  loff_t size,
> >  const struct kernfs_ops *ops,
> >  void *priv, const void *ns,
> >  struct lock_class_key *key) {
> > struct kernfs_node *kn;
> > unsigned flags;
> > int rc;
> >
> > flags = KERNFS_FILE;
> >
> > kn = kernfs_new_node(parent, name, (mode & S_IALLUGO) | S_IFREG,
> >  uid, gid, flags);
> > if (!kn)
> > return ERR_PTR(-ENOMEM);
> >
> > So the condition check with not be satisfied and the backlight registration
> will fail for the 2nd backlight device.
> 
> But the file isn't added by kernfs_new_node(), it just allocates the node. See
> the kernfs_add_one() later in __kernfs_create_file().
> 
Moreover now that we will be supporting dual display, wouldn't it
be better to have the same file naming convention for both the
displays?
Without this patch, the first backlight would create an interface
with name intel_backlight and for the second it would create as
"cardXX-XXX-backlight". There wont be any similarities in the
backlight naming convention.
Would it be better to maintain the same naming convention
across the displays?

Thanks and Regards,
Arun R Murthy



[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2022-06-20 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/xlnx/zynqmp_disp.c: In function 'zynqmp_disp_create_planes':
drivers/gpu/drm/xlnx/zynqmp_disp.c:1260:17: error: implicit declaration of 
function 'drm_plane_create_zpos_immutable_property'; did you mean 
'drm_plane_create_scaling_filter_property'? 
[-Werror=implicit-function-declaration]
 1260 | drm_plane_create_zpos_immutable_property(&layer->plane, 
i);
  | ^~~~
  | drm_plane_create_scaling_filter_property
drivers/gpu/drm/xlnx/zynqmp_disp.c:1262:25: error: implicit declaration of 
function 'drm_plane_create_alpha_property'; did you mean 
'drm_plane_create_color_properties'? [-Werror=implicit-function-declaration]
 1262 | drm_plane_create_alpha_property(&layer->plane);
  | ^~~
  | drm_plane_create_color_properties
cc1: all warnings being treated as errors

Presumably caused by one of the commits that dropped includes from
drm-ctrc.h.

I have used the drm-misc tree from next-20220620 for today.

-- 
Cheers,
Stephen Rothwell


pgpONB8A38WPS.pgp
Description: OpenPGP digital signature


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ttm for stolen (rev3)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: ttm for stolen (rev3)
URL   : https://patchwork.freedesktop.org/series/101396/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11786 -> Patchwork_101396v3


Summary
---

  **FAILURE**

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

Participating hosts (41 -> 43)
--

  Additional (3): fi-kbl-soraka bat-dg2-8 fi-rkl-11600 
  Missing(1): fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@reset:
- fi-rkl-guc: [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-rkl-guc/igt@i915_selftest@l...@reset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-rkl-guc/igt@i915_selftest@l...@reset.html
- bat-adlp-4: [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-4/igt@i915_selftest@l...@reset.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/bat-adlp-4/igt@i915_selftest@l...@reset.html

  
 Suppressed 

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

  * igt@i915_selftest@live@reset:
- {bat-adlp-6}:   [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-6/igt@i915_selftest@l...@reset.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/bat-adlp-6/igt@i915_selftest@l...@reset.html

  * igt@kms_busy@basic@flip:
- {bat-dg2-9}:[PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-dg2-9/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/bat-dg2-9/igt@kms_busy@ba...@flip.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([i915#4613]) +3 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([i915#3282])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#3012])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][15] ([i915#4528])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][16] ([i915#1886])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][17] -> [INCOMPLETE][18] ([i915#3921])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][19] -> [DMESG-FAIL][20] ([i915#4494] / 
[i915#4957])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101396v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOM

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for stolen (rev3)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: ttm for stolen (rev3)
URL   : https://patchwork.freedesktop.org/series/101396/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add HWMON support (rev2)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add HWMON support (rev2)
URL   : https://patchwork.freedesktop.org/series/104278/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11786 -> Patchwork_104278v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 42)
--

  Additional (3): fi-kbl-soraka bat-dg2-8 fi-rkl-11600 
  Missing(2): fi-icl-u2 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][5] ([i915#3282])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#3012])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][8] -> [INCOMPLETE][9] ([i915#3921])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][10] ([i915#5982])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([fdo#111827]) +7 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][13] ([fdo#109271]) +9 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-rkl-11600:   NOTRUN -> [SKIP][14] ([i915#4103]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][15] -> [DMESG-WARN][16] ([i915#3576])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([fdo#109285] / [i915#4098])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] ([i915#533])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_ps

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add HWMON support (rev2)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add HWMON support (rev2)
URL   : https://patchwork.freedesktop.org/series/104278/
State : warning

== Summary ==

Error: dim checkpatch failed
b435e8c95f2c drm/i915/hwmon: Add HWMON infrastructure patch
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:80: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#80: 
new file mode 100644

-:102: CHECK:LINE_SPACING: Please don't use multiple blank lines
#102: FILE: drivers/gpu/drm/i915/i915_hwmon.c:18:
+
+

-:139: CHECK:LINE_SPACING: Please don't use multiple blank lines
#139: FILE: drivers/gpu/drm/i915/i915_hwmon.c:55:
+
+

-:188: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#188: FILE: drivers/gpu/drm/i915/i915_hwmon.c:104:
+{
+

-:189: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#189: FILE: drivers/gpu/drm/i915/i915_hwmon.c:105:
+
+}

total: 0 errors, 1 warnings, 4 checks, 226 lines checked
26283e8ff1e5 drm/i915/hwmon: Add HWMON current voltage support
-:18: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#18: 
new file mode 100644

-:144: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#144: FILE: drivers/gpu/drm/i915/i915_hwmon.c:162:
+   if (IS_DG1(i915) || IS_DG2(i915)) {
[...]
+   } else {
[...]

total: 0 errors, 2 warnings, 0 checks, 116 lines checked
c8f29d0a1e7a drm/i915/hwmon: Add HWMON power sensor support
-:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible 
side-effects?
#64: FILE: drivers/gpu/drm/i915/i915_hwmon.c:25:
+#define FIELD_SHIFT(__mask)\
+   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
+   BUILD_BUG_ON_ZERO((__mask) == 0) +  \
+   __bf_shf(__mask))

-:351: CHECK:LINE_SPACING: Please don't use multiple blank lines
#351: FILE: drivers/gpu/drm/i915/i915_hwmon.c:374:
 
+

-:361: CHECK:BRACES: braces {} should be used on all arms of this statement
#361: FILE: drivers/gpu/drm/i915/i915_hwmon.c:384:
+   if (i915_mmio_reg_valid(hwmon->rg.pkg_power_sku_unit)) {
[...]
+   } else
[...]

-:364: CHECK:BRACES: Unbalanced braces around else statement
#364: FILE: drivers/gpu/drm/i915/i915_hwmon.c:387:
+   } else

total: 0 errors, 0 warnings, 4 checks, 370 lines checked
cf8df8d7e58f drm/i915/hwmon: Add HWMON energy support




[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/fbc: Move flip_pending assignmnt

2022-06-20 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/fbc: Move flip_pending assignmnt
URL   : https://patchwork.freedesktop.org/series/105383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11786 -> Patchwork_105383v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (41 -> 40)
--

  Additional (2): fi-kbl-soraka bat-dg2-8 
  Missing(3): fi-bxt-dsi bat-dg2-9 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][3] ([i915#1886])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-u2:  [PASS][9] -> [DMESG-WARN][10] ([i915#402])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#4312] / 
[i915#5594] / [i915#6246])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@gtt:
- fi-bdw-5557u:   [DMESG-FAIL][13] ([i915#3674]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}:   [DMESG-WARN][17] ([i915#3576]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- bat-adlp-4: [DMESG-WARN][19] ([i915#3576]) -> [PASS][20] +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105383v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move display feature check macros out of i915_drv.h

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: move display feature check macros out of i915_drv.h
URL   : https://patchwork.freedesktop.org/series/105381/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11786 -> Patchwork_105381v1


Summary
---

  **FAILURE**

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

Participating hosts (41 -> 43)
--

  Additional (3): fi-kbl-soraka bat-dg2-8 fi-rkl-11600 
  Missing(1): fi-bdw-samus 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@execlists:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-rkl-11600:   NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html

  * igt@gem_tiled_pread_basic:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#3282])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600:   NOTRUN -> [SKIP][8] ([i915#3012])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_selftest@live@gem:
- fi-blb-e6850:   NOTRUN -> [DMESG-FAIL][9] ([i915#4528])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][10] ([i915#4528])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][12] -> [INCOMPLETE][13] ([i915#3921])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][14] -> [DMESG-FAIL][15] ([i915#4494] / 
[i915#4957])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][16] ([i915#5982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][17] -> [DMESG-WARN][18] ([i915#3576])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11786/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][19] ([fdo#111827]) +7 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105381v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move display feature check macros out of i915_drv.h

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: move display feature check macros out of i915_drv.h
URL   : https://patchwork.freedesktop.org/series/105381/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: move display feature check macros out of i915_drv.h

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: move display feature check macros out of i915_drv.h
URL   : https://patchwork.freedesktop.org/series/105381/
State : warning

== Summary ==

Error: dim checkpatch failed
15d736930b6b drm/i915/display: spread out HAS_*() feature macros
-:47: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#47: FILE: drivers/gpu/drm/i915/display/intel_cursor.c:27:
+#define HAS_CUR_FBC(__i915) (!HAS_GMCH(__i915) && DISPLAY_VER(__i915) >= 7)

-:87: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#87: FILE: drivers/gpu/drm/i915/display/intel_gmbus.c:42:
+#define HAS_GMBUS_BURST_READ(__i915) \
+   (DISPLAY_VER(__i915) >= 11 || IS_GEMINILAKE(__i915) || 
IS_KABYLAKE(__i915))

-:233: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#233: FILE: drivers/gpu/drm/i915/intel_pm.c:61:
+#define HAS_HW_SAGV_WM(__i915) (DISPLAY_VER(__i915) >= 13 && !IS_DGFX(__i915))

total: 0 errors, 0 warnings, 3 checks, 169 lines checked
bf2a38879dbd drm/i915/display: add intel_display_features.h for feature check 
macros
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:12: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#12: 
new file mode 100644

-:27: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#27: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:11:
+#define HAS_D12_PLANE_MINIMIZATION(__i915) (IS_ROCKETLAKE(__i915) || 
IS_ALDERLAKE_S(__i915))

-:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#29: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:13:
+#define HAS_HW_SAGV_WM(__i915) (DISPLAY_VER(__i915) >= 13 && 
!IS_DGFX(__i915))

-:30: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#30: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:14:
+#define HAS_IPS(__i915)(IS_HSW_ULT(__i915) || 
IS_BROADWELL(__i915))

-:35: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#35: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:19:
+#define HAS_DDI(__i915)^I^I ^I(INTEL_INFO(__i915)->display.has_ddi)$

-:41: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#41: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:25:
+#define HAS_PSR(__i915)^I^I ^I(INTEL_INFO(__i915)->display.has_psr)$

-:42: WARNING:LONG_LINE: line length of 109 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:26:
+#define HAS_TRANSCODER(__i915, trans)  
((INTEL_INFO(__i915)->display.cpu_transcoder_mask & BIT(trans)) != 0)

-:48: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i915' - possible 
side-effects?
#48: FILE: drivers/gpu/drm/i915/display/intel_display_features.h:32:
+#define INTEL_DISPLAY_ENABLED(__i915) \
+   (drm_WARN_ON(&(__i915)->drm, !HAS_DISPLAY(__i915)), \
+!(__i915)->params.disable_display &&   \
+!intel_opregion_headless_sku(__i915))

total: 0 errors, 4 warnings, 4 checks, 164 lines checked




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL   : https://patchwork.freedesktop.org/series/103491/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11785 -> Patchwork_103491v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 42)
--

  Additional (1): bat-dg2-9 
  Missing(2): bat-dg2-8 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-5:  [PASS][1] -> [INCOMPLETE][2] ([i915#4418])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/bat-dg1-5/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  NOTRUN -> [DMESG-FAIL][3] ([i915#4494] / [i915#4957])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@mman:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#5704])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/fi-bdw-5557u/igt@i915_selftest@l...@mman.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bdw-5557u/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6:  NOTRUN -> [INCOMPLETE][6] ([i915#6011])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#3576])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-bsw-n3050:   NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-n3050/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-bsw-nick:NOTRUN -> [SKIP][15] ([fdo#109271])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
- fi-bsw-n3050:   NOTRUN -> [SKIP][16] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-n3050/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Possible fixes 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][17] ([i915#5847]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050:   [INCOMPLETE][19] ([i915#5847]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [INCOMPLETE][21] ([i915#4418]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11785/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103491v6/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][23

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL   : https://patchwork.freedesktop.org/series/103491/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.




[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL   : https://patchwork.freedesktop.org/series/103491/
State : warning

== Summary ==

Error: dim checkpatch failed
0cf5770ce11c drm/i915: Relocate intel_crtc_dotclock()
8e214039c42f drm/i915: Shuffle some PLL code around
0a40c0aea05b drm/i915: Extract HAS_DOUBLE_BUFFERED_M_N()
-:53: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#53: FILE: drivers/gpu/drm/i915/i915_drv.h:1255:
+#define HAS_DOUBLE_BUFFERED_M_N(dev_priv)  (DISPLAY_VER(dev_priv) >= 9 || 
IS_BROADWELL(dev_priv))

-:53: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible 
side-effects?
#53: FILE: drivers/gpu/drm/i915/i915_drv.h:1255:
+#define HAS_DOUBLE_BUFFERED_M_N(dev_priv)  (DISPLAY_VER(dev_priv) >= 9 || 
IS_BROADWELL(dev_priv))

total: 0 errors, 1 warnings, 1 checks, 25 lines checked
d135effc011e drm/i915/dsi: Extract {vlv, bxt}_get_pclk()
4cd472892736 drm/i915: Do .crtc_compute_clock() earlier
3f4eddf2ca58 drm/i915: Reassign DPLLs only for crtcs going throug 
.compute_config()
4cae9fa84b8b drm/i915: Feed the DPLL output freq back into crtc_state
27da5a8db7b3 drm/i915: Compute clocks earlier
edee938717df drm/i915: Make M/N checks non-fuzzy
0358bca96699 drm/i915: Make all clock checks non-fuzzy
e399283bacc7 drm/i915: Set active dpll early for icl+
320064a4eba6 drm/i915: Nuke fastet state copy hacks
e46e10fbf5a6 drm/i915: Skip intel_modeset_pipe_config_late() if the pipe is not 
enabled
311d51a7485d drm/i915: Add intel_panel_highest_mode()
ce21626434d0 drm/i915: Allow M/N change during fastset on bdw+
e27993638185 drm/i915: Use a fixed N value always
c87c710ada27 drm/i915: Round TMDS clock to nearest




[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix vm use-after-free in vma destruction (rev2)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix vm use-after-free in vma destruction (rev2)
URL   : https://patchwork.freedesktop.org/series/103922/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11780_full -> Patchwork_103922v2_full


Summary
---

  **WARNING**

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

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Warnings 

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt:
- shard-skl:  [SKIP][1] ([fdo#109271]) -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-skl7/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-skl6/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt.html

  
 Suppressed 

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

  * igt@gen9_exec_parse@allowed-all:
- {shard-rkl}:NOTRUN -> [DMESG-WARN][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-rkl-5/igt@gen9_exec_pa...@allowed-all.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#6268])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-iclb4/igt@gem_exec_balan...@parallel-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-deadline:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#6141])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-iclb2/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) +4 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-iclb3/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar 
issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2849])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-iclb3/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/shard-tglb7/igt@gem_huc_c.

[Intel-gfx] [PATCH v7 10/10] drm/i915: stolen memory use ttm backend

2022-06-20 Thread Robert Beckett
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_region_ttm.c   |  42 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |  12 +-
 13 files changed, 303 insertions(+), 342 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8b807284cde1..6f3afac5e8c9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
  * forcibly disable it to allow proper screen updates.
  */
 
+#include "gem/i915_gem_stolen.h"
 #include 
 
 #include 
@@ -51,6 +52,7 @@
 #include "intel_display_types.h"
 #include "intel_fbc.h"
 #include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
 
 #define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS; 
(__fbc_id)++) \
@@ -92,8 +94,8 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
 
-   struct drm_mm_node compressed_fb;
-   struct drm_mm_node compressed_llb;
+   struct ttm_resource *compressed_fb;
+   struct ttm_resource *compressed_llb;
 
enum intel_fbc_id id;
 
@@ -331,16 +333,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
 static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+   u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
 
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
 
intel_de_write(i915, FBC_CFB_BASE,
-  i915->dsm.start + fbc->compressed_fb.start);
+  i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
-  i915->dsm.start + fbc->compressed_llb.start);
+  i915->dsm.start + llb_offset);
 }
 
 static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -448,8 +454,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
 static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, DPFC_CB_BASE, fb_offset);
 }
 
 static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -499,8 +507,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
 static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), 
fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
 }
 
 static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -744,21 +754,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
 {
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
-   int ret, limit = min_limit;
+   int limit = min_limit;
+   struct ttm_resource *res;
 
size /= limit;
 
/* Try to over-allocate to reduce reallocations and fragmentation. */
-   ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
-  size <<= 1, 4096, 0, end);
-   if (ret == 0)
+   res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+   if (!IS_ERR(res)) {
+   fbc->compressed_fb = res;
return limit;
+   }
 
for (; limit <= in

[Intel-gfx] [PATCH v7 04/10] drm/i915/gem: selftest should not attempt mmap of private regions

2022-06-20 Thread Robert Beckett
During testing make can_mmap consider whether the region is private.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum 
i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
 
+   if (obj->mm.region && obj->mm.region->private)
+   return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
-- 
2.25.1



[Intel-gfx] [PATCH v7 08/10] drm/i915: allow memory region creators to alloc and free the region

2022-06-20 Thread Robert Beckett
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
 drivers/gpu/drm/i915/intel_memory_region.h |  2 ++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index e38d2db1c3e3..3da07a712f90 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -231,7 +231,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
struct intel_memory_region *mem;
int err;
 
-   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+   if (ops->alloc)
+   mem = ops->alloc();
+   else
+   mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return ERR_PTR(-ENOMEM);
 
@@ -265,7 +268,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
if (mem->ops->release)
mem->ops->release(mem);
 err_free:
-   kfree(mem);
+   if (mem->ops->free)
+   mem->ops->free(mem);
+   else
+   kfree(mem);
return ERR_PTR(err);
 }
 
@@ -288,7 +294,11 @@ void intel_memory_region_destroy(struct 
intel_memory_region *mem)
 
GEM_WARN_ON(!list_empty_careful(&mem->objects.list));
mutex_destroy(&mem->objects.lock);
-   if (!ret)
+   if (ret)
+   return;
+   if (mem->ops->free)
+   mem->ops->free(mem);
+   else
kfree(mem);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index 3d8378c1b447..048955b5429f 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -61,6 +61,8 @@ struct intel_memory_region_ops {
   resource_size_t size,
   resource_size_t page_size,
   unsigned int flags);
+   struct intel_memory_region *(*alloc)(void);
+   void (*free)(struct intel_memory_region *mem);
 };
 
 struct intel_memory_region {
-- 
2.25.1



[Intel-gfx] [PATCH v7 03/10] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

2022-06-20 Thread Robert Beckett
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.25.1



[Intel-gfx] [PATCH v7 07/10] drm/i915: ttm move/clear logic fix

2022-06-20 Thread Robert Beckett
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.

The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 81c67ca9edda..a3f8fc056dbc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "drm/ttm/ttm_tt.h"
 #include 
 
 #include "i915_deps.h"
@@ -476,6 +477,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
 }
 
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct 
ttm_resource *dst_mem)
+{
+   /* never clear stolen */
+   if (dst_mem->mem_type == I915_PL_STOLEN)
+   return false;
+   /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+   if (obj->flags & I915_BO_ALLOC_USER)
+   return true;
+
+   if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+   return true;
+
+   return false;
+}
+
 /**
  * i915_ttm_move - The TTM move callback used by i915.
  * @bo: The buffer object.
@@ -526,7 +546,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
 
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
!ttm_tt_is_populated(ttm));
-   if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+   if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
 
i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
__GFP_NOWARN);
-- 
2.25.1



[Intel-gfx] [PATCH v7 09/10] drm/i915/ttm: add buffer pin on alloc flag

2022-06-20 Thread Robert Beckett
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback options for stolen backend allocation like
create_ring_vma to work as expected.

Signed-off-by: Robert Beckett 
---
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 13 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 25 ++-
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 6632ed52e919..07bc11247a3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -325,17 +325,20 @@ struct drm_i915_gem_object {
  * dealing with userspace objects the CPU fault handler is free to ignore this.
  */
 #define I915_BO_ALLOC_GPU_ONLY   BIT(6)
+/* object should be pinned in destination region from allocation */
+#define I915_BO_ALLOC_PINNED BIT(7)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
 I915_BO_ALLOC_PM_VOLATILE | \
 I915_BO_ALLOC_PM_EARLY | \
-I915_BO_ALLOC_GPU_ONLY)
-#define I915_BO_READONLY  BIT(7)
-#define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED BIT(9)
-#define I915_BO_WAS_BOUND_BIT 10
+I915_BO_ALLOC_GPU_ONLY | \
+I915_BO_ALLOC_PINNED)
+#define I915_BO_READONLY  BIT(8)
+#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED BIT(10)
+#define I915_BO_WAS_BOUND_BIT 11
/**
 * @mem_flags - Mutable placement-related flags
 *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27d59639177f..bb988608296d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -998,6 +998,13 @@ static void i915_ttm_delayed_free(struct 
drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!obj->ttm.created);
 
+   /* stolen objects are pinned for lifetime. Unpin before putting */
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   ttm_bo_reserve(i915_gem_to_ttm(obj), true, false, NULL);
+   ttm_bo_unpin(i915_gem_to_ttm(obj));
+   ttm_bo_unreserve(i915_gem_to_ttm(obj));
+   }
+
ttm_bo_put(i915_gem_to_ttm(obj));
 }
 
@@ -1193,6 +1200,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+   struct ttm_place _place;
+   struct ttm_placement _placement;
+   struct ttm_placement *placement;
int ret;
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
@@ -1222,6 +1232,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
 */
i915_gem_object_make_unshrinkable(obj);
 
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   i915_ttm_place_from_region(mem, &_place, obj->bo_offset,
+  obj->base.size, obj->flags);
+   _placement.num_placement = 1;
+   _placement.placement = &_place;
+   _placement.num_busy_placement = 0;
+   _placement.busy_placement = NULL;
+   placement = &_placement;
+   } else {
+   placement = &i915_sys_placement;
+   }
/*
 * If this function fails, it will call the destructor, but
 * our caller still owns the object. So no freeing in the
@@ -1230,7 +1251,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 * until successful initialization.
 */
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), size,
-  bo_type, &i915_sys_placement,
+  bo_type, placement,
   page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
if (ret)
@@ -1242,6 +1263,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
obj->ttm.cache_level_override = false;
+   if (obj->flags & I915_BO_ALLOC_PINNED)
+   ttm_bo_pin(i915_gem_to_ttm(obj));
i915_gem_object_unlock(obj);
 
return 0;
-- 
2.25.1



[Intel-gfx] [PATCH v7 05/10] drm/i915: instantiate ttm ranger manager for stolen memory

2022-06-20 Thread Robert Beckett
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  6 ++--
 drivers/gpu/drm/i915/intel_region_ttm.c  | 31 +++-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 40249fa28a7a..675e9ab30396 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -60,11 +60,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
 
/* There's some room for optimization here... */
-   GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
-  ttm_mem_type < I915_PL_LMEM0);
+   GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
  0);
+   if (ttm_mem_type == I915_PL_STOLEN)
+   return i915->mm.stolen_region;
 
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
  ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index fd2ecfdd8fa1..694e9acb69e2 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -54,7 +54,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private 
*dev_priv)
 
 /*
  * Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
  * memory and TTM_PL_TT for GGTT use if decided to implement this.
  */
 int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -63,11 +63,17 @@ int intel_region_to_ttm_type(const struct 
intel_memory_region *mem)
 
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
   mem->type != INTEL_MEMORY_MOCK &&
-  mem->type != INTEL_MEMORY_SYSTEM);
+  mem->type != INTEL_MEMORY_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_LOCAL);
 
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
 
+   if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+   mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+   return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
 
@@ -91,10 +97,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
 
-   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+   if (mem_type == I915_PL_STOLEN) {
+   ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >> 
PAGE_SHIFT);
+   mem->is_range_manager = true;
+   } else {
+   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+   }
if (ret)
return ret;
 
@@ -114,6 +126,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
 int intel_region_ttm_fini(struct intel_memory_region *mem)
 {
struct ttm_resource_manager *man = mem->region_private;
+   int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
 
@@ -144,8 +157,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
 
-   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+   if (mem_type == I915_PL_STOLEN)
+   ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+   else
+   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
 
-- 
2.25.1



[Intel-gfx] [PATCH v7 06/10] drm/i915: sanitize mem_flags for stolen buffers

2022-06-20 Thread Robert Beckett
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.

See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 675e9ab30396..81c67ca9edda 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -14,6 +14,7 @@
 #include "gem/i915_gem_region.h"
 #include "gem/i915_gem_ttm.h"
 #include "gem/i915_gem_ttm_move.h"
+#include "gem/i915_gem_stolen.h"
 
 #include "gt/intel_engine_pm.h"
 #include "gt/intel_gt.h"
@@ -124,8 +125,9 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
 
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
 
-   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
-   I915_BO_FLAG_STRUCT_PAGE;
+   if (!i915_gem_object_is_stolen(obj))
+   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
 
if (!obj->ttm.cache_level_override) {
cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
-- 
2.25.1



[Intel-gfx] [PATCH v7 02/10] drm/i915: limit ttm to dma32 for i965G[M]

2022-06-20 Thread Robert Beckett
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..fd2ecfdd8fa1 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = &dev_priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.25.1



[Intel-gfx] [PATCH v7 01/10] drm/i915/ttm: dont trample cache_level overrides during ttm move

2022-06-20 Thread Robert Beckett
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..519887769c08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2c88bdb8ff7c..6632ed52e919 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -605,6 +605,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..27d59639177f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1241,6 +1241,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..4c1de0b4a10f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -123,9 +123,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.25.1



[Intel-gfx] [PATCH v7 00/10] drm/i915: ttm for stolen

2022-06-20 Thread Robert Beckett
This series refactors i915's stolen memory region to use ttm.

v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes 
testing
dmesg warning regressions.

v3: rebase to latest drm-tip.
fix v2 code refactor which could leave a buffer pinned.
locally passes fftl again now.

v4: - Allow memory regions creators to do allocation. Allows stolen region 
to track
  it's own reservations.
- Pre-reserve first page of stolen mem (add back 
WaSkipStolenMemoryFirstPage:bdw+)
- Improve commit descritpion for "drm/i915: sanitize mem_flags for 
stolen buffers"
- replace i915_gem_object_pin_pages_unlocked() call with manual locking 
and pinning.
  this avoids ww ctx class reuse during context creation -> ring vma 
obj alloc.

v5: - detect both types of stolen as stolen buffers in
  "drm/i915: sanitize mem_flags for stolen buffers"
- in stolen_object_init limit page size to mem region minimum.
  The range allocator expects the page_size to define the
  alignment

v6: - Share first 4 patches from ttm for internal series as generic
  i915 ttm fixes
- Drop patch 4 from v5. We don't need separate object ops just
  to satisfy test interfaces. The tests have now been fixed via
  checking whether the memory region is private to decide
  whether to mmap
- Add new buffer pin alloc flag to allow creation of buffers in
  their final ttm placement instead of deferring until
  get_pages. This fixes legacy fallback paths for buffer
  allocations during stolen memory pressure.

v7: - fix mock_region_get_pages() to correctly handle I915_BO_INVALID_OFFSET

Robert Beckett (10):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level
  drm/i915/gem: selftest should not attempt mmap of private regions
  drm/i915: instantiate ttm ranger manager for stolen memory
  drm/i915: sanitize mem_flags for stolen buffers
  drm/i915: ttm move/clear logic fix
  drm/i915: allow memory region creators to alloc and free the region
  drm/i915/ttm: add buffer pin on alloc flag
  drm/i915: stolen memory use ttm backend

 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  16 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  29 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  47 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   3 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_memory_region.c|  16 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |  80 +++-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |  12 +-
 18 files changed, 423 insertions(+), 369 deletions(-)

-- 
2.25.1



Re: [Intel-gfx] [PATCH 2/4] drm/i915/hwmon: Add HWMON current voltage support

2022-06-20 Thread Guenter Roeck

On 6/20/22 13:46, Badal Nilawar wrote:

From: Riana Tauro 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display current voltage

v2:
   - Updated date and kernel version in feature description
   - Fixed review comments (Ashutosh)

Cc: Anshuman Gupta 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  7 +++
  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  3 +
  drivers/gpu/drm/i915/i915_hwmon.c | 63 +++
  3 files changed, 73 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..24c4b7477d51
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What:  /sys/devices/.../hwmon/hwmon/in0_input
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Current Voltage in millivolt.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07ef111947b8..63a39e1e00e2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1487,6 +1487,9 @@
  #define VLV_RENDER_C0_COUNT   _MMIO(0x138118)
  #define VLV_MEDIA_C0_COUNT_MMIO(0x13811c)
  
+#define GEN12_RPSTAT1_MMIO(0x1381b4)

+#define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+
  #define GEN11_GT_INTR_DW(x)   _MMIO(0x190018 + ((x) * 4))
  #define   GEN11_CSME  (31)
  #define   GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2ef40b0c1e70..fc06db790243 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -14,9 +14,11 @@
  #include "i915_hwmon.h"
  #include "i915_drv.h"
  #include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
  
  
  struct i915_hwmon_reg {

+   i915_reg_t gt_perf_status;
  };
  
  struct i915_hwmon_drvdata {

@@ -53,15 +55,65 @@ static const struct attribute_group *hwmon_groups[] = {
  };
  
  
+/*

+ * HWMON SENSOR TYPE = hwmon_in
+ *  - Voltage Input value (in0_input)
+ */
+static const u32 i915_config_in[] = {
+   HWMON_I_INPUT,
+   0
+};
+
+static const struct hwmon_channel_info i915_in = {
+   .type = hwmon_in,
+   .config = i915_config_in,
+};
+
  static const struct hwmon_channel_info *i915_info[] = {
+   &i915_in,
NULL
  };


Please use the HWMON_CHANNEL_INFO macro.

Thanks,
Guenter

  
+static umode_t

+i915_in_is_visible(const struct i915_hwmon_drvdata *ddat, u32 attr)
+{
+   struct drm_i915_private *i915 = ddat->uncore->i915;
+
+   switch (attr) {
+   case hwmon_in_input:
+   return (IS_DG1(i915) || IS_DG2(i915)) ? 0444 : 0;
+   default:
+   return 0;
+   }
+}
+
+static int
+i915_in_read(struct i915_hwmon_drvdata *ddat, u32 attr, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   switch (attr) {
+   case hwmon_in_input:
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(ddat->uncore, 
hwmon->rg.gt_perf_status);
+   *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK, 
reg_value) * 25, 10);
+   return 0;
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
  static umode_t
  i915_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
  {
+   struct i915_hwmon_drvdata *ddat = (struct i915_hwmon_drvdata *)drvdata;
+
switch (type) {
+   case hwmon_in:
+   return i915_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -71,7 +123,11 @@ static int
  i915_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
  int channel, long *val)
  {
+   struct i915_hwmon_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+   case hwmon_in:
+   return i915_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -101,6 +157,13 @@ static const struct hwmon_chip_info i915_chip_info = {
  static void
  i915_hwmon_get_preregistration_info(struct drm_i915_private *i915)
  {
+   struct i915_hwmon *hwmon = i915->hwmon;
+
+   if (IS_DG1(i915) || IS_DG2(i915)) {
+   hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+   } else {
+   hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
+   }
  
  }
  




Re: [Intel-gfx] [PATCH 4/4] drm/i915/hwmon: Add HWMON energy support

2022-06-20 Thread Guenter Roeck

On 6/20/22 13:46, Badal Nilawar wrote:

From: Dale B Stimson 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display energy utilization

v2:
   - Updated the date and kernel version in feature description

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  16 ++
  drivers/gpu/drm/i915/i915_hwmon.c | 174 +-
  drivers/gpu/drm/i915/i915_hwmon.h |   1 +
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |   2 +
  4 files changed, 185 insertions(+), 8 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 945f472dd4a2..2e87d7422b73 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,19 @@ Contact: dri-de...@lists.freedesktop.org
  Description:  RO. Card default power limit (default TDP setting).
  
  		Only supported for particular Intel i915 graphics platforms.

+
+What:  /sys/devices/.../hwmon/hwmon/energy1_input
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Energy input of device in microjoules.
+
+   The returned textual representation is an unsigned integer
+   number that can be stored in 64-bits.  Warning: The hardware
+   register is 32-bits wide and can overflow by wrapping around.
+   A single wrap-around between calls to read this value can
+   be detected and will be accounted for in the returned value.
+   At a power consumption of 1 watt, the 32-bit hardware register
+   would wrap-around approximately every 3 days.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 75935a55f573..77d68f17316a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -19,8 +19,10 @@
  /*
   * SF_* - scale factors for particular quantities according to hwmon spec.
   * - power  - microwatts
+ * - energy - microjoules
   */
  #define SF_POWER  100
+#define SF_ENERGY  100
  
  #define FIELD_SHIFT(__mask)\

(BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
@@ -32,12 +34,20 @@ struct i915_hwmon_reg {
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+   i915_reg_t energy_status_all;
+   i915_reg_t energy_status_tile;
+};
+
+struct i915_energy_info {
+   u32 energy_counter_overflow;
+   u32 energy_counter_prev;
  };
  
  struct i915_hwmon_drvdata {

struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+   struct i915_energy_info ei; /*  Energy info for energy1_input */
char name[12];
  };
  
@@ -51,6 +61,7 @@ struct i915_hwmon {

u32 power_max_initial_value;
  
  	int scl_shift_power;

+   int scl_shift_energy;
  };
  
  static void

@@ -121,6 +132,136 @@ _field_scale_and_write(struct i915_hwmon_drvdata *ddat, 
i915_reg_t rgadr,
 bits_to_clear, bits_to_set);
  }
  
+/*

+ * _i915_energy1_input_sub - A custom function to obtain energy1_input.
+ * Use a custom function instead of the usual hwmon helpers in order to
+ * guarantee 64-bits of result to user-space.
+ * Units are microjoules.
+ *
+ * The underlying hardware register is 32-bits and is subject to overflow.
+ * This function compensates for overflow of the 32-bit register by detecting
+ * wrap-around and incrementing an overflow counter.
+ * This only works if the register is sampled often enough to avoid
+ * missing an instance of overflow - achieved either by repeated
+ * queries through the API, or via a possible timer (future - TBD) that
+ * ensures values are read often enough to catch all overflows.
+ *
+ * How long before overflow?  For example, with an example scaling bit
+ * shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and a power draw of
+ * 1000 watts, the 32-bit counter will overflow in approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt:  (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ */
+static int
+_i915_energy1_input_sub(struct i915_hwmon_drvdata *ddat, u64 *energy)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct i915_energy_info *pei = &ddat->ei;
+   int nshift = hwmon->scl_shift_energy;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+   u64 vlo;
+   u64 vhi;
+   i915_reg_t rgaddr;
+
+   rgaddr = hwmon->rg.energy_status_all;
+
+ 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: add payload receiving code (rev5)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: add payload receiving code (rev5)
URL   : https://patchwork.freedesktop.org/series/105096/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11780_full -> Patchwork_105096v5_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (13 -> 13)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_dither@fb-8bpc-vs-panel-8bpc@pipe-a-hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-dg1-18/igt@kms_dither@fb-8bpc-vs-panel-8...@pipe-a-hdmi-a-3.html

  
New tests
-

  New tests have been introduced between CI_DRM_11780_full and 
Patchwork_105096v5_full:

### New IGT tests (4) ###

  * igt@kms_cursor_edge_walk@top-edge@pipe-a-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.23] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-a-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.23] s

  * igt@kms_cursor_edge_walk@top-edge@pipe-a-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.28] s

  * igt@kms_dither@fb-8bpc-vs-panel-8bpc@pipe-a-hdmi-a-3:
- Statuses : 1 skip(s)
- Exec time: [0.06] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][2] -> [FAIL][3] ([i915#6268])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-tglb6/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#3063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb1/igt@gem_...@in-flight-contexts-immediate.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-tglb1/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-iclb4/igt@gem_exec_balan...@parallel-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-iclb7/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-deadline:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#6141])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-iclb6/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) +5 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl:  [PASS][16] -> [SKIP][17] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-kbl6/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_params@secure-non-master:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/shard-iclb4/igt@gem_exec_par...@secure-non-master.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [20]: 
https://in

Re: [Intel-gfx] [PATCH 3/4] drm/i915/hwmon: Add HWMON power sensor support

2022-06-20 Thread Guenter Roeck

On 6/20/22 13:46, Badal Nilawar wrote:

From: Dale B Stimson 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.

v2:
   - Fix review comments (Ashutosh)
   - Do not restore power1_max upon module unload/load sequence
 because on production systems modules are always loaded
 and not unloaded/reloaded (Ashutosh)
   - Fix review comments (Jani)
   - Remove endianness conversion (Ashutosh)

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
  .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 ++
  drivers/gpu/drm/i915/i915_hwmon.c | 226 +-
  drivers/gpu/drm/i915/i915_reg.h   |  15 ++
  drivers/gpu/drm/i915/intel_mchbar_regs.h  |   7 +
  4 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 24c4b7477d51..945f472dd4a2 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact:   dri-de...@lists.freedesktop.org
  Description:  RO. Current Voltage in millivolt.
  
  		Only supported for particular Intel i915 graphics platforms.

+
+What:  /sys/devices/.../hwmon/hwmon/power1_max
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive sustained  (PL1/Tau) power limit in 
microwatts.
+
+   The power controller will throttle the operating frequency
+   if the power averaged over a window (typically seconds)
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_max_default


I don't immediately see the reason for not using the standard power1_cap
attribute, which is described as

If power use rises above this limit, the
system should take action to reduce power use.

and pretty much matches the description above.


+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Card default power limit (default TDP setting).
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index fc06db790243..75935a55f573 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,9 +16,22 @@
  #include "intel_mchbar_regs.h"
  #include "gt/intel_gt_regs.h"
  
+/*

+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - power  - microwatts
+ */
+#define SF_POWER   100
+
+#define FIELD_SHIFT(__mask)\
+   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
+   BUILD_BUG_ON_ZERO((__mask) == 0) +  \
+   __bf_shf(__mask))
  
  struct i915_hwmon_reg {

i915_reg_t gt_perf_status;
+   i915_reg_t pkg_power_sku_unit;
+   i915_reg_t pkg_power_sku;
+   i915_reg_t pkg_rapl_limit;
  };
  
  struct i915_hwmon_drvdata {

@@ -30,18 +43,127 @@ struct i915_hwmon_drvdata {
  
  struct i915_hwmon {

struct i915_hwmon_drvdata ddat;
+
struct mutex hwmon_lock;/* counter overflow logic and rmw */
+
struct i915_hwmon_reg rg;
+
+   u32 power_max_initial_value;
+
+   int scl_shift_power;
  };
  
+static void

+_locked_with_pm_intel_uncore_rmw(struct i915_hwmon_drvdata *ddat,
+i915_reg_t reg, u32 clear, u32 set)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   intel_uncore_rmw(uncore, reg, clear, set);
+
+   mutex_unlock(&hwmon->hwmon_lock);
+}
+
+static u64
+_scale_and_shift(u32 in, u32 scale_factor, int nshift)
+{
+   u64 out = mul_u32_u32(scale_factor, in);
+
+   /* Shift, rounding to nearest */
+   if (nshift > 0)
+   out = (out + (1 << (nshift - 1))) >> nshift;
+   return out;
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+_field_read_and_scale(struct i915_hwmon_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int field_shift,
+ int nshift, u32 scale_factor)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(uncore, rgadr);
+
+   reg_valu

[Intel-gfx] [PATCH 4/4] drm/i915/hwmon: Add HWMON energy support

2022-06-20 Thread Badal Nilawar
From: Dale B Stimson 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display energy utilization

v2:
  - Updated the date and kernel version in feature description

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  16 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 174 +-
 drivers/gpu/drm/i915/i915_hwmon.h |   1 +
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   2 +
 4 files changed, 185 insertions(+), 8 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 945f472dd4a2..2e87d7422b73 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,19 @@ Contact: dri-de...@lists.freedesktop.org
 Description:   RO. Card default power limit (default TDP setting).
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/energy1_input
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Energy input of device in microjoules.
+
+   The returned textual representation is an unsigned integer
+   number that can be stored in 64-bits.  Warning: The hardware
+   register is 32-bits wide and can overflow by wrapping around.
+   A single wrap-around between calls to read this value can
+   be detected and will be accounted for in the returned value.
+   At a power consumption of 1 watt, the 32-bit hardware register
+   would wrap-around approximately every 3 days.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 75935a55f573..77d68f17316a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -19,8 +19,10 @@
 /*
  * SF_* - scale factors for particular quantities according to hwmon spec.
  * - power  - microwatts
+ * - energy - microjoules
  */
 #define SF_POWER   100
+#define SF_ENERGY  100
 
 #define FIELD_SHIFT(__mask)\
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
@@ -32,12 +34,20 @@ struct i915_hwmon_reg {
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+   i915_reg_t energy_status_all;
+   i915_reg_t energy_status_tile;
+};
+
+struct i915_energy_info {
+   u32 energy_counter_overflow;
+   u32 energy_counter_prev;
 };
 
 struct i915_hwmon_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+   struct i915_energy_info ei; /*  Energy info for energy1_input */
char name[12];
 };
 
@@ -51,6 +61,7 @@ struct i915_hwmon {
u32 power_max_initial_value;
 
int scl_shift_power;
+   int scl_shift_energy;
 };
 
 static void
@@ -121,6 +132,136 @@ _field_scale_and_write(struct i915_hwmon_drvdata *ddat, 
i915_reg_t rgadr,
 bits_to_clear, bits_to_set);
 }
 
+/*
+ * _i915_energy1_input_sub - A custom function to obtain energy1_input.
+ * Use a custom function instead of the usual hwmon helpers in order to
+ * guarantee 64-bits of result to user-space.
+ * Units are microjoules.
+ *
+ * The underlying hardware register is 32-bits and is subject to overflow.
+ * This function compensates for overflow of the 32-bit register by detecting
+ * wrap-around and incrementing an overflow counter.
+ * This only works if the register is sampled often enough to avoid
+ * missing an instance of overflow - achieved either by repeated
+ * queries through the API, or via a possible timer (future - TBD) that
+ * ensures values are read often enough to catch all overflows.
+ *
+ * How long before overflow?  For example, with an example scaling bit
+ * shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and a power draw of
+ * 1000 watts, the 32-bit counter will overflow in approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt:  (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ */
+static int
+_i915_energy1_input_sub(struct i915_hwmon_drvdata *ddat, u64 *energy)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct i915_energy_info *pei = &ddat->ei;
+   int nshift = hwmon->scl_shift_energy;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+   u64 vlo;
+   u64 vhi;
+   i915_reg_t rgaddr;
+
+   rgaddr = hwmon->rg.energy_status_all;
+
+   if (!i915_mmio_reg_valid(rgad

[Intel-gfx] [PATCH 3/4] drm/i915/hwmon: Add HWMON power sensor support

2022-06-20 Thread Badal Nilawar
From: Dale B Stimson 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.

v2:
  - Fix review comments (Ashutosh)
  - Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
  - Fix review comments (Jani)
  - Remove endianness conversion (Ashutosh)

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  20 ++
 drivers/gpu/drm/i915/i915_hwmon.c | 226 +-
 drivers/gpu/drm/i915/i915_reg.h   |  15 ++
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   7 +
 4 files changed, 267 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 24c4b7477d51..945f472dd4a2 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact:   dri-de...@lists.freedesktop.org
 Description:   RO. Current Voltage in millivolt.
 
Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_max
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RW. Card reactive sustained  (PL1/Tau) power limit in 
microwatts.
+
+   The power controller will throttle the operating frequency
+   if the power averaged over a window (typically seconds)
+   exceeds this limit.
+
+   Only supported for particular Intel i915 graphics platforms.
+
+What:  /sys/devices/.../hwmon/hwmon/power1_max_default
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Card default power limit (default TDP setting).
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index fc06db790243..75935a55f573 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,9 +16,22 @@
 #include "intel_mchbar_regs.h"
 #include "gt/intel_gt_regs.h"
 
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - power  - microwatts
+ */
+#define SF_POWER   100
+
+#define FIELD_SHIFT(__mask)\
+   (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
+   BUILD_BUG_ON_ZERO((__mask) == 0) +  \
+   __bf_shf(__mask))
 
 struct i915_hwmon_reg {
i915_reg_t gt_perf_status;
+   i915_reg_t pkg_power_sku_unit;
+   i915_reg_t pkg_power_sku;
+   i915_reg_t pkg_rapl_limit;
 };
 
 struct i915_hwmon_drvdata {
@@ -30,18 +43,127 @@ struct i915_hwmon_drvdata {
 
 struct i915_hwmon {
struct i915_hwmon_drvdata ddat;
+
struct mutex hwmon_lock;/* counter overflow logic and rmw */
+
struct i915_hwmon_reg rg;
+
+   u32 power_max_initial_value;
+
+   int scl_shift_power;
 };
 
+static void
+_locked_with_pm_intel_uncore_rmw(struct i915_hwmon_drvdata *ddat,
+i915_reg_t reg, u32 clear, u32 set)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+
+   mutex_lock(&hwmon->hwmon_lock);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   intel_uncore_rmw(uncore, reg, clear, set);
+
+   mutex_unlock(&hwmon->hwmon_lock);
+}
+
+static u64
+_scale_and_shift(u32 in, u32 scale_factor, int nshift)
+{
+   u64 out = mul_u32_u32(scale_factor, in);
+
+   /* Shift, rounding to nearest */
+   if (nshift > 0)
+   out = (out + (1 << (nshift - 1))) >> nshift;
+   return out;
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+_field_read_and_scale(struct i915_hwmon_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int field_shift,
+ int nshift, u32 scale_factor)
+{
+   struct intel_uncore *uncore = ddat->uncore;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   with_intel_runtime_pm(uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(uncore, rgadr);
+
+   reg_value = (reg_value & field_msk) >> field_shift;
+
+   return _scale_and_shift(reg_value, scale_factor, nshift);
+}
+
+static void
+_field_scale_and_write(struct i915_hwmon_drvdata *ddat, i915_reg_t rgadr,
+  u32 field_msk, int field_shift,
+  int nshift, unsigned int scale_factor, long lval)
+{
+ 

[Intel-gfx] [PATCH 2/4] drm/i915/hwmon: Add HWMON current voltage support

2022-06-20 Thread Badal Nilawar
From: Riana Tauro 

As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display current voltage

v2:
  - Updated date and kernel version in feature description
  - Fixed review comments (Ashutosh)

Cc: Anshuman Gupta 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  7 +++
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  3 +
 drivers/gpu/drm/i915/i915_hwmon.c | 63 +++
 3 files changed, 73 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..24c4b7477d51
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What:  /sys/devices/.../hwmon/hwmon/in0_input
+Date:  June 2022
+KernelVersion: 5.19
+Contact:   dri-de...@lists.freedesktop.org
+Description:   RO. Current Voltage in millivolt.
+
+   Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07ef111947b8..63a39e1e00e2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1487,6 +1487,9 @@
 #define VLV_RENDER_C0_COUNT_MMIO(0x138118)
 #define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
 
+#define GEN12_RPSTAT1  _MMIO(0x1381b4)
+#define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
 #define   GEN11_GUNIT  (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2ef40b0c1e70..fc06db790243 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -14,9 +14,11 @@
 #include "i915_hwmon.h"
 #include "i915_drv.h"
 #include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
 
 
 struct i915_hwmon_reg {
+   i915_reg_t gt_perf_status;
 };
 
 struct i915_hwmon_drvdata {
@@ -53,15 +55,65 @@ static const struct attribute_group *hwmon_groups[] = {
 };
 
 
+/*
+ * HWMON SENSOR TYPE = hwmon_in
+ *  - Voltage Input value (in0_input)
+ */
+static const u32 i915_config_in[] = {
+   HWMON_I_INPUT,
+   0
+};
+
+static const struct hwmon_channel_info i915_in = {
+   .type = hwmon_in,
+   .config = i915_config_in,
+};
+
 static const struct hwmon_channel_info *i915_info[] = {
+   &i915_in,
NULL
 };
 
+static umode_t
+i915_in_is_visible(const struct i915_hwmon_drvdata *ddat, u32 attr)
+{
+   struct drm_i915_private *i915 = ddat->uncore->i915;
+
+   switch (attr) {
+   case hwmon_in_input:
+   return (IS_DG1(i915) || IS_DG2(i915)) ? 0444 : 0;
+   default:
+   return 0;
+   }
+}
+
+static int
+i915_in_read(struct i915_hwmon_drvdata *ddat, u32 attr, long *val)
+{
+   struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
+   u32 reg_value;
+
+   switch (attr) {
+   case hwmon_in_input:
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   reg_value = intel_uncore_read(ddat->uncore, 
hwmon->rg.gt_perf_status);
+   *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK, 
reg_value) * 25, 10);
+   return 0;
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
 static umode_t
 i915_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
 {
+   struct i915_hwmon_drvdata *ddat = (struct i915_hwmon_drvdata *)drvdata;
+
switch (type) {
+   case hwmon_in:
+   return i915_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -71,7 +123,11 @@ static int
 i915_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
  int channel, long *val)
 {
+   struct i915_hwmon_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+   case hwmon_in:
+   return i915_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -101,6 +157,13 @@ static const struct hwmon_chip_info i915_chip_info = {
 static void
 i915_hwmon_get_preregistration_info(struct drm_i915_private *i915)
 {
+   struct i915_hwmon *hwmon = i915->hwmon;
+
+   if (IS_DG1(i915) || IS_DG2(i915)) {
+   hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+   } else {
+   hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
+   }
 
 }
 
-- 
2.25.1



[Intel-gfx] [PATCH 1/4] drm/i915/hwmon: Add HWMON infrastructure patch

2022-06-20 Thread Badal Nilawar
From: Dale B Stimson 

As part of the System Managemenent Interface (SMI), HWMON
subsystem can be used to get the raw sensor data.
This patch sets up HWMON infrastructure

v2:
  - Create HWMON infra patch (Ashutosh)
  - Fixed review comments (Jani)
  - Remove "select HWMON" from i915/Kconfig (Jani)

Signed-off-by: Dale B Stimson 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Riana Tauro 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/Makefile  |   3 +
 drivers/gpu/drm/i915/i915_driver.c |   7 ++
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_hwmon.c  | 163 +
 drivers/gpu/drm/i915/i915_hwmon.h  |  21 
 5 files changed, 196 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6c17d3d6db24..09f5b5c74daf 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -208,6 +208,9 @@ i915-y += gt/uc/intel_uc.o \
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
 
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
 # modesetting core code
 i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 0e224761d0ed..60c5cee41aa3 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -80,6 +80,7 @@
 #include "i915_drm_client.h"
 #include "i915_drv.h"
 #include "i915_getparam.h"
+#include "i915_hwmon.h"
 #include "i915_ioc32.h"
 #include "i915_ioctl.h"
 #include "i915_irq.h"
@@ -721,6 +722,9 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
 
intel_gt_driver_register(to_gt(dev_priv));
 
+#ifdef CONFIG_HWMON
+   i915_hwmon_register(dev_priv);
+#endif
intel_display_driver_register(dev_priv);
 
intel_power_domains_enable(dev_priv);
@@ -747,6 +751,9 @@ static void i915_driver_unregister(struct drm_i915_private 
*dev_priv)
 
intel_display_driver_unregister(dev_priv);
 
+#ifdef CONFIG_HWMON
+   i915_hwmon_unregister(dev_priv);
+#endif
intel_gt_driver_unregister(to_gt(dev_priv));
 
i915_perf_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c22f29c3faa0..2357a0295f99 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -705,6 +705,8 @@ struct drm_i915_private {
 
struct i915_perf perf;
 
+   struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct intel_gt gt0;
 
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..2ef40b0c1e70
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/*
+ * Power-related hwmon entries.
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_hwmon.h"
+#include "i915_drv.h"
+#include "intel_mchbar_regs.h"
+
+
+struct i915_hwmon_reg {
+};
+
+struct i915_hwmon_drvdata {
+   struct i915_hwmon *hwmon;
+   struct intel_uncore *uncore;
+   struct device *hwmon_dev;
+   char name[12];
+};
+
+struct i915_hwmon {
+   struct i915_hwmon_drvdata ddat;
+   struct mutex hwmon_lock;/* counter overflow logic and rmw */
+   struct i915_hwmon_reg rg;
+};
+
+static struct attribute *hwmon_attributes[] = {
+   NULL
+};
+
+static umode_t hwmon_attributes_visible(struct kobject *kobj,
+   struct attribute *attr, int index)
+{
+   return 0;
+}
+
+static const struct attribute_group hwmon_attrgroup = {
+   .attrs = hwmon_attributes,
+   .is_visible = hwmon_attributes_visible,
+};
+
+static const struct attribute_group *hwmon_groups[] = {
+   &hwmon_attrgroup,
+   NULL
+};
+
+
+static const struct hwmon_channel_info *i915_info[] = {
+   NULL
+};
+
+static umode_t
+i915_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+   u32 attr, int channel)
+{
+   switch (type) {
+   default:
+   return 0;
+   }
+}
+
+static int
+i915_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static int
+i915_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+  int channel, long val)
+{
+   switch (type) {
+   default:
+   return -EOPNOTSUPP;
+   }
+}
+
+static const struct hwmon_ops i915_hwmon_ops = {
+   .is_visible = i915_is_visible,
+   .read = i915_read,
+   .write = i915_write,
+};
+
+static const struct hwmon_chip_info i915_chip_info = {
+   .ops = &i915_hwmon_ops,
+ 

[Intel-gfx] [PATCH 0/4] drm/i915: Add HWMON support

2022-06-20 Thread Badal Nilawar
v2:
  - Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
  - Fixed review comments (Jani)
  - Fixed review comments (Ashutosh)

Dale B Stimson (3):
  drm/i915/hwmon: Add HWMON infrastructure patch
  drm/i915/hwmon: Add HWMON power sensor support
  drm/i915/hwmon: Add HWMON energy support

Riana Tauro (1):
  drm/i915/hwmon: Add HWMON current voltage support

 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  43 ++
 drivers/gpu/drm/i915/Makefile |   3 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   3 +
 drivers/gpu/drm/i915/i915_driver.c|   7 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_hwmon.c | 608 ++
 drivers/gpu/drm/i915/i915_hwmon.h |  22 +
 drivers/gpu/drm/i915/i915_reg.h   |  15 +
 drivers/gpu/drm/i915/intel_mchbar_regs.h  |   9 +
 9 files changed, 712 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
 create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h

-- 
2.25.1



[Intel-gfx] [PATCH 2/2] drm/i915/fbc: Use lockdep_assert_held()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Replace the mutex_is_locked() stuff with lockdep_assert_held() since
that's what it's there for.

Asoo sprinkle these around so that we have more or less
mirrored coverate for the enable vs. disable instead of the
current situation where the asserts seem to be more or less
randomly thrown around.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 77669e03b9f7..db1c0eb508fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -669,6 +669,7 @@ static void intel_fbc_nuke(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
 
+   lockdep_assert_held(&fbc->lock);
drm_WARN_ON(&i915->drm, fbc->flip_pending);
 
trace_intel_fbc_nuke(fbc->state.plane);
@@ -678,6 +679,8 @@ static void intel_fbc_nuke(struct intel_fbc *fbc)
 
 static void intel_fbc_activate(struct intel_fbc *fbc)
 {
+   lockdep_assert_held(&fbc->lock);
+
intel_fbc_hw_activate(fbc);
intel_fbc_nuke(fbc);
 
@@ -686,9 +689,7 @@ static void intel_fbc_activate(struct intel_fbc *fbc)
 
 static void intel_fbc_deactivate(struct intel_fbc *fbc, const char *reason)
 {
-   struct drm_i915_private *i915 = fbc->i915;
-
-   drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
+   lockdep_assert_held(&fbc->lock);
 
if (fbc->active)
intel_fbc_hw_deactivate(fbc);
@@ -1220,6 +1221,8 @@ static bool __intel_fbc_pre_update(struct 
intel_atomic_state *state,
struct intel_fbc *fbc = plane->fbc;
bool need_vblank_wait = false;
 
+   lockdep_assert_held(&fbc->lock);
+
fbc->flip_pending = true;
 
if (intel_fbc_can_flip_nuke(state, crtc, plane))
@@ -1277,7 +1280,7 @@ static void __intel_fbc_disable(struct intel_fbc *fbc)
struct drm_i915_private *i915 = fbc->i915;
struct intel_plane *plane = fbc->state.plane;
 
-   drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
+   lockdep_assert_held(&fbc->lock);
drm_WARN_ON(&i915->drm, fbc->active);
 
drm_dbg_kms(&i915->drm, "Disabling FBC on [PLANE:%d:%s]\n",
@@ -1292,9 +1295,7 @@ static void __intel_fbc_disable(struct intel_fbc *fbc)
 
 static void __intel_fbc_post_update(struct intel_fbc *fbc)
 {
-   struct drm_i915_private *i915 = fbc->i915;
-
-   drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
+   lockdep_assert_held(&fbc->lock);
 
fbc->flip_pending = false;
 
@@ -1430,6 +1431,8 @@ static void __intel_fbc_enable(struct intel_atomic_state 
*state,
intel_atomic_get_new_plane_state(state, plane);
struct intel_fbc *fbc = plane->fbc;
 
+   lockdep_assert_held(&fbc->lock);
+
if (fbc->state.plane) {
if (fbc->state.plane != plane)
return;
-- 
2.35.1



[Intel-gfx] [PATCH 1/2] drm/i915/fbc: Move flip_pending assignmnt

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Move the flip_pending assignment into __intel_fbc_post_update()
from intel_fbc_post_update(). Now mirrors the pre_update() side.

The only reason the assignment was in the higher level function
is that we used to call __intel_fbc_post_update() from elsewhere
as well. That got cleaned up in commit b39d2c620242 ("drm/i915/fbc:
Call intel_fbc_activate() directly from frontbuffer flush")

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8b807284cde1..77669e03b9f7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1296,6 +1296,8 @@ static void __intel_fbc_post_update(struct intel_fbc *fbc)
 
drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
 
+   fbc->flip_pending = false;
+
if (!fbc->busy_bits)
intel_fbc_activate(fbc);
else
@@ -1317,10 +1319,8 @@ void intel_fbc_post_update(struct intel_atomic_state 
*state,
 
mutex_lock(&fbc->lock);
 
-   if (fbc->state.plane == plane) {
-   fbc->flip_pending = false;
+   if (fbc->state.plane == plane)
__intel_fbc_post_update(fbc);
-   }
 
mutex_unlock(&fbc->lock);
}
-- 
2.35.1



Re: [Intel-gfx] [PATCH v3 03/17] drm/i915: Extract HAS_DOUBLE_BUFFERED_M_N()

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> We have a couple of places that want to make distinction between
> double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> Add a helper for that.
>
> v2: Turn into a HAS_ macro (Jani)
>
> Reviewed-by: Jani Nikula  #v1
> Signed-off-by: Ville Syrjälä 

I'm fine with this, obviously, but also started wondering about the
other direction [1].

BR,
Jani.


[1] 
https://patchwork.freedesktop.org/patch/msgid/dc7e02a24fc231ef0fa3c4e84c01ebf19d61de2f.1655748056.git.jani.nik...@intel.com

> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c  | 3 +--
>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>  3 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6b549aadca13..0384af821ee5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5760,7 +5760,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
> *current_config,
>   PIPE_CONF_CHECK_I(lane_count);
>   PIPE_CONF_CHECK_X(lane_lat_optim_mask);
>  
> - if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
> + if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
>   PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
>   } else {
>   PIPE_CONF_CHECK_M_N(dp_m_n);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e0891b31f089..cf7e4e105891 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1868,8 +1868,7 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct 
> intel_dp *intel_dp,
>  static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
>   enum transcoder cpu_transcoder)
>  {
> - /* M1/N1 is double buffered */
> - if (DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915))
> + if (HAS_DOUBLE_BUFFERED_M_N(i915))
>   return true;
>  
>   return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c22f29c3faa0..805ae6ca7486 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1252,6 +1252,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_DP_MST(dev_priv) (INTEL_INFO(dev_priv)->display.has_dp_mst)
>  #define HAS_DP20(dev_priv)   (IS_DG2(dev_priv))
>  
> +#define HAS_DOUBLE_BUFFERED_M_N(dev_priv)(DISPLAY_VER(dev_priv) >= 9 || 
> IS_BROADWELL(dev_priv))
> +
>  #define HAS_CDCLK_CRAWL(dev_priv) 
> (INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
>  #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
> (INTEL_INFO(dev_priv)->display.has_fpga_dbg)

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [RFC 2/2] drm/i915/display: add intel_display_features.h for feature check macros

2022-06-20 Thread Jani Nikula
Group widely used display feature check macros together in one place.

Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_display_features.h | 37 +++
 .../i915/display/intel_display_power_map.c|  5 +--
 .../drm/i915/display/intel_display_types.h|  1 +
 .../gpu/drm/i915/display/intel_lpe_audio.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h   | 35 --
 drivers/gpu/drm/i915/i915_suspend.c   |  1 +
 drivers/gpu/drm/i915/intel_device_info.c  |  1 +
 drivers/gpu/drm/i915/intel_dram.c |  1 +
 drivers/gpu/drm/i915/intel_pch.c  |  1 +
 9 files changed, 45 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_display_features.h

diff --git a/drivers/gpu/drm/i915/display/intel_display_features.h 
b/drivers/gpu/drm/i915/display/intel_display_features.h
new file mode 100644
index ..019ee4c10252
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_display_features.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __INTEL_DISPLAY_FEATURES_H__
+#define __INTEL_DISPLAY_FEATURES_H__
+
+/* Platform based conditions */
+#define HAS_ASYNC_FLIPS(__i915)(DISPLAY_VER(__i915) >= 5)
+#define HAS_D12_PLANE_MINIMIZATION(__i915) (IS_ROCKETLAKE(__i915) || 
IS_ALDERLAKE_S(__i915))
+#define HAS_DP20(__i915)   (IS_DG2(__i915))
+#define HAS_HW_SAGV_WM(__i915) (DISPLAY_VER(__i915) >= 13 && 
!IS_DGFX(__i915))
+#define HAS_IPS(__i915)(IS_HSW_ULT(__i915) || 
IS_BROADWELL(__i915))
+#define HAS_MSO(__i915)(DISPLAY_VER(__i915) >= 12)
+#define HAS_VRR(__i915)(DISPLAY_VER(__i915) >= 11)
+
+/* Device info flags */
+#define HAS_DDI(__i915)
(INTEL_INFO(__i915)->display.has_ddi)
+#define HAS_DISPLAY(__i915)(INTEL_INFO(__i915)->display.pipe_mask 
!= 0)
+#define HAS_DP_MST(__i915) (INTEL_INFO(__i915)->display.has_dp_mst)
+#define HAS_FBC(__i915)
(INTEL_INFO(__i915)->display.fbc_mask != 0)
+#define HAS_GMCH(__i915)   (INTEL_INFO(__i915)->display.has_gmch)
+#define HAS_IPC(__i915)
(INTEL_INFO(__i915)->display.has_ipc)
+#define HAS_PSR(__i915)
(INTEL_INFO(__i915)->display.has_psr)
+#define HAS_TRANSCODER(__i915, trans)  
((INTEL_INFO(__i915)->display.cpu_transcoder_mask & BIT(trans)) != 0)
+#define I915_HAS_HOTPLUG(__i915)   
(INTEL_INFO(__i915)->display.has_hotplug)
+#define INTEL_NUM_PIPES(__i915)
(hweight8(INTEL_INFO(__i915)->display.pipe_mask))
+#define SUPPORTS_TV(__i915)
(INTEL_INFO(__i915)->display.supports_tv)
+
+/* Only valid when HAS_DISPLAY() is true */
+#define INTEL_DISPLAY_ENABLED(__i915) \
+   (drm_WARN_ON(&(__i915)->drm, !HAS_DISPLAY(__i915)), \
+!(__i915)->params.disable_display &&   \
+!intel_opregion_headless_sku(__i915))
+
+#endif /* __INTEL_DISPLAY_FEATURES_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c 
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 97b367f39f35..d84fdcdea588 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -5,11 +5,10 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
-
-#include "vlv_sideband_reg.h"
-
+#include "intel_display_features.h"
 #include "intel_display_power_map.h"
 #include "intel_display_power_well.h"
+#include "vlv_sideband_reg.h"
 
 #define __LIST_INLINE_ELEMS(__elem_type, ...) \
((__elem_type[]) { __VA_ARGS__ })
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8b0949b6dc75..9dd008c7b4ec 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -49,6 +49,7 @@
 #include "i915_vma_types.h"
 #include "intel_bios.h"
 #include "intel_display.h"
+#include "intel_display_features.h"
 #include "intel_display_power.h"
 #include "intel_dpll_mgr.h"
 #include "intel_pm_types.h"
diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index 4970bf146c4a..9c89801ebaa7 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -72,6 +72,7 @@
 
 #include "i915_drv.h"
 #include "intel_de.h"
+#include "intel_display_features.h"
 #include "intel_lpe_audio.h"
 
 #define HAS_LPE_AUDIO(dev_priv) ((dev_priv)->audio.lpe.platdev != NULL)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1d9ba4cf9e01..fd2a4c3b5d74 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1227,20 +1227,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  */
 #define HAS_128_BYT

[Intel-gfx] [RFC 1/2] drm/i915/display: spread out HAS_*() feature macros

2022-06-20 Thread Jani Nikula
Expand single-use display feature macros around device info flags
in-place, and remove the macros.

Move display feature macros used in one file only into that file.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_bios.c|  2 ++
 drivers/gpu/drm/i915/display/intel_cdclk.c   |  2 ++
 drivers/gpu/drm/i915/display/intel_cursor.c  |  2 ++
 drivers/gpu/drm/i915/display/intel_dmc.c |  2 ++
 drivers/gpu/drm/i915/display/intel_dsb.c |  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c   |  4 
 drivers/gpu/drm/i915/display/intel_overlay.c |  5 ++--
 drivers/gpu/drm/i915/display/intel_psr.c |  3 +++
 drivers/gpu/drm/i915/i915_drv.h  | 25 
 drivers/gpu/drm/i915/intel_pm.c  |  4 
 10 files changed, 23 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index e97f1f979a48..2786a2226d78 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -60,6 +60,8 @@
  * that.
  */
 
+#define HAS_LSPCON(__i915) (IS_DISPLAY_VER(__i915, 9, 10))
+
 /* Wrapper for VBT child device config */
 struct intel_bios_encoder_data {
struct drm_i915_private *i915;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 6e80162632dd..1ba70d47407f 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -66,6 +66,8 @@
  * dividers can be programmed correctly.
  */
 
+#define HAS_CDCLK_CRAWL(__i915) (INTEL_INFO(__i915)->display.has_cdclk_crawl)
+
 struct intel_cdclk_funcs {
void (*get_cdclk)(struct drm_i915_private *i915,
  struct intel_cdclk_config *cdclk_config);
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c 
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 8c80de877605..9b38a61b7a6a 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -23,6 +23,8 @@
 #include "intel_psr.h"
 #include "intel_sprite.h"
 
+#define HAS_CUR_FBC(__i915) (!HAS_GMCH(__i915) && DISPLAY_VER(__i915) >= 7)
+
 /* Cursor formats */
 static const u32 intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index fa9ef591b885..0480866f61d4 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -38,6 +38,8 @@
  * low-power state and comes back to normal.
  */
 
+#define HAS_DMC(__i915) (INTEL_INFO(__i915)->display.has_dmc)
+
 #define DMC_VERSION(major, minor)  ((major) << 16 | (minor))
 #define DMC_VERSION_MAJOR(version) ((version) >> 16)
 #define DMC_VERSION_MINOR(version) ((version) & 0x)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c 
b/drivers/gpu/drm/i915/display/intel_dsb.c
index c4affcb216fd..f94235fbd100 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -270,7 +270,7 @@ void intel_dsb_prepare(struct intel_crtc_state *crtc_state)
u32 *buf;
intel_wakeref_t wakeref;
 
-   if (!HAS_DSB(i915))
+   if (!INTEL_INFO(i915)->display.has_dsb)
return;
 
dsb = kmalloc(sizeof(*dsb), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index a6ba7fb72339..b08e193777ce 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -38,6 +38,10 @@
 #include "intel_display_types.h"
 #include "intel_gmbus.h"
 
+#define HAS_GMBUS_IRQ(__i915) (DISPLAY_VER(__i915) >= 4)
+#define HAS_GMBUS_BURST_READ(__i915) \
+   (DISPLAY_VER(__i915) >= 11 || IS_GEMINILAKE(__i915) || 
IS_KABYLAKE(__i915))
+
 struct intel_gmbus {
struct i2c_adapter adapter;
 #define GMBUS_FORCE_BIT_RETRY (1U << 31)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 79ed8bd04a07..fb67da08624a 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1386,7 +1386,7 @@ void intel_overlay_setup(struct drm_i915_private 
*dev_priv)
struct intel_engine_cs *engine;
int ret;
 
-   if (!HAS_OVERLAY(dev_priv))
+   if (!INTEL_INFO(dev_priv)->display.has_overlay)
return;
 
engine = to_gt(dev_priv)->engine[RCS0];
@@ -1408,7 +1408,8 @@ void intel_overlay_setup(struct drm_i915_private 
*dev_priv)
i915_active_init(&overlay->last_flip,
 NULL, intel_overlay_last_flip_retire, 0);
 
-   ret = get_registers(overlay, OVERLAY_NEEDS_PHYSICAL(dev_priv));
+   ret = get_registers(overlay,
+   
INTEL_INFO(dev_priv)->display.overlay_needs_physical);
if (ret)
goto out_free;
 
diff --git a/drivers/gpu/drm/

[Intel-gfx] [RFC 0/2] drm/i915: move display feature check macros out of i915_drv.h

2022-06-20 Thread Jani Nikula
Started pondering about this based on [1]. Spread out single-use and
single-file-use HAS_*() macros, and move display macros to
display/intel_display_features.h.

Food for thought at least. Doesn't look too bad tbh.

BR,
Jani.


[1] https://lore.kernel.org/r/yrcoxugseuzl+...@intel.com

Jani Nikula (2):
  drm/i915/display: spread out HAS_*() feature macros
  drm/i915/display: add intel_display_features.h for feature check
macros

 drivers/gpu/drm/i915/display/intel_bios.c |  2 +
 drivers/gpu/drm/i915/display/intel_cdclk.c|  2 +
 drivers/gpu/drm/i915/display/intel_cursor.c   |  2 +
 .../drm/i915/display/intel_display_features.h | 37 
 .../i915/display/intel_display_power_map.c|  5 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dmc.c  |  2 +
 drivers/gpu/drm/i915/display/intel_dsb.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  4 ++
 .../gpu/drm/i915/display/intel_lpe_audio.c|  1 +
 drivers/gpu/drm/i915/display/intel_overlay.c  |  5 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  3 +
 drivers/gpu/drm/i915/i915_drv.h   | 60 ---
 drivers/gpu/drm/i915/i915_suspend.c   |  1 +
 drivers/gpu/drm/i915/intel_device_info.c  |  1 +
 drivers/gpu/drm/i915/intel_dram.c |  1 +
 drivers/gpu/drm/i915/intel_pch.c  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   |  4 ++
 18 files changed, 68 insertions(+), 66 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_display_features.h

-- 
2.30.2



[Intel-gfx] [PATCH v3 04/17] drm/i915/dsi: Extract {vlv, bxt}_get_pclk()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Extract the state->freq computation for VLV/BXT DSI PLL
into small helpers. We want to use these during the state
computation as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 121 -
 1 file changed, 68 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c 
b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
index 5894b0138343..2606dbf09ccc 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
@@ -113,6 +113,61 @@ static int dsi_calc_mnp(struct drm_i915_private *dev_priv,
return 0;
 }
 
+static int vlv_dsi_pclk(struct intel_encoder *encoder,
+   struct intel_crtc_state *config)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+   int bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
+   u32 dsi_clock;
+   u32 pll_ctl, pll_div;
+   u32 m = 0, p = 0, n;
+   int refclk = IS_CHERRYVIEW(dev_priv) ? 10 : 25000;
+   int i;
+
+   pll_ctl = config->dsi_pll.ctrl;
+   pll_div = config->dsi_pll.div;
+
+   /* mask out other bits and extract the P1 divisor */
+   pll_ctl &= DSI_PLL_P1_POST_DIV_MASK;
+   pll_ctl = pll_ctl >> (DSI_PLL_P1_POST_DIV_SHIFT - 2);
+
+   /* N1 divisor */
+   n = (pll_div & DSI_PLL_N1_DIV_MASK) >> DSI_PLL_N1_DIV_SHIFT;
+   n = 1 << n; /* register has log2(N1) */
+
+   /* mask out the other bits and extract the M1 divisor */
+   pll_div &= DSI_PLL_M1_DIV_MASK;
+   pll_div = pll_div >> DSI_PLL_M1_DIV_SHIFT;
+
+   while (pll_ctl) {
+   pll_ctl = pll_ctl >> 1;
+   p++;
+   }
+   p--;
+
+   if (!p) {
+   drm_err(&dev_priv->drm, "wrong P1 divisor\n");
+   return 0;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(lfsr_converts); i++) {
+   if (lfsr_converts[i] == pll_div)
+   break;
+   }
+
+   if (i == ARRAY_SIZE(lfsr_converts)) {
+   drm_err(&dev_priv->drm, "wrong m_seed programmed\n");
+   return 0;
+   }
+
+   m = i + 62;
+
+   dsi_clock = (m * refclk) / (p * n);
+
+   return DIV_ROUND_CLOSEST(dsi_clock * intel_dsi->lane_count, bpp);
+}
+
 /*
  * XXX: The muxing and gating is hard coded for now. Need to add support for
  * sharing PLLs with two DSI outputs.
@@ -262,13 +317,7 @@ u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
 struct intel_crtc_state *config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
-   int bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
-   u32 dsi_clock, pclk;
u32 pll_ctl, pll_div;
-   u32 m = 0, p = 0, n;
-   int refclk = IS_CHERRYVIEW(dev_priv) ? 10 : 25000;
-   int i;
 
drm_dbg_kms(&dev_priv->drm, "\n");
 
@@ -280,65 +329,31 @@ u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
config->dsi_pll.ctrl = pll_ctl & ~DSI_PLL_LOCK;
config->dsi_pll.div = pll_div;
 
-   /* mask out other bits and extract the P1 divisor */
-   pll_ctl &= DSI_PLL_P1_POST_DIV_MASK;
-   pll_ctl = pll_ctl >> (DSI_PLL_P1_POST_DIV_SHIFT - 2);
+   return vlv_dsi_pclk(encoder, config);
+}
 
-   /* N1 divisor */
-   n = (pll_div & DSI_PLL_N1_DIV_MASK) >> DSI_PLL_N1_DIV_SHIFT;
-   n = 1 << n; /* register has log2(N1) */
+static int bxt_dsi_pclk(struct intel_encoder *encoder,
+   const struct intel_crtc_state *config)
+{
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+   int bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
+   u32 dsi_ratio, dsi_clk;
 
-   /* mask out the other bits and extract the M1 divisor */
-   pll_div &= DSI_PLL_M1_DIV_MASK;
-   pll_div = pll_div >> DSI_PLL_M1_DIV_SHIFT;
+   dsi_ratio = config->dsi_pll.ctrl & BXT_DSI_PLL_RATIO_MASK;
+   dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
 
-   while (pll_ctl) {
-   pll_ctl = pll_ctl >> 1;
-   p++;
-   }
-   p--;
-
-   if (!p) {
-   drm_err(&dev_priv->drm, "wrong P1 divisor\n");
-   return 0;
-   }
-
-   for (i = 0; i < ARRAY_SIZE(lfsr_converts); i++) {
-   if (lfsr_converts[i] == pll_div)
-   break;
-   }
-
-   if (i == ARRAY_SIZE(lfsr_converts)) {
-   drm_err(&dev_priv->drm, "wrong m_seed programmed\n");
-   return 0;
-   }
-
-   m = i + 62;
-
-   dsi_clock = (m * refclk) / (p * n);
-
-   pclk = DIV_ROUND_CLOSEST(dsi_clock * intel_dsi->lane_count, bpp);
-
-   return pclk;
+   return DIV_ROUND_CLOSEST(dsi_clk * intel_dsi->lane_count, bpp);
 }
 
 u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
   

[Intel-gfx] [PATCH v3 08/17] drm/i915: Compute clocks earlier

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Do the DPLL computation before fastset checks. This should
allow us to get rid of all that horrible fuzzy clock handling
for fastsets. Who knows how many bugs there are caused by our
state not actually matching what the hardware will generate.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e484c7492754..7b1fa24bff19 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2696,6 +2696,10 @@ static int intel_crtc_compute_config(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
int ret;
 
+   ret = intel_dpll_crtc_compute_clock(state, crtc);
+   if (ret)
+   return ret;
+
ret = intel_crtc_compute_pipe_src(crtc_state);
if (ret)
return ret;
@@ -6884,10 +6888,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (intel_crtc_needs_modeset(new_crtc_state)) {
any_ms = true;
 
-   ret = intel_dpll_crtc_compute_clock(state, crtc);
-   if (ret)
-   goto fail;
-
intel_release_shared_dplls(state, crtc);
continue;
}
-- 
2.35.1



[Intel-gfx] [PATCH v3 07/17] drm/i915: Feed the DPLL output freq back into crtc_state

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
frequency we're going to be getting from the hardware. This will
let us accurately compute all derived state that depends on those.

v2: Reintroduce iCLKIP WARN
v3: Try to deal with VLV/BXT DSI PLL as well

Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_crt.c  |  3 +
 drivers/gpu/drm/i915/display/intel_dpll.c | 60 ++-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 24 +++-
 .../gpu/drm/i915/display/intel_pch_refclk.c   | 10 
 .../gpu/drm/i915/display/intel_pch_refclk.h   |  1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c| 11 ++--
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 20 ++-
 7 files changed, 117 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 6a3893c8ff22..a225af030ad7 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -46,6 +46,7 @@
 #include "intel_gmbus.h"
 #include "intel_hotplug.h"
 #include "intel_pch_display.h"
+#include "intel_pch_refclk.h"
 
 /* Here's the desired hotplug mode */
 #define ADPA_HOTPLUG_BITS (ADPA_CRT_HOTPLUG_PERIOD_128 |   \
@@ -444,6 +445,8 @@ static int hsw_crt_compute_config(struct intel_encoder 
*encoder,
/* FDI must always be 2.7 GHz */
pipe_config->port_clock = 135000 * 2;
 
+   adjusted_mode->crtc_clock = lpt_iclkip(pipe_config);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 69dc018385db..cffce8b86d64 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -938,12 +938,25 @@ static int hsw_crtc_compute_clock(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
intel_get_crtc_new_encoder(state, crtc_state);
+   int ret;
 
if (DISPLAY_VER(dev_priv) < 11 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
return 0;
 
-   return intel_compute_shared_dplls(state, crtc, encoder);
+   ret = intel_compute_shared_dplls(state, crtc, encoder);
+   if (ret)
+   return ret;
+
+   /* FIXME this is a mess */
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
+   return 0;
+
+   /* CRT dotclock is determined via other means */
+   if (!crtc_state->has_pch_encoder)
+   crtc_state->hw.adjusted_mode.crtc_clock = 
intel_crtc_dotclock(crtc_state);
+
+   return 0;
 }
 
 static int hsw_crtc_get_shared_dpll(struct intel_atomic_state *state,
@@ -969,8 +982,15 @@ static int dg2_crtc_compute_clock(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct intel_encoder *encoder =
intel_get_crtc_new_encoder(state, crtc_state);
+   int ret;
 
-   return intel_mpllb_calc_state(crtc_state, encoder);
+   ret = intel_mpllb_calc_state(crtc_state, encoder);
+   if (ret)
+   return ret;
+
+   crtc_state->hw.adjusted_mode.crtc_clock = 
intel_crtc_dotclock(crtc_state);
+
+   return 0;
 }
 
 static bool ilk_needs_fb_cb_tune(const struct dpll *dpll, int factor)
@@ -1096,6 +1116,7 @@ static int ilk_crtc_compute_clock(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
const struct intel_limit *limit;
int refclk = 12;
+   int ret;
 
/* CPU eDP is the only output that doesn't need a PCH PLL of its own. */
if (!crtc_state->has_pch_encoder)
@@ -1132,7 +1153,14 @@ static int ilk_crtc_compute_clock(struct 
intel_atomic_state *state,
ilk_compute_dpll(crtc_state, &crtc_state->dpll,
 &crtc_state->dpll);
 
-   return intel_compute_shared_dplls(state, crtc, NULL);
+   ret = intel_compute_shared_dplls(state, crtc, NULL);
+   if (ret)
+   return ret;
+
+   crtc_state->port_clock = crtc_state->dpll.dot;
+   crtc_state->hw.adjusted_mode.crtc_clock = 
intel_crtc_dotclock(crtc_state);
+
+   return ret;
 }
 
 static int ilk_crtc_get_shared_dpll(struct intel_atomic_state *state,
@@ -1198,6 +1226,13 @@ static int chv_crtc_compute_clock(struct 
intel_atomic_state *state,
 
chv_compute_dpll(crtc_state);
 
+   /* FIXME this is a mess */
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
+   return 0;
+
+   crtc_state->port_clock = crtc_state->dpll.dot;
+   crtc_state->hw.adjusted_mode.crtc_clock = 
intel_crtc_dotclock(crtc_state);
+
return 0;
 }
 
@@ -1217,6 +1252,13 @@ static int vlv_crtc_compute_clock(struct 
intel_atomic_state *state,
 
vlv_compute_dpll(crtc_state);
 
+   /* FIXME this is a mess */
+   if (intel

[Intel-gfx] [PATCH v3 17/17] drm/i915: Round TMDS clock to nearest

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Use round-to-nearest behavour when calculating the TMDS clock.
Matches what we do for most other clock related things.

Acked-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
 drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5ec954b293a2..c8a4e9e5f19b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4494,7 +4494,8 @@ int intel_crtc_dotclock(const struct intel_crtc_state 
*pipe_config)
dotclock = intel_dotclock_calculate(pipe_config->port_clock,
&pipe_config->dp_m_n);
else if (pipe_config->has_hdmi_sink && pipe_config->pipe_bpp > 24)
-   dotclock = pipe_config->port_clock * 24 / pipe_config->pipe_bpp;
+   dotclock = DIV_ROUND_CLOSEST(pipe_config->port_clock * 24,
+pipe_config->pipe_bpp);
else
dotclock = pipe_config->port_clock;
 
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 1ae09431f53a..0b04b3800cd4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1891,7 +1891,7 @@ int intel_hdmi_tmds_clock(int clock, int bpc, bool 
ycbcr420_output)
 *  1.5x for 12bpc
 *  1.25x for 10bpc
 */
-   return clock * bpc / 8;
+   return DIV_ROUND_CLOSEST(clock * bpc, 8);
 }
 
 static bool intel_hdmi_source_bpc_possible(struct drm_i915_private *i915, int 
bpc)
-- 
2.35.1



[Intel-gfx] [PATCH v3 16/17] drm/i915: Use a fixed N value always

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Windows/BIOS always uses fixed N values. Let's match that
behaviour.

Allows us to also get rid of that constant_n quirk stuff.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 36 +---
 drivers/gpu/drm/i915/display/intel_display.h |  2 +-
 drivers/gpu/drm/i915/display/intel_dp.c  | 10 +++---
 drivers/gpu/drm/i915/display/intel_dp_mst.c  |  3 +-
 drivers/gpu/drm/i915/display/intel_fdi.c |  2 +-
 5 files changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 43c00f8b4057..5ec954b293a2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2726,19 +2726,11 @@ intel_reduce_m_n_ratio(u32 *num, u32 *den)
}
 }
 
-static void compute_m_n(unsigned int m, unsigned int n,
-   u32 *ret_m, u32 *ret_n,
-   bool constant_n)
+static void compute_m_n(u32 *ret_m, u32 *ret_n,
+   u32 m, u32 n, u32 constant_n)
 {
-   /*
-* Several DP dongles in particular seem to be fussy about
-* too large link M/N values. Give N value as 0x8000 that
-* should be acceptable by specific devices. 0x8000 is the
-* specified fixed N value for asynchronous clock mode,
-* which the devices expect also in synchronous clock mode.
-*/
if (constant_n)
-   *ret_n = DP_LINK_CONSTANT_N_VALUE;
+   *ret_n = constant_n;
else
*ret_n = min_t(unsigned int, roundup_pow_of_two(n), 
DATA_LINK_N_MAX);
 
@@ -2750,22 +2742,28 @@ void
 intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
   struct intel_link_m_n *m_n,
-  bool constant_n, bool fec_enable)
+  bool fec_enable)
 {
u32 data_clock = bits_per_pixel * pixel_clock;
 
if (fec_enable)
data_clock = intel_dp_mode_to_fec_clock(data_clock);
 
+   /*
+* Windows/BIOS uses fixed M/N values always. Follow suit.
+*
+* Also several DP dongles in particular seem to be fussy
+* about too large link M/N values. Presumably the 20bit
+* value used by Windows/BIOS is acceptable to everyone.
+*/
m_n->tu = 64;
-   compute_m_n(data_clock,
-   link_clock * nlanes * 8,
-   &m_n->data_m, &m_n->data_n,
-   constant_n);
+   compute_m_n(&m_n->data_m, &m_n->data_n,
+   data_clock, link_clock * nlanes * 8,
+   0x800);
 
-   compute_m_n(pixel_clock, link_clock,
-   &m_n->link_m, &m_n->link_n,
-   constant_n);
+   compute_m_n(&m_n->link_m, &m_n->link_n,
+   pixel_clock, link_clock,
+   0x8);
 }
 
 static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 8610e17cc593..e00a6022acf8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -547,7 +547,7 @@ u8 intel_calc_active_pipes(struct intel_atomic_state *state,
 void intel_link_compute_m_n(u16 bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
-   bool constant_n, bool fec_enable);
+   bool fec_enable);
 u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
  u32 pixel_format, u64 modifier);
 enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 90fa8eda6911..40c451d1ee85 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1930,7 +1930,7 @@ static bool can_enable_drrs(struct intel_connector 
*connector,
 static void
 intel_dp_drrs_compute_config(struct intel_connector *connector,
 struct intel_crtc_state *pipe_config,
-int output_bpp, bool constant_n)
+int output_bpp)
 {
struct drm_i915_private *i915 = to_i915(connector->base.dev);
const struct drm_display_mode *downclock_mode =
@@ -1957,7 +1957,7 @@ intel_dp_drrs_compute_config(struct intel_connector 
*connector,
 
intel_link_compute_m_n(output_bpp, pipe_config->lane_count, pixel_clock,
   pipe_config->port_clock, &pipe_config->dp_m2_n2,
-  constant_n, pipe_config->fec_enable);
+  pipe_config->fec_enable);
 
/* FIXME: abstract this better */
if (pipe_config->splitter.

[Intel-gfx] [PATCH v3 15/17] drm/i915: Allow M/N change during fastset on bdw+

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

On BDW+ M/N are double buffered and so we can easily reprogram them
during a fastset. So for eDP panels that support seamless DRRS we
can just change these without a full modeset.

For earlier platforms we'd need to play tricks with M1/N1 vs.
M2/N2 during the fastset to make sure we do the switch atomically.
Not sure the added complexity is worth the hassle, so leave it
alone for now.

The slight downside is that we have to keep the link running at
a link rate capable of supporting the highest refresh rate we
want to use. For the moment we just pick the highest mode the
panel reports and calculate the link based on that. This might
need further refinement (eg. if we run into bandwidth
restrictions)...

v2: Only use the high link rate if the platform really supports
the seamless M/N change uring fastset (ie. bdw+)
v3: Rebase due to HAS_DOUBLE_BUFFERED_M_N()

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 13 +--
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 37 ---
 3 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index afef6a826ef2..43c00f8b4057 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5719,7 +5719,8 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_X(lane_lat_optim_mask);
 
if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
-   PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
+   if (!fastset || !pipe_config->seamless_m_n)
+   PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
} else {
PIPE_CONF_CHECK_M_N(dp_m_n);
PIPE_CONF_CHECK_M_N(dp_m2_n2);
@@ -5851,8 +5852,10 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
if (IS_G4X(dev_priv) || DISPLAY_VER(dev_priv) >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
 
-   PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
-   PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
+   if (!fastset || !pipe_config->seamless_m_n) {
+   PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
+   PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
+   }
PIPE_CONF_CHECK_I(port_clock);
 
PIPE_CONF_CHECK_I(min_voltage_level);
@@ -6991,6 +6994,10 @@ static void intel_pipe_fastset(const struct 
intel_crtc_state *old_crtc_state,
if (DISPLAY_VER(dev_priv) >= 9 ||
IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
hsw_set_linetime_wm(new_crtc_state);
+
+   if (new_crtc_state->seamless_m_n)
+   intel_cpu_transcoder_set_m1_n1(crtc, 
new_crtc_state->cpu_transcoder,
+  &new_crtc_state->dp_m_n);
 }
 
 static void commit_pipe_pre_planes(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 8b0949b6dc75..95159d1c8ca8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1129,6 +1129,7 @@ struct intel_crtc_state {
/* m2_n2 for eDP downclock */
struct intel_link_m_n dp_m2_n2;
bool has_drrs;
+   bool seamless_m_n;
 
/* PSR is supported but might not be enabled due the lack of enabled 
planes */
bool has_psr;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index cf7e4e105891..90fa8eda6911 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1311,21 +1311,45 @@ intel_dp_adjust_compliance_config(struct intel_dp 
*intel_dp,
}
 }
 
+static bool has_seamless_m_n(struct intel_connector *connector)
+{
+   struct drm_i915_private *i915 = to_i915(connector->base.dev);
+
+   /*
+* Seamless M/N reprogramming only implemented
+* for BDW+ double buffered M/N registers so far.
+*/
+   return HAS_DOUBLE_BUFFERED_M_N(i915) &&
+   intel_panel_drrs_type(connector) == DRRS_TYPE_SEAMLESS;
+}
+
+static int intel_dp_mode_clock(const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
+{
+   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
+   const struct drm_display_mode *adjusted_mode = 
&crtc_state->hw.adjusted_mode;
+
+   /* FIXME a bit of a mess wrt clock vs. crtc_clock */
+   if (has_seamless_m_n(connector))
+   return intel_panel_highest_mode(connector, 
adjusted_mode)->clock;
+   else
+   return adjusted_mode->crtc_clock;
+}
+
 /* Optimize link config in order: max bpp, min clock, min lanes */
 static int
 intel_dp_comput

[Intel-gfx] [PATCH v3 14/17] drm/i915: Add intel_panel_highest_mode()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Add a function to get the fixed_mode with the highest clock.
The plan is to use this for the link bw calculation on seamless
DRRS panels so that we alwasy end up with the same link params
regardless of the requested refresh rate. This will allow fastset
to do seamless refresh rate changes based on userspace request
instead of having to go for a full modeset.

TODO: the function name isn't great

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_panel.c | 15 +++
 drivers/gpu/drm/i915/display/intel_panel.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_panel.c 
b/drivers/gpu/drm/i915/display/intel_panel.c
index 237a40623dd7..c738de27e49b 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -114,6 +114,21 @@ intel_panel_downclock_mode(struct intel_connector 
*connector,
return best_mode;
 }
 
+const struct drm_display_mode *
+intel_panel_highest_mode(struct intel_connector *connector,
+const struct drm_display_mode *adjusted_mode)
+{
+   const struct drm_display_mode *fixed_mode, *best_mode = adjusted_mode;
+
+   /* pick the fixed_mode that has the highest clock */
+   list_for_each_entry(fixed_mode, &connector->panel.fixed_modes, head) {
+   if (fixed_mode->clock > best_mode->clock)
+   best_mode = fixed_mode;
+   }
+
+   return best_mode;
+}
+
 int intel_panel_get_modes(struct intel_connector *connector)
 {
const struct drm_display_mode *fixed_mode;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.h 
b/drivers/gpu/drm/i915/display/intel_panel.h
index b087c0c3cc6d..eff3ffd3d082 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.h
+++ b/drivers/gpu/drm/i915/display/intel_panel.h
@@ -31,6 +31,9 @@ intel_panel_fixed_mode(struct intel_connector *connector,
 const struct drm_display_mode *
 intel_panel_downclock_mode(struct intel_connector *connector,
   const struct drm_display_mode *adjusted_mode);
+const struct drm_display_mode *
+intel_panel_highest_mode(struct intel_connector *connector,
+const struct drm_display_mode *adjusted_mode);
 int intel_panel_get_modes(struct intel_connector *connector);
 enum drrs_type intel_panel_drrs_type(struct intel_connector *connector);
 enum drm_mode_status
-- 
2.35.1



[Intel-gfx] [PATCH v3 13/17] drm/i915: Skip intel_modeset_pipe_config_late() if the pipe is not enabled

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

No sense in calling intel_modeset_pipe_config_late() for a disabled
pipe.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 8affeac4d963..afef6a826ef2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6772,9 +6772,11 @@ static int intel_atomic_check(struct drm_device *dev,
if (!intel_crtc_needs_modeset(new_crtc_state))
continue;
 
-   ret = intel_modeset_pipe_config_late(state, crtc);
-   if (ret)
-   goto fail;
+   if (new_crtc_state->hw.enable) {
+   ret = intel_modeset_pipe_config_late(state, crtc);
+   if (ret)
+   goto fail;
+   }
 
intel_crtc_check_fastset(old_crtc_state, new_crtc_state);
}
-- 
2.35.1



[Intel-gfx] [PATCH v3 12/17] drm/i915: Nuke fastet state copy hacks

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Now that we no longer do the fuzzy clock and M/N checks we can
get rid of the fastset state copy hacks.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
 1 file changed, 3 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 9bf132707306..8affeac4d963 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6116,23 +6116,6 @@ static void intel_crtc_check_fastset(const struct 
intel_crtc_state *old_crtc_sta
new_crtc_state->update_pipe = true;
 }
 
-static void intel_crtc_copy_fastset(const struct intel_crtc_state 
*old_crtc_state,
-   struct intel_crtc_state *new_crtc_state)
-{
-   /*
-* If we're not doing the full modeset we want to
-* keep the current M/N values as they may be
-* sufficiently different to the computed values
-* to cause problems.
-*
-* FIXME: should really copy more fuzzy state here
-*/
-   new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
-   new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
-   new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
-   new_crtc_state->has_drrs = old_crtc_state->has_drrs;
-}
-
 static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
  struct intel_crtc *crtc,
  u8 plane_ids_mask)
@@ -6842,17 +6825,12 @@ static int intel_atomic_check(struct drm_device *dev,
 
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
-   if (intel_crtc_needs_modeset(new_crtc_state)) {
-   any_ms = true;
-
-   intel_release_shared_dplls(state, crtc);
+   if (!intel_crtc_needs_modeset(new_crtc_state))
continue;
-   }
 
-   if (!new_crtc_state->update_pipe)
-   continue;
+   any_ms = true;
 
-   intel_crtc_copy_fastset(old_crtc_state, new_crtc_state);
+   intel_release_shared_dplls(state, crtc);
}
 
if (any_ms && !check_digital_port_conflicts(state)) {
-- 
2.35.1



[Intel-gfx] [PATCH v3 11/17] drm/i915: Set active dpll early for icl+

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

To make the fastboot checks at least somewhat sensible let's mark
the expected DPLL as the active one right after we finished the
state computation. Otherwise intel_pipe_config_compare() will
always be comparing things against NULL/0.

TODO: This is still not really right. If the previous commit
had to fall back to the other PLL then the comparisong will
now fail. I guess intel_pipe_config_compare() should rather
be comparing port_dplls[] instead. But to do that we really
should just unify every platform to use the port_dplls[]
approach whether they have any need for PLL fallbacks or not.

Acked-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 09816526c5e4..c99ec8da20e0 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3213,6 +3213,9 @@ static int icl_compute_combo_phy_dpll(struct 
intel_atomic_state *state,
 
icl_calc_dpll_state(dev_priv, &pll_params, &port_dpll->hw_state);
 
+   /* this is mainly for the fastset check */
+   icl_set_active_port_dpll(crtc_state, ICL_PORT_DPLL_DEFAULT);
+
crtc_state->port_clock = icl_ddi_combo_pll_get_freq(dev_priv, NULL,

&port_dpll->hw_state);
 
@@ -3301,6 +3304,9 @@ static int icl_compute_tc_phy_dplls(struct 
intel_atomic_state *state,
if (ret)
return ret;
 
+   /* this is mainly for the fastset check */
+   icl_set_active_port_dpll(crtc_state, ICL_PORT_DPLL_MG_PHY);
+
crtc_state->port_clock = icl_ddi_mg_pll_get_freq(dev_priv, NULL,
 &port_dpll->hw_state);
 
-- 
2.35.1



[Intel-gfx] [PATCH v3 10/17] drm/i915: Make all clock checks non-fuzzy

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Now that we backfeed the actual DPLL frequency into the
compute crtc state all our clocks should come out exact.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a2030211439..9bf132707306 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5663,16 +5663,6 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
} \
 } while (0)
 
-#define PIPE_CONF_CHECK_CLOCK_FUZZY(name) do { \
-   if (!intel_fuzzy_clock_check(current_config->name, pipe_config->name)) 
{ \
-   pipe_config_mismatch(fastset, crtc, __stringify(name), \
-"(expected %i, found %i)", \
-current_config->name, \
-pipe_config->name); \
-   ret = false; \
-   } \
-} while (0)
-
 #define PIPE_CONF_CHECK_INFOFRAME(name) do { \
if (!intel_compare_infoframe(¤t_config->infoframes.name, \
 &pipe_config->infoframes.name)) { \
@@ -5791,7 +5781,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_RECT(pch_pfit.dst);
 
PIPE_CONF_CHECK_I(scaler_state.scaler_id);
-   PIPE_CONF_CHECK_CLOCK_FUZZY(pixel_rate);
+   PIPE_CONF_CHECK_I(pixel_rate);
 
PIPE_CONF_CHECK_X(gamma_mode);
if (IS_CHERRYVIEW(dev_priv))
@@ -5861,9 +5851,9 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
if (IS_G4X(dev_priv) || DISPLAY_VER(dev_priv) >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
 
-   PIPE_CONF_CHECK_CLOCK_FUZZY(hw.pipe_mode.crtc_clock);
-   PIPE_CONF_CHECK_CLOCK_FUZZY(hw.adjusted_mode.crtc_clock);
-   PIPE_CONF_CHECK_CLOCK_FUZZY(port_clock);
+   PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
+   PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
+   PIPE_CONF_CHECK_I(port_clock);
 
PIPE_CONF_CHECK_I(min_voltage_level);
 
@@ -5905,7 +5895,6 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
 #undef PIPE_CONF_CHECK_BOOL_INCOMPLETE
 #undef PIPE_CONF_CHECK_P
 #undef PIPE_CONF_CHECK_FLAGS
-#undef PIPE_CONF_CHECK_CLOCK_FUZZY
 #undef PIPE_CONF_CHECK_COLOR_LUT
 #undef PIPE_CONF_CHECK_TIMINGS
 #undef PIPE_CONF_CHECK_RECT
-- 
2.35.1



[Intel-gfx] [PATCH v3 09/17] drm/i915: Make M/N checks non-fuzzy

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Now that we no longer fuzz M/N during fastset these should
match exctly.

In order to get a match with what the BIOS does we need to round
M/N down. And we do the opposite rounding when doing the readback.
That gets us pretty much the same thing back.

There can still be slight rounding differences between FDI M/N
vs. the DPLL output so we allow for tiny deviation in
intel_pipe_config_sanity_check().

v2: Tweak rounding/sanity check stuff a bit

Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 52 ---
 .../drm/i915/display/intel_modeset_verify.c   |  6 +--
 2 files changed, 13 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 7b1fa24bff19..5a2030211439 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4484,7 +4484,8 @@ int intel_dotclock_calculate(int link_freq,
if (!m_n->link_n)
return 0;
 
-   return div_u64(mul_u32_u32(m_n->link_m, link_freq), m_n->link_n);
+   return DIV_ROUND_UP_ULL(mul_u32_u32(m_n->link_m, link_freq),
+   m_n->link_n);
 }
 
 int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
@@ -5376,47 +5377,15 @@ bool intel_fuzzy_clock_check(int clock1, int clock2)
return false;
 }
 
-static bool
-intel_compare_m_n(unsigned int m, unsigned int n,
- unsigned int m2, unsigned int n2,
- bool exact)
-{
-   if (m == m2 && n == n2)
-   return true;
-
-   if (exact || !m || !n || !m2 || !n2)
-   return false;
-
-   BUILD_BUG_ON(DATA_LINK_M_N_MASK > INT_MAX);
-
-   if (n > n2) {
-   while (n > n2) {
-   m2 <<= 1;
-   n2 <<= 1;
-   }
-   } else if (n < n2) {
-   while (n < n2) {
-   m <<= 1;
-   n <<= 1;
-   }
-   }
-
-   if (n != n2)
-   return false;
-
-   return intel_fuzzy_clock_check(m, m2);
-}
-
 static bool
 intel_compare_link_m_n(const struct intel_link_m_n *m_n,
-  const struct intel_link_m_n *m2_n2,
-  bool exact)
+  const struct intel_link_m_n *m2_n2)
 {
return m_n->tu == m2_n2->tu &&
-   intel_compare_m_n(m_n->data_m, m_n->data_n,
- m2_n2->data_m, m2_n2->data_n, exact) &&
-   intel_compare_m_n(m_n->link_m, m_n->link_n,
- m2_n2->link_m, m2_n2->link_n, exact);
+   m_n->data_m == m2_n2->data_m &&
+   m_n->data_n == m2_n2->data_n &&
+   m_n->link_m == m2_n2->link_m &&
+   m_n->link_n == m2_n2->link_n;
 }
 
 static bool
@@ -5610,8 +5579,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
 
 #define PIPE_CONF_CHECK_M_N(name) do { \
if (!intel_compare_link_m_n(¤t_config->name, \
-   &pipe_config->name,\
-   !fastset)) { \
+   &pipe_config->name)) { \
pipe_config_mismatch(fastset, crtc, __stringify(name), \
 "(expected tu %i data %i/%i link %i/%i, " \
 "found tu %i, data %i/%i link %i/%i)", \
@@ -5658,9 +5626,9 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
  */
 #define PIPE_CONF_CHECK_M_N_ALT(name, alt_name) do { \
if (!intel_compare_link_m_n(¤t_config->name, \
-   &pipe_config->name, !fastset) && \
+   &pipe_config->name) && \
!intel_compare_link_m_n(¤t_config->alt_name, \
-   &pipe_config->name, !fastset)) { \
+   &pipe_config->name)) { \
pipe_config_mismatch(fastset, crtc, __stringify(name), \
 "(expected tu %i data %i/%i link %i/%i, " \
 "or tu %i data %i/%i link %i/%i, " \
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c 
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index a91586d77cb6..073607162acc 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -94,10 +94,10 @@ static void intel_pipe_config_sanity_check(struct 
drm_i915_private *dev_priv,
 
/*
 * FDI already provided one idea for the dotclock.
-* Yell if the encoder disagrees.
+* Yell if the encoder disagrees. Allow for slight
+* rounding differences.
 */
-   drm_WARN(&dev_priv->drm,
-  

[Intel-gfx] [PATCH v3 06/17] drm/i915: Reassign DPLLs only for crtcs going throug .compute_config()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.

This should also prevent .get_dplls() from seeing a funky port_clock
for DP even in cases where the readout produces a non-standard
clock and we (for some reason) have decided to not fully recompute
the state to remedy the situation.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 17 +
 drivers/gpu/drm/i915/display/intel_dpll.c|  6 ++
 2 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 25dd47835cfe..e484c7492754 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6055,20 +6055,6 @@ void intel_crtc_update_active_timings(const struct 
intel_crtc_state *crtc_state)
}
 }
 
-static void intel_modeset_clear_plls(struct intel_atomic_state *state)
-{
-   struct intel_crtc_state *new_crtc_state;
-   struct intel_crtc *crtc;
-   int i;
-
-   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
-   if (!intel_crtc_needs_modeset(new_crtc_state))
-   continue;
-
-   intel_release_shared_dplls(state, crtc);
-   }
-}
-
 /*
  * This implements the workaround described in the "notes" section of the mode
  * set sequence documentation. When going from no pipes or single pipe to
@@ -6902,6 +6888,7 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
 
+   intel_release_shared_dplls(state, crtc);
continue;
}
 
@@ -6949,8 +6936,6 @@ static int intel_atomic_check(struct drm_device *dev,
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
-
-   intel_modeset_clear_plls(state);
}
 
ret = intel_atomic_check_crtcs(state);
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 8d095f28fa20..69dc018385db 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1436,11 +1436,9 @@ int intel_dpll_crtc_get_shared_dpll(struct 
intel_atomic_state *state,
int ret;
 
drm_WARN_ON(&i915->drm, !intel_crtc_needs_modeset(crtc_state));
+   drm_WARN_ON(&i915->drm, !crtc_state->hw.enable && 
crtc_state->shared_dpll);
 
-   if (drm_WARN_ON(&i915->drm, crtc_state->shared_dpll))
-   return 0;
-
-   if (!crtc_state->hw.enable)
+   if (!crtc_state->hw.enable || crtc_state->shared_dpll)
return 0;
 
if (!i915->dpll_funcs->crtc_get_shared_dpll)
-- 
2.35.1



[Intel-gfx] [PATCH v3 05/17] drm/i915: Do .crtc_compute_clock() earlier

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.

To allow us to eventually get accurate numbers for all our
DPLL clock derived state we need to move the DPLL calculation
to hapen much earlier. To that end we hoist it up to the just
after the fastset checks. For now we just do the easy code
motion, and the actual back feeding of the final DPLL clock
into the state will come later.

A slight change here is that now .crtc_compute_clock()
can get called while the shared_dpll is still assigned.
But since .crtc_compute_clock() no longer assignes new
shared_dplls this is perfectly fine.

TODO: I'd actually like to do this before the fastset check
so that if the DPLL state should change we actually do the
modeset. Which I think is what the video aficionados want,
but it might not be what the fans of fastboot want. Not yet
sure how to reconcile those conflicting requirements...

v2: s/return/goto/ in error handling

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 +
 drivers/gpu/drm/i915/display/intel_dpll.c| 3 ---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0384af821ee5..25dd47835cfe 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4809,10 +4809,6 @@ static int intel_crtc_atomic_check(struct 
intel_atomic_state *state,
crtc_state->update_wm_post = true;
 
if (mode_changed) {
-   ret = intel_dpll_crtc_compute_clock(state, crtc);
-   if (ret)
-   return ret;
-
ret = intel_dpll_crtc_get_shared_dpll(state, crtc);
if (ret)
return ret;
@@ -6901,6 +6897,11 @@ static int intel_atomic_check(struct drm_device *dev,
new_crtc_state, i) {
if (intel_crtc_needs_modeset(new_crtc_state)) {
any_ms = true;
+
+   ret = intel_dpll_crtc_compute_clock(state, crtc);
+   if (ret)
+   goto fail;
+
continue;
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c 
b/drivers/gpu/drm/i915/display/intel_dpll.c
index 5262f16b45ac..8d095f28fa20 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll.c
@@ -1411,9 +1411,6 @@ int intel_dpll_crtc_compute_clock(struct 
intel_atomic_state *state,
 
drm_WARN_ON(&i915->drm, !intel_crtc_needs_modeset(crtc_state));
 
-   if (drm_WARN_ON(&i915->drm, crtc_state->shared_dpll))
-   return 0;
-
memset(&crtc_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));
 
-- 
2.35.1



[Intel-gfx] [PATCH v3 00/17] drm/i915: Make fastset not suck and allow seamless M/N changes

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

And with fastset made to not suck we can consider allowing
seameless M/N changes on eDP panels that support such things.
I've given that a quick test here on a TGL and it seemed to work
OK.

The rough parts:
- The DPLL stuff is kinda messy still, a lot of which is due to
  the dpll_mgr vs. not depending on platform/output type. Maybe
  it's finally time to start cleaning that mess up...
- the port_dpll[] stuff probably needs to be reworked at some
  point to make a bit more sense
- fastboot I *think* should mostly keep working now that we
  try to match the GOP/VBIOS M/N behaviour. FDI M/N vs. DPLL is
  a bit of a challenge for the platforms where the encoder live
  in the PCH, but I'm going to declare that as not so important
- DSI clock handling is snafu
- DP link computation policy might need a bit more work since we
  may now consume more bandwidth than before on machines where
  seamless M/N changes are possible

I also did a quick smoke test through the series on tgl and
snb in the hopes of keeping this at least mostly bisectable.

Changes in v2:
- bunch of stuff already merged
- a bit more refactoring to make things nicer
- Tweak the M/N rounding for fastboot
- don't mess with the DP link rate on platforms (pre-BDW)
  where we haven't implemented seamsless M/N chages
Changes in v3:
- Attempt to get the VLV/BXT DSI stuff to pass CI :/

Ville Syrjälä (17):
  drm/i915: Relocate intel_crtc_dotclock()
  drm/i915: Shuffle some PLL code around
  drm/i915: Extract HAS_DOUBLE_BUFFERED_M_N()
  drm/i915/dsi: Extract {vlv,bxt}_get_pclk()
  drm/i915: Do .crtc_compute_clock() earlier
  drm/i915: Reassign DPLLs only for crtcs going throug .compute_config()
  drm/i915: Feed the DPLL output freq back into crtc_state
  drm/i915: Compute clocks earlier
  drm/i915: Make M/N checks non-fuzzy
  drm/i915: Make all clock checks non-fuzzy
  drm/i915: Set active dpll early for icl+
  drm/i915: Nuke fastet state copy hacks
  drm/i915: Skip intel_modeset_pipe_config_late() if the pipe is not
enabled
  drm/i915: Add intel_panel_highest_mode()
  drm/i915: Allow M/N change during fastset on bdw+
  drm/i915: Use a fixed N value always
  drm/i915: Round TMDS clock to nearest

 drivers/gpu/drm/i915/display/intel_crt.c  |   3 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |  22 --
 drivers/gpu/drm/i915/display/intel_display.c  | 199 +++--
 drivers/gpu/drm/i915/display/intel_display.h  |   2 +-
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  50 +++--
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |  69 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 204 ++
 drivers/gpu/drm/i915/display/intel_fdi.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |   2 +-
 .../drm/i915/display/intel_modeset_verify.c   |   6 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  15 ++
 drivers/gpu/drm/i915/display/intel_panel.h|   3 +
 .../gpu/drm/i915/display/intel_pch_refclk.c   |  10 +
 .../gpu/drm/i915/display/intel_pch_refclk.h   |   1 +
 drivers/gpu/drm/i915/display/vlv_dsi.c|  11 +-
 drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 141 +++-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 19 files changed, 420 insertions(+), 326 deletions(-)

-- 
2.35.1



[Intel-gfx] [PATCH v3 03/17] drm/i915: Extract HAS_DOUBLE_BUFFERED_M_N()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

We have a couple of places that want to make distinction between
double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
Add a helper for that.

v2: Turn into a HAS_ macro (Jani)

Reviewed-by: Jani Nikula  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 drivers/gpu/drm/i915/display/intel_dp.c  | 3 +--
 drivers/gpu/drm/i915/i915_drv.h  | 2 ++
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6b549aadca13..0384af821ee5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5760,7 +5760,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(lane_count);
PIPE_CONF_CHECK_X(lane_lat_optim_mask);
 
-   if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
+   if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
} else {
PIPE_CONF_CHECK_M_N(dp_m_n);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index e0891b31f089..cf7e4e105891 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1868,8 +1868,7 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct 
intel_dp *intel_dp,
 static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
enum transcoder cpu_transcoder)
 {
-   /* M1/N1 is double buffered */
-   if (DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915))
+   if (HAS_DOUBLE_BUFFERED_M_N(i915))
return true;
 
return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c22f29c3faa0..805ae6ca7486 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1252,6 +1252,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_DP_MST(dev_priv)   (INTEL_INFO(dev_priv)->display.has_dp_mst)
 #define HAS_DP20(dev_priv) (IS_DG2(dev_priv))
 
+#define HAS_DOUBLE_BUFFERED_M_N(dev_priv)  (DISPLAY_VER(dev_priv) >= 9 || 
IS_BROADWELL(dev_priv))
+
 #define HAS_CDCLK_CRAWL(dev_priv)   
(INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
 #define HAS_DDI(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
(INTEL_INFO(dev_priv)->display.has_fpga_dbg)
-- 
2.35.1



[Intel-gfx] [PATCH v3 02/17] drm/i915: Shuffle some PLL code around

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

Shuffle some PLL functions around a bit to avoid ugle
forward declarations later on. No functional changes.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 176 +-
 1 file changed, 88 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index ddae7e42ac46..bfccc96f16fe 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -905,37 +905,6 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
*r2_out = best.r2;
 }
 
-static int
-hsw_ddi_wrpll_compute_dpll(struct intel_atomic_state *state,
-  struct intel_crtc *crtc)
-{
-   struct intel_crtc_state *crtc_state =
-   intel_atomic_get_new_crtc_state(state, crtc);
-   unsigned int p, n2, r2;
-
-   hsw_ddi_calculate_wrpll(crtc_state->port_clock * 1000, &r2, &n2, &p);
-
-   crtc_state->dpll_hw_state.wrpll =
-   WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
-   WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
-   WRPLL_DIVIDER_POST(p);
-
-   return 0;
-}
-
-static struct intel_shared_dpll *
-hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
-  struct intel_crtc *crtc)
-{
-   struct intel_crtc_state *crtc_state =
-   intel_atomic_get_new_crtc_state(state, crtc);
-
-   return intel_find_shared_dpll(state, crtc,
- &crtc_state->dpll_hw_state,
- BIT(DPLL_ID_WRPLL2) |
- BIT(DPLL_ID_WRPLL1));
-}
-
 static int hsw_ddi_wrpll_get_freq(struct drm_i915_private *dev_priv,
  const struct intel_shared_dpll *pll,
  const struct intel_dpll_hw_state *pll_state)
@@ -976,6 +945,37 @@ static int hsw_ddi_wrpll_get_freq(struct drm_i915_private 
*dev_priv,
return (refclk * n / 10) / (p * r) * 2;
 }
 
+static int
+hsw_ddi_wrpll_compute_dpll(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
+{
+   struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   unsigned int p, n2, r2;
+
+   hsw_ddi_calculate_wrpll(crtc_state->port_clock * 1000, &r2, &n2, &p);
+
+   crtc_state->dpll_hw_state.wrpll =
+   WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
+   WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
+   WRPLL_DIVIDER_POST(p);
+
+   return 0;
+}
+
+static struct intel_shared_dpll *
+hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
+{
+   struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+
+   return intel_find_shared_dpll(state, crtc,
+ &crtc_state->dpll_hw_state,
+ BIT(DPLL_ID_WRPLL2) |
+ BIT(DPLL_ID_WRPLL1));
+}
+
 static int
 hsw_ddi_lcpll_compute_dpll(struct intel_crtc_state *crtc_state)
 {
@@ -1618,43 +1618,6 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
return 0;
 }
 
-static int skl_ddi_hdmi_pll_dividers(struct intel_crtc_state *crtc_state)
-{
-   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
-   struct skl_wrpll_params wrpll_params = {};
-   u32 ctrl1, cfgcr1, cfgcr2;
-   int ret;
-
-   /*
-* See comment in intel_dpll_hw_state to understand why we always use 0
-* as the DPLL id in this function.
-*/
-   ctrl1 = DPLL_CTRL1_OVERRIDE(0);
-
-   ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
-
-   ret = skl_ddi_calculate_wrpll(crtc_state->port_clock * 1000,
- i915->dpll.ref_clks.nssc, &wrpll_params);
-   if (ret)
-   return ret;
-
-   cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
-   DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
-   wrpll_params.dco_integer;
-
-   cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
-   DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
-   DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
-   DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
-   wrpll_params.central_freq;
-
-   crtc_state->dpll_hw_state.ctrl1 = ctrl1;
-   crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
-   crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
-
-   return 0;
-}
-
 static int skl_ddi_wrpll_get_freq(struct drm_i915_private *i915,
  const struct intel_shared_dpll *pll,
  const struct intel_dpll_hw_state *pll_state)
@@ -1726,6 +1689,43 @@ static int skl_ddi_wrpll_get_freq(struct 
drm_i915_private *i915,
return dco_fre

[Intel-gfx] [PATCH v3 01/17] drm/i915: Relocate intel_crtc_dotclock()

2022-06-20 Thread Ville Syrjala
From: Ville Syrjälä 

intel_crtc_dotclock() is a bit misplaced. In lieu of a better
place let's just move it next to its friends in intel_display.c.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 22 
 drivers/gpu/drm/i915/display/intel_display.c | 22 
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 272e1bf6006b..51bf26dcb209 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -323,28 +323,6 @@ static int icl_calc_tbt_pll_link(struct drm_i915_private 
*dev_priv,
}
 }
 
-int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
-{
-   int dotclock;
-
-   if (intel_crtc_has_dp_encoder(pipe_config))
-   dotclock = intel_dotclock_calculate(pipe_config->port_clock,
-   &pipe_config->dp_m_n);
-   else if (pipe_config->has_hdmi_sink && pipe_config->pipe_bpp > 24)
-   dotclock = pipe_config->port_clock * 24 / pipe_config->pipe_bpp;
-   else
-   dotclock = pipe_config->port_clock;
-
-   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
-   !intel_crtc_has_dp_encoder(pipe_config))
-   dotclock *= 2;
-
-   if (pipe_config->pixel_multiplier)
-   dotclock /= pipe_config->pixel_multiplier;
-
-   return dotclock;
-}
-
 static void ddi_dotclock_get(struct intel_crtc_state *pipe_config)
 {
/* CRT dotclock is determined via other means */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a626..6b549aadca13 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4483,6 +4483,28 @@ int intel_dotclock_calculate(int link_freq,
return div_u64(mul_u32_u32(m_n->link_m, link_freq), m_n->link_n);
 }
 
+int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
+{
+   int dotclock;
+
+   if (intel_crtc_has_dp_encoder(pipe_config))
+   dotclock = intel_dotclock_calculate(pipe_config->port_clock,
+   &pipe_config->dp_m_n);
+   else if (pipe_config->has_hdmi_sink && pipe_config->pipe_bpp > 24)
+   dotclock = pipe_config->port_clock * 24 / pipe_config->pipe_bpp;
+   else
+   dotclock = pipe_config->port_clock;
+
+   if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
+   !intel_crtc_has_dp_encoder(pipe_config))
+   dotclock *= 2;
+
+   if (pipe_config->pixel_multiplier)
+   dotclock /= pipe_config->pixel_multiplier;
+
+   return dotclock;
+}
+
 /* Returns the currently programmed mode of the given encoder. */
 struct drm_display_mode *
 intel_encoder_current_mode(struct intel_encoder *encoder)
-- 
2.35.1



Re: [Intel-gfx] Performance drop using deinterlace_vaapi on 5.19-rcX

2022-06-20 Thread Daniel Vetter
On Mon, 20 Jun 2022 at 17:28, Christian König  wrote:
>
> Hi Thomas,
>
> Am 20.06.22 um 16:31 schrieb Thomas Voegtle:
> > On Mon, 20 Jun 2022, Christian König wrote:
> >
> >> Am 20.06.22 um 13:40 schrieb Thomas Voegtle:
> >>>  On Mon, 20 Jun 2022, Christian König wrote:
> >>>
>   Hi Thomas,
> 
>   [moving vger to bcc]
> 
>   mhm, sounds like something isn't running in parallel any more.
> 
>   We usually don't test the multimedia engines for this but we do test
>   gfx+compute, so I'm really wondering what goes wrong here.
> 
>   Could you run some tests for me? Additional to that I'm going to
>  raise
>   that issue with our multimedia guys later today.
> >>>
> >>>  Yes, I can run some tests for you. Which tests?
> >>
> >> Try this as root:
> >>
> >> echo 1 >
> >> /sys/kernel/debug/tracing/events/dma_fence/dma_fence_init/enable
> >> echo 1 >
> >> /sys/kernel/debug/tracing/events/dma_fence/dma_fence_signaled/enable
> >> cat /sys/kernel/debug/tracing/trace_pipe > trace.log
> >>
> >> Then start the encoding in another shell, after it completed cancel
> >> the cat with cntr+c and save the log file.
> >>
> >> Do this one with the old kernel and once with the new one.
> >
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F32h.de%2Ftv%2F5.18.0-i5-trace.log.bz2&data=05%7C01%7Cchristian.koenig%40amd.com%7C41a052960a4d4f7dd38e08da52c99097%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637913323382588469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xv8vLUuBq37sBFcGxdua%2FnNQ51BiN1USn30ehP8bys0%3D&reserved=0
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F32h.de%2Ftv%2F5.19.0-rc3-i5-trace.log.bz2&data=05%7C01%7Cchristian.koenig%40amd.com%7C41a052960a4d4f7dd38e08da52c99097%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637913323382588469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xuBVrQMQ%2FDK3Gv1qN%2FntJ9NjXOZxD6XVkmDCWfG4K44%3D&reserved=0
> >
> >
> > I hope I have done this correctly.
> > All necessary tracing things switched on?
>
> Yeah, that looks like what I wanted to see.
>
> >
> > I want to add that this is a headless machine. No monitor connected.
> >
>
> I've just realized that you aren't even using any AMD GPU for
> transcoding, so I have no idea why removing the AMD specific workaround
> can cause a performance problem for i915.
>
> It must be somehow related to i915 now adding some additional
> synchronization in between submissions.
>
> Adding the Intel mailing list, maybe somebody has a better idea.

Only thing I can spot is that we now pile up USAGE_WRITE fences, but
beforehand they got replaced. Also the deinterlace stuff means libva
uses render engine, so this kinda fits - without using the render
engine it's just a single engine, and hence you should never have
multiple write fences (not logically, but hsw is a ringbuffer and i915
doesn't have a ringbuffer scheduler, so it's all in-order anyway and
hence not possible to change something).

This would mean that i915 is doing something silly (well not obeying
the old dma_resv rules that any new exclusive fence must be a strict
superset of all currently attached fences), which it totally is doing
with the EXEC_OBJECT_ASYNC flag. But libva doesn't use that.

So tbh I have no idea, but maybe a quick hack that tosses any old
USAGE_WRITE fence like the old dma_resv_add_excl_fence did would sched
some light?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [Intel-gfx] [PATCH v4] drm/i915/bios: calculate panel type as per child device index in VBT

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, Jani Nikula  wrote:
> On Mon, 20 Jun 2022, Animesh Manna  wrote:
>> Each LFP may have different panel type which is stored in LFP data
>> data block. Based on the child device index respective panel-type/
>> panel-type2 field will be used.
>>
>> v1: Initial rfc verion.
>> v2: Based on review comments from Jani,
>> - Used panel-type instead addition panel-index variable.
>> - DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
>> macro.
>> v3:
>> - passing intel_bios_encoder_data as argument of
>> intel_bios_init_panel(). Passing NULL to indicate encoder is not
>> initialized yet for dsi as current focus is to enable dual EDP. [Jani]
>> v4:
>> - encoder->devdata used which is initialized before from vbt
>> structure. [Jani]
>>
>> Signed-off-by: Animesh Manna 
>
> LGTM, but I'd also like an ack from Ville too as he's been doing a bunch
> of changes around this lately.
>
> Reviewed-by: Jani Nikula 

And pushed to drm-intel-next with Ville's IRC ack.

BR,
Jani.


>
>
>> ---
>>  drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
>>  drivers/gpu/drm/i915/display/intel_bios.c | 16 ++--
>>  drivers/gpu/drm/i915/display/intel_bios.h |  1 +
>>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 ++-
>>  drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
>>  drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
>>  drivers/gpu/drm/i915/display/intel_vbt_defs.h |  4 
>>  drivers/gpu/drm/i915/display/vlv_dsi.c|  2 +-
>>  8 files changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
>> b/drivers/gpu/drm/i915/display/icl_dsi.c
>> index 3b5305c219ba..5dcfa7feffa9 100644
>> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
>> @@ -2050,7 +2050,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
>>  /* attach connector to encoder */
>>  intel_connector_attach_encoder(intel_connector, encoder);
>>  
>> -intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL);
>> +intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL, NULL);
>>  
>>  mutex_lock(&dev->mode_config.mutex);
>>  intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 76e86358adb9..e97f1f979a48 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -604,12 +604,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
>>  }
>>  
>>  static int opregion_get_panel_type(struct drm_i915_private *i915,
>> +   const struct intel_bios_encoder_data 
>> *devdata,
>> const struct edid *edid)
>>  {
>>  return intel_opregion_get_panel_type(i915);
>>  }
>>  
>>  static int vbt_get_panel_type(struct drm_i915_private *i915,
>> +  const struct intel_bios_encoder_data *devdata,
>>const struct edid *edid)
>>  {
>>  const struct bdb_lvds_options *lvds_options;
>> @@ -625,10 +627,16 @@ static int vbt_get_panel_type(struct drm_i915_private 
>> *i915,
>>  return -1;
>>  }
>>  
>> +if (devdata && devdata->child.handle == DEVICE_HANDLE_LFP2)
>> +return lvds_options->panel_type2;
>> +
>> +drm_WARN_ON(&i915->drm, devdata && devdata->child.handle != 
>> DEVICE_HANDLE_LFP1);
>> +
>>  return lvds_options->panel_type;
>>  }
>>  
>>  static int pnpid_get_panel_type(struct drm_i915_private *i915,
>> +const struct intel_bios_encoder_data *devdata,
>>  const struct edid *edid)
>>  {
>>  const struct bdb_lvds_lfp_data *data;
>> @@ -675,6 +683,7 @@ static int pnpid_get_panel_type(struct drm_i915_private 
>> *i915,
>>  }
>>  
>>  static int fallback_get_panel_type(struct drm_i915_private *i915,
>> +   const struct intel_bios_encoder_data 
>> *devdata,
>> const struct edid *edid)
>>  {
>>  return 0;
>> @@ -688,11 +697,13 @@ enum panel_type {
>>  };
>>  
>>  static int get_panel_type(struct drm_i915_private *i915,
>> +  const struct intel_bios_encoder_data *devdata,
>>const struct edid *edid)
>>  {
>>  struct {
>>  const char *name;
>>  int (*get_panel_type)(struct drm_i915_private *i915,
>> +  const struct intel_bios_encoder_data 
>> *devdata,
>>const struct edid *edid);
>>  int panel_type;
>>  } panel_types[] = {
>> @@ -716,7 +727,7 @@ static int get_panel_type(struct drm_i915_private *i915,
>>  int i;
>>  
>>  for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
>> -panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
>> edid);
>> +panel_types[i].panel_type = p

Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Extract has_double_buffered_m_n()

2022-06-20 Thread Ville Syrjälä
On Mon, Jun 20, 2022 at 12:05:42PM +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2022, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > We have a couple of places that want to make distinction between
> > double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> > Add a helper for that.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> Mhh. So why a function in intel_display.c instead of a macro in
> i915_drv.h? Both are kind of cluttered, but at least in i915_drv.h it
> would be among others.

Doesn't feel quite right to me to put low level details like this
into the i915 feature stuff. I'd rather keep it next to the
implementation so I have all the relevant details in one place.

For higher level stuff and features named in bspec the HAS_FOO()
stuff feels more appropriate to me.

But maybe that's just me.

> 
> I do think we should have a separate file for display feature check
> macros, and move most if not all of the display related HAS_*() stuff
> there from i915_drv.h.
> 
> So technically this does what it says on the box, and in that sense,
> 
> Reviewed-by: Jani Nikula 
> 
> but I don't much like the example and precedence this function sets.
> 
> 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
> >  drivers/gpu/drm/i915/display/intel_display.h | 1 +
> >  drivers/gpu/drm/i915/display/intel_dp.c  | 3 +--
> >  3 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index b24784c4522d..5559688047b3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2798,6 +2798,11 @@ static int intel_crtc_compute_config(struct 
> > intel_atomic_state *state,
> > return 0;
> >  }
> >  
> > +bool has_double_buffered_m_n(struct drm_i915_private *i915)
> > +{
> > +   return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915);
> > +}
> > +
> >  static void
> >  intel_reduce_m_n_ratio(u32 *num, u32 *den)
> >  {
> > @@ -5900,7 +5905,7 @@ intel_pipe_config_compare(const struct 
> > intel_crtc_state *current_config,
> > PIPE_CONF_CHECK_I(lane_count);
> > PIPE_CONF_CHECK_X(lane_lat_optim_mask);
> >  
> > -   if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
> > +   if (has_double_buffered_m_n(dev_priv)) {
> > PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
> > } else {
> > PIPE_CONF_CHECK_M_N(dp_m_n);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> > b/drivers/gpu/drm/i915/display/intel_display.h
> > index 2feb8ae5d5d4..44c88aadfc30 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > @@ -543,6 +543,7 @@ int intel_atomic_add_affected_planes(struct 
> > intel_atomic_state *state,
> >  struct intel_crtc *crtc);
> >  u8 intel_calc_active_pipes(struct intel_atomic_state *state,
> >u8 active_pipes);
> > +bool has_double_buffered_m_n(struct drm_i915_private *i915);
> >  void intel_link_compute_m_n(u16 bpp, int nlanes,
> > int pixel_clock, int link_clock,
> > struct intel_link_m_n *m_n,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2fac76bcf06d..75645508080a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1842,8 +1842,7 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct 
> > intel_dp *intel_dp,
> >  static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
> > enum transcoder cpu_transcoder)
> >  {
> > -   /* M1/N1 is double buffered */
> > -   if (DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915))
> > +   if (has_double_buffered_m_n(i915))
> > return true;
> >  
> > return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: split out hw state readout and sanitize

2022-06-20 Thread Jani Nikula
On Fri, 17 Jun 2022, Jani Nikula  wrote:
> Split out the modeset hardware state readout and sanitize, or state
> setup, to a separate file.
>
> Do some drive-by checkpatch fixes while at it.
>
> v2: Rebase
>
> Signed-off-by: Jani Nikula 
> Reviewed-by: Ville Syrjälä  # v1

Both patches pushed to drm-intel-next, thanks for the review.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c  | 739 +-
>  drivers/gpu/drm/i915/display/intel_display.h  |  12 +
>  .../drm/i915/display/intel_modeset_setup.c| 736 +
>  .../drm/i915/display/intel_modeset_setup.h|  15 +
>  5 files changed, 778 insertions(+), 725 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_setup.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_modeset_setup.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 37a8ea56f7d6..c84a9cd8440d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -244,6 +244,7 @@ i915-y += \
>   display/intel_hotplug.o \
>   display/intel_lpe_audio.o \
>   display/intel_modeset_verify.o \
> + display/intel_modeset_setup.o \
>   display/intel_overlay.o \
>   display/intel_pch_display.o \
>   display/intel_pch_refclk.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 90bd26431e31..710a51f14649 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -101,6 +101,7 @@
>  #include "intel_hdcp.h"
>  #include "intel_hotplug.h"
>  #include "intel_modeset_verify.h"
> +#include "intel_modeset_setup.h"
>  #include "intel_overlay.h"
>  #include "intel_panel.h"
>  #include "intel_pch_display.h"
> @@ -130,8 +131,6 @@ static void ilk_set_pipeconf(const struct 
> intel_crtc_state *crtc_state);
>  static void hsw_set_transconf(const struct intel_crtc_state *crtc_state);
>  static void bdw_set_pipemisc(const struct intel_crtc_state *crtc_state);
>  static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state);
> -static void intel_modeset_setup_hw_state(struct drm_device *dev,
> -  struct drm_modeset_acquire_ctx *ctx);
>  
>  /**
>   * intel_update_watermarks - update FIFO watermark values based on current 
> modes
> @@ -166,7 +165,7 @@ static void intel_modeset_setup_hw_state(struct 
> drm_device *dev,
>   * We don't use the sprite, so we can ignore that.  And on Crestline we have
>   * to set the non-SR watermarks to 8.
>   */
> -static void intel_update_watermarks(struct drm_i915_private *dev_priv)
> +void intel_update_watermarks(struct drm_i915_private *dev_priv)
>  {
>   if (dev_priv->wm_disp->update_wm)
>   dev_priv->wm_disp->update_wm(dev_priv);
> @@ -733,10 +732,9 @@ u32 intel_plane_fb_max_stride(struct drm_i915_private 
> *dev_priv,
>DRM_MODE_ROTATE_0);
>  }
>  
> -static void
> -intel_set_plane_visible(struct intel_crtc_state *crtc_state,
> - struct intel_plane_state *plane_state,
> - bool visible)
> +void intel_set_plane_visible(struct intel_crtc_state *crtc_state,
> +  struct intel_plane_state *plane_state,
> +  bool visible)
>  {
>   struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
>  
> @@ -748,7 +746,7 @@ intel_set_plane_visible(struct intel_crtc_state 
> *crtc_state,
>   crtc_state->uapi.plane_mask &= ~drm_plane_mask(&plane->base);
>  }
>  
> -static void fixup_plane_bitmasks(struct intel_crtc_state *crtc_state)
> +void intel_plane_fixup_bitmasks(struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
>   struct drm_plane *plane;
> @@ -783,7 +781,7 @@ void intel_plane_disable_noatomic(struct intel_crtc *crtc,
>   crtc->base.base.id, crtc->base.name);
>  
>   intel_set_plane_visible(crtc_state, plane_state, false);
> - fixup_plane_bitmasks(crtc_state);
> + intel_plane_fixup_bitmasks(crtc_state);
>   crtc_state->data_rate[plane->id] = 0;
>   crtc_state->data_rate_y[plane->id] = 0;
>   crtc_state->rel_data_rate[plane->id] = 0;
> @@ -2209,9 +2207,8 @@ static void get_crtc_power_domains(struct 
> intel_crtc_state *crtc_state,
>   set_bit(intel_dsc_power_domain(crtc, cpu_transcoder), 
> mask->bits);
>  }
>  
> -static void
> -modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state,
> -struct intel_power_domain_mask *old_domains)
> +void intel_modeset_get_crtc_power_domains(struct intel_crtc_state 
> *crtc_state,
> +   struct intel_power_domain_mask 
> *old_domains)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struc

Re: [Intel-gfx] [PATCH v2 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-20 Thread Niranjana Vishwanathapura

On Mon, Jun 20, 2022 at 11:43:10AM +0100, Tvrtko Ursulin wrote:


Hi,

On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:

VM_BIND design document with description of intended use cases.

v2: Reduce the scope to simple Mesa use case.


since I expressed interest please add me to cc when sending out.



Hi Tvrtko,
I did include you in the cc list with git send-email, but looks like some 
patches
in this series has the full cc list, but some don't (you are on cc list of this
patch though). I am not sure why.

How come the direction changed to simplify all of a sudden? I did not 
spot any discussion to that effect. Was it internal talks?




Yah, some of us had offline discussion involving the Mesa team.
I did update the thread (previous version of this patch series) about that.
Plan was to align our roadmap to focus on the deliverables at this point
without further complicating the uapi. 



Signed-off-by: Niranjana Vishwanathapura 
---
 Documentation/gpu/rfc/i915_vm_bind.rst | 238 +
 Documentation/gpu/rfc/index.rst|   4 +
 2 files changed, 242 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
new file mode 100644
index ..4ab590ef11fd
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -0,0 +1,238 @@
+==
+I915 VM_BIND feature design and use cases
+==
+
+VM_BIND feature
+
+DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+specified address space (VM). These mappings (also referred to as persistent
+mappings) will be persistent across multiple GPU submissions (execbuf calls)
+issued by the UMD, without user having to provide a list of all required
+mappings during each submission (as required by older execbuf mode).
+
+The VM_BIND/UNBIND calls allow UMDs to request a timeline fence for signaling
+the completion of bind/unbind operation.
+
+VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.
+User has to opt-in for VM_BIND mode of binding for an address space (VM)
+during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+
+Normally, vm_bind/unbind operations will get completed synchronously,


To me synchronously, at this point in the text, reads as ioctl will 
return only when the operation is done. Rest of the paragraph however 
disagrees (plus existence of out fence). It is not clear to me what is 
the actual behaviour. Will it be clear to userspace developers reading 
uapi kerneldoc? If it is async, what are the ordering rules in this 
version?




Yah, here I am simply stating the i915_vma_pin_ww() behavior which mostly
does the binding synchronously unless there is a moving fence associated
with the object in which case, binding will complete later once that fence
is signaled (hence the out fence).


+but if the object is being moved, the binding will happen once that the
+moving is complete and out fence will be signaled after binding is complete.
+The bind/unbind operation can get completed out of submission order.
+
+VM_BIND features include:
+
+* Multiple Virtual Address (VA) mappings can map to the same physical pages
+  of an object (aliasing).
+* VA mapping can map to a partial section of the BO (partial binding).
+* Support capture of persistent mappings in the dump upon GPU error.
+* TLB is flushed upon unbind completion. Batching of TLB flushes in some
+  use cases will be helpful.
+* Support for userptr gem objects (no special uapi is required for this).
+
+Execbuf ioctl in VM_BIND mode
+---
+A VM in VM_BIND mode will not support older execbuf mode of binding.
+The execbuf ioctl handling in VM_BIND mode differs significantly from the
+older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+execlist. Hence, no support for implicit sync. It is expected that the below
+work will be able to support requirements of object dependency setting in all
+use cases:
+
+"dma-buf: Add an API for exporting sync files"
+(https://lwn.net/Articles/859290/)


What does this mean? If execbuf3 does not know about target objects 
how can we add a meaningful fence?




Execbuf3 does know about the target objects. It is all the objects
bound to that VM via vm_bind call.


+
+The execbuf3 ioctl directly specifies the batch addresses instead of as
+object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+support many of the older features like in/out/submit fences, fence array,
+default gem context and many more (See struct drm_i915_gem_execbuffer3).
+
+In VM_BIND mode, VA allocation is completely managed by the user instead of
+the i9

Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, "Jason A. Donenfeld"  wrote:
> Hi Jani,
>
> On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote:
>> On Mon, 20 Jun 2022, "Jason A. Donenfeld"  wrote:
>> > Hi Jani,
>> >
>> > Do you plan to merge this revert?
>> 
>> Yes, I've done that now, thanks for the bisection and the patch.
>
> Thanks!
>
> I see that this went into `drm-intel-next`, but shouldn't it go into
> `drm-intel-fixes`, so that it makes it into 5.19-rc4?

All of our commits go to drm-intel-next first. I'll pick it up for fixes
later.

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate

2022-06-20 Thread Jason A. Donenfeld
Hi Jani,

On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote:
> On Mon, 20 Jun 2022, "Jason A. Donenfeld"  wrote:
> > Hi Jani,
> >
> > Do you plan to merge this revert?
> 
> Yes, I've done that now, thanks for the bisection and the patch.

Thanks!

I see that this went into `drm-intel-next`, but shouldn't it go into
`drm-intel-fixes`, so that it makes it into 5.19-rc4?

Jason


Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, "Jason A. Donenfeld"  wrote:
> Hi Jani,
>
> Do you plan to merge this revert?

Yes, I've done that now, thanks for the bisection and the patch.

Ankit, Imre, we need to figure out what to do with [1] now.

BR,
Jani.


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



-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction

2022-06-20 Thread Andrzej Hajda

On 20.06.2022 14:36, Thomas Hellström wrote:

In vma destruction, the following race may occur:

Thread 1: Thread 2:
i915_vma_destroy();

   ...
   list_del_init(vma->vm_link);
   ...
   mutex_unlock(vma->vm->mutex);
  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura 
Cc: Matthew Auld 
Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/i915_vma.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
  }
  
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)

+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+  bool vm_ddestroy)
  {
struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_gt *gt = vma->vm->gt;
  
  	GEM_BUG_ON(i915_vma_is_active(vma));
  
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
  
  	force_unbind(vma);

list_del_init(&vma->vm_link);
-   release_references(vma, false);
+   release_references(vma, vma->vm->gt, false);
  }
  
  void i915_vma_destroy(struct i915_vma *vma)

  {
+   struct intel_gt *gt;
bool vm_ddestroy;
  
  	mutex_lock(&vma->vm->mutex);

@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
mutex_unlock(&vma->vm->mutex);
-   release_references(vma, vm_ddestroy);
+   release_references(vma, gt, vm_ddestroy);



Reviewed-by: Andrzej Hajda 

Regards
Andrzej



  }
  
  void i915_vma_parked(struct intel_gt *gt)




Re: [Intel-gfx] [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-20 Thread Niranjana Vishwanathapura

On Mon, Jun 20, 2022 at 07:42:25AM -0700, Zeng, Oak wrote:



Thanks,
Oak


-Original Message-
From: Vishwanathapura, Niranjana 
Sent: June 17, 2022 1:15 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter,
Daniel 
Cc: Hellstrom, Thomas ; Wilson, Chris P
; ja...@jlekstrand.net;
christian.koe...@amd.com; Brost, Matthew ;
Ursulin, Tvrtko ; Auld, Matthew
; Landwerlin, Lionel G
; Zanoni, Paulo R
; Zeng, Oak 
Subject: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition

VM_BIND and related uapi definitions

v2: Reduce the scope to simple Mesa use case.

Signed-off-by: Niranjana Vishwanathapura

---
 Documentation/gpu/rfc/i915_vm_bind.h | 226
+++
 1 file changed, 226 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h

diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..b7540ddb526d
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,226 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND   57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept
any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND   0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
  DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND,
struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+  * @value: A point in the timeline.
+  * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+  * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+  * binary one.
+  */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of
GPU
+ * virtual address (VA) range to the section of an object that should be
bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned. However
the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact
page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+  * @flags: Supported flags are:
+  *
+  * I915_GEM_VM_BIND_READONLY:
+  * Mapping is read-only.
+  *
+  * I915_GEM_VM_BIND_CAPTURE:
+  * Capture this mapping in the dump upon GPU error.
+  */
+ __u64 flags;
+#define I915_GEM_VM_BIND_READONLY(1 << 0)


Should we define another flag for DEVICE_ATOMIC? Without this flag, do you 
imply all the mapping support device atomic operation?
HW platform also has an implication to device atomic, i.e., some platform don't 
support device atomics to system memory.



Thanks Oak, we can always add required flags later when we want to add the 
support.

Niranjana


Regards,
Oak


+#define I915_GEM_VM_BIND_CAPTURE (1 << 1)
+
+ /** @fence: Ti

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vm use-after-free in vma destruction (rev2)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix vm use-after-free in vma destruction (rev2)
URL   : https://patchwork.freedesktop.org/series/103922/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11780 -> Patchwork_103922v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 42)
--

  Additional (2): fi-kbl-soraka bat-dg2-8 
  Missing(2): bat-jsl-2 bat-dg2-9 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([i915#6253])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-guc/igt@debugfs_test@read_all_entries.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][6] -> [DMESG-FAIL][7] ([i915#4494] / 
[i915#4957])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][8] -> [DMESG-FAIL][9] ([i915#4528])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-pnv-d510/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][10] ([i915#4817])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][11] -> [DMESG-WARN][12] ([i915#3576])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][15] ([fdo#109271]) +9 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][16] -> [DMESG-WARN][17] ([i915#402]) +2 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][18] ([fdo#109271]) +47 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-bdw-gvtdvm/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103922v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
 Possible fixes 

  * igt@i915_module_load@load:
- {bat-jsl-1}:[SKIP][20] ([i915#6227]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-jsl-1/igt@i915_module_l...@load.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Pa

Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

2022-06-20 Thread Rob Clark
()

On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
 wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker drivers should:
>
> 1. Implement new evict() shmem object callback.
> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
>activate shrinking of shmem GEMs.
>
> This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
>
> Signed-off-by: Daniel Almeida 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
>  .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   9 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h  |   3 +
>  include/drm/drm_device.h  |   4 +
>  include/drm/drm_gem_shmem_helper.h|  87 ++-
>  5 files changed, 594 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 555fe212bd98..4cd0b5913492 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -126,6 +126,42 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
> drm_device *dev, size_t
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> +{
> +   return (shmem->madv >= 0) && shmem->evict &&
> +   shmem->eviction_enabled && shmem->pages_use_count &&
> +   !shmem->pages_pin_count && !shmem->base.dma_buf &&
> +   !shmem->base.import_attach && shmem->sgt && !shmem->evicted;
> +}
> +
> +static void
> +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> +{
> +   struct drm_gem_object *obj = &shmem->base;
> +   struct drm_gem_shmem_shrinker *gem_shrinker = 
> obj->dev->shmem_shrinker;
> +
> +   dma_resv_assert_held(shmem->base.resv);
> +
> +   if (!gem_shrinker || obj->import_attach)
> +   return;
> +
> +   mutex_lock(&gem_shrinker->lock);
> +
> +   if (drm_gem_shmem_is_evictable(shmem) ||
> +   drm_gem_shmem_is_purgeable(shmem))
> +   list_move_tail(&shmem->madv_list, 
> &gem_shrinker->lru_evictable);
> +   else if (shmem->madv < 0)
> +   list_del_init(&shmem->madv_list);
> +   else if (shmem->evicted)
> +   list_move_tail(&shmem->madv_list, &gem_shrinker->lru_evicted);
> +   else if (!shmem->pages)
> +   list_del_init(&shmem->madv_list);
> +   else
> +   list_move_tail(&shmem->madv_list, &gem_shrinker->lru_pinned);
> +
> +   mutex_unlock(&gem_shrinker->lock);
> +}
> +
>  /**
>   * drm_gem_shmem_free - Free resources associated with a shmem GEM object
>   * @shmem: shmem GEM object to free
> @@ -142,6 +178,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
> *shmem)
> } else {
> dma_resv_lock(shmem->base.resv, NULL);
>
> +   /* take out shmem GEM object from the memory shrinker */
> +   drm_gem_shmem_madvise(shmem, -1);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (shmem->sgt) {
> @@ -150,7 +189,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
> *shmem)
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> -   if (shmem->pages)
> +   if (shmem->pages_use_count)
> drm_gem_shmem_put_pages(shmem);
>
> WARN_ON(shmem->pages_use_count);
> @@ -163,18 +202,82 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object 
> *shmem)
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> -static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +/**
> + * drm_gem_shmem_set_evictable() - Make GEM evictable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be evicted. Initially eviction is
> + * disabled for all GEMs. If GEM was purged, then -ENOMEM is returned.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem)
> +{
> +   dma_resv_lock(shmem->base.resv, NULL);
> +
> +   if (shmem->madv < 0)
> +   return -ENOMEM;
> +
> +   shmem->eviction_enabled = true;
> +
> +   dma_resv_unlock(shmem->base.resv);
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_set_evictable);
> +
> +/**
> + * drm_gem_shmem_set_purgeable() - Make GEM purgeable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be purged. Initially purging is
> + * disabled for al

Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker

2022-06-20 Thread Rob Clark
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
 wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_control *sc)
> >> +{
> >> +   struct drm_gem_shmem_shrinker *gem_shrinker = 
> >> to_drm_shrinker(shrinker);
> >> +   struct drm_gem_shmem_object *shmem;
> >> +   unsigned long count = 0;
> >> +
> >> +   if (!mutex_trylock(&gem_shrinker->lock))
> >> +   return 0;
> >> +
> >> +   list_for_each_entry(shmem, &gem_shrinker->lru_evictable, 
> >> madv_list) {
> >> +   count += shmem->base.size;
> >> +
> >> +   if (count >= SHRINK_EMPTY)
> >> +   break;
> >> +   }
> >> +
> >> +   mutex_unlock(&gem_shrinker->lock);
> >
> > As I mentioned on other thread, count_objects, being approximate but
> > lockless and fast is the important thing.  Otherwise when you start
> > hitting the shrinker on many threads, you end up serializing them all,
> > even if you have no pages to return to the system at that point.
>
> Daniel's point for dropping the lockless variant was that we're already
> in trouble if we're hitting shrinker too often and extra optimizations
> won't bring much benefits to us.

At least with zram swap (which I highly recommend using even if you
are not using a physical swap file/partition), swapin/out is actually
quite fast.  And if you are leaning on zram swap to fit 8GB of chrome
browser on a 4GB device, the shrinker gets hit quite a lot.  Lower
spec (4GB RAM) chromebooks can be under constant memory pressure and
can quite easily get into a situation where you are hitting the
shrinker on many threads simultaneously.  So it is pretty important
for all shrinkers in the system (not just drm driver) to be as
concurrent as possible.  As long as you avoid serializing reclaim on
all the threads, performance can still be quite good, but if you don't
performance will fall off a cliff.

jfwiw, we are seeing pretty good results (iirc 40-70% increase in open
tab counts) with the combination of eviction + multigen LRU[1] +
sizing zram swap to be 2x physical RAM

[1] https://lwn.net/Articles/856931/

> Alright, I'll add back the lockless variant (or will use yours
> drm_gem_lru) in the next revision. The code difference is very small
> after all.
>
> ...
> >> +   /* prevent racing with the dma-buf importing/exporting */
> >> +   if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> >> +   *lock_contention |= true;
> >> +   goto resv_unlock;
> >> +   }
> >
> > I'm not sure this is a good idea to serialize on object_name_lock.
> > Purgeable buffers should never be shared (imported or exported).  So
> > at best you are avoiding evicting and immediately swapping back in, in
> > a rare case, at the cost of serializing multiple threads trying to
> > reclaim pages in parallel.
>
> The object_name_lock shouldn't cause contention in practice. But objects
> are also pinned on attachment, hence maybe this lock is indeed
> unnecessary.. I'll re-check it.

I'm not worried about contention with export/import/etc, but
contention between multiple threads hitting the shrinker in parallel.
I guess since you are using trylock, it won't *block* the other
threads hitting shrinker, but they'll just end up looping in
do_shrink_slab() because they are hitting contention.

I'd have to do some experiments to see how it works out in practice,
but my gut feel is that it isn't a good idea

BR,
-R

> --
> Best regards,
> Dmitry


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: add payload receiving code (rev5)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: add payload receiving code (rev5)
URL   : https://patchwork.freedesktop.org/series/105096/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11780 -> Patchwork_105096v5


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 42)
--

  Additional (2): fi-kbl-soraka bat-dg2-8 
  Missing(2): bat-jsl-2 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][3] ([i915#1886])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6:  [PASS][6] -> [DMESG-FAIL][7] ([i915#4494] / 
[i915#4957])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][8] -> [DMESG-FAIL][9] ([i915#4528])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-pnv-d510/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][10] ([i915#4817])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][11] -> [DMESG-WARN][12] ([i915#3576]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-adlp-4/igt@kms_busy@ba...@flip.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/bat-adlp-4/igt@kms_busy@ba...@flip.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][17] ([fdo#109271]) +9 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][18] -> [DMESG-WARN][19] ([i915#402]) +2 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][20] ([fdo#109271]) +47 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v5/fi-bdw-gvtdvm/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka:  NOTRUN -> [SKIP][21] ([fdo#109271] / [

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: stop modifying "const" device info

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: stop modifying "const" device info
URL   : https://patchwork.freedesktop.org/series/105358/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11780 -> Patchwork_105358v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (42 -> 42)
--

  Additional (2): fi-kbl-soraka bat-dg2-8 
  Missing(2): bat-jsl-2 fi-icl-u2 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][3] -> [INCOMPLETE][4] ([i915#2940])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u:   [PASS][5] -> [INCOMPLETE][6] ([i915#5502])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_engines:
- bat-dg1-6:  [PASS][7] -> [INCOMPLETE][8] ([i915#4418])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][9] ([i915#1886])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick:[PASS][10] -> [DMESG-FAIL][11] ([i915#3428])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html

  * igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][12] -> [DMESG-FAIL][13] ([i915#4528])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-pnv-d510/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm:  NOTRUN -> [INCOMPLETE][14] ([i915#4817])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-g3258:   NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-hsw-g3258/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-bdw-gvtdvm:  NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-bdw-gvtdvm/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-soraka:  NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +7 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][19] ([fdo#109271]) +9 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2:  [PASS][20] -> [DMESG-WARN][21] ([i915#402]) +2 
similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11780/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105358v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html

  * igt@kms_

Re: [Intel-gfx] [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition

2022-06-20 Thread Zeng, Oak


Thanks,
Oak

> -Original Message-
> From: Vishwanathapura, Niranjana 
> Sent: June 17, 2022 1:15 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter,
> Daniel 
> Cc: Hellstrom, Thomas ; Wilson, Chris P
> ; ja...@jlekstrand.net;
> christian.koe...@amd.com; Brost, Matthew ;
> Ursulin, Tvrtko ; Auld, Matthew
> ; Landwerlin, Lionel G
> ; Zanoni, Paulo R
> ; Zeng, Oak 
> Subject: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
> 
> VM_BIND and related uapi definitions
> 
> v2: Reduce the scope to simple Mesa use case.
> 
> Signed-off-by: Niranjana Vishwanathapura
> 
> ---
>  Documentation/gpu/rfc/i915_vm_bind.h | 226
> +++
>  1 file changed, 226 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
> 
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> b/Documentation/gpu/rfc/i915_vm_bind.h
> new file mode 100644
> index ..b7540ddb526d
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,226 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_HAS_VM_BIND
> + *
> + * VM_BIND feature availability.
> + * See typedef drm_i915_getparam_t param.
> + */
> +#define I915_PARAM_HAS_VM_BIND   57
> +
> +/**
> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> + *
> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> + * See struct drm_i915_gem_vm_control flags.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept
> any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + *
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND 0x3d
> +#define DRM_I915_GEM_VM_UNBIND   0x3e
> +#define DRM_I915_GEM_EXECBUFFER3 0x3f
> +
> +#define DRM_IOCTL_I915_GEM_VM_BIND
>   DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND,
> struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_VM_UNBIND
>   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_EXECBUFFER3
>   DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
> notification.
> + *
> + * A timeline out fence for vm_bind/unbind completion notification.
> + */
> +struct drm_i915_gem_vm_bind_fence {
> + /** @handle: User's handle for a drm_syncobj to signal. */
> + __u32 handle;
> +
> + /** @rsvd: Reserved, MBZ */
> + __u32 rsvd;
> +
> + /**
> +  * @value: A point in the timeline.
> +  * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
> +  * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
> +  * binary one.
> +  */
> + __u64 value;
> +};
> +
> +/**
> + * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
> + *
> + * This structure is passed to VM_BIND ioctl and specifies the mapping of
> GPU
> + * virtual address (VA) range to the section of an object that should be
> bound
> + * in the device page table of the specified address space (VM).
> + * The VA range specified must be unique (ie., not currently bound) and can
> + * be mapped to whole object or a section of the object (partial binding).
> + * Multiple VA mappings can be created to the same section of the object
> + * (aliasing).
> + *
> + * The @start, @offset and @length should be 4K page aligned. However
> the DG2
> + * and XEHPSDV has 64K page size for device local-memory and has compact
> page
> + * table. On those platforms, for binding device local-memory objects, the
> + * @start should be 2M aligned, @offset and @length should be 64K aligned.
> + * Also, on those platforms, it is not allowed to bind an device local-memory
> + * object and a system memory object in a single 2M section of VA range.
> + */
> +struct drm_i915_gem_vm_bind {
> + /** @vm_id: VM (address space) id to bind */
> + __u32 vm_id;
> +
> + /** @handle: Object handle */
> + __u32 handle;
> +
> + /** @start: Virtual Address start to bind */
> + __u64 start;
> +
> + /** @offset: Offset in object to bind */
> + __u64 offset;
> +
> + /** @length: Length of mapping to bind */
> + __u64 length;
> +
> + /**
> +  * @flags: Supported flags are:
> +  *
> +  * I915_GEM_VM_BIND_READONLY:
> +  * Mapping is read-only.
> +  *
> +  * I915_GEM_VM_BIND_CAPTURE:
> +  * Capture this mapping in the dump upon GPU error.
> +  */
> + __u64 flags;
> +#define I915_GEM_VM_BIND_READONLY(1 << 0)

Should we define another flag for DEVICE_ATOMIC? Without this flag, do you 
imply all the mapping support device atomic operation? 
HW platform also has an implication to device atomic, i.e., some platform don

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: stop modifying "const" device info

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915: stop modifying "const" device info
URL   : https://patchwork.freedesktop.org/series/105358/
State : warning

== Summary ==

Error: dim checkpatch failed
0c57ec003486 drm/i915: use GRAPHICS_VER() instead of accessing match_info 
directly
596a710de9af drm/i915: combine device info printing into one
27dda2c69a5b drm/i915: add initial runtime info into device info
-:50: WARNING:REPEATED_WORD: Possible repeated word: 'into'
#50: FILE: drivers/gpu/drm/i915/intel_device_info.h:203:
+* Platform mask is used for optimizing or-ed IS_PLATFORM calls into
+* into single runtime conditionals, and also to provide groundwork

total: 0 errors, 1 warnings, 0 checks, 75 lines checked
f2624b41fbe2 drm/i915: move fbc_mask to runtime info
efa469b40f22 drm/i915: move page_sizes to runtime info
340a168b80a7 drm/i915: move ppgtt_type and ppgtt_size to runtime info
f709762facd3 drm/i915: move has_pooled_eu to runtime info
991edfbbdf6d drm/i915: move memory_regions to runtime info
6f6f368ead3b drm/i915: move platform_engine_mask to runtime info
e72012a41c6b drm/i915: move graphics.ver and graphics.rel to runtime info
-:25: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#25: FILE: drivers/gpu/drm/i915/i915_drv.h:860:
+#define GRAPHICS_VER_FULL(i915)
IP_VER(RUNTIME_INFO(i915)->graphics.ver, \
+  RUNTIME_INFO(i915)->graphics.rel)

total: 0 errors, 0 warnings, 1 checks, 92 lines checked
6b83e911add8 drm/i915: move pipe_mask and cpu_transcoder_mask to runtime info
-:29: WARNING:SPACING: space prohibited between function name and open 
parenthesis '('
#29: FILE: drivers/gpu/drm/i915/display/intel_display.h:385:
+   for_each_if (RUNTIME_INFO(__dev_priv)->cpu_transcoder_mask & 
BIT(__t))

-:42: WARNING:LONG_LINE: line length of 106 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/i915_drv.h:1262:
+#define HAS_TRANSCODER(dev_priv, trans) 
((RUNTIME_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)

-:135: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#135: FILE: drivers/gpu/drm/i915/i915_pci.c:461:
+   .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) 
| BIT(TRANSCODER_C), \

total: 0 errors, 3 warnings, 0 checks, 285 lines checked
da3bd5bf69ed drm/i915: move has_hdcp to runtime info
ad747f8e7763 drm/i915: move has_dmc to runtime info
fb508a532365 drm/i915: move has_dsc to runtime info
69828fb97c44 drm/i915: stop resetting display info to zero for no display
66cd29e28b96 drm/i915: make device info a pointer to static const data
-:58: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '__i915' may be better as 
'(__i915)' to avoid precedence issues
#58: FILE: drivers/gpu/drm/i915/i915_drv.h:851:
+#define INTEL_INFO(__i915) (__i915->__info)

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




Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction

2022-06-20 Thread Das, Nirmoy

Acked-by: Nirmoy Das 

On 6/20/2022 2:36 PM, Thomas Hellström wrote:

In vma destruction, the following race may occur:

Thread 1: Thread 2:
i915_vma_destroy();

   ...
   list_del_init(vma->vm_link);
   ...
   mutex_unlock(vma->vm->mutex);
  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura 
Cc: Matthew Auld 
Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/i915_vma.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
  }
  
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)

+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+  bool vm_ddestroy)
  {
struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_gt *gt = vma->vm->gt;
  
  	GEM_BUG_ON(i915_vma_is_active(vma));
  
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
  
  	force_unbind(vma);

list_del_init(&vma->vm_link);
-   release_references(vma, false);
+   release_references(vma, vma->vm->gt, false);
  }
  
  void i915_vma_destroy(struct i915_vma *vma)

  {
+   struct intel_gt *gt;
bool vm_ddestroy;
  
  	mutex_lock(&vma->vm->mutex);

@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
mutex_unlock(&vma->vm->mutex);
-   release_references(vma, vm_ddestroy);
+   release_references(vma, gt, vm_ddestroy);
  }
  
  void i915_vma_parked(struct intel_gt *gt)


[Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction

2022-06-20 Thread Thomas Hellström
In vma destruction, the following race may occur:

Thread 1: Thread 2:
i915_vma_destroy();

  ...
  list_del_init(vma->vm_link);
  ...
  mutex_unlock(vma->vm->mutex);
  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.

However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().

v2: Fix a typo in the commit message (Andi Shyti)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")

Cc: Niranjana Vishwanathapura 
Cc: Matthew Auld 
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/i915_vma.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
 }
 
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)
+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+  bool vm_ddestroy)
 {
struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_gt *gt = vma->vm->gt;
 
GEM_BUG_ON(i915_vma_is_active(vma));
 
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
 
force_unbind(vma);
list_del_init(&vma->vm_link);
-   release_references(vma, false);
+   release_references(vma, vma->vm->gt, false);
 }
 
 void i915_vma_destroy(struct i915_vma *vma)
 {
+   struct intel_gt *gt;
bool vm_ddestroy;
 
mutex_lock(&vma->vm->mutex);
@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+   /* vma->vm may be freed when releasing vma->vm->mutex. */
+   gt = vma->vm->gt;
mutex_unlock(&vma->vm->mutex);
-   release_references(vma, vm_ddestroy);
+   release_references(vma, gt, vm_ddestroy);
 }
 
 void i915_vma_parked(struct intel_gt *gt)
-- 
2.34.3



Re: [Intel-gfx] [PATCH] drm/i915: Fix vm use-after-free in vma destruction

2022-06-20 Thread Thomas Hellström

Hi, Andi

On 5/19/22 23:46, Andi Shyti wrote:

Hi Thomas,

On Thu, May 12, 2022 at 11:40:45AM +0200, Thomas Hellström wrote:

In vma destruction, the following race may occur:

Thread 1: Thread 2:
i915_vma_destroy();

   ...
   list_del_init(vma->vm_link);
   ...
   mutex_unlock(vma->vm->mutex);
  __i915_vm_release();
release_references();

And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leadin go a use-after free.

leading to

Thanks, will fix.


[...]


-static void release_references(struct i915_vma *vma, bool vm_ddestroy)
+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+  bool vm_ddestroy)
  {
struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_gt *gt = vma->vm->gt;
  
  	GEM_BUG_ON(i915_vma_is_active(vma));

but then we have

if (vm_ddestroy)
i915_vm_resv_put(vma->vm);

were we reference to a freed vm, right? Do we need to check it
here, as well?


No, it's not needed, since if vm_ddestroy is true, we keep the vm alive 
using the vm
resv_ref until i915_vm_resv_put(). This is for the rare occasions where, 
during vm destruction, we fail to grab an object reference and therefore 
vma destruction is left for the object destructor. In those cases the 
vma needs to keep the vm in memory for it to be able to grab the vm mutex.


/Thomas






Andi


Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate

2022-06-20 Thread Jason A. Donenfeld
Hi Jani,

Do you plan to merge this revert?

Thanks,
Jason


Re: [Intel-gfx] [PATCH v2 1/3] drm/doc/rfc: VM_BIND feature design document

2022-06-20 Thread Tvrtko Ursulin



Hi,

On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:

VM_BIND design document with description of intended use cases.

v2: Reduce the scope to simple Mesa use case.


since I expressed interest please add me to cc when sending out.

How come the direction changed to simplify all of a sudden? I did not 
spot any discussion to that effect. Was it internal talks?




Signed-off-by: Niranjana Vishwanathapura 
---
  Documentation/gpu/rfc/i915_vm_bind.rst | 238 +
  Documentation/gpu/rfc/index.rst|   4 +
  2 files changed, 242 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst

diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst 
b/Documentation/gpu/rfc/i915_vm_bind.rst
new file mode 100644
index ..4ab590ef11fd
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.rst
@@ -0,0 +1,238 @@
+==
+I915 VM_BIND feature design and use cases
+==
+
+VM_BIND feature
+
+DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+specified address space (VM). These mappings (also referred to as persistent
+mappings) will be persistent across multiple GPU submissions (execbuf calls)
+issued by the UMD, without user having to provide a list of all required
+mappings during each submission (as required by older execbuf mode).
+
+The VM_BIND/UNBIND calls allow UMDs to request a timeline fence for signaling
+the completion of bind/unbind operation.
+
+VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND.
+User has to opt-in for VM_BIND mode of binding for an address space (VM)
+during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+
+Normally, vm_bind/unbind operations will get completed synchronously,


To me synchronously, at this point in the text, reads as ioctl will 
return only when the operation is done. Rest of the paragraph however 
disagrees (plus existence of out fence). It is not clear to me what is 
the actual behaviour. Will it be clear to userspace developers reading 
uapi kerneldoc? If it is async, what are the ordering rules in this version?



+but if the object is being moved, the binding will happen once that the
+moving is complete and out fence will be signaled after binding is complete.
+The bind/unbind operation can get completed out of submission order.
+
+VM_BIND features include:
+
+* Multiple Virtual Address (VA) mappings can map to the same physical pages
+  of an object (aliasing).
+* VA mapping can map to a partial section of the BO (partial binding).
+* Support capture of persistent mappings in the dump upon GPU error.
+* TLB is flushed upon unbind completion. Batching of TLB flushes in some
+  use cases will be helpful.
+* Support for userptr gem objects (no special uapi is required for this).
+
+Execbuf ioctl in VM_BIND mode
+---
+A VM in VM_BIND mode will not support older execbuf mode of binding.
+The execbuf ioctl handling in VM_BIND mode differs significantly from the
+older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+execlist. Hence, no support for implicit sync. It is expected that the below
+work will be able to support requirements of object dependency setting in all
+use cases:
+
+"dma-buf: Add an API for exporting sync files"
+(https://lwn.net/Articles/859290/)


What does this mean? If execbuf3 does not know about target objects how 
can we add a meaningful fence?



+
+The execbuf3 ioctl directly specifies the batch addresses instead of as
+object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+support many of the older features like in/out/submit fences, fence array,
+default gem context and many more (See struct drm_i915_gem_execbuffer3).
+
+In VM_BIND mode, VA allocation is completely managed by the user instead of
+the i915 driver. Hence all VA assignment, eviction are not applicable in
+VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+be using the i915_vma active reference tracking. It will instead use dma-resv
+object for that (See `VM_BIND dma_resv usage`_).
+
+So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA
+evictions, vma lookup table, implicit sync, vma active reference tracking etc.,
+are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling
+should be in a separate file and only functionalities common to these ioctls
+can be the shared code where possible.
+
+VM_PRIVATE objects
+---
+By default, BOs can be mapped on multiple VMs and can also be dma-buf
+exported. Hence these BOs are referred to as Shared BOs.
+During each execbuf submission, the request fence must be added to the
+dma-resv fence list

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: add payload receiving code (rev4)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915/dsi: add payload receiving code (rev4)
URL   : https://patchwork.freedesktop.org/series/105096/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11778_full -> Patchwork_105096v4_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-rkl shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-tglb7/igt@gem_ctx_e...@basic-nohangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-tglb3/igt@gem_ctx_e...@basic-nohangcheck.html

  
 Suppressed 

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

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-bb-first:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-iclb2/igt@gem_exec_balan...@parallel-bb-first.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-iclb6/igt@gem_exec_balan...@parallel-bb-first.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2849])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-kbl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-kbl7/igt@gem_lmem_swapp...@heavy-random.html

  * igt@i915_pm_rpm@system-suspend:
- shard-skl:  [PASS][13] -> [INCOMPLETE][14] ([i915#5420])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-skl7/igt@i915_pm_...@system-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-skl7/igt@i915_pm_...@system-suspend.html

  * igt@i915_selftest@live@hangcheck:
- shard-snb:  [PASS][15] -> [INCOMPLETE][16] ([i915#3921])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-snb5/igt@i915_selftest@l...@hangcheck.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-snb4/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110723])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-iclb4/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109278]) +5 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-iclb4/igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs.html

  * igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-kbl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v4/shard-kbl7/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html

  * igt@kms_ccs@pipe-d-

Re: [Intel-gfx] [PATCH] drm/i915/gem: remove unused assignments

2022-06-20 Thread Tvrtko Ursulin



On 20/06/2022 11:02, zys.zlj...@gmail.com wrote:

From: katrinzhou 

The variable ret is reassigned and the value EINVAL is never used.
Thus, remove the unused assignments.

Addresses-Coverity: ("Unused value")
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create 
parameters (v5)")
Signed-off-by: katrinzhou 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..d5ef5243673a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -931,8 +931,6 @@ static int set_proto_ctx_param(struct drm_i915_file_private 
*fpriv,
break;
  
  	case I915_CONTEXT_PARAM_PERSISTENCE:

-   if (args->size)
-   ret = -EINVAL;
ret = proto_context_set_persistence(fpriv->dev_priv, pc,
args->value);


AFAICT fix should end up with code like this:

if (args->size)
ret = -EINVAL;
else
ret = proto_context_set_persistence(...)
break;


Alternatively move args->size checking into 
proto_context_set_persistence to align with set_persistence().


Regards,

Tvrtko


break;


Re: [Intel-gfx] [PATCH] drm/i915/gem: remove unused assignments

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, zys.zlj...@gmail.com wrote:
> From: katrinzhou 
>
> The variable ret is reassigned and the value EINVAL is never used.
> Thus, remove the unused assignments.

It's obviously a bug, but it's not obvious just throwing the code away
is the fix. Maybe there's a missing "else" instead.

BR,
Jani.


>
> Addresses-Coverity: ("Unused value")
> Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create 
> parameters (v5)")
> Signed-off-by: katrinzhou 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index ab4c5ab28e4d..d5ef5243673a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -931,8 +931,6 @@ static int set_proto_ctx_param(struct 
> drm_i915_file_private *fpriv,
>   break;
>  
>   case I915_CONTEXT_PARAM_PERSISTENCE:
> - if (args->size)
> - ret = -EINVAL;
>   ret = proto_context_set_persistence(fpriv->dev_priv, pc,
>   args->value);
>   break;

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix i915_vma_pin_iomap()

2022-06-20 Thread Juha-Pekka Heikkila

On 10.6.2022 20.43, Matthew Auld wrote:

On Fri, 10 Jun 2022 at 15:53, Matthew Auld
 wrote:


On Fri, 10 Jun 2022 at 13:12, Juha-Pekka Heikkila
 wrote:


From: CQ Tang 

Display might allocate a smem object and call
i915_vma_pin_iomap(), the existing code will fail.

This fix was suggested by Chris P Wilson, that we pin
the smem with i915_gem_object_pin_map_unlocked().

v2 (jheikkil): Change i915_gem_object_pin_map_unlocked to
i915_gem_object_pin_map

Signed-off-by: CQ Tang 
Signed-off-by: Juha-Pekka Heikkila 
Cc: Chris Wilson 
Cc: Jari Tahvanainen 

Reviewed-by: Matthew Auld 


Although maybe consider putting this as patch 1, and then reword the
commit title/message to be more like "drm/i915: extend
i915_vma_iomap()" or so, which then becomes a prep patch for
supporting the dpt fallback to smem. Otherwise it looks like this
patch is basically just fixing the first patch to not trigger the
WARN_ON(), which seems iffy IMO. Each patch by itself should ideally
be functional.


Probably easiest is to put patch 1 in as last, it's the final customer 
for these two other patches. This way if someone will end up doing 
bisecting there would be nothing interesting to see with these.


I did finally get ci to look all green after last weeks outages. I'd 
guess these patches are ready to be pushed but I don't have commit 
rights to drm-tip. Are you able to help with these or I'll go bother 
Imre or Jani to get them into tip?


/Juha-Pekka


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: calculate panel type as per child device index in VBT (rev3)

2022-06-20 Thread Patchwork
== Series Details ==

Series: drm/i915/bios: calculate panel type as per child device index in VBT 
(rev3)
URL   : https://patchwork.freedesktop.org/series/104943/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11778_full -> Patchwork_104943v3_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 13)
--

  Additional (3): shard-rkl shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_dither@fb-8bpc-vs-panel-8bpc@pipe-a-hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [SKIP][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-dg1-18/igt@kms_dither@fb-8bpc-vs-panel-8...@pipe-a-hdmi-a-3.html

  
 Suppressed 

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

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}:   NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html

  * igt@kms_color@pipe-d-invalid-ctm-matrix-sizes:
- {shard-dg1}:NOTRUN -> [WARN][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-dg1-18/igt@kms_co...@pipe-d-invalid-ctm-matrix-sizes.html

  * igt@kms_vblank@pipe-d-query-idle-hang:
- {shard-dg1}:NOTRUN -> [SKIP][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-dg1-17/igt@kms_vbl...@pipe-d-query-idle-hang.html
- {shard-tglu}:   NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-tglu-5/igt@kms_vbl...@pipe-d-query-idle-hang.html

  
New tests
-

  New tests have been introduced between CI_DRM_11778_full and 
Patchwork_104943v3_full:

### New IGT tests (8) ###

  * igt@kms_cursor_edge_walk@top-bottom@pipe-a-hdmi-a-3-128x128:
- Statuses : 1 pass(s)
- Exec time: [3.23] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-a-hdmi-a-3-256x256:
- Statuses : 1 pass(s)
- Exec time: [3.23] s

  * igt@kms_cursor_edge_walk@top-bottom@pipe-a-hdmi-a-3-64x64:
- Statuses : 1 pass(s)
- Exec time: [3.29] s

  * igt@kms_dither@fb-8bpc-vs-panel-8bpc@pipe-a-hdmi-a-3:
- Statuses : 1 skip(s)
- Exec time: [0.10] s

  * igt@kms_plane_lowres@tiling-none@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [8.02] s

  * igt@kms_plane_lowres@tiling-none@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.93] s

  * igt@kms_plane_lowres@tiling-none@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.99] s

  * igt@kms_plane_lowres@tiling-none@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [7.93] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-iclb2/igt@gem_exec_balan...@parallel-out-fence.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-iclb7/igt@gem_exec_balan...@parallel-out-fence.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11778/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@heavy-random:
- shard-kbl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-kbl7/igt@gem_lmem_swapp...@heavy-random.html

  * igt@gem_lmem_swapping@verify-random-ccs:
- shard-apl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104943v3/shard-apl3/igt@gem_lmem_swapp...@verify-rando

Re: [Intel-gfx] [PATCH v2 03/16] drm/i915: Extract has_double_buffered_m_n()

2022-06-20 Thread Jani Nikula
On Fri, 17 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> We have a couple of places that want to make distinction between
> double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> Add a helper for that.
>
> Signed-off-by: Ville Syrjälä 

Mhh. So why a function in intel_display.c instead of a macro in
i915_drv.h? Both are kind of cluttered, but at least in i915_drv.h it
would be among others.

I do think we should have a separate file for display feature check
macros, and move most if not all of the display related HAS_*() stuff
there from i915_drv.h.

So technically this does what it says on the box, and in that sense,

Reviewed-by: Jani Nikula 

but I don't much like the example and precedence this function sets.


> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
>  drivers/gpu/drm/i915/display/intel_display.h | 1 +
>  drivers/gpu/drm/i915/display/intel_dp.c  | 3 +--
>  3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b24784c4522d..5559688047b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2798,6 +2798,11 @@ static int intel_crtc_compute_config(struct 
> intel_atomic_state *state,
>   return 0;
>  }
>  
> +bool has_double_buffered_m_n(struct drm_i915_private *i915)
> +{
> + return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915);
> +}
> +
>  static void
>  intel_reduce_m_n_ratio(u32 *num, u32 *den)
>  {
> @@ -5900,7 +5905,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
> *current_config,
>   PIPE_CONF_CHECK_I(lane_count);
>   PIPE_CONF_CHECK_X(lane_lat_optim_mask);
>  
> - if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
> + if (has_double_buffered_m_n(dev_priv)) {
>   PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
>   } else {
>   PIPE_CONF_CHECK_M_N(dp_m_n);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 2feb8ae5d5d4..44c88aadfc30 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -543,6 +543,7 @@ int intel_atomic_add_affected_planes(struct 
> intel_atomic_state *state,
>struct intel_crtc *crtc);
>  u8 intel_calc_active_pipes(struct intel_atomic_state *state,
>  u8 active_pipes);
> +bool has_double_buffered_m_n(struct drm_i915_private *i915);
>  void intel_link_compute_m_n(u16 bpp, int nlanes,
>   int pixel_clock, int link_clock,
>   struct intel_link_m_n *m_n,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2fac76bcf06d..75645508080a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1842,8 +1842,7 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct 
> intel_dp *intel_dp,
>  static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
>   enum transcoder cpu_transcoder)
>  {
> - /* M1/N1 is double buffered */
> - if (DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915))
> + if (has_double_buffered_m_n(i915))
>   return true;
>  
>   return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v2 02/16] drm/i915: Shuffle some PLL code around

2022-06-20 Thread Jani Nikula
On Fri, 17 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Shuffle some PLL functions around a bit to avoid ugle
> forward declarations later on. No functional changes.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 176 +-
>  1 file changed, 88 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index ddae7e42ac46..bfccc96f16fe 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -905,37 +905,6 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
>   *r2_out = best.r2;
>  }
>  
> -static int
> -hsw_ddi_wrpll_compute_dpll(struct intel_atomic_state *state,
> -struct intel_crtc *crtc)
> -{
> - struct intel_crtc_state *crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> - unsigned int p, n2, r2;
> -
> - hsw_ddi_calculate_wrpll(crtc_state->port_clock * 1000, &r2, &n2, &p);
> -
> - crtc_state->dpll_hw_state.wrpll =
> - WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
> - WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
> - WRPLL_DIVIDER_POST(p);
> -
> - return 0;
> -}
> -
> -static struct intel_shared_dpll *
> -hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
> -struct intel_crtc *crtc)
> -{
> - struct intel_crtc_state *crtc_state =
> - intel_atomic_get_new_crtc_state(state, crtc);
> -
> - return intel_find_shared_dpll(state, crtc,
> -   &crtc_state->dpll_hw_state,
> -   BIT(DPLL_ID_WRPLL2) |
> -   BIT(DPLL_ID_WRPLL1));
> -}
> -
>  static int hsw_ddi_wrpll_get_freq(struct drm_i915_private *dev_priv,
> const struct intel_shared_dpll *pll,
> const struct intel_dpll_hw_state *pll_state)
> @@ -976,6 +945,37 @@ static int hsw_ddi_wrpll_get_freq(struct 
> drm_i915_private *dev_priv,
>   return (refclk * n / 10) / (p * r) * 2;
>  }
>  
> +static int
> +hsw_ddi_wrpll_compute_dpll(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> +{
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + unsigned int p, n2, r2;
> +
> + hsw_ddi_calculate_wrpll(crtc_state->port_clock * 1000, &r2, &n2, &p);
> +
> + crtc_state->dpll_hw_state.wrpll =
> + WRPLL_PLL_ENABLE | WRPLL_REF_LCPLL |
> + WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
> + WRPLL_DIVIDER_POST(p);
> +
> + return 0;
> +}
> +
> +static struct intel_shared_dpll *
> +hsw_ddi_wrpll_get_dpll(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> +{
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> +
> + return intel_find_shared_dpll(state, crtc,
> +   &crtc_state->dpll_hw_state,
> +   BIT(DPLL_ID_WRPLL2) |
> +   BIT(DPLL_ID_WRPLL1));
> +}
> +
>  static int
>  hsw_ddi_lcpll_compute_dpll(struct intel_crtc_state *crtc_state)
>  {
> @@ -1618,43 +1618,6 @@ skl_ddi_calculate_wrpll(int clock /* in Hz */,
>   return 0;
>  }
>  
> -static int skl_ddi_hdmi_pll_dividers(struct intel_crtc_state *crtc_state)
> -{
> - struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> - struct skl_wrpll_params wrpll_params = {};
> - u32 ctrl1, cfgcr1, cfgcr2;
> - int ret;
> -
> - /*
> -  * See comment in intel_dpll_hw_state to understand why we always use 0
> -  * as the DPLL id in this function.
> -  */
> - ctrl1 = DPLL_CTRL1_OVERRIDE(0);
> -
> - ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
> -
> - ret = skl_ddi_calculate_wrpll(crtc_state->port_clock * 1000,
> -   i915->dpll.ref_clks.nssc, &wrpll_params);
> - if (ret)
> - return ret;
> -
> - cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
> - DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
> - wrpll_params.dco_integer;
> -
> - cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
> - DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
> - DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
> - DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
> - wrpll_params.central_freq;
> -
> - crtc_state->dpll_hw_state.ctrl1 = ctrl1;
> - crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
> - crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
> -
> - return 0;
> -}
> -
>  static int skl_ddi_wrpll_get_freq(struct drm_i915_private *i915,
> const struct intel_shared_dpll *pll,
> 

Re: [Intel-gfx] [PATCH v2 01/16] drm/i915: Relocate intel_crtc_dotclock()

2022-06-20 Thread Jani Nikula
On Fri, 17 Jun 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> intel_crtc_dotclock() is a bit misplaced. In lieu of a better
> place let's just move it next to its friends in intel_display.c.

With hopes we'll find a better place than intel_display.c for this and
its friends in the future,

Reviewed-by: Jani Nikula 


>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 22 
>  drivers/gpu/drm/i915/display/intel_display.c | 22 
>  2 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 272e1bf6006b..51bf26dcb209 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -323,28 +323,6 @@ static int icl_calc_tbt_pll_link(struct drm_i915_private 
> *dev_priv,
>   }
>  }
>  
> -int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
> -{
> - int dotclock;
> -
> - if (intel_crtc_has_dp_encoder(pipe_config))
> - dotclock = intel_dotclock_calculate(pipe_config->port_clock,
> - &pipe_config->dp_m_n);
> - else if (pipe_config->has_hdmi_sink && pipe_config->pipe_bpp > 24)
> - dotclock = pipe_config->port_clock * 24 / pipe_config->pipe_bpp;
> - else
> - dotclock = pipe_config->port_clock;
> -
> - if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
> - !intel_crtc_has_dp_encoder(pipe_config))
> - dotclock *= 2;
> -
> - if (pipe_config->pixel_multiplier)
> - dotclock /= pipe_config->pixel_multiplier;
> -
> - return dotclock;
> -}
> -
>  static void ddi_dotclock_get(struct intel_crtc_state *pipe_config)
>  {
>   /* CRT dotclock is determined via other means */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 90bd26431e31..b24784c4522d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4569,6 +4569,28 @@ int intel_dotclock_calculate(int link_freq,
>   return div_u64(mul_u32_u32(m_n->link_m, link_freq), m_n->link_n);
>  }
>  
> +int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
> +{
> + int dotclock;
> +
> + if (intel_crtc_has_dp_encoder(pipe_config))
> + dotclock = intel_dotclock_calculate(pipe_config->port_clock,
> + &pipe_config->dp_m_n);
> + else if (pipe_config->has_hdmi_sink && pipe_config->pipe_bpp > 24)
> + dotclock = pipe_config->port_clock * 24 / pipe_config->pipe_bpp;
> + else
> + dotclock = pipe_config->port_clock;
> +
> + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 &&
> + !intel_crtc_has_dp_encoder(pipe_config))
> + dotclock *= 2;
> +
> + if (pipe_config->pixel_multiplier)
> + dotclock /= pipe_config->pixel_multiplier;
> +
> + return dotclock;
> +}
> +
>  /* Returns the currently programmed mode of the given encoder. */
>  struct drm_display_mode *
>  intel_encoder_current_mode(struct intel_encoder *encoder)

-- 
Jani Nikula, Intel Open Source Graphics Center


[Intel-gfx] [PATCH v5] drm/i915/dsi: add payload receiving code

2022-06-20 Thread William Tseng
To support Host to read data from Peripheral after
a DCS read command is sent over DSI.

v1: initial version.
v2:
- adding error message when failing to place BTA.
- returning byte number instead of 0 for the read
function dsi_read_pkt_payld().
v3: fixing coding style warning.
v4:
- correcting the data type of returning data for
the read function dsi_read_pkt_payld().
v5: adding change history as part of commit messages.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Vandita Kulkarni 
Cc: Lee Shawn C 
Signed-off-by: William Tseng 
---
 drivers/gpu/drm/i915/display/icl_dsi.c  | 75 +++--
 drivers/gpu/drm/i915/display/icl_dsi_regs.h | 13 
 2 files changed, 83 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 19bf717fd4cb..b2aa3c7902f3 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -201,6 +201,69 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
return 0;
 }
 
+static int dsi_read_pkt_payld(struct intel_dsi_host *host,
+ u8 *rx_buf, size_t rx_len)
+{
+   struct intel_dsi *intel_dsi = host->intel_dsi;
+   struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
+   enum transcoder dsi_trans = dsi_port_to_transcoder(host->port);
+   u32 tmp, /*hdr_data, */payld_data;
+   u32 payld_dw;
+   size_t payld_read;
+   u8 i;
+
+   /* step2: place a BTA reque */
+   /* check if header credit available */
+   if (!wait_for_header_credits(dev_priv, dsi_trans, 1)) {
+   drm_err(&dev_priv->drm, "not ready to recive payload\n");
+   return -EBUSY;
+   }
+
+   /* place BTA request */
+   tmp = intel_de_read(dev_priv, DSI_LP_MSG(dsi_trans));
+   tmp |= LINK_BTA;
+   intel_de_write(dev_priv, DSI_LP_MSG(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_LP_MSG(dsi_trans));
+
+   /* step2a:  */
+   /* step2ai: set Turn-Around Timeout */
+   tmp = intel_de_read(dev_priv, DSI_TA_TO(dsi_trans));
+   tmp &= ~TA_TIMEOUT_VALUE_MASK;
+   tmp |= TA_TIMEOUT_VALUE(intel_dsi->turn_arnd_val);
+   intel_de_write(dev_priv, DSI_TA_TO(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_TA_TO(dsi_trans));
+
+   /* step2aii: set maximum allowed time */
+   tmp = intel_de_read(dev_priv, DSI_LPRX_HOST_TO(dsi_trans));
+   tmp &= ~LPRX_TIMEOUT_VALUE_MASK;
+   tmp |= LPRX_TIMEOUT_VALUE(intel_dsi->lp_rx_timeout);
+   intel_de_write(dev_priv, DSI_LPRX_HOST_TO(dsi_trans), tmp);
+
+   tmp = intel_de_read(dev_priv, DSI_LPRX_HOST_TO(dsi_trans));
+
+   /* step4a: wait and read payload */
+   if (wait_for_us(((intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans)) &
+   NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT) > 0, 
10)) {
+   drm_err(&dev_priv->drm, "DSI fails to receive payload\n");
+   return -EBUSY;
+   }
+
+   tmp = intel_de_read(dev_priv, DSI_CMD_RXCTL(dsi_trans));
+   payld_dw = (tmp & NUMBER_RX_PLOAD_DW_MASK) >> NUMBER_RX_PLOAD_DW_SHIFT;
+   payld_read = min(rx_len, (size_t)(4 * payld_dw));
+
+   for (i = 0; i < payld_read; i++) {
+   if ((i % 4) == 0)
+   payld_data = intel_de_read(dev_priv, 
DSI_CMD_RXPYLD(dsi_trans));
+
+   *(rx_buf + i) = (payld_data >> (8 * (i % 4))) & 0xff;
+   }
+
+   return (int)payld_read;
+}
+
 void icl_dsi_frame_update(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1078,8 +1141,8 @@ static void gen11_dsi_setup_timeouts(struct intel_encoder 
*encoder,
mul = 8 * 100;
hs_tx_timeout = DIV_ROUND_UP(intel_dsi->hs_tx_timeout * mul,
 divisor);
-   lp_rx_timeout = DIV_ROUND_UP(intel_dsi->lp_rx_timeout * mul, divisor);
-   ta_timeout = DIV_ROUND_UP(intel_dsi->turn_arnd_val * mul, divisor);
+   lp_rx_timeout = intel_dsi->lp_rx_timeout;
+   ta_timeout = intel_dsi->turn_arnd_val;
 
for_each_dsi_port(port, intel_dsi->ports) {
dsi_trans = dsi_port_to_transcoder(port);
@@ -1837,9 +1900,11 @@ static ssize_t gen11_dsi_host_transfer(struct 
mipi_dsi_host *host,
if (ret < 0)
return ret;
 
-   //TODO: add payload receive code if needed
-
-   ret = sizeof(dsi_pkt.header) + dsi_pkt.payload_length;
+   /* add payload receive code if needed */
+   if (msg->rx_buf && msg->rx_len > 0)
+   ret = dsi_read_pkt_payld(intel_dsi_host, msg->rx_buf, 
msg->rx_len);
+   else
+   ret = sizeof(dsi_pkt.header) + dsi_pkt.payload_length;
 
return ret;
 }
diff --git a/drivers/gpu/drm/i915/display/icl_dsi_regs.h 
b/drivers/gpu/drm/i915/display/icl_dsi_regs.h
index f78f28b8dd94..a77a49b42d60 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi_regs.h
++

Re: [Intel-gfx] [PATCH 00/16] drm/i915: stop modifying "const" device info

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, Jani Nikula  wrote:
> Move any device info that gets modified runtime into runtime info,
> making device info a const pointer. Finally throw mkwrite_device_info()
> into the curb.

Had some SMTP issues sending this series, sorry if you got multiple
copies of some patches.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v4] drm/i915/bios: calculate panel type as per child device index in VBT

2022-06-20 Thread Jani Nikula
On Mon, 20 Jun 2022, Animesh Manna  wrote:
> Each LFP may have different panel type which is stored in LFP data
> data block. Based on the child device index respective panel-type/
> panel-type2 field will be used.
>
> v1: Initial rfc verion.
> v2: Based on review comments from Jani,
> - Used panel-type instead addition panel-index variable.
> - DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
> macro.
> v3:
> - passing intel_bios_encoder_data as argument of
> intel_bios_init_panel(). Passing NULL to indicate encoder is not
> initialized yet for dsi as current focus is to enable dual EDP. [Jani]
> v4:
> - encoder->devdata used which is initialized before from vbt
> structure. [Jani]
>
> Signed-off-by: Animesh Manna 

LGTM, but I'd also like an ack from Ville too as he's been doing a bunch
of changes around this lately.

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c | 16 ++--
>  drivers/gpu/drm/i915/display/intel_bios.h |  1 +
>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 ++-
>  drivers/gpu/drm/i915/display/intel_lvds.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_vbt_defs.h |  4 
>  drivers/gpu/drm/i915/display/vlv_dsi.c|  2 +-
>  8 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 3b5305c219ba..5dcfa7feffa9 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -2050,7 +2050,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
>   /* attach connector to encoder */
>   intel_connector_attach_encoder(intel_connector, encoder);
>  
> - intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL);
> + intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL, NULL);
>  
>   mutex_lock(&dev->mode_config.mutex);
>   intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 76e86358adb9..e97f1f979a48 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -604,12 +604,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
>  }
>  
>  static int opregion_get_panel_type(struct drm_i915_private *i915,
> +const struct intel_bios_encoder_data 
> *devdata,
>  const struct edid *edid)
>  {
>   return intel_opregion_get_panel_type(i915);
>  }
>  
>  static int vbt_get_panel_type(struct drm_i915_private *i915,
> +   const struct intel_bios_encoder_data *devdata,
> const struct edid *edid)
>  {
>   const struct bdb_lvds_options *lvds_options;
> @@ -625,10 +627,16 @@ static int vbt_get_panel_type(struct drm_i915_private 
> *i915,
>   return -1;
>   }
>  
> + if (devdata && devdata->child.handle == DEVICE_HANDLE_LFP2)
> + return lvds_options->panel_type2;
> +
> + drm_WARN_ON(&i915->drm, devdata && devdata->child.handle != 
> DEVICE_HANDLE_LFP1);
> +
>   return lvds_options->panel_type;
>  }
>  
>  static int pnpid_get_panel_type(struct drm_i915_private *i915,
> + const struct intel_bios_encoder_data *devdata,
>   const struct edid *edid)
>  {
>   const struct bdb_lvds_lfp_data *data;
> @@ -675,6 +683,7 @@ static int pnpid_get_panel_type(struct drm_i915_private 
> *i915,
>  }
>  
>  static int fallback_get_panel_type(struct drm_i915_private *i915,
> +const struct intel_bios_encoder_data 
> *devdata,
>  const struct edid *edid)
>  {
>   return 0;
> @@ -688,11 +697,13 @@ enum panel_type {
>  };
>  
>  static int get_panel_type(struct drm_i915_private *i915,
> +   const struct intel_bios_encoder_data *devdata,
> const struct edid *edid)
>  {
>   struct {
>   const char *name;
>   int (*get_panel_type)(struct drm_i915_private *i915,
> +   const struct intel_bios_encoder_data 
> *devdata,
> const struct edid *edid);
>   int panel_type;
>   } panel_types[] = {
> @@ -716,7 +727,7 @@ static int get_panel_type(struct drm_i915_private *i915,
>   int i;
>  
>   for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
> - panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
> edid);
> + panel_types[i].panel_type = panel_types[i].get_panel_type(i915, 
> devdata, edid);
>  
>   drm_WARN_ON(&i915->drm, panel_types[i].panel_type > 0xf &&
>   panel_types[i].panel_type != 0xff);

[Intel-gfx] [PATCH 16/16] drm/i915: make device info a pointer to static const data

2022-06-20 Thread Jani Nikula
Now that the device info is no longer modified runtime, we don't need to
make a copy of it, and we can convert i915->__info into a pointer to
static const data. Also remove mkwrite_device_info().

This does increase the text size slightly.

Signed-off-by: Jani Nikula 

---

An alternative is to keep copying device info, but casting away the
const only once at the copy time, removing mkwrite_device_info().
---
 drivers/gpu/drm/i915/i915_driver.c |  8 ++--
 drivers/gpu/drm/i915/i915_drv.h| 11 ++-
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 5969cc7805d3..9c9c492e97a8 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -793,9 +793,6 @@ static void i915_welcome_messages(struct drm_i915_private 
*dev_priv)
 static struct drm_i915_private *
 i915_driver_create(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
-   const struct intel_device_info *match_info =
-   (struct intel_device_info *)ent->driver_data;
-   struct intel_device_info *device_info;
struct intel_runtime_info *runtime;
struct drm_i915_private *i915;
 
@@ -809,9 +806,8 @@ i915_driver_create(struct pci_dev *pdev, const struct 
pci_device_id *ent)
/* Device parameters start as a copy of module parameters. */
i915_params_copy(&i915->params, &i915_modparams);
 
-   /* Setup the write-once "constant" device info */
-   device_info = mkwrite_device_info(i915);
-   memcpy(device_info, match_info, sizeof(*device_info));
+   /* Static const device info. */
+   i915->__info = (const struct intel_device_info *)ent->driver_data;
 
/* Initialize initial runtime info from static const data and pdev. */
runtime = RUNTIME_INFO(i915);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 89472440947c..a2a57f07c5be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -380,7 +380,7 @@ struct drm_i915_private {
/* i915 device parameters */
struct i915_params params;
 
-   const struct intel_device_info __info; /* Use INTEL_INFO() to access. */
+   const struct intel_device_info *__info; /* Use INTEL_INFO() to access. 
*/
struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */
struct intel_driver_caps caps;
 
@@ -848,7 +848,7 @@ static inline struct intel_gt *to_gt(struct 
drm_i915_private *i915)
GENMASK(INTEL_FRONTBUFFER_BITS_PER_PIPE * ((pipe) + 1) - 1, \
INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))
 
-#define INTEL_INFO(dev_priv)   (&(dev_priv)->__info)
+#define INTEL_INFO(__i915) (__i915->__info)
 #define RUNTIME_INFO(dev_priv) (&(dev_priv)->__runtime)
 #define DRIVER_CAPS(dev_priv)  (&(dev_priv)->caps)
 
@@ -1432,13 +1432,6 @@ void i915_gem_driver_release(struct drm_i915_private 
*dev_priv);
 
 int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
 
-/* intel_device_info.c */
-static inline struct intel_device_info *
-mkwrite_device_info(struct drm_i915_private *dev_priv)
-{
-   return (struct intel_device_info *)INTEL_INFO(dev_priv);
-}
-
 static inline enum i915_map_type
 i915_coherent_map_type(struct drm_i915_private *i915,
   struct drm_i915_gem_object *obj, bool always_coherent)
-- 
2.30.2



[Intel-gfx] [PATCH 15/16] drm/i915: stop resetting display info to zero for no display

2022-06-20 Thread Jani Nikula
This is the last blocker in making device info a pointer to const
data. Hopefully resetting pipe_mask to 0 and thus ensuring HAS_DISPLAY()
is false is enough, and we don't go ahead and do something with the
display info regardless. Fingers crossed.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_device_info.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 12c776900a40..84e6a54c82ff 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -283,7 +283,6 @@ void intel_device_info_subplatform_init(struct 
drm_i915_private *i915)
  */
 void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
 {
-   struct intel_device_info *info = mkwrite_device_info(dev_priv);
struct intel_runtime_info *runtime = RUNTIME_INFO(dev_priv);
enum pipe pipe;
 
@@ -409,7 +408,6 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
if (!HAS_DISPLAY(dev_priv)) {
dev_priv->drm.driver_features &= ~(DRIVER_MODESET |
   DRIVER_ATOMIC);
-   memset(&info->display, 0, sizeof(info->display));
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
}
-- 
2.30.2



[Intel-gfx] [PATCH 14/16] drm/i915: move has_dsc to runtime info

2022-06-20 Thread Jani Nikula
If it's modified runtime, it's runtime info.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
 drivers/gpu/drm/i915/i915_pci.c   | 4 ++--
 drivers/gpu/drm/i915/intel_device_info.c  | 3 ++-
 drivers/gpu/drm/i915/intel_device_info.h  | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 43e1bbc1e303..bb5c5fa3f157 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -344,7 +344,7 @@ bool intel_dsc_source_support(const struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *i915 = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
 
-   if (!INTEL_INFO(i915)->display.has_dsc)
+   if (!RUNTIME_INFO(i915)->has_dsc)
return false;
 
if (DISPLAY_VER(i915) >= 12)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c6637a4982ed..687b49549d13 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -829,7 +829,7 @@ static const struct intel_device_info cml_gt2_info = {
ICL_COLORS, \
.dbuf.size = 2048, \
.dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2), \
-   .display.has_dsc = 1, \
+   .__runtime.has_dsc = 1, \
.has_coherent_ggtt = false, \
.has_logical_ring_elsq = 1
 
@@ -958,7 +958,7 @@ static const struct intel_device_info adl_s_info = {
.__runtime.has_dmc = 1, 
\
.display.has_dp_mst = 1,
\
.display.has_dsb = 1,   
\
-   .display.has_dsc = 1,   
\
+   .__runtime.has_dsc = 1, 
\
.__runtime.fbc_mask = BIT(INTEL_FBC_A), 
\
.display.has_fpga_dbg = 1,  
\
.__runtime.has_hdcp = 1,
\
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index ed5ad5c60db6..12c776900a40 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -127,6 +127,7 @@ void intel_device_info_print(const struct intel_device_info 
*info,
 
drm_printf(p, "has_hdcp: %s\n", str_yes_no(runtime->has_hdcp));
drm_printf(p, "has_dmc: %s\n", str_yes_no(runtime->has_dmc));
+   drm_printf(p, "has_dsc: %s\n", str_yes_no(runtime->has_dsc));
 
drm_printf(p, "rawclk rate: %u kHz\n", runtime->rawclk_freq);
 }
@@ -393,7 +394,7 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
 
if (DISPLAY_VER(dev_priv) >= 10 &&
(dfsm & GLK_DFSM_DISPLAY_DSC_DISABLE))
-   info->display.has_dsc = 0;
+   runtime->has_dsc = 0;
}
 
if (GRAPHICS_VER(dev_priv) == 6 && i915_vtd_active(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 0a3c925d02b7..daeaaad325b7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -176,7 +176,6 @@ enum intel_ppgtt_type {
func(has_ddi); \
func(has_dp_mst); \
func(has_dsb); \
-   func(has_dsc); \
func(has_fpga_dbg); \
func(has_gmch); \
func(has_hotplug); \
@@ -236,6 +235,7 @@ struct intel_runtime_info {
 
bool has_hdcp;
bool has_dmc;
+   bool has_dsc;
};
 };
 
-- 
2.30.2



[Intel-gfx] [PATCH 13/16] drm/i915: move has_dmc to runtime info

2022-06-20 Thread Jani Nikula
If it's modified runtime, it's runtime info.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/i915_pci.c  | 6 +++---
 drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
 drivers/gpu/drm/i915/intel_device_info.h | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5bb1f0e9368c..89472440947c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1267,7 +1267,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_RPS(dev_priv)  (INTEL_INFO(dev_priv)->has_rps)
 
-#define HAS_DMC(dev_priv)  (INTEL_INFO(dev_priv)->display.has_dmc)
+#define HAS_DMC(dev_priv)  (RUNTIME_INFO(dev_priv)->has_dmc)
 
 #define HAS_HECI_PXP(dev_priv) \
(INTEL_INFO(dev_priv)->has_heci_pxp)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 11c236b6a017..c6637a4982ed 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -650,7 +650,7 @@ static const struct intel_device_info chv_info = {
GEN8_FEATURES, \
GEN(9), \
GEN9_DEFAULT_PAGE_SIZES, \
-   .display.has_dmc = 1, \
+   .__runtime.has_dmc = 1, \
.has_gt_uc = 1, \
.__runtime.has_hdcp = 1, \
.display.has_ipc = 1, \
@@ -708,7 +708,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_dmc = 1, \
+   .__runtime.has_dmc = 1, \
.has_rc6 = 1, \
.has_rps = true, \
.display.has_dp_mst = 1, \
@@ -955,7 +955,7 @@ static const struct intel_device_info adl_s_info = {
.dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
\
BIT(DBUF_S4),   
\
.display.has_ddi = 1,   
\
-   .display.has_dmc = 1,   
\
+   .__runtime.has_dmc = 1, 
\
.display.has_dp_mst = 1,
\
.display.has_dsb = 1,   
\
.display.has_dsc = 1,   
\
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 26c883c05e44..ed5ad5c60db6 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -126,6 +126,7 @@ void intel_device_info_print(const struct intel_device_info 
*info,
 #undef PRINT_FLAG
 
drm_printf(p, "has_hdcp: %s\n", str_yes_no(runtime->has_hdcp));
+   drm_printf(p, "has_dmc: %s\n", str_yes_no(runtime->has_dmc));
 
drm_printf(p, "rawclk rate: %u kHz\n", runtime->rawclk_freq);
 }
@@ -388,7 +389,7 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
runtime->fbc_mask = 0;
 
if (DISPLAY_VER(dev_priv) >= 11 && (dfsm & 
ICL_DFSM_DMC_DISABLE))
-   info->display.has_dmc = 0;
+   runtime->has_dmc = 0;
 
if (DISPLAY_VER(dev_priv) >= 10 &&
(dfsm & GLK_DFSM_DISPLAY_DSC_DISABLE))
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 76317db394b7..0a3c925d02b7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -173,7 +173,6 @@ enum intel_ppgtt_type {
/* Keep in alphabetical order */ \
func(cursor_needs_physical); \
func(has_cdclk_crawl); \
-   func(has_dmc); \
func(has_ddi); \
func(has_dp_mst); \
func(has_dsb); \
@@ -236,6 +235,7 @@ struct intel_runtime_info {
u8 fbc_mask;
 
bool has_hdcp;
+   bool has_dmc;
};
 };
 
-- 
2.30.2



  1   2   >