[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev3)
URL   : https://patchwork.freedesktop.org/series/112196/
State : failure

== Summary ==

Error: patch 
https://patchwork.freedesktop.org/api/1.0/series/112196/revisions/3/mbox/ not 
applied
Applying: drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"
Applying: KVM: x86/mmu: Factor out helper to get max mapping size of a memslot
Applying: drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT 
entry
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/gtt.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0003 drm/i915/gvt: Incorporate KVM memslot info into check for 
2MiB GTT entry
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 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry

[Yan Zhao]

On Thu, Jan 05, 2023 at 05:40:32PM +, Sean Christopherson wrote:
> On Thu, Jan 05, 2023, Yan Zhao wrote:
> > On Tue, Jan 03, 2023 at 09:13:54PM +, Sean Christopherson wrote:
> > > On Wed, Dec 28, 2022, Yan Zhao wrote:
> > > > On Fri, Dec 23, 2022 at 12:57:15AM +, Sean Christopherson wrote:
> > > > > Honor KVM's max allowed page size when determining whether or not a 
> > > > > 2MiB
> > > > > GTT shadow page can be created for the guest.  Querying KVM's max 
> > > > > allowed
> > > > > size is somewhat odd as there's no strict requirement that KVM's 
> > > > > memslots
> > > > > and VFIO's mappings are configured with the same gfn=>hva mapping, but
> > > > Without vIOMMU, VFIO's mapping is configured with the same as KVM's
> > > > memslots, i.e. with the same gfn==>HVA mapping
> > > 
> > > But that's controlled by userspace, correct?
> > 
> > Yes, controlled by QEMU.
> 
> ...
> 
> > > Strictly speaking, no.  E.g. if a 2MiB region is covered with multiple 
> > > memslots
> > > and the memslots have different properties.
> > > 
> > > > If for some reason, KVM maps a 2MiB range in 4K sizes, KVMGT can still 
> > > > map
> > > > it in IOMMU size in 2MiB size as long as the PFNs are continous and the
> > > > whole range is all exposed to guest.
> > > 
> > > I agree that practically speaking this will hold true, but if KVMGT wants 
> > > to honor
> > > KVM's memslots then checking that KVM allows a hugepage is correct.  Hrm, 
> > > but on
> > > the flip side, KVMGT ignores read-only memslot flags, so KVMGT is already 
> > > ignoring
> > > pieces of KVM's memslots.
> > KVMGT calls dma_map_page() with DMA_BIDIRECTIONAL after checking 
> > gvt_pin_guest_page().
> > Though for a read-only memslot, DMA_TO_DEVICE should be used instead
> > (see dma_info_to_prot()),
> > as gvt_pin_guest_page() checks (IOMMU_READ | IOMMU_WRITE) permission for 
> > each page,
> > it actually ensures that the pinned GFN is not in a read-only memslot.
> > So, it should be fine.
> > 
> > > 
> > > I have no objection to KVMGT defining its ABI such that KVMGT is allowed 
> > > to create
> > > 2MiB so long as (a) the GFN is contiguous according to VFIO, and (b) that 
> > > the entire
> > > 2MiB range is exposed to the guest.
> > > 
> > sorry. I may not put it clearly enough.
> > for a normal device pass-through via VFIO-PCI, VFIO maps IOMMU mappings in 
> > this way:
> > 
> > (a) fault in PFNs in a GFN range within the same memslot (VFIO saves 
> > dma_list, which is
> > the same as memslot list when vIOMMU is not on or not in shadow mode).
> > (b) map continuous PFNs into iommu driver (honour ro attribute and can > 
> > 2MiB as long as
> > PFNs are continuous).
> > (c) IOMMU driver decides to map in 2MiB or in 4KiB according to its setting.
> > 
> > For KVMGT, gvt_dma_map_page() first calls gvt_pin_guest_page() which
> > (a) calls vfio_pin_pages() to check each GFN is within allowed dma_list with
> > (IOMMU_READ | IOMMU_WRITE) permission and fault-in page. 
> > (b) checks PFNs are continuous in 2MiB,
> > 
> > Though checking kvm_page_track_max_mapping_level() is also fine, it makes 
> > DMA
> > mapping size unnecessarily smaller.
> 
> Yeah, I got all that.  What I'm trying to say, and why I asked about whether 
> or
> not userspace controls the mappings, is that AFAIK there is nothing in the 
> kernel
> that coordinates mappings between VFIO and KVM.  So, very technically, 
> userspace
> could map a 2MiB range contiguous in VFIO but not in KVM, or RW in VFIO but 
> RO in KVM.
> 
> I can't imagine there's a real use case for doing so, and arguably there's no
> requirement that KVMGT honor KVM's memslot.  But because KVMGT taps into KVM's
> page-tracking, KVMGT _does_ honor KVM's memslots to some extent because KVMGT
> needs to know whether or not a given GFN can be write-protected.
> 
> I'm totally fine if KVMGT's ABI is that VFIO is the source of truth for 
> mappings
> and permissions, and that the only requirement for KVM memslots is that GTT 
> page
> tables need to be visible in KVM's memslots.  But if that's the ABI, then
> intel_gvt_is_valid_gfn() should be probing VFIO, not KVM (commit cc753fbe1ac4
> ("drm/i915/gvt: validate gfn before set shadow page entry").
> 
> In other words, pick either VFIO or KVM.  Checking that X is valid according 
> to
> KVM and then mapping X through VFIO is confusing and makes assumptions about 
> how
> userspace configures KVM and VFIO.  It works because QEMU always configures 
> KVM
> and VFIO as expected, but IMO it's unnecessarily fragile and again confusing 
> for
> unaware readers because the code is technically flawed.
>
Agreed. 
Then after some further thought, I think maybe we can just remove
intel_gvt_is_valid_gfn() in KVMGT, because

(1) both intel_gvt_is_valid_gfn() in emulate_ggtt_mmio_write() and
ppgtt_populate_spt() are not for page track purpose, but to validate bogus
GFN.
(2) gvt_pin_guest_page() with gfn and size can do the validity checking,
which is called in 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Defeature Interlace modes for Display >= 12 (rev3)

[Nautiyal, Ankit K]

Hi Lakshmi,

Below failure is not related to the patch, but due to existing issue : 
https://gitlab.freedesktop.org/drm/intel/-/issues/6179



   Possible regressions

 * igt@gem_exec_suspend@basic-s3@smem:
 o fi-rkl-11600: NOTRUN -> INCOMPLETE
   



Regards,

Ankit


On 1/5/2023 10:33 PM, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   Defeature Interlace modes for Display >= 12 (rev3)
*URL:*  https://patchwork.freedesktop.org/series/109773/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/index.html



  CI Bug Log - changes from CI_DRM_12548 -> Patchwork_109773v3


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_109773v3 absolutely need 
to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_109773v3, please notify your bug team to allow 
them
to document this new failure mode, which will reduce false positives 
in CI.


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



Participating hosts (43 -> 42)

Additional (2): bat-dg2-11 fi-rkl-11600
Missing (3): bat-atsm-1 fi-snb-2520m fi-pnv-d510


Possible new issues

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



  IGT changes


Possible regressions

  * igt@gem_exec_suspend@basic-s3@smem:
  o fi-rkl-11600: NOTRUN -> INCOMPLETE




Suppressed

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

 *

igt@i915_selftest@live@hangcheck:

  o {bat-dg2-8}: PASS


-> DMESG-FAIL


 *

igt@i915_suspend@basic-s3-without-i915:

  o {bat-adlm-1}: PASS


-> DMESG-WARN


+1 similar issue


Known issues

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



  IGT changes


Issues hit

 *

igt@debugfs_test@basic-hwmon:

  o fi-rkl-11600: NOTRUN -> SKIP


(i915#7456 )
 *

igt@gem_huc_copy@huc-copy:

  o fi-rkl-11600: NOTRUN -> SKIP


(i915#2190 )
 *

igt@gem_lmem_swapping@basic:

  o fi-rkl-11600: NOTRUN -> SKIP


(i915#4613
) +3
similar issues
 *

igt@gem_tiled_pread_basic:

  o fi-rkl-11600: NOTRUN -> SKIP


(i915#3282 )
 *

igt@i915_pm_backlight@basic-brightness:

  o fi-rkl-11600: NOTRUN -> SKIP


(i915#7561 )
 *

igt@i915_pm_rpm@basic-rte:

  o bat-adlp-4: PASS


-> DMESG-WARN


(i915#7077 )
 *

igt@i915_suspend@basic-s3-without-i915:

  o fi-rkl-11600: NOTRUN -> FAIL


(fdo#103375 )
 *

igt@kms_chamelium@hdmi-edid-read:

  o fi-rkl-11600: NOTRUN -> SKIP


(fdo#111827

Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/hdcp: Fill wired_cmd_in structures at a single place

[Kandpal, Suraj]

> > On 04/01/2023 09:53, Jani Nikula wrote:
> > > On Mon, 02 Jan 2023, Suraj Kandpal  wrote:
> > > > Need to fill wired cmd in structures at a single place as they
> > > > remain same for both gsc and mei.
> > >
> > > I'm still opposed to adding this stuff to i915 and exporting the
> > > symbols. Seems like it should be a separate component, because this
> > > is not about i915.
> > >
> > > Cc: other maintainers, please chime in.
> > >
> > > > --v3
> > > > -remove inline function from header [Jani]
> > > >
> > > > Cc: Ankit Nautiyal 
> > > > Signed-off-by: Suraj Kandpal 
> > > > ---
> > > >   drivers/gpu/drm/i915/Makefile  |   1 +
> > > >   drivers/gpu/drm/i915/i915_hdcp_interface.c | 216
> +
> > > >   drivers/misc/mei/hdcp/mei_hdcp.c   | 153 ++-
> > > >   include/drm/i915_hdcp_interface.h  |  39 
> > > >   4 files changed, 270 insertions(+), 139 deletions(-)
> > > >   create mode 100644 drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > b/drivers/gpu/drm/i915/Makefile index 461d6b40656d..c6a9826af58d
> > > > 100644
> > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > @@ -36,6 +36,7 @@ i915-y += i915_driver.o \
> > > >   i915_drm_client.o \
> > > >   i915_config.o \
> > > >   i915_getparam.o \
> > > > + i915_hdcp_interface.o\
> > > >   i915_ioctl.o \
> > > >   i915_irq.o \
> > > >   i915_mitigations.o \
> > > > diff --git a/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > > b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > > new file mode 100644
> > > > index ..e6b787c2fa50
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/i915/i915_hdcp_interface.c
> > > > @@ -0,0 +1,216 @@
> > > > +// SPDX-License-Identifier: MIT
> > > > +/*
> > > > + * Copyright 2022, Intel Corporation.
> > > > + */
> > > > +
> > > > +#include 
> > > > +
> > > > +void
> > > > +i915_hdcp_fill_session_in(struct wired_cmd_initiate_hdcp2_session_in
> *session_init_in,
> > > > + struct hdcp_port_data *data) {
> > > > +   session_init_in->header.api_version = HDCP_API_VERSION;
> > > > +   session_init_in->header.command_id =
> WIRED_INITIATE_HDCP2_SESSION;
> > > > +   session_init_in->header.status = FW_HDCP_STATUS_SUCCESS;
> > > > +   session_init_in->header.buffer_len =
> > > > +
>   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> > > > +
> > > > +   session_init_in->port.integrated_port_type = data->port_type;
> > > > +   session_init_in->port.physical_port = (u8)data->hdcp_ddi;
> > > > +   session_init_in->port.attached_transcoder = 
> > > > (u8)data->hdcp_transcoder;
> > > > +   session_init_in->protocol = data->protocol; }
> > > > +EXPORT_SYMBOL(i915_hdcp_fill_session_in);
> >
> > I am not familiar enough with the problem space but this kind of
> > trivial exported symbols definitely do not look like the best choice.
> >
> > Presumably there are two kernel modules dealing with this HDCP
> > protocol in which case would creating a kernel module like intel_hdcp,
> > which would establish the protocol definitions and API to use it. I915
> > and any other module would then depend on that module and use it.
> >
> > Presumably this is what Jani meant actually and that sounds like the
> > exactly right direction to me. I just don't know enough about the
> > scope of the protocol to propose anything more specific.
> 
> I'm also in favor of the separated module here. Eventually we will have to 
> use it in
> the new Xe driver as well.
> 
> 

In that case ill create a different patch series which uses a different module 
rather than the
export symbol method and in this series rever back to how things used to be i.e 
keeping this
in the mei_hdcp.c file for now

Regards,
Suraj Kandpal

> >
> > Regards,
> >
> > Tvrtko
> >
> > > > +
> > > > +void
> > > > +i915_hdcp_fill_rxcert_in(struct wired_cmd_verify_receiver_cert_in
> *verify_rxcert_in,
> > > > +struct hdcp2_ake_send_cert *rx_cert,
> > > > +struct hdcp_port_data *data)
> > > > +{
> > > > +   verify_rxcert_in->header.api_version = HDCP_API_VERSION;
> > > > +   verify_rxcert_in->header.command_id =
> WIRED_VERIFY_RECEIVER_CERT;
> > > > +   verify_rxcert_in->header.status = FW_HDCP_STATUS_SUCCESS;
> > > > +   verify_rxcert_in->header.buffer_len =
> > > > +
>   WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
> > > > +
> > > > +   verify_rxcert_in->port.integrated_port_type = data->port_type;
> > > > +   verify_rxcert_in->port.physical_port = (u8)data->hdcp_ddi;
> > > > +   verify_rxcert_in->port.attached_transcoder =
> > > > +(u8)data->hdcp_transcoder;
> > > > +
> > > > +   verify_rxcert_in->cert_rx = rx_cert->cert_rx;
> > > > +   memcpy(verify_rxcert_in->r_rx, _cert->r_rx, 
> > > > HDCP_2_2_RRX_LEN);
> > > > +   

Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

[Matthew Rosato]

On 1/5/23 6:34 PM, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2023 at 03:09:30PM -0700, Alex Williamson wrote:
>> On Thu, 19 May 2022 14:33:11 -0400
>> Matthew Rosato  wrote:
>>
>>> Rather than relying on a notifier for associating the KVM with
>>> the group, let's assume that the association has already been
>>> made prior to device_open.  The first time a device is opened
>>> associate the group KVM with the device.
>>>
>>> This fixes a user-triggerable oops in GVT.
>>
>> It seems this has traded an oops for a deadlock, which still exists
>> today in both GVT-g and vfio-ap.  These are the only vfio drivers that
>> care about kvm, so they make use of kvm_{get,put}_kvm(), where the

vfio-pci-zdev also

>> latter is called by their .close_device() callbacks.

Huh, I've never seen this deadlock with vfio-pci-zdev or vfio-ap, but I see 
what you're saying...  I guess it's not seen under typical circumstances with 
QEMU because kvm_vfio_group_del would have already been triggered via 
KVM_DEV_VFIO_GROUP_DEL by the time we close the device, such that the group 
would not be found during the kvm_vfio_destroy call?  (I'm not at all 
suggesting that we should rely on userspace behaving in this order, just 
wondering why I never saw it while testing)

> 
> Bleck
> 
> It is pretty common to run the final part of 'put' from a workqueue
> specifically to avoid stuff like this, eg fput does it
> 
> Maybe that is the simplest?

Yeah, this is also what I was thinking, replace the direct kvm_put_kvm calls 
with, say, schedule_delayed_work in each driver, where the delayed task just 
does the kvm_put_kvm (along with a brief comment explaining why we handle the 
put asynchronously).

Other than that..  The goal of this patch originally was to get the kvm 
reference at first open_device and release it with the very last close_device, 
so the only other option I could think of would be to take the responsibility 
back from the vfio drivers and do the kvm_get_kvm and kvm_put_kvm directly in 
vfio_main after dropping the  (but that would result in some ugly symbol 
linkage and would acquire kvm references that a driver maybe does not care 
about so I don't really like that idea)

Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

[Matthew Rosato]

On 1/5/23 7:32 PM, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2023 at 07:16:37PM -0500, Matthew Rosato wrote:
> 
>> Yeah, this is also what I was thinking, replace the direct
>> kvm_put_kvm calls with, say, schedule_delayed_work in each driver,
>> where the delayed task just does the kvm_put_kvm (along with a brief
>> comment explaining why we handle the put asynchronously).
> 
> Don't put that in every driver, do something like mmput_async() where
> the core code has all of this.
> 

If the core vfio code were to add logic to invoke kvm_put_kvm and kvm_get_kvm, 
won't this introduce a vfio dependency on kvm?  If I recall, we have the 
drivers handling the kvm reference today in order to avoid that..

>> Other than that..  The goal of this patch originally was to get the
>> kvm reference at first open_device and release it with the very last
>> close_device, so the only other option I could think of would be to
>> take the responsibility back from the vfio drivers and do the
>> kvm_get_kvm and kvm_put_kvm directly in vfio_main after dropping the
>> (but that would result in some ugly symbol linkage and would acquire
>> kvm references that a driver maybe does not care about so I don't
>> really like that idea)
> 
> And we still have the deadlock problem anyhow..

Looks like I never finished my sentence here -- I meant call kvm_put_kvm 
directly in vfio_main after dropping the group lock (e.g. when we set 
device->kvm = NULL;). But I think we'd still have the kvm dependency issue

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add initial gt workarounds (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add initial gt workarounds (rev2)
URL   : https://patchwork.freedesktop.org/series/111994/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12550 -> Patchwork_111994v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 44)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][2] -> [FAIL][3] ([i915#7229])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12550/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html

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

  * igt@gem_lmem_swapping@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.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_111994v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

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

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

  * igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka:   NOTRUN -> [SKIP][10] ([fdo#109271]) +17 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- {bat-adln-1}:   [DMESG-WARN][11] ([i915#7077]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12550/bat-adln-1/igt@i915_pm_...@basic-rte.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/bat-adln-1/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@workarounds:
- {bat-rpls-1}:   [INCOMPLETE][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12550/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111994v2/bat-rpls-1/igt@i915_selftest@l...@workarounds.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359


Build changes
-

  * Linux: CI_DRM_12550 -> Patchwork_111994v2

  CI-20190529: 20190529
  CI_DRM_12550: f604441f326ba242fc0b0f86dc2468863d204c97 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7110: db10a19b94d1d7ae5ba62eb48d52c47ccb27766f @ 

Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

[Jason Gunthorpe]

On Thu, Jan 05, 2023 at 07:16:37PM -0500, Matthew Rosato wrote:

> Yeah, this is also what I was thinking, replace the direct
> kvm_put_kvm calls with, say, schedule_delayed_work in each driver,
> where the delayed task just does the kvm_put_kvm (along with a brief
> comment explaining why we handle the put asynchronously).

Don't put that in every driver, do something like mmput_async() where
the core code has all of this.

> Other than that..  The goal of this patch originally was to get the
> kvm reference at first open_device and release it with the very last
> close_device, so the only other option I could think of would be to
> take the responsibility back from the vfio drivers and do the
> kvm_get_kvm and kvm_put_kvm directly in vfio_main after dropping the
> (but that would result in some ugly symbol linkage and would acquire
> kvm references that a driver maybe does not care about so I don't
> really like that idea)

And we still have the deadlock problem anyhow..

Jason
 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add initial gt workarounds (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Add initial gt workarounds (rev2)
URL   : https://patchwork.freedesktop.org/series/111994/
State : warning

== Summary ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow

[Matt Roper]

On Thu, Jan 05, 2023 at 01:06:37PM +, Tvrtko Ursulin wrote:
> 
> On 04/01/2023 17:41, Matt Roper wrote:
> > On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
> > > 
> > > On 03/01/2023 19:57, Matt Roper wrote:
> > > > On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
> > > > > On 19.12.2022 11:13, Tvrtko Ursulin wrote:
> > > > > > From: Tvrtko Ursulin 
> > > > > > 
> > > > > > As the logic for selecting the register and corresponsing values 
> > > > > > grew, the
> > > > > 
> > > > > corresponding
> > > > > 
> > > > > > code become a bit unsightly. Consolidate by storing the required 
> > > > > > values at
> > > > > > engine init time in the engine itself, and by doing so minimise the 
> > > > > > amount
> > > > > > of invariant platform and engine checks during each and every TLB
> > > > > > invalidation.
> > > > > > 
> > > > > > v2:
> > > > > > * Fail engine probe if TLB invlidations registers are unknown.
> > > > > > 
> > > > > > Signed-off-by: Tvrtko Ursulin 
> > > > > > Cc: Andrzej Hajda 
> > > > > > Cc: Matt Roper 
> > > > > > Reviewed-by: Andrzej Hajda  # v1
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c|  93 +
> > > > > > drivers/gpu/drm/i915/gt/intel_engine_types.h |  15 +++
> > > > > > drivers/gpu/drm/i915/gt/intel_gt.c   | 135 
> > > > > > +++
> > > > > > 3 files changed, 128 insertions(+), 115 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > > > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > index 99c4b866addd..d47dadfc25c8 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > > @@ -1143,12 +1143,105 @@ static int init_status_page(struct 
> > > > > > intel_engine_cs *engine)
> > > > > > return ret;
> > > > > > }
> > > > > > +static int intel_engine_init_tlb_invalidation(struct 
> > > > > > intel_engine_cs *engine)
> > > > > > +{
> > > > > > +   static const union intel_engine_tlb_inv_reg gen8_regs[] = {
> > > > > > +   [RENDER_CLASS].reg  = GEN8_RTCR,
> > > > > > +   [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , 
> > > > > > GEN8_M2TCR */
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN8_VTCR,
> > > > > > +   [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
> > > > > > +   };
> > > > > > +   static const union intel_engine_tlb_inv_reg gen12_regs[] = {
> > > > > > +   [RENDER_CLASS].reg  = GEN12_GFX_TLB_INV_CR,
> > > > > > +   [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN12_VE_TLB_INV_CR,
> > > > > > +   [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
> > > > > > +   [COMPUTE_CLASS].reg = 
> > > > > > GEN12_COMPCTX_TLB_INV_CR,
> > > > > > +   };
> > > > > > +   static const union intel_engine_tlb_inv_reg xehp_regs[] = {
> > > > > > +   [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
> > > > > > +   [VIDEO_DECODE_CLASS].mcr_reg  = XEHP_VD_TLB_INV_CR,
> > > > > > +   [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
> > > > > > +   [COPY_ENGINE_CLASS].mcr_reg   = XEHP_BLT_TLB_INV_CR,
> > > > > > +   [COMPUTE_CLASS].mcr_reg   = 
> > > > > > XEHP_COMPCTX_TLB_INV_CR,
> > > > > > +   };
> > > > > > +   struct drm_i915_private *i915 = engine->i915;
> > > > > > +   const union intel_engine_tlb_inv_reg *regs;
> > > > > > +   union intel_engine_tlb_inv_reg reg;
> > > > > > +   unsigned int class = engine->class;
> > > > > > +   unsigned int num = 0;
> > > > > > +   u32 val;
> > > > > > +
> > > > > > +   /*
> > > > > > +* New platforms should not be added with catch-all-newer (>=)
> > > > > > +* condition so that any later platform added triggers the 
> > > > > > below warning
> > > > > > +* and in turn mandates a human cross-check of whether the 
> > > > > > invalidation
> > > > > > +* flows have compatible semantics.
> > > > > > +*
> > > > > > +* For instance with the 11.00 -> 12.00 transition three out of 
> > > > > > five
> > > > > > +* respective engine registers were moved to masked type. Then 
> > > > > > after the
> > > > > > +* 12.00 -> 12.50 transition multi cast handling is required 
> > > > > > too.
> > > > > > +*/
> > > > > > +
> > > > > > +   if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {
> > > > 
> > > > This is bad...it only captures XEHPSDV and breaks the handling of DG2
> > > > (12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72).  You're not
> > > > hitting the warning as expected since those are all now being captured
> > > > by the next case of the if/else ladder.  With the way GMD_ID works, we
> > > > may also get new version numbers that silently show up in hardware too
> > > > at some point (e.g., 12.73, 12.74, etc.)
> > 

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/tests/drm_format_helper_test.c

between commit:

  a52a5451f43b ("kunit: Use KUNIT_EXPECT_MEMEQ macro")

from Linus' tree and commits:

  f21d62c9ce3d ("drm/format-helper: Store RGB565 in little-endian order")
  175073d694cd ("drm/format-helper: Add conversion from XRGB to ARGB")
  56119bfb3914 ("drm/format-helper: Add conversion from XRGB to 
ARGB2101010")
  10cd592e639e ("drm/format-helper: Add conversion from XRGB to 15-bit 
RGB555 formats")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/tests/drm_format_helper_test.c
index 567c71f95edc,f71dc0fe08a1..
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@@ -375,12 -560,108 +560,108 @@@ static void drm_test_fb_xrgb_to_rgb
iosys_map_set_vaddr(, xrgb);
  
drm_fb_xrgb_to_rgb565(, >dst_pitch, , , 
>clip, false);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
 +  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
  
+   buf = dst.vaddr; /* restore original value of buf */
drm_fb_xrgb_to_rgb565(, >dst_pitch, , , 
>clip, true);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected_swab, dst_size), 0);
 +  KUNIT_EXPECT_MEMEQ(test, buf, result->expected_swab, dst_size);
  }
  
+ static void drm_test_fb_xrgb_to_xrgb1555(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_xrgb1555_result *result = 
>xrgb1555_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+   .format = drm_format_info(DRM_FORMAT_XRGB),
+   .pitches = { params->pitch, 0, 0 },
+   };
+ 
+   dst_size = conversion_buf_size(DRM_FORMAT_XRGB1555, result->dst_pitch,
+  >clip);
+   KUNIT_ASSERT_GT(test, dst_size, 0);
+ 
+   buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+   iosys_map_set_vaddr(, buf);
+ 
+   xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+   iosys_map_set_vaddr(, xrgb);
+ 
+   drm_fb_xrgb_to_xrgb1555(, >dst_pitch, , , 
>clip);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
++  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+ }
+ 
+ static void drm_test_fb_xrgb_to_argb1555(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_argb1555_result *result = 
>argb1555_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+   .format = drm_format_info(DRM_FORMAT_XRGB),
+   .pitches = { params->pitch, 0, 0 },
+   };
+ 
+   dst_size = conversion_buf_size(DRM_FORMAT_ARGB1555, result->dst_pitch,
+  >clip);
+   KUNIT_ASSERT_GT(test, dst_size, 0);
+ 
+   buf = kunit_kzalloc(test, dst_size, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buf);
+   iosys_map_set_vaddr(, buf);
+ 
+   xrgb = cpubuf_to_le32(test, params->xrgb, TEST_BUF_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, xrgb);
+   iosys_map_set_vaddr(, xrgb);
+ 
+   drm_fb_xrgb_to_argb1555(, >dst_pitch, , , 
>clip);
+   buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size / 
sizeof(__le16));
 -  KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
++  KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
+ }
+ 
+ static void drm_test_fb_xrgb_to_rgba5551(struct kunit *test)
+ {
+   const struct convert_xrgb_case *params = test->param_value;
+   const struct convert_to_rgba5551_result *result = 
>rgba5551_result;
+   size_t dst_size;
+   u16 *buf = NULL;
+   __le32 *xrgb = NULL;
+   struct iosys_map dst, src;
+ 
+   struct drm_framebuffer fb = {
+  

[Intel-gfx] [PATCH v3] drm/i915/mtl: Add initial gt workarounds

[Matt Atwood]

From: Matt Roper 

This patch introduces initial gt workarounds for the MTL platform.

v2: drop redundant/stale comments specifying wa platforms affected
(Lucas).
v3: drop additional redundant stale comments (MattR)

Bspec: 66622

Signed-off-by: Matt Roper 
Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   6 +-
 .../drm/i915/gt/intel_execlists_submission.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  11 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 115 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   9 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_device_info.c  |   6 +
 9 files changed, 128 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..e3f30bdf7e61 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1494,10 +1494,12 @@ static int __intel_engine_stop_cs(struct 
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
 
/*
-* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : Prior to doing a reset, ensure CS is
 * stopped, set ring stop bit and prefetch disable bit to halt CS
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
  
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
 
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 2daffa7c7dfd..18ffe55282e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2989,10 +2989,12 @@ static void execlists_reset_prepare(struct 
intel_engine_cs *engine)
intel_engine_stop_cs(engine);
 
/*
-* Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
+* Wa_22011802037: In addition to stopping the cs, we need
 * to wait for any pending mi force wakeups
 */
-   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
+   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+   (GRAPHICS_VER(engine->i915) >= 11 &&
+   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
intel_engine_wait_for_pending_mi_fw(engine);
 
engine->execlists.reset_ccid = active_ccid(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 41a237509dcf..4127830c33ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
} else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
-   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
-intel_uncore_read(gt->uncore, XEHP_FUSE4));
+   /* Wa_14016747170 */
+   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
+   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
+   fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore,
+  
MTL_GT_ACTIVITY_FACTOR));
+   else
+   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
+intel_uncore_read(gt->uncore, 
XEHP_FUSE4));
 
/*
 * Despite the register field being named "exclude mask" the
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f8eb807b56f9..8ad084bd35d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -414,6 +414,7 @@
 #define   TBIMR_FAST_CLIP  REG_BIT(5)
 
 #define VFLSKPDMCR_REG(0x62a8)
+#define   VF_PREFETCH_TLB_DIS  REG_BIT(5)
 #define   DIS_OVER_FETCH_CACHE REG_BIT(1)
 #define   DIS_MULT_MISS_RD_SQUASH  REG_BIT(0)
 
@@ -1535,6 +1536,10 @@
 
 #define MTL_MEDIA_MC6  _MMIO(0x138048)
 
+/* Wa_14016747170 */
+#define MTL_GT_ACTIVITY_FACTOR _MMIO(0x138010)
+#define   MTL_GT_L3_EXC_MASK   

Re: [Intel-gfx] [PATCH v2] drm/i915/mtl: Add initial gt workarounds

[Matt Atwood]

On Tue, Jan 03, 2023 at 04:18:27PM -0800, Matt Roper wrote:
> On Thu, Dec 15, 2022 at 03:30:55PM -0800, Matt Atwood wrote:
> > From: Matt Roper 
> > 
> > This patch introduces initial gt workarounds for the MTL platform.
> > 
> > v2: drop redundant/stale comments specifying wa platforms affected
> 
> This is being discussed on the other thread, but it also doesn't look
> like this actually happened completely in v2 here.  You removed a few
> but most of the workarounds still have them?
Ack.
> 
> > (Lucas). Drop Wa_22011802037 for MTL.
> 
> This statement doesn't seem right...Wa_22011802037 is still (correctly)
> present for the affected variant/steppings of MTL.
You're right.
> 
> 
> Matt
> 
> > 
> > Bspec: 66622
> > 
> > Signed-off-by: Matt Atwood 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c |   6 +-
> >  .../drm/i915/gt/intel_execlists_submission.c  |   6 +-
> >  drivers/gpu/drm/i915/gt/intel_gt_mcr.c|  11 +-
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   5 +
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c   | 115 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc.c|   9 +-
> >  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |   8 +-
> >  drivers/gpu/drm/i915/i915_drv.h   |   4 +
> >  drivers/gpu/drm/i915/intel_device_info.c  |   6 +
> >  9 files changed, 128 insertions(+), 42 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 99c4b866addd..e3f30bdf7e61 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -1494,10 +1494,12 @@ static int __intel_engine_stop_cs(struct 
> > intel_engine_cs *engine,
> > intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
> >  
> > /*
> > -* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
> > +* Wa_22011802037 : Prior to doing a reset, ensure CS is
> >  * stopped, set ring stop bit and prefetch disable bit to halt CS
> >  */
> > -   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
> > +   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
> > +   (GRAPHICS_VER(engine->i915) >= 11 &&
> > +   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
> > intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
> >   
> > _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
> >  
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 49a8f10d76c7..c14476c777cc 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -2989,10 +2989,12 @@ static void execlists_reset_prepare(struct 
> > intel_engine_cs *engine)
> > intel_engine_stop_cs(engine);
> >  
> > /*
> > -* Wa_22011802037:gen11/gen12: In addition to stopping the cs, we need
> > +* Wa_22011802037: In addition to stopping the cs, we need
> >  * to wait for any pending mi force wakeups
> >  */
> > -   if (IS_GRAPHICS_VER(engine->i915, 11, 12))
> > +   if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
> > +   (GRAPHICS_VER(engine->i915) >= 11 &&
> > +   GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
> > intel_engine_wait_for_pending_mi_fw(engine);
> >  
> > engine->execlists.reset_ccid = active_ccid(engine);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index 41a237509dcf..4127830c33ca 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
> > gt->steering_table[OADDRM] = xelpmp_oaddrm_steering_table;
> > } else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > -   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
> > -intel_uncore_read(gt->uncore, XEHP_FUSE4));
> > +   /* Wa_14016747170 */
> > +   if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > +   IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > +   fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
> > +intel_uncore_read(gt->uncore,
> > +  
> > MTL_GT_ACTIVITY_FACTOR));
> > +   else
> > +   fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
> > +intel_uncore_read(gt->uncore, 
> > XEHP_FUSE4));
> >  
> > /*
> >  * Despite the register field being named "exclude mask" the
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 

Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

[Jason Gunthorpe]

On Thu, Jan 05, 2023 at 03:09:30PM -0700, Alex Williamson wrote:
> On Thu, 19 May 2022 14:33:11 -0400
> Matthew Rosato  wrote:
> 
> > Rather than relying on a notifier for associating the KVM with
> > the group, let's assume that the association has already been
> > made prior to device_open.  The first time a device is opened
> > associate the group KVM with the device.
> > 
> > This fixes a user-triggerable oops in GVT.
> 
> It seems this has traded an oops for a deadlock, which still exists
> today in both GVT-g and vfio-ap.  These are the only vfio drivers that
> care about kvm, so they make use of kvm_{get,put}_kvm(), where the
> latter is called by their .close_device() callbacks.

Bleck

It is pretty common to run the final part of 'put' from a workqueue
specifically to avoid stuff like this, eg fput does it

Maybe that is the simplest?

Jason

Re: [Intel-gfx] [PATCH] drm/i915/gt: Cover rest of SVG unit MCR registers

[Matt Roper]

On Thu, Jan 05, 2023 at 10:37:01AM -0300, Gustavo Sousa wrote:
> CHICKEN_RASTER_{1,2} got overlooked with the move done in a9e69428b1b4
> ("drm/i915: Define MCR registers explicitly"). Registers from the SVG
> unit became multicast as of Xe_HP graphics.
> 
> BSpec: 66534
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly").
> Signed-off-by: Gustavo Sousa 
> Cc: Matt Roper 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index f8eb807b56f9..570699548c77 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -407,10 +407,10 @@
>  #define GEN9_WM_CHICKEN3 _MMIO(0x5588)
>  #define   GEN9_FACTOR_IN_CLR_VAL_HIZ (1 << 9)
>  
> -#define CHICKEN_RASTER_1 _MMIO(0x6204)
> +#define CHICKEN_RASTER_1 MCR_REG(0x6204)
>  #define   DIS_SF_ROUND_NEAREST_EVEN  REG_BIT(8)
>  
> -#define CHICKEN_RASTER_2 _MMIO(0x6208)
> +#define CHICKEN_RASTER_2 MCR_REG(0x6208)
>  #define   TBIMR_FAST_CLIPREG_BIT(5)
>  
>  #define VFLSKPD  MCR_REG(0x62a8)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index bf84efb3f15f..9a40aa61e86e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -645,7 +645,7 @@ static void icl_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>  static void dg2_ctx_gt_tuning_init(struct intel_engine_cs *engine,
>  struct i915_wa_list *wal)
>  {
> - wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
> + wa_mcr_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
>   wa_mcr_write_clr_set(wal, XEHP_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
>REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
>   wa_mcr_add(wal,
> @@ -780,7 +780,7 @@ static void dg2_ctx_workarounds_init(struct 
> intel_engine_cs *engine,
>   wa_masked_en(wal, PSS_MODE2, SCOREBOARD_STALL_FLUSH_CONTROL);
>  
>   /* Wa_15010599737:dg2 */
> - wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
> + wa_mcr_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
>  
>   /* Wa_18019271663:dg2 */
>   wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
> -- 
> 2.39.0
> 

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update docs in intel_wakeref.h

[Patchwork]

== Series Details ==

Series: drm/i915: Update docs in intel_wakeref.h
URL   : https://patchwork.freedesktop.org/series/112454/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12550 -> Patchwork_112454v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 43)
--

  Additional (2): fi-kbl-soraka fi-bsw-kefka 
  Missing(2): fi-rkl-11600 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112454v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.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_112454v1/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_112454v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html

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

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

  * igt@i915_selftest@live@late_gt_pm:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][6] ([i915#7640])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112454v1/fi-kbl-soraka/igt@i915_selftest@live@late_gt_pm.html

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

  * igt@prime_vgem@basic-fence-flip:
- fi-bsw-kefka:   NOTRUN -> [SKIP][9] ([fdo#109271]) +17 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112454v1/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-rte:
- {bat-adln-1}:   [DMESG-WARN][10] ([i915#7077]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12550/bat-adln-1/igt@i915_pm_...@basic-rte.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112454v1/bat-adln-1/igt@i915_pm_...@basic-rte.html

  * igt@i915_selftest@live@workarounds:
- {bat-rpls-1}:   [INCOMPLETE][12] -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12550/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112454v1/bat-rpls-1/igt@i915_selftest@l...@workarounds.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
  [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
  [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#7640]: https://gitlab.freedesktop.org/drm/intel/issues/7640


Build changes
-

  * Linux: CI_DRM_12550 -> Patchwork_112454v1

  CI-20190529: 20190529
  CI_DRM_12550: f604441f326ba242fc0b0f86dc2468863d204c97 @ 
git://anongit.freedesktop.org/gfx-ci/linux

Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM

[Alex Williamson]

On Thu, 19 May 2022 14:33:11 -0400
Matthew Rosato  wrote:

> Rather than relying on a notifier for associating the KVM with
> the group, let's assume that the association has already been
> made prior to device_open.  The first time a device is opened
> associate the group KVM with the device.
> 
> This fixes a user-triggerable oops in GVT.

It seems this has traded an oops for a deadlock, which still exists
today in both GVT-g and vfio-ap.  These are the only vfio drivers that
care about kvm, so they make use of kvm_{get,put}_kvm(), where the
latter is called by their .close_device() callbacks.

.close_device() is called holding the group->group_lock, or at the time
of this commit group->group_rwsem.  The remaining call chain looks like
this:

kvm_put_kvm
 -> kvm_destroy_vm
  -> kvm_destroy_devices
   -> kvm_vfio_destroy
-> kvm_vfio_file_set_kvm
 -> vfio_file_set_kvm
  -> group->group_lock/group_rwsem

Any suggestions for a fix?  Thanks,

Alex

[Intel-gfx] linux-next: duplicate patches in the drm-misc tree

[Stephen Rothwell]

Hi all,

The following commits also exist in Linus Torvald's tree as different
commits (but the same patches):

  a189b2ee938f ("fbdev: Make fb_modesetting_disabled() static inline")
  7aa3d63e1ad5 ("Revert "drm/fb-helper: Remove damage worker"")
  8b83e1a45538 ("Revert "drm/fb-helper: Schedule deferred-I/O worker after 
writing to framebuffer"")
  e3ddd2d25533 ("Revert "drm/fb-helper: Perform damage handling in deferred-I/O 
helper"")

-- 
Cheers,
Stephen Rothwell


pgp8Gg5LaYB2y.pgp
Description: OpenPGP digital signature

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

[Matthew Brost]

On Tue, Jan 03, 2023 at 01:02:15PM +, Tvrtko Ursulin wrote:
> 
> On 02/01/2023 07:30, Boris Brezillon wrote:
> > On Fri, 30 Dec 2022 12:55:08 +0100
> > Boris Brezillon  wrote:
> > 
> > > On Fri, 30 Dec 2022 11:20:42 +0100
> > > Boris Brezillon  wrote:
> > > 
> > > > Hello Matthew,
> > > > 
> > > > On Thu, 22 Dec 2022 14:21:11 -0800
> > > > Matthew Brost  wrote:
> > > > > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At first 
> > > > > this
> > > > > seems a bit odd but let us explain the reasoning below.
> > > > > 
> > > > > 1. In XE the submission order from multiple drm_sched_entity is not
> > > > > guaranteed to be the same completion even if targeting the same 
> > > > > hardware
> > > > > engine. This is because in XE we have a firmware scheduler, the GuC,
> > > > > which allowed to reorder, timeslice, and preempt submissions. If a 
> > > > > using
> > > > > shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR 
> > > > > falls
> > > > > apart as the TDR expects submission order == completion order. Using a
> > > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
> > > > 
> > > > Oh, that's interesting. I've been trying to solve the same sort of
> > > > issues to support Arm's new Mali GPU which is relying on a FW-assisted
> > > > scheduling scheme (you give the FW N streams to execute, and it does
> > > > the scheduling between those N command streams, the kernel driver
> > > > does timeslice scheduling to update the command streams passed to the
> > > > FW). I must admit I gave up on using drm_sched at some point, mostly
> > > > because the integration with drm_sched was painful, but also because I
> > > > felt trying to bend drm_sched to make it interact with a
> > > > timeslice-oriented scheduling model wasn't really future proof. Giving
> > > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably might
> > > > help for a few things (didn't think it through yet), but I feel it's
> > > > coming short on other aspects we have to deal with on Arm GPUs.
> > > 
> > > Ok, so I just had a quick look at the Xe driver and how it
> > > instantiates the drm_sched_entity and drm_gpu_scheduler, and I think I
> > > have a better understanding of how you get away with using drm_sched
> > > while still controlling how scheduling is really done. Here
> > > drm_gpu_scheduler is just a dummy abstract that let's you use the
> > > drm_sched job queuing/dep/tracking mechanism. The whole run-queue
> > > selection is dumb because there's only one entity ever bound to the
> > > scheduler (the one that's part of the xe_guc_engine object which also
> > > contains the drm_gpu_scheduler instance). I guess the main issue we'd
> > > have on Arm is the fact that the stream doesn't necessarily get
> > > scheduled when ->run_job() is called, it can be placed in the runnable
> > > queue and be picked later by the kernel-side scheduler when a FW slot
> > > gets released. That can probably be sorted out by manually disabling the
> > > job timer and re-enabling it when the stream gets picked by the
> > > scheduler. But my main concern remains, we're basically abusing
> > > drm_sched here.
> > > 
> > > For the Arm driver, that means turning the following sequence
> > > 
> > > 1. wait for job deps
> > > 2. queue job to ringbuf and push the stream to the runnable
> > > queue (if it wasn't queued already). Wakeup the timeslice scheduler
> > > to re-evaluate (if the stream is not on a FW slot already)
> > > 3. stream gets picked by the timeslice scheduler and sent to the FW for
> > > execution
> > > 
> > > into
> > > 
> > > 1. queue job to entity which takes care of waiting for job deps for
> > > us
> > > 2. schedule a drm_sched_main iteration
> > > 3. the only available entity is picked, and the first job from this
> > > entity is dequeued. ->run_job() is called: the job is queued to the
> > > ringbuf and the stream is pushed to the runnable queue (if it wasn't
> > > queued already). Wakeup the timeslice scheduler to re-evaluate (if
> > > the stream is not on a FW slot already)
> > > 4. stream gets picked by the timeslice scheduler and sent to the FW for
> > > execution
> > > 
> > > That's one extra step we don't really need. To sum-up, yes, all the
> > > job/entity tracking might be interesting to share/re-use, but I wonder
> > > if we couldn't have that without pulling out the scheduling part of
> > > drm_sched, or maybe I'm missing something, and there's something in
> > > drm_gpu_scheduler you really need.
> > 
> > On second thought, that's probably an acceptable overhead (not even
> > sure the extra step I was mentioning exists in practice, because dep
> > fence signaled state is checked as part of the drm_sched_main
> > iteration, so that's basically replacing the worker I schedule to
> > check job deps), and I like the idea of being able to re-use 

Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission

[Matthew Brost]

On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote:
> 
> On 22/12/2022 22:21, Matthew Brost wrote:
> > Hello,
> > 
> > This is a submission for Xe, a new driver for Intel GPUs that supports both
> > integrated and discrete platforms starting with Tiger Lake (first platform 
> > with
> > Intel Xe Architecture). The intention of this new driver is to have a fresh 
> > base
> > to work from that is unencumbered by older platforms, whilst also taking the
> > opportunity to rearchitect our driver to increase sharing across the drm
> > subsystem, both leveraging and allowing us to contribute more towards other
> > shared components like TTM and drm/scheduler. The memory model is based on 
> > VM
> > bind which is similar to the i915 implementation. Likewise the execbuf
> > implementation for Xe is very similar to execbuf3 in the i915 [1].
> > 
> > The code is at a stage where it is already functional and has experimental
> > support for multiple platforms starting from Tiger Lake, with initial 
> > support
> > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as 
> > well
> > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO
> > implementation will be released publicly early next year. We also have a 
> > suite
> > of IGTs for XE that will appear on the IGT list shortly.
> > 
> > It has been built with the assumption of supporting multiple architectures 
> > from
> > the get-go, right now with tests running both on X86 and ARM hosts. And we
> > intend to continue working on it and improving on it as part of the kernel
> > community upstream.
> > 
> > The new Xe driver leverages a lot from i915 and work on i915 continues as we
> > ready Xe for production throughout 2023.
> > 
> > As for display, the intent is to share the display code with the i915 
> > driver so
> > that there is maximum reuse there. Currently this is being done by 
> > compiling the
> > display code twice, but alternatives to that are under consideration and we 
> > want
> > to have more discussion on what the best final solution will look like over 
> > the
> > next few months. Right now, work is ongoing in refactoring the display 
> > codebase
> > to remove as much as possible any unnecessary dependencies on i915 specific 
> > data
> > structures there..
> > 
> > We currently have 2 submission backends, execlists and GuC. The execlist is
> > meant mostly for testing and is not fully functional while GuC backend is 
> > fully
> > functional. As with the i915 and GuC submission, in Xe the GuC firmware is
> > required and should be placed in /lib/firmware/xe.
> 
> What is the plan going forward for the execlists backend? I think it would
> be preferable to not upstream something semi-functional and so to carry
> technical debt in the brand new code base, from the very start. If it is for
> Tigerlake, which is the starting platform for Xe, could it be made GuC only
> Tigerlake for instance?
> 

A little background here. In the original PoC written by Jason and Dave,
the execlist backend was the only one present and it was in semi-working
state. As soon as myself and a few others started working on Xe we went
full in a on the GuC backend. We left the execlist backend basically in
the state it was in. We left it in place for 2 reasons.

1. Having 2 backends from the start ensured we layered our code
correctly. The layer was a complete disaster in the i915 so we really
wanted to avoid that.
2. The thought was it might be needed for early product bring up one
day.

As I think about this a bit more, we likely just delete execlist backend
before merging this upstream and perhaps just carry 1 large patch
internally with this implementation that we can use as needed. Final
decession TDB though.

Matt

> Regards,
> 
> Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915: Update docs in intel_wakeref.h

[Dixit, Ashutosh]

On Thu, 05 Jan 2023 12:38:43 -0800, Nirmoy Das wrote:
>
> Fix docs for __intel_wakeref_put() and intel_wakeref_get() to
> reflect current behaviour.

Reviewed-by: Ashutosh Dixit 

> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/i915/intel_wakeref.h | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
> b/drivers/gpu/drm/i915/intel_wakeref.h
> index 4f4c2e15e736..71b8a63f6f10 100644
> --- a/drivers/gpu/drm/i915/intel_wakeref.h
> +++ b/drivers/gpu/drm/i915/intel_wakeref.h
> @@ -68,11 +68,12 @@ void __intel_wakeref_put_last(struct intel_wakeref *wf, 
> unsigned long flags);
>   * @wf: the wakeref
>   *
>   * Acquire a hold on the wakeref. The first user to do so, will acquire
> - * the runtime pm wakeref and then call the @fn underneath the wakeref
> - * mutex.
> + * the runtime pm wakeref and then call the intel_wakeref_ops->get()
> + * underneath the wakeref mutex.
>   *
> - * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> - * will be released and the acquisition unwound, and an error reported.
> + * Note that intel_wakeref_ops->get() is allowed to fail, in which case
> + * the runtime-pm wakeref will be released and the acquisition unwound,
> + * and an error reported.
>   *
>   * Returns: 0 if the wakeref was acquired successfully, or a negative error
>   * code otherwise.
> @@ -130,19 +131,17 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
>  }
>
>  /**
> - * intel_wakeref_put_flags: Release the wakeref
> + * __intel_wakeref_put: Release the wakeref
>   * @wf: the wakeref
>   * @flags: control flags
>   *
>   * Release our hold on the wakeref. When there are no more users,
> - * the runtime pm wakeref will be released after the @fn callback is called
> - * underneath the wakeref mutex.
> + * the runtime pm wakeref will be released after the intel_wakeref_ops->put()
> + * callback is called underneath the wakeref mutex.
>   *
> - * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> - * is retained and an error reported.
> + * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
> + * runtime-pm wakeref is retained.
>   *
> - * Returns: 0 if the wakeref was released successfully, or a negative error
> - * code otherwise.
>   */
>  static inline void
>  __intel_wakeref_put(struct intel_wakeref *wf, unsigned long flags)
> --
> 2.38.0
>

[Intel-gfx] [PATCH] drm/i915: Update docs in intel_wakeref.h

[Nirmoy Das]

Fix docs for __intel_wakeref_put() and intel_wakeref_get() to
reflect current behaviour.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/intel_wakeref.h | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
b/drivers/gpu/drm/i915/intel_wakeref.h
index 4f4c2e15e736..71b8a63f6f10 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -68,11 +68,12 @@ void __intel_wakeref_put_last(struct intel_wakeref *wf, 
unsigned long flags);
  * @wf: the wakeref
  *
  * Acquire a hold on the wakeref. The first user to do so, will acquire
- * the runtime pm wakeref and then call the @fn underneath the wakeref
- * mutex.
+ * the runtime pm wakeref and then call the intel_wakeref_ops->get()
+ * underneath the wakeref mutex.
  *
- * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
- * will be released and the acquisition unwound, and an error reported.
+ * Note that intel_wakeref_ops->get() is allowed to fail, in which case
+ * the runtime-pm wakeref will be released and the acquisition unwound,
+ * and an error reported.
  *
  * Returns: 0 if the wakeref was acquired successfully, or a negative error
  * code otherwise.
@@ -130,19 +131,17 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
 }
 
 /**
- * intel_wakeref_put_flags: Release the wakeref
+ * __intel_wakeref_put: Release the wakeref
  * @wf: the wakeref
  * @flags: control flags
  *
  * Release our hold on the wakeref. When there are no more users,
- * the runtime pm wakeref will be released after the @fn callback is called
- * underneath the wakeref mutex.
+ * the runtime pm wakeref will be released after the intel_wakeref_ops->put()
+ * callback is called underneath the wakeref mutex.
  *
- * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
- * is retained and an error reported.
+ * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
+ * runtime-pm wakeref is retained.
  *
- * Returns: 0 if the wakeref was released successfully, or a negative error
- * code otherwise.
  */
 static inline void
 __intel_wakeref_put(struct intel_wakeref *wf, unsigned long flags)
-- 
2.38.0

Re: [Intel-gfx] [PATCH v2 3/9] drm/i915/display/dpll: use intel_de_rmw if possible

[Rodrigo Vivi]

On Thu, Jan 05, 2023 at 02:10:40PM +0100, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 165 ++
>  1 file changed, 53 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 1974eb580ed198..e9215ebcdfc44d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -608,10 +608,8 @@ static void hsw_ddi_wrpll_disable(struct 
> drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
>  {
>   const enum intel_dpll_id id = pll->info->id;
> - u32 val;
>  
> - val = intel_de_read(dev_priv, WRPLL_CTL(id));
> - intel_de_write(dev_priv, WRPLL_CTL(id), val & ~WRPLL_PLL_ENABLE);
> + intel_de_rmw(dev_priv, WRPLL_CTL(id), WRPLL_PLL_ENABLE, 0);
>   intel_de_posting_read(dev_priv, WRPLL_CTL(id));
>  
>   /*
> @@ -626,10 +624,8 @@ static void hsw_ddi_spll_disable(struct drm_i915_private 
> *dev_priv,
>struct intel_shared_dpll *pll)
>  {
>   enum intel_dpll_id id = pll->info->id;
> - u32 val;
>  
> - val = intel_de_read(dev_priv, SPLL_CTL);
> - intel_de_write(dev_priv, SPLL_CTL, val & ~SPLL_PLL_ENABLE);
> + intel_de_rmw(dev_priv, SPLL_CTL, SPLL_PLL_ENABLE, 0);
>   intel_de_posting_read(dev_priv, SPLL_CTL);
>  
>   /*
> @@ -1238,16 +1234,10 @@ static void skl_ddi_pll_write_ctrl1(struct 
> drm_i915_private *dev_priv,
>   struct intel_shared_dpll *pll)
>  {
>   const enum intel_dpll_id id = pll->info->id;
> - u32 val;
>  
> - val = intel_de_read(dev_priv, DPLL_CTRL1);
> -
> - val &= ~(DPLL_CTRL1_HDMI_MODE(id) |
> -  DPLL_CTRL1_SSC(id) |
> -  DPLL_CTRL1_LINK_RATE_MASK(id));
> - val |= pll->state.hw_state.ctrl1 << (id * 6);
> -
> - intel_de_write(dev_priv, DPLL_CTRL1, val);
> + intel_de_rmw(dev_priv, DPLL_CTRL1,
> +  DPLL_CTRL1_HDMI_MODE(id) | DPLL_CTRL1_SSC(id) | 
> DPLL_CTRL1_LINK_RATE_MASK(id),
> +  pll->state.hw_state.ctrl1 << (id * 6));
>   intel_de_posting_read(dev_priv, DPLL_CTRL1);
>  }
>  
> @@ -1265,8 +1255,7 @@ static void skl_ddi_pll_enable(struct drm_i915_private 
> *dev_priv,
>   intel_de_posting_read(dev_priv, regs[id].cfgcr2);
>  
>   /* the enable bit is always bit 31 */
> - intel_de_write(dev_priv, regs[id].ctl,
> -intel_de_read(dev_priv, regs[id].ctl) | 
> LCPLL_PLL_ENABLE);
> + intel_de_rmw(dev_priv, regs[id].ctl, 0, LCPLL_PLL_ENABLE);
>  
>   if (intel_de_wait_for_set(dev_priv, DPLL_STATUS, DPLL_LOCK(id), 5))
>   drm_err(_priv->drm, "DPLL %d not locked\n", id);
> @@ -1285,8 +1274,7 @@ static void skl_ddi_pll_disable(struct drm_i915_private 
> *dev_priv,
>   const enum intel_dpll_id id = pll->info->id;
>  
>   /* the enable bit is always bit 31 */
> - intel_de_write(dev_priv, regs[id].ctl,
> -intel_de_read(dev_priv, regs[id].ctl) & 
> ~LCPLL_PLL_ENABLE);
> + intel_de_rmw(dev_priv, regs[id].ctl, LCPLL_PLL_ENABLE, 0);
>   intel_de_posting_read(dev_priv, regs[id].ctl);
>  }
>  
> @@ -1902,14 +1890,11 @@ static void bxt_ddi_pll_enable(struct 
> drm_i915_private *dev_priv,
>   bxt_port_to_phy_channel(dev_priv, port, , );
>  
>   /* Non-SSC reference */
> - temp = intel_de_read(dev_priv, BXT_PORT_PLL_ENABLE(port));
> - temp |= PORT_PLL_REF_SEL;
> - intel_de_write(dev_priv, BXT_PORT_PLL_ENABLE(port), temp);
> + intel_de_rmw(dev_priv, BXT_PORT_PLL_ENABLE(port), 0, PORT_PLL_REF_SEL);
>  
>   if (IS_GEMINILAKE(dev_priv)) {
> - temp = intel_de_read(dev_priv, BXT_PORT_PLL_ENABLE(port));
> - temp |= PORT_PLL_POWER_ENABLE;
> - intel_de_write(dev_priv, BXT_PORT_PLL_ENABLE(port), temp);
> + intel_de_rmw(dev_priv, BXT_PORT_PLL_ENABLE(port),
> +  0, PORT_PLL_POWER_ENABLE);
>  
>   if (wait_for_us((intel_de_read(dev_priv, 
> BXT_PORT_PLL_ENABLE(port)) &
>PORT_PLL_POWER_STATE), 200))
> @@ -1918,39 +1903,28 @@ static void bxt_ddi_pll_enable(struct 
> drm_i915_private *dev_priv,
>   }
>  
>   /* Disable 10 bit clock */
> - temp = intel_de_read(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch));
> - temp &= ~PORT_PLL_10BIT_CLK_ENABLE;
> - intel_de_write(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch), temp);
> + intel_de_rmw(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch),
> +  PORT_PLL_10BIT_CLK_ENABLE, 0);
>  
>   /* Write P1 & P2 */
> - temp = intel_de_read(dev_priv, BXT_PORT_PLL_EBB_0(phy, ch));
> - temp &= ~(PORT_PLL_P1_MASK | PORT_PLL_P2_MASK);
> - temp |= pll->state.hw_state.ebb0;
> - 

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/display/power: use intel_de_rmw if possible

[Rodrigo Vivi]

On Thu, Jan 05, 2023 at 02:10:39PM +0100, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../drm/i915/display/intel_display_power.c| 49 ---
>  .../i915/display/intel_display_power_well.c   | 82 ++-
>  2 files changed, 39 insertions(+), 92 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 1a23ecd4623a53..90d7a623d6e3cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -1260,9 +1260,7 @@ static void hsw_disable_lcpll(struct drm_i915_private 
> *dev_priv,
>   drm_err(_priv->drm, "D_COMP RCOMP still in progress\n");
>  
>   if (allow_power_down) {
> - val = intel_de_read(dev_priv, LCPLL_CTL);
> - val |= LCPLL_POWER_DOWN_ALLOW;
> - intel_de_write(dev_priv, LCPLL_CTL, val);
> + intel_de_rmw(dev_priv, LCPLL_CTL, 0, LCPLL_POWER_DOWN_ALLOW);
>   intel_de_posting_read(dev_priv, LCPLL_CTL);
>   }
>  }
> @@ -1306,9 +1304,7 @@ static void hsw_restore_lcpll(struct drm_i915_private 
> *dev_priv)
>   drm_err(_priv->drm, "LCPLL not locked yet\n");
>  
>   if (val & LCPLL_CD_SOURCE_FCLK) {
> - val = intel_de_read(dev_priv, LCPLL_CTL);
> - val &= ~LCPLL_CD_SOURCE_FCLK;
> - intel_de_write(dev_priv, LCPLL_CTL, val);
> + intel_de_rmw(dev_priv, LCPLL_CTL, LCPLL_CD_SOURCE_FCLK, 0);
>  
>   if (wait_for_us((intel_de_read(dev_priv, LCPLL_CTL) &
>LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
> @@ -1347,15 +1343,11 @@ static void hsw_restore_lcpll(struct drm_i915_private 
> *dev_priv)
>   */
>  static void hsw_enable_pc8(struct drm_i915_private *dev_priv)
>  {
> - u32 val;
> -
>   drm_dbg_kms(_priv->drm, "Enabling package C8+\n");
>  
> - if (HAS_PCH_LPT_LP(dev_priv)) {
> - val = intel_de_read(dev_priv, SOUTH_DSPCLK_GATE_D);
> - val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
> - intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D, val);
> - }
> + if (HAS_PCH_LPT_LP(dev_priv))
> + intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
> +  PCH_LP_PARTITION_LEVEL_DISABLE, 0);
>  
>   lpt_disable_clkout_dp(dev_priv);
>   hsw_disable_lcpll(dev_priv, true, true);
> @@ -1363,25 +1355,21 @@ static void hsw_enable_pc8(struct drm_i915_private 
> *dev_priv)
>  
>  static void hsw_disable_pc8(struct drm_i915_private *dev_priv)
>  {
> - u32 val;
> -
>   drm_dbg_kms(_priv->drm, "Disabling package C8+\n");
>  
>   hsw_restore_lcpll(dev_priv);
>   intel_init_pch_refclk(dev_priv);
>  
> - if (HAS_PCH_LPT_LP(dev_priv)) {
> - val = intel_de_read(dev_priv, SOUTH_DSPCLK_GATE_D);
> - val |= PCH_LP_PARTITION_LEVEL_DISABLE;
> - intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D, val);
> - }
> + if (HAS_PCH_LPT_LP(dev_priv))
> + intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
> +  0, PCH_LP_PARTITION_LEVEL_DISABLE);
>  }
>  
>  static void intel_pch_reset_handshake(struct drm_i915_private *dev_priv,
> bool enable)
>  {
>   i915_reg_t reg;
> - u32 reset_bits, val;
> + u32 reset_bits;
>  
>   if (IS_IVYBRIDGE(dev_priv)) {
>   reg = GEN7_MSG_CTL;
> @@ -1394,14 +1382,7 @@ static void intel_pch_reset_handshake(struct 
> drm_i915_private *dev_priv,
>   if (DISPLAY_VER(dev_priv) >= 14)
>   reset_bits |= MTL_RESET_PICA_HANDSHAKE_EN;
>  
> - val = intel_de_read(dev_priv, reg);
> -
> - if (enable)
> - val |= reset_bits;
> - else
> - val &= ~reset_bits;
> -
> - intel_de_write(dev_priv, reg, val);
> + intel_de_rmw(dev_priv, reg, reset_bits, enable ? reset_bits : 0);

I believe we have a risk here since we were only cleaning if not enable.
But anyway this looks the right thing to do here...


Reviewed-by: Rodrigo Vivi 


>  }
>  
>  static void skl_display_core_init(struct drm_i915_private *dev_priv,
> @@ -1618,7 +1599,6 @@ static void icl_display_core_init(struct 
> drm_i915_private *dev_priv,
>  {
>   struct i915_power_domains *power_domains = 
> _priv->display.power.domains;
>   struct i915_power_well *well;
> - u32 val;
>  
>   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
>  
> @@ -1670,11 +1650,10 @@ static void icl_display_core_init(struct 
> drm_i915_private *dev_priv,
>   intel_dmc_load_program(dev_priv);
>  
>   /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - val = DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM |
> -   DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR;
> - intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 

Re: [Intel-gfx] [PATCH v2 1/9] drm/i915/display/core: use intel_de_rmw if possible

[Rodrigo Vivi]

On Thu, Jan 05, 2023 at 02:10:38PM +0100, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 22 ---
>  .../drm/i915/display/intel_modeset_setup.c| 17 ++
>  2 files changed, 16 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e75b9b2a0e015a..ce506c9fd6ab9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -293,11 +293,11 @@ static void
>  skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
>  {
>   if (enable)
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
> DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
> +  0, DUPS1_GATING_DIS | DUPS2_GATING_DIS);
>   else
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
> +  DUPS1_GATING_DIS | DUPS2_GATING_DIS, 0);
>  }
>  
>  /* Wa_2006604312:icl,ehl */
> @@ -306,11 +306,9 @@ icl_wa_scalerclkgating(struct drm_i915_private 
> *dev_priv, enum pipe pipe,
>  bool enable)
>  {
>   if (enable)
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
> DPFR_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), 0, 
> DPFR_GATING_DIS);
>   else
> - intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> -intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
> ~DPFR_GATING_DIS);
> + intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), DPFR_GATING_DIS, 
> 0);
>  }
>  
>  /* Wa_1604331009:icl,jsl,ehl */
> @@ -1852,12 +1850,10 @@ static void hsw_set_frame_start_delay(const struct 
> intel_crtc_state *crtc_state)
>   enum transcoder transcoder = crtc_state->cpu_transcoder;
>   i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ? 
> MTL_CHICKEN_TRANS(transcoder) :
>CHICKEN_TRANS(transcoder);
> - u32 val;
>  
> - val = intel_de_read(dev_priv, reg);
> - val &= ~HSW_FRAME_START_DELAY_MASK;
> - val |= HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1);
> - intel_de_write(dev_priv, reg, val);
> + intel_de_rmw(dev_priv, reg,
> +  HSW_FRAME_START_DELAY_MASK,
> +  HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1));
>  }
>  
>  static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c 
> b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> index 96395bfbd41dfb..6f6dc7c6b88b0c 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> @@ -647,17 +647,14 @@ static void intel_early_display_was(struct 
> drm_i915_private *i915)
>* Also known as Wa_14010480278.
>*/
>   if (IS_DISPLAY_VER(i915, 10, 12))
> - intel_de_write(i915, GEN9_CLKGATE_DIS_0,
> -intel_de_read(i915, GEN9_CLKGATE_DIS_0) | 
> DARBF_GATING_DIS);
> + intel_de_rmw(i915, GEN9_CLKGATE_DIS_0, 0, DARBF_GATING_DIS);
>  
> - if (IS_HASWELL(i915)) {
> - /*
> -  * WaRsPkgCStateDisplayPMReq:hsw
> -  * System hang if this isn't done before disabling all planes!
> -  */
> - intel_de_write(i915, CHICKEN_PAR1_1,
> -intel_de_read(i915, CHICKEN_PAR1_1) | 
> FORCE_ARB_IDLE_PLANES);
> - }
> + /*
> +  * WaRsPkgCStateDisplayPMReq:hsw
> +  * System hang if this isn't done before disabling all planes!
> +  */
> + if (IS_HASWELL(i915))
> + intel_de_rmw(i915, CHICKEN_PAR1_1, 0, FORCE_ARB_IDLE_PLANES);
>  
>   if (IS_KABYLAKE(i915) || IS_COFFEELAKE(i915) || IS_COMETLAKE(i915)) {
>   /* Display WA #1142:kbl,cfl,cml */
> -- 
> 2.34.1
> 

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

[Rodrigo Vivi]

Hi Dave and Daniel,

Only GVT related fixes for this round.

I have another fix queued for i915_vma_unbind_async from Nirmoy that will
target stable 5.18, but I figured it out late so I didn't run CI on that yet.
So I'm holding this for now. Maybe and extra PR tomorrow or it will
wait for the next week.

Here goes drm-intel-fixes-2023-01-05:

Only gvt-fixes:
 - debugfs fixes (Zhenyu)
 - fix up for vgpu status (Zhi)
 - double free fix in split_2MB_gtt_entry (Zheng)

Thanks,
Rodrigo.

The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:

  Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-01-05

for you to fetch changes up to 87809d3196c2a7a015ab80ca1cb8c19b659bc5f6:

  Merge tag 'gvt-fixes-2023-01-05' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2023-01-05 08:03:38 -0500)


Only gvt-fixes:
 - debugfs fixes (Zhenyu)
 - fix up for vgpu status (Zhi)
 - double free fix in split_2MB_gtt_entry (Zheng)


Dan Carpenter (1):
  drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2023-01-05' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Zheng Wang (1):
  drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

Zhenyu Wang (2):
  drm/i915/gvt: fix gvt debugfs destroy
  drm/i915/gvt: fix vgpu debugfs clean in remove

Zhi Wang (1):
  drm/i915/gvt: use atomic operations to change the vGPU status

 drivers/gpu/drm/i915/gvt/debugfs.c   | 36 +++-
 drivers/gpu/drm/i915/gvt/dmabuf.c|  3 ++-
 drivers/gpu/drm/i915/gvt/gtt.c   | 21 +++--
 drivers/gpu/drm/i915/gvt/gvt.h   | 15 ++-
 drivers/gpu/drm/i915/gvt/interrupt.c |  2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +--
 drivers/gpu/drm/i915/gvt/scheduler.c |  4 +++-
 drivers/gpu/drm/i915/gvt/vgpu.c  | 12 +---
 8 files changed, 80 insertions(+), 48 deletions(-)

Re: [Intel-gfx] [PATCH] drm/i915: Update doc for __intel_wakeref_put()

[Das, Nirmoy]

Hi Andi and Ashutosh,

On 1/5/2023 6:47 PM, Andi Shyti wrote:


   *
- * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
- * is retained and an error reported.
+ * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
+ * runtime-pm wakeref is retained.

@fn is used in multiple places in this file (including some 'get' usages)
so maybe needs to be fixed there too. Maybe better to just say somewhere
@fn refers to ops->get()/put() where applicable?

yeah... as Nirmoy is at it, I think he can take care of the rest,
would you, Nirmoy?



Sorry I missed that. I will squash everything into one patch.


Thanks,

Nirmoy

Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread

[Matthew Brost]

On Mon, Jan 02, 2023 at 08:30:19AM +0100, Boris Brezillon wrote:
> On Fri, 30 Dec 2022 12:55:08 +0100
> Boris Brezillon  wrote:
> 
> > On Fri, 30 Dec 2022 11:20:42 +0100
> > Boris Brezillon  wrote:
> > 
> > > Hello Matthew,
> > > 
> > > On Thu, 22 Dec 2022 14:21:11 -0800
> > > Matthew Brost  wrote:
> > >   
> > > > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > > > mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> > > > seems a bit odd but let us explain the reasoning below.
> > > > 
> > > > 1. In XE the submission order from multiple drm_sched_entity is not
> > > > guaranteed to be the same completion even if targeting the same hardware
> > > > engine. This is because in XE we have a firmware scheduler, the GuC,
> > > > which allowed to reorder, timeslice, and preempt submissions. If a using
> > > > shared drm_gpu_scheduler across multiple drm_sched_entity, the TDR falls
> > > > apart as the TDR expects submission order == completion order. Using a
> > > > dedicated drm_gpu_scheduler per drm_sched_entity solve this problem.
> > > 
> > > Oh, that's interesting. I've been trying to solve the same sort of
> > > issues to support Arm's new Mali GPU which is relying on a FW-assisted
> > > scheduling scheme (you give the FW N streams to execute, and it does
> > > the scheduling between those N command streams, the kernel driver
> > > does timeslice scheduling to update the command streams passed to the
> > > FW). I must admit I gave up on using drm_sched at some point, mostly
> > > because the integration with drm_sched was painful, but also because I
> > > felt trying to bend drm_sched to make it interact with a
> > > timeslice-oriented scheduling model wasn't really future proof. Giving
> > > drm_sched_entity exlusive access to a drm_gpu_scheduler probably might
> > > help for a few things (didn't think it through yet), but I feel it's
> > > coming short on other aspects we have to deal with on Arm GPUs.  
> > 
> > Ok, so I just had a quick look at the Xe driver and how it
> > instantiates the drm_sched_entity and drm_gpu_scheduler, and I think I
> > have a better understanding of how you get away with using drm_sched
> > while still controlling how scheduling is really done. Here
> > drm_gpu_scheduler is just a dummy abstract that let's you use the
> > drm_sched job queuing/dep/tracking mechanism. The whole run-queue

You nailed it here, we use the DRM scheduler for queuing jobs,
dependency tracking and releasing jobs to be scheduled when dependencies
are met, and lastly a tracking mechanism of inflights jobs that need to
be cleaned up if an error occurs. It doesn't actually do any scheduling
aside from the most basic level of not overflowing the submission ring
buffer. In this sense, a 1 to 1 relationship between entity and
scheduler fits quite well.

FWIW this design was also ran by AMD quite a while ago (off the list)
and we didn't get any serious push back. Things can change however...

> > selection is dumb because there's only one entity ever bound to the
> > scheduler (the one that's part of the xe_guc_engine object which also
> > contains the drm_gpu_scheduler instance). I guess the main issue we'd
> > have on Arm is the fact that the stream doesn't necessarily get
> > scheduled when ->run_job() is called, it can be placed in the runnable
> > queue and be picked later by the kernel-side scheduler when a FW slot
> > gets released. That can probably be sorted out by manually disabling the
> > job timer and re-enabling it when the stream gets picked by the
> > scheduler. But my main concern remains, we're basically abusing
> > drm_sched here.
> > 

That's a matter of opinion, yes we are using it slightly differently
than anyone else but IMO the fact the DRM scheduler works for the Xe use
case with barely any changes is a testament to its design.

> > For the Arm driver, that means turning the following sequence
> > 
> > 1. wait for job deps
> > 2. queue job to ringbuf and push the stream to the runnable
> >queue (if it wasn't queued already). Wakeup the timeslice scheduler
> >to re-evaluate (if the stream is not on a FW slot already)
> > 3. stream gets picked by the timeslice scheduler and sent to the FW for
> >execution
> > 
> > into
> > 
> > 1. queue job to entity which takes care of waiting for job deps for
> >us
> > 2. schedule a drm_sched_main iteration
> > 3. the only available entity is picked, and the first job from this
> >entity is dequeued. ->run_job() is called: the job is queued to the
> >ringbuf and the stream is pushed to the runnable queue (if it wasn't
> >queued already). Wakeup the timeslice scheduler to re-evaluate (if
> >the stream is not on a FW slot already)
> > 4. stream gets picked by the timeslice scheduler and sent to the FW for
> >execution
> >

Yes, an extra step but you get to use all the nice DRM scheduler
functions for dependency tracking. Also in our case we really want a
single 

Re: [Intel-gfx] [PATCH] drm/i915: Expand force_probe to block probe of devices as well.

[Rodrigo Vivi]

On Wed, Jan 04, 2023 at 01:55:46PM -0500, Rodrigo Vivi wrote:
> There are new cases where we want to block i915 probe, such
> as when experimenting or developing the new Xe driver.
> 
> But also, with the new hybrid cards, users or developers might
> want to use i915 only on integrated and fully block the probe
> of the i915 for the discrete. Or vice versa.
> 
> There are even older development and validation reasons,
> like when you use some distro where the modprobe.blacklist is
> not present.
> 
> But in any case, let's introduce a more granular control, but without
> introducing yet another parameter, but using the existent force_probe
> one.
> 
> Just by adding a ! in the begin of the id in the force_probe, like
> in this case where we would block the probe for Alder Lake:
> 
> $ insmod i915.ko force_probe='!46a6'
> 
> v2: Take care of '*' and  '!*' cases as pointed out by
> Gustavo and Jani.
> v3: Information message improvements by Michal.
> Documentation improvements by Jani.

Please disregard this goofy v3. Pushed the v2 with the commit message fixes.

> 
> Cc: Jani Nikula 
> Cc: Gustavo Sousa 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Jani Nikula  #v2
> Acked-by: Gustavo Sousa 
> Cc: Michal Wajdeczko 
> ---
>  drivers/gpu/drm/i915/Kconfig   | 21 ---
>  drivers/gpu/drm/i915/i915_params.c |  2 +-
>  drivers/gpu/drm/i915/i915_pci.c| 33 +-
>  3 files changed, 47 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 3efce05d7b57..3dfc1f5ce4de 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -54,24 +54,39 @@ config DRM_I915
> If "M" is selected, the module will be called i915.
>  
>  config DRM_I915_FORCE_PROBE
> - string "Force probe driver for selected new Intel hardware"
> + string "Force probe i915 for selected Intel hardware IDs"
>   depends on DRM_I915
>   help
> This is the default value for the i915.force_probe module
> parameter. Using the module parameter overrides this option.
>  
> -   Force probe the driver for new Intel graphics devices that are
> +   Force probe the i915 for Intel graphics devices that are
> recognized but not properly supported by this kernel version. It is
> recommended to upgrade to a kernel version with proper support as soon
> as it is available.
>  
> +   It can also be used to block the probe of recognized and fully
> +   supported devices.
> +
> Use "" to disable force probe. If in doubt, use this.
>  
> -   Use "[,,...]" to force probe the driver for listed
> +   Use "[,,...]" to force probe the i915 for listed
> devices. For example, "4500" or "4500,4571".
>  
> Use "*" to force probe the driver for all known devices.
>  
> +   Use "!" right before the ID to block the probe of the device. For
> +   example, "4500,!4571" forces the probe of 4500 and blocks the probe of
> +   4571.
> +
> +   Use "!*" to block the probe of the driver for all known devices.
> +
> +   Please be aware that '*' cannot be combined with IDs. For example,
> +   "1234,!*" will result in the global block, even for "1234".
> +
> +   Also, the '!' case supersedes the regular case. For example,
> +   "1234,!1234" and "!1234,1234" both block 1234.
> +
>  config DRM_I915_CAPTURE_ERROR
>   bool "Enable capturing GPU state following a hang"
>   depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 61578f2860cd..d634bd3f641a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -122,7 +122,7 @@ i915_param_named_unsafe(enable_psr2_sel_fetch, bool, 0400,
>   "Default: 0");
>  
>  i915_param_named_unsafe(force_probe, charp, 0400,
> - "Force probe the driver for specified devices. "
> + "Force probe options for specified supported devices. "
>   "See CONFIG_DRM_I915_FORCE_PROBE for details.");
>  
>  i915_param_named_unsafe(disable_power_well, int, 0400,
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 7fd74cc28c0a..1bcbca38ce5c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1253,7 +1253,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
>  }
>  
>  /* is device_id present in comma separated list of ids */
> -static bool force_probe(u16 device_id, const char *devices)
> +static bool device_id_in_list(u16 device_id, const char *devices, bool 
> negative)
>  {
>   char *s, *p, *tok;
>   bool ret;
> @@ -1262,7 +1262,9 @@ static bool force_probe(u16 device_id, const char 
> *devices)
>   return false;
>  
>   /* match everything */
> - if (strcmp(devices, "*") == 0)
> + if (negative && strcmp(devices, "!*") == 0)
> + return true;
> + if 

Re: [Intel-gfx] [PATCH 26/27] KVM: x86/mmu: Add page-track API to query if a gfn is valid

[Sean Christopherson]

On Thu, Jan 05, 2023, Yan Zhao wrote:
> On Tue, Jan 03, 2023 at 09:19:01PM +, Sean Christopherson wrote:
> > On Wed, Dec 28, 2022, Yan Zhao wrote:
> > > On Fri, Dec 23, 2022 at 12:57:38AM +, Sean Christopherson wrote:
> > > > +bool kvm_page_track_is_valid_gfn(struct kvm *kvm, gfn_t gfn)
> > > > +{
> > > > +   bool ret;
> > > > +   int idx;
> > > > +
> > > > +   idx = srcu_read_lock(>srcu);
> > > > +   ret = kvm_is_visible_gfn(kvm, gfn);
> > > > +   srcu_read_unlock(>srcu, idx);
> > > > +
> > > > +   return ret;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(kvm_page_track_is_valid_gfn);
> > > This implementation is only to check whether a GFN is within a visible
> > > kvm memslot. So, why this helper function is named kvm_page_track_xxx()?
> > > Don't think it's anything related to page track, and not all of its 
> > > callers
> > > in KVMGT are for page tracking.
> > 
> > KVMGT is the only user of kvm_page_track_is_valid_gfn().  
> > kvm_is_visible_gfn()
> > has other users, just not in x86.  And long term, my goal is to allow 
> > building
> > KVM x86 without any exports.  Killing off KVM's "internal" (for vendor 
> > modules)
> > exports for select Kconfigs is easy enough, add adding a dedicated 
> > page-track API
> > solves the KVMGT angle.
> Understand!
> But personally, I don't like merging this API into page-track API as
> it obviously has nothing to do with page-track stuffs, and KVMGT also calls 
> it for
> non-page-track purpuse.

100% agreed, but as discussed in the other patch[*], IMO the real issue is that
KVMGT is abusing KVM APIs to check the validity of GFNs that are ultimately 
mapped
via VFIO.  Once that issue is fixed, kvm_page_track_is_valid_gfn() can go away
entirely.  I view this as a short/medium term hack-a-fix to limit and 
encapsulate
KVM's API surface that is "needed" by KVMGT.

[*] https://lore.kernel.org/all/y7clklumcy+xl...@google.com

Re: [Intel-gfx] [PATCH] drm/i915: Update doc for __intel_wakeref_put()

[Andi Shyti]

Hi,

On Thu, Jan 05, 2023 at 08:29:26AM -0800, Dixit, Ashutosh wrote:
> On Thu, 05 Jan 2023 07:38:31 -0800, Nirmoy Das wrote:
> >
> 
> Hi Nirmoy,
> 
> > Fix the __intel_wakeref_put() doc to reflect current behaviour.
> >
> > Fixes: c7302f204490 ("drm/i915: Defer final intel_wakeref_put to process 
> > context")
> 
> Seems to be d91e657876a9?

or maybe this: ee33baa831096

> > Signed-off-by: Nirmoy Das 
> > ---
> >  drivers/gpu/drm/i915/intel_wakeref.h | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
> > b/drivers/gpu/drm/i915/intel_wakeref.h
> > index 4f4c2e15e736..b5e1c61b5003 100644
> > --- a/drivers/gpu/drm/i915/intel_wakeref.h
> > +++ b/drivers/gpu/drm/i915/intel_wakeref.h
> > @@ -135,14 +135,12 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
> >   * @flags: control flags
> >   *
> >   * Release our hold on the wakeref. When there are no more users,
> > - * the runtime pm wakeref will be released after the @fn callback is called
> > - * underneath the wakeref mutex.
> > + * the runtime pm wakeref will be released after the 
> > intel_wakeref_ops->put()
> > + * callback is called underneath the wakeref mutex.
> >   *
> > - * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> > - * is retained and an error reported.
> > + * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
> > + * runtime-pm wakeref is retained.
> 
> @fn is used in multiple places in this file (including some 'get' usages)
> so maybe needs to be fixed there too. Maybe better to just say somewhere
> @fn refers to ops->get()/put() where applicable?

yeah... as Nirmoy is at it, I think he can take care of the rest,
would you, Nirmoy?

> >   *
> > - * Returns: 0 if the wakeref was released successfully, or a negative error
> > - * code otherwise.
> 
> So this seems to be the reason for the patch...

yeah and as for this patch, with the correct "Fixes:" above:

Reviewed-by: Andi Shyti 

Andi

> >   */
> >  static inline void
> >  __intel_wakeref_put(struct intel_wakeref *wf, unsigned long flags)
> > --
> > 2.38.0
> >
> 
> Thanks.
> --
> Ashutosh

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/fbdev: Implement fb_dirty for intel custom fb helper (rev3)
URL   : https://patchwork.freedesktop.org/series/111433/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12548 -> Patchwork_111433v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 41)
--

  Additional (2): bat-dg2-11 fi-rkl-11600 
  Missing(4): fi-kbl-soraka fi-bsw-kefka bat-atsm-1 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

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

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

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

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

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

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

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

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

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][10] ([i915#1072]) +3 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][11] ([i915#3555] / [i915#4098])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-read:
- fi-rkl-11600:   NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3291] / 
[i915#3708]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-11600/igt@prime_v...@basic-read.html

  * igt@prime_vgem@basic-userptr:
- fi-rkl-11600:   NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301] / 
[i915#3708])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

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

  * igt@i915_selftest@live@migrate:
- {bat-adlp-9}:   [DMESG-FAIL][16] ([i915#7699]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/bat-adlp-9/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@mman:
- fi-rkl-guc: [TIMEOUT][18] ([i915#6794]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/fi-rkl-guc/igt@i915_selftest@l...@mman.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111433v3/fi-rkl-guc/igt@i915_selftest@l...@mman.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][20] ([i915#4983]) -> [PASS][21]
   [20]: 

Re: [Intel-gfx] [PATCH 03/27] drm/i915/gvt: Incorporate KVM memslot info into check for 2MiB GTT entry

[Sean Christopherson]

On Thu, Jan 05, 2023, Yan Zhao wrote:
> On Tue, Jan 03, 2023 at 09:13:54PM +, Sean Christopherson wrote:
> > On Wed, Dec 28, 2022, Yan Zhao wrote:
> > > On Fri, Dec 23, 2022 at 12:57:15AM +, Sean Christopherson wrote:
> > > > Honor KVM's max allowed page size when determining whether or not a 2MiB
> > > > GTT shadow page can be created for the guest.  Querying KVM's max 
> > > > allowed
> > > > size is somewhat odd as there's no strict requirement that KVM's 
> > > > memslots
> > > > and VFIO's mappings are configured with the same gfn=>hva mapping, but
> > > Without vIOMMU, VFIO's mapping is configured with the same as KVM's
> > > memslots, i.e. with the same gfn==>HVA mapping
> > 
> > But that's controlled by userspace, correct?
> 
> Yes, controlled by QEMU.

...

> > Strictly speaking, no.  E.g. if a 2MiB region is covered with multiple 
> > memslots
> > and the memslots have different properties.
> > 
> > > If for some reason, KVM maps a 2MiB range in 4K sizes, KVMGT can still map
> > > it in IOMMU size in 2MiB size as long as the PFNs are continous and the
> > > whole range is all exposed to guest.
> > 
> > I agree that practically speaking this will hold true, but if KVMGT wants 
> > to honor
> > KVM's memslots then checking that KVM allows a hugepage is correct.  Hrm, 
> > but on
> > the flip side, KVMGT ignores read-only memslot flags, so KVMGT is already 
> > ignoring
> > pieces of KVM's memslots.
> KVMGT calls dma_map_page() with DMA_BIDIRECTIONAL after checking 
> gvt_pin_guest_page().
> Though for a read-only memslot, DMA_TO_DEVICE should be used instead
> (see dma_info_to_prot()),
> as gvt_pin_guest_page() checks (IOMMU_READ | IOMMU_WRITE) permission for each 
> page,
> it actually ensures that the pinned GFN is not in a read-only memslot.
> So, it should be fine.
> 
> > 
> > I have no objection to KVMGT defining its ABI such that KVMGT is allowed to 
> > create
> > 2MiB so long as (a) the GFN is contiguous according to VFIO, and (b) that 
> > the entire
> > 2MiB range is exposed to the guest.
> > 
> sorry. I may not put it clearly enough.
> for a normal device pass-through via VFIO-PCI, VFIO maps IOMMU mappings in 
> this way:
> 
> (a) fault in PFNs in a GFN range within the same memslot (VFIO saves 
> dma_list, which is
> the same as memslot list when vIOMMU is not on or not in shadow mode).
> (b) map continuous PFNs into iommu driver (honour ro attribute and can > 2MiB 
> as long as
> PFNs are continuous).
> (c) IOMMU driver decides to map in 2MiB or in 4KiB according to its setting.
> 
> For KVMGT, gvt_dma_map_page() first calls gvt_pin_guest_page() which
> (a) calls vfio_pin_pages() to check each GFN is within allowed dma_list with
> (IOMMU_READ | IOMMU_WRITE) permission and fault-in page. 
> (b) checks PFNs are continuous in 2MiB,
> 
> Though checking kvm_page_track_max_mapping_level() is also fine, it makes DMA
> mapping size unnecessarily smaller.

Yeah, I got all that.  What I'm trying to say, and why I asked about whether or
not userspace controls the mappings, is that AFAIK there is nothing in the 
kernel
that coordinates mappings between VFIO and KVM.  So, very technically, userspace
could map a 2MiB range contiguous in VFIO but not in KVM, or RW in VFIO but RO 
in KVM.

I can't imagine there's a real use case for doing so, and arguably there's no
requirement that KVMGT honor KVM's memslot.  But because KVMGT taps into KVM's
page-tracking, KVMGT _does_ honor KVM's memslots to some extent because KVMGT
needs to know whether or not a given GFN can be write-protected.

I'm totally fine if KVMGT's ABI is that VFIO is the source of truth for mappings
and permissions, and that the only requirement for KVM memslots is that GTT page
tables need to be visible in KVM's memslots.  But if that's the ABI, then
intel_gvt_is_valid_gfn() should be probing VFIO, not KVM (commit cc753fbe1ac4
("drm/i915/gvt: validate gfn before set shadow page entry").

In other words, pick either VFIO or KVM.  Checking that X is valid according to
KVM and then mapping X through VFIO is confusing and makes assumptions about how
userspace configures KVM and VFIO.  It works because QEMU always configures KVM
and VFIO as expected, but IMO it's unnecessarily fragile and again confusing for
unaware readers because the code is technically flawed.

On a related topic, ppgtt_populate_shadow_entry() should check the validity of 
the
gfn.  If I'm reading the code correctly, checking only in ppgtt_populate_spt() 
fails
to handle the case where the guest creates a bogus mapping when writing an 
existing
GTT PT.

Combing all my trains of thought, what about this as an end state for this 
series?
(completely untested at this point).  Get rid of the KVM mapping size checks,
verify the validity of the entire range being mapped, and add a FIXME to 
complain
about using KVM instead of VFIO to determine the validity of ranges.

static bool intel_gvt_is_valid_gfn(struct intel_vgpu *vgpu, unsigned long gfn,
  

[Intel-gfx] ✗ Fi.CI.BAT: failure for Defeature Interlace modes for Display >= 12 (rev3)

[Patchwork]

== Series Details ==

Series: Defeature Interlace modes for Display >= 12 (rev3)
URL   : https://patchwork.freedesktop.org/series/109773/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12548 -> Patchwork_109773v3


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 42)
--

  Additional (2): bat-dg2-11 fi-rkl-11600 
  Missing(3): bat-atsm-1 fi-snb-2520m fi-pnv-d510 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

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

  * igt@i915_selftest@live@hangcheck:
- {bat-dg2-8}:[PASS][2] -> [DMESG-FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_suspend@basic-s3-without-i915:
- {bat-adlm-1}:   [PASS][4] -> [DMESG-WARN][5] +1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/bat-adlm-1/igt@i915_susp...@basic-s3-without-i915.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-rkl-11600:   NOTRUN -> [SKIP][6] ([i915#7456])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-rkl-11600:   NOTRUN -> [SKIP][7] ([i915#2190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html

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

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

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

  * igt@i915_pm_rpm@basic-rte:
- bat-adlp-4: [PASS][11] -> [DMESG-WARN][12] ([i915#7077])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/bat-adlp-4/igt@i915_pm_...@basic-rte.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/bat-adlp-4/igt@i915_pm_...@basic-rte.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   NOTRUN -> [FAIL][13] ([fdo#103375])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html

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

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

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

  * igt@kms_psr@primary_page_flip:
- fi-rkl-11600:   NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109773v3/fi-rkl-11600/igt@kms_psr@primary_page_flip.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600:   NOTRUN -> [SKIP][18] 

Re: [Intel-gfx] [PATCH 00/19] Introduce __xchg, non-atomic xchg

[Daniel Vetter]

On Thu, Dec 29, 2022 at 10:54:50AM +0100, Andrzej Hajda wrote:
> Forgive me late response - Holidays,
> 
> On 22.12.2022 18:21, Andrew Morton wrote:
> > On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda  
> > wrote:
> > 
> > > Hi all,
> > > 
> > > I hope there will be place for such tiny helper in kernel.
> > > Quick cocci analyze shows there is probably few thousands places
> > > where it could be useful.
> > So to clarify, the intent here is a simple readability cleanup for
> > existing open-coded exchange operations.
> 
> And replace private helpers with common one, see the last patch - the
> ultimate goal
> would be to replace all occurrences of fetch_and_zero with __xchg.
> 
> > The intent is *not* to
> > identify existing xchg() sites which are unnecessarily atomic and to
> > optimize them by using the non-atomic version.
> > 
> > Have you considered the latter?
> 
> If you mean some way of (semi-)automatic detection of such cases, then no.
> Anyway this could be quite interesting challenge.

My take is that unless there is very clear demand for this macro from
outside of i915, it's not worth it. All that fetch_and_zero zero achieved
is make i915 code a lot more confusing to read for people who don't know
this thing. And it replaces 2 entirely standard lines of 0, every often
clearing pointers in data structures where you really want the verbosity
to have a reminder and thinking about the locking.

Plus it smells way too much like the cmpxchg family of atomic functions,
addig further to the locking confuion.

Imo the right approach is to just open code this macro in i915 and then
drop it. Again, unless enough people outside of i915 really really want
this, and want to lift this to a kernel idiom.
-Daniel

> 
> > 
> > > I am not sure who is good person to review/ack such patches,
> > I can take 'em.
> > 
> > > so I've used my intuition to construct to/cc lists, sorry for mistakes.
> > > This is the 2nd approach of the same idea, with comments addressed[0].
> > > 
> > > The helper is tiny and there are advices we can leave without it, so
> > > I want to present few arguments why it would be good to have it:
> > > 
> > > 1. Code readability/simplification/number of lines:
> > > 
> > > Real example from drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c:
> > > -   previous_min_rate = evport->qos.min_rate;
> > > -   evport->qos.min_rate = min_rate;
> > > +   previous_min_rate = __xchg(evport->qos.min_rate, min_rate);
> > > 
> > > For sure the code is more compact, and IMHO more readable.
> > > 
> > > 2. Presence of similar helpers in other somehow related languages/libs:
> > > 
> > > a) Rust[1]: 'replace' from std::mem module, there is also 'take'
> > >  helper (__xchg(, 0)), which is the same as private helper in
> > >  i915 - fetch_and_zero, see latest patch.
> > > b) C++ [2]: 'exchange' from utility header.
> > > 
> > > If the idea is OK there are still 2 qestions to answer:
> > > 
> > > 1. Name of the helper, __xchg follows kernel conventions,
> > >  but for me Rust names are also OK.
> > I like replace(), or, shockingly, exchange().
> > 
> > But...   Can we simply make swap() return the previous value?
> > 
> > previous_min_rate = swap(>qos.min_rate, min_rate);
> 
> As Alexander already pointed out, swap requires 'references' to two
> variables,
> in contrast to xchg which requires reference to variable and value.
> So we cannot use swap for cases:
>     old_value = __xchg(, new_value);
> 
> Regards
> Andrzej
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH] drm/i915: Update doc for __intel_wakeref_put()

[Dixit, Ashutosh]

On Thu, 05 Jan 2023 07:38:31 -0800, Nirmoy Das wrote:
>

Hi Nirmoy,

> Fix the __intel_wakeref_put() doc to reflect current behaviour.
>
> Fixes: c7302f204490 ("drm/i915: Defer final intel_wakeref_put to process 
> context")

Seems to be d91e657876a9?

> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/i915/intel_wakeref.h | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
> b/drivers/gpu/drm/i915/intel_wakeref.h
> index 4f4c2e15e736..b5e1c61b5003 100644
> --- a/drivers/gpu/drm/i915/intel_wakeref.h
> +++ b/drivers/gpu/drm/i915/intel_wakeref.h
> @@ -135,14 +135,12 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
>   * @flags: control flags
>   *
>   * Release our hold on the wakeref. When there are no more users,
> - * the runtime pm wakeref will be released after the @fn callback is called
> - * underneath the wakeref mutex.
> + * the runtime pm wakeref will be released after the intel_wakeref_ops->put()
> + * callback is called underneath the wakeref mutex.
>   *
> - * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
> - * is retained and an error reported.
> + * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
> + * runtime-pm wakeref is retained.

@fn is used in multiple places in this file (including some 'get' usages)
so maybe needs to be fixed there too. Maybe better to just say somewhere
@fn refers to ops->get()/put() where applicable?

>   *
> - * Returns: 0 if the wakeref was released successfully, or a negative error
> - * code otherwise.

So this seems to be the reason for the patch...

>   */
>  static inline void
>  __intel_wakeref_put(struct intel_wakeref *wf, unsigned long flags)
> --
> 2.38.0
>

Thanks.
--
Ashutosh

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Implement Wa_14015648006

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Implement Wa_14015648006
URL   : https://patchwork.freedesktop.org/series/112430/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12548 -> Patchwork_112430v1


Summary
---

  **FAILURE**

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

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

Participating hosts (43 -> 43)
--

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@slpc:
- fi-kbl-soraka:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/fi-kbl-soraka/igt@i915_selftest@l...@slpc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112430v1/fi-kbl-soraka/igt@i915_selftest@l...@slpc.html

  
 Suppressed 

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

  * igt@i915_selftest@live@gt_heartbeat:
- {bat-kbl-2}:[PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/bat-kbl-2/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112430v1/bat-kbl-2/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@eof:
- fi-kbl-soraka:  [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/fi-kbl-soraka/igt@fb...@eof.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112430v1/fi-kbl-soraka/igt@fb...@eof.html

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050:   [PASS][7] -> [FAIL][8] ([i915#6298])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112430v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  
 Possible fixes 

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

  * igt@i915_selftest@live@mman:
- fi-rkl-guc: [TIMEOUT][11] ([i915#6794]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12548/fi-rkl-guc/igt@i915_selftest@l...@mman.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112430v1/fi-rkl-guc/igt@i915_selftest@l...@mman.html

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

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
  [i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: 

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Tvrtko Ursulin]

On 05/01/2023 15:52, Andi Shyti wrote:

Hi Rob,

On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:

From: Rob Clark 

gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this.  And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.

Signed-off-by: Rob Clark 


Reviewed-by: Andi Shyti 

I also agree with Tvrtko that we should add Stable: and Fixes:.


Yeah I'll add them all when merging. Just waiting for full CI results. It will 
be like this:

Fixes: eb4dedae920a ("drm/i915/gem: Delay tracking the GEM context until it is 
registered")
Fixes: a4c1cdd34e2c ("drm/i915/gem: Delay context creation (v3)")
Fixes: 49bd54b390c2 ("drm/i915: Track all user contexts per client")
Cc:  # v5.10+

Regards,

Tvrtko
 

One little thing, "user after free" is clearer that UAF :)

Thanks,
Andi


---
  drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++--
  1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..6250de9b9196 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private 
*i915)
init_contexts(>gem.contexts);
  }
  
+/*

+ * Note that this implicitly consumes the ctx reference, by placing
+ * the ctx in the context_xa.
+ */
  static void gem_context_register(struct i915_gem_context *ctx,
 struct drm_i915_file_private *fpriv,
 u32 id)
@@ -1703,10 +1707,6 @@ static void gem_context_register(struct i915_gem_context 
*ctx,
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
 current->comm, pid_nr(ctx->pid));
  
-	/* And finally expose ourselves to userspace via the idr */

-   old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
-   WARN_ON(old);
-
spin_lock(>client->ctx_lock);
list_add_tail_rcu(>client_link, >client->ctx_list);
spin_unlock(>client->ctx_lock);
@@ -1714,6 +1714,10 @@ static void gem_context_register(struct i915_gem_context 
*ctx,
spin_lock(>gem.contexts.lock);
list_add_tail(>link, >gem.contexts.list);
spin_unlock(>gem.contexts.lock);
+
+   /* And finally expose ourselves to userspace via the idr */
+   old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
+   WARN_ON(old);
  }
  
  int i915_gem_context_open(struct drm_i915_private *i915,

@@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct 
drm_i915_file_private *file_priv,
if (IS_ERR(ctx))
return ctx;
  
+	/*

+* One for the xarray and one for the caller.  We need to grab
+* the reference *prior* to making the ctx visble to userspace
+* in gem_context_register(), as at any point after that
+* userspace can try to race us with another thread destroying
+* the context under our feet.
+*/
+   i915_gem_context_get(ctx);
+
gem_context_register(ctx, file_priv, id);
  
  	old = xa_erase(_priv->proto_context_xa, id);

GEM_BUG_ON(old != pc);
proto_context_close(file_priv->dev_priv, pc);
  
-	/* One for the xarray and one for the caller */

-   return i915_gem_context_get(ctx);
+   return ctx;
  }
  
  struct i915_gem_context *

--
2.38.1

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential context UAFs

[Andi Shyti]

Hi Rob,

On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
> From: Rob Clark 
> 
> gem_context_register() makes the context visible to userspace, and which
> point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
> So we need to ensure that nothing uses the ctx ptr after this.  And we
> need to ensure that adding the ctx to the xarray is the *last* thing
> that gem_context_register() does with the ctx pointer.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Andi Shyti 

I also agree with Tvrtko that we should add Stable: and Fixes:.

One little thing, "user after free" is clearer that UAF :)

Thanks,
Andi

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7f2831efc798..6250de9b9196 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1688,6 +1688,10 @@ void i915_gem_init__contexts(struct drm_i915_private 
> *i915)
>   init_contexts(>gem.contexts);
>  }
>  
> +/*
> + * Note that this implicitly consumes the ctx reference, by placing
> + * the ctx in the context_xa.
> + */
>  static void gem_context_register(struct i915_gem_context *ctx,
>struct drm_i915_file_private *fpriv,
>u32 id)
> @@ -1703,10 +1707,6 @@ static void gem_context_register(struct 
> i915_gem_context *ctx,
>   snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
>current->comm, pid_nr(ctx->pid));
>  
> - /* And finally expose ourselves to userspace via the idr */
> - old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
> - WARN_ON(old);
> -
>   spin_lock(>client->ctx_lock);
>   list_add_tail_rcu(>client_link, >client->ctx_list);
>   spin_unlock(>client->ctx_lock);
> @@ -1714,6 +1714,10 @@ static void gem_context_register(struct 
> i915_gem_context *ctx,
>   spin_lock(>gem.contexts.lock);
>   list_add_tail(>link, >gem.contexts.list);
>   spin_unlock(>gem.contexts.lock);
> +
> + /* And finally expose ourselves to userspace via the idr */
> + old = xa_store(>context_xa, id, ctx, GFP_KERNEL);
> + WARN_ON(old);
>  }
>  
>  int i915_gem_context_open(struct drm_i915_private *i915,
> @@ -2199,14 +2203,22 @@ finalize_create_context_locked(struct 
> drm_i915_file_private *file_priv,
>   if (IS_ERR(ctx))
>   return ctx;
>  
> + /*
> +  * One for the xarray and one for the caller.  We need to grab
> +  * the reference *prior* to making the ctx visble to userspace
> +  * in gem_context_register(), as at any point after that
> +  * userspace can try to race us with another thread destroying
> +  * the context under our feet.
> +  */
> + i915_gem_context_get(ctx);
> +
>   gem_context_register(ctx, file_priv, id);
>  
>   old = xa_erase(_priv->proto_context_xa, id);
>   GEM_BUG_ON(old != pc);
>   proto_context_close(file_priv->dev_priv, pc);
>  
> - /* One for the xarray and one for the caller */
> - return i915_gem_context_get(ctx);
> + return ctx;
>  }
>  
>  struct i915_gem_context *
> -- 
> 2.38.1

[Intel-gfx] [PATCH] drm/i915: Update doc for __intel_wakeref_put()

[Nirmoy Das]

Fix the __intel_wakeref_put() doc to reflect current behaviour.

Fixes: c7302f204490 ("drm/i915: Defer final intel_wakeref_put to process 
context")
Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/intel_wakeref.h | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
b/drivers/gpu/drm/i915/intel_wakeref.h
index 4f4c2e15e736..b5e1c61b5003 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -135,14 +135,12 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
  * @flags: control flags
  *
  * Release our hold on the wakeref. When there are no more users,
- * the runtime pm wakeref will be released after the @fn callback is called
- * underneath the wakeref mutex.
+ * the runtime pm wakeref will be released after the intel_wakeref_ops->put()
+ * callback is called underneath the wakeref mutex.
  *
- * Note that @fn is allowed to fail, in which case the runtime-pm wakeref
- * is retained and an error reported.
+ * Note that intel_wakeref_ops->put() is allowed to fail, in which case the
+ * runtime-pm wakeref is retained.
  *
- * Returns: 0 if the wakeref was released successfully, or a negative error
- * code otherwise.
  */
 static inline void
 __intel_wakeref_put(struct intel_wakeref *wf, unsigned long flags)
-- 
2.38.0

Re: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Add mode DSB opcodes

[Manna, Animesh]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Add mode DSB opcodes
> 
> From: Ville Syrjälä 
> 
> Add all the know DSB instruction opcodes.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dsb.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 7c593ec84d41..96bc117fd6a0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -67,8 +67,16 @@ struct intel_dsb {
> 
>  /* DSB opcodes. */
>  #define DSB_OPCODE_SHIFT 24
> +#define DSB_OPCODE_NOOP  0x0
>  #define DSB_OPCODE_MMIO_WRITE0x1
> +#define DSB_OPCODE_WAIT_USEC 0x2
> +#define DSB_OPCODE_WAIT_LINES0x3
> +#define DSB_OPCODE_WAIT_VBLANKS  0x4
> +#define DSB_OPCODE_WAIT_DSL_IN   0x5
> +#define DSB_OPCODE_WAIT_DSL_OUT  0x6
> +#define DSB_OPCODE_INTERRUPT 0x7
>  #define DSB_OPCODE_INDEXED_WRITE 0x9
> +#define DSB_OPCODE_POLL  0xA
>  #define DSB_BYTE_EN  0xF
>  #define DSB_BYTE_EN_SHIFT20
>  #define DSB_REG_VALUE_MASK   0xf

Not sure if we can check-in the above macros without its usage.

Regards,
Animesh

> --
> 2.37.4

Re: [Intel-gfx] [PATCH 10/13] drm/i915/dsb: Allow the caller to pass in the DSB buffer size

[Manna, Animesh]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/13] drm/i915/dsb: Allow the caller to pass in
> the DSB buffer size
> 
> From: Ville Syrjälä 
> 
> The caller should more or less know how many DSB commands it wants to
> emit into the command buffer, so allow it to specify the size of the command
> buffer rather than having the low level DSB code guess it.
> 
> Technically we can emit as many as 134+1033 (for adl+ degamma + 10bit
> gamma) register writes but thanks to the DSB indexed register write
> command we get significant space savings so the current size estimate of
> 8KiB (~1024 DSB commands) is sufficient for now.
> 
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c |  2 +-
>  drivers/gpu/drm/i915/display/intel_dsb.c   | 42 +-
>  drivers/gpu/drm/i915/display/intel_dsb.h   |  3 +-
>  3 files changed, 29 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 76603357252d..8d97c299e657 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1380,7 +1380,7 @@ void intel_color_prepare_commit(struct
> intel_crtc_state *crtc_state)
>   /* FIXME DSB has issues loading LUTs, disable it for now */
>   return;
> 
> - crtc_state->dsb = intel_dsb_prepare(crtc);
> + crtc_state->dsb = intel_dsb_prepare(crtc, 1024);
>  }
> 
>  void intel_color_cleanup_commit(struct intel_crtc_state *crtc_state) diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 636c57767f97..7c593ec84d41 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -30,21 +30,24 @@ struct intel_dsb {
>   struct intel_crtc *crtc;
> 
>   /*
> -  * free_pos will point the first free entry position
> -  * and help in calculating tail of command buffer.
> +  * maximum number of dwords the buffer will hold.
>*/
> - int free_pos;
> + unsigned int size;
> 
>   /*
> -  * ins_start_offset will help to store start address of the dsb
> +  * free_pos will point the first free dword and
> +  * help in calculating tail of command buffer.
> +  */
> + unsigned int free_pos;
> +
> + /*
> +  * ins_start_offset will help to store start dword of the dsb
>* instuction and help in identifying the batch of auto-increment
>* register.
>*/
> - u32 ins_start_offset;
> + unsigned int ins_start_offset;
>  };
> 
> -#define DSB_BUF_SIZE(2 * PAGE_SIZE)
> -
>  /**
>   * DOC: DSB
>   *
> @@ -76,7 +79,7 @@ static bool assert_dsb_has_room(struct intel_dsb *dsb)
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> 
>   /* each instruction is 2 dwords */
> - return !drm_WARN(>drm, ALIGN(dsb->free_pos, 2) >
> DSB_BUF_SIZE / 4 - 2,
> + return !drm_WARN(>drm, dsb->free_pos > dsb->size - 2,
>"DSB buffer overflow\n");
>  }
> 
> @@ -168,7 +171,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
>   if (intel_dsb_prev_ins_is_mmio_write(dsb, reg)) {
>   u32 prev_val = buf[dsb->ins_start_offset + 0];
> 
> - buf[dsb->ins_start_offset + 0] = 1; /* size */
> + buf[dsb->ins_start_offset + 0] = 1; /* count */
>   buf[dsb->ins_start_offset + 1] =
>   (DSB_OPCODE_INDEXED_WRITE <<
> DSB_OPCODE_SHIFT) |
>   i915_mmio_reg_offset(reg);
> @@ -178,7 +181,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
>   }
> 
>   buf[dsb->free_pos++] = val;
> - /* Update the size. */
> + /* Update the count */
>   buf[dsb->ins_start_offset]++;
> 
>   /* if number of data words is odd, then the last dword
> should be 0.*/ @@ -250,6 +253,7 @@ void intel_dsb_commit(struct
> intel_dsb *dsb)
>  /**
>   * intel_dsb_prepare() - Allocate, pin and map the DSB command buffer.
>   * @crtc: the CRTC
> + * @max_cmds: number of commands we need to fit into command buffer
>   *
>   * This function prepare the command buffer which is used to store dsb
>   * instructions with data.
> @@ -257,25 +261,30 @@ void intel_dsb_commit(struct intel_dsb *dsb)
>   * Returns:
>   * DSB context, NULL on failure
>   */
> -struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc)
> +struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc,
> + unsigned int max_cmds)
>  {
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> - struct intel_dsb *dsb;
>   struct drm_i915_gem_object *obj;
> - struct i915_vma *vma;
> - 

Re: [Intel-gfx] [PATCH 08/13] drm/i915/dsb: Handle the indexed vs. not inside the DSB code

[Manna, Animesh]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/13] drm/i915/dsb: Handle the indexed vs. not
> inside the DSB code
> 
> From: Ville Syrjälä 
> 
> The DSB indexed register write insturction is purely an internal DSB
> implementation detail, no reason why the caller should have to know about
> it. So let's just have the caller emit blind register writes let the DSB code
> convert things to an indexed write if/when multiple writes occur to the same
> register offset in a row.
> 
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 45 --
>  drivers/gpu/drm/i915/display/intel_dsb.c   | 96 +-
>  drivers/gpu/drm/i915/display/intel_dsb.h   |  2 -
>  3 files changed, 54 insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index d57631b0bb9a..76603357252d 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -847,17 +847,6 @@ static void ilk_lut_write(const struct intel_crtc_state
> *crtc_state,
>   intel_de_write_fw(i915, reg, val);
>  }
> 
> -static void ilk_lut_write_indexed(const struct intel_crtc_state *crtc_state,
> -   i915_reg_t reg, u32 val)
> -{
> - struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> -
> - if (crtc_state->dsb)
> - intel_dsb_indexed_reg_write(crtc_state->dsb, reg, val);
> - else
> - intel_de_write_fw(i915, reg, val);
> -}
> -
>  static void ilk_load_lut_8(const struct intel_crtc_state *crtc_state,
>  const struct drm_property_blob *blob)  { @@ -
> 962,8 +951,8 @@ static void bdw_load_lut_10(const struct intel_crtc_state
> *crtc_state,
> prec_index);
> 
>   for (i = 0; i < lut_size; i++)
> - ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
> -   ilk_lut_10([i]));
> + ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
> +   ilk_lut_10([i]));
> 
>   /*
>* Reset the index, otherwise it prevents the legacy palette to be @@
> -1093,13 +1082,13 @@ static void glk_load_degamma_lut(const struct
> intel_crtc_state *crtc_state,
>* ToDo: Extend to max 7.0. Enable 32 bit input value
>* as compared to just 16 to achieve this.
>*/
> - ilk_lut_write_indexed(crtc_state,
> PRE_CSC_GAMC_DATA(pipe),
> -   lut[i].green);
> + ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
> +   lut[i].green);
>   }
> 
>   /* Clamp values > 1.0. */
>   while (i++ < glk_degamma_lut_size(i915))
> - ilk_lut_write_indexed(crtc_state,
> PRE_CSC_GAMC_DATA(pipe), 1 << 16);
> + ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), 1 <<
> 16);
> 
>   ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0);  } @@ -
> 1165,10 +1154,10 @@ icl_program_gamma_superfine_segment(const struct
> intel_crtc_state *crtc_state)
>   for (i = 0; i < 9; i++) {
>   const struct drm_color_lut *entry = [i];
> 
> - ilk_lut_write_indexed(crtc_state,
> PREC_PAL_MULTI_SEG_DATA(pipe),
> -   ilk_lut_12p4_ldw(entry));
> - ilk_lut_write_indexed(crtc_state,
> PREC_PAL_MULTI_SEG_DATA(pipe),
> -   ilk_lut_12p4_udw(entry));
> + ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
> +   ilk_lut_12p4_ldw(entry));
> + ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_DATA(pipe),
> +   ilk_lut_12p4_udw(entry));
>   }
> 
>   ilk_lut_write(crtc_state, PREC_PAL_MULTI_SEG_INDEX(pipe), @@ -
> 1204,10 +1193,10 @@ icl_program_gamma_multi_segment(const struct
> intel_crtc_state *crtc_state)
>   for (i = 1; i < 257; i++) {
>   entry = [i * 8];
> 
> - ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
> -   ilk_lut_12p4_ldw(entry));
> - ilk_lut_write_indexed(crtc_state, PREC_PAL_DATA(pipe),
> -   ilk_lut_12p4_udw(entry));
> + ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
> +   ilk_lut_12p4_ldw(entry));
> + ilk_lut_write(crtc_state, PREC_PAL_DATA(pipe),
> +   ilk_lut_12p4_udw(entry));
>   }
> 
>   /*
> @@ -1225,10 +1214,10 @@ icl_program_gamma_multi_segment(const
> struct intel_crtc_state *crtc_state)
>   for (i = 0; i < 256; i++) {
>   entry = [i * 8 * 128];
> 
> - ilk_lut_write_indexed(crtc_state, 

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[Daniel Vetter]

On Thu, Jan 05, 2023 at 02:41:43PM +, David Laight wrote:
> From: Daniel Vetter
> > Sent: 05 January 2023 14:13
> ...
> > > > So here we are, with Andrzej looking to add the common helper. And the
> > > > same concerns crop up. What should it be called to make it clear that
> > > > it's not atomic? Is that possible?
> > >
> > > old_value = read_write(variable, new_value);
> > >
> > > But two statements are much clearer.
> > 
> > Yeah this is my point for fetch_and_zero or any of the other proposals.
> > We're essentially replacing these two lines:
> > 
> > var = some->pointer->chase;
> > some->pointer->chase = NULL;
> > 
> > with a macro. C is verbose, and sometimes painfully so,
> 
> Try ADA or VHDL :-)
> 
> > if the pointer
> > chase is really to onerous then I think that should be refactored with a
> > meaningfully locally name variable, not fancy macros wrapped around to
> > golf a few characters away.
> 
> Provided 'var' is a local the compiler is pretty likely to only do the
> 'pointer chase' once.
> You can also do:
>   var = NULL;
>   swap(some->pointer->chase, var);
> and get pretty much the same object code.
> 
> > But what about swap() you ask? That one needs a temp variable, and it does
> > make sense to hide that in a ({}) block in a macro.
> 
> Sometimes, but not enough for the 'missed opportunity for swap()'
> message. 
> 
> > But for the above two
> > lines I really don't see a point outside of obfuscated C contexts.
> 
> Indeed.
> 
> Isn't the suggested __xchg() in one of the 'reserved for implementation'
> namespaces - so shouldn't be a function that might be expected to be
> actually used.

It's more fun, for the atomic functions which don't have the atomic_
prefix in their names, the __ prefixed versions provide the non-atomic
implementation.  This pattern was started with the long * bitops stuff for
managing really big bitmasks.

And I really don't think it's a great function name scheme that we should
proliferate.

The "reserved for implementation" only applies to the standard C library
in userspace, which the kernel doesn't use, so can fairly freely use that
namespace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 09/13] drm/i915/dsb: Introduce intel_dsb_align_tail()

[Manna, Animesh]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville
> Syrjala
> Sent: Friday, December 16, 2022 6:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/13] drm/i915/dsb: Introduce
> intel_dsb_align_tail()
> 
> From: Ville Syrjälä 
> 
> Move the DSB tail cacheline alignment to a helper. No need to pollute the
> caller with mundane details like this.
> 
> Signed-off-by: Ville Syrjälä 

LGTM.
Reviewed-by: Animesh Manna 

> ---
>  drivers/gpu/drm/i915/display/intel_dsb.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index fa4b808a8134..636c57767f97 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -187,6 +187,22 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
>   }
>  }
> 
> +static u32 intel_dsb_align_tail(struct intel_dsb *dsb) {
> + u32 aligned_tail, tail;
> +
> + tail = dsb->free_pos * 4;
> + aligned_tail = ALIGN(tail, CACHELINE_BYTES);
> +
> + if (aligned_tail > tail)
> + memset(>cmd_buf[dsb->free_pos], 0,
> +aligned_tail - tail);
> +
> + dsb->free_pos = aligned_tail / 4;
> +
> + return aligned_tail;
> +}
> +
>  /**
>   * intel_dsb_commit() - Trigger workload execution of DSB.
>   * @dsb: DSB context
> @@ -200,14 +216,10 @@ void intel_dsb_commit(struct intel_dsb *dsb)
>   enum pipe pipe = crtc->pipe;
>   u32 tail;
> 
> - if (!(dsb && dsb->free_pos))
> + tail = intel_dsb_align_tail(dsb);
> + if (tail == 0)
>   return;
> 
> - tail = ALIGN(dsb->free_pos * 4, CACHELINE_BYTES);
> - if (tail > dsb->free_pos * 4)
> - memset(>cmd_buf[dsb->free_pos], 0,
> -(tail - dsb->free_pos * 4));
> -
>   if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
>   drm_err(_priv->drm, "DSB engine is busy.\n");
>   goto reset;
> --
> 2.37.4

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[David Laight]

From: Daniel Vetter
> Sent: 05 January 2023 14:13
...
> > > So here we are, with Andrzej looking to add the common helper. And the
> > > same concerns crop up. What should it be called to make it clear that
> > > it's not atomic? Is that possible?
> >
> > old_value = read_write(variable, new_value);
> >
> > But two statements are much clearer.
> 
> Yeah this is my point for fetch_and_zero or any of the other proposals.
> We're essentially replacing these two lines:
> 
>   var = some->pointer->chase;
>   some->pointer->chase = NULL;
> 
> with a macro. C is verbose, and sometimes painfully so,

Try ADA or VHDL :-)

> if the pointer
> chase is really to onerous then I think that should be refactored with a
> meaningfully locally name variable, not fancy macros wrapped around to
> golf a few characters away.

Provided 'var' is a local the compiler is pretty likely to only do the
'pointer chase' once.
You can also do:
var = NULL;
swap(some->pointer->chase, var);
and get pretty much the same object code.

> But what about swap() you ask? That one needs a temp variable, and it does
> make sense to hide that in a ({}) block in a macro.

Sometimes, but not enough for the 'missed opportunity for swap()'
message. 

> But for the above two
> lines I really don't see a point outside of obfuscated C contexts.

Indeed.

Isn't the suggested __xchg() in one of the 'reserved for implementation'
namespaces - so shouldn't be a function that might be expected to be
actually used.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [Intel-gfx] [PATCH v2 04/21] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming

[Jani Nikula]

On Thu, 05 Jan 2023, Mika Kahola  wrote:
> From: Radhakrishna Sripada 
>
> XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
> has a dedicated PIPE 5.2 Message bus for configuration. This message
> bus is used to configure the phy internal registers.
>
> XELPDP has C10 phys to drive output to the EDP and the native output
> from the display engine. Add structures, programming hardware state
> readout logic. Port clock calculations are similar to DG2. Use the DG2
> formulae to calculate the port clock but use the relevant pll signals.
> Note: PHY lane 0 is always used for PLL programming.
>
> Add sequences for C10 phy enable/disable phy lane reset,
> powerdown change sequence and phy lane programming.
>
> Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636
>
> v2: Squash patches related to C10 phy message bus and pll
> programming support (Jani)
> Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
> Move macro definitions (Jani)
> DP rates as separate patch (Jani)
> Spin out xelpdp register definitions into a separate file (Jani)
> Replace macro to select registers based on phy lane with
> function calls (Jani)
> Fix styling issues (Jani)
> Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
> v3: Move clear request flag into try-loop
>
> Cc: Mika Kahola 
> Cc: Imre Deak 
> Cc: Uma Shankar 
> Signed-off-by: Radhakrishna Sripada 
> Signed-off-by: Mika Kahola 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-5-mika.kah...@intel.com
> ---
>  drivers/gpu/drm/i915/Makefile |1 +
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1110 +
>  drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   43 +
>  .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   34 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  |   22 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |1 +
>  .../drm/i915/display/intel_display_power.c|3 +-
>  .../i915/display/intel_display_power_well.c   |2 +-
>  .../drm/i915/display/intel_display_types.h|6 +
>  drivers/gpu/drm/i915/display/intel_dpll.c |   22 +-
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
>  .../drm/i915/display/intel_modeset_verify.c   |2 +
>  drivers/gpu/drm/i915/i915_reg.h   |5 +
>  drivers/gpu/drm/i915/i915_reg_defs.h  |   57 +
>  14 files changed, 1305 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index f47f00b162a4..200364242c83 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -290,6 +290,7 @@ i915-y += \
>   display/icl_dsi.o \
>   display/intel_backlight.o \
>   display/intel_crt.o \
> + display/intel_cx0_phy.o \
>   display/intel_ddi.o \
>   display/intel_ddi_buf_trans.o \
>   display/intel_display_trace.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> new file mode 100644
> index ..1ceebbc6b650
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -0,0 +1,1110 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include "i915_reg.h"
> +#include "intel_cx0_phy.h"
> +#include "intel_cx0_phy_regs.h"
> +#include "intel_de.h"
> +#include "intel_display_types.h"
> +#include "intel_dp.h"
> +#include "intel_panel.h"
> +
> +bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> +{
> + if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
> + return true;
> +
> + return false;
> +}
> +
> +static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port 
> port, int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> +
> + /* Bring the phy to idle. */
> + intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
> +XELPDP_PORT_M2P_TRANSACTION_RESET);
> +
> + /* Wait for Idle Clear. */
> + if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
> lane-1),
> + XELPDP_PORT_M2P_TRANSACTION_RESET,
> + XELPDP_MSGBUS_TIMEOUT_SLOW)) {
> + drm_err_once(>drm, "Failed to bring PHY %c to idle.\n", 
> phy_name(phy));

I'm not sure about the drm_err_once() use. It'll hide the failures for
the future.

If it's not something the user can meaningfully do anything about, does
it even have to be error level? Make it drm_dbg_kms() and debug log
always?

BR,
Jani.



> + return;
> + }
> +
> + intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane-1), ~0);
> +}
> +
> +static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port 
> port, int lane, 

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[Tvrtko Ursulin]

On 05/01/2023 13:34, David Laight wrote:

From: Jani Nikula

Sent: 05 January 2023 13:28

On Thu, 05 Jan 2023, Daniel Vetter  wrote:

On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:

From: Andrzej Hajda 

Sent: 09 December 2022 15:49

The pattern of setting variable with new value and returning old
one is very common in kernel. Usually atomicity of the operation
is not required, so xchg seems to be suboptimal and confusing in
such cases. Since name xchg is already in use and __xchg is used
in architecture code, proposition is to name the macro exchange.


Dunno, if it is non-atomic then two separate assignment statements
is decidedly more obvious and needs less brain cells to process.
Otherwise someone will assume 'something clever' is going on
and the operation is atomic.


Yes, this also my take. The i915 code that uses this to excess is decidely
unreadable imo, and the macro should simply be replaced by open-coded
versions.

Not moved into shared headers where even more people can play funny games
with it.


My stand in i915 has been that the local fetch_and_zero() needs to
go. Either replaced by a common helper in core kernel headers, or open
coded, I personally don't care, but the local version can't stay.

My rationale has been that fetch_and_zero() looks atomic and looks like
it comes from shared headers, but it's neither. It's deceptive. It
started small and harmless, but things like this just proliferate and
get copy-pasted all over the place.

So here we are, with Andrzej looking to add the common helper. And the
same concerns crop up. What should it be called to make it clear that
it's not atomic? Is that possible?


old_value = read_write(variable, new_value);

But two statements are much clearer.


In a later thread there was more discussion on this and some new 
suggestions - exchange(), replace() or even take() sound fine to me. 
Last one is perhaps most specialized if it implies zeroing, which I at 
least assume it does.


All three are distant enough from atomic connotations of xchg. If that 
was a concern with __xchg, which I not sure it should be since there is 
"prior art" in the kernel for atomic vs non-atomic like set_bit and 
__set_bit.


My 2c, regardless of what name, that it is not something which is 
strictly needed, but a convenient syntactic sugar. (Exploded line counts 
with sometimes single use local variables are a bit meh.) And I am not 
really sure that open coding is more readable once the new pattern would 
be established. In short, if there can be swap there can be $insert_name 
too I guess.


Bonus points if needlessly atomic sites can be converted but identifying 
them is probably an exercise for a later phase.


Regards,

Tvrtko

P.S. FWIW my preference are either replace() or __xchg().

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[Daniel Vetter]

On Thu, Jan 05, 2023 at 01:34:33PM +, David Laight wrote:
> From: Jani Nikula
> > Sent: 05 January 2023 13:28
> > 
> > On Thu, 05 Jan 2023, Daniel Vetter  wrote:
> > > On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
> > >> From: Andrzej Hajda 
> > >> > Sent: 09 December 2022 15:49
> > >> >
> > >> > The pattern of setting variable with new value and returning old
> > >> > one is very common in kernel. Usually atomicity of the operation
> > >> > is not required, so xchg seems to be suboptimal and confusing in
> > >> > such cases. Since name xchg is already in use and __xchg is used
> > >> > in architecture code, proposition is to name the macro exchange.
> > >>
> > >> Dunno, if it is non-atomic then two separate assignment statements
> > >> is decidedly more obvious and needs less brain cells to process.
> > >> Otherwise someone will assume 'something clever' is going on
> > >> and the operation is atomic.
> > >
> > > Yes, this also my take. The i915 code that uses this to excess is decidely
> > > unreadable imo, and the macro should simply be replaced by open-coded
> > > versions.
> > >
> > > Not moved into shared headers where even more people can play funny games
> > > with it.
> > 
> > My stand in i915 has been that the local fetch_and_zero() needs to
> > go. Either replaced by a common helper in core kernel headers, or open
> > coded, I personally don't care, but the local version can't stay.
> > 
> > My rationale has been that fetch_and_zero() looks atomic and looks like
> > it comes from shared headers, but it's neither. It's deceptive. It
> > started small and harmless, but things like this just proliferate and
> > get copy-pasted all over the place.

Yeah the entire "is it atomic or not" is the issue on top here.

> > So here we are, with Andrzej looking to add the common helper. And the
> > same concerns crop up. What should it be called to make it clear that
> > it's not atomic? Is that possible?
> 
> old_value = read_write(variable, new_value);
> 
> But two statements are much clearer.

Yeah this is my point for fetch_and_zero or any of the other proposals.
We're essentially replacing these two lines:

var = some->pointer->chase;
some->pointer->chase = NULL;

with a macro. C is verbose, and sometimes painfully so, if the pointer
chase is really to onerous then I think that should be refactored with a
meaningfully locally name variable, not fancy macros wrapped around to
golf a few characters away.

But what about swap() you ask? That one needs a temp variable, and it does
make sense to hide that in a ({}) block in a macro. But for the above two
lines I really don't see a point outside of obfuscated C contexts.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[David Laight]

From: Jani Nikula
> Sent: 05 January 2023 13:28
> 
> On Thu, 05 Jan 2023, Daniel Vetter  wrote:
> > On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
> >> From: Andrzej Hajda 
> >> > Sent: 09 December 2022 15:49
> >> >
> >> > The pattern of setting variable with new value and returning old
> >> > one is very common in kernel. Usually atomicity of the operation
> >> > is not required, so xchg seems to be suboptimal and confusing in
> >> > such cases. Since name xchg is already in use and __xchg is used
> >> > in architecture code, proposition is to name the macro exchange.
> >>
> >> Dunno, if it is non-atomic then two separate assignment statements
> >> is decidedly more obvious and needs less brain cells to process.
> >> Otherwise someone will assume 'something clever' is going on
> >> and the operation is atomic.
> >
> > Yes, this also my take. The i915 code that uses this to excess is decidely
> > unreadable imo, and the macro should simply be replaced by open-coded
> > versions.
> >
> > Not moved into shared headers where even more people can play funny games
> > with it.
> 
> My stand in i915 has been that the local fetch_and_zero() needs to
> go. Either replaced by a common helper in core kernel headers, or open
> coded, I personally don't care, but the local version can't stay.
> 
> My rationale has been that fetch_and_zero() looks atomic and looks like
> it comes from shared headers, but it's neither. It's deceptive. It
> started small and harmless, but things like this just proliferate and
> get copy-pasted all over the place.
> 
> So here we are, with Andrzej looking to add the common helper. And the
> same concerns crop up. What should it be called to make it clear that
> it's not atomic? Is that possible?

old_value = read_write(variable, new_value);

But two statements are much clearer.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[Intel-gfx] [PATCH] drm/i915/gt: Cover rest of SVG unit MCR registers

[Gustavo Sousa]

CHICKEN_RASTER_{1,2} got overlooked with the move done in a9e69428b1b4
("drm/i915: Define MCR registers explicitly"). Registers from the SVG
unit became multicast as of Xe_HP graphics.

BSpec: 66534
Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly").
Signed-off-by: Gustavo Sousa 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f8eb807b56f9..570699548c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -407,10 +407,10 @@
 #define GEN9_WM_CHICKEN3   _MMIO(0x5588)
 #define   GEN9_FACTOR_IN_CLR_VAL_HIZ   (1 << 9)
 
-#define CHICKEN_RASTER_1   _MMIO(0x6204)
+#define CHICKEN_RASTER_1   MCR_REG(0x6204)
 #define   DIS_SF_ROUND_NEAREST_EVENREG_BIT(8)
 
-#define CHICKEN_RASTER_2   _MMIO(0x6208)
+#define CHICKEN_RASTER_2   MCR_REG(0x6208)
 #define   TBIMR_FAST_CLIP  REG_BIT(5)
 
 #define VFLSKPDMCR_REG(0x62a8)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index bf84efb3f15f..9a40aa61e86e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -645,7 +645,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs 
*engine,
 static void dg2_ctx_gt_tuning_init(struct intel_engine_cs *engine,
   struct i915_wa_list *wal)
 {
-   wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
+   wa_mcr_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
wa_mcr_write_clr_set(wal, XEHP_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
 REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
wa_mcr_add(wal,
@@ -780,7 +780,7 @@ static void dg2_ctx_workarounds_init(struct intel_engine_cs 
*engine,
wa_masked_en(wal, PSS_MODE2, SCOREBOARD_STALL_FLUSH_CONTROL);
 
/* Wa_15010599737:dg2 */
-   wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
+   wa_mcr_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
 
/* Wa_18019271663:dg2 */
wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
-- 
2.39.0

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds

[Tvrtko Ursulin]

Okay to sum it up below with some final notes..

On 04/01/2023 19:34, Matt Roper wrote:

On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:


On 23/12/2022 18:28, Lucas De Marchi wrote:

On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:


On 22/12/2022 15:55, Lucas De Marchi wrote:

On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:


On 22/12/2022 08:25, Lucas De Marchi wrote:

The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended to new platforms or steppings.  Remove them altogether with
the following matches (platforms extracted from intel_workarounds.c):

 find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
 find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1

Same things was executed in the gem directory, omitted
here for brevity.



There were a few false positives that included the workaround
description. Those were manually patched.


sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'


then there are false negatives. We have Was in the form
"Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
we simply don't see. After running that in gt/:

$ git grep ": mtl" -- drivers/gpu/drm/i915/
drivers/gpu/drm/i915/gt/intel_gt_pm.c:  /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c:  /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c:  /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/intel_gt_pm.c:  /* Wa_14017073508: mtl */
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c:   * Wa_14017073508: mtl
drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */

I was going with the platform names to avoid the false
negatives and because I was entertaining the idea of only doing this for
latest platforms where we do have the "Wa_[[:number:]]" form



Maybe..

Matt recently said he has this worked planned, but more
importantly - I gather then that the WA lookup tool
definitely does not output these strings?


Whatever it does it's true only at the time it's called. It
simply tells what
are the platforms and steppings the Wa applies to. We can change the
output to whatever we want, but that is not the point.
Those comments get stale and bring no real value as they match 1:1
what the code is supposed to be doing. Several times a patch has to
update just that comment to "extend a workaround" to a next platform.
This is not always done, so we get a comment that doesn't match what is
supposed to be there.


Tl;dr; version - lets park this until January and discuss once
everyone is back.


I'll leave my comment here since I will be out until mid January.



Longer version. I've been trying to get us talking about this a
couple times before and I'd really like to close with an explicit
consensus, discussion points addressed instead of skipped and just
moving ahead with patches.

References:
  3fcf71b9-337f-6186-7b00-27cbfd116...@linux.intel.com
  Y5j0b/bykbitc...@mdroper-desk1.amr.corp.intel.com

So point I wanted to discuss is whether these comments are truly
useless or maybe they can help during review. If the tool can
actually output them then I am leaning towards that they can be.


I consider "can the tool output xyz?" asking the wrong question.
"The tool", which is our own small python script querying a database can
output anything like that if we want to. The database has information of
what are the platforms/steppings for each the WA is known to be applied
*today*. And that can change and do change often, particularly for early
steppings and recent platforms.


Thought is, when a patch comes for review adding a new platform,
stepping, whatever, to an existing if condition, if it contains the
comments reviewer can more easily spot a hyphotetical logic
inversion error or similar. It is also trivial to check that both
condition and comment have been updated. (So lets not be rash and
remove something maybe useful just because it can go stale *only if*
reviewers are not giving sufficient attention that changes are made
in tandem.)


I can argue to the other side too. We don't have comments in the kernel
like

  /* Add 1 to i */
  i += 1;

This is exactly what these comments are doing. And they are misleading


I'll file this under "Reductio ad absurdum", kind of. :)


and may introduce bugs rather than helping reviewing:

  Wa_12345:tgl[a0,c0)
  if (IS_TGL_GRAPHICS_STEP(STEP_A0, STEP_B0)

One might read the comment, skipping over the condition and 

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[Jani Nikula]

On Thu, 05 Jan 2023, Daniel Vetter  wrote:
> On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
>> From: Andrzej Hajda 
>> > Sent: 09 December 2022 15:49
>> > 
>> > The pattern of setting variable with new value and returning old
>> > one is very common in kernel. Usually atomicity of the operation
>> > is not required, so xchg seems to be suboptimal and confusing in
>> > such cases. Since name xchg is already in use and __xchg is used
>> > in architecture code, proposition is to name the macro exchange.
>> 
>> Dunno, if it is non-atomic then two separate assignment statements
>> is decidedly more obvious and needs less brain cells to process.
>> Otherwise someone will assume 'something clever' is going on
>> and the operation is atomic.
>
> Yes, this also my take. The i915 code that uses this to excess is decidely
> unreadable imo, and the macro should simply be replaced by open-coded
> versions.
>
> Not moved into shared headers where even more people can play funny games
> with it.

My stand in i915 has been that the local fetch_and_zero() needs to
go. Either replaced by a common helper in core kernel headers, or open
coded, I personally don't care, but the local version can't stay.

My rationale has been that fetch_and_zero() looks atomic and looks like
it comes from shared headers, but it's neither. It's deceptive. It
started small and harmless, but things like this just proliferate and
get copy-pasted all over the place.

So here we are, with Andrzej looking to add the common helper. And the
same concerns crop up. What should it be called to make it clear that
it's not atomic? Is that possible?


BR,
Jani.



>
> I think swap() is a standard idiom in C, this one here just isn't.
> -Daniel

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH v2 9/9] drm/i915/display/misc: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/g4x_dp.c | 12 
 drivers/gpu/drm/i915/display/intel_drrs.c | 12 +++-
 drivers/gpu/drm/i915/display/intel_dvo.c  |  7 ++-
 drivers/gpu/drm/i915/display/intel_lvds.c | 12 
 drivers/gpu/drm/i915/display/intel_tv.c   | 18 +-
 5 files changed, 18 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
b/drivers/gpu/drm/i915/display/g4x_dp.c
index 24ef36ec2d3d3c..9629b174ec5d2c 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -136,16 +136,12 @@ static void intel_dp_prepare(struct intel_encoder 
*encoder,
 
intel_dp->DP |= DP_PIPE_SEL_IVB(crtc->pipe);
} else if (HAS_PCH_CPT(dev_priv) && port != PORT_A) {
-   u32 trans_dp;
-
intel_dp->DP |= DP_LINK_TRAIN_OFF_CPT;
 
-   trans_dp = intel_de_read(dev_priv, TRANS_DP_CTL(crtc->pipe));
-   if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
-   trans_dp |= TRANS_DP_ENH_FRAMING;
-   else
-   trans_dp &= ~TRANS_DP_ENH_FRAMING;
-   intel_de_write(dev_priv, TRANS_DP_CTL(crtc->pipe), trans_dp);
+   intel_de_rmw(dev_priv, TRANS_DP_CTL(crtc->pipe),
+TRANS_DP_ENH_FRAMING,
+drm_dp_enhanced_frame_cap(intel_dp->dpcd) ?
+TRANS_DP_ENH_FRAMING : 0);
} else {
if (IS_G4X(dev_priv) && pipe_config->limited_color_range)
intel_dp->DP |= DP_COLOR_RANGE_16_235;
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c 
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 5b9e3814e9..a52974f5f66042 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -68,21 +68,15 @@ intel_drrs_set_refresh_rate_pipeconf(struct intel_crtc 
*crtc,
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc->drrs.cpu_transcoder;
-   u32 val, bit;
+   u32 bit;
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
bit = PIPECONF_REFRESH_RATE_ALT_VLV;
else
bit = PIPECONF_REFRESH_RATE_ALT_ILK;
 
-   val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
-
-   if (refresh_rate == DRRS_REFRESH_RATE_LOW)
-   val |= bit;
-   else
-   val &= ~bit;
-
-   intel_de_write(dev_priv, PIPECONF(cpu_transcoder), val);
+   intel_de_rmw(dev_priv, PIPECONF(cpu_transcoder),
+bit, refresh_rate == DRRS_REFRESH_RATE_LOW ? bit : 0);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c 
b/drivers/gpu/drm/i915/display/intel_dvo.c
index 4aeae0f3ac9172..77d413781020de 100644
--- a/drivers/gpu/drm/i915/display/intel_dvo.c
+++ b/drivers/gpu/drm/i915/display/intel_dvo.c
@@ -444,11 +444,8 @@ static bool intel_dvo_init_dev(struct drm_i915_private 
*dev_priv,
 * the clock enabled before we attempt to initialize
 * the device.
 */
-   for_each_pipe(dev_priv, pipe) {
-   dpll[pipe] = intel_de_read(dev_priv, DPLL(pipe));
-   intel_de_write(dev_priv, DPLL(pipe),
-  dpll[pipe] | DPLL_DVO_2X_MODE);
-   }
+   for_each_pipe(dev_priv, pipe)
+   dpll[pipe] = intel_de_rmw(dev_priv, DPLL(pipe), 0, 
DPLL_DVO_2X_MODE);
 
ret = dvo->dev_ops->init(_dvo->dev, i2c);
 
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c 
b/drivers/gpu/drm/i915/display/intel_lvds.c
index aecec992cd0d2d..e8f47b7ef87649 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -316,11 +316,9 @@ static void intel_enable_lvds(struct intel_atomic_state 
*state,
struct intel_lvds_encoder *lvds_encoder = to_lvds_encoder(encoder);
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   intel_de_write(dev_priv, lvds_encoder->reg,
-  intel_de_read(dev_priv, lvds_encoder->reg) | 
LVDS_PORT_EN);
+   intel_de_rmw(dev_priv, lvds_encoder->reg, 0, LVDS_PORT_EN);
 
-   intel_de_write(dev_priv, PP_CONTROL(0),
-  intel_de_read(dev_priv, PP_CONTROL(0)) | PANEL_POWER_ON);
+   intel_de_rmw(dev_priv, PP_CONTROL(0), 0, PANEL_POWER_ON);
intel_de_posting_read(dev_priv, lvds_encoder->reg);
 
if (intel_de_wait_for_set(dev_priv, PP_STATUS(0), PP_ON, 5000))
@@ -338,14 +336,12 @@ static void intel_disable_lvds(struct intel_atomic_state 
*state,
struct intel_lvds_encoder *lvds_encoder = to_lvds_encoder(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
 
-   intel_de_write(dev_priv, PP_CONTROL(0),
-  intel_de_read(dev_priv, PP_CONTROL(0)) & 

[Intel-gfx] [PATCH v2 8/9] drm/i915/display/interfaces: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_ddi.c   | 49 +++---
 drivers/gpu/drm/i915/display/intel_fdi.c   |  3 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c | 30 +++--
 3 files changed, 22 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1f5a471a0adf27..500dac59a14157 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -644,19 +644,14 @@ int intel_ddi_toggle_hdcp_bits(struct intel_encoder 
*intel_encoder,
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
int ret = 0;
-   u32 tmp;
 
wakeref = intel_display_power_get_if_enabled(dev_priv,
 
intel_encoder->power_domain);
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
 
-   tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
-   if (enable)
-   tmp |= hdcp_mask;
-   else
-   tmp &= ~hdcp_mask;
-   intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
+   intel_de_rmw(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder),
+hdcp_mask, enable ? hdcp_mask : 0);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
 }
@@ -2200,15 +2195,13 @@ static void intel_ddi_enable_fec(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp;
-   u32 val;
 
if (!crtc_state->fec_enable)
return;
 
intel_dp = enc_to_intel_dp(encoder);
-   val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
-   val |= DP_TP_CTL_FEC_ENABLE;
-   intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
+   intel_de_rmw(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
+0, DP_TP_CTL_FEC_ENABLE);
 }
 
 static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
@@ -2216,15 +2209,13 @@ static void intel_ddi_disable_fec_state(struct 
intel_encoder *encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp;
-   u32 val;
 
if (!crtc_state->fec_enable)
return;
 
intel_dp = enc_to_intel_dp(encoder);
-   val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
-   val &= ~DP_TP_CTL_FEC_ENABLE;
-   intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
+   intel_de_rmw(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
+DP_TP_CTL_FEC_ENABLE, 0);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
 }
 
@@ -2622,12 +2613,10 @@ static void intel_disable_ddi_buf(struct intel_encoder 
*encoder,
wait = true;
}
 
-   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;
-   intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), 
val);
-   }
+   if (intel_crtc_has_dp_encoder(crtc_state))
+   intel_de_rmw(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
+DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK,
+DP_TP_CTL_LINK_TRAIN_PAT1);
 
/* Disable FEC in DP Sink */
intel_ddi_disable_fec_state(encoder, crtc_state);
@@ -2660,15 +2649,10 @@ static void intel_ddi_post_disable_dp(struct 
intel_atomic_state *state,
if (DISPLAY_VER(dev_priv) >= 12) {
if (is_mst) {
enum transcoder cpu_transcoder = 
old_crtc_state->cpu_transcoder;
-   u32 val;
 
-   val = intel_de_read(dev_priv,
-   TRANS_DDI_FUNC_CTL(cpu_transcoder));
-   val &= ~(TGL_TRANS_DDI_PORT_MASK |
-TRANS_DDI_MODE_SELECT_MASK);
-   intel_de_write(dev_priv,
-  TRANS_DDI_FUNC_CTL(cpu_transcoder),
-  val);
+   intel_de_rmw(dev_priv, 
TRANS_DDI_FUNC_CTL(cpu_transcoder),
+TGL_TRANS_DDI_PORT_MASK | 
TRANS_DDI_MODE_SELECT_MASK,
+0);
}
} else {
if (!is_mst)
@@ -3222,12 +3206,9 @@ static void intel_ddi_set_idle_link_train(struct 
intel_dp *intel_dp,
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum 

[Intel-gfx] [PATCH v2 7/9] drm/i915/display/panel: use intel_de_rmw if possible in panel related code

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 .../gpu/drm/i915/display/intel_backlight.c| 59 +++
 drivers/gpu/drm/i915/display/intel_pps.c  | 14 ++---
 drivers/gpu/drm/i915/display/intel_psr.c  | 40 -
 3 files changed, 37 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 5b7da72c95b8c5..b088921c543eaa 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -349,8 +349,7 @@ static void lpt_disable_backlight(const struct 
drm_connector_state *old_conn_sta
intel_de_write(i915, BLC_PWM_CPU_CTL2, tmp & ~BLM_PWM_ENABLE);
}
 
-   tmp = intel_de_read(i915, BLC_PWM_PCH_CTL1);
-   intel_de_write(i915, BLC_PWM_PCH_CTL1, tmp & ~BLM_PCH_PWM_ENABLE);
+   tmp = intel_de_rmw(i915, BLC_PWM_PCH_CTL1, BLM_PCH_PWM_ENABLE, 0);
 }
 
 static void pch_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -361,11 +360,9 @@ static void pch_disable_backlight(const struct 
drm_connector_state *old_conn_sta
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(i915, BLC_PWM_CPU_CTL2);
-   intel_de_write(i915, BLC_PWM_CPU_CTL2, tmp & ~BLM_PWM_ENABLE);
+   intel_de_rmw(i915, BLC_PWM_CPU_CTL2, BLM_PWM_ENABLE, 0);
 
-   tmp = intel_de_read(i915, BLC_PWM_PCH_CTL1);
-   intel_de_write(i915, BLC_PWM_PCH_CTL1, tmp & ~BLM_PCH_PWM_ENABLE);
+   tmp = intel_de_rmw(i915, BLC_PWM_PCH_CTL1, BLM_PCH_PWM_ENABLE, 0);
 }
 
 static void i9xx_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -380,8 +377,7 @@ static void i965_disable_backlight(const struct 
drm_connector_state *old_conn_st
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(i915, BLC_PWM_CTL2);
-   intel_de_write(i915, BLC_PWM_CTL2, tmp & ~BLM_PWM_ENABLE);
+   tmp = intel_de_rmw(i915, BLC_PWM_CTL2, BLM_PWM_ENABLE, 0);
 }
 
 static void vlv_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -393,8 +389,7 @@ static void vlv_disable_backlight(const struct 
drm_connector_state *old_conn_sta
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(i915, VLV_BLC_PWM_CTL2(pipe));
-   intel_de_write(i915, VLV_BLC_PWM_CTL2(pipe), tmp & ~BLM_PWM_ENABLE);
+   tmp = intel_de_rmw(i915, VLV_BLC_PWM_CTL2(pipe), BLM_PWM_ENABLE, 0);
 }
 
 static void bxt_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -402,19 +397,14 @@ static void bxt_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 tmp;
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(i915, BXT_BLC_PWM_CTL(panel->backlight.controller));
-   intel_de_write(i915, BXT_BLC_PWM_CTL(panel->backlight.controller),
-  tmp & ~BXT_BLC_PWM_ENABLE);
+   intel_de_rmw(i915, BXT_BLC_PWM_CTL(panel->backlight.controller),
+BXT_BLC_PWM_ENABLE, 0);
 
-   if (panel->backlight.controller == 1) {
-   val = intel_de_read(i915, UTIL_PIN_CTL);
-   val &= ~UTIL_PIN_ENABLE;
-   intel_de_write(i915, UTIL_PIN_CTL, val);
-   }
+   if (panel->backlight.controller == 1)
+   intel_de_rmw(i915, UTIL_PIN_CTL, UTIL_PIN_ENABLE, 0);
 }
 
 static void cnp_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 val)
@@ -422,13 +412,11 @@ static void cnp_disable_backlight(const struct 
drm_connector_state *old_conn_sta
struct intel_connector *connector = 
to_intel_connector(old_conn_state->connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 tmp;
 
intel_backlight_set_pwm_level(old_conn_state, val);
 
-   tmp = intel_de_read(i915, BXT_BLC_PWM_CTL(panel->backlight.controller));
-   intel_de_write(i915, BXT_BLC_PWM_CTL(panel->backlight.controller),
-  tmp & ~BXT_BLC_PWM_ENABLE);
+   intel_de_rmw(i915, BXT_BLC_PWM_CTL(panel->backlight.controller),
+BXT_BLC_PWM_ENABLE, 0);
 }
 
 static void ext_pwm_disable_backlight(const struct drm_connector_state 
*old_conn_state, u32 level)
@@ -478,7 +466,7 @@ static void lpt_enable_backlight(const struct 
intel_crtc_state *crtc_state,
struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
-   u32 pch_ctl1, pch_ctl2, schicken;
+ 

[Intel-gfx] [PATCH v2 2/9] drm/i915/display/power: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 .../drm/i915/display/intel_display_power.c| 49 ---
 .../i915/display/intel_display_power_well.c   | 82 ++-
 2 files changed, 39 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 1a23ecd4623a53..90d7a623d6e3cc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1260,9 +1260,7 @@ static void hsw_disable_lcpll(struct drm_i915_private 
*dev_priv,
drm_err(_priv->drm, "D_COMP RCOMP still in progress\n");
 
if (allow_power_down) {
-   val = intel_de_read(dev_priv, LCPLL_CTL);
-   val |= LCPLL_POWER_DOWN_ALLOW;
-   intel_de_write(dev_priv, LCPLL_CTL, val);
+   intel_de_rmw(dev_priv, LCPLL_CTL, 0, LCPLL_POWER_DOWN_ALLOW);
intel_de_posting_read(dev_priv, LCPLL_CTL);
}
 }
@@ -1306,9 +1304,7 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
drm_err(_priv->drm, "LCPLL not locked yet\n");
 
if (val & LCPLL_CD_SOURCE_FCLK) {
-   val = intel_de_read(dev_priv, LCPLL_CTL);
-   val &= ~LCPLL_CD_SOURCE_FCLK;
-   intel_de_write(dev_priv, LCPLL_CTL, val);
+   intel_de_rmw(dev_priv, LCPLL_CTL, LCPLL_CD_SOURCE_FCLK, 0);
 
if (wait_for_us((intel_de_read(dev_priv, LCPLL_CTL) &
 LCPLL_CD_SOURCE_FCLK_DONE) == 0, 1))
@@ -1347,15 +1343,11 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
  */
 static void hsw_enable_pc8(struct drm_i915_private *dev_priv)
 {
-   u32 val;
-
drm_dbg_kms(_priv->drm, "Enabling package C8+\n");
 
-   if (HAS_PCH_LPT_LP(dev_priv)) {
-   val = intel_de_read(dev_priv, SOUTH_DSPCLK_GATE_D);
-   val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
-   intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D, val);
-   }
+   if (HAS_PCH_LPT_LP(dev_priv))
+   intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
+PCH_LP_PARTITION_LEVEL_DISABLE, 0);
 
lpt_disable_clkout_dp(dev_priv);
hsw_disable_lcpll(dev_priv, true, true);
@@ -1363,25 +1355,21 @@ static void hsw_enable_pc8(struct drm_i915_private 
*dev_priv)
 
 static void hsw_disable_pc8(struct drm_i915_private *dev_priv)
 {
-   u32 val;
-
drm_dbg_kms(_priv->drm, "Disabling package C8+\n");
 
hsw_restore_lcpll(dev_priv);
intel_init_pch_refclk(dev_priv);
 
-   if (HAS_PCH_LPT_LP(dev_priv)) {
-   val = intel_de_read(dev_priv, SOUTH_DSPCLK_GATE_D);
-   val |= PCH_LP_PARTITION_LEVEL_DISABLE;
-   intel_de_write(dev_priv, SOUTH_DSPCLK_GATE_D, val);
-   }
+   if (HAS_PCH_LPT_LP(dev_priv))
+   intel_de_rmw(dev_priv, SOUTH_DSPCLK_GATE_D,
+0, PCH_LP_PARTITION_LEVEL_DISABLE);
 }
 
 static void intel_pch_reset_handshake(struct drm_i915_private *dev_priv,
  bool enable)
 {
i915_reg_t reg;
-   u32 reset_bits, val;
+   u32 reset_bits;
 
if (IS_IVYBRIDGE(dev_priv)) {
reg = GEN7_MSG_CTL;
@@ -1394,14 +1382,7 @@ static void intel_pch_reset_handshake(struct 
drm_i915_private *dev_priv,
if (DISPLAY_VER(dev_priv) >= 14)
reset_bits |= MTL_RESET_PICA_HANDSHAKE_EN;
 
-   val = intel_de_read(dev_priv, reg);
-
-   if (enable)
-   val |= reset_bits;
-   else
-   val &= ~reset_bits;
-
-   intel_de_write(dev_priv, reg, val);
+   intel_de_rmw(dev_priv, reg, reset_bits, enable ? reset_bits : 0);
 }
 
 static void skl_display_core_init(struct drm_i915_private *dev_priv,
@@ -1618,7 +1599,6 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
 {
struct i915_power_domains *power_domains = 
_priv->display.power.domains;
struct i915_power_well *well;
-   u32 val;
 
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
 
@@ -1670,11 +1650,10 @@ static void icl_display_core_init(struct 
drm_i915_private *dev_priv,
intel_dmc_load_program(dev_priv);
 
/* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */
-   if (DISPLAY_VER(dev_priv) >= 12) {
-   val = DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM |
- DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR;
-   intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0, val);
-   }
+   if (DISPLAY_VER(dev_priv) >= 12)
+   intel_de_rmw(dev_priv, GEN11_CHICKEN_DCPR_2, 0,
+DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM |
+DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR);
 
/* Wa_14011503030:xelpd */
if 

[Intel-gfx] [PATCH v2 6/9] drm/i915/display/hdmi: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/g4x_hdmi.c   |  8 ++---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 15 -
 drivers/gpu/drm/i915/display/intel_hdmi.c | 40 +++
 3 files changed, 22 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c 
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index c3580d96765c6c..f58849b416ea89 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -271,8 +271,8 @@ static void cpt_enable_hdmi(struct intel_atomic_state 
*state,
 */
 
if (pipe_config->pipe_bpp > 24) {
-   intel_de_write(dev_priv, TRANS_CHICKEN1(pipe),
-  intel_de_read(dev_priv, TRANS_CHICKEN1(pipe)) | 
TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
+   intel_de_rmw(dev_priv, TRANS_CHICKEN1(pipe),
+0, TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
 
temp &= ~SDVO_COLOR_FORMAT_MASK;
temp |= SDVO_COLOR_FORMAT_8bpc;
@@ -288,8 +288,8 @@ static void cpt_enable_hdmi(struct intel_atomic_state 
*state,
intel_de_write(dev_priv, intel_hdmi->hdmi_reg, temp);
intel_de_posting_read(dev_priv, intel_hdmi->hdmi_reg);
 
-   intel_de_write(dev_priv, TRANS_CHICKEN1(pipe),
-  intel_de_read(dev_priv, TRANS_CHICKEN1(pipe)) & 
~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
+   intel_de_rmw(dev_priv, TRANS_CHICKEN1(pipe),
+TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE, 0);
}
 
drm_WARN_ON(_priv->drm, pipe_config->has_audio &&
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6406fd487ee524..2984d2810e42cc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -943,8 +943,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 
repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
   port);
-   intel_de_write(dev_priv, HDCP_REP_CTL,
-  intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+   intel_de_rmw(dev_priv, HDCP_REP_CTL, repeater_ctl, 0);
 
ret = hdcp->shim->toggle_signalling(dig_port, cpu_transcoder, false);
if (ret) {
@@ -1819,12 +1818,10 @@ static int hdcp2_enable_encryption(struct 
intel_connector *connector)
}
 
if (intel_de_read(dev_priv, HDCP2_STATUS(dev_priv, cpu_transcoder, 
port)) &
-   LINK_AUTH_STATUS) {
+   LINK_AUTH_STATUS)
/* Link is Authenticated. Now set for Encryption */
-   intel_de_write(dev_priv,
-  HDCP2_CTL(dev_priv, cpu_transcoder, port),
-  intel_de_read(dev_priv, HDCP2_CTL(dev_priv, 
cpu_transcoder, port)) | CTL_LINK_ENCRYPTION_REQ);
-   }
+   intel_de_rmw(dev_priv, HDCP2_CTL(dev_priv, cpu_transcoder, 
port),
+0, CTL_LINK_ENCRYPTION_REQ);
 
ret = intel_de_wait_for_set(dev_priv,
HDCP2_STATUS(dev_priv, cpu_transcoder,
@@ -1848,8 +1845,8 @@ static int hdcp2_disable_encryption(struct 
intel_connector *connector)
drm_WARN_ON(_priv->drm, !(intel_de_read(dev_priv, 
HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
  LINK_ENCRYPTION_STATUS));
 
-   intel_de_write(dev_priv, HDCP2_CTL(dev_priv, cpu_transcoder, port),
-  intel_de_read(dev_priv, HDCP2_CTL(dev_priv, 
cpu_transcoder, port)) & ~CTL_LINK_ENCRYPTION_REQ);
+   intel_de_rmw(dev_priv, HDCP2_CTL(dev_priv, cpu_transcoder, port),
+CTL_LINK_ENCRYPTION_REQ, 0);
 
ret = intel_de_wait_for_clear(dev_priv,
  HDCP2_STATUS(dev_priv, cpu_transcoder,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index efa2da080f62d4..4b09f17aa4b23b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -237,15 +237,11 @@ static void g4x_read_infoframe(struct intel_encoder 
*encoder,
   void *frame, ssize_t len)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   u32 val, *data = frame;
+   u32 *data = frame;
int i;
 
-   val = intel_de_read(dev_priv, VIDEO_DIP_CTL);
-
-   val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
-   val |= g4x_infoframe_index(type);
-
-   intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
+   intel_de_rmw(dev_priv, VIDEO_DIP_CTL,
+VIDEO_DIP_SELECT_MASK | 0xf, g4x_infoframe_index(type));
 
for (i = 0; i < len; i += 4)
*data++ = intel_de_read(dev_priv, 

[Intel-gfx] [PATCH v2 5/9] drm/i915/display/pch: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 .../gpu/drm/i915/display/intel_pch_display.c  | 41 +--
 .../gpu/drm/i915/display/intel_pch_refclk.c   | 10 +
 2 files changed, 13 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_pch_display.c 
b/drivers/gpu/drm/i915/display/intel_pch_display.c
index cecc0d007cf39c..4b5e069a1b9051 100644
--- a/drivers/gpu/drm/i915/display/intel_pch_display.c
+++ b/drivers/gpu/drm/i915/display/intel_pch_display.c
@@ -307,7 +307,6 @@ static void ilk_disable_pch_transcoder(struct intel_crtc 
*crtc)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
i915_reg_t reg;
-   u32 val;
 
/* FDI relies on the transcoder */
assert_fdi_tx_disabled(dev_priv, pipe);
@@ -317,21 +316,16 @@ static void ilk_disable_pch_transcoder(struct intel_crtc 
*crtc)
assert_pch_ports_disabled(dev_priv, pipe);
 
reg = PCH_TRANSCONF(pipe);
-   val = intel_de_read(dev_priv, reg);
-   val &= ~TRANS_ENABLE;
-   intel_de_write(dev_priv, reg, val);
+   intel_de_rmw(dev_priv, reg, TRANS_ENABLE, 0);
/* wait for PCH transcoder off, transcoder state */
if (intel_de_wait_for_clear(dev_priv, reg, TRANS_STATE_ENABLE, 50))
drm_err(_priv->drm, "failed to disable transcoder %c\n",
pipe_name(pipe));
 
-   if (HAS_PCH_CPT(dev_priv)) {
+   if (HAS_PCH_CPT(dev_priv))
/* Workaround: Clear the timing override chicken bit again. */
-   reg = TRANS_CHICKEN2(pipe);
-   val = intel_de_read(dev_priv, reg);
-   val &= ~TRANS_CHICKEN2_TIMING_OVERRIDE;
-   intel_de_write(dev_priv, reg, val);
-   }
+   intel_de_rmw(dev_priv, TRANS_CHICKEN2(pipe),
+TRANS_CHICKEN2_TIMING_OVERRIDE, 0);
 }
 
 void ilk_pch_pre_enable(struct intel_atomic_state *state,
@@ -456,21 +450,14 @@ void ilk_pch_post_disable(struct intel_atomic_state 
*state,
ilk_disable_pch_transcoder(crtc);
 
if (HAS_PCH_CPT(dev_priv)) {
-   i915_reg_t reg;
-   u32 temp;
-
/* disable TRANS_DP_CTL */
-   reg = TRANS_DP_CTL(pipe);
-   temp = intel_de_read(dev_priv, reg);
-   temp &= ~(TRANS_DP_OUTPUT_ENABLE |
- TRANS_DP_PORT_SEL_MASK);
-   temp |= TRANS_DP_PORT_SEL_NONE;
-   intel_de_write(dev_priv, reg, temp);
+   intel_de_rmw(dev_priv, TRANS_DP_CTL(pipe),
+TRANS_DP_OUTPUT_ENABLE | TRANS_DP_PORT_SEL_MASK,
+TRANS_DP_PORT_SEL_NONE);
 
/* disable DPLL_SEL */
-   temp = intel_de_read(dev_priv, PCH_DPLL_SEL);
-   temp &= ~(TRANS_DPLL_ENABLE(pipe) | TRANS_DPLLB_SEL(pipe));
-   intel_de_write(dev_priv, PCH_DPLL_SEL, temp);
+   intel_de_rmw(dev_priv, PCH_DPLL_SEL,
+TRANS_DPLL_ENABLE(pipe) | TRANS_DPLLB_SEL(pipe), 
0);
}
 
ilk_fdi_pll_disable(crtc);
@@ -580,20 +567,14 @@ static void lpt_enable_pch_transcoder(const struct 
intel_crtc_state *crtc_state)
 
 static void lpt_disable_pch_transcoder(struct drm_i915_private *dev_priv)
 {
-   u32 val;
-
-   val = intel_de_read(dev_priv, LPT_TRANSCONF);
-   val &= ~TRANS_ENABLE;
-   intel_de_write(dev_priv, LPT_TRANSCONF, val);
+   intel_de_rmw(dev_priv, LPT_TRANSCONF, TRANS_ENABLE, 0);
/* wait for PCH transcoder off, transcoder state */
if (intel_de_wait_for_clear(dev_priv, LPT_TRANSCONF,
TRANS_STATE_ENABLE, 50))
drm_err(_priv->drm, "Failed to disable PCH transcoder\n");
 
/* Workaround: clear timing override bit. */
-   val = intel_de_read(dev_priv, TRANS_CHICKEN2(PIPE_A));
-   val &= ~TRANS_CHICKEN2_TIMING_OVERRIDE;
-   intel_de_write(dev_priv, TRANS_CHICKEN2(PIPE_A), val);
+   intel_de_rmw(dev_priv, TRANS_CHICKEN2(PIPE_A), 
TRANS_CHICKEN2_TIMING_OVERRIDE, 0);
 }
 
 void lpt_pch_enable(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_pch_refclk.c 
b/drivers/gpu/drm/i915/display/intel_pch_refclk.c
index 08a94365b7d13b..6780c8fd9a1d31 100644
--- a/drivers/gpu/drm/i915/display/intel_pch_refclk.c
+++ b/drivers/gpu/drm/i915/display/intel_pch_refclk.c
@@ -12,19 +12,13 @@
 
 static void lpt_fdi_reset_mphy(struct drm_i915_private *dev_priv)
 {
-   u32 tmp;
-
-   tmp = intel_de_read(dev_priv, SOUTH_CHICKEN2);
-   tmp |= FDI_MPHY_IOSFSB_RESET_CTL;
-   intel_de_write(dev_priv, SOUTH_CHICKEN2, tmp);
+   intel_de_rmw(dev_priv, SOUTH_CHICKEN2, 0, FDI_MPHY_IOSFSB_RESET_CTL);
 
if (wait_for_us(intel_de_read(dev_priv, SOUTH_CHICKEN2) &
FDI_MPHY_IOSFSB_RESET_STATUS, 100))

[Intel-gfx] [PATCH v2 3/9] drm/i915/display/dpll: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 165 ++
 1 file changed, 53 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 1974eb580ed198..e9215ebcdfc44d 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -608,10 +608,8 @@ static void hsw_ddi_wrpll_disable(struct drm_i915_private 
*dev_priv,
  struct intel_shared_dpll *pll)
 {
const enum intel_dpll_id id = pll->info->id;
-   u32 val;
 
-   val = intel_de_read(dev_priv, WRPLL_CTL(id));
-   intel_de_write(dev_priv, WRPLL_CTL(id), val & ~WRPLL_PLL_ENABLE);
+   intel_de_rmw(dev_priv, WRPLL_CTL(id), WRPLL_PLL_ENABLE, 0);
intel_de_posting_read(dev_priv, WRPLL_CTL(id));
 
/*
@@ -626,10 +624,8 @@ static void hsw_ddi_spll_disable(struct drm_i915_private 
*dev_priv,
 struct intel_shared_dpll *pll)
 {
enum intel_dpll_id id = pll->info->id;
-   u32 val;
 
-   val = intel_de_read(dev_priv, SPLL_CTL);
-   intel_de_write(dev_priv, SPLL_CTL, val & ~SPLL_PLL_ENABLE);
+   intel_de_rmw(dev_priv, SPLL_CTL, SPLL_PLL_ENABLE, 0);
intel_de_posting_read(dev_priv, SPLL_CTL);
 
/*
@@ -1238,16 +1234,10 @@ static void skl_ddi_pll_write_ctrl1(struct 
drm_i915_private *dev_priv,
struct intel_shared_dpll *pll)
 {
const enum intel_dpll_id id = pll->info->id;
-   u32 val;
 
-   val = intel_de_read(dev_priv, DPLL_CTRL1);
-
-   val &= ~(DPLL_CTRL1_HDMI_MODE(id) |
-DPLL_CTRL1_SSC(id) |
-DPLL_CTRL1_LINK_RATE_MASK(id));
-   val |= pll->state.hw_state.ctrl1 << (id * 6);
-
-   intel_de_write(dev_priv, DPLL_CTRL1, val);
+   intel_de_rmw(dev_priv, DPLL_CTRL1,
+DPLL_CTRL1_HDMI_MODE(id) | DPLL_CTRL1_SSC(id) | 
DPLL_CTRL1_LINK_RATE_MASK(id),
+pll->state.hw_state.ctrl1 << (id * 6));
intel_de_posting_read(dev_priv, DPLL_CTRL1);
 }
 
@@ -1265,8 +1255,7 @@ static void skl_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
intel_de_posting_read(dev_priv, regs[id].cfgcr2);
 
/* the enable bit is always bit 31 */
-   intel_de_write(dev_priv, regs[id].ctl,
-  intel_de_read(dev_priv, regs[id].ctl) | 
LCPLL_PLL_ENABLE);
+   intel_de_rmw(dev_priv, regs[id].ctl, 0, LCPLL_PLL_ENABLE);
 
if (intel_de_wait_for_set(dev_priv, DPLL_STATUS, DPLL_LOCK(id), 5))
drm_err(_priv->drm, "DPLL %d not locked\n", id);
@@ -1285,8 +1274,7 @@ static void skl_ddi_pll_disable(struct drm_i915_private 
*dev_priv,
const enum intel_dpll_id id = pll->info->id;
 
/* the enable bit is always bit 31 */
-   intel_de_write(dev_priv, regs[id].ctl,
-  intel_de_read(dev_priv, regs[id].ctl) & 
~LCPLL_PLL_ENABLE);
+   intel_de_rmw(dev_priv, regs[id].ctl, LCPLL_PLL_ENABLE, 0);
intel_de_posting_read(dev_priv, regs[id].ctl);
 }
 
@@ -1902,14 +1890,11 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
bxt_port_to_phy_channel(dev_priv, port, , );
 
/* Non-SSC reference */
-   temp = intel_de_read(dev_priv, BXT_PORT_PLL_ENABLE(port));
-   temp |= PORT_PLL_REF_SEL;
-   intel_de_write(dev_priv, BXT_PORT_PLL_ENABLE(port), temp);
+   intel_de_rmw(dev_priv, BXT_PORT_PLL_ENABLE(port), 0, PORT_PLL_REF_SEL);
 
if (IS_GEMINILAKE(dev_priv)) {
-   temp = intel_de_read(dev_priv, BXT_PORT_PLL_ENABLE(port));
-   temp |= PORT_PLL_POWER_ENABLE;
-   intel_de_write(dev_priv, BXT_PORT_PLL_ENABLE(port), temp);
+   intel_de_rmw(dev_priv, BXT_PORT_PLL_ENABLE(port),
+0, PORT_PLL_POWER_ENABLE);
 
if (wait_for_us((intel_de_read(dev_priv, 
BXT_PORT_PLL_ENABLE(port)) &
 PORT_PLL_POWER_STATE), 200))
@@ -1918,39 +1903,28 @@ static void bxt_ddi_pll_enable(struct drm_i915_private 
*dev_priv,
}
 
/* Disable 10 bit clock */
-   temp = intel_de_read(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch));
-   temp &= ~PORT_PLL_10BIT_CLK_ENABLE;
-   intel_de_write(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch), temp);
+   intel_de_rmw(dev_priv, BXT_PORT_PLL_EBB_4(phy, ch),
+PORT_PLL_10BIT_CLK_ENABLE, 0);
 
/* Write P1 & P2 */
-   temp = intel_de_read(dev_priv, BXT_PORT_PLL_EBB_0(phy, ch));
-   temp &= ~(PORT_PLL_P1_MASK | PORT_PLL_P2_MASK);
-   temp |= pll->state.hw_state.ebb0;
-   intel_de_write(dev_priv, BXT_PORT_PLL_EBB_0(phy, ch), temp);
+   intel_de_rmw(dev_priv, BXT_PORT_PLL_EBB_0(phy, ch),
+PORT_PLL_P1_MASK | PORT_PLL_P2_MASK, 
pll->state.hw_state.ebb0);
 

[Intel-gfx] [PATCH v2 4/9] drm/i915/display/phys: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 .../gpu/drm/i915/display/intel_combo_phy.c| 43 +---
 drivers/gpu/drm/i915/display/intel_dpio_phy.c | 51 ++-
 2 files changed, 29 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c 
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 8b870b2dd4f9d9..27e98eabb0060a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -78,14 +78,11 @@ static void icl_set_procmon_ref_values(struct 
drm_i915_private *dev_priv,
   enum phy phy)
 {
const struct icl_procmon *procmon;
-   u32 val;
 
procmon = icl_get_procmon_ref_values(dev_priv, phy);
 
-   val = intel_de_read(dev_priv, ICL_PORT_COMP_DW1(phy));
-   val &= ~((0xff << 16) | 0xff);
-   val |= procmon->dw1;
-   intel_de_write(dev_priv, ICL_PORT_COMP_DW1(phy), val);
+   intel_de_rmw(dev_priv, ICL_PORT_COMP_DW1(phy),
+(0xff << 16) | 0xff, procmon->dw1);
 
intel_de_write(dev_priv, ICL_PORT_COMP_DW9(phy), procmon->dw9);
intel_de_write(dev_priv, ICL_PORT_COMP_DW10(phy), procmon->dw10);
@@ -267,7 +264,6 @@ void intel_combo_phy_power_up_lanes(struct drm_i915_private 
*dev_priv,
int lane_count, bool lane_reversal)
 {
u8 lane_mask;
-   u32 val;
 
if (is_dsi) {
drm_WARN_ON(_priv->drm, lane_reversal);
@@ -308,10 +304,8 @@ void intel_combo_phy_power_up_lanes(struct 
drm_i915_private *dev_priv,
}
}
 
-   val = intel_de_read(dev_priv, ICL_PORT_CL_DW10(phy));
-   val &= ~PWR_DOWN_LN_MASK;
-   val |= lane_mask;
-   intel_de_write(dev_priv, ICL_PORT_CL_DW10(phy), val);
+   intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy),
+PWR_DOWN_LN_MASK, lane_mask);
 }
 
 static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
@@ -366,19 +360,13 @@ static void icl_combo_phys_init(struct drm_i915_private 
*dev_priv)
 
icl_set_procmon_ref_values(dev_priv, phy);
 
-   if (phy_is_master(dev_priv, phy)) {
-   val = intel_de_read(dev_priv, ICL_PORT_COMP_DW8(phy));
-   val |= IREFGEN;
-   intel_de_write(dev_priv, ICL_PORT_COMP_DW8(phy), val);
-   }
-
-   val = intel_de_read(dev_priv, ICL_PORT_COMP_DW0(phy));
-   val |= COMP_INIT;
-   intel_de_write(dev_priv, ICL_PORT_COMP_DW0(phy), val);
+   if (phy_is_master(dev_priv, phy))
+   intel_de_rmw(dev_priv, ICL_PORT_COMP_DW8(phy),
+0, IREFGEN);
 
-   val = intel_de_read(dev_priv, ICL_PORT_CL_DW5(phy));
-   val |= CL_POWER_DOWN_ENABLE;
-   intel_de_write(dev_priv, ICL_PORT_CL_DW5(phy), val);
+   intel_de_rmw(dev_priv, ICL_PORT_COMP_DW0(phy), 0, COMP_INIT);
+   intel_de_rmw(dev_priv, ICL_PORT_CL_DW5(phy),
+0, CL_POWER_DOWN_ENABLE);
}
 }
 
@@ -387,8 +375,6 @@ static void icl_combo_phys_uninit(struct drm_i915_private 
*dev_priv)
enum phy phy;
 
for_each_combo_phy_reverse(dev_priv, phy) {
-   u32 val;
-
if (phy == PHY_A &&
!icl_combo_phy_verify_state(dev_priv, phy)) {
if (IS_TIGERLAKE(dev_priv) || IS_DG1(dev_priv)) {
@@ -410,14 +396,11 @@ static void icl_combo_phys_uninit(struct drm_i915_private 
*dev_priv)
if (!has_phy_misc(dev_priv, phy))
goto skip_phy_misc;
 
-   val = intel_de_read(dev_priv, ICL_PHY_MISC(phy));
-   val |= ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
-   intel_de_write(dev_priv, ICL_PHY_MISC(phy), val);
+   intel_de_rmw(dev_priv, ICL_PHY_MISC(phy), 0,
+ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN);
 
 skip_phy_misc:
-   val = intel_de_read(dev_priv, ICL_PORT_COMP_DW0(phy));
-   val &= ~COMP_INIT;
-   intel_de_write(dev_priv, ICL_PORT_COMP_DW0(phy), val);
+   intel_de_rmw(dev_priv, ICL_PORT_COMP_DW0(phy), COMP_INIT, 0);
}
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
index 7eb7440b31803f..9d825fdaa29055 100644
--- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
@@ -389,9 +389,7 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
"force reprogramming it\n", phy);
}
 
-   val = intel_de_read(dev_priv, BXT_P_CR_GT_DISP_PWRON);
-   val |= phy_info->pwron_mask;
-   intel_de_write(dev_priv, BXT_P_CR_GT_DISP_PWRON, val);
+   intel_de_rmw(dev_priv, BXT_P_CR_GT_DISP_PWRON, 0, 

[Intel-gfx] [PATCH v2 1/9] drm/i915/display/core: use intel_de_rmw if possible

[Andrzej Hajda]

The helper makes the code more compact and readable.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 22 ---
 .../drm/i915/display/intel_modeset_setup.c| 17 ++
 2 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e75b9b2a0e015a..ce506c9fd6ab9f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -293,11 +293,11 @@ static void
 skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
 {
if (enable)
-   intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
+0, DUPS1_GATING_DIS | DUPS2_GATING_DIS);
else
-   intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe),
+DUPS1_GATING_DIS | DUPS2_GATING_DIS, 0);
 }
 
 /* Wa_2006604312:icl,ehl */
@@ -306,11 +306,9 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, 
enum pipe pipe,
   bool enable)
 {
if (enable)
-   intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
DPFR_GATING_DIS);
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), 0, 
DPFR_GATING_DIS);
else
-   intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~DPFR_GATING_DIS);
+   intel_de_rmw(dev_priv, CLKGATE_DIS_PSL(pipe), DPFR_GATING_DIS, 
0);
 }
 
 /* Wa_1604331009:icl,jsl,ehl */
@@ -1852,12 +1850,10 @@ static void hsw_set_frame_start_delay(const struct 
intel_crtc_state *crtc_state)
enum transcoder transcoder = crtc_state->cpu_transcoder;
i915_reg_t reg = DISPLAY_VER(dev_priv) >= 14 ? 
MTL_CHICKEN_TRANS(transcoder) :
 CHICKEN_TRANS(transcoder);
-   u32 val;
 
-   val = intel_de_read(dev_priv, reg);
-   val &= ~HSW_FRAME_START_DELAY_MASK;
-   val |= HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1);
-   intel_de_write(dev_priv, reg, val);
+   intel_de_rmw(dev_priv, reg,
+HSW_FRAME_START_DELAY_MASK,
+HSW_FRAME_START_DELAY(crtc_state->framestart_delay - 1));
 }
 
 static void icl_ddi_bigjoiner_pre_enable(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c 
b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index 96395bfbd41dfb..6f6dc7c6b88b0c 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -647,17 +647,14 @@ static void intel_early_display_was(struct 
drm_i915_private *i915)
 * Also known as Wa_14010480278.
 */
if (IS_DISPLAY_VER(i915, 10, 12))
-   intel_de_write(i915, GEN9_CLKGATE_DIS_0,
-  intel_de_read(i915, GEN9_CLKGATE_DIS_0) | 
DARBF_GATING_DIS);
+   intel_de_rmw(i915, GEN9_CLKGATE_DIS_0, 0, DARBF_GATING_DIS);
 
-   if (IS_HASWELL(i915)) {
-   /*
-* WaRsPkgCStateDisplayPMReq:hsw
-* System hang if this isn't done before disabling all planes!
-*/
-   intel_de_write(i915, CHICKEN_PAR1_1,
-  intel_de_read(i915, CHICKEN_PAR1_1) | 
FORCE_ARB_IDLE_PLANES);
-   }
+   /*
+* WaRsPkgCStateDisplayPMReq:hsw
+* System hang if this isn't done before disabling all planes!
+*/
+   if (IS_HASWELL(i915))
+   intel_de_rmw(i915, CHICKEN_PAR1_1, 0, FORCE_ARB_IDLE_PLANES);
 
if (IS_KABYLAKE(i915) || IS_COFFEELAKE(i915) || IS_COMETLAKE(i915)) {
/* Display WA #1142:kbl,cfl,cml */
-- 
2.34.1

Re: [Intel-gfx] [PULL] gvt-fixes

[Rodrigo Vivi]

On Thu, Jan 05, 2023 at 08:15:28AM +0800, Zhenyu Wang wrote:
> On 2023.01.04 06:34:28 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 04, 2023 at 04:05:13PM +0800, Zhenyu Wang wrote:
> > > 
> > > Hi,
> > > 
> > > Here's accumulated current gvt-fixes. Several of them handle
> > > for error or destroy path issues and one from Zhi to fix up
> > > left vgpu status tracking.
> > > 
> > > thanks!
> > > ---
> > > The following changes since commit 
> > > 6217e9f05a74df48c77ee68993d587cdfdb1feb7:
> > 
> > I'm kind of confused on your baseline here.
> > 
> > It is including a strange merge commit in the middle of the commits:
> > Zhenyu Wang   ??? M?? Merge tag 'drm-intel-fixes-2022-12-30' into 
> > gvt-fixes
> > commit c063c8c07864246ba3831b017cea8d3096e236a8
> > 
> > Please rebase on top of v6.2-rc2 so we have the same base here.
> > (and please remind to sign-off-by when pushing the commits)
> > 
> 
> oh, I tried to sycn up by back merge with vfio iommufd of gvt changes
> to apply Zhi's patch properly, so it should stand on that tag..but anyway

I'd say for the fixes branches probably a rebase is better than back merges.
Keep the rebase in sync with -rc tags is probably the best way. or rebase
on drm-intel-fixes.

> I just refresh with rebase and fixed two invalid r-b tags. Please pull
> below one.

pulled. Thanks

> 
> thanks!
> ---
> The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:
> 
>   Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-fixes-2023-01-05
> 
> for you to fetch changes up to 4a61648af68f5ba4884f0e3b494ee1cabc4b6620:
> 
>   drm/i915/gvt: fix double free bug in split_2MB_gtt_entry (2023-01-04 
> 23:21:19 +0800)
> 
> 
> gvt-fixes-2023-01-05
> 
> - Fix one missed unpin in error of intel_vgpu_shadow_mm_pin()
> - Fix two debugfs destroy oops issues for vgpu and gvt entries
> - Fix one potential double free issue in gtt shadow pt code
> - Fix to use atomic bit flag for vgpu status
> 
> 
> Dan Carpenter (1):
>   drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()
> 
> Zheng Wang (1):
>   drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
> 
> Zhenyu Wang (2):
>   drm/i915/gvt: fix gvt debugfs destroy
>   drm/i915/gvt: fix vgpu debugfs clean in remove
> 
> Zhi Wang (1):
>   drm/i915/gvt: use atomic operations to change the vGPU status
> 
>  drivers/gpu/drm/i915/gvt/debugfs.c   | 36 
> +++-
>  drivers/gpu/drm/i915/gvt/dmabuf.c|  3 ++-
>  drivers/gpu/drm/i915/gvt/gtt.c   | 21 +++--
>  drivers/gpu/drm/i915/gvt/gvt.h   | 15 ++-
>  drivers/gpu/drm/i915/gvt/interrupt.c |  2 +-
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 35 +--
>  drivers/gpu/drm/i915/gvt/scheduler.c |  4 +++-
>  drivers/gpu/drm/i915/gvt/vgpu.c  | 12 +---
>  8 files changed, 80 insertions(+), 48 deletions(-)

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate TLB invalidation flow

[Tvrtko Ursulin]

On 04/01/2023 17:41, Matt Roper wrote:

On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:


On 03/01/2023 19:57, Matt Roper wrote:

On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:

On 19.12.2022 11:13, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

As the logic for selecting the register and corresponsing values grew, the


corresponding


code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each and every TLB
invalidation.

v2:
* Fail engine probe if TLB invlidations registers are unknown.

Signed-off-by: Tvrtko Ursulin 
Cc: Andrzej Hajda 
Cc: Matt Roper 
Reviewed-by: Andrzej Hajda  # v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c|  93 +
drivers/gpu/drm/i915/gt/intel_engine_types.h |  15 +++
drivers/gpu/drm/i915/gt/intel_gt.c   | 135 +++
3 files changed, 128 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 99c4b866addd..d47dadfc25c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1143,12 +1143,105 @@ static int init_status_page(struct intel_engine_cs 
*engine)
return ret;
}
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine)
+{
+   static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+   [RENDER_CLASS].reg  = GEN8_RTCR,
+   [VIDEO_DECODE_CLASS].reg= GEN8_M1TCR, /* , GEN8_M2TCR */
+   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN8_VTCR,
+   [COPY_ENGINE_CLASS].reg = GEN8_BTCR,
+   };
+   static const union intel_engine_tlb_inv_reg gen12_regs[] = {
+   [RENDER_CLASS].reg  = GEN12_GFX_TLB_INV_CR,
+   [VIDEO_DECODE_CLASS].reg= GEN12_VD_TLB_INV_CR,
+   [VIDEO_ENHANCEMENT_CLASS].reg   = GEN12_VE_TLB_INV_CR,
+   [COPY_ENGINE_CLASS].reg = GEN12_BLT_TLB_INV_CR,
+   [COMPUTE_CLASS].reg = GEN12_COMPCTX_TLB_INV_CR,
+   };
+   static const union intel_engine_tlb_inv_reg xehp_regs[] = {
+   [RENDER_CLASS].mcr_reg= XEHP_GFX_TLB_INV_CR,
+   [VIDEO_DECODE_CLASS].mcr_reg  = XEHP_VD_TLB_INV_CR,
+   [VIDEO_ENHANCEMENT_CLASS].mcr_reg = XEHP_VE_TLB_INV_CR,
+   [COPY_ENGINE_CLASS].mcr_reg   = XEHP_BLT_TLB_INV_CR,
+   [COMPUTE_CLASS].mcr_reg   = XEHP_COMPCTX_TLB_INV_CR,
+   };
+   struct drm_i915_private *i915 = engine->i915;
+   const union intel_engine_tlb_inv_reg *regs;
+   union intel_engine_tlb_inv_reg reg;
+   unsigned int class = engine->class;
+   unsigned int num = 0;
+   u32 val;
+
+   /*
+* New platforms should not be added with catch-all-newer (>=)
+* condition so that any later platform added triggers the below warning
+* and in turn mandates a human cross-check of whether the invalidation
+* flows have compatible semantics.
+*
+* For instance with the 11.00 -> 12.00 transition three out of five
+* respective engine registers were moved to masked type. Then after the
+* 12.00 -> 12.50 transition multi cast handling is required too.
+*/
+
+   if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50)) {


This is bad...it only captures XEHPSDV and breaks the handling of DG2
(12.55), PVC (12.60), and MTL (12.70, 12.71, and 12.72).  You're not
hitting the warning as expected since those are all now being captured
by the next case of the if/else ladder.  With the way GMD_ID works, we
may also get new version numbers that silently show up in hardware too
at some point (e.g., 12.73, 12.74, etc.)


Great (on multiple counts) ...




+   regs = xehp_regs;
+   num = ARRAY_SIZE(xehp_regs);
+   } else if (GRAPHICS_VER(i915) == 12) {


You'd want to change this to

  GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)

to get the behavior you expected.


Okay, that, and then to be as safe as I intended, ie. warn on every new
platforms so developers *must* check registers are still compatible during
platform enablement, we would need a full ver range check something like:

if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50) &&
GRAPHICS_VER_FULL(i915) <= IP_VER(12, 55)) {
regs = xehp_regs;
num = ARRAY_SIZE(xehp_regs);
} else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0)) {
regs = gen12_regs;
num = ARRAY_SIZE(gen12_regs);

What do you think about that?


What about just keeping the code the way it is now, but adding a new
error condition at the *top* of the ladder?

 if (GRAPHICS_VER_FULL(i915) > IP_VER(12, 72)) {
 

Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg

[Daniel Vetter]

On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
> From: Andrzej Hajda 
> > Sent: 09 December 2022 15:49
> > 
> > The pattern of setting variable with new value and returning old
> > one is very common in kernel. Usually atomicity of the operation
> > is not required, so xchg seems to be suboptimal and confusing in
> > such cases. Since name xchg is already in use and __xchg is used
> > in architecture code, proposition is to name the macro exchange.
> 
> Dunno, if it is non-atomic then two separate assignment statements
> is decidedly more obvious and needs less brain cells to process.
> Otherwise someone will assume 'something clever' is going on
> and the operation is atomic.

Yes, this also my take. The i915 code that uses this to excess is decidely
unreadable imo, and the macro should simply be replaced by open-coded
versions.

Not moved into shared headers where even more people can play funny games
with it.

I think swap() is a standard idiom in C, this one here just isn't.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v2 21/21] drm/i915/mtl: Pin assignment for TypeC

[Mika Kahola]

From: Anusha Srivatsa 

Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.

Bspec: 50235, 65380
Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Matt Roper 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Jose Roberto de Souza 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-21-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_tc.c | 30 +
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index de851fddb255..e7d5301fc35e 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -15,6 +15,10 @@
 #include "intel_mg_phy_regs.h"
 #include "intel_tc.h"
 
+#define DP_PIN_ASSIGNMENT_C0x3
+#define DP_PIN_ASSIGNMENT_D0x4
+#define DP_PIN_ASSIGNMENT_E0x5
+
 static const char *tc_port_mode_name(enum tc_port_mode mode)
 {
static const char * const names[] = {
@@ -147,6 +151,29 @@ u32 intel_tc_port_get_pin_assignment_mask(struct 
intel_digital_port *dig_port)
   DP_PIN_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
 }
 
+static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port 
*dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   intel_wakeref_t wakeref;
+   u32 pin_mask;
+
+   assert_tc_cold_blocked(dig_port);
+
+   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
+   pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
+
+   switch(pin_mask) {
+   default:
+   MISSING_CASE(pin_mask);
+   fallthrough;
+   case DP_PIN_ASSIGNMENT_D:
+   return 2;
+   case DP_PIN_ASSIGNMENT_C:
+   case DP_PIN_ASSIGNMENT_E:
+   return 4;
+   }
+}
+
 int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -156,6 +183,9 @@ int intel_tc_port_fia_max_lane_count(struct 
intel_digital_port *dig_port)
if (dig_port->tc_mode != TC_PORT_DP_ALT)
return 4;
 
+   if (DISPLAY_VER(i915) >= 14)
+   return mtl_tc_port_get_pin_assignment_mask(dig_port);
+
assert_tc_cold_blocked(dig_port);
 
lane_mask = 0;
-- 
2.34.1

[Intel-gfx] [PATCH v2 20/21] drm/i915/mtl: TypeC HPD live status query

[Mika Kahola]

From: Imre Deak 

The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing  HPD live status detection

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Imre Deak 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 30 +
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index 74d8d8e0e0df..de851fddb255 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -297,10 +297,40 @@ static u32 adl_tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
return mask;
 }
 
+static u32 xelpdp_tc_port_live_status_mask(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
+   u32 isr_bit = i915->display.hotplug.pch_hpd[dig_port->base.hpd_pin];
+   struct intel_uncore *uncore = >uncore;
+   u32 val, mask = 0;
+   enum hpd_pin pin;
+
+   val = intel_uncore_read(uncore, PICAINTERRUPT_ISR);
+   pin = HPD_PORT_TC1 + tc_port - TC_PORT_1;
+   if (val & XELPDP_DP_ALT_HOTPLUG(pin))
+   mask |= BIT(TC_PORT_DP_ALT);
+   if (val & XELPDP_TBT_HOTPLUG(pin))
+   mask |= BIT(TC_PORT_TBT_ALT);
+
+   if (dig_port->tc_legacy_port &&
+   intel_uncore_read(uncore, SDEISR) & isr_bit)
+   mask |= BIT(TC_PORT_LEGACY);
+
+   /* The sink can be connected only in a single mode. */
+   if (!drm_WARN_ON(>drm, hweight32(mask) > 1))
+   tc_port_fixup_legacy_flag(dig_port, mask);
+
+   return mask;
+}
+
 static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
+   if (DISPLAY_VER(i915) >= 14)
+   return xelpdp_tc_port_live_status_mask(dig_port);
+
if (DISPLAY_VER(i915) >= 13)
return adl_tc_port_live_status_mask(dig_port);
 
-- 
2.34.1

[Intel-gfx] [PATCH v2 19/21] drm/i915/mtl: Power up TCSS

[Mika Kahola]

Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.

In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.

v2: Call tcss power request with correct parameter.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-20-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_display.c |   2 +-
 drivers/gpu/drm/i915/display/intel_tc.c  | 117 ++-
 2 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 302c795c2e3f..75fcc0ef5ced 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2119,7 +2119,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv, 
enum phy phy)
if (IS_DG2(dev_priv))
/* DG2's "TC1" output uses a SNPS PHY */
return false;
-   else if (IS_ALDERLAKE_P(dev_priv))
+   else if (IS_ALDERLAKE_P(dev_priv) || IS_METEORLAKE(dev_priv))
return phy >= PHY_F && phy <= PHY_I;
else if (IS_TIGERLAKE(dev_priv))
return phy >= PHY_D && phy <= PHY_I;
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
b/drivers/gpu/drm/i915/display/intel_tc.c
index f45328712bff..74d8d8e0e0df 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -5,6 +5,7 @@
 
 #include "i915_drv.h"
 #include "i915_reg.h"
+#include "intel_cx0_phy_regs.h"
 #include "intel_de.h"
 #include "intel_display.h"
 #include "intel_display_power_map.h"
@@ -300,7 +301,7 @@ static u32 tc_port_live_status_mask(struct 
intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
-   if (IS_ALDERLAKE_P(i915))
+   if (DISPLAY_VER(i915) >= 13)
return adl_tc_port_live_status_mask(dig_port);
 
return icl_tc_port_live_status_mask(dig_port);
@@ -354,11 +355,69 @@ static bool adl_tc_phy_status_complete(struct 
intel_digital_port *dig_port)
return val & TCSS_DDI_STATUS_READY;
 }
 
+static bool xelpdp_wait_phy_status_complete(struct intel_digital_port 
*dig_port)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
+
+   if (intel_wait_for_register(>uncore,
+   TCSS_DDI_STATUS(tc_port),
+   TCSS_DDI_STATUS_READY,
+   TCSS_DDI_STATUS_READY,
+   1)) {
+   drm_dbg_kms(>drm,
+   "Port %s: PHY in TCCOLD, assuming not complete\n",
+   dig_port->tc_port_name);
+   return false;
+   }
+
+   return true;
+}
+
+static bool xelpdp_wait_for_tcss_power(struct intel_digital_port *dig_port,
+  bool enabled)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+
+   if (intel_wait_for_register(>uncore,
+   XELPDP_PORT_BUF_CTL1(dig_port->base.port),
+   XELPDP_TCSS_POWER_STATE,
+   enabled ? XELPDP_TCSS_POWER_STATE : 0,
+   5)) {
+   drm_dbg_kms(>drm,
+   "Port %s: TCSS power state not as expected\n",
+   dig_port->tc_port_name);
+   return false;
+   }
+
+   return true;
+}
+
+static bool xelpdp_tc_power_request(struct intel_digital_port *dig_port, bool 
request)
+{
+   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+   struct intel_uncore *uncore = >uncore;
+   enum port port = dig_port->base.port;
+   u32 val;
+
+   val = intel_uncore_read(uncore, XELPDP_PORT_BUF_CTL1(port));
+   if (request)
+   val |= XELPDP_TCSS_POWER_REQUEST;
+   else
+   val &= ~XELPDP_TCSS_POWER_REQUEST;
+   intel_uncore_write(uncore, XELPDP_PORT_BUF_CTL1(port), val);
+
+   return xelpdp_wait_phy_status_complete(dig_port) &&
+  xelpdp_wait_for_tcss_power(dig_port, request);
+}
+
 static bool tc_phy_status_complete(struct intel_digital_port *dig_port)
 {
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
-   if (IS_ALDERLAKE_P(i915))
+   if (DISPLAY_VER(i915) >= 14)
+   return xelpdp_wait_phy_status_complete(dig_port);
+   else if (IS_ALDERLAKE_P(i915))
return adl_tc_phy_status_complete(dig_port);
 
return icl_tc_phy_status_complete(dig_port);
@@ -400,11 +459,31 @@ static bool adl_tc_phy_take_ownership(struct 
intel_digital_port *dig_port,
 

[Intel-gfx] [PATCH v2 18/21] drm/i915/mtl: Define mask for DDI AUX interrupts

[Mika Kahola]

From: Gustavo Sousa 

Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port
Interrupt registers. The bits for Type-C ports are defined in the PICA
interrupt registers.

BSpec: 50064
Signed-off-by: Gustavo Sousa 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-19-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 66df94ae8063..11ebdbef1832 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2340,7 +2340,10 @@ static u32 gen8_de_port_aux_mask(struct drm_i915_private 
*dev_priv)
 {
u32 mask;
 
-   if (DISPLAY_VER(dev_priv) >= 13)
+   if (DISPLAY_VER(dev_priv) >= 14)
+   return TGL_DE_PORT_AUX_DDIA |
+   TGL_DE_PORT_AUX_DDIB;
+   else if (DISPLAY_VER(dev_priv) >= 13)
return TGL_DE_PORT_AUX_DDIA |
TGL_DE_PORT_AUX_DDIB |
TGL_DE_PORT_AUX_DDIC |
-- 
2.34.1

[Intel-gfx] [PATCH v2 17/21] drm/i915/mtl: MTL PICA hotplug detection

[Mika Kahola]

PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed
from PICA chip to south display engine and from there to north display
engine. This patch adds functionality to enable hotplug detection for
all Type-C ports (4 ports available).

Differently from HPD in south display, PICA provides a dedicated HPD
control register for each supported port, so we loop over ports
ourselves instead of using intel_hpd_hotplug_enables() or
intel_get_hpd_pins().

BSpec: 49305, 55726, 65107, 65300

Signed-off-by: Mika Kahola 
Signed-off-by: Madhumitha Tolakanahalli Pradeep 

Signed-off-by: Gustavo Sousa 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-18-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/i915_irq.c | 226 +++-
 drivers/gpu/drm/i915/i915_reg.h |  31 -
 2 files changed, 252 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 15dfef6d93a9..66df94ae8063 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -162,6 +162,13 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
[HPD_PORT_TC6] = GEN11_TC_HOTPLUG(HPD_PORT_TC6) | 
GEN11_TBT_HOTPLUG(HPD_PORT_TC6),
 };
 
+static const u32 hpd_xelpdp[HPD_NUM_PINS] = {
+   [HPD_PORT_TC1] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC1) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC1),
+   [HPD_PORT_TC2] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC2) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC2),
+   [HPD_PORT_TC3] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC3) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC3),
+   [HPD_PORT_TC4] = XELPDP_TBT_HOTPLUG(HPD_PORT_TC4) | 
XELPDP_DP_ALT_HOTPLUG(HPD_PORT_TC4),
+};
+
 static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_A),
[HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
@@ -182,6 +189,16 @@ static const u32 hpd_sde_dg1[HPD_NUM_PINS] = {
[HPD_PORT_TC1] = SDE_TC_HOTPLUG_DG2(HPD_PORT_TC1),
 };
 
+static const u32 hpd_mtp[HPD_NUM_PINS] = {
+   [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_A),
+   [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
+   [HPD_PORT_TC1] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC1),
+   [HPD_PORT_TC2] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC2),
+   [HPD_PORT_TC3] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC3),
+   [HPD_PORT_TC4] = SDE_TC_HOTPLUG_ICP(HPD_PORT_TC4),
+};
+
+
 static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
 {
struct intel_hotplug *hpd = _priv->display.hotplug;
@@ -195,7 +212,9 @@ static void intel_hpd_init_pins(struct drm_i915_private 
*dev_priv)
return;
}
 
-   if (DISPLAY_VER(dev_priv) >= 11)
+   if (DISPLAY_VER(dev_priv) >= 14)
+   hpd->hpd = hpd_xelpdp;
+   else if (DISPLAY_VER(dev_priv) >= 11)
hpd->hpd = hpd_gen11;
else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
hpd->hpd = hpd_bxt;
@@ -212,6 +231,8 @@ static void intel_hpd_init_pins(struct drm_i915_private 
*dev_priv)
 
if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
hpd->pch_hpd = hpd_sde_dg1;
+   else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP)
+   hpd->pch_hpd = hpd_mtp;
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
hpd->pch_hpd = hpd_icp;
else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_SPT(dev_priv))
@@ -1965,6 +1986,44 @@ static void cpt_irq_handler(struct drm_i915_private 
*dev_priv, u32 pch_iir)
cpt_serr_int_handler(dev_priv);
 }
 
+static void xelpdp_pica_hpd_irq_handler(struct drm_i915_private *dev_priv, u32 
iir)
+{
+   enum hpd_pin pin;
+   u32 hotplug_trigger = iir & (XELPDP_DP_ALT_HOTPLUG_MASK | 
XELPDP_TBT_HOTPLUG_MASK);
+   u32 trigger_aux = iir & XELPDP_AUX_TC_MASK;
+   u32 pin_mask = 0, long_mask = 0;
+
+   for (pin = HPD_PORT_TC1; pin <= HPD_PORT_TC4; pin++) {
+   u32 val;
+
+   if (!(dev_priv->display.hotplug.hpd[pin] & hotplug_trigger))
+   continue;
+
+   pin_mask |= BIT(pin);
+
+   val = intel_uncore_read(_priv->uncore, 
XELPDP_PORT_HOTPLUG_CTL(pin));
+   intel_uncore_write(_priv->uncore, 
XELPDP_PORT_HOTPLUG_CTL(pin), val);
+
+   if (val & (XELPDP_DP_ALT_HPD_LONG_DETECT | 
XELPDP_TBT_HPD_LONG_DETECT))
+   long_mask |= BIT(pin);
+   }
+
+   if (pin_mask) {
+   drm_dbg(_priv->drm,
+   "pica hotplug event received, stat 0x%08x, pins 0x%08x, 
long 0x%08x\n",
+   hotplug_trigger, pin_mask, long_mask);
+
+   intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
+   }
+
+   if (trigger_aux)
+   dp_aux_irq_handler(dev_priv);
+
+   if (!pin_mask && !trigger_aux)
+   drm_err(_priv->drm,
+   "Unexpected DE HPD/AUX interrupt 0x%08x\n", iir);
+}
+
 static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 

[Intel-gfx] [PATCH v2 16/21] drm/i915/mtl: Enable TC ports

[Mika Kahola]

Finally, we can enable TC ports for Meteorlake.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-17-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_display.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 87cd6a808938..302c795c2e3f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7885,9 +7885,12 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
return;
 
if (IS_METEORLAKE(dev_priv)) {
-   /* TODO: initialize TC ports as well */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+   intel_ddi_init(dev_priv, PORT_TC1);
+   intel_ddi_init(dev_priv, PORT_TC2);
+   intel_ddi_init(dev_priv, PORT_TC3);
+   intel_ddi_init(dev_priv, PORT_TC4);
} else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
-- 
2.34.1

[Intel-gfx] [PATCH v2 15/21] drm/i915/mtl: Readout Thunderbolt HW state

[Mika Kahola]

Readout hw state for Thunderbolt.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-16-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 27 
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  2 +-
 drivers/gpu/drm/i915/display/intel_ddi.c |  5 +++-
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 9218f99bca4e..c4905bd32900 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2439,6 +2439,33 @@ static void intel_cx0pll_enable(struct intel_encoder 
*encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   u32 clock;
+   u32 val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+   clock = REG_FIELD_GET(XELPDP_DDI_CLOCK_SELECT_MASK, val);
+
+   drm_WARN_ON(>drm, !(val & XELPDP_FORWARD_CLOCK_UNGATE));
+   drm_WARN_ON(>drm, !(val & XELPDP_TBT_CLOCK_REQUEST));
+   drm_WARN_ON(>drm, !(val & XELPDP_TBT_CLOCK_ACK));
+
+   switch (clock) {
+   case XELPDP_DDI_CLOCK_SELECT_TBT_162:
+   return 162000;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_270:
+   return 27;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_540:
+   return 54;
+   case XELPDP_DDI_CLOCK_SELECT_TBT_810:
+   return 81;
+   default:
+   MISSING_CASE(clock);
+   return 162000;
+   }
+}
+
 static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
 {
switch (clock) {
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 141802038f12..97a3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -53,5 +53,5 @@ int intel_c20_phy_check_hdmi_link_rate(int clock);
 void intel_cx0_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
   const struct intel_crtc_state 
*crtc_state,
   u32 level);
-int intel_mtl_tbt_readout_hw_state(struct intel_encoder *encoder);
+int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder);
 #endif /* __INTEL_CX0_PHY_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c2b9a2053732..4a70e76e7328 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3531,8 +3531,11 @@ static void mtl_ddi_get_config(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
 
-   if (intel_is_c10phy(i915, phy)) {
+   if (intel_tc_port_in_tbt_alt_mode(dig_port)) {
+   crtc_state->port_clock = intel_mtl_tbt_calc_port_clock(encoder);
+   } else if (intel_is_c10phy(i915, phy)) {
intel_c10mpllb_readout_hw_state(encoder, 
_state->cx0pll_state.c10mpllb_state);
intel_c10mpllb_dump_hw_state(i915, 
_state->cx0pll_state.c10mpllb_state);
crtc_state->port_clock = 
intel_c10mpllb_calc_port_clock(encoder, 
_state->cx0pll_state.c10mpllb_state);
-- 
2.34.1

[Intel-gfx] [PATCH v2 12/21] drm/i915/mtl: Add voltage swing sequence for C20

[Mika Kahola]

DP1.4 and DP20 voltage swing sequence for C20 phy.

Bspec: 65449, 67636, 67610

v2: DP2.0 Tx Eq tables has been updated in BSpec.
Update also the driver code as per BSpec 65449

Signed-off-by: Mika Kahola 
Signed-off-by: Radhakrishna Sripada 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-13-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 31 -
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  4 +++
 .../drm/i915/display/intel_ddi_buf_trans.c| 33 +--
 3 files changed, 58 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index e5542fb209ab..7520f50d4ffc 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -342,14 +342,29 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder 
*encoder,
lane = ln / 2 + 1;
tx = ln % 2 + 1;
 
-   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
2),
- C10_PHY_VSWING_PREEMPH_MASK,
- 
C10_PHY_VSWING_PREEMPH(trans->entries[level].direct.preemph),
- MB_WRITE_COMMITTED);
-   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
8),
- C10_PHY_VSWING_LEVEL_MASK,
- 
C10_PHY_VSWING_LEVEL(trans->entries[level].direct.level),
- MB_WRITE_COMMITTED);
+   if (crtc_state->port_clock > 100) {
+   intel_cx0_rmw(i915, encoder->port, lane, 
PHY_CX0_TX_CONTROL(tx, 2),
+ C20_PHY_VSWING_PREEMPH_MASK,
+ 
C20_PHY_VSWING_PREEMPH(trans->entries[level].snps.pre_cursor),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, 
PHY_CX0_TX_CONTROL(tx, 3),
+ C20_PHY_VSWING_PREEMPH_MASK,
+ 
C20_PHY_VSWING_PREEMPH(trans->entries[level].snps.vswing),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, 
PHY_CX0_TX_CONTROL(tx, 4),
+ C20_PHY_VSWING_PREEMPH_MASK,
+ 
C20_PHY_VSWING_PREEMPH(trans->entries[level].snps.post_cursor),
+ MB_WRITE_COMMITTED);
+   } else {
+   intel_cx0_rmw(i915, encoder->port, lane, 
PHY_CX0_TX_CONTROL(tx, 2),
+ C10_PHY_VSWING_PREEMPH_MASK,
+ 
C10_PHY_VSWING_PREEMPH(trans->entries[level].direct.preemph),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, 
PHY_CX0_TX_CONTROL(tx, 8),
+ C10_PHY_VSWING_LEVEL_MASK,
+ 
C10_PHY_VSWING_LEVEL(trans->entries[level].direct.level),
+ MB_WRITE_COMMITTED);
+   }
}
 
intel_cx0_write(i915, encoder->port, follower_lane, 
PHY_C10_VDR_CONTROL(1),
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index 794372f4798d..9c32152a3d10 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -203,6 +203,10 @@
 #define C20_MPLLB_TX_CLK_DIV_MASK  REG_GENMASK(15, 13)
 #define C20_MPLLA_TX_CLK_DIV_MASK  REG_GENMASK(10, 8)
 
+/* C20 Phy VSwing Masks */
+#define C20_PHY_VSWING_PREEMPH_MASKREG_GENMASK8(5, 0)
+#define C20_PHY_VSWING_PREEMPH(val)
REG_FIELD_PREP8(C20_PHY_VSWING_PREEMPH_MASK, val)
+
 #define RAWLANEAONX_DIG_TX_MPLLB_CAL_DONE_BANK(idx)(0x303D + (idx))
 
 #endif /* __INTEL_CX0_PHY_REGS_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
index ca2acaa73a64..4f4a8d3712a6 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
@@ -9,6 +9,7 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
+#include "intel_cx0_phy.h"
 
 /* HDMI/DVI modes ignore everything but the last 2 items. So we share
  * them for both DP and FDI transports, allowing those ports to
@@ -1053,12 +1054,37 @@ static const union intel_ddi_buf_trans_entry 
direct_map_trans[] = {
 { .direct = { .level = 3, .preemph = 0 } },
 };
 
-static const struct intel_ddi_buf_trans mtl_cx0c10_trans = {
+static const struct intel_ddi_buf_trans mtl_cx0_trans = {
.entries = direct_map_trans,
.num_entries = ARRAY_SIZE(direct_map_trans),
.hdmi_default_entry = 

[Intel-gfx] [PATCH v2 14/21] drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll

[Mika Kahola]

Enabling and disabling sequence for Thunderbolt PLL.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-15-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 137 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   7 +-
 drivers/gpu/drm/i915/display/intel_ddi.c |   4 +-
 3 files changed, 139 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 67e8889aec29..9218f99bca4e 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -14,8 +14,8 @@
 #include "intel_hdmi.h"
 #include "intel_panel.h"
 #include "intel_psr.h"
-#include "intel_uncore.h"
 #include "intel_tc.h"
+#include "intel_uncore.h"
 
 bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
 {
@@ -2365,8 +2365,8 @@ static u32 intel_cx0_get_pclk_pll_ack(u8 lane)
   XELPDP_LANE1_PCLK_PLL_ACK;
 }
 
-void intel_cx0pll_enable(struct intel_encoder *encoder,
-const struct intel_crtc_state *crtc_state)
+static void intel_cx0pll_enable(struct intel_encoder *encoder,
+   const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
@@ -2439,7 +2439,86 @@ void intel_cx0pll_enable(struct intel_encoder *encoder,
intel_cx0_phy_transaction_end(encoder, wakeref);
 }
 
-void intel_cx0pll_disable(struct intel_encoder *encoder)
+static int intel_mtl_tbt_clock_select(struct drm_i915_private *i915, int clock)
+{
+   switch (clock) {
+   case 162000:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+   case 27:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_270;
+   case 54:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_540;
+   case 81:
+   return XELPDP_DDI_CLOCK_SELECT_TBT_810;
+   default:
+   MISSING_CASE(clock);
+   return XELPDP_DDI_CLOCK_SELECT_TBT_162;
+   }
+}
+
+static void intel_mtl_tbt_pll_enable(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
+   u32 val = 0;
+
+   /*
+* 1. Program PORT_CLOCK_CTL REGISTER to configure
+* clock muxes, gating and SSC
+*/
+   val |= XELPDP_DDI_CLOCK_SELECT(intel_mtl_tbt_clock_select(i915, 
crtc_state->port_clock));
+   val |= XELPDP_FORWARD_CLOCK_UNGATE;
+   intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
+XELPDP_DDI_CLOCK_SELECT_MASK | 
XELPDP_FORWARD_CLOCK_UNGATE, val);
+
+   /* 2. Read back PORT_CLOCK_CTL REGISTER */
+   val = intel_de_read(i915, XELPDP_PORT_CLOCK_CTL(encoder->port));
+
+   /*
+* 3. Follow the Display Voltage Frequency Switching - Sequence
+* Before Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+   /*
+* 4. Set PORT_CLOCK_CTL register TBT CLOCK Request to "1" to enable 
PLL.
+*/
+   val |= XELPDP_TBT_CLOCK_REQUEST;
+   intel_de_write(i915, XELPDP_PORT_CLOCK_CTL(encoder->port), val);
+
+   /* 5. Poll on PORT_CLOCK_CTL TBT CLOCK Ack == "1". */
+   if (__intel_wait_for_register(>uncore, 
XELPDP_PORT_CLOCK_CTL(encoder->port),
+ XELPDP_TBT_CLOCK_ACK,
+ XELPDP_TBT_CLOCK_ACK,
+ 100, 0, NULL))
+   drm_warn(>drm, "[ENCODER:%d:%s][%c] PHY PLL not locked 
after 100us.\n",
+encoder->base.base.id, encoder->base.name, 
phy_name(phy));
+
+   /*
+* 6. Follow the Display Voltage Frequency Switching Sequence After
+* Frequency Change. We handle this step in bxt_set_cdclk().
+*/
+
+   /*
+* 7. Program DDI_CLK_VALFREQ to match intended DDI
+* clock frequency.
+*/
+   intel_de_write(i915, DDI_CLK_VALFREQ(encoder->port),
+  crtc_state->port_clock);
+}
+
+void intel_mtl_pll_enable(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+
+   if (intel_tc_port_in_tbt_alt_mode(dig_port))
+   intel_mtl_tbt_pll_enable(encoder, crtc_state);
+   else
+   intel_cx0pll_enable(encoder, crtc_state);
+}
+
+static void intel_cx0pll_disable(struct intel_encoder *encoder)
 {
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
@@ -2491,6 +2570,56 @@ void intel_cx0pll_disable(struct intel_encoder *encoder)

[Intel-gfx] [PATCH v2 13/21] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA

[Mika Kahola]

Use MPLLA for DP2.0 rates 20G and 20G, when ssc is enabled.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-14-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 7520f50d4ffc..67e8889aec29 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -2128,8 +2128,12 @@ static void intel_program_port_clock_ctl(struct 
intel_encoder *encoder,
if (!intel_panel_use_ssc(i915))
ssc_enabled = false;
 
-   /* TODO: DP2.0 10G and 20G rates enable MPLLA*/
-   val |= ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 0;
+   /* DP2.0 10G and 20G rates enable MPLLA*/
+   if (crtc_state->port_clock == 100 || crtc_state->port_clock 
== 200) {
+   val |= ssc_enabled ? XELPDP_SSC_ENABLE_PLLA : 0;
+   } else {
+   val |= ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 0;
+   }
}
 
intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
-- 
2.34.1

[Intel-gfx] [PATCH v2 11/21] drm/i915/mtl: C20 HDMI state calculations

[Mika Kahola]

Add C20 HDMI state calculations and put HDMI table definitions
in use.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-12-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 14ea40cd0631..e5542fb209ab 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1732,9 +1732,19 @@ intel_c20_pll_tables_get(struct intel_crtc_state 
*crtc_state,
 int intel_c20pll_calc_state(struct intel_crtc_state *crtc_state,
struct intel_encoder *encoder)
 {
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(i915, encoder->port);
const struct intel_c20pll_state * const *tables;
int i;
 
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+   if (intel_c20_phy_check_hdmi_link_rate(crtc_state->port_clock) 
!= MODE_OK) {
+   drm_dbg_kms(>drm, "Can't support HDMI link rate 
%d on phy %c.\n",
+   crtc_state->port_clock, phy_name(phy));
+   return -EINVAL;
+   }
+   }
+
tables = intel_c20_pll_tables_get(crtc_state, encoder);
if (!tables)
return -EINVAL;
-- 
2.34.1

[Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout

[Mika Kahola]

Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.

Once register settings are done, we read back C20 HW state.

BSpec: 64568

v2: Update rbr, hbr1, hbr2, and hbr3 pll configurations 4 and 5
based on changes in BSpec consolidated table

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-10-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 495 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  10 +-
 drivers/gpu/drm/i915/display/intel_ddi.c |   9 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c|   6 +-
 drivers/gpu/drm/i915/display/intel_hdmi.h|   1 +
 5 files changed, 513 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 022888050a68..285e4cdd23eb 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -11,6 +11,7 @@
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
+#include "intel_hdmi.h"
 #include "intel_panel.h"
 #include "intel_psr.h"
 #include "intel_uncore.h"
@@ -247,6 +248,23 @@ static void intel_c20_write(struct drm_i915_private *i915, 
enum port port,
intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
 }
 
+static u16 intel_c20_read(struct drm_i915_private *i915, enum port port,
+  int lane, u16 addr)
+{
+   u16 val;
+
+   assert_dc_off(i915);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, (addr >> 8) & 
0xff, 1);
+
+   val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
+   val <<= 8;
+   val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
+
+return val;
+}
+
 static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
@@ -588,6 +606,192 @@ static const struct intel_c10mpllb_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/* C20 basic DP 1.4 tables */
+static const struct intel_c20pll_state mtl_c20_dp_rbr = {
+   .clock = 162000,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x5800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x50a8,  /* mpllb cfg0 */
+   0x2120, /* mpllb cfg1 */
+   0xcd9a, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x5ab8, /* mpllb cfg4 */
+   0x4c34, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+   0x6000, /* mpllb cfg8 */
+   0x, /* mpllb cfg9 */
+   0x, /* mpllb cfg10 */
+   },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
+   .clock = 27,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x4800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x308c,  /* mpllb cfg0 */
+   0x2110, /* mpllb cfg1 */
+   0xcc9c, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x489a, /* mpllb cfg4 */
+   0x3f81, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+   0x5000, /* mpllb cfg8 */
+   0x, /* mpllb cfg9 */
+   0x, /* mpllb cfg10 */
+   },
+};
+
+static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
+   .clock = 54,
+   .tx = { 0xbe88, /* tx cfg0 */
+   0x4800, /* tx cfg1 */
+   0x, /* tx cfg2 */
+   },
+   .cmn = {0x0500, /* cmn cfg0*/
+   0x0005, /* cmn cfg1 */
+   0x, /* cmn cfg2 */
+   0x, /* cmn cfg3 */
+   },
+   .mpllb = { 0x108c,  /* mpllb cfg0 */
+   0x2108, /* mpllb cfg1 */
+   0xcc9c, /* mpllb cfg2 */
+   0xbfc1, /* mpllb cfg3 */
+   0x489a, /* mpllb cfg4 */
+   0x3f81, /* mpllb cfg5 */
+   0x2000, /* mpllb cfg6 */
+   0x0001, /* mpllb cfg7 */
+   

[Intel-gfx] [PATCH v2 10/21] drm/i915/mtl: C20 port clock calculation

[Mika Kahola]

Calculate port clock with C20 phy.

Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-11-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 32 ++--
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  2 ++
 drivers/gpu/drm/i915/display/intel_ddi.c |  4 +--
 3 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 285e4cdd23eb..14ea40cd0631 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -1571,9 +1571,10 @@ int intel_cx0mpllb_calc_state(struct intel_crtc_state 
*crtc_state,
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
 
-   drm_WARN_ON(>drm, !intel_is_c10phy(i915, phy));
-
-   return intel_c10mpllb_calc_state(crtc_state, encoder);
+   if (intel_is_c10phy(i915, phy))
+   return intel_c10mpllb_calc_state(crtc_state, encoder);
+   else
+   return intel_c20pll_calc_state(crtc_state, encoder);
 }
 
 void intel_c10mpllb_readout_hw_state(struct intel_encoder *encoder,
@@ -2044,6 +2045,31 @@ int intel_c10mpllb_calc_port_clock(struct intel_encoder 
*encoder,
return tmpclk;
 }
 
+int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_c20pll_state *pll_state)
+{
+   unsigned int frac_quot = 0, frac_rem = 0, frac_den = 1;
+   unsigned int multiplier, tx_clk_div, refclk = 38400;
+
+   if (pll_state->mpllb[6] & C20_MPLLB_FRACEN) {
+   frac_quot = pll_state->mpllb[8];
+   frac_rem =  pll_state->mpllb[9];
+   frac_den =  pll_state->mpllb[7];
+   multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK, 
pll_state->mpllb[0]);
+   tx_clk_div = REG_FIELD_GET(C20_MPLLB_TX_CLK_DIV_MASK, 
pll_state->mpllb[0]);
+   } else if (pll_state->mplla[6] & C20_MPLLA_FRACEN) {
+   frac_quot = pll_state->mplla[8];
+   frac_rem =  pll_state->mplla[9];
+   frac_den =  pll_state->mplla[7];
+   multiplier = REG_FIELD_GET(C20_MULTIPLIER_MASK, 
pll_state->mplla[0]);
+   tx_clk_div = REG_FIELD_GET(C20_MPLLA_TX_CLK_DIV_MASK, 
pll_state->mplla[1]);
+   }
+
+   return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(refclk, (multiplier << 16) + 
frac_quot) +
+  DIV_ROUND_CLOSEST(refclk * frac_rem, frac_den),
+10 << (tx_clk_div + 16));
+}
+
 static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
 const struct intel_crtc_state 
*crtc_state,
 bool lane_reversal)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
index 86edbc4b1718..8ca77dfea24b 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
@@ -43,6 +43,8 @@ int intel_c10mpllb_calc_port_clock(struct intel_encoder 
*encoder,
   const struct intel_c10mpllb_state 
*pll_state);
 void intel_c10mpllb_state_verify(struct intel_atomic_state *state,
 struct intel_crtc_state *new_crtc_state);
+int intel_c20pll_calc_port_clock(struct intel_encoder *encoder,
+const struct intel_c20pll_state *pll_state);
 int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
 void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
 const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c37f7f7d84cf..829c90b17b08 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3535,12 +3535,12 @@ static void mtl_ddi_get_config(struct intel_encoder 
*encoder,
if (intel_is_c10phy(i915, phy)) {
intel_c10mpllb_readout_hw_state(encoder, 
_state->cx0pll_state.c10mpllb_state);
intel_c10mpllb_dump_hw_state(i915, 
_state->cx0pll_state.c10mpllb_state);
+   crtc_state->port_clock = 
intel_c10mpllb_calc_port_clock(encoder, 
_state->cx0pll_state.c10mpllb_state);
} else {
intel_c20pll_readout_hw_state(encoder, 
_state->cx0pll_state.c20pll_state);
+   crtc_state->port_clock = intel_c20pll_calc_port_clock(encoder, 
_state->cx0pll_state.c20pll_state);
}
 
-   crtc_state->port_clock = intel_c10mpllb_calc_port_clock(encoder, 
_state->cx0pll_state.c10mpllb_state);
-
intel_ddi_get_config(encoder, crtc_state);
 }
 
-- 
2.34.1

[Intel-gfx] [PATCH v2 08/21] drm/i915/mtl: C20 PLL programming

[Mika Kahola]

C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
4 lane support for c20.

Signed-off-by: José Roberto de Souza 
Signed-off-by: Mika Kahola 
Signed-off-by: Bhanuprakash Modem 
Signed-off-by: Imre Deak 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-9-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 279 +++---
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  30 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |  11 +-
 .../drm/i915/display/intel_display_types.h|  19 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  12 +-
 5 files changed, 311 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 3d86b0f1c36d..022888050a68 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -14,6 +14,7 @@
 #include "intel_panel.h"
 #include "intel_psr.h"
 #include "intel_uncore.h"
+#include "intel_tc.h"
 
 bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
 {
@@ -234,6 +235,18 @@ static void intel_cx0_write(struct drm_i915_private *i915, 
enum port port,
}
 }
 
+static void intel_c20_write(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u16 data)
+{
+   assert_dc_off(i915);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, (addr >> 8) & 
0xff, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff, 0);
+
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, (data >> 8) & 
0xff, 0);
+   intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
+}
+
 static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
@@ -1155,7 +1168,7 @@ static int intel_c10mpllb_calc_state(struct 
intel_crtc_state *crtc_state,
 
for (i = 0; tables[i]; i++) {
if (crtc_state->port_clock <= tables[i]->clock) {
-   crtc_state->c10mpllb_state = *tables[i];
+   crtc_state->cx0pll_state.c10mpllb_state = *tables[i];
return 0;
}
}
@@ -1215,7 +1228,7 @@ static void intel_c10_pll_program(struct drm_i915_private 
*i915,
  const struct intel_crtc_state *crtc_state,
  struct intel_encoder *encoder)
 {
-   const struct intel_c10mpllb_state *pll_state = 
_state->c10mpllb_state;
+   const struct intel_c10mpllb_state *pll_state = 
_state->cx0pll_state.c10mpllb_state;
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
u8 master_lane = lane_reversal ? INTEL_CX0_LANE1 :
@@ -1299,6 +1312,218 @@ void intel_c10mpllb_dump_hw_state(struct 
drm_i915_private *dev_priv,
i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i 
+ 3]);
 }
 
+static bool intel_c20_use_mplla(u32 clock)
+{
+   /* 10G and 20G rates use MPLLA */
+   if (clock == 312500 || clock == 625000)
+   return true;
+
+   return false;
+}
+
+static u8 intel_c20_get_dp_rate(u32 clock)
+{
+   switch (clock) {
+   case 162000: /* 1.62 Gbps DP1.4 */
+   return 0;
+   case 27: /* 2.7 Gbps DP1.4 */
+   return 1;
+   case 54: /* 5.4 Gbps DP 1.4 */
+   return 2;
+   case 81: /* 8.1 Gbps DP1.4 */
+   return 3;
+   case 216000: /* 2.16 Gbps eDP */
+   return 4;
+   case 243000: /* 2.43 Gbps eDP */
+   return 5;
+   case 324000: /* 3.24 Gbps eDP */
+   return 6;
+   case 432000: /* 4.32 Gbps eDP */
+   return 7;
+   case 312500: /* 10 Gbps DP2.0 */
+   return 8;
+   case 421875: /* 13.5 Gbps DP2.0 */
+   return 9;
+   case 625000: /* 20 Gbps DP2.0*/
+   return 10;
+   default:
+   MISSING_CASE(clock);
+   return 0;
+   }
+}
+
+static u8 intel_c20_get_hdmi_rate(u32 clock)
+{
+   switch (clock) {
+   case 25175:
+   case 27000:
+   case 74250:
+   case 148500:
+   case 594000:
+   return 0;
+   case 166670: /* 3 Gbps */
+   case 30: /* 6 Gbps */
+   case 70: /* 12 Gbps */
+   return 1;
+   case 40: /* 8 Gbps */
+   return 2;
+   case 60: /* 10 Gbps */
+   return 3;
+   default:
+   MISSING_CASE(clock);
+   return 0;
+   }
+}
+
+static bool is_dp2(u32 clock)
+{
+   /* DP2.0 clock rates */
+   if (clock == 312500 || clock == 421875 || clock  == 625000)
+   return true;

[Intel-gfx] [PATCH v2 07/21] drm/i915/mtl: Add support for PM DEMAND

[Mika Kahola]

Display14 introduces a new way to instruct the PUnit with
power and bandwidth requirements of DE. Add the functionality
to program the registers and handle waits using interrupts.
The current wait time for timeouts is programmed for 10 msecs to
factor in the worst case scenarios. Changes made to use REG_BIT
for a register that we touched(GEN8_DE_MISC_IER _MMIO).

Bspec: 66451, 64636, 64602, 64603

v2: Moved pmdemand to be part of "struct intel_display"

Cc: Matt Atwood 
Cc: Matt Roper 
Cc: Lucas De Marchi 

Signed-off-by: José Roberto de Souza 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-8-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_bw.c   |   4 +-
 drivers/gpu/drm/i915/display/intel_bw.h   |   2 +
 drivers/gpu/drm/i915/display/intel_display.c  |  14 +
 .../gpu/drm/i915/display/intel_display_core.h |   6 +
 .../drm/i915/display/intel_display_power.c|   8 +
 drivers/gpu/drm/i915/i915_irq.c   |  22 +-
 drivers/gpu/drm/i915/i915_reg.h   |  33 +-
 drivers/gpu/drm/i915/intel_pm.c   | 286 ++
 drivers/gpu/drm/i915/intel_pm.h   |  35 +++
 9 files changed, 405 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index 1c236f02b380..179dfa0a2284 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -717,8 +717,8 @@ static unsigned int intel_bw_num_active_planes(struct 
drm_i915_private *dev_priv
return num_active_planes;
 }
 
-static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
-  const struct intel_bw_state *bw_state)
+unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
+   const struct intel_bw_state *bw_state)
 {
unsigned int data_rate = 0;
enum pipe pipe;
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h 
b/drivers/gpu/drm/i915/display/intel_bw.h
index cb7ee3a24a58..b3eb82a71e6c 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
 int intel_bw_atomic_check(struct intel_atomic_state *state);
 void intel_bw_crtc_update(struct intel_bw_state *bw_state,
  const struct intel_crtc_state *crtc_state);
+unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
+   const struct intel_bw_state *bw_state);
 int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
  u32 points_mask);
 int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 655e1c86a1eb..87cd6a808938 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1089,6 +1089,9 @@ intel_get_crtc_new_encoder(const struct 
intel_atomic_state *state,
num_encoders++;
}
 
+   if (!encoder)
+   return NULL;
+
drm_WARN(encoder->base.dev, num_encoders != 1,
 "%d encoders for pipe %c\n",
 num_encoders, pipe_name(master_crtc->pipe));
@@ -6868,6 +6871,10 @@ static int intel_atomic_check(struct drm_device *dev,
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
+
+   ret = intel_pmdemand_atomic_check(state);
+   if (ret)
+   goto fail;
}
 
ret = intel_atomic_check_crtcs(state);
@@ -7484,6 +7491,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
}
 
intel_sagv_pre_plane_update(state);
+   intel_pmdemand_pre_plane_update(state);
 
/* Complete the events for pipes that have now been disabled */
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
@@ -7596,6 +7604,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_verify_planes(state);
 
intel_sagv_post_plane_update(state);
+   intel_pmdemand_post_plane_update(state);
 
drm_atomic_helper_commit_hw_done(>base);
 
@@ -8327,6 +8336,7 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
intel_color_init_hooks(dev_priv);
intel_init_cdclk_hooks(dev_priv);
intel_audio_hooks_init(dev_priv);
+   intel_init_pmdemand(dev_priv);
 
intel_dpll_init_clock_hook(dev_priv);
 
@@ -8667,6 +8677,10 @@ int intel_modeset_init_noirq(struct drm_i915_private 
*i915)
if (ret)
goto cleanup_vga_client_pw_domain_dmc;
 
+   ret = intel_pmdemand_init(i915);
+   if (ret)
+   goto 

[Intel-gfx] [PATCH v2 06/21] drm/i915/mtl: Add vswing programming for C10 phys

[Mika Kahola]

From: Radhakrishna Sripada 

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
and preemphasis 1 instead of two times of level 1 preemphasis 0.
Fix this in the driver code as well.

Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-7-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 131 --
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   2 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   6 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|  36 -
 .../drm/i915/display/intel_ddi_buf_trans.h|   6 +
 .../i915/display/intel_display_power_map.c|   1 +
 7 files changed, 175 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 746c905538a7..3d86b0f1c36d 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -6,10 +6,14 @@
 #include "i915_reg.h"
 #include "intel_cx0_phy.h"
 #include "intel_cx0_phy_regs.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_panel.h"
+#include "intel_psr.h"
+#include "intel_uncore.h"
 
 bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
 {
@@ -19,6 +23,15 @@ bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum 
phy phy)
return false;
 }
 
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(>drm, !enabled);
+}
+
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -111,6 +124,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915, 
enum port port,
int i, status = 0;
u32 val;
 
+   assert_dc_off(i915);
+
for (i = 0; i < 3; i++) {
status = __intel_cx0_read(i915, port, lane, addr, );
 
@@ -193,6 +208,8 @@ static void __intel_cx0_write(struct drm_i915_private 
*i915, enum port port,
enum phy phy = intel_port_to_phy(i915, port);
int i, status;
 
+   assert_dc_off(i915);
+
for (i = 0; i < 3; i++) {
status = __intel_cx0_write_once(i915, port, lane, addr, data, 
committed);
 
@@ -240,6 +257,80 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
}
 }
 
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_resume(intel_dp);
+   intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+   u8 master_lane = lane_reversal ? INTEL_CX0_LANE1 :
+INTEL_CX0_LANE0;
+   u8 follower_lane = lane_reversal ? INTEL_CX0_LANE0 :
+INTEL_CX0_LANE1;
+   const struct intel_ddi_buf_trans *trans;
+   intel_wakeref_t wakeref;
+   int n_entries, ln;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   trans = encoder->get_buf_trans(encoder, crtc_state, _entries);
+   if (drm_WARN_ON_ONCE(>drm, !trans))
+   return;
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
+
+   for (ln = 0; ln < 4; ln++) {
+   int level = intel_ddi_level(encoder, crtc_state, ln);
+   int lane, tx;
+
+   lane = ln / 2 + 1;
+   

[Intel-gfx] [PATCH v2 05/21] drm/i915/mtl: Add C10 phy programming for HDMI

[Mika Kahola]

From: Radhakrishna Sripada 

Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.

Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.

Bspec: 64568

v2: Rebasing with Clint's HDMI C10 PLL tables (Mika)

v3: Add missing use_hdmi checks from Clint's HDMI implementation changes (Ankit)

Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Clint Taylor 
Signed-off-by: Mika Kahola 
Signed-off-by: Ankit Nautiyal 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-6-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 584 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   1 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   2 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |   5 +-
 4 files changed, 581 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 1ceebbc6b650..746c905538a7 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -484,6 +484,546 @@ static const struct intel_c10mpllb_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/*
+ * HDMI link rates with 38.4 MHz reference clock.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25_2 = {
+   .clock = 25200,
+   .pll[0] = 0x4,
+   .pll[1] = 0,
+   .pll[2] = 0xB2,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0x8F,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_27_0 = {
+   .clock = 27000,
+   .pll[0] = 0x34,
+   .pll[1] = 0,
+   .pll[2] = 0xC0,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x80,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0xCF,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_74_25 = {
+   .clock = 74250,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xB,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_148_5 = {
+   .clock = 148500,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xA,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_594 = {
+   .clock = 594000,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x8,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+/* Precomputed C10 HDMI PLL tables */
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25175 = {
+   .clock = 25175,
+   .pll[0]=0x34,
+   .pll[1]=0x00,
+   .pll[2]=0xB0,
+   .pll[3]=0x00,
+   .pll[4]=0x00,
+   .pll[5]=0x00,
+   .pll[6]=0x00,
+   .pll[7]=0x00,
+   .pll[8]=0x20,
+   .pll[9]=0xFF,
+   .pll[10]=0xFF,
+   .pll[11]=0x55,
+   .pll[12]=0xE5,
+   .pll[13]=0x55,
+   .pll[14]=0x55,
+   .pll[15]=0x0D,
+   

[Intel-gfx] [PATCH v2 04/21] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming

[Mika Kahola]

From: Radhakrishna Sripada 

XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.

XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.

Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.

Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636

v2: Squash patches related to C10 phy message bus and pll
programming support (Jani)
Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
Move macro definitions (Jani)
DP rates as separate patch (Jani)
Spin out xelpdp register definitions into a separate file (Jani)
Replace macro to select registers based on phy lane with
function calls (Jani)
Fix styling issues (Jani)
Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
v3: Move clear request flag into try-loop

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-5-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1110 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   43 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |   34 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   22 +-
 drivers/gpu/drm/i915/display/intel_display.c  |1 +
 .../drm/i915/display/intel_display_power.c|3 +-
 .../i915/display/intel_display_power_well.c   |2 +-
 .../drm/i915/display/intel_display_types.h|6 +
 drivers/gpu/drm/i915/display/intel_dpll.c |   22 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_reg.h   |5 +
 drivers/gpu/drm/i915/i915_reg_defs.h  |   57 +
 14 files changed, 1305 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f47f00b162a4..200364242c83 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -290,6 +290,7 @@ i915-y += \
display/icl_dsi.o \
display/intel_backlight.o \
display/intel_crt.o \
+   display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
display/intel_display_trace.o \
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
new file mode 100644
index ..1ceebbc6b650
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -0,0 +1,1110 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "i915_reg.h"
+#include "intel_cx0_phy.h"
+#include "intel_cx0_phy_regs.h"
+#include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
+
+bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
+{
+   if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
+   return true;
+
+   return false;
+}
+
+static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+
+   /* Bring the phy to idle. */
+   intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
+  XELPDP_PORT_M2P_TRANSACTION_RESET);
+
+   /* Wait for Idle Clear. */
+   if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
lane-1),
+   XELPDP_PORT_M2P_TRANSACTION_RESET,
+   XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+   drm_err_once(>drm, "Failed to bring PHY %c to idle.\n", 
phy_name(phy));
+   return;
+   }
+
+   intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane-1), ~0);
+}
+
+static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port 
port, int lane, u32 *val)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+
+   if (__intel_wait_for_register(>uncore,
+ XELPDP_PORT_P2M_MSGBUS_STATUS(port, 
lane-1),
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_MSGBUS_TIMEOUT_FAST_US,
+ XELPDP_MSGBUS_TIMEOUT_SLOW, 

[Intel-gfx] [PATCH v2 03/21] drm/i915/mtl: Create separate reg file for PICA registers

[Mika Kahola]

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))
+
+#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) 
_MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane))
+#define  XELPDP_PORT_M2P_TRANSACTION_PENDING   REG_BIT(31)
+#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_READYREG_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_SLOW1
+#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   100
+#define XELPDP_PORT_RESET_START_TIMEOUT_US 5
+#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US100
+#define XELPDP_PORT_RESET_END_TIMEOUT  15
+#define XELPDP_REFCLK_ENABLE_TIMEOUT_US1
+
+#define _XELPDP_PORT_BUF_CTL1_LN0_A0x64004
+#define _XELPDP_PORT_BUF_CTL1_LN0_B0x64104
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC10x16F200
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC20x16F400
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC30x16F600
+#define _XELPDP_PORT_BUF_CTL1_LN0_USBC40x16F800
+#define _XELPDP_PORT_BUF_CTL1(port)(_PICK(port, \
+   [PORT_A] = 
_XELPDP_PORT_BUF_CTL1_LN0_A, \
+   [PORT_B] = 
_XELPDP_PORT_BUF_CTL1_LN0_B, \
+   [PORT_TC1] = 
_XELPDP_PORT_BUF_CTL1_LN0_USBC1, \
+   [PORT_TC2] = 
_XELPDP_PORT_BUF_CTL1_LN0_USBC2, \
+  

