Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Tian, Kevin]

> From: Liu, Yi L 
> Sent: Wednesday, March 8, 2023 3:47 PM
> 
> > From: Tian, Kevin 
> > Sent: Wednesday, March 8, 2023 3:26 PM
> >
> > > From: Liu, Yi L 
> > > Sent: Tuesday, March 7, 2023 9:29 PM
> > >
> > > >
> > > > I really prefer the 'use the iommufd option' still exist, it is so
> > > > much cleaner and easier for the actual users of this API. We've lost
> > > > the point by worrying about no iommu.
> > >
> > > Hmmm, so you are suggesting to have both the device fd approach
> > > and the zero-length array approach, let user to select the best way
> > > based on their wisdom. Is it? how about something like below in the
> > > uapi header.
> > >
> > > /**
> > >  * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> > >  *  struct vfio_pci_hot_reset)
> > >  *
> > >  * Userspace requests hot reset for the devices it uses.  Due to the
> > >  * underlying topology, multiple devices may be affected in the reset.
> > >  * The affected devices may have been opened by the user or by other
> > >  * users or not opened yet.  Only when all the affected devices are
> > >  * either opened by the current user or not opened by any user, should
> > >  * the reset request be allowed.  Otherwise, this request is expected
> > >  * to return error. group_fds array can accept either group fds or
> > >  * device fds.  Users using iommufd (valid fd), could also passing a
> > >  * zero-length group_fds array to indicate using the bound iommufd_ctx
> > >  * for ownership check to the affected devices that are opened.
> > >  *
> > >  * Return: 0 on success, -errno on failure.
> > >  */
> > > struct vfio_pci_hot_reset {
> > > __u32   argsz;
> > > __u32   flags;
> > > __u32   count;
> > > __s32   group_fds[];
> > > };
> > >
> >
> >  * Userspace requests hot reset for the devices it uses.  Due to the
> >  * underlying topology, multiple devices can be affected in the reset
> >  * while some might be opened by another user. To avoid interference
> >  * the calling user must ensure all affected devices, if opened, are
> >  * owned by itself.
> >  *
> >  * The ownership can be proved in three ways:
> >  *   - An array of group fds
> >  *   - An array of device fds
> >  *   - A zero-length array
> >  *
> Thanks.
> >  * In the last case all affected devices which are opened by this user must
> >  * have been bound to a same iommufd_ctx.
> 
> I think we only allow it when this iommufd_ctx is valid. Is it? To
> user, it means device should be bound to a positive iommufd.

I didn't get it. Do we have a iommufd_ctx created but marked as
invalid?

> 
> > and with this change let's rename 'group_fds'  to 'fds'
> 
> Sure. It would be something like below:
> 
> struct vfio_pci_hot_reset {
>   __u32   argsz;
>   __u32   flags;
>   _u32   count;
>   union {
>   __s32   group_fds[0];
>   __s32   fds[0];
>   };
> };
> 

why union? Just renaming should work. In the kernel we will first
check whether it's group, whether it's device, then compare
iommufd_ctx is zero length.

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Liu, Yi L]

> From: Tian, Kevin 
> Sent: Wednesday, March 8, 2023 3:26 PM
> 
> > From: Liu, Yi L 
> > Sent: Tuesday, March 7, 2023 9:29 PM
> >
> > >
> > > I really prefer the 'use the iommufd option' still exist, it is so
> > > much cleaner and easier for the actual users of this API. We've lost
> > > the point by worrying about no iommu.
> >
> > Hmmm, so you are suggesting to have both the device fd approach
> > and the zero-length array approach, let user to select the best way
> > based on their wisdom. Is it? how about something like below in the
> > uapi header.
> >
> > /**
> >  * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> >  *  struct vfio_pci_hot_reset)
> >  *
> >  * Userspace requests hot reset for the devices it uses.  Due to the
> >  * underlying topology, multiple devices may be affected in the reset.
> >  * The affected devices may have been opened by the user or by other
> >  * users or not opened yet.  Only when all the affected devices are
> >  * either opened by the current user or not opened by any user, should
> >  * the reset request be allowed.  Otherwise, this request is expected
> >  * to return error. group_fds array can accept either group fds or
> >  * device fds.  Users using iommufd (valid fd), could also passing a
> >  * zero-length group_fds array to indicate using the bound iommufd_ctx
> >  * for ownership check to the affected devices that are opened.
> >  *
> >  * Return: 0 on success, -errno on failure.
> >  */
> > struct vfio_pci_hot_reset {
> > __u32   argsz;
> > __u32   flags;
> > __u32   count;
> > __s32   group_fds[];
> > };
> >
> 
>  * Userspace requests hot reset for the devices it uses.  Due to the
>  * underlying topology, multiple devices can be affected in the reset
>  * while some might be opened by another user. To avoid interference
>  * the calling user must ensure all affected devices, if opened, are
>  * owned by itself.
>  *
>  * The ownership can be proved in three ways:
>  *   - An array of group fds
>  *   - An array of device fds
>  *   - A zero-length array
>  *
Thanks.
>  * In the last case all affected devices which are opened by this user must
>  * have been bound to a same iommufd_ctx.

I think we only allow it when this iommufd_ctx is valid. Is it? To
user, it means device should be bound to a positive iommufd.

> and with this change let's rename 'group_fds'  to 'fds'

Sure. It would be something like below:

struct vfio_pci_hot_reset {
__u32   argsz;
__u32   flags;
_u32   count;
union {
__s32   group_fds[0];
__s32   fds[0];
};
};

Regards,
Yi Liu

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Tian, Kevin]

> From: Liu, Yi L 
> Sent: Tuesday, March 7, 2023 9:29 PM
> 
> >
> > I really prefer the 'use the iommufd option' still exist, it is so
> > much cleaner and easier for the actual users of this API. We've lost
> > the point by worrying about no iommu.
> 
> Hmmm, so you are suggesting to have both the device fd approach
> and the zero-length array approach, let user to select the best way
> based on their wisdom. Is it? how about something like below in the
> uapi header.
> 
> /**
>  * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
>  *  struct vfio_pci_hot_reset)
>  *
>  * Userspace requests hot reset for the devices it uses.  Due to the
>  * underlying topology, multiple devices may be affected in the reset.
>  * The affected devices may have been opened by the user or by other
>  * users or not opened yet.  Only when all the affected devices are
>  * either opened by the current user or not opened by any user, should
>  * the reset request be allowed.  Otherwise, this request is expected
>  * to return error. group_fds array can accept either group fds or
>  * device fds.  Users using iommufd (valid fd), could also passing a
>  * zero-length group_fds array to indicate using the bound iommufd_ctx
>  * for ownership check to the affected devices that are opened.
>  *
>  * Return: 0 on success, -errno on failure.
>  */
> struct vfio_pci_hot_reset {
> __u32   argsz;
> __u32   flags;
> __u32   count;
> __s32   group_fds[];
> };
> 

 * Userspace requests hot reset for the devices it uses.  Due to the
 * underlying topology, multiple devices can be affected in the reset
 * while some might be opened by another user. To avoid interference
 * the calling user must ensure all affected devices, if opened, are
 * owned by itself.
 *
 * The ownership can be proved in three ways:
 *   - An array of group fds
 *   - An array of device fds
 *   - A zero-length array
 *
 * In the last case all affected devices which are opened by this user must
 * have been bound to a same iommufd_ctx.

and with this change let's rename 'group_fds'  to 'fds'

Re: [Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

[Tian, Kevin]

> From: Liu, Yi L 
> Sent: Tuesday, March 7, 2023 9:04 PM
> 
> > From: Jason Gunthorpe 
> > Sent: Tuesday, March 7, 2023 8:38 PM
> >
> > On Tue, Mar 07, 2023 at 06:38:59AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L 
> > > > Sent: Friday, March 3, 2023 2:58 PM
> > > >
> > > > > What should we return here anyhow if an access was created?
> > > >
> > > > iommufd_access->obj.id. should be fine. Is it?
> > >
> > > Thinking more I'm not sure whether it's a good idea to fill the
> > > dev_id field with an access object id and then later confuse
> > > the user to get an -ENOENT error when trying to allocate a
> > > hwpt with an access object id.
> > >
> > > How can user differentiate it from the real error case where
> > > invalid iommufd object is used?
> > >
> > > It sounds clearer to return dev_id only when there is a true
> > > device object being created by the bind_iommufd cmd. Then
> > > the user can use it to decide whether  to further attempt
> > > dev_id related cmds.
> >
> > It means we can never return an access_id
> >
> > I don't think this is a problem, the first thing userspace should do
> > is a get info to the dev_id which is needed to learn which iommu
> > driver is running it, if that returns EOPNOTSUPP then it isn't a
> > physical iommu device.
> 
> This may mean your below patch depends on the get info series. 
> Also need to update the description to the ioctl.
> 
> https://lore.kernel.org/linux-iommu/12-v1-7612f88c19f5+2f21-
> iommufd_alloc_...@nvidia.com/
> 

Probably not necessary. It's user to get info and then create hwpt.
I don't think we'll ever add a check whether the user has acquired
the info before creating the hwpt. From this angle there is no
dependency in code-wise.

My earlier comment was based on the user creating hwpt w/o
querying the info. Looks it's just user's job to make it right. We
may clarify this point in hwpt_alloc uAPI comment.

Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg file for PICA registers

[Kahola, Mika]

> -Original Message-
> From: Intel-gfx  On Behalf Of Kahola,
> Mika
> Sent: Tuesday, March 7, 2023 3:24 PM
> To: De Marchi, Lucas 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg 
> file
> for PICA registers
> 
> > -Original Message-
> > From: De Marchi, Lucas 
> > Sent: Wednesday, March 1, 2023 1:27 AM
> > To: Kahola, Mika 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create
> > separate reg file for PICA registers
> >
> > On Fri, Feb 24, 2023 at 12:13:37PM +0200, Mika Kahola wrote:
> > >Create a separate file to store registers for PICA chips
> > >C10 and C20.
> > >
> > >v2: Rename file (Jani)
> > >
> > >Signed-off-by: Radhakrishna Sripada 
> > >Signed-off-by: Mika Kahola 
> > >---
> > > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 136
> > >++
> > > 1 file changed, 136 insertions(+)
> > > create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> > >
> > >diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> > >b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> > >new file mode 100644
> > >index ..d6b3709d3762
> > >--- /dev/null
> > >+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> > >@@ -0,0 +1,136 @@
> > >+/* SPDX-License-Identifier: MIT
> > >+ *
> > >+ * Copyright © 2022 Intel Corporation  */
> > >+
> > >+#ifndef __INTEL_CX0_PHY_REGS_H__
> > >+#define __INTEL_CX0_PHY_REGS_H__
> > >+
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A 0x64040
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B 0x64140
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1
> > 0x16F240
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2
> > 0x16F440
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3
> > 0x16F640
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4
> > 0x16F840
> > >+#define _XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
> > (_PICK(port, \
> > >+  [PORT_A] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \
> > >+  [PORT_B] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \
> > >+  [PORT_TC1] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \
> > >+  [PORT_TC2] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2, \
> > >+  [PORT_TC3] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3, \
> > >+  [PORT_TC4] =
> > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4) + ((lane) *
> > >+4))
> > >+
> >
> > stray newline
> >
> > >+#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
> > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane))
> >
> >
> > one of the reasons _PICK_EVEN_2RANGES() was added. We usually have 2
> > ranges for the ports due to the combo vs tc distinction.
> >
> > #define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
> > _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1,
> >
> >  _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A,
> >
> >  _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B,
> >
> >  _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1,
> >
> >  _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2))
> >
> Btw, are we missing something from upstream? It seems that this is not
> compiling properly with upstream kernel?

Never mind this comment. I sorted this one out.

> 
> Thanks for the review and comments! I'm working on the rest of these fixes.
> 
> -Mika-
> >
> > >+#define  XELPDP_PORT_M2P_TRANSACTION_PENDING
> > REG_BIT(31)
> >
> >^ wrong amount of spaces. See the example on top of
> > i915_reg.h
> >
> > here and everywhere in this file
> >
> > >+#define  XELPDP_PORT_M2P_COMMAND_TYPE_MASK
> > REG_GENMASK(30, 27)
> > >+#define  XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED
> > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1)
> > >+#define  XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED
> > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2)
> > >+#define  XELPDP_PORT_M2P_COMMAND_READ
> > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3)
> > >+#define  XELPDP_PORT_M2P_DATA_MASK
> > REG_GENMASK(23, 16)
> > >+#define  XELPDP_PORT_M2P_DATA(val)
> > REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val)
> > >+#define  XELPDP_PORT_M2P_TRANSACTION_RESETREG_BIT(15)
> > >+#define  XELPDP_PORT_M2P_ADDRESS_MASK
> > REG_GENMASK(11, 0)
> > >+#define  XELPDP_PORT_M2P_ADDRESS(val)
> > REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val)
> > >+
> > >+#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane)
> > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) + 8)
> > >+#define  XELPDP_PORT_P2M_RESPONSE_READY
> > REG_BIT(31)
> > >+#define  XELPDP_PORT_P2M_COMMAND_TYPE_MASK
> > REG_GENMASK(30, 27)
> > >+#define  XELPDP_PORT_P2M_COMMAND_READ_ACK 0x4
> > >+#define  XELPDP_PORT_P2M_COMMAND_WRITE_ACK0x5
> > >+#define  

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

[Christian König]

Am 08.03.23 um 03:26 schrieb Steven Rostedt:

On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt  wrote:


Looks like there was a lock possibly used after free. But as commit
9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
workers") changed a lot of this code, I figured it may be the culprit.

If I bothered to look at the second warning after this one (I usually stop
after the first), it appears to state there was a use after free issue.


Yeah, that looks like the reference count was somehow messed up.

What test case/environment do you run to trigger this?

Thanks for the notice,
Christian.



[  206.692285] [ cut here ]
[  206.706333] refcount_t: underflow; use-after-free.
[  206.720577] WARNING: CPU: 0 PID: 332 at lib/refcount.c:28 
refcount_warn_saturate+0xb6/0xfc
[  206.735810] Modules linked in:
[  206.749493] CPU: 0 PID: 332 Comm: kworker/0:13H Tainted: GW  
6.3.0-rc1-test-1-ga98bd42762ed-dirty #965
[  206.765833] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.0-debian-1.16.0-5 04/01/2014
[  206.781767] Workqueue: ttm ttm_bo_delayed_delete
[  206.796500] EIP: refcount_warn_saturate+0xb6/0xfc
[  206.811121] Code: 68 50 1c 0d cf e8 66 b3 a9 ff 0f 0b 58 c9 c3 90 80 3d 57 c6 38 
cf 00 75 8a c6 05 57 c6 38 cf 01 68 7c 1c 0d cf e8 46 b3 a9 ff <0f> 0b 59 c9 c3 
80 3d 55 c6 38 cf 00 0f 85 67 ff ff ff c6 05 55 c6
[  206.844560] EAX: 0026 EBX: c2d5f150 ECX: c3ae5e40 EDX: 0002
[  206.862109] ESI: c2d5f0bc EDI: f6f91200 EBP: c3ae5f18 ESP: c3ae5f14
[  206.878773] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 00010246
[  206.895665] CR0: 80050033 CR2: ff9ff000 CR3: 0f512000 CR4: 00150ef0
[  206.912303] Call Trace:
[  206.927940]  ttm_bo_delayed_delete+0x8c/0x94
[  206.944179]  process_one_work+0x21a/0x538
[  206.960605]  worker_thread+0x146/0x398
[  206.976839]  kthread+0xea/0x10c
[  206.992696]  ? process_one_work+0x538/0x538
[  207.008827]  ? kthread_complete_and_exit+0x1c/0x1c
[  207.025150]  ret_from_fork+0x1c/0x28
[  207.041307] irq event stamp: 4219
[  207.056883] hardirqs last  enabled at (4219): [] 
_raw_spin_unlock_irqrestore+0x2d/0x58
[  207.074298] hardirqs last disabled at (4218): [] 
kvfree_call_rcu+0x155/0x2ec
[  207.091461] softirqs last  enabled at (3570): [] 
__do_softirq+0x2f3/0x48b
[  207.107979] softirqs last disabled at (3565): [] 
call_on_stack+0x45/0x4c
[  207.123827] ---[ end trace  ]---


-- Steve

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Use common freq functions with sysfs

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: Use common freq functions with sysfs
URL   : https://patchwork.freedesktop.org/series/114814/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114814v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 35)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-kbl-soraka/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_114814v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka:  NOTRUN -> [DMESG-WARN][4] ([i915#1982])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-kbl-soraka/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [ABORT][6] ([i915#7911] / [i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][7] ([i915#7913])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][9] -> [DMESG-FAIL][10] ([i915#7699])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271]) +16 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [DMESG-FAIL][12] ([i915#4258]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [DMESG-WARN][14] ([i915#8073]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [ABORT][16] ([i915#4983] / [i915#7694] / [i915#7911] 
/ [i915#7981]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-5:  [FAIL][18] ([fdo#103375]) -> [PASS][19] +3 similar 
issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][20] ([i915#6367] / [i915#7913]) -> 
[DMESG-FAIL][21] ([i915#6997] / [i915#7913])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114814v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  

Re: [Intel-gfx] [PATCH 3/3] drm/i915/pmu: Use common freq functions with sysfs

[Belgaumkar, Vinay]

On 3/7/2023 9:33 PM, Ashutosh Dixit wrote:

Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)


For the requested_freq, we read it only if actual_freq is zero below 
(meaning, GT is in C6). So then what is the point of reading it without 
a force wake? It will also be zero, correct?


Thanks,

Vinay.


missing support for older generation (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU code future proof where sometimes code has been updated for
sysfs and PMU has been missed.

Signed-off-by: Ashutosh Dixit 
---
  drivers/gpu/drm/i915/gt/intel_rps.c | 10 --
  drivers/gpu/drm/i915/gt/intel_rps.h |  1 -
  drivers/gpu/drm/i915/i915_pmu.c | 10 --
  3 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 49df31927c0e..b03bfbe7ee23 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2046,16 +2046,6 @@ void intel_rps_sanitize(struct intel_rps *rps)
rps_disable_interrupts(rps);
  }
  
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)

-{
-   struct drm_i915_private *i915 = rps_to_i915(rps);
-   i915_reg_t rpstat;
-
-   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
-
-   return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
-}
-
  u32 intel_rps_read_rpstat(struct intel_rps *rps)
  {
struct drm_i915_private *i915 = rps_to_i915(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index a990f985ab23..60ae27679011 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -53,7 +53,6 @@ u32 intel_rps_get_rp1_frequency(struct intel_rps *rps);
  u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
  u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
  u32 intel_rps_read_rpstat(struct intel_rps *rps);
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps);
  void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps 
*caps);
  void intel_rps_raise_unslice(struct intel_rps *rps);
  void intel_rps_lower_unslice(struct intel_rps *rps);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index a76c5ce9513d..1a4c9fed257c 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -392,14 +392,12 @@ frequency_sample(struct intel_gt *gt, unsigned int 
period_ns)
 * case we assume the system is running at the intended
 * frequency. Fortunately, the read should rarely fail!
 */
-   val = intel_rps_read_rpstat_fw(rps);
-   if (val)
-   val = intel_rps_get_cagf(rps, val);
-   else
-   val = rps->cur_freq;
+   val = intel_rps_read_actual_frequency_fw(rps);
+   if (!val)
+   val = intel_rps_get_requested_frequency_fw(rps),
  
  		add_sample_mult(>sample[__I915_SAMPLE_FREQ_ACT],

-   intel_gpu_freq(rps, val), period_ns / 1000);
+   val, period_ns / 1000);
}
  
  	if (pmu->enable & config_mask(I915_PMU_REQUESTED_FREQUENCY)) {

Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Use correct requested freq for SLPC

[Dixit, Ashutosh]

On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote:
>

Hi Tvrtko,

> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from
>
> Would it be more accurate to say 'SLPC does not use rps->cur_freq' rather
> than it not using struct intel_rps?

No actually SLPC maintains a separate 'struct intel_guc_slpc' and does not
use 'struct intel_rps' at all so all of 'struct intel_rps' is 0.

> Fixes: / stable ? CI chances of catching this?

Same issue as Patch 1, I have answered this there.

> > GEN6_RPNSWREQ for SLPC. See intel_rps_get_requested_frequency.
> >
> > Bspec: 52745
> >
> > Signed-off-by: Ashutosh Dixit 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 9 +++--
> >   1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index f0a1e36915b8..5ee836610801 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -394,8 +394,13 @@ frequency_sample(struct intel_gt *gt, unsigned int 
> > period_ns)
> >  * frequency. Fortunately, the read should rarely fail!
> >  */
> > val = intel_rps_get_cagf(rps, intel_rps_read_rpstat_fw(rps));
> > -   if (!val)
> > -   val = rps->cur_freq;
> > +   if (!val) {
> > +   if (intel_uc_uses_guc_slpc(>uc))
> > +   val = intel_rps_read_punit_req(rps) >>
> > +   GEN9_SW_REQ_UNSLICE_RATIO_SHIFT;
> > +   else
> > +   val = rps->cur_freq;
> > +   }
>
> That's a bunch of duplication from intel_rps.c so perhaps the appropriate
> helpers should be exported (some way) from there.

This is also addressed in the new series:

https://patchwork.freedesktop.org/series/114814/

> > add_sample_mult(>sample[__I915_SAMPLE_FREQ_ACT],
> > intel_gpu_freq(rps, val), period_ns / 1000);

Thanks.
--
Ashutosh

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use only freq bits for falling back to requested freq

[Dixit, Ashutosh]

On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote:
>

Hi Tvrtko,

> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > On newer generations, the GEN12_RPSTAT1 register contains more than freq
> > information, e.g. see GEN12_VOLTAGE_MASK. Therefore use only the freq bits
> > to decide whether to fall back to requested freq.
>

> CI is not catching the problem?

This is because as we know PMU freq sampling happens only when gt is
unparked (actively processing requests) so it is highly unlikely that gt
will be in rc6 when it might have to fall back to requested freq (I checked
this and it seems it is only at the end of the workload that we see it
entering the fallback code path). Deleting the fallback path completely
will not make much difference to the output and is an option too. Anyway I
have retained it for now.

> Could you find an appropriate Fixes: tag please? If it can affects a
> platform out of force probe then cc: stable to.

Cc stable is anyway not needed because affected platforms (DG1 onwards) are
under force probe. Also because the issue does not affect real metrics (as
mentioned above) as well as because it is a really a missing patch rather
than a broken previous patch I am skipping the Fixes tag.

> > Signed-off-by: Ashutosh Dixit 
> > ---
> >   drivers/gpu/drm/i915/i915_pmu.c | 6 ++
> >   1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 52531ab28c5f..f0a1e36915b8 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -393,10 +393,8 @@ frequency_sample(struct intel_gt *gt, unsigned int 
> > period_ns)
> >  * case we assume the system is running at the intended
> >  * frequency. Fortunately, the read should rarely fail!
> >  */
> > -   val = intel_rps_read_rpstat_fw(rps);
> > -   if (val)
> > -   val = intel_rps_get_cagf(rps, val);
> > -   else
> > +   val = intel_rps_get_cagf(rps, intel_rps_read_rpstat_fw(rps));
>
> Will this work with gen5_invert_freq as called by intel_rps_get_cagf?

PMU has ever only supported Gen6+. See intel_rps_read_rpstat_fw (Gen5 does
not have a GEN6_RPSTAT1 register) as well as 01b8c2e60e96.

More importantly PMU was missing support for MTL. It is to avoid these
kinds of issues I have submitted a new series with a different approach
which should now take care of both MTL+ as well as Gen5-:

https://patchwork.freedesktop.org/series/114814/

> > +   if (!val)
> > val = rps->cur_freq;
> > add_sample_mult(>sample[__I915_SAMPLE_FREQ_ACT],

Thanks.
--
Ashutosh

[Intel-gfx] [PATCH 3/3] drm/i915/pmu: Use common freq functions with sysfs

[Ashutosh Dixit]

Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generation (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU code future proof where sometimes code has been updated for
sysfs and PMU has been missed.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 10 --
 drivers/gpu/drm/i915/gt/intel_rps.h |  1 -
 drivers/gpu/drm/i915/i915_pmu.c | 10 --
 3 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 49df31927c0e..b03bfbe7ee23 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2046,16 +2046,6 @@ void intel_rps_sanitize(struct intel_rps *rps)
rps_disable_interrupts(rps);
 }
 
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
-{
-   struct drm_i915_private *i915 = rps_to_i915(rps);
-   i915_reg_t rpstat;
-
-   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
-
-   return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
-}
-
 u32 intel_rps_read_rpstat(struct intel_rps *rps)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index a990f985ab23..60ae27679011 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -53,7 +53,6 @@ u32 intel_rps_get_rp1_frequency(struct intel_rps *rps);
 u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
 u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
 u32 intel_rps_read_rpstat(struct intel_rps *rps);
-u32 intel_rps_read_rpstat_fw(struct intel_rps *rps);
 void gen6_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps 
*caps);
 void intel_rps_raise_unslice(struct intel_rps *rps);
 void intel_rps_lower_unslice(struct intel_rps *rps);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index a76c5ce9513d..1a4c9fed257c 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -392,14 +392,12 @@ frequency_sample(struct intel_gt *gt, unsigned int 
period_ns)
 * case we assume the system is running at the intended
 * frequency. Fortunately, the read should rarely fail!
 */
-   val = intel_rps_read_rpstat_fw(rps);
-   if (val)
-   val = intel_rps_get_cagf(rps, val);
-   else
-   val = rps->cur_freq;
+   val = intel_rps_read_actual_frequency_fw(rps);
+   if (!val)
+   val = intel_rps_get_requested_frequency_fw(rps),
 
add_sample_mult(>sample[__I915_SAMPLE_FREQ_ACT],
-   intel_gpu_freq(rps, val), period_ns / 1000);
+   val, period_ns / 1000);
}
 