[Intel-gfx] [PATCH v2 02/21] drm/i915/mtl: Add DP rates

[Mika Kahola]

Add DP rates for Meteorlake.

Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-3-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_dp.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index bf80f296a8fd..0b08e9b6ea22 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -420,6 +420,11 @@ static int ehl_max_source_rate(struct intel_dp *intel_dp)
return 81;
 }
 
+static int mtl_max_source_rate(struct intel_dp *intel_dp)
+{
+   return intel_dp_is_edp(intel_dp) ? 675000 : 81;
+}
+
 static int vbt_max_link_rate(struct intel_dp *intel_dp)
 {
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
@@ -444,6 +449,10 @@ static void
 intel_dp_set_source_rates(struct intel_dp *intel_dp)
 {
/* The values must be in increasing order */
+   static const int mtl_rates[] = {
+   162000, 216000, 243000, 27, 324000, 432000, 54, 675000,
+   81,
+   };
static const int icl_rates[] = {
162000, 216000, 27, 324000, 432000, 54, 648000, 81,
100, 135,
@@ -469,7 +478,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
drm_WARN_ON(_priv->drm,
intel_dp->source_rates || intel_dp->num_source_rates);
 
-   if (DISPLAY_VER(dev_priv) >= 11) {
+   if (DISPLAY_VER(dev_priv) >= 14) {
+   source_rates = mtl_rates;
+   size = ARRAY_SIZE(mtl_rates);
+   max_rate = mtl_max_source_rate(intel_dp);
+   } else if (DISPLAY_VER(dev_priv) >= 11) {
source_rates = icl_rates;
size = ARRAY_SIZE(icl_rates);
if (IS_DG2(dev_priv))
-- 
2.34.1

[Intel-gfx] [PATCH v2 01/21] drm/i915/mtl: Initial DDI port setup

[Mika Kahola]

From: Clint Taylor 

Initialize c10 combo phy ports. TODO Type-C ports.

Cc: Radhakrishna Sripada 

Signed-off-by: Clint Taylor 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-2-mika.kah...@intel.com
---
 drivers/gpu/drm/i915/display/intel_display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e75b9b2a0e01..b5618de88f03 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7874,7 +7874,11 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (IS_DG2(dev_priv)) {
+   if (IS_METEORLAKE(dev_priv)) {
+   /* TODO: initialize TC ports as well */
+   intel_ddi_init(dev_priv, PORT_A);
+   intel_ddi_init(dev_priv, PORT_B);
+   } else if (IS_DG2(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
-- 
2.34.1

[Intel-gfx] [PATCH v2 00/21] drm/i915/mtl: Add C10 and C20 phy support

[Mika Kahola]

PHY programming support for PICA C10 and C20 Type-C chips.

v2: Move intel_cx0_reg_defs.h to intel_cx0_phy_regs.h (Jani)
Move pmdemand as part of intel_display structure
PLL table updates

Signed-off-by: Mika Kahola 

Anusha Srivatsa (1):
  drm/i915/mtl: Pin assignment for TypeC

Clint Taylor (1):
  drm/i915/mtl: Initial DDI port setup

Gustavo Sousa (1):
  drm/i915/mtl: Define mask for DDI AUX interrupts

Imre Deak (1):
  drm/i915/mtl: TypeC HPD live status query

Mika Kahola (14):
  drm/i915/mtl: Add DP rates
  drm/i915/mtl: Create separate reg file for PICA registers
  drm/i915/mtl: Add support for PM DEMAND
  drm/i915/mtl: C20 PLL programming
  drm/i915/mtl: C20 HW readout
  drm/i915/mtl: C20 port clock calculation
  drm/i915/mtl: C20 HDMI state calculations
  drm/i915/mtl: Add voltage swing sequence for C20
  drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA
  drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
  drm/i915/mtl: Readout Thunderbolt HW state
  drm/i915/mtl: Enable TC ports
  drm/i915/mtl: MTL PICA hotplug detection
  drm/i915/mtl: Power up TCSS

Radhakrishna Sripada (3):
  drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
  drm/i915/mtl: Add C10 phy programming for HDMI
  drm/i915/mtl: Add vswing programming for C10 phys

 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_bw.c   |4 +-
 drivers/gpu/drm/i915/display/intel_bw.h   |2 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 2702 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   57 +
 .../gpu/drm/i915/display/intel_cx0_phy_regs.h |  212 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |   37 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   65 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|6 +
 drivers/gpu/drm/i915/display/intel_display.c  |   26 +-
 .../gpu/drm/i915/display/intel_display_core.h |6 +
 .../drm/i915/display/intel_display_power.c|   11 +-
 .../i915/display/intel_display_power_map.c|1 +
 .../i915/display/intel_display_power_well.c   |2 +-
 .../drm/i915/display/intel_display_types.h|   23 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   23 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |   22 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |7 +-
 drivers/gpu/drm/i915/display/intel_hdmi.h |1 +
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/display/intel_tc.c   |  177 +-
 drivers/gpu/drm/i915/i915_irq.c   |  253 +-
 drivers/gpu/drm/i915/i915_reg.h   |   69 +-
 drivers/gpu/drm/i915/i915_reg_defs.h  |   57 +
 drivers/gpu/drm/i915/intel_pm.c   |  286 ++
 drivers/gpu/drm/i915/intel_pm.h   |   35 +
 27 files changed, 4062 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h

-- 
2.34.1

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/display: Prune Interlace modes for Display >=12

[Jani Nikula]

On Thu, 05 Jan 2023, Ankit Nautiyal  wrote:
> Defeature Display Interlace support.
> Support for interlace modes is removed from Gen 12 onwards.
> Pruning the interlace modes for HDMI for Display >=12.
> Bspec: 50490
>
> v2: Add check for both DP and HDMI. (Ville)
> Get rid of redundant check for interlace mode in modevalid. (Ville)
>
> v3: Simplify the condition to avoid interlace modes. (Jani)
>
> Signed-off-by: Ankit Nautiyal 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 4 ++--
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++-
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a9ebc73d3b87..c03a11173dc8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2092,7 +2092,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> - if (HAS_GMCH(dev_priv) &&
> + if (!connector->base.interlace_allowed &&
>   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   return -EINVAL;
>  
> @@ -5435,7 +5435,7 @@ intel_dp_init_connector(struct intel_digital_port 
> *dig_port,
>   drm_connector_init(dev, connector, _dp_connector_funcs, type);
>   drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>  
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv) && DISPLAY_VER(dev_priv) < 12)
>   connector->interlace_allowed = true;
>  
>   intel_connector->polled = DRM_CONNECTOR_POLL_HPD;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index b4323303baba..6a2ee342eab5 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2255,6 +2255,10 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> + if (!connector->interlace_allowed &&
> + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return -EINVAL;
> +
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->has_hdmi_sink =
>   intel_has_hdmi_sink(intel_hdmi, conn_state) &&
> @@ -2956,7 +2960,9 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *dig_port,
>   ddc);
>   drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>  
> - connector->interlace_allowed = true;
> + if (DISPLAY_VER(dev_priv) < 12)
> + connector->interlace_allowed = true;
> +
>   connector->stereo_allowed = true;
>  
>   if (DISPLAY_VER(dev_priv) >= 10)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/2] drm_print: fix stale macro-name in comment

[Daniel Vetter]

On Mon, Dec 05, 2022 at 09:10:05AM -0700, Jim Cromie wrote:
> Cited commit uses stale macro name, fix this, and explain better.
> 
> When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
> onto BITs in drm.debug.  This still uses enum drm_debug_category, but
> it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
> This requires that the macro args: DRM_UT_* list must be kept in sync
> and in order.
> 
> Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
> drivers.")
> Signed-off-by: Jim Cromie 

What's the status of this series?

Greg, you landed the original entire pile that wasn't quite ready yet? Or
should I apply these two?
-Daniel

> ---
> . emphasize ABI non-change despite enum val change - Jani Nikula
> . reorder to back of patchset to follow API name changes.
> ---
>  include/drm/drm_print.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index a44fb7ef257f..e4c0c7e6d49d 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
> char *prefix)
>   *
>   */
>  enum drm_debug_category {
> - /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
> + /*
> +  * Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
> +  * the enum-values define BIT()s in drm.debug, so are ABI.
> +  */
>   /**
>* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> -- 
> 2.38.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v3 2/2] drm/i915/display: Prune Interlace modes for Display >=12

[Ankit Nautiyal]

Defeature Display Interlace support.
Support for interlace modes is removed from Gen 12 onwards.
Pruning the interlace modes for HDMI for Display >=12.
Bspec: 50490

v2: Add check for both DP and HDMI. (Ville)
Get rid of redundant check for interlace mode in modevalid. (Ville)

v3: Simplify the condition to avoid interlace modes. (Jani)

Signed-off-by: Ankit Nautiyal 
---
 drivers/gpu/drm/i915/display/intel_dp.c   | 4 ++--
 drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index a9ebc73d3b87..c03a11173dc8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2092,7 +2092,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
 
-   if (HAS_GMCH(dev_priv) &&
+   if (!connector->base.interlace_allowed &&
adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
return -EINVAL;
 
@@ -5435,7 +5435,7 @@ intel_dp_init_connector(struct intel_digital_port 
*dig_port,
drm_connector_init(dev, connector, _dp_connector_funcs, type);
drm_connector_helper_add(connector, _dp_connector_helper_funcs);
 
-   if (!HAS_GMCH(dev_priv))
+   if (!HAS_GMCH(dev_priv) && DISPLAY_VER(dev_priv) < 12)
connector->interlace_allowed = true;
 
intel_connector->polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b4323303baba..6a2ee342eab5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2255,6 +2255,10 @@ int intel_hdmi_compute_config(struct intel_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
return -EINVAL;
 
+   if (!connector->interlace_allowed &&
+   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
+   return -EINVAL;
+
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
pipe_config->has_hdmi_sink =
intel_has_hdmi_sink(intel_hdmi, conn_state) &&
@@ -2956,7 +2960,9 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*dig_port,
ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
 
-   connector->interlace_allowed = true;
+   if (DISPLAY_VER(dev_priv) < 12)
+   connector->interlace_allowed = true;
+
connector->stereo_allowed = true;
 
if (DISPLAY_VER(dev_priv) >= 10)
-- 
2.25.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix potential context UAFs (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix potential context UAFs (rev2)
URL   : https://patchwork.freedesktop.org/series/112383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12546 -> Patchwork_112383v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (43 -> 44)
--

  Additional (2): fi-kbl-soraka bat-dg2-oem1 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_gttfill@basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:   NOTRUN -> [FAIL][2] ([fdo#103375])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

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

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

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

  * igt@i915_selftest@live@late_gt_pm:
- fi-glk-j4005:   [PASS][6] -> [DMESG-FAIL][7] ([i915#6217])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html

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

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600:   NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html

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

  * 
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050:   [PASS][11] -> [FAIL][12] ([i915#6298])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html

  * igt@runner@aborted:
- fi-glk-j4005:   NOTRUN -> [FAIL][13] ([i915#4312])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/fi-glk-j4005/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlp-6}:   [DMESG-WARN][14] ([i915#2867]) -> [PASS][15] +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@reset:
- {bat-rpls-1}:   [DMESG-FAIL][16] ([i915#4983]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-rpls-1/igt@i915_selftest@l...@reset.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-rpls-1/igt@i915_selftest@l...@reset.html

  * igt@i915_selftest@live@workarounds:
- {bat-adln-1}:   [INCOMPLETE][18] -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/bat-adln-1/igt@i915_selftest@l...@workarounds.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112383v2/bat-adln-1/igt@i915_selftest@l...@workarounds.html

  
 Warnings 

  * igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600:   [INCOMPLETE][20] ([i915#4817]) -> [FAIL][21] 
([fdo#103375])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12546/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
   [21]: 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Drop check for doublescan mode in modevalid

[Jani Nikula]

On Mon, 17 Oct 2022, Ankit Nautiyal  wrote:
> Since the DP/HDMI connector do not set connector->doublescan_allowed,
> the doublescan modes will get automatically filtered during
> drm_helper_probe_single_connector_modes().
>
> Therefore check for double scan modes is not required and is dropped
> from modevalid functions for both DP and HDMI.
>
> Signed-off-by: Ankit Nautiyal 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 3 ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ---
>  2 files changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a060903891b2..1f83ddf13928 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -973,9 +973,6 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>   enum drm_mode_status status;
>   bool dsc = false, bigjoiner = false;
>  
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 93519fb23d9d..e21deb6ef7fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1987,9 +1987,6 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
>   bool has_hdmi_sink = intel_has_hdmi_sink(hdmi, connector->state);
>   bool ycbcr_420_only;
>  
> - if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - return MODE_NO_DBLESCAN;
> -
>   if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == 
> DRM_MODE_FLAG_3D_FRAME_PACKING)
>   clock *= 2;

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Prune Interlace modes for Display >=12

[Jani Nikula]

On Mon, 17 Oct 2022, Ankit Nautiyal  wrote:
> Defeature Display Interlace support.
> Support for interlace modes is removed from Gen 12 onwards.
> Pruning the interlace modes for HDMI for Display >=12.
> Bspec: 50490
>
> v2: Add check for both DP and HDMI. (Ville)
> Get rid of redundant check for interlace mode in modevalid. (Ville)
>
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c   | 4 ++--
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++-
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1f83ddf13928..3dc197a45f16 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2032,7 +2032,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> - if (HAS_GMCH(dev_priv) &&
> + if ((HAS_GMCH(dev_priv) || DISPLAY_VER(dev_priv) >= 12) &&

You could just look at connector->interlace_allowed here to avoid
duplicating the conditions.

>   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
>   return -EINVAL;
>  
> @@ -5412,7 +5412,7 @@ intel_dp_init_connector(struct intel_digital_port 
> *dig_port,
>   drm_connector_init(dev, connector, _dp_connector_funcs, type);
>   drm_connector_helper_add(connector, _dp_connector_helper_funcs);
>  
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv) && DISPLAY_VER(dev_priv) < 12)
>   connector->interlace_allowed = true;
>  
>   intel_connector->polled = DRM_CONNECTOR_POLL_HPD;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index e21deb6ef7fa..05ab0a4f6d39 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2244,6 +2244,10 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
>   return -EINVAL;
>  
> + if (DISPLAY_VER(dev_priv) >= 12 &&

Same here.

> + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return -EINVAL;
> +
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
>   pipe_config->has_hdmi_sink = intel_has_hdmi_sink(intel_hdmi,
>conn_state);
> @@ -2953,7 +2957,9 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *dig_port,
>   ddc);
>   drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>  
> - connector->interlace_allowed = true;
> + if (DISPLAY_VER(dev_priv) < 12)
> + connector->interlace_allowed = true;
> +
>   connector->stereo_allowed = true;
>  
>   if (DISPLAY_VER(dev_priv) >= 10)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PULL] drm-misc-fixes

[Daniel Vetter]

On Thu, Jan 05, 2023 at 08:49:09AM +0100, Maxime Ripard wrote:
> Hi Dave, Daniel,
> 
> Here's this week drm-misc-fixes PR
> 
> Maxime
> 
> drm-misc-fixes-2023-01-05:
> Several fixes to fix the error path of dma_buf_export, add a missing
> structure declaration resulting in a compiler warning, fix the GEM
> handle refcounting in panfrost, fix a corrupted image with AFBC on
> meson, a memleak in virtio, improper plane width for imx, and a lockup
> in drm_sched_entity_kill()
> The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:
> 
>   Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-01-05
> 
> for you to fetch changes up to 6949cfa42e10f2fdd2699ed4e34d9d4f392b:

Pülled, danke vielmals.
-Daniel

> 
>   drm/scheduler: Fix lockup in drm_sched_entity_kill() (2023-01-03 14:49:59 
> +0300)
> 
> 
> Several fixes to fix the error path of dma_buf_export, add a missing
> structure declaration resulting in a compiler warning, fix the GEM
> handle refcounting in panfrost, fix a corrupted image with AFBC on
> meson, a memleak in virtio, improper plane width for imx, and a lockup
> in drm_sched_entity_kill()
> 
> 
> Carlo Caione (1):
>   drm/meson: Reduce the FIFO lines held when AFBC is not used
> 
> Christian König (1):
>   dma-buf: fix dma_buf_export init order v2
> 
> Dmitry Osipenko (1):
>   drm/scheduler: Fix lockup in drm_sched_entity_kill()
> 
> Ma Jun (1):
>   drm/plane-helper: Add the missing declaration of drm_atomic_state
> 
> Maxime Ripard (1):
>   Merge drm/drm-fixes into drm-misc-fixes
> 
> Philipp Zabel (1):
>   drm/imx: ipuv3-plane: Fix overlay plane width
> 
> Steven Price (1):
>   drm/panfrost: Fix GEM handle creation ref-counting
> 
> Xiu Jianfeng (1):
>   drm/virtio: Fix memory leak in virtio_gpu_object_create()
> 
>  drivers/dma-buf/dma-buf-sysfs-stats.c|  7 +--
>  drivers/dma-buf/dma-buf-sysfs-stats.h|  4 +-
>  drivers/dma-buf/dma-buf.c| 82 
> +++-
>  drivers/gpu/drm/imx/ipuv3-plane.c| 14 +++---
>  drivers/gpu/drm/meson/meson_viu.c|  5 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c  | 27 +++
>  drivers/gpu/drm/panfrost/panfrost_gem.c  | 16 +--
>  drivers/gpu/drm/panfrost/panfrost_gem.h  |  5 +-
>  drivers/gpu/drm/scheduler/sched_entity.c |  2 +-
>  drivers/gpu/drm/scheduler/sched_main.c   |  4 +-
>  drivers/gpu/drm/virtio/virtgpu_object.c  |  6 ++-
>  include/drm/drm_plane_helper.h   |  1 +
>  12 files changed, 80 insertions(+), 93 deletions(-)



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH] drm/i915: Reserve enough fence slot for i915_vma_unbind_async

[Das, Nirmoy]

On 1/5/2023 10:56 AM, Matthew Auld wrote:

On Fri, 23 Dec 2022 at 09:20, Nirmoy Das  wrote:

A nested dma_resv_reserve_fences(1) will not reserve slot from the
2nd call onwards and folowing dma_resv_add_fence() might hit the
"BUG_ON(fobj->num_fences >= fobj->max_fences)" check.

I915 hit above nested dma_resv case in ttm_bo_handle_move_mem() with
async unbind:

dma_resv_reserve_fences() from --> ttm_bo_handle_move_mem()
 dma_resv_reserve_fences() from --> i915_vma_unbind_async()
 dma_resv_add_fence() from --> i915_vma_unbind_async()
dma_resv_add_fence() from -->ttm_bo_move_accel_cleanup()

Resolve this by adding an extra fence in i915_vma_unbind_async().

Suggested-by: Thomas Hellström 
Signed-off-by: Nirmoy Das 

Reviewed-by: Matthew Auld 

Does this need a fixes tag?

Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Cc:  # v5.18+

I can add when pushing.



Yes, please add that.


Thanks,

Nirmoy




---
  drivers/gpu/drm/i915/i915_vma.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7d044888ac33..5ac4c1c2403c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -2149,7 +2149,7 @@ int i915_vma_unbind_async(struct i915_vma *vma, bool 
trylock_vm)
 if (!obj->mm.rsgt)
 return -EBUSY;

-   err = dma_resv_reserve_fences(obj->base.resv, 1);
+   err = dma_resv_reserve_fences(obj->base.resv, 2);
 if (err)
 return -EBUSY;

--
2.38.0

Re: [Intel-gfx] [PATCH] drm/i915: Reserve enough fence slot for i915_vma_unbind_async

[Matthew Auld]

On Fri, 23 Dec 2022 at 09:20, Nirmoy Das  wrote:
>
> A nested dma_resv_reserve_fences(1) will not reserve slot from the
> 2nd call onwards and folowing dma_resv_add_fence() might hit the
> "BUG_ON(fobj->num_fences >= fobj->max_fences)" check.
>
> I915 hit above nested dma_resv case in ttm_bo_handle_move_mem() with
> async unbind:
>
> dma_resv_reserve_fences() from --> ttm_bo_handle_move_mem()
> dma_resv_reserve_fences() from --> i915_vma_unbind_async()
> dma_resv_add_fence() from --> i915_vma_unbind_async()
> dma_resv_add_fence() from -->ttm_bo_move_accel_cleanup()
>
> Resolve this by adding an extra fence in i915_vma_unbind_async().
>
> Suggested-by: Thomas Hellström 
> Signed-off-by: Nirmoy Das 
Reviewed-by: Matthew Auld 

Does this need a fixes tag?

Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding")
Cc:  # v5.18+

I can add when pushing.

> ---
>  drivers/gpu/drm/i915/i915_vma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 7d044888ac33..5ac4c1c2403c 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -2149,7 +2149,7 @@ int i915_vma_unbind_async(struct i915_vma *vma, bool 
> trylock_vm)
> if (!obj->mm.rsgt)
> return -EBUSY;
>
> -   err = dma_resv_reserve_fences(obj->base.resv, 1);
> +   err = dma_resv_reserve_fences(obj->base.resv, 2);
> if (err)
> return -EBUSY;
>
> --
> 2.38.0
>

[Intel-gfx] [PATCH v4] arch: rename all internal names __xchg to __arch_xchg

[Andrzej Hajda]

__xchg will be used for non-atomic xchg macro.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Arnd Bergmann 
---
v2: squashed all arch patches into one
v3: fixed alpha/xchg_local, thx to l...@intel.com
v4: adjusted indentation (Heiko)
---
 arch/alpha/include/asm/cmpxchg.h | 10 +-
 arch/arc/include/asm/cmpxchg.h   |  4 ++--
 arch/arm/include/asm/cmpxchg.h   |  7 ---
 arch/arm64/include/asm/cmpxchg.h |  7 +++
 arch/hexagon/include/asm/cmpxchg.h   | 10 +-
 arch/ia64/include/asm/cmpxchg.h  |  2 +-
 arch/ia64/include/uapi/asm/cmpxchg.h |  4 ++--
 arch/loongarch/include/asm/cmpxchg.h |  4 ++--
 arch/m68k/include/asm/cmpxchg.h  |  6 +++---
 arch/mips/include/asm/cmpxchg.h  |  4 ++--
 arch/openrisc/include/asm/cmpxchg.h  | 10 +-
 arch/parisc/include/asm/cmpxchg.h|  4 ++--
 arch/powerpc/include/asm/cmpxchg.h   |  4 ++--
 arch/riscv/include/asm/atomic.h  |  2 +-
 arch/riscv/include/asm/cmpxchg.h |  4 ++--
 arch/s390/include/asm/cmpxchg.h  |  8 
 arch/sh/include/asm/cmpxchg.h|  4 ++--
 arch/sparc/include/asm/cmpxchg_32.h  |  4 ++--
 arch/sparc/include/asm/cmpxchg_64.h  |  6 +++---
 arch/xtensa/include/asm/cmpxchg.h|  4 ++--
 20 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/alpha/include/asm/cmpxchg.h b/arch/alpha/include/asm/cmpxchg.h
index 6e0a850aa9d38c..91d4a4d9258cd2 100644
--- a/arch/alpha/include/asm/cmpxchg.h
+++ b/arch/alpha/include/asm/cmpxchg.h
@@ -6,15 +6,15 @@
  * Atomic exchange routines.
  */
 
-#define xchg(type, args...)__xchg ## type ## _local(args)
+#define xchg(type, args...)__arch_xchg ## type ## 
_local(args)
 #define cmpxchg(type, args...) __cmpxchg ## type ## _local(args)
 #include 
 
 #define xchg_local(ptr, x) \
 ({ \
__typeof__(*(ptr)) _x_ = (x);   \
-   (__typeof__(*(ptr))) __xchg_local((ptr), (unsigned long)_x_,\
-  sizeof(*(ptr))); \
+   (__typeof__(*(ptr))) __arch_xchg_local((ptr), (unsigned long)_x_,\
+  sizeof(*(ptr))); \
 })
 
 #define arch_cmpxchg_local(ptr, o, n)  \
@@ -34,7 +34,7 @@
 
 #undef xchg
 #undef cmpxchg
-#define xchg(type, args...)__xchg ##type(args)
+#define xchg(type, args...)__arch_xchg ##type(args)
 #define cmpxchg(type, args...) __cmpxchg ##type(args)
 #include 
 
@@ -48,7 +48,7 @@
__typeof__(*(ptr)) _x_ = (x);   \
smp_mb();   \
__ret = (__typeof__(*(ptr)))\
-   __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr)));  \
+   __arch_xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
smp_mb();   \
__ret;  \
 })
diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index c5b544a5fe8106..e138fde067dea5 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -85,7 +85,7 @@
  */
 #ifdef CONFIG_ARC_HAS_LLSC
 
-#define __xchg(ptr, val)   \
+#define __arch_xchg(ptr, val)  \
 ({ \
__asm__ __volatile__(   \
"   ex  %0, [%1]\n" /* set new value */ \
@@ -102,7 +102,7 @@
\
switch(sizeof(*(_p_))) {\
case 4: \
-   _val_ = __xchg(_p_, _val_); \
+   _val_ = __arch_xchg(_p_, _val_);\
break;  \
default:\
BUILD_BUG();\
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 4dfe538dfc689b..44667bdb4707a9 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -25,7 +25,8 @@
 #define swp_is_buggy
 #endif
 
-static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int 
size)
+static inline unsigned long
+__arch_xchg(unsigned long x, volatile void *ptr, int size)
 {
extern void __bad_xchg(volatile void *, int);
unsigned long ret;
@@ -115,8 +116,8 @@ static inline unsigned long __xchg(unsigned 

Re: [Intel-gfx] [PATCH] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes

[Julia Lawall]

> Hi Julia, thanks for helping here.
>
> So, my question is why this
>
> make coccicheck M=drivers/gpu/drm/i915/ MODE=context 
> COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> didn't catch this chunck:
>
> - debugfs_create_file("i915_fbc_false_color", 0644, parent,
> - fbc, _fbc_debugfs_false_color_fops);
> + debugfs_create_file_unsafe("i915_fbc_false_color", 0644, parent,
> +fbc, 
> _fbc_debugfs_false_color_fops);
>
> When I run it it only catches and replaces this:
>
> - DEFINE_SIMPLE_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);
> + DEFINE_DEBUGFS_ATTRIBUTE(dsa_fops, dsa_get, dsa_set, dsa_fmt);

There is something strange in your question.  You have MODE=context but
you show the output for MODE=patch.  The rule dcf matches a call to
debugfs_create_file, and the context rule matching DEFINE_SIMPLE_ATTRIBUTE
is only activated if dcf succeeds.  So when the context rule gives a
report, there is always a corresponding call to debugfs_create_file in the
same file, it is just not highlighted.  So the request is that it should
be highlighted as well?

julia

>
> But looking to the .cocci script or at least to its description,
> I believe it should catch both cases.
>
> But if it is not a bug in the cocci script, then I'd like to hear
> from Nicolai why. And have this documented in the script.
>
> Thanks,
> Rodrigo.
>
> >
> > julia
> >
> >
> > >
> > > Thank you,
> > > ./drv
> > >
> > > >
> > > > >
> > > > > >
> > > > > > Reviewed-by: Rodrigo Vivi 
> > > > > > (to both patches, this and the drrs one.
> > > > > >
> > > > > > Also, it looks like you could contribute with other 2 patches:
> > > > > > drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c:64:0-23: WARNING: 
> > > > > > pxp_terminate_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE
> > > > > > drivers/gpu/drm/i915/gvt/debugfs.c:150:0-23: WARNING: 
> > > > > > vgpu_scan_nonprivbb_fops should be defined with 
> > > > > > DEFINE_DEBUGFS_ATTRIBUTE
> > > > >
> > > > > Yes, these are on my list. Was waiting for a feedback on the first 
> > > > > submission
> > > > > before I send more similar patches.
> > > > >
> > > > > Appreciate your time and the feedback.
> > > > >
> > > > >
> > > > > Regards,
> > > > > ./drv
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Deepak R Varma 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
> > > > > > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> > > > > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > > > index b5ee5ea0d010..4b481e2f908b 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > > > @@ -1809,10 +1809,10 @@ static int 
> > > > > > > intel_fbc_debugfs_false_color_set(void *data, u64 val)
> > > > > > >   return 0;
> > > > > > >  }
> > > > > > >
> > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> > > > > > > - intel_fbc_debugfs_false_color_get,
> > > > > > > - intel_fbc_debugfs_false_color_set,
> > > > > > > - "%llu\n");
> > > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> > > > > > > +  intel_fbc_debugfs_false_color_get,
> > > > > > > +  intel_fbc_debugfs_false_color_set,
> > > > > > > +  "%llu\n");
> > > > > > >
> > > > > > >  static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
> > > > > > > struct dentry *parent)
> > > > > > > @@ -1821,8 +1821,8 @@ static void intel_fbc_debugfs_add(struct 
> > > > > > > intel_fbc *fbc,
> > > > > > >   fbc, _fbc_debugfs_status_fops);
> > > > > > >
> > > > > > >   if (fbc->funcs->set_false_color)
> > > > > > > - debugfs_create_file("i915_fbc_false_color", 0644, 
> > > > > > > parent,
> > > > > > > - fbc, 
> > > > > > > _fbc_debugfs_false_color_fops);
> > > > > > > + debugfs_create_file_unsafe("i915_fbc_false_color", 
> > > > > > > 0644, parent,
> > > > > > > +fbc, 
> > > > > > > _fbc_debugfs_false_color_fops);
> > > > > > >  }
> > > > > > >
> > > > > > >  void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc)
> > > > > > > --
> > > > > > > 2.34.1
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
>