if (pmu->enable & config_mask(I915_PMU_REQUESTED_FREQUENCY)) {
-- 
2.38.0

[Intel-gfx] [PATCH 0/3] drm/i915/pmu: Use common freq functions with sysfs

[Ashutosh Dixit]

Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generations (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU code future proof where sometimes code has been updated for
sysfs and PMU has been missed.

Ashutosh Dixit (3):
  drm/i915/rps: Expose read_actual_frequency_fw for PMU
  drm/i915/rps: Expose get_requested_frequency_fw for PMU
  drm/i915/pmu: Use common freq functions with sysfs

 drivers/gpu/drm/i915/gt/intel_rps.c | 68 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  4 +-
 drivers/gpu/drm/i915/i915_pmu.c | 10 ++---
 3 files changed, 56 insertions(+), 26 deletions(-)

-- 
2.38.0

[Intel-gfx] [PATCH 2/3] drm/i915/rps: Expose get_requested_frequency_fw for PMU

[Ashutosh Dixit]

Expose intel_rps_get_requested_frequency_fw to read the requested freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support both host
turbo (rps) and slpc which was previously missed due to the non-use of
common functions across sysfs and PMU.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 22 +++---
 drivers/gpu/drm/i915/gt/intel_rps.h |  2 +-
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 0a8e24bcb874..49df31927c0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2154,7 +2154,7 @@ u32 intel_rps_read_actual_frequency_fw(struct intel_rps 
*rps)
return freq;
 }
 
-u32 intel_rps_read_punit_req(struct intel_rps *rps)
+static u32 intel_rps_read_punit_req(struct intel_rps *rps, bool take_fw)
 {
struct intel_uncore *uncore = rps_to_uncore(rps);
struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
@@ -2162,7 +2162,8 @@ u32 intel_rps_read_punit_req(struct intel_rps *rps)
u32 freq = 0;
 
with_intel_runtime_pm_if_in_use(rpm, wakeref)
-   freq = intel_uncore_read(uncore, GEN6_RPNSWREQ);
+   freq = take_fw ? intel_uncore_read(uncore, GEN6_RPNSWREQ) :
+   intel_uncore_read_fw(uncore, GEN6_RPNSWREQ);
 
return freq;
 }
@@ -2176,7 +2177,7 @@ static u32 intel_rps_get_req(u32 pureq)
 
 u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps)
 {
-   u32 freq = intel_rps_get_req(intel_rps_read_punit_req(rps));
+   u32 freq = intel_rps_get_req(intel_rps_read_punit_req(rps, true));
 
return intel_gpu_freq(rps, freq);
 }
@@ -2189,6 +2190,21 @@ u32 intel_rps_get_requested_frequency(struct intel_rps 
*rps)
return intel_gpu_freq(rps, rps->cur_freq);
 }
 
+static u32 intel_rps_read_punit_req_frequency_fw(struct intel_rps *rps)
+{
+   u32 freq = intel_rps_get_req(intel_rps_read_punit_req(rps, false));
+
+   return intel_gpu_freq(rps, freq);
+}
+
+u32 intel_rps_get_requested_frequency_fw(struct intel_rps *rps)
+{
+   if (rps_uses_slpc(rps))
+   return intel_rps_read_punit_req_frequency_fw(rps);
+   else
+   return intel_gpu_freq(rps, rps->cur_freq);
+}
+
 u32 intel_rps_get_max_frequency(struct intel_rps *rps)
 {
struct intel_guc_slpc *slpc = rps_to_slpc(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 63511b826a97..a990f985ab23 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -41,6 +41,7 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat1);
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
 u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
+u32 intel_rps_get_requested_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_min_frequency(struct intel_rps *rps);
 u32 intel_rps_get_min_raw_freq(struct intel_rps *rps);
 int intel_rps_set_min_frequency(struct intel_rps *rps, u32 val);
@@ -50,7 +51,6 @@ int intel_rps_set_max_frequency(struct intel_rps *rps, u32 
val);
 u32 intel_rps_get_rp0_frequency(struct intel_rps *rps);
 u32 intel_rps_get_rp1_frequency(struct intel_rps *rps);
 u32 intel_rps_get_rpn_frequency(struct intel_rps *rps);
-u32 intel_rps_read_punit_req(struct intel_rps *rps);
 u32 intel_rps_read_punit_req_frequency(struct intel_rps *rps);
 u32 intel_rps_read_rpstat(struct intel_rps *rps);
 u32 intel_rps_read_rpstat_fw(struct intel_rps *rps);
-- 
2.38.0

[Intel-gfx] [PATCH 1/3] drm/i915/rps: Expose read_actual_frequency_fw for PMU

[Ashutosh Dixit]

Expose intel_rps_read_actual_frequency_fw to read the actual/granted freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support MTL as well
as older generations (before Gen6) which were previously missed due to the
non-use of common functions across sysfs and PMU.

Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 36 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  1 +
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 4d0dc9de23f9..0a8e24bcb874 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2089,10 +2089,11 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 
rpstat)
return cagf;
 }
 
-static u32 read_cagf(struct intel_rps *rps)
+static u32 __read_cagf(struct intel_rps *rps, bool take_fw)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
struct intel_uncore *uncore = rps_to_uncore(rps);
+   i915_reg_t r = INVALID_MMIO_REG;
u32 freq;
 
/*
@@ -2100,22 +2101,30 @@ static u32 read_cagf(struct intel_rps *rps)
 * registers will return 0 freq when GT is in RC6
 */
if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   freq = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
+   r = MTL_MIRROR_TARGET_WP1;
} else if (GRAPHICS_VER(i915) >= 12) {
-   freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
+   r = GEN12_RPSTAT1;
} else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
vlv_punit_put(i915);
+   goto exit;
} else if (GRAPHICS_VER(i915) >= 6) {
-   freq = intel_uncore_read(uncore, GEN6_RPSTAT1);
+   r = GEN6_RPSTAT1;
} else {
-   freq = intel_uncore_read(uncore, MEMSTAT_ILK);
+   r = MEMSTAT_ILK;
}
 
+   freq = take_fw ? intel_uncore_read(uncore, r) : 
intel_uncore_read_fw(uncore, r);
+exit:
return intel_rps_get_cagf(rps, freq);
 }
 
+static u32 read_cagf(struct intel_rps *rps)
+{
+   return __read_cagf(rps, true);
+}
+
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps)
 {
struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
@@ -2128,6 +2137,23 @@ u32 intel_rps_read_actual_frequency(struct intel_rps 
*rps)
return freq;
 }
 
+static u32 read_cagf_fw(struct intel_rps *rps)
+{
+   return __read_cagf(rps, false);
+}
+
+u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps)
+{
+   struct intel_runtime_pm *rpm = rps_to_uncore(rps)->rpm;
+   intel_wakeref_t wakeref;
+   u32 freq = 0;
+
+   with_intel_runtime_pm_if_in_use(rpm, wakeref)
+   freq = intel_gpu_freq(rps, read_cagf_fw(rps));
+
+   return freq;
+}
+
 u32 intel_rps_read_punit_req(struct intel_rps *rps)
 {
struct intel_uncore *uncore = rps_to_uncore(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index c622962c6bef..63511b826a97 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -39,6 +39,7 @@ int intel_gpu_freq(struct intel_rps *rps, int val);
 int intel_freq_opcode(struct intel_rps *rps, int val);
 u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat1);
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
+u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
 u32 intel_rps_get_min_frequency(struct intel_rps *rps);
 u32 intel_rps_get_min_raw_freq(struct intel_rps *rps);
-- 
2.38.0

Re: [Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

[Steven Rostedt]

On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt  wrote:

> Looks like there was a lock possibly used after free. But as commit
> 9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
> workers") changed a lot of this code, I figured it may be the culprit.

If I bothered to look at the second warning after this one (I usually stop
after the first), it appears to state there was a use after free issue.

[  206.692285] [ cut here ]
[  206.706333] refcount_t: underflow; use-after-free.
[  206.720577] WARNING: CPU: 0 PID: 332 at lib/refcount.c:28 
refcount_warn_saturate+0xb6/0xfc
[  206.735810] Modules linked in:
[  206.749493] CPU: 0 PID: 332 Comm: kworker/0:13H Tainted: GW  
6.3.0-rc1-test-1-ga98bd42762ed-dirty #965
[  206.765833] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.0-debian-1.16.0-5 04/01/2014
[  206.781767] Workqueue: ttm ttm_bo_delayed_delete
[  206.796500] EIP: refcount_warn_saturate+0xb6/0xfc
[  206.811121] Code: 68 50 1c 0d cf e8 66 b3 a9 ff 0f 0b 58 c9 c3 90 80 3d 57 
c6 38 cf 00 75 8a c6 05 57 c6 38 cf 01 68 7c 1c 0d cf e8 46 b3 a9 ff <0f> 0b 59 
c9 c3 80 3d 55 c6 38 cf 00 0f 85 67 ff ff ff c6 05 55 c6
[  206.844560] EAX: 0026 EBX: c2d5f150 ECX: c3ae5e40 EDX: 0002
[  206.862109] ESI: c2d5f0bc EDI: f6f91200 EBP: c3ae5f18 ESP: c3ae5f14
[  206.878773] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 00010246
[  206.895665] CR0: 80050033 CR2: ff9ff000 CR3: 0f512000 CR4: 00150ef0
[  206.912303] Call Trace:
[  206.927940]  ttm_bo_delayed_delete+0x8c/0x94
[  206.944179]  process_one_work+0x21a/0x538
[  206.960605]  worker_thread+0x146/0x398
[  206.976839]  kthread+0xea/0x10c
[  206.992696]  ? process_one_work+0x538/0x538
[  207.008827]  ? kthread_complete_and_exit+0x1c/0x1c
[  207.025150]  ret_from_fork+0x1c/0x28
[  207.041307] irq event stamp: 4219
[  207.056883] hardirqs last  enabled at (4219): [] 
_raw_spin_unlock_irqrestore+0x2d/0x58
[  207.074298] hardirqs last disabled at (4218): [] 
kvfree_call_rcu+0x155/0x2ec
[  207.091461] softirqs last  enabled at (3570): [] 
__do_softirq+0x2f3/0x48b
[  207.107979] softirqs last disabled at (3565): [] 
call_on_stack+0x45/0x4c
[  207.123827] ---[ end trace  ]---


-- Steve

[Intel-gfx] [BUG 6.3-rc1] Bad lock in ttm_bo_delayed_delete()

[Steven Rostedt]

In a report for a regression in my code, I tried to run v6.3-rc1 through my
tests. It crashed at boot up on my first test (my start up tests do take a
long time, hence the 206 seconds of boot!).

[  206.238782] [ cut here ]
[  206.277786] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
[  206.277946] WARNING: CPU: 0 PID: 332 at kernel/locking/mutex.c:582 
__ww_mutex_lock.constprop.0+0x566/0xfec
[  206.313338] Modules linked in:
[  206.324732] CPU: 0 PID: 332 Comm: kworker/0:13H Not tainted 
6.3.0-rc1-test-1-ga98bd42762ed-dirty #965
[  206.338273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.0-debian-1.16.0-5 04/01/2014
[  206.353596] Workqueue: ttm ttm_bo_delayed_delete
[  206.370520] EIP: __ww_mutex_lock.constprop.0+0x566/0xfec
[  206.382855] Code: e8 ab 59 95 ff 85 c0 0f 84 25 fb ff ff 8b 0d 58 c0 3b cf 
85 c9 0f 85 17 fb ff ff 68 e0 8d 07 cf 68 2b ac 05 cf e8 e6 e6 3f ff <0f> 0b 58 
5a e9 ff fa ff ff e8 78 59 95 ff 85 c0 74 0e 8b 0d 58 c0
[  206.411247] EAX: 0028 EBX:  ECX: c3ae5dd8 EDX: 0002
[  206.425193] ESI:  EDI: c2d5f0bc EBP: c3ae5f00 ESP: c3ae5eac
[  206.439236] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 00010246
[  206.453597] CR0: 80050033 CR2: ff9ff000 CR3: 0f512000 CR4: 00150ef0
[  206.467841] Call Trace:
[  206.481059]  ? ttm_bo_delayed_delete+0x30/0x94
[  206.494980]  ww_mutex_lock+0x32/0x94
[  206.508699]  ttm_bo_delayed_delete+0x30/0x94
[  206.522371]  process_one_work+0x21a/0x538
[  206.536306]  worker_thread+0x146/0x398
[  206.549860]  kthread+0xea/0x10c
[  206.563141]  ? process_one_work+0x538/0x538
[  206.576835]  ? kthread_complete_and_exit+0x1c/0x1c
[  206.590652]  ret_from_fork+0x1c/0x28
[  206.604522] irq event stamp: 4219
[  206.617852] hardirqs last  enabled at (4219): [] 
_raw_spin_unlock_irqrestore+0x2d/0x58
[  206.633077] hardirqs last disabled at (4218): [] 
kvfree_call_rcu+0x155/0x2ec
[  206.648161] softirqs last  enabled at (3570): [] 
__do_softirq+0x2f3/0x48b
[  206.663025] softirqs last disabled at (3565): [] 
call_on_stack+0x45/0x4c
[  206.678065] ---[ end trace  ]---

Looks like there was a lock possibly used after free. But as commit
9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
workers") changed a lot of this code, I figured it may be the culprit.

-- Steve

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915/perf: Add engine class instance parameters to perf

[Dixit, Ashutosh]

On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote:
>

Hi Umesh,

> + /* Defaults when class:instance is not passed */
> + class = I915_ENGINE_CLASS_RENDER;
> + instance = 0;
> +
>   for (i = 0; i < n_props; i++) {
>   u64 oa_period, oa_freq_hz;
>   u64 id, value;
> @@ -4174,7 +4156,13 @@ static int read_properties_unlocked(struct i915_perf 
> *perf,
>   }
>   props->poll_oa_period = value;
>   break;
> - case DRM_I915_PERF_PROP_MAX:
> + case DRM_I915_PERF_PROP_OA_ENGINE_CLASS:
> + class = (u8)value;
> + break;
> + case DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE:
> + instance = (u8)value;
> + break;

I am wondering since this is uapi we should make it robust. So if the user
passes either class or instance he must pass both and we should check for
that. If only one is passed we should not implicitly assume the other as we
are doing here (if only instance is passed here we will assume RCS and if
only class is passed we will assume instance 0). I think making this
explicit will avoid confusion later. Thoughts?

> + default:
>   MISSING_CASE(id);
>   return -EINVAL;
>   }
> @@ -4182,6 +4170,21 @@ static int read_properties_unlocked(struct i915_perf 
> *perf,
>   uprop += 2;
>   }
>
> + props->engine = intel_engine_lookup_user(perf->i915, class, instance);
> + if (!props->engine) {
> + drm_dbg(>i915->drm,
> + "OA engine class and instance invalid %d:%d\n",
> + class, instance);
> + return -EINVAL;
> + }

Thanks.
--
Ashutosh

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix a couple of issues with the GSC worker timing (rev2)

[Patchwork]

== Series Details ==

Series: Fix a couple of issues with the GSC worker timing (rev2)
URL   : https://patchwork.freedesktop.org/series/114306/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114306v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 35)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_114306v2 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_114306v2/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_114306v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][3] ([i915#7913])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_lrc:
- bat-rpls-1: [PASS][4] -> [INCOMPLETE][5] ([i915#4983])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html

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

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][7] -> [DMESG-WARN][8] ([i915#7699])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][9] ([fdo#109271]) +16 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [DMESG-WARN][10] ([i915#8073]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-5:  [FAIL][12] ([fdo#103375]) -> [PASS][13] +3 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html

  
 Warnings 

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][14] ([i915#6367] / [i915#7913]) -> 
[DMESG-FAIL][15] ([i915#6997] / [i915#7913])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-2/igt@i915_selftest@l...@slpc.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114306v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073


Build changes
-

  * Linux: CI_DRM_12827 -> Patchwork_114306v2

  CI-20190529: 20190529
  CI_DRM_12827: b794b8d84dc0470ee58467386f41870e81a86580 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7183: 3434cef8be4e487644a740039ad15123cd094526 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_114306v2: b794b8d84dc0470ee58467386f41870e81a86580 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

0358da0eee64 drm/i915/gsc: Fix race between HW init and GSC FW 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix a couple of issues with the GSC worker timing (rev2)

[Patchwork]

== Series Details ==

Series: Fix a couple of issues with the GSC worker timing (rev2)
URL   : https://patchwork.freedesktop.org/series/114306/
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/dmc: Load DMC on MTL (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dmc: Load DMC on MTL (rev2)
URL   : https://patchwork.freedesktop.org/series/114576/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114576v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (35 -> 35)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Known issues


  Here are the changes found in Patchwork_114576v2 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_114576v2/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_114576v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_pm_rpm@basic-rte:
- bat-adln-1: [PASS][3] -> [ABORT][4] ([i915#7977])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-adln-1/igt@i915_pm_...@basic-rte.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-adln-1/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#7913])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][7] ([i915#7913])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_mocs:
- bat-dg1-5:  [PASS][10] -> [ABORT][11] ([i915#4983])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-dg1-5/igt@i915_selftest@live@gt_mocs.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-dg1-5/igt@i915_selftest@live@gt_mocs.html

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

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][13] -> [DMESG-WARN][14] ([i915#7699])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@reset:
- bat-rpls-2: [PASS][15] -> [ABORT][16] ([i915#4983] / [i915#7913])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-rpls-2/igt@i915_selftest@l...@reset.html
- bat-rpls-1: NOTRUN -> [ABORT][17] ([i915#4983])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][18] ([fdo#109271]) +16 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [DMESG-WARN][19] ([i915#8073]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [ABORT][21] ([i915#4983] / [i915#7694] / [i915#7911] 
/ [i915#7981]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12827/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v2/bat-rpls-1/igt@i915_selftest@l...@requests.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 5.15-stable tree

[Patchwork]

== Series Details ==

Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has 
been added to the 5.15-stable tree
URL   : https://patchwork.freedesktop.org/series/114787/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114787/revisions/1/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gsc: flush the GSC worker before wedging on unload

[Teres Alexis, Alan Previn]

On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> If we unload the driver and wedge before the GSC worker is complete,
> the worker will hit an error on its submission to the GSC engine and
> then exit. This is hard to hit for a user, but it is reproducible
> with skipping selftests. The error is handled gracefully by the
> worker, so there are no functional issues, but we still end up with
> an error message in dmesg, which is something we want to avoid as
> this is a supported scenario. We could modify the worker to better
> handle a wedging occurring during its execution, but that gets
> complicated for a couple of reasons:
> - We do want the error on runtime wedging, because there are
>   implications for subsystems outside of GT (i.e., PXP, HDCP), it's
>   only the error on driver unload that we want to silence.
> - The worker is responsible for multiple submissions (GSC FW load,
>   HuC auth, SW proxy), so all of those will have to be adapted to
>   handle the wedged_on_fini scenario.
> Therefore, it's much simpler to just wait for the worker to be done
> before wedging on driver removal, also considering that the worker
> will likely already be idle in the great majority of non-selftest
> scenarios.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> 
alan:snip
> 
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -784,6 +784,29 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
>   intel_rps_driver_unregister(>rps);
>   intel_gsc_fini(>gsc);
>  
> + /*
> +  * If we unload the driver and wedge before the GSC worker is complete,
alan:snip
> +  * scenarios.
> +  */
> + intel_gsc_uc_flush_work(>uc.gsc);

alan: nit: from a code readiblity, having intel_gsc_fini before 
intel_gsc_uc_flush_work almost reads
as if code should have been inverted eventhough we know that the former is for 
the old mei-comp based
framework and the latter is based on the new gsc-cs based framework. i cant 
think of how else to resolve
this other unintrusively other than adding a comment. Other than that, also 
considering we've had offline
testing already verify this and the next patch too, LGTM:
Reviewed-by: Alan Previn 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 6.1-stable tree

[Patchwork]

== Series Details ==

Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has 
been added to the 6.1-stable tree
URL   : https://patchwork.freedesktop.org/series/114785/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114785/revisions/1/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has been added to the 6.1-stable tree

[Patchwork]

== Series Details ==

Series: Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has 
been added to the 6.1-stable tree
URL   : https://patchwork.freedesktop.org/series/114784/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114784/revisions/1/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Don't switch to TPS1 when 
disabling DP_TP_CTL (rev2)
URL   : https://patchwork.freedesktop.org/series/114011/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114011/revisions/2/mbox/ not 
applied
Applying: drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_ddi.c
M   drivers/gpu/drm/i915/display/intel_fdi.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_fdi.c
Auto-merging drivers/gpu/drm/i915/display/intel_ddi.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_ddi.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] [PATCH 4/4] drm/i915/opregion: Register/unregister opregion on platforms without display

[Imre Deak]

On Tue, Mar 07, 2023 at 10:50:49AM +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2023, Imre Deak  wrote:
> > Call the opregion register/unregister functions during driver
> > loading/unloading on !HAS_DISPLAY platforms. These functions will send
> > the opregion adapter power state notifications which is required on all
> > platforms (similarly how this is sent during runtime and system
> > suspend/resume). Skip registering the ACPI video notifier callback on
> > !HAS_DISPLAY, where the corresponding video extensions are not
> > supported.
> 
> I think the direction should be towards better separation of display
> code, and this patch is counter productive. Basically we shouldn't
> require calling display functions on !HAS_DISPLAY, and the early return
> is what we should do.

Ok, missed this point.

> This, in turn, means we probably need to handle opregion differently. :(
> 
> Dunno, maybe we need to move opregion under soc/ and have parts called
> by high level driver code, and some other parts from display code.

Yes, I think we can be sure that some part of the opregion i/f is not
display-only (VRAM SR), so makes sense, though it's a bigger change. I think
the following instead of patch 4 would be more in line with what you said
above:

diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index b7973a05d022d..abfe1615afb06 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1155,8 +1155,6 @@ void intel_opregion_register(struct drm_i915_private 
*i915)
intel_opregion_video_event;
register_acpi_notifier(>acpi_notifier);
}
-
-   intel_opregion_resume(i915);
 }
 
 static void intel_opregion_resume_display(struct drm_i915_private *i915)
@@ -1228,8 +1226,6 @@ void intel_opregion_unregister(struct drm_i915_private 
*i915)
 {
struct intel_opregion *opregion = >display.opregion;
 
-   intel_opregion_suspend(i915, PCI_D1);
-
if (!opregion->header)
return;
 
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 8f5e3ded52233..c554495d4f8e1 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -633,6 +633,8 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
 
intel_display_driver_register(dev_priv);
 
+   intel_opregion_resume(i915);
+
intel_power_domains_enable(dev_priv);
intel_runtime_pm_enable(_priv->runtime_pm);
 
@@ -658,6 +660,8 @@ static void i915_driver_unregister(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_disable(_priv->runtime_pm);
intel_power_domains_disable(dev_priv);
 
+   intel_opregion_suspend(i915, PCI_D1);
+
intel_display_driver_unregister(dev_priv);
 
intel_pxp_fini(dev_priv);

> BR,
> Jani.
> 
> 
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  | 11 +++
> >  drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
> >  2 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 7827ef3e2d1e6..467f6e2376057 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8882,11 +8882,12 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
> >  
> >  void intel_display_driver_register(struct drm_i915_private *i915)
> >  {
> > -   if (!HAS_DISPLAY(i915))
> > -   return;
> > -
> > /* Must be done after probing outputs */
> > intel_opregion_register(i915);
> > +
> > +   if (!HAS_DISPLAY(i915))
> > +   return;
> > +
> > intel_acpi_video_register(i915);
> >  
> > intel_audio_init(i915);
> > @@ -8914,7 +8915,7 @@ void intel_display_driver_register(struct 
> > drm_i915_private *i915)
> >  void intel_display_driver_unregister(struct drm_i915_private *i915)
> >  {
> > if (!HAS_DISPLAY(i915))
> > -   return;
> > +   goto unregister_opregion;
> >  
> > intel_fbdev_unregister(i915);
> > intel_audio_deinit(i915);
> > @@ -8928,6 +8929,8 @@ void intel_display_driver_unregister(struct 
> > drm_i915_private *i915)
> > drm_atomic_helper_shutdown(>drm);
> >  
> > acpi_video_unregister();
> > +
> > +unregister_opregion:
> > intel_opregion_unregister(i915);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
> > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > index b7973a05d022d..37098e7f607e6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > @@ -1150,7 +1150,7 @@ void intel_opregion_register(struct drm_i915_private 
> > *i915)
> > if (!opregion->header)
> > return;
> >  
> > -   if (opregion->acpi) {
> > +   if (HAS_DISPLAY(i915) && 

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has been added to the 6.2-stable tree

[Patchwork]

== Series Details ==

Series: Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has 
been added to the 6.2-stable tree
URL   : https://patchwork.freedesktop.org/series/114782/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114782/revisions/1/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 6.2-stable tree

[Patchwork]

== Series Details ==

Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has 
been added to the 6.2-stable tree
URL   : https://patchwork.freedesktop.org/series/114781/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/114781/revisions/1/mbox/ not 
applied
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To record the empty patch as an empty commit, run "git am --allow-empty".
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] [PULL] drm-intel-next

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes our first pull request towards 6.3.

drm-intel-next-2023-03-07:

Cross-subsystem Changes:
- MEI patches to fix suspend/resume issues with the i915's PXP. (Alexander)

Driver Changes:
- Registers helpers and clean-ups. (Lucas)
- PXP fixes and clean-ups. (Alan, Alexander)
- CDCLK related fixes and w/a (Chaitanya, Stanislav)
- Move display code to use RMW whenever possible (Andrzej)
- PSR fixes (Jouni, Ville)
- Implement async_flip mode per plane tracking (Andrzej)
- Remove pre-production Workarounds (Matt)
- HDMI related fixes (Ankit)
- LVDS cleanup (Ville)
- Watermark fixes and cleanups (Ville, Jani, Stanilav)
- DMC code related fixes, cleanups and improvements (Jani)
- Implement fb_dirty for PSR,FBC,DRRS fixes (Jouni)
- Initial DSB improvements targeting LUTs loading (Ville)
- HWMON related fixes (Ashutosh)
- PCI ID updates (Jonathan, Matt Roper)
- Fix leak in scatterlist (Matt Atwood)
- Fix eDP+DSI dual panel systems (Ville)
- Cast iomem to avoid sparese warnings (Jani)
- Set default backlight controller index (Jani)
- More MTL enabling (RK)
- Conversion of display dev_priv towards i915 (Nirmoy)
- Improvements in log/debug messages (Ville)
- Increase slice_height for DP VDSC (Suraj)
- VBT ports improvements (Ville)
- Fix platforms without Display (Imre)
- Other generic display code clean-ups (Ville, Jani, Rodrigo)
- Add RPL-U sub platform (Chaitanya)
- Add inverted backlight quirk for HP 14-r206nv (Mavroudis)
- Transcoder timing improvements (Ville)
- Track audio state per-transcoder (Ville)
- Error/underrun interrupt fixes (Ville)
- Update combo PHY init sequence (Matt Roper)
- Get HDR DPCD refresh timeout (Ville)
- Vblank improvements (Ville)
- DSS fixes and cleanups (Jani)
- PM code cleanup (Jani)
- Split display parts related to RPS (Jani)

Thanks,
Rodrigo.

The following changes since commit d3eb347da1148fdb1c2462ae83090a4553d3f46f:

  drm/i915/mtl: Apply Wa_14013475917 for all MTL steppings (2023-01-26 13:54:05 
+0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-03-07

for you to fetch changes up to 4b736ed40583631e0cf32c55dbc1e5ec0434a74b:

  drm/i915: Get rid of the gm45 HPD live state nonsense (2023-03-07 19:09:20 
+0200)


Cross-subsystem Changes:
- MEI patches to fix suspend/resume issues with the i915's PXP. (Alexander)

Driver Changes:
- Registers helpers and clean-ups. (Lucas)
- PXP fixes and clean-ups. (Alan, Alexander)
- CDCLK related fixes and w/a (Chaitanya, Stanislav)
- Move display code to use RMW whenever possible (Andrzej)
- PSR fixes (Jouni, Ville)
- Implement async_flip mode per plane tracking (Andrzej)
- Remove pre-production Workarounds (Matt)
- HDMI related fixes (Ankit)
- LVDS cleanup (Ville)
- Watermark fixes and cleanups (Ville, Jani, Stanilav)
- DMC code related fixes, cleanups and improvements (Jani)
- Implement fb_dirty for PSR,FBC,DRRS fixes (Jouni)
- Initial DSB improvements targeting LUTs loading (Ville)
- HWMON related fixes (Ashutosh)
- PCI ID updates (Jonathan, Matt Roper)
- Fix leak in scatterlist (Matt Atwood)
- Fix eDP+DSI dual panel systems (Ville)
- Cast iomem to avoid sparese warnings (Jani)
- Set default backlight controller index (Jani)
- More MTL enabling (RK)
- Conversion of display dev_priv towards i915 (Nirmoy)
- Improvements in log/debug messages (Ville)
- Increase slice_height for DP VDSC (Suraj)
- VBT ports improvements (Ville)
- Fix platforms without Display (Imre)
- Other generic display code clean-ups (Ville, Jani, Rodrigo)
- Add RPL-U sub platform (Chaitanya)
- Add inverted backlight quirk for HP 14-r206nv (Mavroudis)
- Transcoder timing improvements (Ville)
- Track audio state per-transcoder (Ville)
- Error/underrun interrupt fixes (Ville)
- Update combo PHY init sequence (Matt Roper)
- Get HDR DPCD refresh timeout (Ville)
- Vblank improvements (Ville)
- DSS fixes and cleanups (Jani)
- PM code cleanup (Jani)
- Split display parts related to RPS (Jani)


Alan Previn (3):
  drm/i915/pxp: Invalidate all PXP fw sessions during teardown
  drm/i915/pxp: Trigger the global teardown for before suspending
  drm/i915/pxp: Pxp hw init should be in resume_complete

Alexander Usyskin (3):
  mei: mei-me: resume device in prepare
  drm/i915/pxp: add device link between i915 and mei_pxp
  mei: clean pending read with vtag on bus

Andrzej Hajda (14):
  drm/i915/display/fdi: use intel_de_rmw if possible
  drm/i915/display/vlv: fix pixel overlap register update
  drm/i915/display/vlv: use intel_de_rmw if possible
  drm/i915/display/dsi: use intel_de_rmw if possible
  drm/i915: implement async_flip mode per plane tracking
  drm/i915/display/core: use intel_de_rmw if possible
  drm/i915/display/dpll: use intel_de_rmw if possible
  drm/i915/display/phys: use intel_de_rmw if possible
  

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gsc: Fix race between HW init and GSC FW load

[Teres Alexis, Alan Previn]

On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> The GSC FW load is a slow process (up to 250 ms), so we defer it to a
> dedicated worker to avoid stalling the init flow for that long. However,
> we currently start this worker before the HW init is complete, so there
> is a chance that the GSC loading code submits to the HW before the
> engine initialization has completed. We can easily fix this by starting
> the thread later in the gt_resume flow.
> From this later spot, the GSC code can still race with the default
> submission code; we functionally don't care who wins the race (the GSC
> load doesn't need any state), but since the whole point of the separate
> worker is to make the main thread faster, we prefer the default
> submission code to run first. Therefore, make an exception for driver
> probe and only and start the gsc load from uc_init_late.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> ---
alan:snip

Simple fix... LGTM:
Reviewed-by: Alan Previn 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ttm: Small fixes / cleanups in prep for shrinking

[Patchwork]

== Series Details ==

Series: drm/ttm: Small fixes / cleanups in prep for shrinking
URL   : https://patchwork.freedesktop.org/series/114774/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12824 -> Patchwork_114774v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (34 -> 34)
--

  Additional (1): bat-atsm-1 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@fb...@eof.html

  * igt@gem_mmap@basic:
- bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@gem_m...@basic.html

  * igt@gem_tiled_fence_blits@basic:
- bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rpm@module-reload:
- bat-adlm-1: [PASS][5] -> [FAIL][6] ([i915#7948])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12824/bat-adlm-1/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-adlm-1/igt@i915_pm_...@module-reload.html

  * igt@i915_pm_rps@basic-api:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6621])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@hangcheck:
- bat-rpls-1: [PASS][8] -> [ABORT][9] ([i915#7677])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12824/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][10] ([i915#6997] / [i915#7913])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-adlm-1: [PASS][11] -> [DMESG-WARN][12] ([i915#2867]) +10 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12824/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#6645])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@size-max:
- bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6077]) +36 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@kms_addfb_ba...@size-max.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#7828])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#6078]) +19 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html

  * igt@kms_flip@basic-plain-flip:
- bat-atsm-1: NOTRUN -> [SKIP][17] ([i915#6166]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@kms_f...@basic-plain-flip.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-atsm-1: NOTRUN -> [SKIP][18] ([i915#6093]) +3 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_pipe_crc_basic@hang-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][19] ([i915#1836]) +6 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-atsm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-2: NOTRUN -> [SKIP][20] ([i915#1845])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114774v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftest: Remove avoidable init assignment

[Patchwork]

== Series Details ==

Series: drm/i915/selftest: Remove avoidable init assignment
URL   : https://patchwork.freedesktop.org/series/114755/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114755v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@device_reset@unbind-cold-reset-rebind:
- shard-tglu-10:  NOTRUN -> [SKIP][1] ([i915#7701])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html

  * igt@gem_basic@multigpu-create-close:
- shard-tglu-10:  NOTRUN -> [SKIP][2] ([i915#7697])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@gem_ba...@multigpu-create-close.html

  * igt@gem_ccs@block-multicopy-compressed:
- shard-tglu-10:  NOTRUN -> [SKIP][3] ([i915#5325]) +2 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@gem_...@block-multicopy-compressed.html

  * igt@gem_create@create-ext-cpu-access-big:
- shard-tglu-9:   NOTRUN -> [SKIP][4] ([i915#6335])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-big.html

  * igt@gem_exec_capture@capture-invisible@smem0:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#6334])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-glk6/igt@gem_exec_capture@capture-invisi...@smem0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-apl:  [PASS][6] -> [SKIP][7] ([fdo#109271])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12820/shard-apl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglu-10:  NOTRUN -> [FAIL][8] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@gem_exec_fair@basic-none-...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  NOTRUN -> [FAIL][9] ([i915#2842]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglu-9:   NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-9/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-10:  NOTRUN -> [SKIP][11] ([fdo#109283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@gem_exec_par...@rsvd2-dirt.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-glk:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-glk1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-tglu-10:  NOTRUN -> [SKIP][14] ([i915#4613]) +4 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-10/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@random-engines:
- shard-glk:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +13 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-glk2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random-ccs:
- shard-tglu-9:   NOTRUN -> [SKIP][16] ([i915#4613]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-9/igt@gem_lmem_swapp...@verify-random-ccs.html

  * igt@gem_mmap_wc@set-cache-level:
- shard-tglu-9:   NOTRUN -> [SKIP][17] ([i915#1850])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-tglu-9/igt@gem_mmap...@set-cache-level.html

  * igt@gem_pread@exhaustion:
- shard-glk:  NOTRUN -> [WARN][18] ([i915#2658]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114755v1/shard-glk5/igt@gem_pr...@exhaustion.html

  * igt@gem_pxp@create-regular-context-1:
- shard-tglu-10:  NOTRUN -> [SKIP][19] ([i915#4270]) +3 similar issues
   [19]: 

Re: [Intel-gfx] [PATCH] drm/i915/xelp: Implement Wa_1606376872

[Matt Roper]

On Tue, Mar 07, 2023 at 05:23:37PM -0300, Gustavo Sousa wrote:
> On Tue, Mar 07, 2023 at 12:12:46PM -0800, Matt Roper wrote:
> > On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> > > Wa_1606376872 applies to all Xe_LP IPs.
> > 
> > "...except DG1"
> 
> Oh, okay. I thought there was distinction between Xe_LP and Xe_LP+.

I think technically DG1 is considered "Xe_LP+" in some marketing
material, but that's not a term we've ever used in our drivers so I
don't think most people will be aware of it.  Even "Xe_LP" has only been
used once or twice in i915; generally we've just continued to refer to
all of these older TGL/RKL/ADL/DG1 platforms as "gen12" since that name
was already grandfathered in before the Xe branding was announced.
Going back and trying to rename everything in i915 at this point would
cause too much thrash (although when working on the Xe KMD where we
don't have years of ancient history to deal with we should avoid the
"gen" terminology from the start).

> 
> > 
> > Aside from that,
> > 
> > Reviewed-by: Matt Roper 
> 
> Thanks for the review, Matt! Should I send a v2 or can the amend suggested 
> above
> be done while applying?

It can be done while applying.  It looks like CI already came back
clean, so I'll take care of that in a little bit.


Matt

> 
> --
> Gustavo Sousa
> 
> > 
> > > 
> > > Signed-off-by: Gustavo Sousa 
> > > ---
> > >  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
> > >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
> > >  2 files changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index 08d76aa06974..4aecb5a7b631 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -478,6 +478,9 @@
> > >  #define   HDC_FORCE_NON_COHERENT (1 << 4)
> > >  #define   HDC_BARRIER_PERFORMANCE_DISABLE(1 << 10)
> > >  
> > > +#define COMMON_SLICE_CHICKEN4_MMIO(0x7300)
> > > +#define   DISABLE_TDC_LOAD_BALANCING_CALCREG_BIT(6)
> > > +
> > >  #define GEN8_HDC_CHICKEN1_MMIO(0x7304)
> > >  
> > >  #define GEN11_COMMON_SLICE_CHICKEN3  _MMIO(0x7304)
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 32aa1647721a..8092f289c492 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -743,9 +743,13 @@ static void gen12_ctx_workarounds_init(struct 
> > > intel_engine_cs *engine,
> > >  FF_MODE2_GS_TIMER_224,
> > >  0, false);
> > >  
> > > - if (!IS_DG1(i915))
> > > + if (!IS_DG1(i915)) {
> > >   /* Wa_1806527549 */
> > >   wa_masked_en(wal, HIZ_CHICKEN, HZ_DEPTH_TEST_LE_GE_OPT_DISABLE);
> > > +
> > > + /* Wa_1606376872 */
> > > + wa_masked_en(wal, COMMON_SLICE_CHICKEN4, 
> > > DISABLE_TDC_LOAD_BALANCING_CALC);
> > > + }
> > >  }
> > >  
> > >  static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine,
> > > -- 
> > > 2.39.2
> > > 
> > 
> > -- 
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915/xelp: Implement Wa_1606376872

[Gustavo Sousa]

On Tue, Mar 07, 2023 at 12:12:46PM -0800, Matt Roper wrote:
> On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> > Wa_1606376872 applies to all Xe_LP IPs.
> 
> "...except DG1"

Oh, okay. I thought there was distinction between Xe_LP and Xe_LP+.

> 
> Aside from that,
> 
> Reviewed-by: Matt Roper 

Thanks for the review, Matt! Should I send a v2 or can the amend suggested above
be done while applying?

--
Gustavo Sousa

> 
> > 
> > Signed-off-by: Gustavo Sousa 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 08d76aa06974..4aecb5a7b631 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -478,6 +478,9 @@
> >  #define   HDC_FORCE_NON_COHERENT   (1 << 4)
> >  #define   HDC_BARRIER_PERFORMANCE_DISABLE  (1 << 10)
> >  
> > +#define COMMON_SLICE_CHICKEN4  _MMIO(0x7300)
> > +#define   DISABLE_TDC_LOAD_BALANCING_CALC  REG_BIT(6)
> > +
> >  #define GEN8_HDC_CHICKEN1  _MMIO(0x7304)
> >  
> >  #define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 32aa1647721a..8092f289c492 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -743,9 +743,13 @@ static void gen12_ctx_workarounds_init(struct 
> > intel_engine_cs *engine,
> >FF_MODE2_GS_TIMER_224,
> >0, false);
> >  
> > -   if (!IS_DG1(i915))
> > +   if (!IS_DG1(i915)) {
> > /* Wa_1806527549 */
> > wa_masked_en(wal, HIZ_CHICKEN, HZ_DEPTH_TEST_LE_GE_OPT_DISABLE);
> > +
> > +   /* Wa_1606376872 */
> > +   wa_masked_en(wal, COMMON_SLICE_CHICKEN4, 
> > DISABLE_TDC_LOAD_BALANCING_CALC);
> > +   }
> >  }
> >  
> >  static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine,
> > -- 
> > 2.39.2
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation

[Intel-gfx] [PATCH v4 9/9] drm/i915/perf: Add support for OA media units

[Umesh Nerlige Ramappa]

MTL introduces additional OA units dedicated to media use cases. Add
support for programming these OA units by passing the media engine class
and instance parameters.

UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023

v2: (Ashutosh)
- check for IP_VER(12, 70) instead of MTL
- remove PERF_GROUP_OAG comment in mtl_oa_base
- remove oa_buffer.group
- use engine->oa_group->type in engine_supports_oa_format
- remove fw_domains and use FORCEWAKE_ALL
- remove MPES/MPEC comment
- s/xehp/mtl/ in b counter validation function name
- remove engine_supports_oa in __oa_engine_group
- remove warn_ON from __oam_engine_group
- refactor oa_init_groups and oa_init_regs
- assign g->type correctly
- use enum oa_type definition

v3: (Ashutosh)
- Drop oa_unit_functional as engine_supports_oa is enough

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_pci.c  |   1 +
 drivers/gpu/drm/i915/i915_perf.c | 189 ---
 drivers/gpu/drm/i915/i915_perf_oa_regs.h |  78 ++
 drivers/gpu/drm/i915/i915_perf_types.h   |  30 
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 include/uapi/drm/i915_drm.h  |   4 +
 7 files changed, 281 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0393273faa09..f3cacbf41c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -856,6 +856,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(INTEL_INFO(dev_priv)->has_oa_bpc_reporting)
 #define HAS_OA_SLICE_CONTRIB_LIMITS(dev_priv) \
(INTEL_INFO(dev_priv)->has_oa_slice_contrib_limits)
+#define HAS_OAM(dev_priv) \
+   (INTEL_INFO(dev_priv)->has_oam)
 
 /*
  * Set this flag, when platform requires 64K GTT page sizes or larger for
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..621730b6551c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info adl_p_info = {
.has_mslice_steering = 1, \
.has_oa_bpc_reporting = 1, \
.has_oa_slice_contrib_limits = 1, \
+   .has_oam = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
.has_rps = 1, \
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1b7059e9b10d..ff3b2083efe3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -326,6 +327,12 @@ static const struct i915_oa_format 
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
[I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
[I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
+   [I915_OAM_FORMAT_MPEC8u64_B8_C8]= { 1, 192, TYPE_OAM, 
HDR_64_BIT },
+   [I915_OAM_FORMAT_MPEC8u32_B8_C8]= { 2, 128, TYPE_OAM, 
HDR_64_BIT },
+};
+
+static const u32 mtl_oa_base[] = {
+   [PERF_GROUP_OAM_SAMEDIA_0] = 0x393000,
 };
 
 #define SAMPLE_OA_REPORT  (1<<0)
@@ -418,11 +425,17 @@ static void free_oa_config_bo(struct i915_oa_config_bo 
*oa_bo)
kfree(oa_bo);
 }
 
+static inline const
+struct i915_perf_regs *__oa_regs(struct i915_perf_stream *stream)
+{
+   return >engine->oa_group->regs;
+}
+
 static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream)
 {
struct intel_uncore *uncore = stream->uncore;
 
-   return intel_uncore_read(uncore, GEN12_OAG_OATAILPTR) &
+   return intel_uncore_read(uncore, __oa_regs(stream)->oa_tail_ptr) &
   GEN12_OAG_OATAILPTR_MASK;
 }
 
@@ -875,7 +888,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
i915_reg_t oaheadptr;
 
oaheadptr = GRAPHICS_VER(stream->perf->i915) == 12 ?
-   GEN12_OAG_OAHEADPTR : GEN8_OAHEADPTR;
+   __oa_regs(stream)->oa_head_ptr :
+   GEN8_OAHEADPTR;
 
spin_lock_irqsave(>oa_buffer.ptr_lock, flags);
 
@@ -928,7 +942,8 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
return -EIO;
 
oastatus_reg = GRAPHICS_VER(stream->perf->i915) == 12 ?
-  GEN12_OAG_OASTATUS : GEN8_OASTATUS;
+  __oa_regs(stream)->oa_status :
+  GEN8_OASTATUS;
 
oastatus = intel_uncore_read(uncore, oastatus_reg);
 
@@ -1637,6 +1652,11 @@ static bool engine_supports_oa(const 

[Intel-gfx] [PATCH v4 2/9] drm/i915/perf: Add helper to check supported OA engines

[Umesh Nerlige Ramappa]

With an intention to add more engines that are supported by OA, add
helper to check for supported OA engines.

v2: (Ashutosh)
- Update commit message
- Drop virtual engine check since we support only one render engine

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 283a4a3c6862..b0e1acbe90fc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1570,6 +1570,16 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(>noa_wait, 0);
 }
 
+static bool engine_supports_oa(const struct intel_engine_cs *engine)
+{
+   enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
+
+   switch (platform) {
+   default:
+   return engine->class == RENDER_CLASS;
+   }
+}
+
 static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
 {
struct i915_perf *perf = stream->perf;
@@ -2505,7 +2515,7 @@ static int gen8_configure_context(struct i915_gem_context 
*ctx,
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
GEM_BUG_ON(ce == ce->engine->kernel_context);
 
-   if (ce->engine->class != RENDER_CLASS)
+   if (!engine_supports_oa(ce->engine))
continue;
 
/* Otherwise OA settings will be set upon first use */
@@ -2656,7 +2666,7 @@ oa_configure_all_contexts(struct i915_perf_stream *stream,
for_each_uabi_engine(engine, i915) {
struct intel_context *ce = engine->kernel_context;
 
-   if (engine->class != RENDER_CLASS)
+   if (!engine_supports_oa(ce->engine))
continue;
 
regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
@@ -3369,7 +3379,7 @@ void i915_oa_init_reg_state(const struct intel_context 
*ce,
 {
struct i915_perf_stream *stream;
 
-   if (engine->class != RENDER_CLASS)
+   if (!engine_supports_oa(engine))
return;
 
/* perf.exclusive_stream serialised by lrc_configure_all_contexts() */
-- 
2.36.1

[Intel-gfx] [PATCH v4 5/9] drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM

[Umesh Nerlige Ramappa]

i915_perf_init can fail due to OOM. Fail driver init if i915_perf_init
fails.

v2: (Jani)
- Reorder patch in the series

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_driver.c | 4 +++-
 drivers/gpu/drm/i915/i915_perf.c   | 8 ++--
 drivers/gpu/drm/i915/i915_perf.h   | 2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 0c0ae3eabb4b..998ca41c9713 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -477,7 +477,9 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
if (ret)
return ret;
 
-   i915_perf_init(dev_priv);
+   ret = i915_perf_init(dev_priv);
+   if (ret)
+   return ret;
 
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 26ee8377cece..536de16b83b3 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4902,7 +4902,7 @@ static void i915_perf_init_info(struct drm_i915_private 
*i915)
  * Note: i915-perf initialization is split into an 'init' and 'register'
  * phase with the i915_perf_register() exposing state to userspace.
  */
-void i915_perf_init(struct drm_i915_private *i915)
+int i915_perf_init(struct drm_i915_private *i915)
 {
struct i915_perf *perf = >perf;
 
@@ -5018,12 +5018,16 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->i915 = i915;
 
ret = oa_init_engine_groups(perf);
-   if (ret)
+   if (ret) {
drm_err(>drm,
"OA initialization failed %d\n", ret);
+   return ret;
+   }
 
oa_init_supported_formats(perf);
}
+
+   return 0;
 }
 
 static int destroy_config(int id, void *p, void *data)
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index f96e09a4af04..253637651d5e 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -18,7 +18,7 @@ struct i915_oa_config;
 struct intel_context;
 struct intel_engine_cs;
 
-void i915_perf_init(struct drm_i915_private *i915);
+int i915_perf_init(struct drm_i915_private *i915);
 void i915_perf_fini(struct drm_i915_private *i915);
 void i915_perf_register(struct drm_i915_private *i915);
 void i915_perf_unregister(struct drm_i915_private *i915);
-- 
2.36.1

[Intel-gfx] [PATCH v4 3/9] drm/i915/perf: Validate OA sseu config outside switch

[Umesh Nerlige Ramappa]

Once OA supports media engine class:instance, the engine can only be
validated outside the switch since class and instance parameters are
separate entities. Since OA sseu config depends on engine
class:instance, validate OA sseu config outside the switch.

v2: (Ashutosh)
- Clarify commit message
- Use drm_dbg instead of DRM_DEBUG
- Reorder stack variables

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b0e1acbe90fc..1229f65534e2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3950,7 +3950,9 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
u32 n_props,
struct perf_open_properties *props)
 {
+   struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
+   bool config_sseu = false;
u32 i;
int ret;
 
@@ -4079,8 +4081,6 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
props->hold_preemption = !!value;
break;
case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
-   struct drm_i915_gem_context_param_sseu user_sseu;
-
if (GRAPHICS_VER_FULL(perf->i915) >= IP_VER(12, 50)) {
drm_dbg(>i915->drm,
"SSEU config not supported on gfx %x\n",
@@ -4095,14 +4095,7 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
"Unable to copy global sseu 
parameter\n");
return -EFAULT;
}
-
-   ret = get_sseu_config(>sseu, props->engine, 
_sseu);
-   if (ret) {
-   drm_dbg(>i915->drm,
-   "Invalid SSEU configuration\n");
-   return ret;
-   }
-   props->has_sseu = true;
+   config_sseu = true;
break;
}
case DRM_I915_PERF_PROP_POLL_OA_PERIOD:
@@ -4122,6 +4115,16 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
uprop += 2;
}
 
+   if (config_sseu) {
+   ret = get_sseu_config(>sseu, props->engine, _sseu);
+   if (ret) {
+   drm_dbg(>i915->drm,
+   "Invalid SSEU configuration\n");
+   return ret;
+   }
+   props->has_sseu = true;
+   }
+
return 0;
 }
 
-- 
2.36.1

[Intel-gfx] [PATCH v4 0/9] Add OAM support for MTL

[Umesh Nerlige Ramappa]

The OAM unit captures OA reports specific to the media engines. Add support to
program the OAM unit on media tile on MTL.

The OAM unit is selected by passing the class:instance of a media engine to perf
parameters. Corresponding UMD changes are posted to the igt-dev repo as part of
supporting the GPUvis tool.

v2: Incorporate review feedback (Jani, Ashutosh)
v3: Incorporate review feedback (Jani, Ashutosh)
v4: Incorporate review feedback (Ashutosh)

Signed-off-by: Umesh Nerlige Ramappa 
Test-with: 20230215004648.2100655-1-umesh.nerlige.rama...@intel.com

Chris Wilson (1):
  drm/i915/perf: Drop wakeref on GuC RC error

Umesh Nerlige Ramappa (8):
  drm/i915/perf: Add helper to check supported OA engines
  drm/i915/perf: Validate OA sseu config outside switch
  drm/i915/perf: Group engines into respective OA groups
  drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM
  drm/i915/perf: Parse 64bit report header formats correctly
  drm/i915/perf: Handle non-power-of-2 reports
  drm/i915/perf: Add engine class instance parameters to perf
  drm/i915/perf: Add support for OA media units

 drivers/gpu/drm/i915/gt/intel_engine_types.h |  10 +
 drivers/gpu/drm/i915/gt/intel_sseu.c |   3 +-
 drivers/gpu/drm/i915/i915_driver.c   |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_pci.c  |   1 +
 drivers/gpu/drm/i915/i915_perf.c | 527 +++
 drivers/gpu/drm/i915/i915_perf.h |   2 +-
 drivers/gpu/drm/i915/i915_perf_oa_regs.h |  78 +++
 drivers/gpu/drm/i915/i915_perf_types.h   |  75 ++-
 drivers/gpu/drm/i915/intel_device_info.h |   1 +
 include/uapi/drm/i915_drm.h  |  21 +
 11 files changed, 603 insertions(+), 121 deletions(-)

-- 
2.36.1

[Intel-gfx] [PATCH v4 7/9] drm/i915/perf: Handle non-power-of-2 reports

[Umesh Nerlige Ramappa]

Some of the newer OA formats are not powers of 2. For those formats,
adjust the hw_tail accordingly when checking for new reports.

v2: (Ashutosh)
- Switch to OA_TAKEN for diff calculation
- Use OA_BUFFER_SIZE instead of the vma size
- Update comments

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c | 51 +---
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8336430aa27f..9e6da8859284 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -534,6 +534,7 @@ static bool oa_buffer_check_unlocked(struct 
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+   u32 partial_report_size;
 
/* We have to consider the (unlikely) possibility that read() errors
 * could result in an OA buffer reset which might reset the head and
@@ -543,10 +544,15 @@ static bool oa_buffer_check_unlocked(struct 
i915_perf_stream *stream)
 
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
 
-   /* The tail pointer increases in 64 byte increments,
-* not in report_size steps...
+   /* The tail pointer increases in 64 byte increments, not in report_size
+* steps. Also the report size may not be a power of 2. Compute
+* potentially partially landed report in the OA buffer
 */
-   hw_tail &= ~(report_size - 1);
+   partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+   partial_report_size %= report_size;
+
+   /* Subtract partial amount off the tail */
+   hw_tail = gtt_offset + OA_TAKEN(hw_tail, partial_report_size);
 
now = ktime_get_mono_fast_ns();
 
@@ -669,6 +675,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
 {
int report_size = stream->oa_buffer.format->size;
struct drm_i915_perf_record_header header;
+   int report_size_partial;
+   u8 *oa_buf_end;
 
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -682,8 +690,20 @@ static int append_oa_sample(struct i915_perf_stream 
*stream,
return -EFAULT;
buf += sizeof(header);
 
-   if (copy_to_user(buf, report, report_size))
+   oa_buf_end = stream->oa_buffer.vaddr + OA_BUFFER_SIZE;
+   report_size_partial = oa_buf_end - report;
+
+   if (report_size_partial < report_size) {
+   if (copy_to_user(buf, report, report_size_partial))
+   return -EFAULT;
+   buf += report_size_partial;
+
+   if (copy_to_user(buf, stream->oa_buffer.vaddr,
+report_size - report_size_partial))
+   return -EFAULT;
+   } else if (copy_to_user(buf, report, report_size)) {
return -EFAULT;
+   }
 
(*offset) += header.size;
 
@@ -747,12 +767,11 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
 * An out of bounds or misaligned head or tail pointer implies a driver
 * bug since we validate + align the tail pointers we read from the
 * hardware and we are in full control of the head pointer which should
-* only be incremented by multiples of the report size (notably also
-* all a power of two).
+* only be incremented by multiples of the report size.
 */
if (drm_WARN_ONCE(>i915->drm,
- head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ head > OA_BUFFER_SIZE ||
+ tail > OA_BUFFER_SIZE,
  "Inconsistent OA buffer pointers: head = %u, tail = 
%u\n",
  head, tail))
return -EIO;
@@ -766,22 +785,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
u32 ctx_id;
u64 reason;
 
-   /*
-* All the report sizes factor neatly into the buffer
-* size so we never expect to see a report split
-* between the beginning and end of the buffer.
-*
-* Given the initial alignment check a misalignment
-* here would imply a driver bug that would result
-* in an overrun.
-*/
-   if (drm_WARN_ON(>i915->drm,
-   (OA_BUFFER_SIZE - head) < report_size)) {
-   drm_err(>i915->drm,
-   "Spurious OA head ptr: non-integral report 
offset\n");
-   break;
-   }
-
/*
 * The reason field includes flags identifying what
 * triggered this specific report (mostly timer
-- 
2.36.1

[Intel-gfx] [PATCH v4 6/9] drm/i915/perf: Parse 64bit report header formats correctly

[Umesh Nerlige Ramappa]

Now that OA formats come in flavor of 64 bit reports, the report header
has 64 bit report-id, timestamp, context-id and gpu-ticks fields. When
filtering these reports, use the right width for these fields.

Note that upper dword of context id is reserved, so squash lower dword
only.

v2: (Ashutosh)
- Drop inline
- Update comment with dword definitions - report id and timestamp

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c   | 109 +++--
 drivers/gpu/drm/i915/i915_perf_types.h |   6 ++
 2 files changed, 90 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 536de16b83b3..8336430aa27f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -441,6 +441,67 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream 
*stream)
return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
 }
 
+#define oa_report_header_64bit(__s) \
+   ((__s)->oa_buffer.format->header == HDR_64_BIT)
+
+static u64 oa_report_id(struct i915_perf_stream *stream, void *report)
+{
+   return oa_report_header_64bit(stream) ? *(u64 *)report : *(u32 *)report;
+}
+
+static u64 oa_report_reason(struct i915_perf_stream *stream, void *report)
+{
+   return (oa_report_id(stream, report) >> OAREPORT_REASON_SHIFT) &
+  (GRAPHICS_VER(stream->perf->i915) == 12 ?
+   OAREPORT_REASON_MASK_EXTENDED :
+   OAREPORT_REASON_MASK);
+}
+
+static void oa_report_id_clear(struct i915_perf_stream *stream, u32 *report)
+{
+   if (oa_report_header_64bit(stream))
+   *(u64 *)report = 0;
+   else
+   *report = 0;
+}
+
+static bool oa_report_ctx_invalid(struct i915_perf_stream *stream, void 
*report)
+{
+   return !(oa_report_id(stream, report) &
+  stream->perf->gen8_valid_ctx_bit) &&
+  GRAPHICS_VER(stream->perf->i915) <= 11;
+}
+
+static u64 oa_timestamp(struct i915_perf_stream *stream, void *report)
+{
+   return oa_report_header_64bit(stream) ?
+   *((u64 *)report + 1) :
+   *((u32 *)report + 1);
+}
+
+static void oa_timestamp_clear(struct i915_perf_stream *stream, u32 *report)
+{
+   if (oa_report_header_64bit(stream))
+   *(u64 *)[2] = 0;
+   else
+   report[1] = 0;
+}
+
+static u32 oa_context_id(struct i915_perf_stream *stream, u32 *report)
+{
+   u32 ctx_id = oa_report_header_64bit(stream) ? report[4] : report[2];
+
+   return ctx_id & stream->specific_ctx_id_mask;
+}
+
+static void oa_context_id_squash(struct i915_perf_stream *stream, u32 *report)
+{
+   if (oa_report_header_64bit(stream))
+   report[4] = INVALID_CTX_ID;
+   else
+   report[2] = INVALID_CTX_ID;
+}
+
 /**
  * oa_buffer_check_unlocked - check for data and update tail ptr state
  * @stream: i915 stream instance
@@ -509,21 +570,22 @@ static bool oa_buffer_check_unlocked(struct 
i915_perf_stream *stream)
hw_tail -= gtt_offset;
tail = hw_tail;
 
-   /* Walk the stream backward until we find a report with dword 0
-* & 1 not at 0. Since the circular buffer pointers progress by
-* increments of 64 bytes and that reports can be up to 256
-* bytes long, we can't tell whether a report has fully landed
-* in memory before the first 2 dwords of the following report
-* have effectively landed.
+   /* Walk the stream backward until we find a report with report
+* id and timestmap not at 0. Since the circular buffer pointers
+* progress by increments of 64 bytes and that reports can be up
+* to 256 bytes long, we can't tell whether a report has fully
+* landed in memory before the report id and timestamp of the
+* following report have effectively landed.
 *
 * This is assuming that the writes of the OA unit land in
 * memory in the order they were written to.
 * If not : (╯°□°）╯︵ ┻━┻
 */
while (OA_TAKEN(tail, aged_tail) >= report_size) {
-   u32 *report32 = (void *)(stream->oa_buffer.vaddr + 
tail);
+   void *report = stream->oa_buffer.vaddr + tail;
 
-   if (report32[0] != 0 || report32[1] != 0)
+   if (oa_report_id(stream, report) ||
+   oa_timestamp(stream, report))
break;
 
tail = (tail - report_size) & (OA_BUFFER_SIZE - 1);
@@ -702,7 +764,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
u8 *report = oa_buf_base + head;
u32 *report32 = (void *)report;
u32 ctx_id;
-   u32 reason;
+  

[Intel-gfx] [PATCH v4 8/9] drm/i915/perf: Add engine class instance parameters to perf

[Umesh Nerlige Ramappa]

One or more engines map to a specific OA unit. All reports from these
engines are captured in the OA buffer managed by this OA unit.

Current i915 OA implementation supports only the OAG unit. OAG primarily
caters to render engine, so i915 OA uses render as the default engine
in the OA implementation. Since there are more OA units on newer
hardware that map to other engines, allow user to pass engine class and
instance to select and program specific OA units.

UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023

v2: (Ashutosh)
- Clarify commit message
- Add drm_dbg
- Clarify uapi description

v3: (Ashutosh)
- Remove irrelevant info from the uapi comment

Signed-off-by: Umesh Nerlige Ramappa 
---
 drivers/gpu/drm/i915/i915_perf.c | 60 ++--
 include/uapi/drm/i915_drm.h  | 17 +
 2 files changed, 50 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9e6da8859284..1b7059e9b10d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4013,47 +4013,29 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
bool config_sseu = false;
+   u8 class, instance;
u32 i;
int ret;
 
memset(props, 0, sizeof(struct perf_open_properties));
props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
 
-   if (!n_props) {
-   drm_dbg(>i915->drm,
-   "No i915 perf properties given\n");
-   return -EINVAL;
-   }
-
-   /* At the moment we only support using i915-perf on the RCS. */
-   props->engine = intel_engine_lookup_user(perf->i915,
-I915_ENGINE_CLASS_RENDER,
-0);
-   if (!props->engine) {
-   drm_dbg(>i915->drm,
-   "No RENDER-capable engines\n");
-   return -EINVAL;
-   }
-
-   if (!engine_supports_oa(props->engine)) {
-   drm_dbg(>i915->drm,
-   "Engine not supported by OA %d:%d\n",
-   I915_ENGINE_CLASS_RENDER, 0);
-   return -EINVAL;
-   }
-
/* Considering that ID = 0 is reserved and assuming that we don't
 * (currently) expect any configurations to ever specify duplicate
 * values for a particular property ID then the last _PROP_MAX value is
 * one greater than the maximum number of properties we expect to get
 * from userspace.
 */
-   if (n_props >= DRM_I915_PERF_PROP_MAX) {
+   if (!n_props || n_props >= DRM_I915_PERF_PROP_MAX) {
drm_dbg(>i915->drm,
-   "More i915 perf properties specified than exist\n");
+   "Invalid number of i915 perf properties given\n");
return -EINVAL;
}
 
+   /* Defaults when class:instance is not passed */
+   class = I915_ENGINE_CLASS_RENDER;
+   instance = 0;
+
for (i = 0; i < n_props; i++) {
u64 oa_period, oa_freq_hz;
u64 id, value;
@@ -4174,7 +4156,13 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
}
props->poll_oa_period = value;
break;
-   case DRM_I915_PERF_PROP_MAX:
+   case DRM_I915_PERF_PROP_OA_ENGINE_CLASS:
+   class = (u8)value;
+   break;
+   case DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE:
+   instance = (u8)value;
+   break;
+   default:
MISSING_CASE(id);
return -EINVAL;
}
@@ -4182,6 +4170,21 @@ static int read_properties_unlocked(struct i915_perf 
*perf,
uprop += 2;
}
 
+   props->engine = intel_engine_lookup_user(perf->i915, class, instance);
+   if (!props->engine) {
+   drm_dbg(>i915->drm,
+   "OA engine class and instance invalid %d:%d\n",
+   class, instance);
+   return -EINVAL;
+   }
+
+   if (!engine_supports_oa(props->engine)) {
+   drm_dbg(>i915->drm,
+   "Engine not supported by OA %d:%d\n",
+   class, instance);
+   return -EINVAL;
+   }
+
if (config_sseu) {
ret = get_sseu_config(>sseu, props->engine, _sseu);

[Intel-gfx] [PATCH v4 4/9] drm/i915/perf: Group engines into respective OA groups

[Umesh Nerlige Ramappa]

Now that we may have multiple OA units in a single GT as well as on
separate GTs, create an engine group that maps to a single OA unit.

v2: (Jani)
- Drop warning on ENOMEM
- Reorder patch in the series

v3: (Ashutosh)
- Remove unused members from perf structs
- Update comments
- Update engine_supports_oa check
- Just return 1 in num_perf_groups_per_gt for now
- Set engine->oa_group to NULL to begin with

v4: Use engine_supports_oa() check in oa_init_reg_state (Ashutosh)

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++
 drivers/gpu/drm/i915/gt/intel_sseu.c |  3 +-
 drivers/gpu/drm/i915/i915_perf.c | 95 +---
 drivers/gpu/drm/i915/i915_perf_types.h   | 33 ++-
 4 files changed, 123 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h 
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 4fd54fb8810f..1a5fb4131ec2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -53,6 +53,8 @@ struct intel_gt;
 struct intel_ring;
 struct intel_uncore;
 struct intel_breadcrumbs;
+struct intel_engine_cs;
+struct i915_perf_group;
 
 typedef u32 intel_engine_mask_t;
 #define ALL_ENGINES ((intel_engine_mask_t)~0ul)
@@ -603,6 +605,14 @@ struct intel_engine_cs {
} props, defaults;
 
I915_SELFTEST_DECLARE(struct fault_attr reset_timeout);
+
+   /*
+* The perf group maps to one OA unit which controls one OA buffer. All
+* reports corresponding to this engine will be reported to this OA
+* buffer. An engine will map to a single OA unit, but a single OA unit
+* can generate reports for multiple engines.
+*/
+   struct i915_perf_group *oa_group;
 };
 
 static inline bool
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 6c6198a257ac..1141f875f5bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -6,6 +6,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "i915_perf_types.h"
 #include "intel_engine_regs.h"
 #include "intel_gt_regs.h"
 #include "intel_sseu.h"
@@ -677,7 +678,7 @@ u32 intel_sseu_make_rpcs(struct intel_gt *gt,
 * If i915/perf is active, we want a stable powergating configuration
 * on the system. Use the configuration pinned by i915/perf.
 */
-   if (gt->perf.exclusive_stream)
+   if (gt->perf.group && gt->perf.group[PERF_GROUP_OAG].exclusive_stream)
req_sseu = >perf.sseu;
 
slices = hweight8(req_sseu->slice_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1229f65534e2..26ee8377cece 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1572,20 +1572,16 @@ free_noa_wait(struct i915_perf_stream *stream)
 
 static bool engine_supports_oa(const struct intel_engine_cs *engine)
 {
-   enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
-
-   switch (platform) {
-   default:
-   return engine->class == RENDER_CLASS;
-   }
+   return engine->oa_group;
 }
 
 static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
 {
struct i915_perf *perf = stream->perf;
struct intel_gt *gt = stream->engine->gt;
+   struct i915_perf_group *g = stream->engine->oa_group;
 
-   if (WARN_ON(stream != gt->perf.exclusive_stream))
+   if (WARN_ON(stream != g->exclusive_stream))
return;
 
/*
@@ -1594,7 +1590,7 @@ static void i915_oa_stream_destroy(struct 
i915_perf_stream *stream)
 *
 * See i915_oa_init_reg_state() and lrc_configure_all_contexts()
 */
-   WRITE_ONCE(gt->perf.exclusive_stream, NULL);
+   WRITE_ONCE(g->exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
 
free_oa_buffer(stream);
@@ -3192,6 +3188,7 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 {
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+   struct i915_perf_group *g;
struct intel_gt *gt;
int ret;
 
@@ -3201,6 +3198,7 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return -EINVAL;
}
gt = props->engine->gt;
+   g = props->engine->oa_group;
 
/*
 * If the sysfs metrics/ directory wasn't registered for some
@@ -3231,7 +3229,7 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 * counter reports and marshal to the appropriate client
 * we currently only allow exclusive access
 */
-   if (gt->perf.exclusive_stream) {
+   if (g->exclusive_stream) {
drm_dbg(>perf->i915->drm,
"OA unit already in use\n");
return -EBUSY;
@@ -3326,7 +3324,7 @@ static int 

[Intel-gfx] [PATCH v4 1/9] drm/i915/perf: Drop wakeref on GuC RC error

[Umesh Nerlige Ramappa]

From: Chris Wilson 

If we fail to adjust the GuC run-control on opening the perf stream,
make sure we unwind the wakeref just taken.

v2: Retain old goto label names (Ashutosh)

Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled")
Signed-off-by: Chris Wilson 
Reviewed-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/i915_perf.c   | 14 +-
 drivers/gpu/drm/i915/i915_perf_types.h |  6 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..283a4a3c6862 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,9 +1592,7 @@ static void i915_oa_stream_destroy(struct 
i915_perf_stream *stream)
/*
 * Wa_16011777198:dg2: Unset the override of GUCRC mode to enable rc6.
 */
-   if (intel_uc_uses_guc_rc(>uc) &&
-   (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
-IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)))
+   if (stream->override_gucrc)
drm_WARN_ON(>i915->drm,
intel_guc_slpc_unset_gucrc_mode(>uc.guc.slpc));
 
@@ -3305,8 +3303,10 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret) {
drm_dbg(>perf->i915->drm,
"Unable to override gucrc mode\n");
-   goto err_config;
+   goto err_gucrc;
}
+
+   stream->override_gucrc = true;
}
 
ret = alloc_oa_buffer(stream);
@@ -3345,11 +3345,15 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
free_oa_buffer(stream);
 
 err_oa_buf_alloc:
-   free_oa_configs(stream);
+   if (stream->override_gucrc)
+   intel_guc_slpc_unset_gucrc_mode(>uc.guc.slpc);
 
+err_gucrc:
intel_uncore_forcewake_put(stream->uncore, FORCEWAKE_ALL);
intel_engine_pm_put(stream->engine);
 
+   free_oa_configs(stream);
+
 err_config:
free_noa_wait(stream);
 
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h 
b/drivers/gpu/drm/i915/i915_perf_types.h
index ca150b7af3f2..e36f046fe2b6 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -316,6 +316,12 @@ struct i915_perf_stream {
 * buffer should be checked for available data.
 */
u64 poll_oa_period;
+
+   /**
+* @override_gucrc: GuC RC has been overridden for the perf stream,
+* and we need to restore the default configuration on release.
+*/
+   bool override_gucrc:1;
 };
 
 /**
-- 
2.36.1

Re: [Intel-gfx] [PATCH] drm/i915/xelp: Implement Wa_1606376872

[Matt Roper]

On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> Wa_1606376872 applies to all Xe_LP IPs.

"...except DG1"

Aside from that,

Reviewed-by: Matt Roper 

> 
> Signed-off-by: Gustavo Sousa 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 08d76aa06974..4aecb5a7b631 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -478,6 +478,9 @@
>  #define   HDC_FORCE_NON_COHERENT (1 << 4)
>  #define   HDC_BARRIER_PERFORMANCE_DISABLE(1 << 10)
>  
> +#define COMMON_SLICE_CHICKEN4_MMIO(0x7300)
> +#define   DISABLE_TDC_LOAD_BALANCING_CALCREG_BIT(6)
> +
>  #define GEN8_HDC_CHICKEN1_MMIO(0x7304)
>  
>  #define GEN11_COMMON_SLICE_CHICKEN3  _MMIO(0x7304)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 32aa1647721a..8092f289c492 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -743,9 +743,13 @@ static void gen12_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>  FF_MODE2_GS_TIMER_224,
>  0, false);
>  
> - if (!IS_DG1(i915))
> + if (!IS_DG1(i915)) {
>   /* Wa_1806527549 */
>   wa_masked_en(wal, HIZ_CHICKEN, HZ_DEPTH_TEST_LE_GE_OPT_DISABLE);
> +
> + /* Wa_1606376872 */
> + wa_masked_en(wal, COMMON_SLICE_CHICKEN4, 
> DISABLE_TDC_LOAD_BALANCING_CALC);
> + }
>  }
>  
>  static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine,
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Set correct voltage level for 480MHz CDCLK

[Patchwork]

== Series Details ==

Series: drm/i915/display: Set correct voltage level for 480MHz CDCLK
URL   : https://patchwork.freedesktop.org/series/114752/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114752v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_114752v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_114752v1_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 -> 10)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_hdr@bpc-switch:
- shard-apl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-apl7/igt@kms_...@bpc-switch.html

  
 Warnings 

  * igt@kms_content_protection@legacy@pipe-a-dp-1:
- shard-apl:  [TIMEOUT][2] ([i915#7173]) -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12820/shard-apl2/igt@kms_content_protection@leg...@pipe-a-dp-1.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-apl7/igt@kms_content_protection@leg...@pipe-a-dp-1.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@crc32:
- shard-tglu-10:  NOTRUN -> [SKIP][4] ([i915#6230])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@api_intel...@crc32.html

  * igt@drm_buddy@all-tests:
- shard-tglu-10:  NOTRUN -> [SKIP][5] ([i915#6433])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@drm_bu...@all-tests.html

  * igt@drm_mm@all-tests:
- shard-tglu-9:   NOTRUN -> [SKIP][6] ([i915#6433])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-9/igt@drm...@all-tests.html

  * igt@fbdev@eof:
- shard-tglu-9:   NOTRUN -> [SKIP][7] ([i915#2582])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-9/igt@fb...@eof.html

  * igt@gem_ccs@ctrl-surf-copy:
- shard-tglu-10:  NOTRUN -> [SKIP][8] ([i915#3555] / [i915#5325])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_...@ctrl-surf-copy.html

  * igt@gem_ctx_sseu@invalid-sseu:
- shard-tglu-10:  NOTRUN -> [SKIP][9] ([i915#280]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_ctx_s...@invalid-sseu.html

  * igt@gem_exec_capture@capture-invisible@smem0:
- shard-glk:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#6334])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-glk6/igt@gem_exec_capture@capture-invisi...@smem0.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  NOTRUN -> [FAIL][11] ([i915#2842]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@rcs0:
- shard-tglu-10:  NOTRUN -> [FAIL][12] ([i915#2842]) +5 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_exec_fair@basic-n...@rcs0.html

  * igt@gem_exec_gttfill@multigpu-basic:
- shard-tglu-10:  NOTRUN -> [SKIP][13] ([i915#7697])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_exec_gttf...@multigpu-basic.html

  * igt@gem_huc_copy@huc-copy:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-glk3/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random:
- shard-tglu-10:  NOTRUN -> [SKIP][15] ([i915#4613]) +4 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_lmem_swapp...@random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-glk:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +13 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-glk4/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_media_vme:
- shard-tglu-10:  NOTRUN -> [SKIP][17] ([i915#284])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114752v1/shard-tglu-10/igt@gem_media_vme.html

  * igt@gem_pread@exhaustion:
- shard-glk:  NOTRUN -> [WARN][18] ([i915#2658]) +1 similar issue
   [18]: 

Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Load DMC on MTL

[Matt Roper]

On Tue, Mar 07, 2023 at 04:51:11PM -0300, Gustavo Sousa wrote:
> From: Madhumitha Tolakanahalli Pradeep 
> 
> 
> Add support to load DMC on MTL.
> 
> According to the spec and based on tests done on real hardware, 0x7000
> is a reasonable size limit that covers each possible payload.
> 
> v2:
>   - Tighten payload size limit. (Matt, Rodrigo)
>   - Use a better name for the defined payload limit. (Rodrigo)
> 
> Signed-off-by: Madhumitha Tolakanahalli Pradeep 
> 
> Signed-off-by: Gustavo Sousa 
> Cc: Rodrigo Vivi 
> Cc: Matt Roper 
> Cc: Anusha Srivatsa 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 6b162f77340e..d84cf9237b9c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -89,10 +89,13 @@ static struct intel_dmc *i915_to_dmc(struct 
> drm_i915_private *i915)
>   __stringify(major) "_"  \
>   __stringify(minor) ".bin"
>  
> +#define XELPDP_DMC_MAX_FW_SIZE   0x7000
>  #define DISPLAY_VER13_DMC_MAX_FW_SIZE0x2
> -
>  #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>  
> +#define MTL_DMC_PATH DMC_PATH(mtl)
> +MODULE_FIRMWARE(MTL_DMC_PATH);
> +
>  #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
>  MODULE_FIRMWARE(DG2_DMC_PATH);
>  
> @@ -979,7 +982,10 @@ void intel_dmc_init(struct drm_i915_private *i915)
>  
>   INIT_WORK(>work, dmc_load_work_fn);
>  
> - if (IS_DG2(i915)) {
> + if (IS_METEORLAKE(i915)) {
> + dmc->fw_path = MTL_DMC_PATH;
> + dmc->max_fw_size = XELPDP_DMC_MAX_FW_SIZE;
> + } else if (IS_DG2(i915)) {
>   dmc->fw_path = DG2_DMC_PATH;
>   dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
>   } else if (IS_ALDERLAKE_P(i915)) {
> -- 
> 2.39.2
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation

[Intel-gfx] [PATCH v2] drm/i915/dmc: Load DMC on MTL

[Gustavo Sousa]

From: Madhumitha Tolakanahalli Pradeep 


Add support to load DMC on MTL.

According to the spec and based on tests done on real hardware, 0x7000
is a reasonable size limit that covers each possible payload.

v2:
  - Tighten payload size limit. (Matt, Rodrigo)
  - Use a better name for the defined payload limit. (Rodrigo)

Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Gustavo Sousa 
Cc: Rodrigo Vivi 
Cc: Matt Roper 
Cc: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 6b162f77340e..d84cf9237b9c 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -89,10 +89,13 @@ static struct intel_dmc *i915_to_dmc(struct 
drm_i915_private *i915)
__stringify(major) "_"  \
__stringify(minor) ".bin"
 
+#define XELPDP_DMC_MAX_FW_SIZE 0x7000
 #define DISPLAY_VER13_DMC_MAX_FW_SIZE  0x2
-
 #define DISPLAY_VER12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
 
+#define MTL_DMC_PATH   DMC_PATH(mtl)
+MODULE_FIRMWARE(MTL_DMC_PATH);
+
 #define DG2_DMC_PATH   DMC_LEGACY_PATH(dg2, 2, 08)
 MODULE_FIRMWARE(DG2_DMC_PATH);
 
@@ -979,7 +982,10 @@ void intel_dmc_init(struct drm_i915_private *i915)
 
INIT_WORK(>work, dmc_load_work_fn);
 
-   if (IS_DG2(i915)) {
+   if (IS_METEORLAKE(i915)) {
+   dmc->fw_path = MTL_DMC_PATH;
+   dmc->max_fw_size = XELPDP_DMC_MAX_FW_SIZE;
+   } else if (IS_DG2(i915)) {
dmc->fw_path = DG2_DMC_PATH;
dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
} else if (IS_ALDERLAKE_P(i915)) {
-- 
2.39.2

Re: [Intel-gfx] [PATCH v2 6/7] drm/ttm: Reduce the number of used allocation orders for TTM pages

[kernel test robot]

Hi Thomas,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next]
[cannot apply to drm-tip/drm-tip]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-ttm-Fix-a-NULL-pointer-dereference/20230307-224931
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230307144621.10748-7-thomas.hellstrom%40linux.intel.com
patch subject: [Intel-gfx] [PATCH v2 6/7] drm/ttm: Reduce the number of used 
allocation orders for TTM pages
config: powerpc-randconfig-r006-20230306 
(https://download.01.org/0day-ci/archive/20230308/202303080352.azyewwwt-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/0eee47dba298051fc49965d56cb17dd113ff0236
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Thomas-Hellstr-m/drm-ttm-Fix-a-NULL-pointer-dereference/20230307-224931
git checkout 0eee47dba298051fc49965d56cb17dd113ff0236
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=powerpc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 
O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/drm/ttm/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303080352.azyewwwt-...@intel.com/

All error/warnings (new ones prefixed by >>):

   In function 'ttm_pool_type_init',
   inlined from 'ttm_pool_init' at drivers/gpu/drm/ttm/ttm_pool.c:557:5:
>> drivers/gpu/drm/ttm/ttm_pool.c:264:18: warning: iteration 9 invokes 
>> undefined behavior [-Waggressive-loop-optimizations]
 264 | pt->pool = pool;
 | ~^~
   drivers/gpu/drm/ttm/ttm_pool.c: In function 'ttm_pool_init':
   drivers/gpu/drm/ttm/ttm_pool.c:556:39: note: within this loop
 556 | for (j = 0; j < TTM_DIM_ORDER; ++j)
 |   ^
   In file included from :
   drivers/gpu/drm/ttm/ttm_pool.c: In function 'ttm_pool_mgr_init':
>> include/linux/compiler_types.h:358:45: error: call to 
>> '__compiletime_assert_283' declared with attribute error: BUILD_BUG_ON 
>> failed: TTM_DIM_ORDER > MAX_ORDER
 358 | _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 | ^
   include/linux/compiler_types.h:339:25: note: in definition of macro 
'__compiletime_assert'
 339 | prefix ## suffix();  
   \
 | ^~
   include/linux/compiler_types.h:358:9: note: in expansion of macro 
'_compiletime_assert'
 358 | _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 | ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   include/linux/build_bug.h:50:9: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
  50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " 
#condition)
 | ^~~~
   drivers/gpu/drm/ttm/ttm_pool.c:744:9: note: in expansion of macro 
'BUILD_BUG_ON'
 744 | BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
 | ^~~~


vim +/__compiletime_assert_283 +358 include/linux/compiler_types.h

eb5c2d4b45e3d2 Will Deacon 2020-07-21  344  
eb5c2d4b45e3d2 Will Deacon 2020-07-21  345  #define 
_compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21  346  __compiletime_assert(condition, 
msg, prefix, suffix)
eb5c2d4b45e3d2 Will Deacon 2020-07-21  347  
eb5c2d4b45e3d2 Will Deacon 2020-07-21  348  /**
eb5c2d4b45e3d2 Will Deacon 2020-07-21  349   * compiletime_assert - break build 
and emit msg if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21  350   * @condition: a compile-time 
constant condition to check
eb5c2d4b45e3d2 Will Deacon 2020-07-21  351   * @msg:   a message to emit if 
condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21  352   *
eb5c2d4b45e3d2 Will De

[Intel-gfx] [PATCH 5.15 566/567] drm/i915: Dont use BAR mappings for ring buffers with LLC

[Greg Kroah-Hartman]

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -51,7 +51,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -96,7 +96,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);

[Intel-gfx] [PATCH 6.1 882/885] drm/i915: Dont use BAR mappings for ring buffers with LLC

[Greg Kroah-Hartman]

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);

[Intel-gfx] [PATCH 6.1 881/885] drm/i915: Dont use stolen memory for ring buffers with LLC

[Greg Kroah-Hartman]

From: John Harrison 

commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.

Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.

Signed-off-by: John Harrison 
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -116,7 +116,7 @@ static struct i915_vma *create_ring_vma(
 
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
  I915_BO_ALLOC_PM_VOLATILE);
-   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);

Re: [Intel-gfx] [PATCH v12 10/11] drm/virtio: Support memory shrinking

[Dmitry Osipenko]

On 3/7/23 21:25, Dmitry Osipenko wrote:
>> Not really a problem with this patchset, but having such branches looks
>> like a bug in the driver's GEM design. Whatever your GEM object needs or
>> does, it should be hidden in the implementation. Why is virtio doing this?
> There is another "VRAM" VirtIO-GPU BO type that doesn't implement the
> pin/unpin callbacks. Perhaps another option was to add the callbacks.

Although, the pin/unpin are optional. So yes, there was no need for the
extra branch, good catch.

-- 
Best regards,
Dmitry

Re: [Intel-gfx] [PATCH v12 10/11] drm/virtio: Support memory shrinking

[Dmitry Osipenko]

On 3/7/23 13:42, Thomas Zimmermann wrote:
> Hi
> 
> Am 05.03.23 um 23:10 schrieb Dmitry Osipenko:
> [...]
>>     *bo_ptr = bo;
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> index 4c09e313bebc..3f21512ff153 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> @@ -238,20 +238,32 @@ static int virtio_gpu_plane_prepare_fb(struct
>> drm_plane *plane,
>>   struct virtio_gpu_device *vgdev = dev->dev_private;
>>   struct virtio_gpu_framebuffer *vgfb;
>>   struct virtio_gpu_object *bo;
>> +    int err;
>>     if (!new_state->fb)
>>   return 0;
>>     vgfb = to_virtio_gpu_framebuffer(new_state->fb);
>>   bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
>> -    if (!bo || (plane->type == DRM_PLANE_TYPE_PRIMARY &&
>> !bo->guest_blob))
>> +
>> +    if (virtio_gpu_is_shmem(bo)) {
> 
> Not really a problem with this patchset, but having such branches looks
> like a bug in the driver's GEM design. Whatever your GEM object needs or
> does, it should be hidden in the implementation. Why is virtio doing this?

There is another "VRAM" VirtIO-GPU BO type that doesn't implement the
pin/unpin callbacks. Perhaps another option was to add the callbacks.

>> +    err = drm_gem_pin(>base.base);
> 
> As the driver uses GEM SHMEM, please call drm_gem_shmem_object_pin()
> directly and remove patch [09/11]. Same goes for the _unpin call below.
> 
> The problem with generic pinning interfaces is that there's no way of
> specifying where to pin to BO.  The problem is most apparent with TTM,
> where hardware often has multiple locations were buffer can be placed
> (VRAM, GART, system memory). So it's really a detail between the driver
> and the memory manager.
> 
> These generic internal GEM interfaces should only be used by DRM core
> and helpers. Drivers should use their memory manager's interface.

I'll switch to use drm_gem_shmem_object_pin() directly in v13, maybe add
virtio_gpu_gem_pin() helper for that. Thanks!

-- 
Best regards,
Dmitry

[Intel-gfx] [PATCH 6.2 0998/1001] drm/i915: Dont use BAR mappings for ring buffers with LLC

[Greg Kroah-Hartman]

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);

[Intel-gfx] [PATCH 6.2 0997/1001] drm/i915: Dont use stolen memory for ring buffers with LLC

[Greg Kroah-Hartman]

From: John Harrison 

commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.

Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.

Signed-off-by: John Harrison 
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -116,7 +116,7 @@ static struct i915_vma *create_ring_vma(
 
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
  I915_BO_ALLOC_PM_VOLATILE);
-   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);

Re: [Intel-gfx] [PATCH v2 1/7] drm/ttm: Fix a NULL pointer dereference

[Thomas Hellström]

On 3/7/23 17:55, Christian König wrote:

Am 07.03.23 um 15:46 schrieb Thomas Hellström:

The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().


Please make sure that this is pushed to drm-misc-fixes ASAP.

I've getting complains for this from different sides.

Thanks,
Christian.


Done.

/Thomas






Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4")
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: Alex Deucher 
Cc: Felix Kuehling 
Cc: Philip Yang 
Cc: Qiang Yu 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Tvrtko Ursulin 
Cc: "Thomas Hellström" 
Cc: Anshuman Gupta 
Cc: Arunpravin Paneer Selvam 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c 
b/drivers/gpu/drm/ttm/ttm_device.c

index c7a1862f322a..ae2f19dc9f81 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -158,7 +158,7 @@ int ttm_device_swapout(struct ttm_device *bdev, 
struct ttm_operation_ctx *ctx,

  struct ttm_buffer_object *bo = res->bo;
  uint32_t num_pages;
  -    if (!bo)
+    if (!bo || bo->resource != res)
  continue;
    num_pages = PFN_UP(bo->base.size);

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable HDCP2.x via GSC CS (rev11)

[Patchwork]

== Series Details ==

Series: Enable HDCP2.x via GSC CS (rev11)
URL   : https://patchwork.freedesktop.org/series/111876/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_111876v11_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_workarounds@suspend-resume:
- {shard-tglu}:   NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-2/igt@gem_workarou...@suspend-resume.html

  * igt@kms_rotation_crc@primary-y-tiled-reflect-x-270:
- {shard-rkl}:[PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12820/shard-rkl-6/igt@kms_rotation_...@primary-y-tiled-reflect-x-270.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-rkl-6/igt@kms_rotation_...@primary-y-tiled-reflect-x-270.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ccs@ctrl-surf-copy:
- shard-tglu-10:  NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_...@ctrl-surf-copy.html

  * igt@gem_ccs@suspend-resume:
- shard-tglu-10:  NOTRUN -> [SKIP][5] ([i915#5325])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_...@suspend-resume.html

  * igt@gem_create@create-ext-cpu-access-big:
- shard-tglu-9:   NOTRUN -> [SKIP][6] ([i915#6335])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-big.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-tglu-10:  NOTRUN -> [SKIP][7] ([fdo#109314])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-tglu-10:  NOTRUN -> [SKIP][8] ([i915#280])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][9] -> [ABORT][10] ([i915#180])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12820/shard-apl7/igt@gem_...@in-flight-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-apl3/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-tglu-10:  NOTRUN -> [FAIL][11] ([i915#6117])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_exec_balan...@parallel-ordering.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][12] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-glk3/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_gttfill@multigpu-basic:
- shard-tglu-10:  NOTRUN -> [SKIP][13] ([i915#7697])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_exec_gttf...@multigpu-basic.html

  * igt@gem_lmem_evict@dontneed-evict-race:
- shard-tglu-10:  NOTRUN -> [SKIP][14] ([i915#7582])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_lmem_ev...@dontneed-evict-race.html

  * igt@gem_lmem_swapping@random:
- shard-tglu-10:  NOTRUN -> [SKIP][15] ([i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_lmem_swapp...@random.html

  * igt@gem_lmem_swapping@smem-oom:
- shard-glk:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-glk1/igt@gem_lmem_swapp...@smem-oom.html

  * igt@gem_mmap_wc@set-cache-level:
- shard-tglu-9:   NOTRUN -> [SKIP][17] ([i915#1850])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-9/igt@gem_mmap...@set-cache-level.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-tglu-10:  NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v11/shard-tglu-10/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-tglu-9:   NOTRUN -> [SKIP][19] ([i915#4270])
   [19]: 

Re: [Intel-gfx] [PATCH v2 1/7] drm/ttm: Fix a NULL pointer dereference

[Christian König]

Am 07.03.23 um 15:46 schrieb Thomas Hellström:

The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().


Please make sure that this is pushed to drm-misc-fixes ASAP.

I've getting complains for this from different sides.

Thanks,
Christian.



Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4")
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: Alex Deucher 
Cc: Felix Kuehling 
Cc: Philip Yang 
Cc: Qiang Yu 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Tvrtko Ursulin 
Cc: "Thomas Hellström" 
Cc: Anshuman Gupta 
Cc: Arunpravin Paneer Selvam 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index c7a1862f322a..ae2f19dc9f81 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -158,7 +158,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct 
ttm_operation_ctx *ctx,
struct ttm_buffer_object *bo = res->bo;
uint32_t num_pages;
  
-			if (!bo)

+   if (!bo || bo->resource != res)
continue;
  
  			num_pages = PFN_UP(bo->base.size);

[Intel-gfx] Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 5.15-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Don't use BAR mappings for ring buffers with LLC

to the 5.15-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 85636167e3206c3fbd52254fc432991cc4e90194 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 15 Feb 2023 17:11:01 -0800
Subject: drm/i915: Don't use BAR mappings for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -51,7 +51,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -96,7 +96,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);


Patches currently in stable-queue which might be from john.c.harri...@intel.com 
are

queue-5.15/drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch

[Intel-gfx] Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 6.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Don't use BAR mappings for ring buffers with LLC

to the 6.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 85636167e3206c3fbd52254fc432991cc4e90194 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 15 Feb 2023 17:11:01 -0800
Subject: drm/i915: Don't use BAR mappings for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);


Patches currently in stable-queue which might be from john.c.harri...@intel.com 
are

queue-6.1/drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
queue-6.1/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch

[Intel-gfx] Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has been added to the 6.1-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Don't use stolen memory for ring buffers with LLC

to the 6.1-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch
and it can be found in the queue-6.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 15 Feb 2023 17:11:00 -0800
Subject: drm/i915: Don't use stolen memory for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: John Harrison 

commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.

Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.

Signed-off-by: John Harrison 
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -116,7 +116,7 @@ static struct i915_vma *create_ring_vma(
 
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
  I915_BO_ALLOC_PM_VOLATILE);
-   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);


Patches currently in stable-queue which might be from john.c.harri...@intel.com 
are

queue-6.1/drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
queue-6.1/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch

[Intel-gfx] [PATCH v2 1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL

[Ville Syrjala]

From: Ville Syrjälä 

AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.

v2: Do the same for FDI

Reviewed-by: Imre Deak  #v1
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
 drivers/gpu/drm/i915/display/intel_fdi.c | 4 +---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bfd1e30a27b4..4af2ba2dfcad 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2624,8 +2624,7 @@ static void intel_disable_ddi_buf(struct intel_encoder 
*encoder,
 
if (intel_crtc_has_dp_encoder(crtc_state)) {
val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, 
crtc_state));
-   val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
-   val |= DP_TP_CTL_LINK_TRAIN_PAT1;
+   val &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), 
val);
}
 
@@ -3153,8 +3152,7 @@ static void intel_ddi_prepare_link_retrain(struct 
intel_dp *intel_dp,
wait = true;
}
 
-   dp_tp_ctl &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
-   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT1;
+   dp_tp_ctl &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), 
dp_tp_ctl);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, 
crtc_state));
 
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c 
b/drivers/gpu/drm/i915/display/intel_fdi.c
index f62d9a931349..f3ac34b0f3fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -846,9 +846,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
intel_de_posting_read(dev_priv, DDI_BUF_CTL(PORT_E));
 
/* Disable DP_TP_CTL and FDI_RX_CTL and retry */
-   intel_de_rmw(dev_priv, DP_TP_CTL(PORT_E),
-DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK,
-DP_TP_CTL_LINK_TRAIN_PAT1);
+   intel_de_rmw(dev_priv, DP_TP_CTL(PORT_E), DP_TP_CTL_ENABLE, 0);
intel_de_posting_read(dev_priv, DP_TP_CTL(PORT_E));
 
intel_wait_ddi_buf_idle(dev_priv, PORT_E);
-- 
2.39.2

[Intel-gfx] Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has been added to the 6.2-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Don't use stolen memory for ring buffers with LLC

to the 6.2-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch
and it can be found in the queue-6.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 15 Feb 2023 17:11:00 -0800
Subject: drm/i915: Don't use stolen memory for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: John Harrison 

commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.

Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is safest to just not use it.

Signed-off-by: John Harrison 
Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-2-john.c.harri...@intel.com
(cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -116,7 +116,7 @@ static struct i915_vma *create_ring_vma(
 
obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE |
  I915_BO_ALLOC_PM_VOLATILE);
-   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt))
+   if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt) && !HAS_LLC(i915))
obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, size);


Patches currently in stable-queue which might be from john.c.harri...@intel.com 
are

queue-6.2/drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
queue-6.2/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch

[Intel-gfx] Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has been added to the 6.2-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

drm/i915: Don't use BAR mappings for ring buffers with LLC

to the 6.2-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
and it can be found in the queue-6.2 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From 85636167e3206c3fbd52254fc432991cc4e90194 Mon Sep 17 00:00:00 2001
From: John Harrison 
Date: Wed, 15 Feb 2023 17:11:01 -0800
Subject: drm/i915: Don't use BAR mappings for ring buffers with LLC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: John Harrison 

commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.

Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.

Signed-off-by: John Harrison 
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: intel-gfx@lists.freedesktop.org
Cc:  # v4.9+
Tested-by: Jouni Högander 
Reviewed-by: Daniele Ceraolo Spurio 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/gt/intel_ring.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,7 +53,7 @@ int intel_ring_pin(struct intel_ring *ri
if (unlikely(ret))
goto err_unpin;
 
-   if (i915_vma_is_map_and_fenceable(vma)) {
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915)) {
addr = (void __force *)i915_vma_pin_iomap(vma);
} else {
int type = i915_coherent_map_type(vma->vm->i915, vma->obj, 
false);
@@ -98,7 +98,7 @@ void intel_ring_unpin(struct intel_ring
return;
 
i915_vma_unset_ggtt_write(vma);
-   if (i915_vma_is_map_and_fenceable(vma))
+   if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
i915_vma_unpin_iomap(vma);
else
i915_gem_object_unpin_map(vma->obj);


Patches currently in stable-queue which might be from john.c.harri...@intel.com 
are

queue-6.2/drm-i915-don-t-use-bar-mappings-for-ring-buffers-with-llc.patch
queue-6.2/drm-i915-don-t-use-stolen-memory-for-ring-buffers-with-llc.patch

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/xelp: Implement Wa_1606376872

[Patchwork]

== Series Details ==

Series: drm/i915/xelp: Implement Wa_1606376872
URL   : https://patchwork.freedesktop.org/series/114745/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114745v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 10)
--

  No changes in participating hosts

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@device_reset@unbind-cold-reset-rebind:
- shard-tglu-10:  NOTRUN -> [SKIP][1] ([i915#7701])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html

  * igt@fbdev@nullptr:
- shard-tglu-9:   NOTRUN -> [SKIP][2] ([i915#2582])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@fb...@nullptr.html

  * igt@gem_basic@multigpu-create-close:
- shard-tglu-10:  NOTRUN -> [SKIP][3] ([i915#7697])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_ba...@multigpu-create-close.html

  * igt@gem_ccs@ctrl-surf-copy-new-ctx:
- shard-tglu-10:  NOTRUN -> [SKIP][4] ([i915#5325])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_...@ctrl-surf-copy-new-ctx.html

  * igt@gem_create@create-ext-cpu-access-big:
- shard-tglu-9:   NOTRUN -> [SKIP][5] ([i915#6335])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-big.html

  * igt@gem_ctx_param@set-priority-not-supported:
- shard-tglu-10:  NOTRUN -> [SKIP][6] ([fdo#109314])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_ctx_pa...@set-priority-not-supported.html

  * igt@gem_ctx_sseu@invalid-sseu:
- shard-tglu-9:   NOTRUN -> [SKIP][7] ([i915#280])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_ctx_s...@invalid-sseu.html

  * igt@gem_exec_balancer@parallel-ordering:
- shard-tglu-10:  NOTRUN -> [FAIL][8] ([i915#6117])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_exec_balan...@parallel-ordering.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][9] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-glk2/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-tglu-10:  NOTRUN -> [FAIL][10] ([i915#2842]) +1 similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-10:  NOTRUN -> [SKIP][11] ([fdo#109283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_exec_par...@rsvd2-dirt.html

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

  * igt@gem_huc_copy@huc-copy:
- shard-tglu-9:   NOTRUN -> [SKIP][13] ([i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_evict@dontneed-evict-race:
- shard-tglu-10:  NOTRUN -> [SKIP][14] ([i915#7582])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_lmem_ev...@dontneed-evict-race.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-tglu-10:  NOTRUN -> [SKIP][15] ([i915#4613]) +5 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-10/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-tglu-9:   NOTRUN -> [SKIP][16] ([i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-glk2/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_media_vme:
- shard-tglu-9:   NOTRUN -> [SKIP][18] ([i915#284])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_media_vme.html

  * igt@gem_mmap_wc@set-cache-level:
- shard-tglu-9:   NOTRUN -> [SKIP][19] ([i915#1850])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114745v1/shard-tglu-9/igt@gem_mmap...@set-cache-level.html

  * igt@gem_pwrite@basic-exhaustion:
- 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap 
framebuffer obj
URL   : https://patchwork.freedesktop.org/series/114775/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12821 -> Patchwork_114775v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (36 -> 36)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

New tests
-

  New tests have been introduced between CI_DRM_12821 and Patchwork_114775v1:

### New IGT tests (1) ###

  * igt@fbdev:
- Statuses :
- Exec time: [None] s

  

Known issues


  Here are the changes found in Patchwork_114775v1 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_114775v1/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_114775v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][3] ([i915#7913])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#8073])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@reset:
- bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#4983] / [i915#7913])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/bat-rpls-2/igt@i915_selftest@l...@reset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-1: [PASS][9] -> [DMESG-FAIL][10] ([i915#6367])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/bat-rpls-1/igt@i915_selftest@l...@slpc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html

  * igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka:  NOTRUN -> [SKIP][11] ([fdo#109271]) +16 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][12] ([i915#7828])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][13] ([i915#1845])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][14] ([i915#6687] / [i915#7978]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12821/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114775v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
  [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
  [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073


Build changes
-

  * Linux: CI_DRM_12821 -> Patchwork_114775v1

  CI-20190529: 20190529
  CI_DRM_12821: 24f94240c4bca70cadfd00528ffd56c3049e5f58 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  

Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

[Maxime Ripard]

Hi,

On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
> 
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> for msm and vc4 landed. nouveau and i915 have their own commit
> routines, doing something similar.
> 
> For everyone else it's probably better to remove the use-after-free
> bug, and encourage folks to use the async support instead. The
> affected drivers which register a legacy cursor plane and don't either
> use the new async stuff or their own commit routine are: amdgpu,
> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
> 
> Inspired by an amdgpu bug report.

Thanks for submitting that patch. It's been in the downstream RPi tree
for a while, so I'd really like it to be merged eventually :)

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap 
framebuffer obj
URL   : https://patchwork.freedesktop.org/series/114775/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915: Add a function to mmap framebuffer obj

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap 
framebuffer obj
URL   : https://patchwork.freedesktop.org/series/114775/
State : warning

== Summary ==

Error: dim checkpatch failed
d0b102d9dd12 drm/i915: Add a function to mmap framebuffer obj
-:120: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#120: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1040:
+   GEM_BUG_ON(obj && obj->ops->mmap_ops);

-:126: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#126: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:1046:
+   GEM_BUG_ON(obj && !obj->ops->mmap_ops);

total: 0 errors, 2 warnings, 0 checks, 148 lines checked
36875aac2dd5 drm/i915/display: Implement fb_mmap callback function

Re: [Intel-gfx] [PATCH RFC 3/3] drm/i915/display: Implement fb_mmap callback function

[Das, Nirmoy]

Hi Ville,

On 3/6/2023 3:32 PM, Ville Syrjälä wrote:

On Mon, Mar 06, 2023 at 11:28:50AM +0100, Nirmoy Das wrote:

If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which also gives
driver more control.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/display/intel_fbdev.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 98ae3a3a986a..ed0f9e2af3ed 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "gem/i915_gem_lmem.h"

+#include "gem/i915_gem_mman.h"
  
  #include "i915_drv.h"

  #include "intel_display_types.h"
@@ -120,6 +122,23 @@ static int intel_fbdev_pan_display(struct 
fb_var_screeninfo *var,
return ret;
  }
  
+#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)

+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+   struct drm_gem_object *bo = drm_gem_fb_get_obj(>fb->base, 0);
+   struct drm_i915_gem_object *obj = to_intel_bo(bo);
+   struct drm_device *dev = fbdev->helper.dev;

You seem to be missing the fb vs. mmio handling here entirely.



Could you please expand this more, I am not so familiar to fbdev code.





+
+   vma->vm_page_prot =
+   pgprot_writecombine(vm_get_page_prot(vma->vm_flags));

Does that do something sane on eg. !PAT?


+
+   if (obj->stolen)
+   return vm_iomap_memory(vma, info->fix.smem_start,
+  info->fix.smem_len);

Why doesn't i915_gem_object_mmap() know how to handle stolen?



Sent out another rfc series to address this.


Regards,

Nirmoy




+
+   return i915_gem_object_mmap(obj, vma);
+}
  static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -131,6 +150,7 @@ static const struct fb_ops intelfb_ops = {
.fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_pan_display = intel_fbdev_pan_display,
.fb_blank = intel_fbdev_blank,
+   .fb_mmap = intel_fbdev_mmap,
  };
  
  static int intelfb_alloc(struct drm_fb_helper *helper,

--
2.39.0

[Intel-gfx] [PATCH v2 7/7] drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting

[Thomas Hellström]

When swapping in, or under memory pressure ttm_tt_populate() may sleep
for a substantiable amount of time. Allow interrupts during the sleep.
This will also allow us to inject -EINTR errors during swapin in upcoming
patches.

Also avoid returning VM_FAULT_OOM, since that will confuse the core
mm, making it print out a confused message and retrying the fault.
Return VM_FAULT_SIGBUS also under OOM conditions.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index ca7744b852f5..4bca6b54520a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -218,14 +218,21 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
prot = ttm_io_prot(bo, bo->resource, prot);
if (!bo->resource->bus.is_iomem) {
struct ttm_operation_ctx ctx = {
-   .interruptible = false,
+   .interruptible = true,
.no_wait_gpu = false,
.force_alloc = true
};
 
ttm = bo->ttm;
-   if (ttm_tt_populate(bdev, bo->ttm, ))
-   return VM_FAULT_OOM;
+   err = ttm_tt_populate(bdev, bo->ttm, );
+   if (err) {
+   if (err == -EINTR || err == -ERESTARTSYS ||
+   err == -EAGAIN)
+   return VM_FAULT_NOPAGE;
+
+   pr_debug("TTM fault hit %pe.\n", ERR_PTR(err));
+   return VM_FAULT_SIGBUS;
+   }
} else {
/* Iomem should not be marked encrypted */
prot = pgprot_decrypted(prot);
-- 
2.39.2

[Intel-gfx] [PATCH v2 6/7] drm/ttm: Reduce the number of used allocation orders for TTM pages

[Thomas Hellström]

When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
Reduce the page max order to the system PMD size, as we can then be nicer
to the system and avoid splitting gigantic pages.

Looking forward to when we might be able to swap out PMD size folios
without splitting, this will also be a benefit.

v2:
- Include all orders up to the PMD size (Christian König)

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 0b6e20613d19..939845d853af 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -47,6 +47,9 @@
 
 #include "ttm_module.h"
 
+#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
+#define TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
+
 /**
  * struct ttm_pool_dma - Helper object for coherent DMA mappings
  *
@@ -65,11 +68,11 @@ module_param(page_pool_size, ulong, 0644);
 
 static atomic_long_t allocated_pages;
 
-static struct ttm_pool_type global_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
 
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
 
 static spinlock_t shrinker_lock;
 static struct list_head shrinker_list;
@@ -431,7 +434,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
else
gfp_flags |= GFP_HIGHUSER;
 
-   for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
+   for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
 num_pages;
 order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
@@ -550,7 +553,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device 
*dev,
 
if (use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
-   for (j = 0; j < MAX_ORDER; ++j)
+   for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_init(>caching[i].orders[j],
   pool, i, j);
}
@@ -570,7 +573,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
 
if (pool->use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
-   for (j = 0; j < MAX_ORDER; ++j)
+   for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_fini(>caching[i].orders[j]);
}
 
@@ -624,7 +627,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
unsigned int i;
 
seq_puts(m, "\t ");
-   for (i = 0; i < MAX_ORDER; ++i)
+   for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " ---%2u---", i);
seq_puts(m, "\n");
 }
@@ -635,7 +638,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type 
*pt,
 {
unsigned int i;
 
-   for (i = 0; i < MAX_ORDER; ++i)
+   for (i = 0; i < TTM_DIM_ORDER; ++i)
seq_printf(m, " %8u", ttm_pool_type_count([i]));
seq_puts(m, "\n");
 }
@@ -738,13 +741,15 @@ int ttm_pool_mgr_init(unsigned long num_pages)
 {
unsigned int i;
 
+   BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
+
if (!page_pool_size)
page_pool_size = num_pages;
 
spin_lock_init(_lock);
INIT_LIST_HEAD(_list);
 
-   for (i = 0; i < MAX_ORDER; ++i) {
+   for (i = 0; i < TTM_DIM_ORDER; ++i) {
ttm_pool_type_init(_write_combined[i], NULL,
   ttm_write_combined, i);
ttm_pool_type_init(_uncached[i], NULL, ttm_uncached, i);
@@ -777,7 +782,7 @@ void ttm_pool_mgr_fini(void)
 {
unsigned int i;
 
-   for (i = 0; i < MAX_ORDER; ++i) {
+   for (i = 0; i < TTM_DIM_ORDER; ++i) {
ttm_pool_type_fini(_write_combined[i]);
ttm_pool_type_fini(_uncached[i]);
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 5/7] drm/ttm: Don't print error message if eviction was interrupted

[Thomas Hellström]

Avoid printing an error message if eviction was interrupted by,
for example, the user pressing CTRL-C. That may happen if eviction
is waiting for something, like for example a free batch-buffer.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 882c2fa346f3..459f1b4440da 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -464,7 +464,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
if (ret == -EMULTIHOP) {
ret = ttm_bo_bounce_temp_buffer(bo, _mem, ctx, );
if (ret) {
-   pr_err("Buffer eviction failed\n");
+   if (ret != -ERESTARTSYS && ret != -EINTR)
+   pr_err("Buffer eviction failed\n");
ttm_resource_free(bo, _mem);
goto out;
}
-- 
2.39.2

[Intel-gfx] [PATCH v2 4/7] drm/ttm: Unexport ttm_global_swapout()

[Thomas Hellström]

Unexport ttm_global_swapout() since it is not used outside of TTM.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_device.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index ae2f19dc9f81..64a59f46f6c3 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -137,7 +137,6 @@ int ttm_global_swapout(struct ttm_operation_ctx *ctx, gfp_t 
gfp_flags)
mutex_unlock(_global_mutex);
return ret;
 }
-EXPORT_SYMBOL(ttm_global_swapout);
 
 int ttm_device_swapout(struct ttm_device *bdev, struct ttm_operation_ctx *ctx,
   gfp_t gfp_flags)
-- 
2.39.2

[Intel-gfx] [PATCH v2 3/7] drm/ttm: Use the BIT macro for the TTM_TT_FLAGs

[Thomas Hellström]

New code is recommended to use the BIT macro instead of the explicit
shifts. Change the older defines so that we can keep the style consistent
with upcoming changes.

v2:
- Also change the value of the _PRIV_POPULATED bit (Christian König)

Signed-off-by: Thomas Hellström 
---
 include/drm/ttm/ttm_tt.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index b7d3f3843f1e..977ca195a536 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -83,12 +83,12 @@ struct ttm_tt {
 * set by TTM after ttm_tt_populate() has successfully returned, and is
 * then unset when TTM calls ttm_tt_unpopulate().
 */
-#define TTM_TT_FLAG_SWAPPED(1 << 0)
-#define TTM_TT_FLAG_ZERO_ALLOC (1 << 1)
-#define TTM_TT_FLAG_EXTERNAL   (1 << 2)
-#define TTM_TT_FLAG_EXTERNAL_MAPPABLE  (1 << 3)
+#define TTM_TT_FLAG_SWAPPEDBIT(0)
+#define TTM_TT_FLAG_ZERO_ALLOC BIT(1)
+#define TTM_TT_FLAG_EXTERNAL   BIT(2)
+#define TTM_TT_FLAG_EXTERNAL_MAPPABLE  BIT(3)
 
-#define TTM_TT_FLAG_PRIV_POPULATED  (1U << 31)
+#define TTM_TT_FLAG_PRIV_POPULATED BIT(4)
uint32_t page_flags;
/** @num_pages: Number of pages in the page array. */
uint32_t num_pages;
-- 
2.39.2

[Intel-gfx] [PATCH v2 2/7] drm/ttm/pool: Fix ttm_pool_alloc error path

[Thomas Hellström]

When hitting an error, the error path forgot to unmap dma mappings and
could call set_pages_wb() on already uncached pages.

Fix this by introducing a common __ttm_pool_free() function that
does the right thing.

v2:
- Simplify __ttm_pool_free() (Christian König)

Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Cc: Christian König 
Cc: Dave Airlie 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/ttm/ttm_pool.c | 68 +++---
 1 file changed, 38 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index aa116a7bbae3..0b6e20613d19 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -367,6 +367,30 @@ static int ttm_pool_page_allocated(struct ttm_pool *pool, 
unsigned int order,
return 0;
 }
 
+static void __ttm_pool_free(struct ttm_pool *pool, struct ttm_tt *tt,
+   enum ttm_caching caching,
+   pgoff_t start_page, pgoff_t end_page)
+{
+   struct page **pages = tt->pages;
+   unsigned int order;
+   pgoff_t i, nr;
+
+   for (i = start_page; i < end_page; i += nr, pages += nr) {
+   struct ttm_pool_type *pt = NULL;
+
+   order = ttm_pool_page_order(pool, *pages);
+   nr = (1UL << order);
+   if (tt->dma_address)
+   ttm_pool_unmap(pool, tt->dma_address[i], nr);
+
+   pt = ttm_pool_select_type(pool, caching, order);
+   if (pt)
+   ttm_pool_type_give(pt, *pages);
+   else
+   ttm_pool_free_page(pool, caching, order, *pages);
+   }
+}
+
 /**
  * ttm_pool_alloc - Fill a ttm_tt object
  *
@@ -382,12 +406,14 @@ static int ttm_pool_page_allocated(struct ttm_pool *pool, 
unsigned int order,
 int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
   struct ttm_operation_ctx *ctx)
 {
-   unsigned long num_pages = tt->num_pages;
+   pgoff_t num_pages = tt->num_pages;
dma_addr_t *dma_addr = tt->dma_address;
struct page **caching = tt->pages;
struct page **pages = tt->pages;
+   enum ttm_caching page_caching;
gfp_t gfp_flags = GFP_USER;
-   unsigned int i, order;
+   pgoff_t caching_divide;
+   unsigned int order;
struct page *p;
int r;
 
@@ -410,6 +436,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
 order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
 
+   page_caching = tt->caching;
pt = ttm_pool_select_type(pool, tt->caching, order);
p = pt ? ttm_pool_type_take(pt) : NULL;
if (p) {
@@ -418,6 +445,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
if (r)
goto error_free_page;
 
+   caching = pages;
do {
r = ttm_pool_page_allocated(pool, order, p,
_addr,
@@ -426,14 +454,15 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt 
*tt,
if (r)
goto error_free_page;
 
+   caching = pages;
if (num_pages < (1 << order))
break;
 
p = ttm_pool_type_take(pt);
} while (p);
-   caching = pages;
}
 
+   page_caching = ttm_cached;
while (num_pages >= (1 << order) &&
   (p = ttm_pool_alloc_page(pool, gfp_flags, order))) {
 
@@ -442,6 +471,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
   tt->caching);
if (r)
goto error_free_page;
+   caching = pages;
}
r = ttm_pool_page_allocated(pool, order, p, _addr,
_pages, );
@@ -468,15 +498,13 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt 
*tt,
return 0;
 
 error_free_page:
-   ttm_pool_free_page(pool, tt->caching, order, p);
+   ttm_pool_free_page(pool, page_caching, order, p);
 
 error_free_all:
num_pages = tt->num_pages - num_pages;
-   for (i = 0; i < num_pages; ) {
-   order = ttm_pool_page_order(pool, tt->pages[i]);
-   ttm_pool_free_page(pool, tt->caching, order, tt->pages[i]);
-   i += 1 << order;
-   }
+   caching_divide = caching - tt->pages;
+   __ttm_pool_free(pool, 

[Intel-gfx] [PATCH v2 1/7] drm/ttm: Fix a NULL pointer dereference

[Thomas Hellström]

The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().

Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4")
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: Alex Deucher 
Cc: Felix Kuehling 
Cc: Philip Yang 
Cc: Qiang Yu 
Cc: Matthew Auld 
Cc: Nirmoy Das 
Cc: Tvrtko Ursulin 
Cc: "Thomas Hellström" 
Cc: Anshuman Gupta 
Cc: Arunpravin Paneer Selvam 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index c7a1862f322a..ae2f19dc9f81 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -158,7 +158,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct 
ttm_operation_ctx *ctx,
struct ttm_buffer_object *bo = res->bo;
uint32_t num_pages;
 
-   if (!bo)
+   if (!bo || bo->resource != res)
continue;
 
num_pages = PFN_UP(bo->base.size);
-- 
2.39.2

[Intel-gfx] [RFC PATCH 2/2] drm/i915/display: Implement fb_mmap callback function

[Nirmoy Das]

If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will use cpu to access
the framebuffer.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 3659350061a7..67427d020bd3 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
 
 #include "i915_drv.h"
 #include "intel_display_types.h"
@@ -120,6 +122,16 @@ static int intel_fbdev_pan_display(struct 
fb_var_screeninfo *var,
return ret;
 }
 
+#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)
+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+   struct drm_gem_object *bo = drm_gem_fb_get_obj(>fb->base, 0);
+   struct drm_i915_gem_object *obj = to_intel_bo(bo);
+
+   return i915_gem_fb_mmap(obj, vma);
+}
+
 static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -131,6 +143,7 @@ static const struct fb_ops intelfb_ops = {
.fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_pan_display = intel_fbdev_pan_display,
.fb_blank = intel_fbdev_blank,
+   .fb_mmap = intel_fbdev_mmap,
 };
 
 static int intelfb_alloc(struct drm_fb_helper *helper,
-- 
2.39.0

[Intel-gfx] [RFC PATCH 1/2] drm/i915: Add a function to mmap framebuffer obj

[Nirmoy Das]

Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 121 ++-
 drivers/gpu/drm/i915/gem/i915_gem_mman.h |   2 +-
 2 files changed, 77 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d3c1dee16af2..373ff94ed616 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -927,53 +927,15 @@ static struct file *mmap_singleton(struct 
drm_i915_private *i915)
return file;
 }
 
-/*
- * This overcomes the limitation in drm_gem_mmap's assignment of a
- * drm_gem_object as the vma->vm_private_data. Since we need to
- * be able to resolve multiple mmap offsets which could be tied
- * to a single gem object.
- */
-int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+static int
+i915_gem_object_mmap(struct drm_i915_gem_object *obj,
+struct i915_mmap_offset *mmo,
+struct vm_area_struct *vma)
 {
-   struct drm_vma_offset_node *node;
-   struct drm_file *priv = filp->private_data;
-   struct drm_device *dev = priv->minor->dev;
-   struct drm_i915_gem_object *obj = NULL;
-   struct i915_mmap_offset *mmo = NULL;
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct drm_device *dev = >drm;
struct file *anon;
 
-   if (drm_dev_is_unplugged(dev))
-   return -ENODEV;
-
-   rcu_read_lock();
-   drm_vma_offset_lock_lookup(dev->vma_offset_manager);
-   node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
- vma->vm_pgoff,
- vma_pages(vma));
-   if (node && drm_vma_node_is_allowed(node, priv)) {
-   /*
-* Skip 0-refcnted objects as it is in the process of being
-* destroyed and will be invalid when the vma manager lock
-* is released.
-*/
-   if (!node->driver_private) {
-   mmo = container_of(node, struct i915_mmap_offset, 
vma_node);
-   obj = i915_gem_object_get_rcu(mmo->obj);
-
-   GEM_BUG_ON(obj && obj->ops->mmap_ops);
-   } else {
-   obj = i915_gem_object_get_rcu
-   (container_of(node, struct drm_i915_gem_object,
- base.vma_node));
-
-   GEM_BUG_ON(obj && !obj->ops->mmap_ops);
-   }
-   }
-   drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
-   rcu_read_unlock();
-   if (!obj)
-   return node ? -EACCES : -EINVAL;
-
if (i915_gem_object_is_readonly(obj)) {
if (vma->vm_flags & VM_WRITE) {
i915_gem_object_put(obj);
@@ -1005,7 +967,7 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
if (obj->ops->mmap_ops) {
vma->vm_page_prot = 
pgprot_decrypted(vm_get_page_prot(vma->vm_flags));
vma->vm_ops = obj->ops->mmap_ops;
-   vma->vm_private_data = node->driver_private;
+   vma->vm_private_data = obj->base.vma_node.driver_private;
return 0;
}
 
@@ -1043,6 +1005,75 @@ int i915_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return 0;
 }
 
+/*
+ * This overcomes the limitation in drm_gem_mmap's assignment of a
+ * drm_gem_object as the vma->vm_private_data. Since we need to
+ * be able to resolve multiple mmap offsets which could be tied
+ * to a single gem object.
+ */
+int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+   struct drm_vma_offset_node *node;
+   struct drm_file *priv = filp->private_data;
+   struct drm_device *dev = priv->minor->dev;
+   struct drm_i915_gem_object *obj = NULL;
+   struct i915_mmap_offset *mmo = NULL;
+
+   if (drm_dev_is_unplugged(dev))
+   return -ENODEV;
+
+   rcu_read_lock();
+   drm_vma_offset_lock_lookup(dev->vma_offset_manager);
+   node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
+ vma->vm_pgoff,
+ vma_pages(vma));
+   if (node && drm_vma_node_is_allowed(node, priv)) {
+   /*
+* Skip 0-refcnted objects as it is in the process of being
+* destroyed and will be invalid when the vma manager lock
+* is released.
+*/
+   if (!node->driver_private) {
+   mmo = container_of(node, struct i915_mmap_offset, 
vma_node);
+   obj = i915_gem_object_get_rcu(mmo->obj);
+
+   GEM_BUG_ON(obj && 

[Intel-gfx] [PATCH v2 0/7] drm/ttm: Small fixes / cleanups in prep for shrinking

[Thomas Hellström]

I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error message if
eviction was interrupted"). It would be nice to have these reviewed and
merged while reworking the rest.

v2:
- Simplify __ttm_pool_free().
- Fix the TTM_TT_FLAG bit numbers.
- Keep all allocation orders for TTM pages at or below PMD order

Thomas Hellström (7):
  drm/ttm: Fix a NULL pointer dereference
  drm/ttm/pool: Fix ttm_pool_alloc error path
  drm/ttm: Use the BIT macro for the TTM_TT_FLAGs
  drm/ttm: Unexport ttm_global_swapout()
  drm/ttm: Don't print error message if eviction was interrupted
  drm/ttm: Reduce the number of used allocation orders for TTM pages
  drm/ttm: Make the call to ttm_tt_populate() interruptible when
faulting

 drivers/gpu/drm/ttm/ttm_bo.c |  3 +-
 drivers/gpu/drm/ttm/ttm_bo_vm.c  | 13 -
 drivers/gpu/drm/ttm/ttm_device.c |  3 +-
 drivers/gpu/drm/ttm/ttm_pool.c   | 95 ++--
 include/drm/ttm/ttm_tt.h | 10 ++--
 5 files changed, 72 insertions(+), 52 deletions(-)

-- 
2.39.2

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes

[Jani Nikula]

On Tue, 07 Mar 2023, Ville Syrjälä  wrote:
> On Tue, Mar 07, 2023 at 02:24:08PM +0200, Jani Nikula wrote:
>> On Mon, 06 Mar 2023, Ville Syrjala  wrote:
>> > From: Ville Syrjälä 
>> >
>> > Add some (probably overkill) locking to protect the vblank
>> > timestamping constants updates during seamless M/N fastsets.
>> >
>> > As everything should be naturally aligned I think the individual
>> > pieces should probably end up updating atomically enough. So this
>> > is only really meant to guarantee everyone sees a consistent whole.
>> >
>> > All the drm_vblank.c usage is covered by vblank_time_lock,
>> > and uncore.lock will take care of __intel_get_crtc_scanline()
>> > that can also be called from outside the core vblank functionality.
>> 
>> The patch seems to do what it says on the box, but I increasingly
>> dislike the use of uncore.lock for anything other than the nuts and
>> bolts of uncore.
>
> Yeah, it's not really great. Hence the TODO I left behind there.

Okay,

Reviewed-by: Jani Nikula 

>
>> 
>> BR,
>> Jani.
>> 
>> >
>> > Currently only crtc_clock and framedur_ns can change, but in
>> > the future might fastset also across eg. vtotal/vblank_end
>> > changes, so let's just grab the locks across the whole thing.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_display.c | 24 +++-
>> >  1 file changed, 23 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> > b/drivers/gpu/drm/i915/display/intel_display.c
>> > index a1fbdf32bd21..020320468967 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -5908,6 +5908,8 @@ void intel_crtc_update_active_timings(const struct 
>> > intel_crtc_state *crtc_state)
>> >struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>> >struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> >struct drm_display_mode adjusted_mode;
>> > +  int vmax_vblank_start = 0;
>> > +  unsigned long irqflags;
>> >  
>> >drm_mode_init(_mode, _state->hw.adjusted_mode);
>> >  
>> > @@ -5915,11 +5917,28 @@ void intel_crtc_update_active_timings(const struct 
>> > intel_crtc_state *crtc_state)
>> >adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
>> >adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
>> >adjusted_mode.crtc_vblank_start = 
>> > intel_vrr_vmin_vblank_start(crtc_state);
>> > -  crtc->vmax_vblank_start = 
>> > intel_vrr_vmax_vblank_start(crtc_state);
>> > +  vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
>> >}
>> >  
>> > +  /*
>> > +   * Belts and suspenders locking to guarantee everyone sees 100%
>> > +   * consistent state during fastset seamless refresh rate changes.
>> > +   *
>> > +   * vblank_time_lock takes care of all drm_vblank.c stuff, and
>> > +   * uncore.lock takes care of __intel_get_crtc_scanline() which
>> > +   * may get called elsewhere as well.
>> > +   *
>> > +   * TODO maybe just protect everything (including
>> > +   * __intel_get_crtc_scanline()) with vblank_time_lock?
>> > +   * Need to audit everything to make sure it's safe.
>> > +   */
>> > +  spin_lock_irqsave(_priv->drm.vblank_time_lock, irqflags);
>> > +  spin_lock(_priv->uncore.lock);
>> > +
>> >drm_calc_timestamping_constants(>base, _mode);
>> >  
>> > +  crtc->vmax_vblank_start = vmax_vblank_start;
>> > +
>> >crtc->mode_flags = crtc_state->mode_flags;
>> >  
>> >/*
>> > @@ -5963,6 +5982,9 @@ void intel_crtc_update_active_timings(const struct 
>> > intel_crtc_state *crtc_state)
>> >} else {
>> >crtc->scanline_offset = 1;
>> >}
>> > +
>> > +  spin_unlock(_priv->uncore.lock);
>> > +  spin_unlock_irqrestore(_priv->drm.vblank_time_lock, irqflags);
>> >  }
>> >  
>> >  /*
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add belts and suspenders locking for seamless M/N changes

[Ville Syrjälä]

On Tue, Mar 07, 2023 at 02:24:08PM +0200, Jani Nikula wrote:
> On Mon, 06 Mar 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Add some (probably overkill) locking to protect the vblank
> > timestamping constants updates during seamless M/N fastsets.
> >
> > As everything should be naturally aligned I think the individual
> > pieces should probably end up updating atomically enough. So this
> > is only really meant to guarantee everyone sees a consistent whole.
> >
> > All the drm_vblank.c usage is covered by vblank_time_lock,
> > and uncore.lock will take care of __intel_get_crtc_scanline()
> > that can also be called from outside the core vblank functionality.
> 
> The patch seems to do what it says on the box, but I increasingly
> dislike the use of uncore.lock for anything other than the nuts and
> bolts of uncore.

Yeah, it's not really great. Hence the TODO I left behind there.

> 
> BR,
> Jani.
> 
> >
> > Currently only crtc_clock and framedur_ns can change, but in
> > the future might fastset also across eg. vtotal/vblank_end
> > changes, so let's just grab the locks across the whole thing.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 24 +++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a1fbdf32bd21..020320468967 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5908,6 +5908,8 @@ void intel_crtc_update_active_timings(const struct 
> > intel_crtc_state *crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > struct drm_display_mode adjusted_mode;
> > +   int vmax_vblank_start = 0;
> > +   unsigned long irqflags;
> >  
> > drm_mode_init(_mode, _state->hw.adjusted_mode);
> >  
> > @@ -5915,11 +5917,28 @@ void intel_crtc_update_active_timings(const struct 
> > intel_crtc_state *crtc_state)
> > adjusted_mode.crtc_vtotal = crtc_state->vrr.vmax;
> > adjusted_mode.crtc_vblank_end = crtc_state->vrr.vmax;
> > adjusted_mode.crtc_vblank_start = 
> > intel_vrr_vmin_vblank_start(crtc_state);
> > -   crtc->vmax_vblank_start = 
> > intel_vrr_vmax_vblank_start(crtc_state);
> > +   vmax_vblank_start = intel_vrr_vmax_vblank_start(crtc_state);
> > }
> >  
> > +   /*
> > +* Belts and suspenders locking to guarantee everyone sees 100%
> > +* consistent state during fastset seamless refresh rate changes.
> > +*
> > +* vblank_time_lock takes care of all drm_vblank.c stuff, and
> > +* uncore.lock takes care of __intel_get_crtc_scanline() which
> > +* may get called elsewhere as well.
> > +*
> > +* TODO maybe just protect everything (including
> > +* __intel_get_crtc_scanline()) with vblank_time_lock?
> > +* Need to audit everything to make sure it's safe.
> > +*/
> > +   spin_lock_irqsave(_priv->drm.vblank_time_lock, irqflags);
> > +   spin_lock(_priv->uncore.lock);
> > +
> > drm_calc_timestamping_constants(>base, _mode);
> >  
> > +   crtc->vmax_vblank_start = vmax_vblank_start;
> > +
> > crtc->mode_flags = crtc_state->mode_flags;
> >  
> > /*
> > @@ -5963,6 +5982,9 @@ void intel_crtc_update_active_timings(const struct 
> > intel_crtc_state *crtc_state)
> > } else {
> > crtc->scanline_offset = 1;
> > }
> > +
> > +   spin_unlock(_priv->uncore.lock);
> > +   spin_unlock_irqrestore(_priv->drm.vblank_time_lock, irqflags);
> >  }
> >  
> >  /*
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Update vblank timestamping stuff on seamless M/N change

[Ville Syrjälä]

On Tue, Mar 07, 2023 at 02:16:48PM +0200, Jani Nikula wrote:
> On Mon, 06 Mar 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > When we change the M/N values seamlessly during a fastset we should
> > also update the vblank timestamping stuff to make sure the vblank
> > timestamp corrections/guesstimations come out exact.
> >
> > Note that only crtc_clock and framedur_ns can actually end up
> > changing here during fastsets. Everything else we touch can
> > only change during full modesets.
> >
> > Technically we should try to do this exactly at the start of
> > vblank, but that would require some kind of double buffering
> > scheme. Let's skip that for now and just update things right
> > after the commit has been submitted to the hardware. This
> > means the information will be properly up to date when the
> > vblank irq handler goes to work. Only if someone ends up
> > querying some vblanky stuff in between the commit and start
> > of vblank may we see a slight discrepancy.
> >
> > Also this same problem really exists for the DRRS downclocking
> > stuff. But as that is supposed to be more or less transparent
> > to the user, and it only drops to low gear after a long delay
> > (1 sec currently) we probably don't have to worry about it.
> > Any time something is actively submitting updates DRRS will
> > remain in high gear and so the timestamping constants will
> > match the hardware state.
> >
> > Fixes: e6f29923c048 ("drm/i915: Allow M/N change during fastset on bdw+")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index b79a8834559f..41d381bbb57a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -686,6 +686,14 @@ void intel_pipe_update_end(struct intel_crtc_state 
> > *new_crtc_state)
> >  */
> > intel_vrr_send_push(new_crtc_state);
> >  
> > +   /*
> > +* Seamless M/N update may need to update frame timings.
> > +*
> > +* FIXME Should be synchronized with the start of vblank somehow...
> > +*/
> > +   if (new_crtc_state->seamless_m_n && 
> > intel_crtc_needs_fastset(new_crtc_state))
> > +   intel_crtc_update_active_timings(new_crtc_state);
> 
> Side note, do we ensure somewhere that intel_crtc_needs_modeset() &&
> intel_crtc_needs_fastset() is never true?

commit 7de5b6b54630 ("drm/i915: Don't flag both full modeset and fastset
at the same time")

> 
> Reviewed-by: Jani Nikula 

Thanks

> 
> > +
> > local_irq_enable();
> >  
> > if (intel_vgpu_active(dev_priv))
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH v2 09/10] drm/display/dsc: add helper to set semi-const parameters

[Dmitry Baryshkov]

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 21 +
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 65e810a54257..10ba413d8bf1 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,27 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
 /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
 static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 0bb0c3afd740..4448c482b092 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
-- 
2.39.2

[Intel-gfx] [PATCH v2 08/10] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters

[Dmitry Baryshkov]

Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 438 +++
 include/drm/display/drm_dsc_helper.h |   2 +
 2 files changed, 440 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index aec6f8c201af..65e810a54257 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -740,6 +740,438 @@ static const struct rc_parameters_data 
rc_parameters_1_2_444[] = {
{ /* sentinel */ }
 };
 
+static const struct rc_parameters_data rc_parameters_1_2_422[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 512, 15, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, 
-12 },
+   { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
+   { 512, 15, 6144, 7, 16, 15, 15, {
+   { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15, 
-12 },
+   { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
+   { 512, 15, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
+   { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
+   { 20, 21, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
+   { 512, 15, 6144, 15, 24, 23, 23, {
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 
},
+   { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 
20, -8 },
+   { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
+   { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
+   { 24, 25, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
+   { 512, 15, 6144, 19, 28, 27, 27, {
+   { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2 
},
+   { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19, 
24, -8 },
+   { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
+   { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
+   { 28, 29, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 8,
+   { 410, 15, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10, 
-10 },
+   { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 10,
+   { 410, 15, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14, 
-10 },
+   { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 12,
+   { 410, 15, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
+   { 19, 20, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 14,
+   { 410, 15, 5632, 15, 24, 23, 23, {
+   { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2 
},
+   { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 
20, -8 },
+ 

[Intel-gfx] [PATCH v2 10/10] drm/msm/dsi: use new helpers for DSC setup

[Dmitry Baryshkov]

Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 61 --
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 18fa30e1e858..dda989727921 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1735,28 +1735,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
-   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
-   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
-   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
-   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
 static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct 
drm_dsc_config *dsc)
 {
-   int i;
-   u16 bpp = dsc->bits_per_pixel >> 4;
+   int ret;
 
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(_host->pdev->dev, "DSI does not support 
fractional bits_per_pixel\n");
@@ -1768,49 +1749,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
 
-   dsc->rc_model_size = 8192;
-   dsc->first_line_bpg_offset = 12;
-   dsc->rc_edge_factor = 6;
-   dsc->rc_tgt_offset_high = 3;
-   dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
 
-   /* handle only bpp = bpc = 8 */
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
-   dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+   drm_dsc_set_const_params(dsc);
+   drm_dsc_set_rc_buf_thresh(dsc);
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
-   dsc->rc_range_params[i].range_min_qp = min_qp[i];
-   dsc->rc_range_params[i].range_max_qp = max_qp[i];
-   /*
-* Range BPG Offset contains two's-complement signed values 
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits 
wide.
-*/
-   dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] & 
DSC_RANGE_BPG_OFFSET_MASK;
+   /* handle only bpp = bpc = 8, pre-SCR panels */
+   ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+   if (ret) {
+   DRM_DEV_ERROR(_host->pdev->dev, "could not find DSC RC 
parameters\n");
+   return ret;
}
 
-   dsc->initial_offset = 6144; /* Not bpp 12 */
-   if (bpp != 8)
-   dsc->initial_offset = 2048; /* bpp = 12 */
-
-   if (dsc->bits_per_component <= 10)
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
-   else
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
-   dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
-   dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
-   /* bpc 8 */
-   dsc->flatness_min_qp = 3;
-   dsc->flatness_max_qp = 12;
-   dsc->rc_quant_incr_limit0 = 11;
-   dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
 }
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 07/10] drm/display/dsc: include the rest of pre-SCR parameters

[Dmitry Baryshkov]

DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 72 
 1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 35b39f3109c4..aec6f8c201af 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -325,6 +325,16 @@ struct rc_parameters_data {
 #define DSC_BPP(bpp)   ((bpp) << 4)
 
 static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 683, 15, 6144, 3, 13, 11, 11, {
+   { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
+   { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
+   { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12, 
-12 },
+   { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
@@ -360,6 +370,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(10), .bpc = 8,
+   { 410, 12, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11, 
-10 },
+   { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 10,
+   { 410, 12, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15, 
-10 },
+   { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 12,
+   { 410, 12, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(12), .bpc = 8,
{ 341, 15, 2048, 3, 12, 11, 11, {
@@ -391,6 +432,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(15), .bpc = 8,
+   { 273, 15, 2048, 3, 12, 11, 11, {
+   { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
+   { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
+   { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10 
},
+   { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 10,
+   { 273, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
+   { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
+   { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, 
-10 },
+   { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 12,
+   { 273, 15, 2048, 11, 20, 19, 19, {
+   { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
+   { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 
},
+   { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
+   { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{ /* sentinel */ }
 };
 
-- 
2.39.2

[Intel-gfx] [PATCH v2 04/10] drm/i915/dsc: stop using interim structure for calculated params

[Dmitry Baryshkov]

Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 100 ++
 1 file changed, 26 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 8f99434c4ebc..20a4c2f343fe 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -18,17 +18,6 @@
 #include "intel_qp_tables.h"
 #include "intel_vdsc.h"
 
-struct rc_parameters {
-   u16 initial_xmit_delay;
-   u8 first_line_bpg_offset;
-   u16 initial_offset;
-   u8 flatness_min_qp;
-   u8 flatness_max_qp;
-   u8 rc_quant_incr_limit0;
-   u8 rc_quant_incr_limit1;
-   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
-};
-
 bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
 {
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -63,8 +52,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum 
transcoder cpu_transcoder)
 }
 
 static void
-calculate_rc_params(struct rc_parameters *rc,
-   struct drm_dsc_config *vdsc_cfg)
+calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
 {
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
@@ -84,56 +72,57 @@ calculate_rc_params(struct rc_parameters *rc,
u32 res, buf_i, bpp_i;
 
if (vdsc_cfg->slice_height >= 8)
-   rc->first_line_bpg_offset =
+   vdsc_cfg->first_line_bpg_offset =
12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height - 
8)), 100);
else
-   rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+   vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 
1);
 
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
-   rc->initial_offset = 2048;
+   vdsc_cfg->initial_offset = 2048;
else if (bpp >= 10)
-   rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584), 
2);
+   vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 
3584), 2);
else if (bpp >= 8)
-   rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+   vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 
512), 2);
else
-   rc->initial_offset = 6144;
+   vdsc_cfg->initial_offset = 6144;
 
/* initial_xmit_delay = rc_model_size/2/compression_bpp */
-   rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+   vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 
* bpp);
 
-   rc->flatness_min_qp = 3 + qp_bpc_modifier;
-   rc->flatness_max_qp = 12 + qp_bpc_modifier;
+   vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
+   vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
 
-   rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
-   rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
 
bpp_i  = (2 * (bpp - 6));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+   u8 range_bpg_offset;
+
/* Read range_minqp and range_max_qp from qp tables */
-   rc->rc_range_params[buf_i].range_min_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_min_qp =
intel_lookup_range_min_qp(bpc, buf_i, bpp_i);
-   rc->rc_range_params[buf_i].range_max_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_max_qp =
intel_lookup_range_max_qp(bpc, buf_i, bpp_i);
 
-   /* Calculate range_bgp_offset */
+   /* Calculate range_bpg_offset */
if (bpp <= 6) {
-   rc->rc_range_params[buf_i].range_bpg_offset = 
ofs_und6[buf_i];
+   range_bpg_offset = ofs_und6[buf_i];
} else if (bpp <= 8) {
res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
ofs_und6[buf_i])), 2);
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und6[buf_i] 
+ res;
+   range_bpg_offset = ofs_und6[buf_i] + res;
} else if (bpp <= 12) {
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und8[buf_i];
+   range_bpg_offset = ofs_und8[buf_i];
} else if (bpp <= 15) {
res = 

[Intel-gfx] [PATCH v2 05/10] drm/display/dsc: use flat array for rc_parameters lookup

[Dmitry Baryshkov]

Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 228 +++
 1 file changed, 108 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 122a292bbc8f..acb93d4116e0 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,24 +305,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
-enum ROW_INDEX_BPP {
-   ROW_INDEX_6BPP = 0,
-   ROW_INDEX_8BPP,
-   ROW_INDEX_10BPP,
-   ROW_INDEX_12BPP,
-   ROW_INDEX_15BPP,
-   MAX_ROW_INDEX
-};
-
-enum COLUMN_INDEX_BPC {
-   COLUMN_INDEX_8BPC = 0,
-   COLUMN_INDEX_10BPC,
-   COLUMN_INDEX_12BPC,
-   COLUMN_INDEX_14BPC,
-   COLUMN_INDEX_16BPC,
-   MAX_COLUMN_INDEX
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -334,21 +316,31 @@ struct rc_parameters {
struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
 };
 
+struct rc_parameters_data {
+   u8 bpp;
+   u8 bpc;
+   struct rc_parameters params;
+};
+
+#define DSC_BPP(bpp)   ((bpp) << 4)
+
 /*
  * Selected Rate Control Related Parameter Recommended Values
  * from DSC_v1.11 spec & C Model release: DSC_model_20161212
  */
-static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters_data rc_parameters[] = {
{
-   /* 6BPP/8BPC */
+   .bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
{ 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
{ 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
{ 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
{ 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
}
-   },
-   /* 6BPP/10BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
{ 768, 15, 6144, 7, 17, 15, 15, {
{ 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
{ 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
@@ -356,8 +348,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
{ 17, 18, -12 }
}
-   },
-   /* 6BPP/12BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
{ 768, 15, 6144, 11, 21, 19, 19, {
{ 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
{ 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
@@ -365,8 +359,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
{ 21, 22, -12 }
}
-   },
-   /* 6BPP/14BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
{ 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
@@ -374,8 +370,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
{ 25, 26, -12 }
}
-   },
-   /* 6BPP/16BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
{ 768, 15, 6144, 19, 29, 27, 27, {
{ 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
{ 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
@@ -383,18 +381,20 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
{ 29, 30, -12 }
}
-   },
+   }
},
{
-   /* 8BPP/8BPC */
+   .bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 

[Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

[Dmitry Baryshkov]

The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 127 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
 include/drm/display/drm_dsc_helper.h  |   7 +-
 3 files changed, 119 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index acb93d4116e0..35b39f3109c4 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -324,11 +324,81 @@ struct rc_parameters_data {
 
 #define DSC_BPP(bpp)   ((bpp) << 4)
 
+static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(8), .bpc = 8,
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 10,
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 12,
+   { 512, 12, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 8,
+   { 341, 15, 2048, 3, 12, 11, 11, {
+   { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
+   { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 10,
+   { 341, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
+   { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
},
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 12,
+   { 341, 15, 2048, 11, 20, 19, 19, {
+   { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
+   { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   { /* sentinel */ }
+};
+
 /*
  * Selected Rate Control Related Parameter Recommended Values
  * from DSC_v1.11 spec & C Model release: DSC_model_20161212
  */
-static const struct rc_parameters_data rc_parameters[] = {
+static const struct rc_parameters_data rc_parameters_1_2_444[] = {
{
.bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -388,22 +458,18 @@ static const struct rc_parameters_data rc_parameters[] = {
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
-   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
-   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, 
-12 },
+   { 5, 11, -12 }, { 9, 12, -12 }, 

[Intel-gfx] [PATCH v2 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper

[Dmitry Baryshkov]

The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 35 +++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +---
 include/drm/display/drm_dsc_helper.h  |  1 +
 3 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..be91abe2cfb2 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,41 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+static const u16 drm_dsc_rc_buf_thresh[] = {
+   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+   7744, 7872, 8000, 8064
+};
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+   int i;
+
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+DSC_NUM_BUF_RANGES - 1);
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+ARRAY_SIZE(vdsc_cfg->rc_buf_thresh));
+
+   for (i = 0; i < ARRAY_SIZE(drm_dsc_rc_buf_thresh); i++)
+   vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+
+   /*
+* For 6bpp, RC Buffer threshold 12 and 13 need a different value
+* as per C Model
+*/
+   if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+   vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+   vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+   }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
 /**
  * drm_dsc_compute_rc_parameters() - Write rate control
  * parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index a91b70301640..38cc4b43f1cb 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
 };
 
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
-   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
-   7744, 7872, 8000, 8064
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
-   /*
-* six 0s are appended to the lsb of each threshold value
-* internally in h/w.
-* Only 8 bits are allowed for programming RcBufThreshold
-*/
-   vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
-   }
-
-   /*
-* For 6bpp, RC Buffer threshold 12 and 13 need a different value
-* as per C Model
-*/
-   if (compressed_bpp == 6) {
-   vdsc_cfg->rc_buf_thresh[12] = 0x7C;
-   vdsc_cfg->rc_buf_thresh[13] = 0x7D;
-   }
+   drm_dsc_set_rc_buf_thresh(vdsc_cfg);
 
/*
 * From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 8b41edbbabab..706ba1d34742 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 
 #endif /* _DRM_DSC_HELPER_H_ */
-- 
2.39.2

[Intel-gfx] [PATCH v2 01/10] drm/i915/dsc: change DSC param tables to follow the DSC model

[Dmitry Baryshkov]

After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.

Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 207b2a648d32..a91b70301640 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -86,7 +86,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
-   { 768, 15, 6144, 15, 25, 23, 27, {
+   { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -115,6 +115,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -132,7 +136,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
-   { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -529,6 +533,20 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
 
+   if (DISPLAY_VER(dev_priv) < 13) {
+   /*
+* FIXME: verify that the hardware actually needs these
+* modifications rather than them being simple typos.
+*/
+   if (compressed_bpp == 6 &&
+   vdsc_cfg->bits_per_component == 8)
+   vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+   if (compressed_bpp == 8 &&
+   vdsc_cfg->bits_per_component == 14)
+   vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+   }
+
/*
 * BitsPerComponent value determines mux_word_size:
 * When BitsPerComponent is less than or 10bpc, muxWordSize will be 
equal to
-- 
2.39.2

[Intel-gfx] [PATCH v2 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper

[Dmitry Baryshkov]

Move DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 372 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
 include/drm/display/drm_dsc_helper.h  |   1 +
 3 files changed, 380 insertions(+), 312 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index be91abe2cfb2..122a292bbc8f 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,6 +305,378 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
+enum ROW_INDEX_BPP {
+   ROW_INDEX_6BPP = 0,
+   ROW_INDEX_8BPP,
+   ROW_INDEX_10BPP,
+   ROW_INDEX_12BPP,
+   ROW_INDEX_15BPP,
+   MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+   COLUMN_INDEX_8BPC = 0,
+   COLUMN_INDEX_10BPC,
+   COLUMN_INDEX_12BPC,
+   COLUMN_INDEX_14BPC,
+   COLUMN_INDEX_16BPC,
+   MAX_COLUMN_INDEX
+};
+
+struct rc_parameters {
+   u16 initial_xmit_delay;
+   u8 first_line_bpg_offset;
+   u16 initial_offset;
+   u8 flatness_min_qp;
+   u8 flatness_max_qp;
+   u8 rc_quant_incr_limit0;
+   u8 rc_quant_incr_limit1;
+   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values
+ * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ */
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+   {
+   /* 6BPP/8BPC */
+   { 768, 15, 6144, 3, 13, 11, 11, {
+   { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
+   { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
+   { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
+   { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
+   }
+   },
+   /* 6BPP/10BPC */
+   { 768, 15, 6144, 7, 17, 15, 15, {
+   { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
+   { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
+   { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
+   { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
+   { 17, 18, -12 }
+   }
+   },
+   /* 6BPP/12BPC */
+   { 768, 15, 6144, 11, 21, 19, 19, {
+   { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
+   { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
+   { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
+   { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
+   { 21, 22, -12 }
+   }
+   },
+   /* 6BPP/14BPC */
+   { 768, 15, 6144, 15, 25, 23, 23, {
+   { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
+   { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
+   { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
+   { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
+   { 25, 26, -12 }
+   }
+   },
+   /* 6BPP/16BPC */
+   { 768, 15, 6144, 19, 29, 27, 27, {
+   { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
+   { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
+   { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
+   { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
+   { 29, 30, -12 }
+   }
+   },
+   },
+   {
+   /* 8BPP/8BPC */
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   },
+   /* 8BPP/10BPC */
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ 

[Intel-gfx] [PATCH v2 00/10] drm/i915: move DSC RC tables to drm_dsc_helper.c

[Dmitry Baryshkov]

Other platforms (msm) will benefit from sharing the DSC config setup
functions. This series moves parts of static DSC config data from the
i915 driver to the common helpers to be used by other drivers.

Note: the RC parameters were cross-checked against config files found in
DSC model 2021062, 20161212 (and 20150914). The first patch modifies
tables according to those config files, while preserving parameter
values using the code. I have not changed one of the values in the
pre-SCR config file as it clearly looks like a typo in the config file,
considering the table E in DSC 1.1 and in the DSC 1.1 SCR.

Chances since v1:
- Made drm_dsc_rc_buf_thresh static rather than exporting it
- Switched drm_dsc_rc_buf_thresh loop to use ARRAY_SIZE. Added
  BUILD_BUG_ON's to be sure that array sizes are correct
- Fixed rc_parameters_data indentation to be logical and tidy
- Fixed drm_dsc_setup_rc_params() kerneldoc
- Added a clause to drm_dsc_setup_rc_params() to verify bpp and bpc
  being set.
- Fixed range_bpg_offset programming in calculate_rc_params()
- Fixed bpp vs bpc bug in intel_dsc_compute_params()
- Added FIXME comment next to the customizations in
  intel_dsc_compute_params().

Dmitry Baryshkov (10):
  drm/i915/dsc: change DSC param tables to follow the DSC model
  drm/i915/dsc: move rc_buf_thresh values to common helper
  drm/i915/dsc: move DSC tables to DRM DSC helper
  drm/i915/dsc: stop using interim structure for calculated params
  drm/display/dsc: use flat array for rc_parameters lookup
  drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
  drm/display/dsc: include the rest of pre-SCR parameters
  drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
  drm/display/dsc: add helper to set semi-const parameters
  drm/msm/dsi: use new helpers for DSC setup

 drivers/gpu/drm/display/drm_dsc_helper.c  | 1007 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |  443 +
 drivers/gpu/drm/msm/dsi/dsi_host.c|   61 +-
 include/drm/display/drm_dsc_helper.h  |   10 +
 4 files changed, 1072 insertions(+), 449 deletions(-)

-- 
2.39.2

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Extend Wa_14017073508 in suspend/resume flow

[Nilawar, Badal]

On 07-03-2023 01:50, Rodrigo Vivi wrote:

On Mon, Mar 06, 2023 at 08:33:04AM +, Gupta, Anshuman wrote:




-Original Message-
From: Nilawar, Badal 
Sent: Saturday, March 4, 2023 9:48 PM
To: intel-gfx@lists.freedesktop.org
Cc: Gupta, Anshuman ; Ewins, Jon
; Belgaumkar, Vinay ;
Vivi, Rodrigo 
Subject: [PATCH] drm/i915/mtl: Extend Wa_14017073508 in suspend/resume
flow

During suspend resume flow it was seen that lots forcewakes are taken and
released for media. So to avoid HANG due to MC6 entry/exit while accessing
media applied Wa_14017073508 in suspend/resume flow.

We need to fix such gaps in runtime PM as well, but that will make this WA 
dirty somewhat similar to other RC6 related WA on other platforms.
I suggest to disable the MC6 rather on A step rather than having this form of 
WA. This WA is not needed on A step.
@rodrigo and @matt what is you opinion here ?


My opinion since day-0 is that we should simply disable MC6 on A0 parts
and move on with this feature only on B0. Since the beginning it was
pretty clear that this workaround would get out of control and become
the same as the PVC-RC6 one.

Thanks for your opinion Rodrigo. I will disable MC6 and send the patch.

Regards,
Badal Nilawar




However some comment her to improve this patch.



Signed-off-by: Badal Nilawar 
---
  drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  6 -
  drivers/gpu/drm/i915/gt/intel_gt_pm.c| 32 
  drivers/gpu/drm/i915/gt/intel_gt_pm.h|  3 +++
  drivers/gpu/drm/i915/gt/intel_gt_types.h |  1 +
  drivers/gpu/drm/i915/i915_driver.c   | 32 
  5 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 0d812f4d787d..60deac41104d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -160,8 +160,12 @@ void i915_gem_suspend_late(struct
drm_i915_private *i915)
 * machine in an unusable condition.
 */

-   for_each_gt(gt, i915, i)
+   for_each_gt(gt, i915, i) {
+   /* Wa_14017073508: mtl */
+   mtl_media_busy(gt);

Let's add  these busy/idle in intel_gt_suspend_late()

intel_gt_suspend_late(gt);
+   mtl_media_idle(gt);
+   }

spin_lock_irqsave(>mm.obj_lock, flags);
for (phase = phases; *phase; phase++) { diff --git
a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index cef3d6f5c34e..1f3bf1cf0421 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -26,24 +26,34 @@

  #define I915_GT_SUSPEND_IDLE_TIMEOUT (HZ / 2)

-static void mtl_media_busy(struct intel_gt *gt)
+void mtl_media_busy(struct intel_gt *gt)
  {
/* Wa_14017073508: mtl */
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+   if (gt && IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)
&&
gt->type == GT_MEDIA)

Let's have this in a separate patch , I believe that is already floated and 
ready to merge.

-   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
- PCODE_MBOX_GT_STATE_MEDIA_BUSY,
-
PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+   if (!atomic_inc_not_zero(>media_wakeref)) {
+   drm_err(>i915->drm, "Media busy\n");

This should not be Error message.

+   snb_pcode_write_p(gt->uncore,
PCODE_MBOX_GT_STATE,
+
PCODE_MBOX_GT_STATE_MEDIA_BUSY,
+
PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+   atomic_inc(>media_wakeref);
+   }
  }

-static void mtl_media_idle(struct intel_gt *gt)
+void mtl_media_idle(struct intel_gt *gt)
  {
/* Wa_14017073508: mtl */
-   if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
-   gt->type == GT_MEDIA)
-   snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
-
PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
-
PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+   if (gt && IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)
&&
+   gt->type == GT_MEDIA) {
+   WARN_ON(atomic_read(>media_wakeref) <= 0);
+   if (!atomic_add_unless(>media_wakeref, -1, 1)) {
+   drm_err(>i915->drm, "Media idle\n");

Same here this can't be error message.
Thanks,
Anshuman Gupta.

+   snb_pcode_write_p(gt->uncore,
PCODE_MBOX_GT_STATE,
+
PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
+
PCODE_MBOX_GT_STATE_DOMAIN_MEDIA, 0);
+   atomic_dec(>media_wakeref);
+   }
+   }
  }

  static void user_forcewake(struct intel_gt *gt, bool suspend) diff --git
a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..43ffabf9babe 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -89,4 +89,7 @@ static inline bool is_mock_gt(const struct intel_gt *gt)
   

Re: [Intel-gfx] [PATCH 07/10] drm/display/dsc: include the rest of pre-SCR parameters

[Dmitry Baryshkov]

On 28/02/2023 18:31, Jani Nikula wrote:

On Tue, 28 Feb 2023, Dmitry Baryshkov  wrote:

DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.


Need to run now, note to self:

Does i915 use the arrays to limit the bpp/bpc combos supported by
hardware? Do we need to add separate limiting in i915.


There is already a limitation in intel_dsc_compute_params(): the driver 
uses DRM_DSC_1_1_PRE_SCR only in a limited amount of cases (bpp 8 or 12, 
bpc 8, 10 or 12). But thanks, I noticed a bug there.




BR,
Jani.


--
With best wishes
Dmitry

Re: [Intel-gfx] drm/i915/selftest: Remove avoidable init assignment

[Rodrigo Vivi]

On Tue, Mar 07, 2023 at 03:16:43PM +0530, Tejas Upadhyay wrote:
> We can skip the assignment and i915 variable
> altogether and use refernce directly. Also used at
> single place only.
> 
> Signed-off-by: Tejas Upadhyay 

trusting the compiler,

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/selftests/i915_request.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c 
> b/drivers/gpu/drm/i915/selftests/i915_request.c
> index 7a27aba3da8a..a9b79888c193 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> @@ -1117,9 +1117,8 @@ static int live_empty_request(void *arg)
>  
>  static struct i915_vma *recursive_batch(struct intel_gt *gt)
>  {
> - struct drm_i915_private *i915 = gt->i915;
>   struct drm_i915_gem_object *obj;
> - const int ver = GRAPHICS_VER(i915);
> + const int ver = GRAPHICS_VER(gt->i915);
>   struct i915_vma *vma;
>   u32 *cmd;
>   int err;
> -- 
> 2.25.1
> 

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Liu, Yi L]

> From: Jason Gunthorpe 
> Sent: Tuesday, March 7, 2023 8:37 PM
> 
> On Tue, Mar 07, 2023 at 02:31:11AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe 
> > > Sent: Monday, March 6, 2023 9:17 PM
> > >
> > > On Fri, Mar 03, 2023 at 09:55:42AM -0700, Alex Williamson wrote:
> > >
> > > > I can't think of a reason DPDK couldn't use hot-reset.  If we want to
> > > > make it a policy, it should be enforced by code, but creating that
> > > > policy based on a difficulty in supporting that mode with iommufd isn't
> > > > great.
> > >
> > > On the other hand adding code to allow device FDs in the hot reset
> > > path that is never used and never tested isn't great either..
> > >
> > > hot-reset does work for DPDK, it just doesn't work in the case where
> > > DPDK would have many VFIO devices open and they have overlapping
> > > device sets. Which, again, is something it doesn't do.
> > >
> > > IMHO we should leave it out of the kernel and wait for a no-iommu user
> > > to come forward that wants hot-reset of many devices. Then we can
> add
> > > and test the device FD part. Most likely such a thing will never come
> > > at this point.
> > >
> >
> > I think we don't need to have this tradeoff if following Yi's last proposal
> > which requires every opened device in the set to be covered by the
> > device fd array. with dev_set->lock held in the reset/open path this is
> > a safe measure and fully contained in vfio-pci w/o need of further
> > checking noiommu or iommufd.
> 
> I really prefer the 'use the iommufd option' still exist, it is so
> much cleaner and easier for the actual users of this API. We've lost
> the point by worrying about no iommu.

Hmmm, so you are suggesting to have both the device fd approach
and the zero-length array approach, let user to select the best way
based on their wisdom. Is it? how about something like below in the
uapi header.

/**
 * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
 *  struct vfio_pci_hot_reset)
 *
 * Userspace requests hot reset for the devices it uses.  Due to the
 * underlying topology, multiple devices may be affected in the reset.
 * The affected devices may have been opened by the user or by other
 * users or not opened yet.  Only when all the affected devices are
 * either opened by the current user or not opened by any user, should
 * the reset request be allowed.  Otherwise, this request is expected
 * to return error. group_fds array can accept either group fds or
 * device fds.  Users using iommufd (valid fd), could also passing a
 * zero-length group_fds array to indicate using the bound iommufd_ctx
 * for ownership check to the affected devices that are opened.
 *
 * Return: 0 on success, -errno on failure.
 */
struct vfio_pci_hot_reset {
__u32   argsz;
__u32   flags;
__u32   count;
__s32   group_fds[];
};

Regards,
Yi Liu

Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg file for PICA registers

[Kahola, Mika]

> -Original Message-
> From: De Marchi, Lucas 
> Sent: Wednesday, March 1, 2023 1:27 AM
> To: Kahola, Mika 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg 
> file
> for PICA registers
> 
> On Fri, Feb 24, 2023 at 12:13:37PM +0200, Mika Kahola wrote:
> >Create a separate file to store registers for PICA chips
> >C10 and C20.
> >
> >v2: Rename file (Jani)
> >
> >Signed-off-by: Radhakrishna Sripada 
> >Signed-off-by: Mika Kahola 
> >---
> > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 136 ++
> > 1 file changed, 136 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> >b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> >new file mode 100644
> >index ..d6b3709d3762
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> >@@ -0,0 +1,136 @@
> >+/* SPDX-License-Identifier: MIT
> >+ *
> >+ * Copyright © 2022 Intel Corporation
> >+ */
> >+
> >+#ifndef __INTEL_CX0_PHY_REGS_H__
> >+#define __INTEL_CX0_PHY_REGS_H__
> >+
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A   0x64040
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B   0x64140
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1
>   0x16F240
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2
>   0x16F440
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3
>   0x16F640
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4
>   0x16F840
> >+#define _XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
>   (_PICK(port, \
> >+[PORT_A] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \
> >+[PORT_B] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \
> >+[PORT_TC1] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \
> >+[PORT_TC2] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2, \
> >+[PORT_TC3] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3, \
> >+[PORT_TC4] =
> _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4) + ((lane) *
> >+4))
> >+
> 
> stray newline
> 
> >+#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
>   _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane))
> 
> 
> one of the reasons _PICK_EVEN_2RANGES() was added. We usually have 2
> ranges for the ports due to the combo vs tc distinction.
> 
> #define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)
>   _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1,
> 
>_XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A,
> 
>_XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B,
> 
>_XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1,
> 
>_XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2))
> 
Btw, are we missing something from upstream? It seems that this is not 
compiling properly with upstream kernel?

Thanks for the review and comments! I'm working on the rest of these fixes.

-Mika-
> 
> >+#define  XELPDP_PORT_M2P_TRANSACTION_PENDING
>   REG_BIT(31)
> 
>^ wrong amount of spaces. See the example on top of i915_reg.h
> 
> here and everywhere in this file
> 
> >+#define  XELPDP_PORT_M2P_COMMAND_TYPE_MASK
>   REG_GENMASK(30, 27)
> >+#define  XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED
>   REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1)
> >+#define  XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED
>   REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2)
> >+#define  XELPDP_PORT_M2P_COMMAND_READ
>   REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3)
> >+#define  XELPDP_PORT_M2P_DATA_MASK
>   REG_GENMASK(23, 16)
> >+#define  XELPDP_PORT_M2P_DATA(val)
>   REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val)
> >+#define  XELPDP_PORT_M2P_TRANSACTION_RESET  REG_BIT(15)
> >+#define  XELPDP_PORT_M2P_ADDRESS_MASK
>   REG_GENMASK(11, 0)
> >+#define  XELPDP_PORT_M2P_ADDRESS(val)
>   REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val)
> >+
> >+#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane)
>   _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) + 8)
> >+#define  XELPDP_PORT_P2M_RESPONSE_READY
>   REG_BIT(31)
> >+#define  XELPDP_PORT_P2M_COMMAND_TYPE_MASK
>   REG_GENMASK(30, 27)
> >+#define  XELPDP_PORT_P2M_COMMAND_READ_ACK   0x4
> >+#define  XELPDP_PORT_P2M_COMMAND_WRITE_ACK  0x5
> >+#define  XELPDP_PORT_P2M_DATA_MASK
>   REG_GENMASK(23, 16)
> >+#define  XELPDP_PORT_P2M_DATA(val)
>   REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val)
> >+#define  XELPDP_PORT_P2M_ERROR_SET  REG_BIT(15)
> >+#define  XELPDP_MSGBUS_TIMEOUT_SLOW 1
> >+#define  XELPDP_MSGBUS_TIMEOUT_FAST_US  2
> >+
> >+#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US   3200
> >+#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US  20
> >+#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US