[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable YCbCr420 for VDSC
== Series Details == Series: Enable YCbCr420 for VDSC URL : https://patchwork.freedesktop.org/series/113729/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC
== Series Details ==
Series: Enable YCbCr420 for VDSC
URL : https://patchwork.freedesktop.org/series/113729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12707 -> Patchwork_113729v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/index.html
Participating hosts (37 -> 35)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113729v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][1] -> [SKIP][2] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_selftest@live@workarounds:
- bat-dg1-5: [PASS][3] -> [ABORT][4] ([i915#4983])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-dg1-5/igt@i915_selftest@l...@workarounds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/bat-dg1-5/igt@i915_selftest@l...@workarounds.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][5] ([i915#7229]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-11}: [INCOMPLETE][7] ([i915#7609] / [i915#7913]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.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
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
Build changes
-
* Linux: CI_DRM_12707 -> Patchwork_113729v1
CI-20190529: 20190529
CI_DRM_12707: 4553eb97820406ff3cbc51a3348ffabfe3b3110e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113729v1: 4553eb97820406ff3cbc51a3348ffabfe3b3110e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
3430efbafaba drm/i915/dsc: Add debugfs entry to validate DSC output formats
f467d8e93b5f drm/i915/vdsc: Check slice design requirement
963dc1002ca0 drm/i915: Fill in native_420 field
fb083ecc1dcd drm/i915: Enable YCbCr420 for VDSC
c5efe64a4570 drm/i915: Adding the new registers for DSC
f11a601a6476 drm/i915/dp: Check if DSC supports the given output_format
15a0b532b825 drm/dp_helper: Add helper to check if the sink supports given
format with DSC
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/index.html
Re: [Intel-gfx] [PATCH v9 7/7] drm/i915/dsc: Add debugfs entry to validate DSC output formats
On Tue, 07 Feb 2023, Suraj Kandpal wrote:
> From: Swati Sharma
>
> DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
> to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
> Also, new debugfs entry is created to enforce output format. This is
> required because of our driver policy. For ex. if a mode is supported
> in both RGB and YCbCr420 output formats by the sink, our policy is to
> try RGB first and fall back to YCbCr420, if mode cannot be shown
> using RGB. So, to test other output formats like YCbCr420 or YCbCr444,
> we need a debugfs entry (force_dsc_output_format) to force this
> output format.
>
> Signed-off-by: Swati Sharma
> ---
> .../drm/i915/display/intel_crtc_state_dump.c | 4 +-
> .../drm/i915/display/intel_crtc_state_dump.h | 2 +
> .../drm/i915/display/intel_display_debugfs.c | 77 +++
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
> 5 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> index 2422d6ef5777..9913f22e0f79 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> @@ -115,13 +115,13 @@ static void snprintf_output_types(char *buf, size_t len,
> WARN_ON_ONCE(output_types != 0);
> }
>
> -static const char * const output_format_str[] = {
> +const char * const output_format_str[] = {
Why?
> [INTEL_OUTPUT_FORMAT_RGB] = "RGB",
> [INTEL_OUTPUT_FORMAT_YCBCR420] = "YCBCR4:2:0",
> [INTEL_OUTPUT_FORMAT_YCBCR444] = "YCBCR4:4:4",
> };
>
> -static const char *output_formats(enum intel_output_format format)
> +const char *output_formats(enum intel_output_format format)
output_formats is too generic a name to be non-static.
> {
> if (format >= ARRAY_SIZE(output_format_str))
> return "invalid";
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
> b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
> index 9399c35b7e5e..daf0a7cc0702 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
> @@ -8,9 +8,11 @@
>
> struct intel_crtc_state;
> struct intel_atomic_state;
> +enum intel_output_format;
>
> void intel_crtc_state_dump(const struct intel_crtc_state *crtc_state,
> struct intel_atomic_state *state,
> const char *context);
> +const char *output_formats(enum intel_output_format format);
And maybe the place for the function is not here at all if it's needed
in multiple places.
>
> #endif /* __INTEL_CRTC_STATE_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 9e2fb8626c96..27b7d8dafe66 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -12,6 +12,7 @@
> #include "i915_irq.h"
> #include "i915_reg.h"
> #include "intel_de.h"
> +#include "intel_crtc_state_dump.h"
> #include "intel_display_debugfs.h"
> #include "intel_display_power.h"
> #include "intel_display_power_well.h"
> @@ -1770,6 +1771,13 @@ static int i915_dsc_fec_support_show(struct seq_file
> *m, void *data)
> str_yes_no(crtc_state->dsc.compression_enable));
> seq_printf(m, "DSC_Sink_Support: %s\n",
>
> str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> + seq_printf(m, "DSC_Output_Format_Sink_Support: RGB: %s
> YCBCR420: %s YCBCR444: %s\n",
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> DP_DSC_RGB)),
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> DP_DSC_YCbCr420_Native)),
> +
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> +
> DP_DSC_YCbCr444)));
> seq_printf(m, "Force_DSC_Enable: %s\n",
> str_yes_no(intel_dp->force_dsc_en));
> if (!intel_dp_is_edp(intel_dp))
> @@ -1895,6 +1903,72 @@ static const struct file_operations i915_dsc_bpc_fops
> = {
> .write = i915_dsc_bpc_write
> };
>
> +static int i915_dsc_output_format_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + struct intel_crtc_state *crtc_state;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + int ret;
Re: [Intel-gfx] [PATCH v2 05/14] kvm/vfio: Accept vfio device file from userspace
> From: Tian, Kevin > Sent: Tuesday, February 7, 2023 11:37 AM > > > From: Liu, Yi L > > Sent: Monday, February 6, 2023 5:05 PM > > > > This defines KVM_DEV_VFIO_FILE* and make alias with > > KVM_DEV_VFIO_GROUP*. > > Old userspace uses KVM_DEV_VFIO_GROUP* works as well. > > > > Signed-off-by: Yi Liu > > --- > > Documentation/virt/kvm/devices/vfio.rst | 40 ++-- > - > > include/uapi/linux/kvm.h| 16 +++--- > > virt/kvm/vfio.c | 16 +- > > 3 files changed, 42 insertions(+), 30 deletions(-) > > > > diff --git a/Documentation/virt/kvm/devices/vfio.rst > > b/Documentation/virt/kvm/devices/vfio.rst > > index 2d20dc561069..7f84ec26ca4a 100644 > > --- a/Documentation/virt/kvm/devices/vfio.rst > > +++ b/Documentation/virt/kvm/devices/vfio.rst > > @@ -9,23 +9,26 @@ Device types supported: > >- KVM_DEV_TYPE_VFIO > > > > Only one VFIO instance may be created per VM. The created device > > -tracks VFIO groups in use by the VM and features of those groups > > -important to the correctness and acceleration of the VM. As groups > > -are enabled and disabled for use by the VM, KVM should be updated > > -about their presence. When registered with KVM, a reference to the > > -VFIO-group is held by KVM. > > +tracks VFIO files (group or device) in use by the VM and features > > +of those groups/devices important to the correctness and acceleration > > +of the VM. As groups/devices are enabled and disabled for use by the > > +VM, KVM should be updated about their presence. When registered > with > > +KVM, a reference to the VFIO file is held by KVM. > > > > Groups: > > "Files" It should be "Groups" 😊 Here "Groups" means subcmd groups. > > > - KVM_DEV_VFIO_GROUP > > - > > -KVM_DEV_VFIO_GROUP attributes: > > - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device > > tracking > > - kvm_device_attr.addr points to an int32_t file descriptor > > - for the VFIO group. > > - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM > > device tracking > > - kvm_device_attr.addr points to an int32_t file descriptor > > - for the VFIO group. > > - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE > > table > > + KVM_DEV_VFIO_FILE > > + - alias: KVM_DEV_VFIO_GROUP > > + > > +KVM_DEV_VFIO_FILE attributes: > > + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM > > device > > + tracking kvm_device_attr.addr points to an int32_t file descriptor > > "... device tracking" and "kvm_device.attr.addr points to..." are two > sentences. They are deliberately arranged to be in different lines. Oh, yes. > > + for the VFIO file. > > + - alias: KVM_DEV_VFIO_GROUP_ADD > > + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from > VFIO- > > KVM > > + device tracking kvm_device_attr.addr points to an int32_t file > > + descriptor for the VFIO file. > > ditto Will convert. > > > + - alias: KVM_DEV_VFIO_GROUP_DEL > > + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE > table > > allocated by sPAPR KVM. > > somehow here it should emphasize that the file can only be group Yes. > > kvm_device_attr.addr points to a struct:: > > > > @@ -36,6 +39,7 @@ KVM_DEV_VFIO_GROUP attributes: > > > > where: > > > > - - @groupfd is a file descriptor for a VFIO group; > > - - @tablefd is a file descriptor for a TCE table allocated via > > - KVM_CREATE_SPAPR_TCE. > > + *) @groupfd is a file descriptor for a VFIO group; > > + *) @tablefd is a file descriptor for a TCE table allocated via > > why changing above two lines? this is due to changing "-" to be "*)" as subbullet as below need to add alias. > > + KVM_CREATE_SPAPR_TCE. > > + - alias: KVM_DEV_VFIO_FILE_SET_SPAPR_TCE > > GROUP Yes. Regards, Yi Liu
Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size
On Mon, Feb 06, 2023 at 04:59:36PM +, Tvrtko Ursulin wrote:
>
> On 06/02/2023 14:19, Dan Carpenter wrote:
> > [ Ancient code but the warning showed up again because the function was
> >renamed or something? - dan ]
> >
> > Hello Chris Wilson,
> >
> > The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max
> > segment size" from Oct 11, 2016, leads to the following Smatch static
> > checker warning:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c:164 shmem_sg_alloc_table()
> > warn: variable dereferenced before check 'sg' (see line 155)
>
> Is smatch getting confused here? Not entirely sure but lets see below..
Reading through your comments, it seems like you're saying the NULL
check should be deleted. I don't really consider that a "false positive".
Hopefully, we both agree that by the time we get to the check the "sg"
pointer has been dereferenced.
> >
> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > 58 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct
> > sg_table *st,
> > 59 size_t size, struct intel_memory_region
> > *mr,
> > 60 struct address_space *mapping,
> > 61 unsigned int max_segment)
> > 62 {
> > 63 unsigned int page_count; /* restricted by sg_alloc_table */
> > 64 unsigned long i;
> > 65 struct scatterlist *sg;
> > 66 struct page *page;
> > 67 unsigned long last_pfn = 0;/* suppress gcc warning
> > */
> > 68 gfp_t noreclaim;
> > 69 int ret;
> > 70
> > 71 if (overflows_type(size / PAGE_SIZE, page_count))
> > 72 return -E2BIG;
> > 73
> > 74 page_count = size / PAGE_SIZE;
> > 75 /*
> > 76 * If there's no chance of allocating enough pages for the
> > whole
> > 77 * object, bail early.
> > 78 */
> > 79 if (size > resource_size(&mr->region))
> > 80 return -ENOMEM;
> > 81
> > 82 if (sg_alloc_table(st, page_count, GFP_KERNEL |
> > __GFP_NOWARN))
> > 83 return -ENOMEM;
> > 84
> > 85 /*
> > 86 * Get the list of pages out of our struct file. They'll
> > be pinned
> > 87 * at this point until we release them.
> > 88 *
> > 89 * Fail silently without starting the shrinker
> > 90 */
> > 91 mapping_set_unevictable(mapping);
> > 92 noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
> > 93 noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
> > 94
> > 95 sg = st->sgl;
> >
> > "sg" set here.
>
> It is guaranteed to be non-NULL since sg_alloc_table succeeded.
>
Yeah. This doesn't matter. When I originally wrote this, I thought it
mattered but then I re-read the code but forgot to delete this comment.
In theory Smatch is supposed to be able to be tracking that "If
sg_alloc_table() succeeds, then "st->sgl" is non-NULL," but
__sg_alloc_table() has a do { } while() loop and Smatch is bad at
parsing loops.
However, Smatch does say that if sg_alloc_table() succeeds it means
page_count is non-zero.
> >
> > 96 st->nents = 0;
> > 97 for (i = 0; i < page_count; i++) {
Since page_count is non-zero we definitely enter this loop.
> > 98 const unsigned int shrink[] = {
> > 99 I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
> > 100 0,
> > 101 }, *s = shrink;
> > 102 gfp_t gfp = noreclaim;
> > 103
> > 104 do {
> > 105 cond_resched();
> > 106 page =
> > shmem_read_mapping_page_gfp(mapping, i, gfp);
> > 107 if (!IS_ERR(page))
> > 108 break;
> >
> > This should probably break out of the outer loop instead of the inner
> > loop?
>
> Don't think so, the loop has allocated a page and wants to break out the
> inner loop so the page can be appended to the sg list.
>
> >
> > 109
> > 110 if (!*s) {
> > 111 ret = PTR_ERR(page);
> > 112 goto err_sg;
> > 113 }
> > 114
> > 115 i915_gem_shrink(NULL, i915, 2 *
> > page_count, NULL, *s++);
> > 116
> > 117 /*
> > 118 * We've tried hard to allocate the memory
> > by reaping
> > 119 * our own buffer, now let the real VM do
> > its job and
> > 120 * go down in flames if truly OOM.
> > 121
Re: [Intel-gfx] [PATCH v2 11/14] vfio: Make vfio_device_open() exclusive between group path and device cdev path
> From: Tian, Kevin
> Sent: Tuesday, February 7, 2023 2:25 PM
>
> > From: Liu, Yi L
> > Sent: Monday, February 6, 2023 5:05 PM
> >
> > struct vfio_device_file *
> > -vfio_allocate_device_file(struct vfio_device *device)
> > +vfio_allocate_device_file(struct vfio_device *device, bool
> is_cdev_device)
> > {
> > struct vfio_device_file *df;
> >
> > @@ -407,6 +407,7 @@ vfio_allocate_device_file(struct vfio_device
> *device)
> > return ERR_PTR(-ENOMEM);
> >
> > df->device = device;
> > + df->is_cdev_device = is_cdev_device;
>
> You missed Alex's comment that the one caller can open code the
> assignment instead of introducing an unmemorable Boolean arg here.
Oh, yes. will open code to set it in cdev path.
> >
> > + /*
> > +* Device cdev path cannot support multiple device open since
> > +* it doesn't have a secure way for it. So a second device
> > +* open attempt should be failed if the caller is from a cdev
> > +* path or the device has already been opened by a cdev path.
> > +*/
> > + if (device->open_count != 0 &&
> > + (df->is_cdev_device || device->single_open))
> > + return -EINVAL;
> > +
>
> If we are gonna handle the exclusive open via dma ownership, then
> here we don't need a new single_open flag inside vfio_device since
> only one interface (cdev or group) could be used to open this device.
>
> Just preventing multi-open in cdev is sufficient here.
I see. Per below discussion, just need to make group path always
use vfio_group pointer as DMA marker.
https://lore.kernel.org/kvm/bn9pr11mb5276fa68e8cad6394a8887848c...@bn9pr11mb5276.namprd11.prod.outlook.com/
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v2 09/14] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Tian, Kevin
> Sent: Tuesday, February 7, 2023 2:07 PM
>
> > From: Liu, Yi L
> > Sent: Monday, February 6, 2023 5:05 PM
> >
> > +static void __vfio_iommufd_detach(struct vfio_device *vdev)
> > +{
> > + iommufd_device_detach(vdev->iommufd_device);
> > + vdev->iommufd_attached = false;
> > +}
> > +
> > void vfio_iommufd_physical_unbind(struct vfio_device *vdev)
> > {
> > lockdep_assert_held(&vdev->dev_set->lock);
> >
> > - if (vdev->iommufd_attached) {
> > - iommufd_device_detach(vdev->iommufd_device);
> > - vdev->iommufd_attached = false;
> > - }
> > + if (vdev->iommufd_attached)
> > + __vfio_iommufd_detach(vdev);
>
> I'm not sure whether this abstraction really improves things.
>
> Just two callers. and the old code reads clearer to me which
> checks a flag, does something and then clear the flag.
Ok. Will revert it.
>
> > @@ -74,6 +74,7 @@ struct vfio_device {
> > * @unbind_iommufd: Opposite of bind_iommufd
> > * @attach_ioas: Called when attaching device to an IOAS/HWPT
> managed
> > by the
> > * bound iommufd. Undo in unbind_iommufd.
>
> "Undo in unbind_iommufd if @detach_ioas is not called".
>
> > + * @detach_ioas: Opposite of attach_ioas, this is for runtime undo.
>
> remove "this is for runtime undo" which is confusing.
Ok, clear with your above suggestion.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix VBT DSI DVO port handling
On Tue, 07 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Turns out modern (icl+) VBTs still declare their DSI ports
> as MIPI-A and MIPI-C despite the PHYs now being A and B.
> Remap appropriately to allow the panels declared as MIPI-C
> to work.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 33 ---
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index e6ca51232dcf..06a2d98d2277 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2467,6 +2467,22 @@ static enum port dvo_port_to_port(struct
> drm_i915_private *i915,
> dvo_port);
> }
>
> +static enum port
> +dsi_dvo_port_to_port(struct drm_i915_private *i915, u8 dvo_port)
> +{
> + switch (dvo_port) {
> + case DVO_PORT_MIPIA:
> + return PORT_A;
I think I would add:
case DVO_PORT_MIPIB:
if (DISPLAY_VER(i915) >= 11)
return PORT_B;
else
return PORT_NONE;
just in case.
With that,
Reviewed-by: Jani Nikula
> + case DVO_PORT_MIPIC:
> + if (DISPLAY_VER(i915) >= 11)
> + return PORT_B;
> + else
> + return PORT_C;
> + default:
> + return PORT_NONE;
> + }
> +}
> +
> static int parse_bdb_230_dp_max_link_rate(const int vbt_max_link_rate)
> {
> switch (vbt_max_link_rate) {
> @@ -3442,19 +3458,16 @@ bool intel_bios_is_dsi_present(struct
> drm_i915_private *i915,
>
> dvo_port = child->dvo_port;
>
> - if (dvo_port == DVO_PORT_MIPIA ||
> - (dvo_port == DVO_PORT_MIPIB && DISPLAY_VER(i915) >= 11) ||
> - (dvo_port == DVO_PORT_MIPIC && DISPLAY_VER(i915) < 11)) {
> - if (port)
> - *port = dvo_port - DVO_PORT_MIPIA;
> - return true;
> - } else if (dvo_port == DVO_PORT_MIPIB ||
> -dvo_port == DVO_PORT_MIPIC ||
> -dvo_port == DVO_PORT_MIPID) {
> + if (dsi_dvo_port_to_port(i915, dvo_port) == PORT_NONE) {
Yeah that monstrosity should've been a separate function a long time ago!
> drm_dbg_kms(&i915->drm,
> "VBT has unsupported DSI port %c\n",
> port_name(dvo_port - DVO_PORT_MIPIA));
> + continue;
> }
> +
> + if (port)
> + *port = dsi_dvo_port_to_port(i915, dvo_port);
> + return true;
> }
>
> return false;
> @@ -3539,7 +3552,7 @@ bool intel_bios_get_dsc_params(struct intel_encoder
> *encoder,
> if (!(child->device_type & DEVICE_TYPE_MIPI_OUTPUT))
> continue;
>
> - if (child->dvo_port - DVO_PORT_MIPIA == encoder->port) {
> + if (dsi_dvo_port_to_port(i915, child->dvo_port) ==
> encoder->port) {
> if (!devdata->dsc)
> return false;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix VBT DSI DVO port handling
On Tue, Feb 07, 2023 at 10:59:36AM +0200, Jani Nikula wrote:
> On Tue, 07 Feb 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Turns out modern (icl+) VBTs still declare their DSI ports
> > as MIPI-A and MIPI-C despite the PHYs now being A and B.
> > Remap appropriately to allow the panels declared as MIPI-C
> > to work.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 33 ---
> > 1 file changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index e6ca51232dcf..06a2d98d2277 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -2467,6 +2467,22 @@ static enum port dvo_port_to_port(struct
> > drm_i915_private *i915,
> > dvo_port);
> > }
> >
> > +static enum port
> > +dsi_dvo_port_to_port(struct drm_i915_private *i915, u8 dvo_port)
> > +{
> > + switch (dvo_port) {
> > + case DVO_PORT_MIPIA:
> > + return PORT_A;
>
> I think I would add:
>
> case DVO_PORT_MIPIB:
> if (DISPLAY_VER(i915) >= 11)
> return PORT_B;
> else
> return PORT_NONE;
>
> just in case.
Looks like Windows doesn't expect MIPI-B to be used ever.
So I'm tempted to leave it out as well.
>
> With that,
>
> Reviewed-by: Jani Nikula
>
> > + case DVO_PORT_MIPIC:
> > + if (DISPLAY_VER(i915) >= 11)
> > + return PORT_B;
> > + else
> > + return PORT_C;
> > + default:
> > + return PORT_NONE;
> > + }
> > +}
> > +
> > static int parse_bdb_230_dp_max_link_rate(const int vbt_max_link_rate)
> > {
> > switch (vbt_max_link_rate) {
> > @@ -3442,19 +3458,16 @@ bool intel_bios_is_dsi_present(struct
> > drm_i915_private *i915,
> >
> > dvo_port = child->dvo_port;
> >
> > - if (dvo_port == DVO_PORT_MIPIA ||
> > - (dvo_port == DVO_PORT_MIPIB && DISPLAY_VER(i915) >= 11) ||
> > - (dvo_port == DVO_PORT_MIPIC && DISPLAY_VER(i915) < 11)) {
> > - if (port)
> > - *port = dvo_port - DVO_PORT_MIPIA;
> > - return true;
> > - } else if (dvo_port == DVO_PORT_MIPIB ||
> > - dvo_port == DVO_PORT_MIPIC ||
> > - dvo_port == DVO_PORT_MIPID) {
> > + if (dsi_dvo_port_to_port(i915, dvo_port) == PORT_NONE) {
>
> Yeah that monstrosity should've been a separate function a long time ago!
>
> > drm_dbg_kms(&i915->drm,
> > "VBT has unsupported DSI port %c\n",
> > port_name(dvo_port - DVO_PORT_MIPIA));
> > + continue;
> > }
> > +
> > + if (port)
> > + *port = dsi_dvo_port_to_port(i915, dvo_port);
> > + return true;
> > }
> >
> > return false;
> > @@ -3539,7 +3552,7 @@ bool intel_bios_get_dsc_params(struct intel_encoder
> > *encoder,
> > if (!(child->device_type & DEVICE_TYPE_MIPI_OUTPUT))
> > continue;
> >
> > - if (child->dvo_port - DVO_PORT_MIPIA == encoder->port) {
> > + if (dsi_dvo_port_to_port(i915, child->dvo_port) ==
> > encoder->port) {
> > if (!devdata->dsc)
> > return false;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Populate encoder->devdata for DSI on icl+
On Tue, 07 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We now have some eDP+DSI dual panel systems floating around
> where the DSI panel is the secondary LFP and thus needs to
> consult "panel type 2" in VBT in order to locate all the
> other panel type dependante stuff correctly.
>
> To that end we need to pass in the devdata to
> intel_bios_init_panel_late(), otherwise it'll just assume
> we want the primary panel type. So let's try to just populate
> the vbt.ports[] stuff and encoder->devdata for icl+ DSI
> panels as well.
>
> We can't do this on older platforms as there we risk a DSI
> port aliasing with a HDMI/DP port, which is a totally legal
> thing as the DSI ports live in their own little parallel
> universe.
Btw the series should probably be Cc: stable.
Reviewed-by: Jani Nikula
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 3 ++-
> drivers/gpu/drm/i915/display/intel_bios.c | 15 ---
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 003cac918228..05e749861658 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1951,7 +1951,8 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> /* attach connector to encoder */
> intel_connector_attach_encoder(intel_connector, encoder);
>
> - intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
> NULL);
> + encoder->devdata = intel_bios_encoder_data_lookup(dev_priv, port);
> + intel_bios_init_panel_late(dev_priv, &intel_connector->panel,
> encoder->devdata, NULL);
>
> mutex_lock(&dev_priv->drm.mode_config.mutex);
> intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 06a2d98d2277..1cd8af88ce50 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -2593,6 +2593,12 @@ intel_bios_encoder_supports_edp(const struct
> intel_bios_encoder_data *devdata)
> devdata->child.device_type & DEVICE_TYPE_INTERNAL_CONNECTOR;
> }
>
> +static bool
> +intel_bios_encoder_supports_dsi(const struct intel_bios_encoder_data
> *devdata)
> +{
> + return devdata->child.device_type & DEVICE_TYPE_MIPI_OUTPUT;
> +}
> +
> static int _intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
> *devdata)
> {
> if (!devdata || devdata->i915->display.vbt.version < 158)
> @@ -2643,7 +2649,7 @@ static void print_ddi_port(const struct
> intel_bios_encoder_data *devdata,
> {
> struct drm_i915_private *i915 = devdata->i915;
> const struct child_device_config *child = &devdata->child;
> - bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb,
> supports_tbt;
> + bool is_dvi, is_hdmi, is_dp, is_edp, is_dsi, is_crt,
> supports_typec_usb, supports_tbt;
> int dp_boost_level, dp_max_link_rate, hdmi_boost_level,
> hdmi_level_shift, max_tmds_clock;
>
> is_dvi = intel_bios_encoder_supports_dvi(devdata);
> @@ -2651,13 +2657,14 @@ static void print_ddi_port(const struct
> intel_bios_encoder_data *devdata,
> is_crt = intel_bios_encoder_supports_crt(devdata);
> is_hdmi = intel_bios_encoder_supports_hdmi(devdata);
> is_edp = intel_bios_encoder_supports_edp(devdata);
> + is_dsi = intel_bios_encoder_supports_dsi(devdata);
>
> supports_typec_usb = intel_bios_encoder_supports_typec_usb(devdata);
> supports_tbt = intel_bios_encoder_supports_tbt(devdata);
>
> drm_dbg_kms(&i915->drm,
> - "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
> LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
> - port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
> + "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
> DSI:%d LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
> + port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
> is_dsi,
> HAS_LSPCON(i915) && child->lspcon,
> supports_typec_usb, supports_tbt,
> devdata->dsc != NULL);
> @@ -2710,6 +2717,8 @@ static void parse_ddi_port(struct
> intel_bios_encoder_data *devdata)
> enum port port;
>
> port = dvo_port_to_port(i915, child->dvo_port);
> + if (port == PORT_NONE && DISPLAY_VER(i915) >= 11)
> + port = dsi_dvo_port_to_port(i915, child->dvo_port);
> if (port == PORT_NONE)
> return;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/i915/pcode: Give the punit time to settle before fatally failing
On 06.02.2023 19:32, Andi Shyti wrote:
From: Aravind Iddamsetty
During module load the punit might still be busy with its booting
routines. During this time we try to communicate with it but we
fail because we don't receive any feedback from it and we return
immediately with a -EINVAL fatal error.
At this point the driver load is "dramatically" aborted. The
following error message notifies us about it.
i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)
It would be enough to wait a little in order to give the punit
the chance to come up bright and shiny, ready to interact with
the driver.
Wait up 10 seconds for the punit to settle and complete any
outstanding transactions upon module load. If it still fails try
again with a longer timeout, 180s, 3 minutes. If it still fails
then return -EPROBE_DEFER, in order to give the punit a second
chance.
Even if these timers might look long, we should consider that the
punit, depending on the platforms, might need long times to
complete its routines. Besides we want to try anything possible
to move forward before deciding to abort the driver's load.
The issue has been reported in:
https://gitlab.freedesktop.org/drm/intel/-/issues/7814
The changes in this patch are valid only and uniquely during
boot. The common transactions with the punit during the driver's
normal operation are not affected.
Signed-off-by: Aravind Iddamsetty
Co-developed-by: Chris Wilson
Signed-off-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: Rodrigo Vivi
With improved commit message it looks OK for me. There is still question
why it takes so long for punit to become ready.
Anyway:
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
Hi,
I'm proposing again the same patch as v1 with a hopefully more
descriptive commit log in order to minimize the
misunderstandings that we had during the v1 review.
Thanks,
Andi
Changelog:
==
v1 -> v2:
- write a more descriptive commit log.
- add Chris SoB which was triggering a checkpatch error.
drivers/gpu/drm/i915/intel_pcode.c | 35 ++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pcode.c
b/drivers/gpu/drm/i915/intel_pcode.c
index a234d9b4ed143..3db2ba439bb57 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -204,15 +204,42 @@ int skl_pcode_request(struct intel_uncore *uncore, u32
mbox, u32 request,
#undef COND
}
+static int pcode_init_wait(struct intel_uncore *uncore, int timeout_ms)
+{
+ if (__intel_wait_for_register_fw(uncore,
+GEN6_PCODE_MAILBOX,
+GEN6_PCODE_READY, 0,
+500, timeout_ms,
+NULL))
+ return -EPROBE_DEFER;
+
+ return skl_pcode_request(uncore,
+DG1_PCODE_STATUS,
+DG1_UNCORE_GET_INIT_STATUS,
+DG1_UNCORE_INIT_STATUS_COMPLETE,
+DG1_UNCORE_INIT_STATUS_COMPLETE, timeout_ms);
+}
+
int intel_pcode_init(struct intel_uncore *uncore)
{
+ int err;
+
if (!IS_DGFX(uncore->i915))
return 0;
- return skl_pcode_request(uncore, DG1_PCODE_STATUS,
-DG1_UNCORE_GET_INIT_STATUS,
-DG1_UNCORE_INIT_STATUS_COMPLETE,
-DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
+ /*
+* Wait 10 seconds so that the punit to settle and complete
+* any outstanding transactions upon module load
+*/
+ err = pcode_init_wait(uncore, 1);
+
+ if (err) {
+ drm_notice(&uncore->i915->drm,
+ "Waiting for HW initialisation...\n");
+ err = pcode_init_wait(uncore, 18);
+ }
+
+ return err;
}
int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2, u32 *val)
Re: [Intel-gfx] [PATCH v2 13/14] vfio: Add ioctls for device cdev using iommufd
> From: Liu, Yi L
> Sent: Monday, February 6, 2023 5:06 PM
>
> +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> + unsigned long arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_bind_iommufd bind;
> + struct iommufd_ctx *iommufd = NULL;
> + unsigned long minsz;
> + struct fd f;
> + int ret;
> +
> + minsz = offsetofend(struct vfio_device_bind_iommufd, iommufd);
shouldn't the minsz include out_devid?
> + /*
> + * Before the first device open, get the KVM pointer currently
> + * associated with the device file (if there is) and obtain a
> + * reference. This reference is held until device closed. Save
> + * the pointer in the device for use by drivers.
> + */
> + vfio_device_get_kvm_safe(df);
there is no multi-open for cdev so "before the first device open"
doesn't make sense here.
> +int vfio_ioctl_device_attach(struct vfio_device_file *df,
> + void __user *arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_attach_iommufd_pt attach;
> + int ret;
> +
> + if (copy_from_user(&attach, (void __user *)arg, sizeof(attach)))
> + return -EFAULT;
lack of a minsz check
> +
> + if (attach.flags || attach.pt_id == IOMMUFD_INVALID_ID)
> + return -EINVAL;
> +
> + if (!device->ops->bind_iommufd)
> + return -ENODEV;
> +
> + mutex_lock(&device->dev_set->lock);
> + if (df->noiommu)
> + return -ENODEV;
-EINVAL
> +
> +int vfio_ioctl_device_detach(struct vfio_device_file *df,
> + void __user *arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_detach_iommufd_pt detach;
> +
> + if (copy_from_user(&detach, (void __user *)arg, sizeof(detach)))
> + return -EFAULT;
lack of minsz check
> + mutex_lock(&device->dev_set->lock);
> + if (df->noiommu)
> + return -ENODEV;
-EINVAL
> @@ -442,16 +443,41 @@ static int vfio_device_first_open(struct
> vfio_device_file *df,
> {
> struct vfio_device *device = df->device;
> struct iommufd_ctx *iommufd = df->iommufd;
> - int ret;
> + int ret = 0;
>
> lockdep_assert_held(&device->dev_set->lock);
>
> + /* df->iommufd and df->noiommu should be exclusive */
> + if (WARN_ON(iommufd && df->noiommu))
pointless comment
> + return -EINVAL;
> +
> if (!try_module_get(device->dev->driver->owner))
> return -ENODEV;
>
> + /*
> + * For group path, iommufd pointer is NULL when comes into this
"For group/container path"
> + * helper. Its noiommu support is in container.c.
> + *
> + * For iommufd compat mode, iommufd pointer here is a valid value.
> + * Its noiommu support is supposed to be in vfio_iommufd_bind().
remove "supposed to be"
> + *
> + * For device cdev path, iommufd pointer here is a valid value for
> + * normal cases, but it is NULL if it's noiommu. The reason is
> + * that userspace uses iommufd==-1 to indicate noiommu mode in
> this
"iommufd < 0"
> + * path. So caller of this helper will pass in a NULL iommufd
I don't think that is the reason. Instead the caller is required to pass
NULL iommufd pointer to indicate noiommu. Just remove the reason part.
> + * pointer. To differentiate it from the group path which also
> + * passes NULL iommufd pointer in, df->noiommu is used. For cdev
> + * noiommu, df->noiommu would be set to mark noiommu case for
> cdev
> + * path.
"To differentiate ..., check df->noiommu which is set only in the cdev path"
> + *
> + * So if df->noiommu is set then this helper just goes ahead to
> + * open device. If not, it depends on if iommufd pointer is NULL
> + * to handle the group path, iommufd compat mode, normal cases in
> + * the cdev path.
this doesn't match the code order. Probably can be removed after earlier
explanation.
> + * @argsz:user filled size of this data.
> + * @flags:reserved for future extension.
> + * @dev_cookie: a per device cookie provided by userspace.
> + * @iommufd: iommufd to bind. iommufd < 0 means noiommu.
s/iommufd < 0/a negative value/
Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size
On 07/02/2023 08:49, Dan Carpenter wrote:
On Mon, Feb 06, 2023 at 04:59:36PM +, Tvrtko Ursulin wrote:
On 06/02/2023 14:19, Dan Carpenter wrote:
[ Ancient code but the warning showed up again because the function was
renamed or something? - dan ]
Hello Chris Wilson,
The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max
segment size" from Oct 11, 2016, leads to the following Smatch static
checker warning:
drivers/gpu/drm/i915/gem/i915_gem_shmem.c:164 shmem_sg_alloc_table()
warn: variable dereferenced before check 'sg' (see line 155)
Is smatch getting confused here? Not entirely sure but lets see below..
Reading through your comments, it seems like you're saying the NULL
check should be deleted. I don't really consider that a "false positive".
Hopefully, we both agree that by the time we get to the check the "sg"
pointer has been dereferenced.
drivers/gpu/drm/i915/gem/i915_gem_shmem.c
58 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct
sg_table *st,
59 size_t size, struct intel_memory_region *mr,
60 struct address_space *mapping,
61 unsigned int max_segment)
62 {
63 unsigned int page_count; /* restricted by sg_alloc_table */
64 unsigned long i;
65 struct scatterlist *sg;
66 struct page *page;
67 unsigned long last_pfn = 0;/* suppress gcc warning */
68 gfp_t noreclaim;
69 int ret;
70
71 if (overflows_type(size / PAGE_SIZE, page_count))
72 return -E2BIG;
73
74 page_count = size / PAGE_SIZE;
75 /*
76 * If there's no chance of allocating enough pages for the
whole
77 * object, bail early.
78 */
79 if (size > resource_size(&mr->region))
80 return -ENOMEM;
81
82 if (sg_alloc_table(st, page_count, GFP_KERNEL | __GFP_NOWARN))
83 return -ENOMEM;
84
85 /*
86 * Get the list of pages out of our struct file. They'll be
pinned
87 * at this point until we release them.
88 *
89 * Fail silently without starting the shrinker
90 */
91 mapping_set_unevictable(mapping);
92 noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
93 noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
94
95 sg = st->sgl;
"sg" set here.
It is guaranteed to be non-NULL since sg_alloc_table succeeded.
Yeah. This doesn't matter. When I originally wrote this, I thought it
mattered but then I re-read the code but forgot to delete this comment.
In theory Smatch is supposed to be able to be tracking that "If
sg_alloc_table() succeeds, then "st->sgl" is non-NULL," but
__sg_alloc_table() has a do { } while() loop and Smatch is bad at
parsing loops.
However, Smatch does say that if sg_alloc_table() succeeds it means
page_count is non-zero.
96 st->nents = 0;
97 for (i = 0; i < page_count; i++) {
Since page_count is non-zero we definitely enter this loop.
98 const unsigned int shrink[] = {
99 I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
100 0,
101 }, *s = shrink;
102 gfp_t gfp = noreclaim;
103
104 do {
105 cond_resched();
106 page = shmem_read_mapping_page_gfp(mapping,
i, gfp);
107 if (!IS_ERR(page))
108 break;
This should probably break out of the outer loop instead of the inner
loop?
Don't think so, the loop has allocated a page and wants to break out the
inner loop so the page can be appended to the sg list.
109
110 if (!*s) {
111 ret = PTR_ERR(page);
112 goto err_sg;
113 }
114
115 i915_gem_shrink(NULL, i915, 2 * page_count,
NULL, *s++);
116
117 /*
118 * We've tried hard to allocate the memory by
reaping
119 * our own buffer, now let the real VM do its
job and
120 * go down in flames if truly OOM.
121 *
122 * However, since graphics tend to be
disposable,
123 * defer the oom here by reporting the ENOMEM
back
124 * to userspace.
125
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Pick the backlight controller based on VBT on ICP+
On Tue, 07 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the second backlight controller on ICP+ if the VBT asks
> us to do so.
>
> On pre-MTP we also check the chicken bit to make sure the
> pins have been correctly muxed by the firmware.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_backlight.c| 34 +--
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 5b7da72c95b8..a4e4b7f79e4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -1431,6 +1431,30 @@ bxt_setup_backlight(struct intel_connector *connector,
> enum pipe unused)
> return 0;
> }
>
> +static int cnp_num_backlight_controllers(struct drm_i915_private *i915)
> +{
> + if (INTEL_PCH_TYPE(i915) >= PCH_DG1)
> + return 1;
> +
> + if (INTEL_PCH_TYPE(i915) >= PCH_ICP)
> + return 2;
> +
> + return 1;
> +}
At some point I think we should clean this up between backlight and
pps. There's already intel_num_pps(). But let's get this merged as-is
now.
> +
> +static bool cnp_backlight_controller_is_valid(struct drm_i915_private *i915,
> int controller)
> +{
> + if (controller < 0 || controller >= cnp_num_backlight_controllers(i915))
> + return false;
> +
> + if (controller == 1 &&
> + INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> + INTEL_PCH_TYPE(i915) < PCH_MTP)
> + return intel_de_read(i915, SOUTH_CHICKEN1) &
> ICP_SECOND_PPS_IO_SELECT;
I got a bit confused that MTP has two controllers but it doesn't have
that bit. I first thought you were off by one with that < PCH_MTP. But
looks like it's correct.
Anyway,
Reviewed-by: Jani Nikula
> +
> + return true;
> +}
> +
> static int
> cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
> {
> @@ -1440,10 +1464,14 @@ cnp_setup_backlight(struct intel_connector
> *connector, enum pipe unused)
>
> /*
>* CNP has the BXT implementation of backlight, but with only one
> - * controller. TODO: ICP has multiple controllers but we only use
> - * controller 0 for now.
> + * controller. ICP+ can have two controllers, depending on pin muxing.
>*/
> - panel->backlight.controller = 0;
> + panel->backlight.controller = connector->panel.vbt.backlight.controller;
> + if (!cnp_backlight_controller_is_valid(i915,
> panel->backlight.controller)) {
> + drm_dbg_kms(&i915->drm, "Invalid backlight controller %d,
> assuming 0\n",
> + panel->backlight.controller);
> + panel->backlight.controller = 0;
> + }
>
> pwm_ctl = intel_de_read(i915,
> BXT_BLC_PWM_CTL(panel->backlight.controller));
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit wrote:
>
> Previous documentation suggested that PL1 power limit is always
> enabled. However we now find this not to be the case on some
> platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> initialization.
For some reason it looks like this change is impacting the atsm in CI:
https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
>
> Bspec: 51864
>
> v2: Add Bspec reference (Gwan-gyeong)
> v3: Add Fixes tag
>
> Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> Signed-off-by: Ashutosh Dixit
> Reviewed-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 1225bc432f0d5..4683a5b96eff1 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private
> *i915)
> for_each_gt(gt, i915, i)
> hwm_energy(&hwmon->ddat_gt[i], &energy);
> }
> +
> + /* Enable PL1 power limit */
> + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> hwmon->rg.pkg_rapl_limit,
> + PKG_PWR_LIM_1_EN,
> PKG_PWR_LIM_1_EN);
> }
>
> void i915_hwmon_register(struct drm_i915_private *i915)
> --
> 2.38.0
>
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix VBT DSI DVO port handling
On Tue, 07 Feb 2023, Ville Syrjälä wrote:
> On Tue, Feb 07, 2023 at 10:59:36AM +0200, Jani Nikula wrote:
>> On Tue, 07 Feb 2023, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Turns out modern (icl+) VBTs still declare their DSI ports
>> > as MIPI-A and MIPI-C despite the PHYs now being A and B.
>> > Remap appropriately to allow the panels declared as MIPI-C
>> > to work.
>> >
>> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > drivers/gpu/drm/i915/display/intel_bios.c | 33 ---
>> > 1 file changed, 23 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> > b/drivers/gpu/drm/i915/display/intel_bios.c
>> > index e6ca51232dcf..06a2d98d2277 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> > @@ -2467,6 +2467,22 @@ static enum port dvo_port_to_port(struct
>> > drm_i915_private *i915,
>> > dvo_port);
>> > }
>> >
>> > +static enum port
>> > +dsi_dvo_port_to_port(struct drm_i915_private *i915, u8 dvo_port)
>> > +{
>> > + switch (dvo_port) {
>> > + case DVO_PORT_MIPIA:
>> > + return PORT_A;
>>
>> I think I would add:
>>
>> case DVO_PORT_MIPIB:
>> if (DISPLAY_VER(i915) >= 11)
>> return PORT_B;
>> else
>> return PORT_NONE;
>>
>> just in case.
>
> Looks like Windows doesn't expect MIPI-B to be used ever.
> So I'm tempted to leave it out as well.
Okay then. $EXPLETIVE.
J.
>
>>
>> With that,
>>
>> Reviewed-by: Jani Nikula
>>
>> > + case DVO_PORT_MIPIC:
>> > + if (DISPLAY_VER(i915) >= 11)
>> > + return PORT_B;
>> > + else
>> > + return PORT_C;
>> > + default:
>> > + return PORT_NONE;
>> > + }
>> > +}
>> > +
>> > static int parse_bdb_230_dp_max_link_rate(const int vbt_max_link_rate)
>> > {
>> >switch (vbt_max_link_rate) {
>> > @@ -3442,19 +3458,16 @@ bool intel_bios_is_dsi_present(struct
>> > drm_i915_private *i915,
>> >
>> >dvo_port = child->dvo_port;
>> >
>> > - if (dvo_port == DVO_PORT_MIPIA ||
>> > - (dvo_port == DVO_PORT_MIPIB && DISPLAY_VER(i915) >= 11) ||
>> > - (dvo_port == DVO_PORT_MIPIC && DISPLAY_VER(i915) < 11)) {
>> > - if (port)
>> > - *port = dvo_port - DVO_PORT_MIPIA;
>> > - return true;
>> > - } else if (dvo_port == DVO_PORT_MIPIB ||
>> > - dvo_port == DVO_PORT_MIPIC ||
>> > - dvo_port == DVO_PORT_MIPID) {
>> > + if (dsi_dvo_port_to_port(i915, dvo_port) == PORT_NONE) {
>>
>> Yeah that monstrosity should've been a separate function a long time ago!
>>
>> >drm_dbg_kms(&i915->drm,
>> >"VBT has unsupported DSI port %c\n",
>> >port_name(dvo_port - DVO_PORT_MIPIA));
>> > + continue;
>> >}
>> > +
>> > + if (port)
>> > + *port = dsi_dvo_port_to_port(i915, dvo_port);
>> > + return true;
>> >}
>> >
>> >return false;
>> > @@ -3539,7 +3552,7 @@ bool intel_bios_get_dsc_params(struct intel_encoder
>> > *encoder,
>> >if (!(child->device_type & DEVICE_TYPE_MIPI_OUTPUT))
>> >continue;
>> >
>> > - if (child->dvo_port - DVO_PORT_MIPIA == encoder->port) {
>> > + if (dsi_dvo_port_to_port(i915, child->dvo_port) ==
>> > encoder->port) {
>> >if (!devdata->dsc)
>> >return false;
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains
On Mon, 06 Feb 2023, Imre Deak wrote:
> On Mon, Feb 06, 2023 at 06:21:11PM +0200, Jani Nikula wrote:
>> On Fri, 03 Feb 2023, Imre Deak wrote:
>> > On Thu, Feb 02, 2023 at 10:47:46PM +0200, Jani Nikula wrote:
>> >> There's only one reference to the struct intel_dmc members dc_state,
>> >> target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
>> >> question why they are under struct intel_dmc to begin with.
>> >>
>> >> Moreover, the only references to i915->display.dmc outside of
>> >> intel_dmc.c are to these members.
>> >>
>> >> They don't belong. Move them from struct intel_dmc to struct
>> >> i915_power_domains, which seems like a more suitable place.
>> >>
>> >> Cc: Imre Deak
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> [...]
>> >>
>> >> @@ -481,7 +482,7 @@ void intel_dmc_load_program(struct drm_i915_private
>> >> *dev_priv)
>> >> }
>> >> }
>> >>
>> >> - dev_priv->display.dmc.dc_state = 0;
>> >> + power_domains->dc_state = 0;
>> >
>> > This could be dropped as well, as it's already inited by the time the
>> > function is called.
>>
>> The whole dc_state thing originates to 832dba889e27 ("drm/i915/gen9:
>> Check for DC state mismatch"), and it's all about detecting
>> mismatches. I'm not sure how that works and if it's still useful.
>
> On SKL writing the DC_STATE_EN register didn't take effect, so a
> workaround was added to reread/verify the write. Yes, on newer platforms
> we should probably revisit this and try to remove at least the part
> rereading the register 5 times.
>
>> > I agree with making struct intel_dmc internal to intel_dmc.c. Since DC
>> > state is a functionality provided by the firmware (except of DC9), an
>> > alternative would be to move/add get/set/assert etc. DC state functions
>> > to intel_dmc.c instead and call these from intel_display_power*.c.
>>
>> That was actually the first patch I wrote but didn't send. There were a
>> few reasons I switched to this one:
>>
>> First, it adds a dependency between power well and dmc initialization.
>
> Do you mean the dependency that is there already?: taking some power ref
> and keeping the whole runtime PM functionality disabled until the
> firmware load completes. This is based on an earlier decision not to
> support runtime PM w/o DMC.
intel_power_domains_init() is called very early. It adjusts
allowed_dc_mask and target_dc_state.
intel_dmc_ucode_init() is called later, and depends on
intel_power_domains_init() in the way you describe above.
If intel_dmc_ucode_init() starts allocating intel_dmc dynamically, it
needs to exist before intel_power_domains_init() modifies
allowed_dc_mask and target_dc_state.
It's an interdependency that would need to be broken up somehow.
>
>> Second, it's a bunch of boilerplate, six get/set functions altogether,
>> and all of them checking for dmc init in patch 3.
>>
>> Third, it still seems funny to have these members stored in intel_dmc,
>> accessed via intel_dmc.c, but intel_dmc.c not actually using them for
>> anything internally. It's only the power well code that uses
>> them. Should more of the DC state handling be moved to intel_dmc.c then?
>
> I thought that any functions accessing the DC_STATE_EN register would be
> moved as well (besides the state checkers you refer to). I wasn't sure
> if my suggestion makes sense without actually seeing the end result; I
> think we can also regard the DC_STATE_EN register as a more general
> display PM HW interface leaving that in intel_display_power* (since DC9
> which isn't a DMC thing is also toggled via it) and leave only the
> firmware loading/initialization in intel_dmc.c as in your RFC.
Yeah, I don't know. *lots of shrugging* :)
>
>> BR,
>> Jani.
>>
>> >> gen9_set_dc_state_debugmask(dev_priv);
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
>> >> b/drivers/gpu/drm/i915/display/intel_dmc.h
>> >> index 88eae74dbcf2..da8ba246013e 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_dmc.h
>> >> +++ b/drivers/gpu/drm/i915/display/intel_dmc.h
>> >> @@ -40,9 +40,6 @@ struct intel_dmc {
>> >> bool present;
>> >> } dmc_info[DMC_FW_MAX];
>> >>
>> >> - u32 dc_state;
>> >> - u32 target_dc_state;
>> >> - u32 allowed_dc_mask;
>> >> intel_wakeref_t wakeref;
>> >> };
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>> >> b/drivers/gpu/drm/i915/display/intel_psr.c
>> >> index 2954759e9d12..cf13580af34a 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> >> @@ -702,6 +702,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
>> >> *intel_dp,
>> >> {
>> >> const u32 crtc_vdisplay = crtc_state->uapi.adjusted_mode.crtc_vdisplay;
>> >> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> >> + struct i915_power_domains *power_domains =
>> >> &dev_priv->display.power.domains;
>> >> u32 exit_scanlines;
>> >>
>> >> /*
>> >> @@ -718,7 +719,7 @@ tgl_dc3co_exitline_compute_config(struct
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dgfx, mtl+: Disable display functionality if it's globally fused-off
On Mon, 06 Feb 2023, Imre Deak wrote:
> DG1/DG2 and MTL+ has added a new display-present HW flag. Check this
> flag and if cleared, disable the driver's display functionality.
>
> So far the missing check resulted in running the display initialization
> sequence, and the WARNs below, due to the display register accesses
> timing out:
>
> [3.902843] [ cut here ]
> [3.902848] i915 :03:00.0: drm_WARN_ON(intel_de_wait_for_set(dev_priv,
> ((const i915_reg_t){ .reg = (0x42000) }), (1 << (27 - (pg))), 1))
> [3.902879] WARNING: CPU: 6 PID: 462 at
> drivers/gpu/drm/i915/display/intel_display_power_well.c:326
> gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
> [3.903009] Modules linked in: hid_sensor_hub intel_ishtp_hid i915(+)
> rtsx_pci_sdmmc drm_buddy mmc_core drm_display_helper crct10dif_pclmul nvme
> cec crc32_pclmul intel_ish_ipc crc32c_intel ucsi_acpi hid_multitouch
> nvme_core ghash_clmulni_intel typec_ucsi rtsx_pci ttm sha512_ssse3 serio_raw
> intel_ishtp typec video i2c_hid_acpi i2c_hid wmi pinctrl_tigerlake ip6_tables
> ip_tables x_tables fuse
> [3.903021] CPU: 6 PID: 462 Comm: systemd-udevd Tainted: G U
> 6.2.0-rc6+ #50
> [3.903023] Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW
> 04/26/2022
> [3.903023] RIP: 0010:gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
> [3.903105] Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 98 bb 0d e9 48 c7
> c1 00 65 a1 c0 48 89 da 48 c7 c7 4b c5 a3 c0 48 89 c6 e8 e3 df 53 e9 <0f> 0b
> 5b c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90
> [3.903106] RSP: 0018:a7cec0b07a98 EFLAGS: 00010292
> [3.903107] RAX: 0080 RBX: 9a05430eaaa0 RCX:
>
> [3.903108] RDX: 0001 RSI: aa7ab69e RDI:
>
> [3.903108] RBP: 9a0552ba2020 R08: ab062ce0 R09:
> abd3ffc2
> [3.903109] R10: R11: 0081 R12:
>
> [3.903109] R13: 9a05532a9cb0 R14: c09e1670 R15:
> 9a0543132000
> [3.903110] FS: 7f24d0fe5b40() GS:9a0ccf78()
> knlGS:
> [3.903110] CS: 0010 DS: ES: CR0: 80050033
> [3.903111] CR2: 5643d7a31a28 CR3: 000111614002 CR4:
> 00770ee0
> [3.903112] PKRU: 5554
> [3.903112] Call Trace:
> [3.903113]
> [3.903114] hsw_power_well_enable+0x12f/0x1a0 [i915]
> [3.903191] intel_power_well_enable+0x21/0x70 [i915]
> [3.903265] icl_display_core_init+0x92/0x6a0 [i915]
> [3.903346] intel_power_domains_init_hw+0x1da/0x5b0 [i915]
> [3.903422] intel_modeset_init_noirq+0x60/0x250 [i915]
> [3.903497] i915_driver_probe+0x562/0xe10 [i915]
> [3.903557] ? i915_pci_probe+0x87/0x180 [i915]
> [3.903617] local_pci_probe+0x3e/0x80
> [3.903621] pci_device_probe+0xb3/0x210
> [3.903622] really_probe+0xdb/0x380
> [3.903624] ? pm_runtime_barrier+0x50/0x90
> [3.903626] __driver_probe_device+0x78/0x170
> [3.903627] driver_probe_device+0x1f/0x90
> [3.903628] __driver_attach+0xce/0x1c0
> [3.903629] ? __pfx___driver_attach+0x10/0x10
> [3.903630] bus_for_each_dev+0x5f/0x90
> [3.903631] bus_add_driver+0x1ae/0x200
> [3.903632] driver_register+0x89/0xe0
> [3.903634] i915_init+0x1f/0x7f [i915]
> [3.903695] ? __pfx_init_module+0x10/0x10 [i915]
> [3.903751] do_one_initcall+0x43/0x220
> [3.903753] ? kmalloc_trace+0x26/0x90
> [3.903756] do_init_module+0x4a/0x200
> [3.903758] __do_sys_init_module+0x157/0x180
> [3.903760] do_syscall_64+0x58/0xc0
> [3.903762] ? do_syscall_64+0x67/0xc0
> [3.903762] ? exc_page_fault+0x70/0x170
> [3.903764] entry_SYSCALL_64_after_hwframe+0x72/0xdc
>
> Bspec: 49189, 53112
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_device_info.c | 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 596efc940ee70..a22a0fa299645 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -116,6 +116,9 @@
> * #define GEN8_BAR_MMIO(0xb888)
> */
>
> +#define GU_CNTL_PROTECTED_MMIO(0x10100C)
> +#define DEPRESENT REG_BIT(9)
> +
> #define GU_CNTL _MMIO(0x101010)
> #define LMEM_INIT REG_BIT(7)
> #define DRIVERFLR REG_BIT(31)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 98769e5f2c3d1..044ac552c9280 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -501,6 +501,19 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *d
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Factor out a function disabling fused-off display
On Mon, 06 Feb 2023, Imre Deak wrote:
> Factor out a function used both on older and new platforms to disable
> the display functionality if the display is fused-off.
The single point of truth for disabling display is the if
(!HAS_DISPLAY()) path near the end of intel_device_info_runtime_init().
I think it's fine to abstract it if you want, but it should *only* be
called from that *one* place in one path.
So that's a no for this one.
BR,
Jani.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 34 +---
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 044ac552c9280..9d6d1fad9f1d9 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -369,6 +369,21 @@ void intel_device_info_runtime_init_early(struct
> drm_i915_private *i915)
> intel_device_info_subplatform_init(i915);
> }
>
> +static void disable_fused_off_display(struct drm_i915_private *i915)
> +{
> + struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
> +
> + drm_info(&i915->drm, "Display fused off, disabling\n");
> +
> + runtime->pipe_mask = 0;
> + runtime->cpu_transcoder_mask = 0;
> + runtime->fbc_mask = 0;
> + runtime->has_hdcp = 0;
> + runtime->fbc_mask = 0;
> + runtime->has_dmc = 0;
> + runtime->has_dsc = 0;
> +}
> +
> /**
> * intel_device_info_runtime_init - initialize runtime info
> * @dev_priv: the i915 device
> @@ -454,11 +469,7 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
> (HAS_PCH_CPT(dev_priv) &&
>!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
> - drm_info(&dev_priv->drm,
> - "Display fused off, disabling\n");
> - runtime->pipe_mask = 0;
> - runtime->cpu_transcoder_mask = 0;
> - runtime->fbc_mask = 0;
> + disable_fused_off_display(dev_priv);
> } else if (fuse_strap & IVB_PIPE_C_DISABLE) {
> drm_info(&dev_priv->drm, "PipeC fused off\n");
> runtime->pipe_mask &= ~BIT(PIPE_C);
> @@ -502,17 +513,8 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
> }
>
> if ((IS_DGFX(dev_priv) || DISPLAY_VER(dev_priv) >= 14) &&
> - !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT)) {
> - drm_info(&dev_priv->drm, "Display fused off, disabling\n");
> -
> - runtime->pipe_mask = 0;
> - runtime->cpu_transcoder_mask = 0;
> - runtime->fbc_mask = 0;
> - runtime->has_hdcp = 0;
> - runtime->fbc_mask = 0;
> - runtime->has_dmc = 0;
> - runtime->has_dsc = 0;
> - }
> + !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT))
> + disable_fused_off_display(dev_priv);
>
> if (GRAPHICS_VER(dev_priv) == 6 && i915_vtd_active(dev_priv)) {
> drm_info(&dev_priv->drm,
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix eDP+DSI dual panel systems (rev2)
== Series Details == Series: drm/i915: Fix eDP+DSI dual panel systems (rev2) URL : https://patchwork.freedesktop.org/series/113728/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./incl
Re: [Intel-gfx] [PATCH v3 2/2] drm/probe_helper: sort out poll_running vs poll_enabled
Hi Dmitry,
On Tue, 24 Jan 2023, Dmitry Baryshkov wrote:
There are two flags attemting to guard connector polling:
poll_enabled and poll_running. While poll_enabled semantics is clearly
defined and fully adhered (mark that drm_kms_helper_poll_init() was
called and not finalized by the _fini() call), the poll_running flag
doesn't have such clearliness.
This flag is used only in drm_helper_probe_single_connector_modes() to
guard calling of drm_kms_helper_poll_enable, it doesn't guard the
drm_kms_helper_poll_fini(), etc. Change it to only be set if the polling
is actually running. Tie HPD enablement to this flag.
This fixes the following warning reported after merging the HPD series:
Hot plug detection already enabled
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_bridge.c:1257
drm_bridge_hpd_enable+0x94/0x9c [drm]
Modules linked in: videobuf2_memops snd_soc_simple_card
snd_soc_simple_card_utils fsl_imx8_ddr_perf videobuf2_common snd_soc_imx_spdif
adv7511 etnaviv imx8m_ddrc imx_dcss mc cec nwl_dsi gov
CPU: 2 PID: 9 Comm: kworker/u8:0 Not tainted 6.2.0-rc2-15208-g25b283acd578 #6
Hardware name: NXP i.MX8MQ EVK (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_bridge_hpd_enable+0x94/0x9c [drm]
lr : drm_bridge_hpd_enable+0x94/0x9c [drm]
sp : 89ef3740
x29: 89ef3740 x28: 09331f00 x27: 1000
x26: 0020 x25: 81148ed8 x24: 0a8fe000
x23: fffd x22: 05086348 x21: 81133ee0
x20: 0550d800 x19: 05086288 x18: 0006
x17: x16: 896ef008 x15: 972891004260
x14: 2a1403e19400 x13: 972891004260 x12: 2a1403e19400
x11: 7100385f29400801 x10: 0aa0 x9 : 88112744
x8 : 00250b00 x7 : 0003 x6 : 0011
x5 : x4 : bd986a48 x3 : 0001
x2 : x1 : x0 : 0025
Call trace:
drm_bridge_hpd_enable+0x94/0x9c [drm]
drm_bridge_connector_enable_hpd+0x2c/0x3c [drm_kms_helper]
drm_kms_helper_poll_enable+0x94/0x10c [drm_kms_helper]
drm_helper_probe_single_connector_modes+0x1a8/0x510 [drm_kms_helper]
drm_client_modeset_probe+0x204/0x1190 [drm]
__drm_fb_helper_initial_config_and_unlock+0x5c/0x4a4 [drm_kms_helper]
drm_fb_helper_initial_config+0x54/0x6c [drm_kms_helper]
drm_fbdev_client_hotplug+0xd0/0x140 [drm_kms_helper]
drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
dcss_kms_attach+0x1c8/0x254 [imx_dcss]
dcss_drv_platform_probe+0x90/0xfc [imx_dcss]
platform_probe+0x70/0xcc
really_probe+0xc4/0x2e0
__driver_probe_device+0x80/0xf0
driver_probe_device+0xe0/0x164
__device_attach_driver+0xc0/0x13c
bus_for_each_drv+0x84/0xe0
__device_attach+0xa4/0x1a0
device_initial_probe+0x1c/0x30
bus_probe_device+0xa4/0xb0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x200/0x474
worker_thread+0x74/0x43c
kthread+0xfc/0x110
ret_from_fork+0x10/0x20
---[ end trace ]---
Reported-by: Laurentiu Palcu
Fixes: c8268795c9a9 ("drm/probe-helper: enable and disable HPD on connectors")
Tested-by: Marek Szyprowski
Tested-by: Chen-Yu Tsai
Acked-by: Laurentiu Palcu
Tested-by: Laurentiu Palcu
Tested-by: Laurent Pinchart
Signed-off-by: Dmitry Baryshkov
Thanks for your patch!
This gets rids of the warning splats on e.g. Renesas Koelsch and
Salvator-XS, so
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [PATCH v2] drm/i915/pcode: Give the punit time to settle before fatally failing
Hi Andrzej, > > During module load the punit might still be busy with its booting > > routines. During this time we try to communicate with it but we > > fail because we don't receive any feedback from it and we return > > immediately with a -EINVAL fatal error. > > > > At this point the driver load is "dramatically" aborted. The > > following error message notifies us about it. > > > > i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3) > > > > It would be enough to wait a little in order to give the punit > > the chance to come up bright and shiny, ready to interact with > > the driver. > > > > Wait up 10 seconds for the punit to settle and complete any > > outstanding transactions upon module load. If it still fails try > > again with a longer timeout, 180s, 3 minutes. If it still fails > > then return -EPROBE_DEFER, in order to give the punit a second > > chance. > > > > Even if these timers might look long, we should consider that the > > punit, depending on the platforms, might need long times to > > complete its routines. Besides we want to try anything possible > > to move forward before deciding to abort the driver's load. > > > > The issue has been reported in: > > > > https://gitlab.freedesktop.org/drm/intel/-/issues/7814 > > > > The changes in this patch are valid only and uniquely during > > boot. The common transactions with the punit during the driver's > > normal operation are not affected. > > > > Signed-off-by: Aravind Iddamsetty > > Co-developed-by: Chris Wilson > > Signed-off-by: Chris Wilson > > Signed-off-by: Andi Shyti > > Cc: Rodrigo Vivi > > With improved commit message it looks OK for me. There is still question why > it takes so long for punit to become ready. It's hardware and some punit operations require that much. There are some documents floating around that have all these calculations. Some devices require even more time and, after consulting with hardware guys, Aravind had to increase the timeout to 6 minutes! Boot routines should not require this much, thus the 20 seconds. > Anyway: > Reviewed-by: Andrzej Hajda Thanks a lot for looking into this, Andrzej! Andi
[Intel-gfx] ✓ Fi.CI.IGT: success for More drm_dbg to guc_dbg changes (rev2)
== Series Details ==
Series: More drm_dbg to guc_dbg changes (rev2)
URL : https://patchwork.freedesktop.org/series/113624/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12707_full -> Patchwork_113624v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/index.html
Participating hosts (11 -> 10)
--
Missing(1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113624v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_balancer@hang:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-dg1-14/igt@gem_exec_balan...@hang.html
Known issues
Here are the changes found in Patchwork_113624v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-glk1/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-glk9/igt@kms_...@dsc-with-bpc-formats.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@drm_fdinfo@i...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][9] ([i915#658]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-2/igt@feature_discov...@psr1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][11] ([i915#6268]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@gem_ctx_e...@basic-nohangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][13] ([i915#6252]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-3/igt@gem_ctx_persiste...@hang.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][15] ([i915#5115] / [i915#7052]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@gem_...@suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-1/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +14 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-6/igt@gem_exec_re...@basic-wc-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:[SKIP][21] ([i915#7276]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@gem_exec_sched...@semaphore-power.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/shard-rkl-5/igt@gem_exec_sched...@semaphore-power.html
* igt@gem_tiled_partial_pwrite_pread@writes:
- {shard-rkl}:[SKIP][23] ([i915#3282]) -> [PASS][24] +4 similar
issues
[23]:
https:
[Intel-gfx] [PATCH] drm/i915/dmc: drop "ucode" from function names
The ucode part in the init, fini, suspend and resume function names is
just unnecessary. Drop it.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dmc.c | 20 ++--
drivers/gpu/drm/i915/display/intel_dmc.h | 8
drivers/gpu/drm/i915/i915_driver.c | 6 +++---
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 12ade593..a8c91fda40a8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8639,7 +8639,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
if (!HAS_DISPLAY(i915))
return 0;
- intel_dmc_ucode_init(i915);
+ intel_dmc_init(i915);
i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
@@ -8674,7 +8674,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
return 0;
cleanup_vga_client_pw_domain_dmc:
- intel_dmc_ucode_fini(i915);
+ intel_dmc_fini(i915);
intel_power_domains_driver_remove(i915);
intel_vga_unregister(i915);
cleanup_bios:
@@ -9000,7 +9000,7 @@ void intel_modeset_driver_remove_noirq(struct
drm_i915_private *i915)
/* part #3: call after gem init */
void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915)
{
- intel_dmc_ucode_fini(i915);
+ intel_dmc_fini(i915);
intel_power_domains_driver_remove(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 3b8e8193d042..f70ada2357dc 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -918,13 +918,13 @@ static void dmc_load_work_fn(struct work_struct *work)
}
/**
- * intel_dmc_ucode_init() - initialize the firmware loading.
+ * intel_dmc_init() - initialize the firmware loading.
* @dev_priv: i915 drm device.
*
* This function is called at the time of loading the display driver to read
* firmware from a .bin file and copied into a internal memory.
*/
-void intel_dmc_ucode_init(struct drm_i915_private *dev_priv)
+void intel_dmc_init(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = &dev_priv->display.dmc;
@@ -1002,14 +1002,14 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_suspend() - prepare DMC firmware before system suspend
+ * intel_dmc_suspend() - prepare DMC firmware before system suspend
* @dev_priv: i915 drm device
*
* Prepare the DMC firmware before entering system suspend. This includes
* flushing pending work items and releasing any resources acquired during
* init.
*/
-void intel_dmc_ucode_suspend(struct drm_i915_private *dev_priv)
+void intel_dmc_suspend(struct drm_i915_private *dev_priv)
{
if (!HAS_DMC(dev_priv))
return;
@@ -1022,13 +1022,13 @@ void intel_dmc_ucode_suspend(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_resume() - init DMC firmware during system resume
+ * intel_dmc_resume() - init DMC firmware during system resume
* @dev_priv: i915 drm device
*
* Reinitialize the DMC firmware during system resume, reacquiring any
- * resources released in intel_dmc_ucode_suspend().
+ * resources released in intel_dmc_suspend().
*/
-void intel_dmc_ucode_resume(struct drm_i915_private *dev_priv)
+void intel_dmc_resume(struct drm_i915_private *dev_priv)
{
if (!HAS_DMC(dev_priv))
return;
@@ -1042,20 +1042,20 @@ void intel_dmc_ucode_resume(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_fini() - unload the DMC firmware.
+ * intel_dmc_fini() - unload the DMC firmware.
* @dev_priv: i915 drm device.
*
* Firmmware unloading includes freeing the internal memory and reset the
* firmware loading status.
*/
-void intel_dmc_ucode_fini(struct drm_i915_private *dev_priv)
+void intel_dmc_fini(struct drm_i915_private *dev_priv)
{
enum intel_dmc_id dmc_id;
if (!HAS_DMC(dev_priv))
return;
- intel_dmc_ucode_suspend(dev_priv);
+ intel_dmc_suspend(dev_priv);
drm_WARN_ON(&dev_priv->drm, dev_priv->display.dmc.wakeref);
for_each_dmc_id(dmc_id)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 88eae74dbcf2..c9808bbe7162 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -46,14 +46,14 @@ struct intel_dmc {
intel_wakeref_t wakeref;
};
-void intel_dmc_ucode_init(struct drm_i915_private *i915);
+void intel_dmc_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_disable_program(struct
[Intel-gfx] [PATCH] drm/i915/bios: set default backlight controller index
With backlight controller set to -1 in intel_panel_init_alloc() to
distinguish uninitialized values, and controller later being set only if
it's present in VBT, we can end up with -1 for the controller:
[drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255,
controller 4294967295
There's no harm if it happens on platforms that ignore controller due to
only one backlight controller being present, like on VLV above, but play
it safe.
Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer
intiially on bxt/glk")
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index e6ca51232dcf..ad833069f59c 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1033,6 +1033,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
}
panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
+ panel->vbt.backlight.controller = 0;
if (i915->display.vbt.version >= 191) {
size_t exp_size;
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix sphinx warnings for workarounds documentation
On 2/6/23 18:00, Rodrigo Vivi wrote:
On Tue, Jan 31, 2023 at 02:03:01PM +0100, Mauro Carvalho Chehab wrote:
On 1/24/23 20:39, Rodrigo Vivi wrote:
On Sat, Jan 21, 2023 at 04:08:53PM -0300, Gustavo Sousa wrote:
The wildchar ("*") used in the function name patterns in the
documentation was taken as a start of an "emphasis" inline markup. Wrap
the patterns with the inline literal markup and, for consistency, do the
same for the other function names mentioned.
Fixes: 0c3064cf33fb ("drm/i915/doc: Document where to implement register
workarounds")
Reported-by: kernel test robot
Signed-off-by: Gustavo Sousa
Cc: Mauro Carvalho Chehab
just in case he sees some better alternative for the escaping the '*'
My fear is that this ``*_fn_name()`` could create invalid links in the doc...
Seems OK to me. ``foo`` is literal inline. It won't try to generate
cross-references.
Reviewed-by: Mauro Carvalho Chehab
Gustavo and Mauro, please accept my apologies here.
I ended up pushing the patch from Bagas that had a escape \*
instead of the `` wrapper.
For some unexcused reason I had missed Mauro's response here
and forgot about this. I'm really sorry.
And the escape sounded more natural so I just pushed it immediately.
No worries. An escape \* works.
Regards,
Mauro
Re: [Intel-gfx] [PATCH] drm/i915/bios: set default backlight controller index
On Tue, Feb 07, 2023 at 01:16:26PM +0200, Jani Nikula wrote:
> With backlight controller set to -1 in intel_panel_init_alloc() to
> distinguish uninitialized values, and controller later being set only if
> it's present in VBT, we can end up with -1 for the controller:
>
> [drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
> frequency 200 Hz, active high, min brightness 0, level 255,
> controller 4294967295
>
> There's no harm if it happens on platforms that ignore controller due to
> only one backlight controller being present, like on VLV above, but play
> it safe.
>
> Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer
> intiially on bxt/glk")
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index e6ca51232dcf..ad833069f59c 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1033,6 +1033,7 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> }
>
> panel->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> + panel->vbt.backlight.controller = 0;
> if (i915->display.vbt.version >= 191) {
> size_t exp_size;
Ah right, older VBT didnt have this so we leave it untouched.
Zeroing in that case seems like the right thing to do.
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dgfx, mtl+: Disable display functionality if it's globally fused-off
On Tue, Feb 07, 2023 at 12:17:59PM +0200, Jani Nikula wrote:
> On Mon, 06 Feb 2023, Imre Deak wrote:
> > DG1/DG2 and MTL+ has added a new display-present HW flag. Check this
> > flag and if cleared, disable the driver's display functionality.
> >
> > So far the missing check resulted in running the display initialization
> > sequence, and the WARNs below, due to the display register accesses
> > timing out:
> >
> > [3.902843] [ cut here ]
> > [3.902848] i915 :03:00.0:
> > drm_WARN_ON(intel_de_wait_for_set(dev_priv, ((const i915_reg_t){ .reg =
> > (0x42000) }), (1 << (27 - (pg))), 1))
> > [3.902879] WARNING: CPU: 6 PID: 462 at
> > drivers/gpu/drm/i915/display/intel_display_power_well.c:326
> > gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
> > [3.903009] Modules linked in: hid_sensor_hub intel_ishtp_hid i915(+)
> > rtsx_pci_sdmmc drm_buddy mmc_core drm_display_helper crct10dif_pclmul nvme
> > cec crc32_pclmul intel_ish_ipc crc32c_intel ucsi_acpi hid_multitouch
> > nvme_core ghash_clmulni_intel typec_ucsi rtsx_pci ttm sha512_ssse3
> > serio_raw intel_ishtp typec video i2c_hid_acpi i2c_hid wmi
> > pinctrl_tigerlake ip6_tables ip_tables x_tables fuse
> > [3.903021] CPU: 6 PID: 462 Comm: systemd-udevd Tainted: G U
> > 6.2.0-rc6+ #50
> > [3.903023] Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW
> > 04/26/2022
> > [3.903023] RIP: 0010:gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
> > [3.903105] Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 98 bb 0d e9 48
> > c7 c1 00 65 a1 c0 48 89 da 48 c7 c7 4b c5 a3 c0 48 89 c6 e8 e3 df 53 e9
> > <0f> 0b 5b c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90
> > [3.903106] RSP: 0018:a7cec0b07a98 EFLAGS: 00010292
> > [3.903107] RAX: 0080 RBX: 9a05430eaaa0 RCX:
> >
> > [3.903108] RDX: 0001 RSI: aa7ab69e RDI:
> >
> > [3.903108] RBP: 9a0552ba2020 R08: ab062ce0 R09:
> > abd3ffc2
> > [3.903109] R10: R11: 0081 R12:
> >
> > [3.903109] R13: 9a05532a9cb0 R14: c09e1670 R15:
> > 9a0543132000
> > [3.903110] FS: 7f24d0fe5b40() GS:9a0ccf78()
> > knlGS:
> > [3.903110] CS: 0010 DS: ES: CR0: 80050033
> > [3.903111] CR2: 5643d7a31a28 CR3: 000111614002 CR4:
> > 00770ee0
> > [3.903112] PKRU: 5554
> > [3.903112] Call Trace:
> > [3.903113]
> > [3.903114] hsw_power_well_enable+0x12f/0x1a0 [i915]
> > [3.903191] intel_power_well_enable+0x21/0x70 [i915]
> > [3.903265] icl_display_core_init+0x92/0x6a0 [i915]
> > [3.903346] intel_power_domains_init_hw+0x1da/0x5b0 [i915]
> > [3.903422] intel_modeset_init_noirq+0x60/0x250 [i915]
> > [3.903497] i915_driver_probe+0x562/0xe10 [i915]
> > [3.903557] ? i915_pci_probe+0x87/0x180 [i915]
> > [3.903617] local_pci_probe+0x3e/0x80
> > [3.903621] pci_device_probe+0xb3/0x210
> > [3.903622] really_probe+0xdb/0x380
> > [3.903624] ? pm_runtime_barrier+0x50/0x90
> > [3.903626] __driver_probe_device+0x78/0x170
> > [3.903627] driver_probe_device+0x1f/0x90
> > [3.903628] __driver_attach+0xce/0x1c0
> > [3.903629] ? __pfx___driver_attach+0x10/0x10
> > [3.903630] bus_for_each_dev+0x5f/0x90
> > [3.903631] bus_add_driver+0x1ae/0x200
> > [3.903632] driver_register+0x89/0xe0
> > [3.903634] i915_init+0x1f/0x7f [i915]
> > [3.903695] ? __pfx_init_module+0x10/0x10 [i915]
> > [3.903751] do_one_initcall+0x43/0x220
> > [3.903753] ? kmalloc_trace+0x26/0x90
> > [3.903756] do_init_module+0x4a/0x200
> > [3.903758] __do_sys_init_module+0x157/0x180
> > [3.903760] do_syscall_64+0x58/0xc0
> > [3.903762] ? do_syscall_64+0x67/0xc0
> > [3.903762] ? exc_page_fault+0x70/0x170
> > [3.903764] entry_SYSCALL_64_after_hwframe+0x72/0xdc
> >
> > Bspec: 49189, 53112
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > drivers/gpu/drm/i915/intel_device_info.c | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 596efc940ee70..a22a0fa299645 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -116,6 +116,9 @@
> > * #define GEN8_BAR_MMIO(0xb888)
> > */
> >
> > +#define GU_CNTL_PROTECTED _MMIO(0x10100C)
> > +#define DEPRESENTREG_BIT(9)
> > +
> > #define GU_CNTL_MMIO(0x101010)
> > #define LMEM_INITREG_BIT(7)
> > #define DRIVERFLRREG_BIT(31)
> > diff --git a/drivers/gpu/drm/i915/intel_devic
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dmc: drop "ucode" from function names
== Series Details == Series: drm/i915/dmc: drop "ucode" from function names URL : https://patchwork.freedesktop.org/series/113735/ 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 3/3] drm/i915: Factor out a function disabling fused-off display
On Tue, Feb 07, 2023 at 12:21:34PM +0200, Jani Nikula wrote:
> On Mon, 06 Feb 2023, Imre Deak wrote:
> > Factor out a function used both on older and new platforms to disable
> > the display functionality if the display is fused-off.
>
> The single point of truth for disabling display is the if
> (!HAS_DISPLAY()) path near the end of intel_device_info_runtime_init().
>
> I think it's fine to abstract it if you want, but it should *only* be
> called from that *one* place in one path.
I think for consistency GEN 7,8 should also just clear
runtime->pipe_mask depending on the later block to clear the other
fields.
> So that's a no for this one.
Ok, I can drop this patch.
> BR,
> Jani.
>
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_device_info.c | 34 +---
> > 1 file changed, 18 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 044ac552c9280..9d6d1fad9f1d9 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -369,6 +369,21 @@ void intel_device_info_runtime_init_early(struct
> > drm_i915_private *i915)
> > intel_device_info_subplatform_init(i915);
> > }
> >
> > +static void disable_fused_off_display(struct drm_i915_private *i915)
> > +{
> > + struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
> > +
> > + drm_info(&i915->drm, "Display fused off, disabling\n");
> > +
> > + runtime->pipe_mask = 0;
> > + runtime->cpu_transcoder_mask = 0;
> > + runtime->fbc_mask = 0;
> > + runtime->has_hdcp = 0;
> > + runtime->fbc_mask = 0;
> > + runtime->has_dmc = 0;
> > + runtime->has_dsc = 0;
> > +}
> > +
> > /**
> > * intel_device_info_runtime_init - initialize runtime info
> > * @dev_priv: the i915 device
> > @@ -454,11 +469,7 @@ void intel_device_info_runtime_init(struct
> > drm_i915_private *dev_priv)
> > sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
> > (HAS_PCH_CPT(dev_priv) &&
> > !(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
> > - drm_info(&dev_priv->drm,
> > -"Display fused off, disabling\n");
> > - runtime->pipe_mask = 0;
> > - runtime->cpu_transcoder_mask = 0;
> > - runtime->fbc_mask = 0;
> > + disable_fused_off_display(dev_priv);
> > } else if (fuse_strap & IVB_PIPE_C_DISABLE) {
> > drm_info(&dev_priv->drm, "PipeC fused off\n");
> > runtime->pipe_mask &= ~BIT(PIPE_C);
> > @@ -502,17 +513,8 @@ void intel_device_info_runtime_init(struct
> > drm_i915_private *dev_priv)
> > }
> >
> > if ((IS_DGFX(dev_priv) || DISPLAY_VER(dev_priv) >= 14) &&
> > - !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT)) {
> > - drm_info(&dev_priv->drm, "Display fused off, disabling\n");
> > -
> > - runtime->pipe_mask = 0;
> > - runtime->cpu_transcoder_mask = 0;
> > - runtime->fbc_mask = 0;
> > - runtime->has_hdcp = 0;
> > - runtime->fbc_mask = 0;
> > - runtime->has_dmc = 0;
> > - runtime->has_dsc = 0;
> > - }
> > + !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT))
> > + disable_fused_off_display(dev_priv);
> >
> > if (GRAPHICS_VER(dev_priv) == 6 && i915_vtd_active(dev_priv)) {
> > drm_info(&dev_priv->drm,
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dgfx, mtl+: Disable display functionality if it's globally fused-off
On Tue, 07 Feb 2023, Imre Deak wrote: > On Tue, Feb 07, 2023 at 12:17:59PM +0200, Jani Nikula wrote: >> Please drop all of these. There's an if (!HAS_DISPLAY()) just a few >> lines down the purpose of which is to cover all of it in a unified >> manner. > > Yes, missed this and just did the same as on older platforms above. I > guess > > runtime->cpu_transcoder_mask = 0; > runtime->fbc_mask = 0; > > could be removed from there as well then. Agreed. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Mon, Feb 06, 2023 at 07:42:32PM -0500, Lyude Paul wrote:
> On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote:
> >
> > Yes, this patch should have no functional change, so please check what
> > would apply to other drivers as well.
> >
> > Could you also check Ville's comment about storing start_slot elsewhere
> > than the atomic state (leaving only time_slots there). I wonder if that
> > would work, at least it would simplify things I think.
>
> Ideally it'd be nice if we could have all this info in the atomic commit, but
> yeah - you're not the first person to find this a bit confusing. FWIW though,
> the way we store start_slot right now is intended to follow the same kind of
> behavior we have with atomic CRTC commit dependencies, I think I also made it
> that way so all of the state would be in a single place but there's no hard
> requirement for it.
As I understood the atomic state should be precomputed during atomic
check and not changed later during the commit phase. In case of
start_slot this would mean knowing in advance the actual (driver
specific) disabling / enabling sequence of the payloads, not sure how
feasible it is to figure that out. start_slot also changes dynamically
as each payload is disabled, so these intermediate versions of the field
would need to be tracked somehow separately from the final (precomputed)
versions.
> So if you guys think it'd be better design-wise to store this something else,
> I've got no strong feelings either way
> >
> > > For 0-2:
> > >
> > > Reviewed-by: Lyude Paul
> >
> > Thanks.
> >
> > >
> > > >
> > > > Cc: Lyude Paul
> > > > Cc: Ville Syrjälä
> > > > Cc: Ben Skeggs
> > > > Cc: Karol Herbst
> > > > Cc: Harry Wentland
> > > > Cc: Alex Deucher
> > > > Cc: Wayne Lin
> > > > Cc: sta...@vger.kernel.org # 6.1
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Reviewed-by: Ville Syrjälä
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> > > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > > > include/drm/display/drm_dp_mst_helper.h | 3 ++-
> > > > 5 files changed, 21 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > index a50319fc42b11..180d3893b68da 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > @@ -208,7 +208,7 @@ bool
> > > > dm_helpers_dp_mst_write_payload_allocation_table(
> > > > if (enable)
> > > > drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> > > > else
> > > > - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> > > > + drm_dp_remove_payload(mst_mgr, mst_state, payload,
> > > > payload);
> > > >
> > > > /* mst_mgr->->payloads are VC payload notify MST branch using
> > > > DPCD or
> > > > * AUX message. The sequence is slot 1-63 allocated sequence
> > > > for each
> > > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > index 847c10aa2098c..1990ff5dc7ddd 100644
> > > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > > @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > > * drm_dp_remove_payload() - Remove an MST payload
> > > > * @mgr: Manager to use.
> > > > * @mst_state: The MST atomic state
> > > > - * @payload: The payload to write
> > > > + * @old_payload: The payload with its old state
> > > > + * @new_payload: The payload to write
> > > > *
> > > > * Removes a payload from an MST topology if it was successfully
> > > > assigned a start slot. Also updates
> > > > * the starting time slots of all other payloads which would have been
> > > > shifted towards the start of
> > > > @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > > */
> > > > void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> > > >struct drm_dp_mst_topology_state *mst_state,
> > > > - struct drm_dp_mst_atomic_payload *payload)
> > > > + const struct drm_dp_mst_atomic_payload
> > > > *old_payload,
> > > > + struct drm_dp_mst_atomic_payload
> > > > *new_payload)
> > > > {
> > > > struct drm_dp_mst_atomic_payload *pos;
> > > > bool send_remove = false;
> > > >
> > > > /* We failed to make the payload, so nothing to do */
> > > > - if (payload->vc_start_slot == -1)
> > > > + if (new_payload->vc_start_slot == -1)
> > > > return;
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: drop "ucode" from function names
== Series Details ==
Series: drm/i915/dmc: drop "ucode" from function names
URL : https://patchwork.freedesktop.org/series/113735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12708 -> Patchwork_113735v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/index.html
Participating hosts (36 -> 35)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113735v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-rpls-2}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-rpls-2/igt@i915_selftest@l...@migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/bat-rpls-2/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_113735v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334] /
[i915#7872])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@i915_selftest@live@workarounds:
- {bat-dg2-11}: [DMESG-WARN][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [FAIL][7] ([i915#6298]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
Build changes
-
* Linux: CI_DRM_12708 -> Patchwork_113735v1
CI-20190529: 20190529
CI_DRM_12708: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113735v1: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
94d9ee3f75c3 drm/i915/dmc: drop "ucode" from function names
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/index.html
[Intel-gfx] [PATCH 1/4] drm/i915/gt: add sparse lock annotation to avoid warnings
Annotate intel_gt_mcr_lock() and intel_gt_mcr_unlock() to fix sparse
warnings:
drivers/gpu/drm/i915/gt/intel_gt_mcr.c:397:9: warning: context imbalance in
'intel_gt_mcr_lock' - wrong count at exit
drivers/gpu/drm/i915/gt/intel_gt_mcr.c:412:6: warning: context imbalance in
'intel_gt_mcr_unlock' - unexpected unlock
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 169393a7ad88..a4a8b8bc5737 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -364,6 +364,7 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
* function call.
*/
void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
+ __acquires(>->mcr_lock)
{
unsigned long __flags;
int err = 0;
@@ -410,6 +411,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long
*flags)
* Context: Releases gt->mcr_lock
*/
void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
+ __releases(>->mcr_lock)
{
spin_unlock_irqrestore(>->mcr_lock, flags);
--
2.34.1
[Intel-gfx] [PATCH 3/4] drm/i915/syncmap: squelch a sparse warning
The code is fine, really, but tweak it to get rid of the sparse warning:
drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/selftests/i915_syncmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index 47f4ae18a1ef..88fa845e9f4a 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -77,7 +77,7 @@ __sync_print(struct i915_syncmap *p,
for_each_set_bit(i, (unsigned long *)&p->bitmap, KSYNCMAP) {
buf = __sync_print(__sync_child(p)[i], buf, sz,
depth + 1,
- last << 1 | !!(p->bitmap >> (i + 1)),
+ last << 1 | ((p->bitmap >> (i + 1))
? 1 : 0),
i);
}
}
--
2.34.1
[Intel-gfx] [PATCH 2/4] drm/i915/uncore: cast iomem to avoid sparse warning
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs
to be a plain void *. Cast __iomem away and back while the pointer goes
through drmm.
drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in
argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_uncore.c:2463:17:expected void volatile
[noderef] __iomem *addr
drivers/gpu/drm/i915/intel_uncore.c:2463:17:got void *regs
drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in
argument 3 (different address spaces)
drivers/gpu/drm/i915/intel_uncore.c:2494:16:expected void *data
drivers/gpu/drm/i915/intel_uncore.c:2494:16:got void [noderef] __iomem *regs
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_uncore.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 8dee9e62a73e..f018da7ebaac 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2460,7 +2460,7 @@ static int i915_pmic_bus_access_notifier(struct
notifier_block *nb,
static void uncore_unmap_mmio(struct drm_device *drm, void *regs)
{
- iounmap(regs);
+ iounmap((void __iomem *)regs);
}
int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t phys_addr)
@@ -2491,7 +2491,8 @@ int intel_uncore_setup_mmio(struct intel_uncore *uncore,
phys_addr_t phys_addr)
return -EIO;
}
- return drmm_add_action_or_reset(&i915->drm, uncore_unmap_mmio,
uncore->regs);
+ return drmm_add_action_or_reset(&i915->drm, uncore_unmap_mmio,
+ (void __force *)uncore->regs);
}
void intel_uncore_init_early(struct intel_uncore *uncore,
--
2.34.1
[Intel-gfx] [PATCH 4/4] drm/i915/pxp: fix __le64 access to get rid of sparse warning
__le64 and friends should go through the cpu_to_* and *_to_cpu accessors: drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35:expected restricted __le64 [assigned] [usertype] huc_base_address drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35:got unsigned long long [assigned] [usertype] huc_phys_addr Cc: Tomas Winkler Cc: Alan Previn Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c index 64609d1b1c0f..23431c36b60b 100644 --- a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c @@ -38,7 +38,7 @@ int intel_pxp_huc_load_and_auth(struct intel_pxp *pxp) huc_in.header.command_id = PXP43_CMDID_START_HUC_AUTH; huc_in.header.status = 0; huc_in.header.buffer_len = sizeof(huc_in.huc_base_address); - huc_in.huc_base_address = huc_phys_addr; + huc_in.huc_base_address = cpu_to_le64(huc_phys_addr); err = intel_pxp_tee_stream_message(pxp, client_id, fence_id, &huc_in, sizeof(huc_in), -- 2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: set default backlight controller index
== Series Details ==
Series: drm/i915/bios: set default backlight controller index
URL : https://patchwork.freedesktop.org/series/113736/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12708 -> Patchwork_113736v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/index.html
Participating hosts (36 -> 33)
--
Additional (1): bat-atsm-1
Missing(4): fi-kbl-soraka fi-bsw-nick fi-snb-2520m fi-pnv-d510
Known issues
Here are the changes found in Patchwork_113736v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@workarounds:
- {bat-dg2-11}: [DMESG-WARN][1] -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [FAIL][3] ([i915#6298]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[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#5251]: https://gitlab.freedesktop.org/drm/intel/issues/5251
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#8000]: https://gitlab.freedesktop.org/drm/intel/issues/8000
[i915#8060]: https://gitlab.freedesktop.org/drm/intel/issues/8060
[i915#8062]: https://gitlab.freedesktop.org/drm/intel/issues/8062
Build changes
-
* Linux: CI_DRM_12708 -> Patchwork_113736v1
CI-20190529: 20190529
CI_DRM_12708: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113736v1: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
d5a9c60c1b95 drm/i915/bios: set default backlight controller index
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/index.html
Re: [Intel-gfx] [PATCH 4/4] drm/i915/pxp: fix __le64 access to get rid of sparse warning
> __le64 and friends should go through the cpu_to_* and *_to_cpu > accessors: > > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35: warning: incorrect type in > assignment (different base types) > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35:expected restricted > __le64 [assigned] [usertype] huc_base_address > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c:41:35:got unsigned long long > [assigned] [usertype] huc_phys_addr > > Cc: Tomas Winkler > Cc: Alan Previn > Signed-off-by: Jani Nikula Reviewed-by: Tomas Winkler > --- > drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c > b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c > index 64609d1b1c0f..23431c36b60b 100644 > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_huc.c > @@ -38,7 +38,7 @@ int intel_pxp_huc_load_and_auth(struct intel_pxp > *pxp) > huc_in.header.command_id = PXP43_CMDID_START_HUC_AUTH; > huc_in.header.status = 0; > huc_in.header.buffer_len = sizeof(huc_in.huc_base_address); > - huc_in.huc_base_address = huc_phys_addr; > + huc_in.huc_base_address = cpu_to_le64(huc_phys_addr); > > err = intel_pxp_tee_stream_message(pxp, client_id, fence_id, > &huc_in, sizeof(huc_in), > -- > 2.34.1
Re: [Intel-gfx] [CI 1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
Hi all,
On Mon, Feb 06, 2023 at 01:48:53PM +0200, Imre Deak wrote:
> Add the MST topology for a CRTC to the atomic state if the driver
> needs to force a modeset on the CRTC after the encoder compute config
> functions are called.
>
> Later the MST encoder's disable hook also adds the state, but that isn't
> guaranteed to work (since in that hook getting the state may fail, which
> can't be handled there). This should fix that, while a later patch fixes
> the use of the MST state in the disable hook.
>
> v2: Add missing forward struct declartions, caught by hdrtest.
> v3: Factor out intel_dp_mst_add_topology_state_for_connector() used
> later in the patchset.
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: sta...@vger.kernel.org # 6.1
> Reviewed-by: Ville Syrjälä # v2
> Reviewed-by: Lyude Paul
> Signed-off-by: Imre Deak
Is it ok to merge these 4 patches (also at [1]), via the i915 tree?
If so could it be also acked from the AMD and Nouveau side?
[1] https://patchwork.freedesktop.org/series/113703/
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 61
> drivers/gpu/drm/i915/display/intel_dp_mst.h | 4 ++
> 3 files changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 12ade593c..38106cf63b3b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5936,6 +5936,10 @@ int intel_modeset_all_pipes(struct intel_atomic_state
> *state,
> if (ret)
> return ret;
>
> + ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
> + if (ret)
> + return ret;
> +
> ret = intel_atomic_add_affected_planes(state, crtc);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8b0e4defa3f10..f3cb12dcfe0a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -1223,3 +1223,64 @@ bool intel_dp_mst_is_slave_trans(const struct
> intel_crtc_state *crtc_state)
> return crtc_state->mst_master_transcoder != INVALID_TRANSCODER &&
> crtc_state->mst_master_transcoder != crtc_state->cpu_transcoder;
> }
> +
> +/**
> + * intel_dp_mst_add_topology_state_for_connector - add MST topology state
> for a connector
> + * @state: atomic state
> + * @connector: connector to add the state for
> + * @crtc: the CRTC @connector is attached to
> + *
> + * Add the MST topology state for @connector to @state.
> + *
> + * Returns 0 on success, negative error code on failure.
> + */
> +static int
> +intel_dp_mst_add_topology_state_for_connector(struct intel_atomic_state
> *state,
> + struct intel_connector *connector,
> + struct intel_crtc *crtc)
> +{
> + struct drm_dp_mst_topology_state *mst_state;
> +
> + if (!connector->mst_port)
> + return 0;
> +
> + mst_state = drm_atomic_get_mst_topology_state(&state->base,
> +
> &connector->mst_port->mst_mgr);
> + if (IS_ERR(mst_state))
> + return PTR_ERR(mst_state);
> +
> + mst_state->pending_crtc_mask |= drm_crtc_mask(&crtc->base);
> +
> + return 0;
> +}
> +
> +/**
> + * intel_dp_mst_add_topology_state_for_crtc - add MST topology state for a
> CRTC
> + * @state: atomic state
> + * @crtc: CRTC to add the state for
> + *
> + * Add the MST topology state for @crtc to @state.
> + *
> + * Returns 0 on success, negative error code on failure.
> + */
> +int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_connector *_connector;
> + struct drm_connector_state *conn_state;
> + int i;
> +
> + for_each_new_connector_in_state(&state->base, _connector, conn_state,
> i) {
> + struct intel_connector *connector =
> to_intel_connector(_connector);
> + int ret;
> +
> + if (conn_state->crtc != &crtc->base)
> + continue;
> +
> + ret = intel_dp_mst_add_topology_state_for_connector(state,
> connector, crtc);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.h
> b/drivers/gpu/drm/i915/display/intel_dp_mst.h
> index f7301de6cdfb3..f1815bb722672 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.h
> @@ -8,6 +8,8 @@
>
> #include
>
> +struct intel_atomic_state;
> +struct intel_crtc;
> struct intel_crtc_state;
> struct intel_digital_port;
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] intel_gpu_top: Rename STDOUT to TEXT
On 2023-02-03 at 11:16:35 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Internal cleanup only - the name text is more accurate given the output
> can also go to a file.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Caleb Callaway
Lgtm,
Reviewed-by: Kamil Konieczny
> ---
> tools/intel_gpu_top.c | 54 +--
> 1 file changed, 26 insertions(+), 28 deletions(-)
>
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index e2a7f4753099..a980cc7043dc 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -1282,7 +1282,7 @@ usage(const char *appname)
>
> static enum {
> INTERACTIVE,
> - STDOUT,
> + TEXT,
> JSON
> } output_mode;
>
> @@ -1387,33 +1387,31 @@ json_add_member(const struct cnt_group *parent,
> struct cnt_item *item,
> return 1;
> }
>
> -static unsigned int stdout_level;
> +static unsigned int text_level;
>
> -#define STDOUT_HEADER_REPEAT 20
> -static unsigned int stdout_lines = STDOUT_HEADER_REPEAT;
> -static bool stdout_header_repeat;
> +#define TEXT_HEADER_REPEAT 20
> +static unsigned int text_lines = TEXT_HEADER_REPEAT;
> +static bool text_header_repeat;
>
> -static void
> -stdout_open_struct(const char *name)
> +static void text_open_struct(const char *name)
> {
> - stdout_level++;
> - assert(stdout_level > 0);
> + text_level++;
> + assert(text_level > 0);
> }
>
> -static void
> -stdout_close_struct(void)
> +static void text_close_struct(void)
> {
> - assert(stdout_level > 0);
> - if (--stdout_level == 0) {
> - stdout_lines++;
> + assert(text_level > 0);
> + if (--text_level == 0) {
> + text_lines++;
> fputs("\n", out);
> fflush(out);
> }
> }
>
> static unsigned int
> -stdout_add_member(const struct cnt_group *parent, struct cnt_item *item,
> - unsigned int headers)
> +text_add_member(const struct cnt_group *parent, struct cnt_item *item,
> + unsigned int headers)
> {
> unsigned int fmt_tot = item->fmt_width + (item->fmt_precision ? 1 : 0);
> char buf[fmt_tot + 1];
> @@ -1565,10 +1563,10 @@ static const struct print_operations json_pops = {
> .print_group = print_group,
> };
>
> -static const struct print_operations stdout_pops = {
> - .open_struct = stdout_open_struct,
> - .close_struct = stdout_close_struct,
> - .add_member = stdout_add_member,
> +static const struct print_operations text_pops = {
> + .open_struct = text_open_struct,
> + .close_struct = text_close_struct,
> + .add_member = text_add_member,
> .print_group = print_group,
> };
>
> @@ -1584,9 +1582,9 @@ static bool print_groups(struct cnt_group **groups)
> static bool headers_printed = false;
> bool print_data = true;
>
> - if (output_mode == STDOUT &&
> - (stdout_header_repeat || !headers_printed)) {
> - unsigned int headers = stdout_lines % STDOUT_HEADER_REPEAT + 1;
> + if (output_mode == TEXT &&
> + (text_header_repeat || !headers_printed)) {
> + unsigned int headers = text_lines % TEXT_HEADER_REPEAT + 1;
>
> if (headers == 1 || headers == 2)
> for (struct cnt_group **grp = groups; *grp; grp++)
> @@ -2492,7 +2490,7 @@ int main(int argc, char **argv)
> list_device = true;
> break;
> case 'l':
> - output_mode = STDOUT;
> + output_mode = TEXT;
> break;
> case 'h':
> usage(argv[0]);
> @@ -2505,7 +2503,7 @@ int main(int argc, char **argv)
> }
>
> if (output_mode == INTERACTIVE && (output_path || isatty(1) != 1))
> - output_mode = STDOUT;
> + output_mode = TEXT;
>
> if (output_path && strcmp(output_path, "-")) {
> out = fopen(output_path, "w");
> @@ -2519,7 +2517,7 @@ int main(int argc, char **argv)
> out = stdout;
> }
>
> - stdout_header_repeat = output_mode == STDOUT && isatty(fileno(out));
> + text_header_repeat = output_mode == TEXT && isatty(fileno(out));
>
> if (signal(SIGINT, sigint_handler) == SIG_ERR)
> fprintf(stderr, "Failed to install signal handler!\n");
> @@ -2531,8 +2529,8 @@ int main(int argc, char **argv)
> pops = &term_pops;
> interactive_stdin();
> break;
> - case STDOUT:
> - pops = &stdout_pops;
> + case TEXT:
> + pops = &text_pops;
> break;
> case JSON:
> pops = &json_pops;
> --
> 2.34.1
>
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable YCbCr420 for VDSC
== Series Details ==
Series: Enable YCbCr420 for VDSC
URL : https://patchwork.freedesktop.org/series/113729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12707_full -> Patchwork_113729v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/index.html
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113729v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium_hpd@dp-hpd-for-each-pipe:
- {shard-rkl}:[SKIP][1] ([i915#7828]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@kms_chamelium_...@dp-hpd-for-each-pipe.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-5/igt@kms_chamelium_...@dp-hpd-for-each-pipe.html
* igt@kms_cursor_crc@cursor-random-256x85:
- {shard-rkl}:[SKIP][3] ([i915#4098]) -> [SKIP][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@kms_cursor_...@cursor-random-256x85.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-5/igt@kms_cursor_...@cursor-random-256x85.html
Known issues
Here are the changes found in Patchwork_113729v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +8 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-glk4/igt@kms_...@dsc-with-bpc-formats.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#79])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@fbdev@info:
- {shard-tglu}: [SKIP][12] ([i915#2582]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-tglu-6/igt@fb...@info.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-tglu-1/igt@fb...@info.html
* igt@fbdev@nullptr:
- {shard-rkl}:[SKIP][14] ([i915#2582]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-3/igt@fb...@nullptr.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-6/igt@fb...@nullptr.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][16] ([i915#6252]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-1/igt@gem_ctx_persiste...@hang.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19] +3 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-1/igt@gem_exec_fair@basic-none-...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-5/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-cpu:
- {shard-rkl}:[SKIP][20] ([i915#3281]) -> [PASS][21] +11 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-2/igt@gem_exec_re...@basic-gtt-cpu.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-cpu.html
* igt@gem_readwrite@beyond-eob:
- {shard-rkl}:[SKIP][22] ([i915#3282]) -> [PASS][23] +2 similar
issues
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/shard-rkl-6
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings
== Series Details == Series: series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings URL : https://patchwork.freedesktop.org/series/113738/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./drivers/gpu/drm/i915/intel_uncore.h:344:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:345:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:347:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:349:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:350:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:351:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:351:1: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced
Re: [Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Do not repeat header lines in non-interactive output
On 2023-02-03 at 11:16:34 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> If output is redirected to a file, or a pipe, lets not repeat the headers
> because that can usually mean user is trying to parse the data later and
> so repeated headers are a hindrance.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Caleb Callaway
Reviewed-by: Kamil Konieczny
> ---
> tools/intel_gpu_top.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index 0a1de41b3374..e2a7f4753099 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -1391,6 +1391,7 @@ static unsigned int stdout_level;
>
> #define STDOUT_HEADER_REPEAT 20
> static unsigned int stdout_lines = STDOUT_HEADER_REPEAT;
> +static bool stdout_header_repeat;
>
> static void
> stdout_open_struct(const char *name)
> @@ -1580,16 +1581,22 @@ static const struct print_operations term_pops = {
>
> static bool print_groups(struct cnt_group **groups)
> {
> - unsigned int headers = stdout_lines % STDOUT_HEADER_REPEAT + 1;
> + static bool headers_printed = false;
> bool print_data = true;
>
> - if (output_mode == STDOUT && (headers == 1 || headers == 2)) {
> - for (struct cnt_group **grp = groups; *grp; grp++)
> - print_data = pops->print_group(*grp, headers);
> + if (output_mode == STDOUT &&
> + (stdout_header_repeat || !headers_printed)) {
> + unsigned int headers = stdout_lines % STDOUT_HEADER_REPEAT + 1;
> +
> + if (headers == 1 || headers == 2)
> + for (struct cnt_group **grp = groups; *grp; grp++)
> + print_data = pops->print_group(*grp, headers);
> +
> + headers_printed = print_data;
> }
>
> for (struct cnt_group **grp = groups; print_data && *grp; grp++)
> - pops->print_group(*grp, false);
> + pops->print_group(*grp, 0);
>
> return print_data;
> }
> @@ -2512,6 +2519,8 @@ int main(int argc, char **argv)
> out = stdout;
> }
>
> + stdout_header_repeat = output_mode == STDOUT && isatty(fileno(out));
> +
> if (signal(SIGINT, sigint_handler) == SIG_ERR)
> fprintf(stderr, "Failed to install signal handler!\n");
>
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Add CSV output format
On 2023-02-03 at 11:31:19 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Add CSV output mode.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Caleb Callaway
Reviewed-by: Kamil Konieczny
> ---
> man/intel_gpu_top.rst | 3 ++
> tools/intel_gpu_top.c | 78 +--
> 2 files changed, 78 insertions(+), 3 deletions(-)
>
> diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
> index 69834756b81e..2d041457a95e 100644
> --- a/man/intel_gpu_top.rst
> +++ b/man/intel_gpu_top.rst
> @@ -31,6 +31,9 @@ OPTIONS
> -h
> Show help text.
>
> +-c
> +Output CSV formatted data.
> +
> -J
> Output JSON formatted data.
>
> diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
> index a980cc7043dc..2e1365959d8b 100644
> --- a/tools/intel_gpu_top.c
> +++ b/tools/intel_gpu_top.c
> @@ -1268,6 +1268,7 @@ usage(const char *appname)
> "\n"
> "\tThe following parameters are optional:\n\n"
> "\t[-h]Show this help text.\n"
> + "\t[-c]Output CSV formatted data.\n"
> "\t[-J]Output JSON formatted data.\n"
> "\t[-l]List plain text data.\n"
> "\t[-o ] Output to specified file or '-' for standard
> out.\n"
> @@ -1283,6 +1284,7 @@ usage(const char *appname)
> static enum {
> INTERACTIVE,
> TEXT,
> + CSV,
> JSON
> } output_mode;
>
> @@ -1457,6 +1459,22 @@ text_add_member(const struct cnt_group *parent, struct
> cnt_item *item,
> return len > 0 ? len : 0;
> }
>
> +static unsigned int
> +csv_add_member(const struct cnt_group *parent, struct cnt_item *item,
> +unsigned int headers)
> +{
> + int len = 0;
> +
> + if (headers)
> + fprintf(out, "%s %s", parent->display_name, item->unit);
> + else
> + len = fprintf(out, "%f",
> + pmu_calc(&item->pmu->val, item->d, item->t,
> +item->s));
> +
> + return len > 0 ? len : 0;
> +}
> +
> static void
> term_open_struct(const char *name)
> {
> @@ -1540,6 +1558,46 @@ print_group(struct cnt_group *grp, unsigned int
> headers)
> return consumed;
> }
>
> +static unsigned int csv_count, prev_csv_count;
> +
> +static void csv_close_struct(void)
> +{
> + assert(text_level > 0);
> + if (--text_level == 0) {
> + csv_count = prev_csv_count = 0;
> + text_lines++;
> + fputs("\n", out);
> + fflush(out);
> + }
> +}
> +
> +static bool
> +csv_print_group(struct cnt_group *grp, unsigned int headers)
> +{
> + unsigned int consumed = 0;
> + struct cnt_item *item;
> +
> + if (!present_in_group(grp))
> + return false;
> +
> + text_open_struct(grp->name);
> +
> + for (item = grp->items; item->name; item++) {
> + if (!item->pmu || !item->pmu->present)
> + continue;
> +
> + if (csv_count != prev_csv_count)
> + fprintf(out, ",");
> + prev_csv_count = csv_count++;
> +
> + consumed += csv_add_member(grp, item, headers);
> + }
> +
> + csv_close_struct();
> +
> + return consumed;
> +}
> +
> static bool
> term_print_group(struct cnt_group *grp, unsigned int headers)
> {
> @@ -1570,6 +1628,13 @@ static const struct print_operations text_pops = {
> .print_group = print_group,
> };
>
> +static const struct print_operations csv_pops = {
> + .open_struct = text_open_struct,
> + .close_struct = csv_close_struct,
> + .add_member = csv_add_member,
> + .print_group = csv_print_group,
> +};
> +
> static const struct print_operations term_pops = {
> .open_struct = term_open_struct,
> .close_struct = term_close_struct,
> @@ -1582,11 +1647,12 @@ static bool print_groups(struct cnt_group **groups)
> static bool headers_printed = false;
> bool print_data = true;
>
> - if (output_mode == TEXT &&
> + if ((output_mode == TEXT || output_mode == CSV) &&
> (text_header_repeat || !headers_printed)) {
> + const unsigned int header_lines = output_mode == TEXT ? 2 : 1;
> unsigned int headers = text_lines % TEXT_HEADER_REPEAT + 1;
>
> - if (headers == 1 || headers == 2)
> + if (headers > 0 && headers <= header_lines)
> for (struct cnt_group **grp = groups; *grp; grp++)
> print_data = pops->print_group(*grp, headers);
>
> @@ -2469,7 +2535,7 @@ int main(int argc, char **argv)
> char *codename = NULL;
>
> /* Parse options */
> - while ((ch = getopt(argc, argv, "o:s:d:pJLlh")) != -1) {
> + while ((ch = getopt(argc, argv, "o:s:d:pcJLlh")) != -1) {
> switch (ch) {
> case 'o':
> output_path = optarg;
> @@ -2483,6 +2549,9 @@ int main(int argc, char **argv)
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: add sparse lock annotation to
avoid warnings
URL : https://patchwork.freedesktop.org/series/113738/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12708 -> Patchwork_113738v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113738v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113738v1, 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_113738v1/index.html
Participating hosts (36 -> 36)
--
Additional (1): bat-adls-5
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113738v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-skl-guc: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_113738v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334] /
[i915#7872])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][5] ([i915#6367]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
- {bat-adln-1}: [DMESG-FAIL][7] ([i915#6997]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-adln-1/igt@i915_selftest@l...@slpc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v1/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@i915_selftest@live@workarounds:
- {bat-dg2-11}: [DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v1/bat-dg2-11/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#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
Build changes
-
* Linux: CI_DRM_12708 -> Patchwork_113738v1
CI-20190529: 20190529
CI_DRM_12708: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113738v1: e9426d9d1eeb72f84725043dd2a9e073d9a6f1d7 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
aca857cd3324 drm/i915/pxp: fix __le64 access to get rid of sparse warning
4f6355c50deb drm/i915/syncmap: squelch a sparse warning
4b2d7248e2a7 drm/i915/uncore: cast iomem to avoid sparse warning
04cbf603e3a8 drm/i915/gt: add sparse lock annotation to avoid warnings
== Logs ==
F
[Intel-gfx] PR for MTL DMC v2.11
The following changes since commit 5c11a3742947810ee8bffbd476eb5a1b0c7999f2: amdgpu: Add VCN 4.0.2 firmware (2023-01-25 07:40:41 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware dmc-mtl_2.11 for you to fetch changes up to c1181ae796970b6b48218bd2bdb9392fab0e070f: i915: Add DMC v2.11 for MTL (2023-02-07 09:13:10 -0300) Gustavo Sousa (1): i915: Add DMC v2.11 for MTL WHENCE | 3 +++ i915/mtl_dmc.bin | Bin 0 -> 48512 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/mtl_dmc.bin
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: drop "ucode" from function names
== Series Details ==
Series: drm/i915/dmc: drop "ucode" from function names
URL : https://patchwork.freedesktop.org/series/113735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12708_full -> Patchwork_113735v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113735v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_dsc@dsc-basic}:
- {shard-tglu}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-tglu-6/igt@kms_...@dsc-basic.html
Known issues
Here are the changes found in Patchwork_113735v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][2] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk9/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_lmem_swapping@massive:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk1/igt@gem_lmem_swapp...@massive.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1937])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk1/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
* igt@kms_big_fb@linear-16bpp-rotate-90:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk1/igt@kms_big...@linear-16bpp-rotate-90.html
* igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk1/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#72])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
Possible fixes
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- {shard-rkl}:[SKIP][11] ([i915#6252]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-rkl-3/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][13] ([i915#6247]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +11 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-1/igt@gem_exec_re...@basic-gtt-read-noreloc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read-noreloc.html
* igt@gem_partial_pwrite_pread@writes-after-reads:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +4 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-1/igt@gem_partial_pwrite_pr...@writes-after-reads.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113735v1/shard-rkl-5/igt@ge
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings (rev2)
== Series Details == Series: series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings (rev2) URL : https://patchwork.freedesktop.org/series/113738/ State : warning == Summary == Error: dim checkpatch failed 8edcb86cabc5 drm/i915/gt: add sparse lock annotation to avoid warnings -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/gt: add sparse lock annotation to avoid warnings total: 0 errors, 1 warnings, 0 checks, 14 lines checked 696eed2f8526 drm/i915/uncore: cast iomem to avoid sparse warning -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/uncore: cast iomem to avoid sparse warning total: 0 errors, 1 warnings, 0 checks, 17 lines checked d59ef2d2dff8 drm/i915/syncmap: squelch a sparse warning -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/syncmap: squelch a sparse warning total: 0 errors, 1 warnings, 0 checks, 8 lines checked bc636b1cb3b3 drm/i915/pxp: fix __le64 access to get rid of sparse warning -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/pxp: fix __le64 access to get rid of sparse warning total: 0 errors, 1 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [PATCH v3] drm/i915: add guard page to ggtt->error_capture
Hi Andrzej,
On Mon, Feb 06, 2023 at 10:03:27AM +0100, Andrzej Hajda wrote:
> Write-combining memory allows speculative reads by CPU.
> ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
> to prefetch memory beyond the error_capture, ie it tries
> to read memory pointed by next PTE in GGTT.
> If this PTE points to invalid address DMAR errors will occur.
> This behaviour was observed on ADL, RPL, DG2 platforms.
> To avoid it, guard scratch page should be added after error_capture.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Thanks,
Andi
> ---
> This patch tries to diminish plague of DMAR read errors present
> in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
> CI is usually tolerant for these errors, so the scale of the problem
> is not really visible.
> To show it I have counted lines containing DMAR read errors in dmesgs
> produced by CI for all three versions of the patch, but in contrast to v2
> I have grepped only for lines containing "PTE Read access".
> Below stats for kernel w/o patch vs patched one.
> v1: 210 vs 0
> v2: 201 vs 0
> v3: 214 vs 0
> Apparently the patch fixes all common PTE read errors.
>
> In previous version there were different numbers due to less exact grepping,
> "grep DMAR" catched write errors and "DMAR: DRHD: handling fault status reg"
> lines, anyway the actual number of errors is much bigger - DMAR errors
> are rate-limited.
>
> [1]:
> http://gfx-ci.igk.intel.com/tree/drm-tip/CI_DRM_12678/bat-adln-1/dmesg0.txt
>
> Changelog:
> v2:
> - modified commit message (I hope the diagnosis is correct),
> - added bug checks to ensure scratch is initialized on gen3 platforms.
> CI produces strange stacktrace for it suggesting scratch[0] is NULL,
> to be removed after resolving the issue with gen3 platforms.
> v3:
> - removed bug checks, replaced with gen check.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 +---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 842e69c7b21e49..15eb2d4158d679 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -503,6 +503,13 @@ static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
> mutex_destroy(&ggtt->error_mutex);
> }
>
> +static void ggtt_insert_scratch_page(struct i915_ggtt *ggtt, u64 offset)
> +{
> + struct i915_address_space *vm = &ggtt->vm;
> +
> + vm->insert_page(vm, px_dma(vm->scratch[0]), offset, I915_CACHE_NONE, 0);
> +}
> +
> static int init_ggtt(struct i915_ggtt *ggtt)
> {
> /*
> @@ -553,6 +560,13 @@ static int init_ggtt(struct i915_ggtt *ggtt)
>* bug, which we expect to cause other failures...
>*/
> ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
> + /*
> + * Since CPU can perform speculative reads on error capture
> + * (write-combining allows it) and since gen12 it really happens
> + * add scratch page after error capture to avoid DMAR errors.
> + */
> + if (GRAPHICS_VER(ggtt->vm.i915) >= 12)
> + ggtt->error_capture.size += I915_GTT_PAGE_SIZE;
> ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
> if (drm_mm_reserve_node(&ggtt->vm.mm, &ggtt->error_capture))
> drm_mm_insert_node_in_range(&ggtt->vm.mm,
> @@ -562,11 +576,21 @@ static int init_ggtt(struct i915_ggtt *ggtt)
> 0, ggtt->mappable_end,
> DRM_MM_INSERT_LOW);
> }
> - if (drm_mm_node_allocated(&ggtt->error_capture))
> + if (drm_mm_node_allocated(&ggtt->error_capture)) {
> + u64 start = ggtt->error_capture.start;
> + u64 end = ggtt->error_capture.start + ggtt->error_capture.size;
> + u64 i;
> +
> + /*
> + * During error capture, memcpying from the GGTT is triggering a
> + * prefetch of the following PTE, so fill it with a guard page.
> + */
> + for (i = start + I915_GTT_PAGE_SIZE; i < end; i +=
> I915_GTT_PAGE_SIZE)
> + ggtt_insert_scratch_page(ggtt, i);
> drm_dbg(&ggtt->vm.i915->drm,
> "Reserved GGTT:[%llx, %llx] for use by error capture\n",
> - ggtt->error_capture.start,
> - ggtt->error_capture.start + ggtt->error_capture.size);
> + start, end);
> + }
>
> /*
>* The upper portion of the GuC address space has a sizeable hole
> --
> 2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: add sparse lock annotation to
avoid warnings (rev2)
URL : https://patchwork.freedesktop.org/series/113738/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709 -> Patchwork_113738v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/index.html
Participating hosts (39 -> 36)
--
Missing(3): fi-kbl-soraka bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113738v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@dmabuf:
- fi-bsw-nick:[PASS][1] -> [ABORT][2] ([i915#7913])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
Possible fixes
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [ABORT][3] ([i915#7977]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlm-1}: [FAIL][5] ([i915#7948]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-adlm-1/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: [DMESG-FAIL][7] ([i915#4258]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@gt_timelines:
- {bat-adlm-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
* igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}: [ABORT][11] ([i915#7913]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][13] ([i915#6367] / [i915#7996]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adlm-1}: [DMESG-WARN][15] -> [PASS][16] +6 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7948]: https://gitlab.freedesktop.org/drm/intel/issues/7948
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12709 -> Patchwork_113738v2
CI-20190529: 20190529
CI_DRM_12709: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113738v2: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
###
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: set default backlight controller index
== Series Details ==
Series: drm/i915/bios: set default backlight controller index
URL : https://patchwork.freedesktop.org/series/113736/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12708_full -> Patchwork_113736v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113736v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-glk7/igt@gem_exec_fair@basic-n...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-glk6/igt@gem_exec_fair@basic-n...@vecs0.html
Possible fixes
* igt@fbdev@read:
- {shard-rkl}:[SKIP][3] ([i915#2582]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@fb...@read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-6/igt@fb...@read.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][5] ([i915#6252]) -> [PASS][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][7] ([i915#6247]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-6/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][9] ([i915#2842]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_reloc@basic-cpu-read-active:
- {shard-rkl}:[SKIP][11] ([i915#3281]) -> [PASS][12] +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-3/igt@gem_exec_re...@basic-cpu-read-active.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-5/igt@gem_exec_re...@basic-cpu-read-active.html
* igt@i915_pm_rpm@drm-resources-equal:
- {shard-tglu}: [SKIP][13] ([i915#3547]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-tglu-6/igt@i915_pm_...@drm-resources-equal.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-tglu-4/igt@i915_pm_...@drm-resources-equal.html
* igt@i915_selftest@live@hangcheck:
- {shard-rkl}:[INCOMPLETE][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-3/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-180:
- {shard-tglu}: [SKIP][17] ([i915#1845] / [i915#7651]) -> [PASS][18]
+2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-tglu-6/igt@kms_big...@y-tiled-16bpp-rotate-180.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-tglu-4/igt@kms_big...@y-tiled-16bpp-rotate-180.html
* igt@kms_flip@2x-flip-vs-expired-vblank@ab-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][19] ([i915#79]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@ab-hdmi-a1-hdmi-a2.html
* igt@kms_frontbuffer_tracking@psr-indfb-scaledprimary:
- {shard-rkl}:[SKIP][21] ([i915#1849] / [i915#4098]) -> [PASS][22]
+6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-5/igt@kms_frontbuffer_track...@psr-indfb-scaledprimary.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113736v1/shard-rkl-6/igt@kms_frontbuffer_track...@psr-indfb-scaledprimary.html
* igt@kms_plane@pixel-format-source-clamping@pipe-b-planes:
- {shard-rkl}:[SKIP][23] ([i915#1849]) -> [PASS][24] +1 similar
issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12708/shard-rkl-4/igt@kms_plane@pixel-format-source-clamp...@pip
[Intel-gfx] [PATCH v3 0/3] Provision to ignore long HPDs in CI systems
Some panels generate long HPDs during CI execution steps even while connected to the system and cause unexpected CI execution failures. In environments like CI, we don't expect to disconnect the panels in the middle of the CI execution. There are two parts to handle this case - display driver and IGT 1. In the display driver, based on a flag, long HPDs are ignored. This flag can be set/unset using debugfs on systems where such panels are connected. Also random link training issues are popping up because of spurious HPDs, ignore the link training failures as well if the ignore long HPD is set. 2. In IGT, add provision to set ignore long HPD debugfs entry on the driver and also set Force "on" the active connectors. With force on, the connector's detect sequences will not get initiated. This patchset address the driver part to handle this issue. Vinod Govindapillai (3): drm/i915/display: ignore long HPDs based on a flag drm/i915/display: debugfs entry to control ignore long hpd flag drm/i915/display: ignore link training failures in CI .../gpu/drm/i915/display/intel_display_core.h | 11 +++ .../drm/i915/display/intel_dp_link_training.c | 24 ++ drivers/gpu/drm/i915/display/intel_hotplug.c | 32 +++ 3 files changed, 67 insertions(+) -- 2.34.1
[Intel-gfx] [PATCH v3 2/3] drm/i915/display: debugfs entry to control ignore long hpd flag
Knob to control ignoring the long hpds. Set this to true will
start ignoring the long HPDs generated by the displays. Useful
for use cases like CI systems where we dont expect to disconnect
the panels.
v2: Address patch styling comments (Jani Nikula)
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 25
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index f0a2aa648bb8..41372a10288c 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -939,6 +939,29 @@ static const struct file_operations
i915_hpd_short_storm_ctl_fops = {
.write = i915_hpd_short_storm_ctl_write,
};
+static int i915_ignore_long_hpd_set(void *data, u64 val)
+{
+ struct drm_i915_private *i915 = data;
+
+ drm_dbg_kms(&i915->drm, "Ignoring long HPDs: %s\n", str_yes_no(val));
+
+ i915->display.hotplug.ignore_long_hpd = val;
+
+ return 0;
+}
+
+static int i915_ignore_long_hpd_get(void *data, u64 *val)
+{
+ struct drm_i915_private *i915 = data;
+
+ *val = i915->display.hotplug.ignore_long_hpd;
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_ignore_long_hpd_fops, i915_ignore_long_hpd_get,
+ i915_ignore_long_hpd_set, "%llu\n");
+
void intel_hpd_debugfs_register(struct drm_i915_private *i915)
{
struct drm_minor *minor = i915->drm.primary;
@@ -947,4 +970,6 @@ void intel_hpd_debugfs_register(struct drm_i915_private
*i915)
i915, &i915_hpd_storm_ctl_fops);
debugfs_create_file("i915_hpd_short_storm_ctl", 0644,
minor->debugfs_root,
i915, &i915_hpd_short_storm_ctl_fops);
+ debugfs_create_file("i915_ignore_long_hpd", 0644, minor->debugfs_root,
+ i915, &i915_ignore_long_hpd_fops);
}
--
2.34.1
[Intel-gfx] [PATCH v3 1/3] drm/i915/display: ignore long HPDs based on a flag
Some panels generate long HPD events even while connected to
the port. This cause some unexpected CI execution issues. A
new flag is added to track if such spurious long HPDs can be
ignored and are not processed further if the flag is set.
v2: Address patch styling comments (Jani Nikula)
v3: Ignoring the HPD moved to hotplug handler and now applies
to all types of outputs (Imre Deak)
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_display_core.h | 11 +++
drivers/gpu/drm/i915/display/intel_hotplug.c | 7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fb8670aa2932..251f774bd590 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -182,6 +182,17 @@ struct intel_hotplug {
* blocked behind the non-DP one.
*/
struct workqueue_struct *dp_wq;
+
+ /*
+* Flag to track if long HPDs need not to be processed
+*
+* Some panels generate long HPDs while keep connected to the port.
+* This can cause issues with CI tests results. In CI systems we
+* don't expect to disconnect the panels and could ignore the long
+* HPDs generated from the faulty panels. This flag can be used as
+* cue to ignore the long HPDs and can be set / unset using debugfs.
+*/
+ bool ignore_long_hpd;
};
struct intel_vbt_data {
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 907ab7526cb4..f0a2aa648bb8 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -389,6 +389,13 @@ static void i915_hotplug_work_func(struct work_struct
*work)
spin_unlock_irq(&dev_priv->irq_lock);
+ /* Skip calling encode hotplug handlers if ignore long HPD set*/
+ if (dev_priv->display.hotplug.ignore_long_hpd) {
+ drm_dbg_kms(&dev_priv->drm, "Ignore HPD flag on - skip encoder
hotplug handlers\n");
+ mutex_unlock(&dev_priv->drm.mode_config.mutex);
+ return;
+ }
+
drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
enum hpd_pin pin;
--
2.34.1
[Intel-gfx] [PATCH v3 3/3] drm/i915/display: ignore link training failures in CI
If the ignore long HPD flag is set, ignore the link training
failures as well. Because of spurious HPDs, some unexpected link
training failures are happening while executing IGT test cases.
Ignore the link training failures for the time being if the long
HPDs are also ignored in the environments like CI.
Signed-off-by: Vinod Govindapillai
---
.../drm/i915/display/intel_dp_link_training.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 3d3efcf02011..f90c627ab553 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1433,7 +1433,11 @@ intel_dp_128b132b_link_train(struct intel_dp *intel_dp,
void intel_dp_start_link_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_connector *connector = intel_dp->attached_connector;
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
bool passed;
+
/*
* TODO: Reiniting LTTPRs here won't be needed once proper connector
* HW state readout is added.
@@ -1451,6 +1455,26 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
else
passed = intel_dp_link_train_all_phys(intel_dp, crtc_state,
lttpr_count);
+ /*
+* Ignore the link failure in CI
+*
+* In fixed enviroments like CI, sometimes unexpected long HPDs are
+* generated by the displays. If ignore_long_hpd flag is set, such long
+* HPDs are ignored. And probably as a consequence of these ignored
+* long HPDs, subsequent link trainings are failed resulting into CI
+* execution failures.
+*
+* For test cases which rely on the link training or processing of HPDs
+* ignore_long_hpd flag can unset from the testcase.
+*/
+ if (!passed && i915->display.hotplug.ignore_long_hpd) {
+ drm_dbg_kms(&i915->drm,
+ "[CONNECTOR:%d:%s][ENCODER:%d:%s] Ignore the link
failure\n",
+ connector->base.base.id, connector->base.name,
+ encoder->base.base.id, encoder->base.name);
+ return;
+ }
+
if (!passed)
intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
}
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
>
> On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit wrote:
> >
> > Previous documentation suggested that PL1 power limit is always
> > enabled. However we now find this not to be the case on some
> > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > initialization.
>
> For some reason it looks like this change is impacting the atsm in CI:
> https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
ATSM and see if I can figure out what might be going on with these
seemingly unrelated failures and if I can repro them locally. Thanks!
>
> >
> > Bspec: 51864
> >
> > v2: Add Bspec reference (Gwan-gyeong)
> > v3: Add Fixes tag
> >
> > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > Signed-off-by: Ashutosh Dixit
> > Reviewed-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 1225bc432f0d5..4683a5b96eff1 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private
> > *i915)
> > for_each_gt(gt, i915, i)
> > hwm_energy(&hwmon->ddat_gt[i], &energy);
> > }
> > +
> > + /* Enable PL1 power limit */
> > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > hwmon->rg.pkg_rapl_limit,
> > + PKG_PWR_LIM_1_EN,
> > PKG_PWR_LIM_1_EN);
> > }
> >
> > void i915_hwmon_register(struct drm_i915_private *i915)
> > --
> > 2.38.0
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for Provision to ignore long HPDs in CI systems (rev4)
== Series Details ==
Series: Provision to ignore long HPDs in CI systems (rev4)
URL : https://patchwork.freedesktop.org/series/109475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709 -> Patchwork_109475v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_109475v4 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}: [ABORT][1] ([i915#5251] / [i915#6311] / [i915#7359])
-> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [ABORT][3] ([i915#7977]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlm-1}: [FAIL][5] ([i915#7948]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-adlm-1/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: [DMESG-FAIL][7] ([i915#4258]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@gt_timelines:
- {bat-adlm-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
* igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}: [ABORT][11] ([i915#7913]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adlm-1}: [DMESG-WARN][13] -> [PASS][14] +6 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5251]: https://gitlab.freedesktop.org/drm/intel/issues/5251
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7948]: https://gitlab.freedesktop.org/drm/intel/issues/7948
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
Build changes
-
* Linux: CI_DRM_12709 -> Patchwork_109475v4
CI-20190529: 20190529
CI_DRM_12709: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_109475v4: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freed
Re: [Intel-gfx] [PATCH v2 04/21] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
On Thu, Jan 05, 2023 at 02:54:29PM +0200, 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(&i915->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(&i915->uncore,
> + XELPDP_PORT_P2M_MSGBUS_STATUS(port,
> lane-1),
>
Re: [Intel-gfx] [PATCH v2 06/21] drm/i915/mtl: Add vswing programming for C10 phys
I feel like some parts of this patch actually belong to previous patches as
fixups instead, namely the implementation and usage of
intel_cx0_phy_transaction_{begin,end}() and other fixes unrelated to vswing
programming.
Also, please see some comments inline.
On Thu, Jan 05, 2023 at 02:54:31PM +0200, Mika Kahola wrote:
> 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(&i915->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, &val);
>
> @@ -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);
Shouldn't we check if this encoder is really for DP before calling
intel_psr_{pause,resume}()?
> + 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;
>
Re: [Intel-gfx] [PATCH v2 08/21] drm/i915/mtl: C20 PLL programming
On Thu, Jan 05, 2023 at 02:54:33PM +0200, Mika Kahola wrote:
> 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)
I think it would be better to name this function intel_c20_sram_write(), so
there is no confusion about the semantics of intel_cx0_write() vs
intel_c20_write().
Technically, this is for both SRAM and CREG registers, but I think just using
"sram" in the function name is enough to make the distinction. We could add a
comment one deems necessary.
> +{
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, (addr >> 8) &
> 0xff, 0);
I think the 0xff mask is unnecessary here.
> + 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);
Also here I think the 0xff mask is unnecessary.
> + 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 =
> &crtc_state->c10mpllb_state;
> + const struct intel_c10mpllb_state *pll_state =
> &crtc_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)
> +{
> +
Re: [Intel-gfx] [PATCH v2 09/21] drm/i915/mtl: C20 HW readout
On Thu, Jan 05, 2023 at 02:54:34PM +0200, Mika Kahola wrote:
> 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)
Similar to my comment for intel_c20_write(), I think it would be better to name
this function intel_c20_sram_read().
Also, this function is indented with spaces instead of tabs.
> +{
> + 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);
Looks like the 0xff maks is unnecessary here.
Also, does the byte order matter here? The diagram for the read operation in the
BSpec suggests writing the higher part of the address first and then the lower
part.
> +
> + 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 c
Re: [Intel-gfx] [PATCH v2 14/21] drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll
On Thu, Jan 05, 2023 at 02:54:39PM +0200, Mika Kahola wrote:
> 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(&i915->uncore,
> XELPDP_PORT_CLOCK_CTL(encoder->port),
> + XELPDP_TBT_CLOCK_ACK,
> + XELPDP_TBT_CLOCK_ACK,
> + 100, 0, NULL))
> + drm_warn(&i915->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)
> {
> struc
[Intel-gfx] [PATCH] drm/i915/display/selftest: Add pcode selftest
From: Mohammed Khajapasha
Include pcode selftest for display to validate QGV points read.
Failure of this selftest indicates a bad firmware rather than regular
display issue.
Cc: Stanislav Lisovskiy
Cc: Matt Roper
Signed-off-by: Mohammed Khajapasha
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_bw.c | 4 ++
.../drm/i915/display/selftests/selftest_bw.c | 54 +++
.../i915/display/selftests/selftest_display.c | 18 +++
.../i915/display/selftests/selftest_display.h | 6 +++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
6 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_bw.c
create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_display.c
create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_display.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 918470a04591..aa7d34b3f71c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -350,7 +350,8 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
selftests/igt_mmap.o \
selftests/igt_reset.o \
selftests/igt_spinner.o \
- selftests/librapl.o
+ selftests/librapl.o \
+ display/selftests/selftest_display.o
# virtual gpu code
i915-y += i915_vgpu.o
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 202321ffbe2a..b0bfe04f2835 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -1211,3 +1211,7 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
return 0;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftests/selftest_bw.c"
+#endif
diff --git a/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
b/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
new file mode 100644
index ..69d52201bd9b
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include "display/intel_bw.h"
+#include "i915_drv.h"
+#include "i915_selftest.h"
+#include "soc/intel_dram.h"
+#include "selftest_display.h"
+
+/**
+ * intel_pcode_read_qgv_points_read_test - Test QGV point reads from pcode
+ * @arg: i915 device instance
+ *
+ * Return 0 on success and error on fail and when dclk is zero
+ */
+int intel_pcode_read_qgv_points_test(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_qgv_info qi;
+ struct intel_qgv_point qp;
+ int i, ret;
+ bool fail = false;
+ intel_wakeref_t wakeref;
+
+ if (DISPLAY_VER(i915) < 11) {
+ drm_info(&i915->drm, "QGV doesn't support, skipping\n");
+ return 0;
+ }
+
+ with_intel_runtime_pm(i915->uncore.rpm, wakeref)
+ intel_dram_detect(i915);
+
+ qi.num_points = i915->dram_info.num_qgv_points;
+
+ for (i = 0; i < qi.num_points; i++) {
+ ret = intel_read_qgv_point_info(i915, &qp, i);
+ if (ret) {
+ drm_err(&i915->drm, "Pcode failed to read qgv point
%d\n", i);
+ fail = true;
+ }
+
+ if (qp.dclk == 0) {
+ drm_err(&i915->drm, "DCLK set to 0 for qgv point %d\n",
i);
+ fail = true;
+ }
+ }
+
+ if (fail)
+ return -EINVAL;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/display/selftests/selftest_display.c
b/drivers/gpu/drm/i915/display/selftests/selftest_display.c
new file mode 100644
index ..1663c69f9ddc
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/selftests/selftest_display.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include "i915_selftest.h"
+
+#include "selftest_display.h"
+
+int intel_display_live_selftests(struct drm_i915_private *i915)
+{
+ static const struct i915_subtest tests[] = {
+ SUBTEST(intel_pcode_read_qgv_points_test),
+ };
+
+ return i915_subtests(tests, i915);
+}
diff --git a/drivers/gpu/drm/i915/display/selftests/selftest_display.h
b/drivers/gpu/drm/i915/display/selftests/selftest_display.h
new file mode 100644
index ..c8d80d5945bb
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/selftests/selftest_display.h
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+int intel_pcode_read_qgv_points_test(void *arg);
diff --git a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
index 5aee6c9a8295..8f980483cca8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_live_selftests.h
@@ -42,6 +42,7 @@
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 07 Feb 2023 08:12:25 -0800, Dixit, Ashutosh wrote:
>
> On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
> >
> > On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit
> > wrote:
> > >
> > > Previous documentation suggested that PL1 power limit is always
> > > enabled. However we now find this not to be the case on some
> > > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > > initialization.
> >
> > For some reason it looks like this change is impacting the atsm in CI:
> > https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
>
> Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
> ATSM and see if I can figure out what might be going on with these
> seemingly unrelated failures and if I can repro them locally. Thanks!
Rodrigo/Matt,
I am proposing we revert this now and remerge again after investigating,
even getting ATSM systems to investigate is not easy so it might take a few
days to investigate. What do you guys think?
Thanks.
--
Ashutosh
>
> >
> > >
> > > Bspec: 51864
> > >
> > > v2: Add Bspec reference (Gwan-gyeong)
> > > v3: Add Fixes tag
> > >
> > > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > Signed-off-by: Ashutosh Dixit
> > > Reviewed-by: Gwan-gyeong Mun
> > > ---
> > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > index 1225bc432f0d5..4683a5b96eff1 100644
> > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private
> > > *i915)
> > > for_each_gt(gt, i915, i)
> > > hwm_energy(&hwmon->ddat_gt[i], &energy);
> > > }
> > > +
> > > + /* Enable PL1 power limit */
> > > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > > hwmon->rg.pkg_rapl_limit,
> > > + PKG_PWR_LIM_1_EN,
> > > PKG_PWR_LIM_1_EN);
> > > }
> > >
> > > void i915_hwmon_register(struct drm_i915_private *i915)
> > > --
> > > 2.38.0
> > >
[Intel-gfx] [PATCH] drm: Disable dynamic debug as broken
From: Ville Syrjälä
CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
drm drivers. The debug prints can be reinstated by manually frobbing
/sys/module/drm/parameters/debug after the fact, but at that point the
damage is done and all debugs from driver probe are lost. This makes
drivers totally undebuggable.
There's a more complete fix in progress [1], with further details, but
we need this fixed in stable kernels. Mark the feature as broken and
disable it by default, with hopes distros follow suit and disable it as
well.
[1] https://lore.kernel.org/r/20230125203743.564009-1-jim.cro...@gmail.com
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
macro")
Cc: Jim Cromie
Cc: Greg Kroah-Hartman
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Cc: # v6.1+
Signed-off-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f42d4c6a19f2..dc0f94f02a82 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -52,7 +52,8 @@ config DRM_DEBUG_MM
config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
- default y
+ default n
+ depends on BROKEN
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
--
2.34.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/selftest: Add pcode selftest
== Series Details == Series: drm/i915/display/selftest: Add pcode selftest URL : https://patchwork.freedesktop.org/series/113745/ State : warning == Summary == Error: dim checkpatch failed d149647441a7 drm/i915/display/selftest: Add pcode selftest Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:42: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #42: new file mode 100644 -:131: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for 'drivers/gpu/drm/i915/display/selftests/selftest_display.h', please use '/*' instead #131: FILE: drivers/gpu/drm/i915/display/selftests/selftest_display.h:1: +// SPDX-License-Identifier: MIT -:131: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #131: FILE: drivers/gpu/drm/i915/display/selftests/selftest_display.h:1: +// SPDX-License-Identifier: MIT total: 0 errors, 3 warnings, 0 checks, 101 lines checked
Re: [Intel-gfx] [PATCH v2 06/21] drm/i915/mtl: Add vswing programming for C10 phys
On Tue, Feb 07, 2023 at 01:52:20PM -0300, Gustavo Sousa wrote:
> I feel like some parts of this patch actually belong to previous patches as
> fixups instead, namely the implementation and usage of
> intel_cx0_phy_transaction_{begin,end}() and other fixes unrelated to vswing
> programming.
>
> Also, please see some comments inline.
>
> On Thu, Jan 05, 2023 at 02:54:31PM +0200, Mika Kahola wrote:
> > 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(&i915->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, &val);
> >
> > @@ -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);
>
> Shouldn't we check if this encoder is really for DP before calling
> intel_psr_{pause,resume}()?
>
> > + 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;
> > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/selftest: Add pcode selftest
== Series Details ==
Series: drm/i915/display/selftest: Add pcode selftest
URL : https://patchwork.freedesktop.org/series/113745/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709 -> Patchwork_113745v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/index.html
Participating hosts (39 -> 36)
--
Missing(3): fi-kbl-soraka bat-atsm-1 fi-snb-2520m
New tests
-
New tests have been introduced between CI_DRM_12709 and Patchwork_113745v1:
### New IGT tests (1) ###
* igt@i915_selftest@live@display:
- Statuses : 35 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_113745v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [ABORT][1] ([i915#7977]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlm-1}: [FAIL][3] ([i915#7948]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-adlm-1/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: [DMESG-FAIL][5] ([i915#4258]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@gt_timelines:
- {bat-adlm-1}: [DMESG-WARN][7] ([i915#2867]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
* igt@i915_selftest@live@hangcheck:
- {bat-dg2-11}: [ABORT][9] ([i915#7913]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adlm-1}: [DMESG-WARN][11] -> [PASS][12] +6 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7948]: https://gitlab.freedesktop.org/drm/intel/issues/7948
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
Build changes
-
* Linux: CI_DRM_12709 -> Patchwork_113745v1
CI-20190529: 20190529
CI_DRM_12709: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113745v1: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
721c3b2c464e drm/i915/display/selftest: Add pcode selftest
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/index.html
Re: [Intel-gfx] [PATCH] drm: Disable dynamic debug as broken
On Tue, Feb 07, 2023 at 04:33:37PM +0200, Jani Nikula wrote:
> From: Ville Syrjälä
>
> CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
> drm drivers. The debug prints can be reinstated by manually frobbing
> /sys/module/drm/parameters/debug after the fact, but at that point the
> damage is done and all debugs from driver probe are lost. This makes
> drivers totally undebuggable.
>
> There's a more complete fix in progress [1], with further details, but
> we need this fixed in stable kernels. Mark the feature as broken and
> disable it by default, with hopes distros follow suit and disable it as
> well.
>
> [1] https://lore.kernel.org/r/20230125203743.564009-1-jim.cro...@gmail.com
>
> Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
> macro")
> Cc: Jim Cromie
> Cc: Greg Kroah-Hartman
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Cc: # v6.1+
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f42d4c6a19f2..dc0f94f02a82 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -52,7 +52,8 @@ config DRM_DEBUG_MM
>
> config DRM_USE_DYNAMIC_DEBUG
> bool "use dynamic debug to implement drm.debug"
> - default y
> + default n
> + depends on BROKEN
> depends on DRM
> depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> depends on JUMP_LABEL
Acked-by: Greg Kroah-Hartman
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Disable dynamic debug as broken
== Series Details == Series: drm: Disable dynamic debug as broken URL : https://patchwork.freedesktop.org/series/113746/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915/gt: add sparse lock annotation to avoid warnings (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: add sparse lock annotation to
avoid warnings (rev2)
URL : https://patchwork.freedesktop.org/series/113738/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709_full -> Patchwork_113738v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113738v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@unwedge-stress:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-tglu-4/igt@gem_...@unwedge-stress.html
Known issues
Here are the changes found in Patchwork_113738v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2346])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-glk7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-glk2/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#79])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
Possible fixes
* igt@fbdev@eof:
- {shard-rkl}:[SKIP][9] ([i915#2582]) -> [PASS][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-5/igt@fb...@eof.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-rkl-6/igt@fb...@eof.html
- {shard-tglu}: [SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@fb...@eof.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-tglu-8/igt@fb...@eof.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gem_exec_fair@basic-none-r...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-glk7/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_reloc@basic-cpu-noreloc:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +3 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-6/igt@gem_exec_re...@basic-cpu-noreloc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-rkl-5/igt@gem_exec_re...@basic-cpu-noreloc.html
* igt@gem_exec_whisper@basic-fds-priority-all:
- {shard-dg1}:[ABORT][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-dg1-14/igt@gem_exec_whis...@basic-fds-priority-all.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113738v2/shard-dg1-18/igt@gem_exec_whis...@basic-fds-priority-all.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +6 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gem_partial_pwrite_pr...@writes-afte
[Intel-gfx] [linux-next:master] BUILD REGRESSION 49a8133221c71b935f36a7c340c0271c2a9ee2db
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 49a8133221c71b935f36a7c340c0271c2a9ee2db Add linux-next specific files for 20230207 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301301801.y5o08tqx-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301302110.metnwkbd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301310939.tagcoezb-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302011836.ka3bxqdy-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302061911.c7xvhx9v-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302062224.byzetxh1-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302072055.odjdvd5v-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/riscv/uabi.rst:24: WARNING: Enumerated list ends without a blank line; unexpected unindent. ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! FAILED: load BTF from vmlinux: No data available arch/arm64/kvm/arm.c:2207: warning: expecting prototype for Initialize Hyp(). Prototype was for kvm_arm_init() instead drivers/clk/qcom/gcc-sa8775p.c:313:32: warning: unused variable 'gcc_parent_map_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:318:37: warning: unused variable 'gcc_parent_data_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:333:32: warning: unused variable 'gcc_parent_map_12' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:338:37: warning: unused variable 'gcc_parent_data_12' [-Wunused-const-variable] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:62:10: fatal error: mod_info_packet.h: No such file or directory drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_hubbub.c:1011:6: warning: no previous prototype for 'hubbub31_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubbub.c:948:6: warning: no previous prototype for 'hubbub32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubp.c:158:6: warning: no previous prototype for 'hubp32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource_helpers.c:62:18: warning: variable 'cursor_bpp' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:148:6: warning: no previous prototype for 'link_dp_trace_set_edp_power_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:158:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweron_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:163:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweroff_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1295:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:279:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] ftrace-ops.c:(.init.text+0x2c3): undefined reference to `__udivdi3' libbpf: failed to find '.BTF' ELF section in vmlinux Unverified Error/Warning (likely false positive, please contact us if interested): drivers/media/i2c/max9286.c:802 max9286_s_stream() error: buffer overflow 'priv->fmt' 4 <= 32 drivers/thermal/qcom/tsens-v0_1.c:106:40: sparse: sparse: symbol 'tsens_9607_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:26:40: sparse: sparse: symbol 'tsens_8916_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:42:40: sparse: sparse: symbol 'tsens_8939_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:62:40: sparse: sparse: symbol 'tsens_8974_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:84:40: sparse: sparse: symbol 'tsens_8974_backup_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:24:40: sparse: sparse: symbol 'tsens_qcs404_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:45:40: sparse: sparse: symbol 'tsens_8976_nvmem' was not declare
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Disable dynamic debug as broken
== Series Details ==
Series: drm: Disable dynamic debug as broken
URL : https://patchwork.freedesktop.org/series/113746/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709 -> Patchwork_113746v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/index.html
Participating hosts (39 -> 36)
--
Missing(3): bat-atsm-1 fi-snb-2520m fi-pnv-d510
Known issues
Here are the changes found in Patchwork_113746v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334] /
[i915#7872])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [ABORT][3] ([i915#7977]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlm-1}: [FAIL][5] ([i915#7948]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/bat-adlm-1/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_pm:
- {bat-adln-1}: [DMESG-FAIL][7] ([i915#4258]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adln-1/igt@i915_selftest@live@gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/bat-adln-1/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@gt_timelines:
- {bat-adlm-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/bat-adlm-1/igt@i915_selftest@live@gt_timelines.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-adlm-1}: [DMESG-WARN][11] -> [PASS][12] +6 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/bat-adlm-1/igt@i915_susp...@basic-s2idle-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[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#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7948]: https://gitlab.freedesktop.org/drm/intel/issues/7948
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
Build changes
-
* Linux: CI_DRM_12709 -> Patchwork_113746v1
CI-20190529: 20190529
CI_DRM_12709: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113746v1: 7560422b3d150a860b471c139319a64f01f336cc @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/index.html
Re: [Intel-gfx] [PATCH 1/4] drm/i915/pvc: Annotate two more workaround/tuning registers as MCR
On Wed, Feb 01, 2023 at 02:28:28PM -0800, Matt Roper wrote:
> XEHPC_LNCFMISCCFGREG0 and XEHPC_L3SCRUB are both in MCR register ranges
> on PVC (with HALFBSLICE and L3BANK replication respectively), so they
> should be explicitly declared as MCR registers and use MCR-aware
> workaround handlers.
>
> The workarounds/tuning settings should still be applied properly on PVC
> even without the MCR annotation, but readback verification on
> CONFIG_DRM_I915_DEBUG_GEM builds could potentitally give false positive
> "workaround lost on load" warnings on parts fused such that a unicast
> read targets a terminated register instance.
>
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +---
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 7fa18a3b3957..928698c621e5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -979,7 +979,7 @@
> #define GEN7_WA_FOR_GEN7_L3_CONTROL0x3C47FF8C
> #define GEN7_L3AGDIS (1 << 19)
>
> -#define XEHPC_LNCFMISCCFGREG0_MMIO(0xb01c)
> +#define XEHPC_LNCFMISCCFGREG0MCR_REG(0xb01c)
> #define XEHPC_HOSTCACHEEN REG_BIT(1)
> #define XEHPC_OVRLSCCC REG_BIT(0)
>
> @@ -1042,7 +1042,7 @@
> #define XEHP_L3SCQREG7 MCR_REG(0xb188)
> #define BLEND_FILL_CACHING_OPT_DIS REG_BIT(3)
>
> -#define XEHPC_L3SCRUB_MMIO(0xb18c)
> +#define XEHPC_L3SCRUBMCR_REG(0xb18c)
> #define SCRUB_CL_DWNGRADE_SHARED REG_BIT(12)
> #define SCRUB_RATE_PER_BANK_MASK REG_GENMASK(2, 0)
> #define SCRUB_RATE_4B_PER_CLK
> REG_FIELD_PREP(SCRUB_RATE_PER_BANK_MASK, 0x6)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 29718d0595f4..f45ca3d4a07c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -240,6 +240,12 @@ wa_write(struct i915_wa_list *wal, i915_reg_t reg, u32
> set)
> wa_write_clr_set(wal, reg, ~0, set);
> }
>
> +static void
> +wa_mcr_write(struct i915_wa_list *wal, i915_mcr_reg_t reg, u32 set)
> +{
> + wa_mcr_write_clr_set(wal, reg, ~0, set);
> +}
> +
> static void
> wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
> {
> @@ -2892,9 +2898,9 @@ add_render_compute_tuning_settings(struct
> drm_i915_private *i915,
> struct i915_wa_list *wal)
> {
> if (IS_PONTEVECCHIO(i915)) {
> - wa_write(wal, XEHPC_L3SCRUB,
> + wa_mcr_write(wal, XEHPC_L3SCRUB,
>SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> - wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> }
>
> if (IS_DG2(i915)) {
> @@ -2984,7 +2990,7 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
>
> if (IS_PONTEVECCHIO(i915)) {
> /* Wa_16016694945 */
> - wa_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> }
>
> if (IS_XEHPSDV(i915)) {
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
On Tue, 7 Feb 2023 at 17:19, Dixit, Ashutosh wrote:
>
> On Tue, 07 Feb 2023 08:12:25 -0800, Dixit, Ashutosh wrote:
> >
> > On Tue, 07 Feb 2023 01:32:44 -0800, Matthew Auld wrote:
> > >
> > > On Fri, 3 Feb 2023 at 15:54, Ashutosh Dixit
> > > wrote:
> > > >
> > > > Previous documentation suggested that PL1 power limit is always
> > > > enabled. However we now find this not to be the case on some
> > > > platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
> > > > initialization.
> > >
> > > For some reason it looks like this change is impacting the atsm in CI:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/bat-atsm-1.html
> >
> > Hmm, the change was meant for ATSM. Anyway let me try to get hold of an
> > ATSM and see if I can figure out what might be going on with these
> > seemingly unrelated failures and if I can repro them locally. Thanks!
>
> Rodrigo/Matt,
>
> I am proposing we revert this now and remerge again after investigating,
> even getting ATSM systems to investigate is not easy so it might take a few
> days to investigate. What do you guys think?
Yeah, maybe just revert for now.
>
> Thanks.
> --
> Ashutosh
>
>
> >
> > >
> > > >
> > > > Bspec: 51864
> > > >
> > > > v2: Add Bspec reference (Gwan-gyeong)
> > > > v3: Add Fixes tag
> > > >
> > > > Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting")
> > > > Signed-off-by: Ashutosh Dixit
> > > > Reviewed-by: Gwan-gyeong Mun
> > > > ---
> > > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > index 1225bc432f0d5..4683a5b96eff1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > > > @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct
> > > > drm_i915_private *i915)
> > > > for_each_gt(gt, i915, i)
> > > > hwm_energy(&hwmon->ddat_gt[i], &energy);
> > > > }
> > > > +
> > > > + /* Enable PL1 power limit */
> > > > + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > > > + hwm_locked_with_pm_intel_uncore_rmw(ddat,
> > > > hwmon->rg.pkg_rapl_limit,
> > > > + PKG_PWR_LIM_1_EN,
> > > > PKG_PWR_LIM_1_EN);
> > > > }
> > > >
> > > > void i915_hwmon_register(struct drm_i915_private *i915)
> > > > --
> > > > 2.38.0
> > > >
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: add sparse lock annotation to avoid warnings
On Tue, Feb 07, 2023 at 02:40:23PM +0200, Jani Nikula wrote:
> Annotate intel_gt_mcr_lock() and intel_gt_mcr_unlock() to fix sparse
> warnings:
>
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:397:9: warning: context imbalance in
> 'intel_gt_mcr_lock' - wrong count at exit
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c:412:6: warning: context imbalance in
> 'intel_gt_mcr_unlock' - unexpected unlock
>
> Cc: Matt Roper
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 169393a7ad88..a4a8b8bc5737 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -364,6 +364,7 @@ static u32 rw_with_mcr_steering(struct intel_gt *gt,
> * function call.
> */
> void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long *flags)
> + __acquires(>->mcr_lock)
Are these annotations supposed to take the lock itself or a pointer to
the lock as you're doing here? Or does it matter? It seems like
there's a mix of both forms elsewhere in the kernel and sparse.rst
doesn't really specify which is expected.
Assuming it's correct to provide a pointer to the lock in the
annotation,
Reviewed-by: Matt Roper
> {
> unsigned long __flags;
> int err = 0;
> @@ -410,6 +411,7 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long
> *flags)
> * Context: Releases gt->mcr_lock
> */
> void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned long flags)
> + __releases(>->mcr_lock)
> {
> spin_unlock_irqrestore(>->mcr_lock, flags);
>
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Fix GEN8_MISCCPCTL
On Mon, Feb 06, 2023 at 08:04:29PM +, Patchwork wrote:
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Fix GEN8_MISCCPCTL
URL : https://patchwork.freedesktop.org/series/113713/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12704 -> Patchwork_113713v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113713v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113713v1, 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_113713v1/index.html
Participating hosts (36 -> 34)
--
Missing(2): bat-atsm-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113713v1:
### IGT changes ###
Possible regressions
* igt@kms_flip@basic-flip-vs-modeset@b-dp1:
- fi-elk-e7500: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
unrelated fail. There were no changes between v1 and v2 except for the
commit message in the first patch. v1 got full pass:
https://patchwork.freedesktop.org/series/113626/
Also, looking at
https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html?testfilter=basic-flip-vs-modeset
It looks like this machine changed from DP to HDMI starting in
CI_DRM_12708?
Lucas De Marchi
Known issues
Here are the changes found in Patchwork_113713v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#7828])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [ABORT][4] ([i915#4983]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][6] ([i915#6367]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_busy@basic@modeset:
- fi-elk-e7500: [FAIL][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12704 -> Patchwork_113713v1
CI-20190529: 20190529
CI_DRM_12704: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113713v1: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
204afd36a3d7 drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATE
80322c878d54 drm/i915: Fix GEN8_MISCCPCTL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/index.html
Re: [Intel-gfx] [PATCH 2/4] drm/i915/uncore: cast iomem to avoid sparse warning
On Tue, Feb 07, 2023 at 02:40:24PM +0200, Jani Nikula wrote:
> drmm_add_action_or_reset() is unaware of __iomem and the pointer needs
> to be a plain void *. Cast __iomem away and back while the pointer goes
> through drmm.
>
> drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in
> argument 1 (different address spaces)
> drivers/gpu/drm/i915/intel_uncore.c:2463:17:expected void volatile
> [noderef] __iomem *addr
> drivers/gpu/drm/i915/intel_uncore.c:2463:17:got void *regs
> drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in
> argument 3 (different address spaces)
> drivers/gpu/drm/i915/intel_uncore.c:2494:16:expected void *data
> drivers/gpu/drm/i915/intel_uncore.c:2494:16:got void [noderef] __iomem
> *regs
>
> Cc: Matt Roper
> Signed-off-by: Jani Nikula
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 8dee9e62a73e..f018da7ebaac 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2460,7 +2460,7 @@ static int i915_pmic_bus_access_notifier(struct
> notifier_block *nb,
>
> static void uncore_unmap_mmio(struct drm_device *drm, void *regs)
> {
> - iounmap(regs);
> + iounmap((void __iomem *)regs);
> }
>
> int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t
> phys_addr)
> @@ -2491,7 +2491,8 @@ int intel_uncore_setup_mmio(struct intel_uncore
> *uncore, phys_addr_t phys_addr)
> return -EIO;
> }
>
> - return drmm_add_action_or_reset(&i915->drm, uncore_unmap_mmio,
> uncore->regs);
> + return drmm_add_action_or_reset(&i915->drm, uncore_unmap_mmio,
> + (void __force *)uncore->regs);
> }
>
> void intel_uncore_init_early(struct intel_uncore *uncore,
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.IGT: success for Provision to ignore long HPDs in CI systems (rev4)
== Series Details ==
Series: Provision to ignore long HPDs in CI systems (rev4)
URL : https://patchwork.freedesktop.org/series/109475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709_full -> Patchwork_109475v4_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_109475v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_dsc@dsc-basic}:
- {shard-tglu}: [SKIP][1] ([i915#3840]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-3/igt@kms_...@dsc-basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-tglu-6/igt@kms_...@dsc-basic.html
* igt@kms_vblank@pipe-d-ts-continuation-dpms-suspend:
- {shard-tglu-10}:NOTRUN -> [ABORT][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-tglu-10/igt@kms_vbl...@pipe-d-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_109475v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@gem_exec_fair@basic-n...@vecs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-glk9/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-glk9/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-glk2/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@fbdev@eof:
- {shard-tglu}: [SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@fb...@eof.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-tglu-3/igt@fb...@eof.html
* igt@gem_exec_reloc@basic-gtt-cpu-active:
- {shard-rkl}:[SKIP][13] ([i915#3281]) -> [PASS][14] +7 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-2/igt@gem_exec_re...@basic-gtt-cpu-active.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-rkl-5/igt@gem_exec_re...@basic-gtt-cpu-active.html
* igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:[SKIP][15] ([i915#7276]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gem_exec_sched...@semaphore-power.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-rkl-5/igt@gem_exec_sched...@semaphore-power.html
* igt@gem_exec_whisper@basic-fds-priority-all:
- {shard-dg1}:[ABORT][17] -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-dg1-14/igt@gem_exec_whis...@basic-fds-priority-all.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-dg1-18/igt@gem_exec_whis...@basic-fds-priority-all.html
* igt@gem_pread@bench:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +2 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-3/igt@gem_pr...@bench.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-rkl-5/igt@gem_pr...@bench.html
* igt@gen9_exec_parse@batch-invalid-length:
- {shard-rkl}:[SKIP][21] ([i915#2527]) -> [PASS][22] +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gen9_exec_pa...@batch-invalid-length.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v4/shard-rkl-5/igt@gen9_exec_pa...@batch-invalid
Re: [Intel-gfx] [PATCH 2/4] drm/i915/gen11: Wa_1408615072/Wa_1407596294 should be on GT list
On Wed, Feb 01, 2023 at 02:28:29PM -0800, Matt Roper wrote:
> The UNSLICE_UNIT_LEVEL_CLKGATE register programmed by this workaround
> has 'BUS' style reset, indicating that it does not lose its value on
> engine resets. Furthermore, this register is part of the GT forcewake
> domain rather than the RENDER domain, so it should not be impacted by
> RCS engine resets. As such, we should implement this on the GT
> workaround list rather than an engine list.
>
> Bspec: 19219
> Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index f45ca3d4a07c..7e93ba6b3208 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1405,6 +1405,13 @@ icl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> GAMT_CHKN_BIT_REG,
> GAMT_CHKN_DISABLE_L3_COH_PIPE);
>
> + /*
> + * Wa_1408615072:icl,ehl (vsunit)
> + * Wa_1407596294:icl,ehl (hsunit)
> + */
> + wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> + VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
> +
> /* Wa_1407352427:icl,ehl */
> wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE2,
> PSDUNIT_CLKGATE_DIS);
> @@ -2536,13 +2543,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> wa_masked_en(wal, GEN9_CSFE_CHICKEN1_RCS,
>GEN11_ENABLE_32_PLANE_MODE);
>
> - /*
> - * Wa_1408615072:icl,ehl (vsunit)
> - * Wa_1407596294:icl,ehl (hsunit)
> - */
> - wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> - VSUNIT_CLKGATE_DIS | HSUNIT_CLKGATE_DIS);
> -
> /*
>* Wa_1408767742:icl[a2..forever],ehl[all]
>* Wa_1605460711:icl[a0..c0]
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH] drm/i915/dmc: drop "ucode" from function names
On Tue, Feb 07, 2023 at 01:06:19PM +0200, Jani Nikula wrote:
> The ucode part in the init, fini, suspend and resume function names is
> just unnecessary. Drop it.
>
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_dmc.c | 20 ++--
> drivers/gpu/drm/i915/display/intel_dmc.h | 8
> drivers/gpu/drm/i915/i915_driver.c | 6 +++---
> 4 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 12ade593..a8c91fda40a8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8639,7 +8639,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
> *i915)
> if (!HAS_DISPLAY(i915))
> return 0;
>
> - intel_dmc_ucode_init(i915);
> + intel_dmc_init(i915);
>
> i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
> i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
> @@ -8674,7 +8674,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
> *i915)
> return 0;
>
> cleanup_vga_client_pw_domain_dmc:
> - intel_dmc_ucode_fini(i915);
> + intel_dmc_fini(i915);
> intel_power_domains_driver_remove(i915);
> intel_vga_unregister(i915);
> cleanup_bios:
> @@ -9000,7 +9000,7 @@ void intel_modeset_driver_remove_noirq(struct
> drm_i915_private *i915)
> /* part #3: call after gem init */
> void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915)
> {
> - intel_dmc_ucode_fini(i915);
> + intel_dmc_fini(i915);
>
> intel_power_domains_driver_remove(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 3b8e8193d042..f70ada2357dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -918,13 +918,13 @@ static void dmc_load_work_fn(struct work_struct *work)
> }
>
> /**
> - * intel_dmc_ucode_init() - initialize the firmware loading.
> + * intel_dmc_init() - initialize the firmware loading.
> * @dev_priv: i915 drm device.
> *
> * This function is called at the time of loading the display driver to read
> * firmware from a .bin file and copied into a internal memory.
> */
> -void intel_dmc_ucode_init(struct drm_i915_private *dev_priv)
> +void intel_dmc_init(struct drm_i915_private *dev_priv)
> {
> struct intel_dmc *dmc = &dev_priv->display.dmc;
>
> @@ -1002,14 +1002,14 @@ void intel_dmc_ucode_init(struct drm_i915_private
> *dev_priv)
> }
>
> /**
> - * intel_dmc_ucode_suspend() - prepare DMC firmware before system suspend
> + * intel_dmc_suspend() - prepare DMC firmware before system suspend
> * @dev_priv: i915 drm device
> *
> * Prepare the DMC firmware before entering system suspend. This includes
> * flushing pending work items and releasing any resources acquired during
> * init.
> */
> -void intel_dmc_ucode_suspend(struct drm_i915_private *dev_priv)
> +void intel_dmc_suspend(struct drm_i915_private *dev_priv)
> {
> if (!HAS_DMC(dev_priv))
> return;
> @@ -1022,13 +1022,13 @@ void intel_dmc_ucode_suspend(struct drm_i915_private
> *dev_priv)
> }
>
> /**
> - * intel_dmc_ucode_resume() - init DMC firmware during system resume
> + * intel_dmc_resume() - init DMC firmware during system resume
> * @dev_priv: i915 drm device
> *
> * Reinitialize the DMC firmware during system resume, reacquiring any
> - * resources released in intel_dmc_ucode_suspend().
> + * resources released in intel_dmc_suspend().
> */
> -void intel_dmc_ucode_resume(struct drm_i915_private *dev_priv)
> +void intel_dmc_resume(struct drm_i915_private *dev_priv)
> {
> if (!HAS_DMC(dev_priv))
> return;
> @@ -1042,20 +1042,20 @@ void intel_dmc_ucode_resume(struct drm_i915_private
> *dev_priv)
> }
>
> /**
> - * intel_dmc_ucode_fini() - unload the DMC firmware.
> + * intel_dmc_fini() - unload the DMC firmware.
> * @dev_priv: i915 drm device.
> *
> * Firmmware unloading includes freeing the internal memory and reset the
> * firmware loading status.
> */
> -void intel_dmc_ucode_fini(struct drm_i915_private *dev_priv)
> +void intel_dmc_fini(struct drm_i915_private *dev_priv)
> {
> enum intel_dmc_id dmc_id;
>
> if (!HAS_DMC(dev_priv))
> return;
>
> - intel_dmc_ucode_suspend(dev_priv);
> + intel_dmc_suspend(dev_priv);
> drm_WARN_ON(&dev_priv->drm, dev_priv->display.dmc.wakeref);
>
> for_each_dmc_id(dmc_id)
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
> b/drivers/gpu/drm/i915/display/intel_dmc.h
> index 88eae74dbcf2..c9808bbe7162 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.h
> +++ b/drivers/gpu/drm/i915/displa
Re: [Intel-gfx] [RFC] drm/i915/dp: Remove i915.enable_dp_mst module parameter
I wanted to add a note about why I initially proposed the modparam
enable_dp_mst: --
The problem I was facing is that an external DisplayPort adapter
(Sunix DPD2001: https://sunix.com/en/product_detail.php?pid=1720),
supporting both MST and SST, had no means of choosing SST
("splitting", single display) vs MST ("normal", additional display)
mode -- the MST mode is automatically selected if the graphics
advertised support, and SST otherwise. This presented and issue when
using two of these devices with e.g. Intel HD 4600, which supports a
maximum of three displays. At the time, disabling MST support was the
only mechanism [not yet] available to enable this setup. A
per-port/channel disable is great, as likely are the debugfs
improvements since.
Finally, Sunix actually provided me with a customized firmware that
disabled MST support in the device, enabling the quad-monitor setup in
this situation, though the ability of the user to control the
driver/mode is preferred. I'm happy to share this firmware if anyone
requests it.
I'm surprised and happy this modparam proved useful to others, and
glad it was accepted as a change.
Kudos,
--
Nathan
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display/selftest: Add pcode selftest
== Series Details ==
Series: drm/i915/display/selftest: Add pcode selftest
URL : https://patchwork.freedesktop.org/series/113745/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709_full -> Patchwork_113745v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
New tests
-
New tests have been introduced between CI_DRM_12709_full and
Patchwork_113745v1_full:
### New IGT tests (1) ###
* igt@i915_selftest@live@display:
- Statuses : 4 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_113745v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-glk7/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [FAIL][6] ([i915#2842]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_reloc@basic-write-read:
- {shard-rkl}:[SKIP][8] ([i915#3281]) -> [PASS][9] +6 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-2/igt@gem_exec_re...@basic-write-read.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-rkl-5/igt@gem_exec_re...@basic-write-read.html
* igt@gem_userptr_blits@forbidden-operations:
- {shard-rkl}:[SKIP][10] ([i915#3282]) -> [PASS][11] +4 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-2/igt@gem_userptr_bl...@forbidden-operations.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-rkl-5/igt@gem_userptr_bl...@forbidden-operations.html
* igt@gen9_exec_parse@shadow-peek:
- {shard-rkl}:[SKIP][12] ([i915#2527]) -> [PASS][13] +2 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-2/igt@gen9_exec_pa...@shadow-peek.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-rkl-5/igt@gen9_exec_pa...@shadow-peek.html
* igt@i915_pm_dc@dc5-psr:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-3/igt@i915_pm...@dc5-psr.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-rkl-6/igt@i915_pm...@dc5-psr.html
* igt@i915_pm_dc@dc6-dpms:
- {shard-rkl}:[SKIP][16] ([i915#3361]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-5/igt@i915_pm...@dc6-dpms.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-rkl-1/igt@i915_pm...@dc6-dpms.html
* igt@i915_pm_rpm@cursor-dpms:
- {shard-tglu}: [SKIP][18] ([i915#1849]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@i915_pm_...@cursor-dpms.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-tglu-1/igt@i915_pm_...@cursor-dpms.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-tglu}: [SKIP][20] ([i915#1397]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@i915_pm_...@modeset-lpsp.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/shard-tglu-1/igt@i915_pm_...@modeset-lpsp.html
* igt@i915_pm_rpm@pm-tiling:
- {shard-rkl}:[SKIP][22] ([fdo#109308]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-5/igt@i915_pm_...@pm-tiling.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113745v1/s
Re: [Intel-gfx] [PATCH 3/4] drm/i915/xehp: LNCF/LBCF workarounds should be on the GT list
On Wed, Feb 01, 2023 at 02:28:30PM -0800, Matt Roper wrote:
> Although registers in the L3 bank/node configuration ranges are marked
> as having "DEV" reset characteristics in the bspec, this appears to be a
> hold-over from pre-Xe_HP platforms. In reality, these registers
> maintain their values across engine resets, meaning that workarounds
> and tuning settings targetting them should be placed on the GT
> workaround list rather than an engine workaround list.
>
> Note that an extra clue here is that these registers moved from the
> RENDER forcewake domain to the GT forcewake domain in Xe_HP; generally
> RCS/CCS engine resets should not lead to the reset of a register that
> lives outside the RENDER domain.
Looked and it seems DG2 also has GT forcewake domain for XEHP_L3NODEARBCFG.
Shouldn't Wa_14010648519 be fixed as well then? Or am I missing
something?
>
> Re-applying these registers on engine resets wouldn't actually hurt
> anything, but is unnecessary and just makes it more confusing to anyone
> trying to decipher how these registers really work.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 61 +
> 1 file changed, 38 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 7e93ba6b3208..09c9837458b5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1499,6 +1499,12 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> /* Wa_1409757795:xehpsdv */
> wa_mcr_write_or(wal, SCCGCTL94DC, CG3DDISURB);
>
> + /* Wa_18011725039:xehpsdv */
> + if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_B0)) {
> + wa_mcr_masked_dis(wal, MLTICTXCTL, TDONRENDER);
> + wa_mcr_write_or(wal, L3SQCREG1_CCS0, FLUSHALLNONCOH);
> + }
> +
> /* Wa_16011155590:xehpsdv */
> if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
> wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
> @@ -1548,6 +1554,9 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> /* Wa_14014368820:xehpsdv */
> wa_mcr_write_or(wal, XEHP_GAMCNTRL_CTRL,
> INVALIDATION_BROADCAST_MODE_DIS |
> GLOBAL_INVALIDATION_MODE);
> +
> + /* Wa_14010670810:xehpsdv */
> + wa_mcr_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);
> }
>
> static void
> @@ -1684,6 +1693,9 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, XEHP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> wa_mcr_write_or(wal, XEHP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> +
> + /* Wa_16016694945 */
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_OVRLSCCC);
> }
>
> static void
> @@ -1724,11 +1736,36 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> debug_dump_steering(gt);
> }
>
> +/*
> + * The bspec performance guide has recommended MMIO tuning settings. These
> + * aren't truly "workarounds" but we want to program them through the
> + * workaround infrastructure to make sure they're (re)applied at the proper
> + * times.
> + *
> + * The settings in this function are for settings that persist through
> + * engine resets and also are not part of any engine's register state
> context.
> + * I.e., settings that only need to be re-applied in the event of a full GT
> + * reset.
> + */
> +static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list *wal)
> +{
> + if (IS_PONTEVECCHIO(gt->i915)) {
> + wa_mcr_write(wal, XEHPC_L3SCRUB,
> + SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> + wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> + }
> +
> + if (IS_DG2(gt->i915))
> + wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> +}
> +
> static void
> gt_init_workarounds(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> struct drm_i915_private *i915 = gt->i915;
>
> + gt_tuning_settings(gt, wal);
> +
> if (gt->type == GT_MEDIA) {
> if (MEDIA_VER(i915) >= 13)
> xelpmp_gt_workarounds_init(gt, wal);
> @@ -2897,16 +2934,8 @@ static void
> add_render_compute_tuning_settings(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> {
> - if (IS_PONTEVECCHIO(i915)) {
> - wa_mcr_write(wal, XEHPC_L3SCRUB,
> - SCRUB_CL_DWNGRADE_SHARED | SCRUB_RATE_4B_PER_CLK);
> - wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0, XEHPC_HOSTCACHEEN);
> - }
> -
> - if (IS_DG2(i915)) {
> - wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> + if (IS_DG2(i915))
> wa_mcr_write_clr_set(wal,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Disable dynamic debug as broken
== Series Details ==
Series: drm: Disable dynamic debug as broken
URL : https://patchwork.freedesktop.org/series/113746/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12709_full -> Patchwork_113746v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113746v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-d-ts-continuation-dpms-suspend:
- {shard-tglu-10}:NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-tglu-10/igt@kms_vbl...@pipe-d-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_113746v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2346])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-glk9/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@fbdev@unaligned-read:
- {shard-rkl}:[SKIP][6] ([i915#2582]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@fb...@unaligned-read.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-6/igt@fb...@unaligned-read.html
* igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- {shard-rkl}:[SKIP][8] ([i915#3281]) -> [PASS][9] +4 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
* igt@gem_pwrite@basic-self:
- {shard-rkl}:[SKIP][10] ([i915#3282]) -> [PASS][11] +3 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@gem_pwr...@basic-self.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-5/igt@gem_pwr...@basic-self.html
* igt@gen9_exec_parse@secure-batches:
- {shard-rkl}:[SKIP][12] ([i915#2527]) -> [PASS][13] +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-2/igt@gen9_exec_pa...@secure-batches.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-5/igt@gen9_exec_pa...@secure-batches.html
* igt@i915_pm_dc@dc5-psr:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-3/igt@i915_pm...@dc5-psr.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-6/igt@i915_pm...@dc5-psr.html
* igt@i915_pm_dc@dc6-dpms:
- {shard-rkl}:[SKIP][16] ([i915#3361]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-5/igt@i915_pm...@dc6-dpms.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-rkl-4/igt@i915_pm...@dc6-dpms.html
* igt@i915_pm_rpm@cursor-dpms:
- {shard-tglu}: [SKIP][18] ([i915#1849]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@i915_pm_...@cursor-dpms.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-tglu-1/igt@i915_pm_...@cursor-dpms.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-tglu}: [SKIP][20] ([i915#1397]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-tglu-6/igt@i915_pm_...@modeset-lpsp.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113746v1/shard-tglu-1/igt@i915_pm_...@modeset-lpsp.html
* igt@i915_pm_rpm@system-suspend-modeset:
- {shard-rkl}:[SKIP][22] ([fdo#109308]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12709/shard-rkl-1/igt@i915_pm_...@system-suspend-modeset.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix eDP+DSI dual panel systems (rev3)
== Series Details ==
Series: drm/i915: Fix eDP+DSI dual panel systems (rev3)
URL : https://patchwork.freedesktop.org/series/113728/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12710 -> Patchwork_113728v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/index.html
Participating hosts (38 -> 35)
--
Missing(3): fi-glk-j4005 bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113728v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][3] -> [FAIL][4] ([i915#6298])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6600u: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-edp-1:
- {bat-rplp-1}: [DMESG-WARN][7] -> [PASS][8] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/bat-rplp-1/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/bat-rplp-1/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-edp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
Build changes
-
* Linux: CI_DRM_12710 -> Patchwork_113728v3
CI-20190529: 20190529
CI_DRM_12710: eec9b4f6f829c4d09f6e1d19a37dc392376c95b5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7153: f47f859f13376958a2bd199423b1f0ff53dddbe0 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113728v3: eec9b4f6f829c4d09f6e1d19a37dc392376c95b5 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
528dd70a040d drm/i915: Pick the backlight controller based on VBT on ICP+
3f4d49af9104 drm/i915: Populate encoder->devdata for DSI on icl+
92a5dc4e505d drm/i915: Fix VBT DSI DVO port handling
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/index.html
Re: [Intel-gfx] [PATCH v2 0/6] More drm_dbg to guc_dbg changes
On 07.02.2023 06:07, john.c.harri...@intel.com wrote: > From: John Harrison > > Update more print messages to the new scheme. > > v2: Also change all errors to %pe rather than %d (MichalW). > Few other tweaks. > > Signed-off-by: John Harrison LGTM, series is Reviewed-by: Michal Wajdeczko > > > John Harrison (6): > drm/i915/guc: More debug print updates - UC firmware > drm/i915/guc: More debug print updates - GSC firmware > drm/i915/guc: More debug print updates - GuC reg capture > drm/i915/guc: More debug print updates - GuC selftests > drm/i915/guc: More debug print updates - GuC SLPC > drm/i915/guc: More debug print updates - GuC logging > > drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 + > drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 9 +- > drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +- > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 + > drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +- > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 61 - > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 42 +++ > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +- > drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 42 --- > .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++-- > .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +- > 13 files changed, 174 insertions(+), 205 deletions(-) >
Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists
On Wed, Feb 01, 2023 at 02:28:31PM -0800, Matt Roper wrote:
> Although register information in the bspec includes a field that is
> supposed to reflect a register's reset characteristics (i.e., whether a
> register maintains its value through engine resets), it's been
> discovered that this information is incorrect for some register ranges
> (i.e., registers that are not affected by engine resets are tagged in a
> way that indicates they would be).
>
> We can sanity check workaround registers placed on the RCS/CCS engine
> workaround lists (including those placed there via the
> general_render_compute_wa_init() function) by comparing against the
> forcewake table. As far as we know, there's never a case where a
> register that lives outside the RENDER powerwell will be reset by an
> RCS/CCS engine reset.
>
> Signed-off-by: Matt Roper
> ---
> .../gpu/drm/i915/gt/selftest_workarounds.c| 52 +++
> 1 file changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index 14a8b25b6204..1bc8febc5c1d 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -1362,12 +1362,64 @@ live_engine_reset_workarounds(void *arg)
> return ret;
> }
>
> +/*
> + * The bspec's documentation for register reset behavior can be unreliable
> for
> + * some MMIO ranges. But in general we do not expect registers outside the
> + * RENDER forcewake domain to be reset by RCS/CCS engine resets. If we find
> + * workaround registers on an RCS or CCS engine's list, it likely indicates
I think "workaround registers" is too general and makes the sentence a bit
confusing. I believe you mean those registers mentioned in the previous
sentence, right? Maybe s/workaround registers/said registers/?
> + * the register is misdocumented in the bspec and the workaround
> implementation
> + * should be moved to the GT workaround list instead.
> + */
> +static int
> +live_check_engine_workarounds_fw(void *arg)
> +{
> + struct intel_gt *gt = arg;
> + struct intel_engine_cs *engine;
> + struct wa_lists *lists;
> + enum intel_engine_id id;
> + int ret = 0;
> +
> + lists = kzalloc(sizeof(*lists), GFP_KERNEL);
> + if (!lists)
> + return -ENOMEM;
> +
> + reference_lists_init(gt, lists);
> +
> + for_each_engine(engine, gt, id) {
> + struct i915_wa_list *wal = &lists->engine[id].wa_list;
> + struct i915_wa *wa;
> + int i;
> +
> + if (engine->class != RENDER_CLASS &&
> + engine->class != COMPUTE_CLASS)
> + continue;
> +
> + for (i = 0, wa = wal->list; i < wal->count; i++, wa++) {
> + enum forcewake_domains fw;
> +
> + fw = intel_uncore_forcewake_for_reg(gt->uncore, wa->reg,
> + FW_REG_READ |
> FW_REG_WRITE);
> + if ((fw & FORCEWAKE_RENDER) == 0) {
> + pr_err("%s: Register %#x not in RENDER
> forcewake domain!\n",
> +engine->name,
> i915_mmio_reg_offset(wa->reg));
I think it is safer to use the correct member (wa->reg vs wa->mcr_reg) according
to the value of wa->is_mcr. Coincidently the reg member for both types have the
same offset in the struct, but I do not think we should rely on that.
One issue is that, unlike i915_mmio_reg_offset(),
intel_uncore_forcewake_for_reg() is not implemented with generics and expects
i915_reg_t. A workaround here would be "converting" the wa->mcr_reg (when
wa->is_mcr holds) an i915_reg_t by copying the correct fields. While this is
trivial since both types have only one field, I think the proper way
(future-proof) of doing that is by having a dedicated function/macro to do the
transformation.
Thinking about an alternative approach, do you think we could say that
i915_mcr_reg_t will always have the same fields as i915_reg_t? In that case, we
could tweak the type definition (or at least formalize via code documentation)
to reflect that and then it would be okay to always use wa->reg here, as
i915_mcr_reg_t would be thought as a subclass of i915_reg_t.
> + ret = -EINVAL;
> + }
> + }
> + }
> +
> + reference_lists_fini(gt, lists);
> + kfree(lists);
> +
> + return ret;
> +}
> +
> int intel_workarounds_live_selftests(struct drm_i915_private *i915)
> {
> static const struct i915_subtest tests[] = {
> SUBTEST(live_dirty_whitelist),
> SUBTEST(live_reset_whitelist),
> SUBTEST(live_isolated_whitelist),
> + SUBTEST(live_check_engine_workarounds_fw),
> SUBTEST(live_gpu_reset_workarounds),
> SUBTEST(live_engine_reset_workarounds),
> };
> --
> 2.39.1
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix eDP+DSI dual panel systems (rev3)
== Series Details ==
Series: drm/i915: Fix eDP+DSI dual panel systems (rev3)
URL : https://patchwork.freedesktop.org/series/113728/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12710_full -> Patchwork_113728v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113728v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-d-ts-continuation-dpms-suspend:
- {shard-tglu}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-tglu-3/igt@kms_vbl...@pipe-d-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_113728v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842]) +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
*
igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscaling@pipe-a-valid-mode:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +45 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-glk9/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-upscal...@pipe-a-valid-mode.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-glk9/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][6] ([i915#7742]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][8] ([i915#6268]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@in-flight-external:
- {shard-rkl}:[ABORT][10] ([i915#7811]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-2/igt@gem_...@in-flight-external.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-2/igt@gem_...@in-flight-external.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][12] ([fdo#103375]) -> [PASS][13] +4 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-6/igt@gem_...@in-flight-suspend.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][14] ([i915#5115] / [i915#7052]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-3/igt@gem_...@suspend.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-5/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-cpu-active:
- {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +6 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-3/igt@gem_exec_re...@basic-gtt-cpu-active.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-5/igt@gem_exec_re...@basic-gtt-cpu-active.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][20] ([fdo#111656]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12710/shard-rkl-2/igt@gem_mmap_...@coherency.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v3/shard-rkl-5/igt@gem_mmap_...@coherency.h
Re: [Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Tue, 2023-02-07 at 14:11 +0200, Imre Deak wrote: > On Mon, Feb 06, 2023 at 07:42:32PM -0500, Lyude Paul wrote: > > On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote: > > > > > > Yes, this patch should have no functional change, so please check what > > > would apply to other drivers as well. > > > > > > Could you also check Ville's comment about storing start_slot elsewhere > > > than the atomic state (leaving only time_slots there). I wonder if that > > > would work, at least it would simplify things I think. > > > > Ideally it'd be nice if we could have all this info in the atomic commit, > > but > > yeah - you're not the first person to find this a bit confusing. FWIW > > though, > > the way we store start_slot right now is intended to follow the same kind of > > behavior we have with atomic CRTC commit dependencies, I think I also made > > it > > that way so all of the state would be in a single place but there's no hard > > requirement for it. > > As I understood the atomic state should be precomputed during atomic > check and not changed later during the commit phase. In case of > start_slot this would mean knowing in advance the actual (driver > specific) disabling / enabling sequence of the payloads, not sure how > feasible it is to figure that out. start_slot also changes dynamically It isn't feasible afaict, which was the main motivation for having the strange update procedure - this is pretty much something that needs to be determined at commit time. > as each payload is disabled, so these intermediate versions of the field > would need to be tracked somehow separately from the final (precomputed) > versions. FWIW, the current way this works is that we call drm_dp_mst_atomic_wait_for_dependencies() in order to ensure that no one's currently writing to the start_slot field (remember, at this point we may not have atomic locks held anymore). Then at that point, start_slot in the new atomic state should hold the current in-hw start_slot value. start_slot isn't actually set to the new starting slot until drm_dp_add_payload_part1(). That of course as you pointed out, doesn't help us unless we read all of the start_slot values before we start changing payloads - since disabling payloads inevitably changes the start slot of payloads that come afterwards. I'll admit I'm a bit surprised this logic was wrong - if I recall the whole reason I assumed this was OK when writing this code was that since we're updating one payload at a time, ACT, repeat, that the start slots of each payload in hardware _would_ actually change in the same way we modify them in helpers. e.g., my expectation was if we had a bunch of payloads like this: Payload #1: 15 slots, start_slot=0 Payload #2: 15 slots, start_slot=15 Payload #3: 15 slots, start_slot=30 And then disabled say, payload #1, that immediately after we get the ACT that the payload table in hardware would look like this: Payload #2: 15 slots, start_slot=0 Payload #3: 15 slots, start_slot=15 But it sounds like it actually would look like this in the real world? Payload #2: 15 slots, start_slot=15 Payload #3: 15 slots, start_slot=30 So I'm curious, is there something I missed here? At what point does the MST hub at the other end decide that it's time to move the start slots back? (keep in mind, the MST specification does explicitly mention that there should never be holes in the payload table - so something has to be shifting the payloads back). > > > So if you guys think it'd be better design-wise to store this something > > else, > > I've got no strong feelings either way > > > > > > > For 0-2: > > > > > > > > Reviewed-by: Lyude Paul > > > > > > Thanks. > > > > > > > > > > > > > > > > > Cc: Lyude Paul > > > > > Cc: Ville Syrjälä > > > > > Cc: Ben Skeggs > > > > > Cc: Karol Herbst > > > > > Cc: Harry Wentland > > > > > Cc: Alex Deucher > > > > > Cc: Wayne Lin > > > > > Cc: sta...@vger.kernel.org # 6.1 > > > > > Cc: dri-de...@lists.freedesktop.org > > > > > Reviewed-by: Ville Syrjälä > > > > > Signed-off-by: Imre Deak > > > > > --- > > > > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > > > > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 > > > > > ++- > > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++- > > > > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- > > > > > include/drm/display/drm_dp_mst_helper.h | 3 ++- > > > > > 5 files changed, 21 insertions(+), 16 deletions(-) > > > > > > > > > > diff --git > > > > > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > index a50319fc42b11..180d3893b68da 100644 > > > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c > > > > > @@ -208,7 +208,7 @@ bool > > > > > dm_helpers_dp_mst_write_payload_allocation_table( > > > > > if (enable) >
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Populate encoder->devdata for DSI on icl+
On Tue, Feb 07, 2023 at 11:06:01AM +0200, Jani Nikula wrote:
> On Tue, 07 Feb 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We now have some eDP+DSI dual panel systems floating around
> > where the DSI panel is the secondary LFP and thus needs to
> > consult "panel type 2" in VBT in order to locate all the
> > other panel type dependante stuff correctly.
> >
> > To that end we need to pass in the devdata to
> > intel_bios_init_panel_late(), otherwise it'll just assume
> > we want the primary panel type. So let's try to just populate
> > the vbt.ports[] stuff and encoder->devdata for icl+ DSI
> > panels as well.
> >
> > We can't do this on older platforms as there we risk a DSI
> > port aliasing with a HDMI/DP port, which is a totally legal
> > thing as the DSI ports live in their own little parallel
> > universe.
>
> Btw the series should probably be Cc: stable.
Slapped that on optimistically and pushed the lot.
Thanks for the review.
>
> Reviewed-by: Jani Nikula
>
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/icl_dsi.c| 3 ++-
> > drivers/gpu/drm/i915/display/intel_bios.c | 15 ---
> > 2 files changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 003cac918228..05e749861658 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1951,7 +1951,8 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> > /* attach connector to encoder */
> > intel_connector_attach_encoder(intel_connector, encoder);
> >
> > - intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
> > NULL);
> > + encoder->devdata = intel_bios_encoder_data_lookup(dev_priv, port);
> > + intel_bios_init_panel_late(dev_priv, &intel_connector->panel,
> > encoder->devdata, NULL);
> >
> > mutex_lock(&dev_priv->drm.mode_config.mutex);
> > intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 06a2d98d2277..1cd8af88ce50 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -2593,6 +2593,12 @@ intel_bios_encoder_supports_edp(const struct
> > intel_bios_encoder_data *devdata)
> > devdata->child.device_type & DEVICE_TYPE_INTERNAL_CONNECTOR;
> > }
> >
> > +static bool
> > +intel_bios_encoder_supports_dsi(const struct intel_bios_encoder_data
> > *devdata)
> > +{
> > + return devdata->child.device_type & DEVICE_TYPE_MIPI_OUTPUT;
> > +}
> > +
> > static int _intel_bios_hdmi_level_shift(const struct
> > intel_bios_encoder_data *devdata)
> > {
> > if (!devdata || devdata->i915->display.vbt.version < 158)
> > @@ -2643,7 +2649,7 @@ static void print_ddi_port(const struct
> > intel_bios_encoder_data *devdata,
> > {
> > struct drm_i915_private *i915 = devdata->i915;
> > const struct child_device_config *child = &devdata->child;
> > - bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb,
> > supports_tbt;
> > + bool is_dvi, is_hdmi, is_dp, is_edp, is_dsi, is_crt,
> > supports_typec_usb, supports_tbt;
> > int dp_boost_level, dp_max_link_rate, hdmi_boost_level,
> > hdmi_level_shift, max_tmds_clock;
> >
> > is_dvi = intel_bios_encoder_supports_dvi(devdata);
> > @@ -2651,13 +2657,14 @@ static void print_ddi_port(const struct
> > intel_bios_encoder_data *devdata,
> > is_crt = intel_bios_encoder_supports_crt(devdata);
> > is_hdmi = intel_bios_encoder_supports_hdmi(devdata);
> > is_edp = intel_bios_encoder_supports_edp(devdata);
> > + is_dsi = intel_bios_encoder_supports_dsi(devdata);
> >
> > supports_typec_usb = intel_bios_encoder_supports_typec_usb(devdata);
> > supports_tbt = intel_bios_encoder_supports_tbt(devdata);
> >
> > drm_dbg_kms(&i915->drm,
> > - "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
> > LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
> > - port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
> > + "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
> > DSI:%d LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
> > + port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
> > is_dsi,
> > HAS_LSPCON(i915) && child->lspcon,
> > supports_typec_usb, supports_tbt,
> > devdata->dsc != NULL);
> > @@ -2710,6 +2717,8 @@ static void parse_ddi_port(struct
> > intel_bios_encoder_data *devdata)
> > enum port port;
> >
> > port = dvo_port_to_port(i915, child->dvo_port);
> > + if (port == PORT_NONE && DISPLAY_VER(i915) >= 11)
> > + port = dsi_dvo_port_to_port(i915, child->dvo_port);
> > if (port == PORT_NONE)
> > return;
[Intel-gfx] [PATCH 00/10] drm/i915: Prep work for vbt.ports[] nukage
From: Ville Syrjälä We need to get rid of the vbt.ports[] array. The main reason being the bogus VBTs found on many ADL laptops that declare both eDP+HDMI child devices for the same port. The goal is to probe each of those in order and stick to the first one that works. But the vbt.ports[] array gets populated before we do any output probing and, being indexed with the port, can't handle any aliasing child devices. Here's a bit of prep work to reduce our reliance on vbt.ports[], mainly by expanding the encoder->devdata (a direct pointer to the correct vbt child device from the encoder) usage. Ville Syrjälä (10): drm/i915: Pass the whole encoder to hotplug_enables() drm/i915: Move variables to loop context drm/i915: Replace intel_bios_is_lspcon_present() with intel_bios_encoder_is_lspcon() drm/i915: Replace intel_bios_is_lane_reversal_needed() with intel_bios_encoder_lane_reversal() drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert() drm/i915: Consult the registested encoders for the ICL combo PHY w/a drm/i915: Populate encoder->devdata for g4x+ DP/HDMI ports drm/i915: Pass devdata to intel_bios_port_aux_ch() drm/i915: Iterate all child devs in intel_bios_is_port_present() drm/i915: Use encoder->devdata in eDP init drivers/gpu/drm/i915/display/g4x_dp.c | 12 +- drivers/gpu/drm/i915/display/g4x_hdmi.c | 12 +- drivers/gpu/drm/i915/display/intel_bios.c | 128 ++ drivers/gpu/drm/i915/display/intel_bios.h | 14 +- drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- .../i915/display/intel_display_power_well.c | 15 +- drivers/gpu/drm/i915/display/intel_dp.c | 30 ++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 59 10 files changed, 134 insertions(+), 146 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 01/10] drm/i915: Pass the whole encoder to hotplug_enables()
From: Ville Syrjälä
bxt_hotplug_enables() needs to dig out not only the
hpd_pin bit also the VBT child device info, so let's just
pass in the whole encoder to avoid having to look things
up multiple times.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 54 +++--
1 file changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 240d5e198904..ae0a3b07281a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -81,8 +81,7 @@ static inline void pmu_irq_stats(struct drm_i915_private
*i915,
}
typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
-typedef u32 (*hotplug_enables_func)(struct drm_i915_private *i915,
- enum hpd_pin pin);
+typedef u32 (*hotplug_enables_func)(struct intel_encoder *encoder);
static const u32 hpd_ilk[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG,
@@ -884,7 +883,7 @@ static u32 intel_hpd_hotplug_enables(struct
drm_i915_private *i915,
u32 hotplug = 0;
for_each_intel_encoder(&i915->drm, encoder)
- hotplug |= hotplug_enables(i915, encoder->hpd_pin);
+ hotplug |= hotplug_enables(encoder);
return hotplug;
}
@@ -2835,10 +2834,11 @@ static void cherryview_irq_reset(struct
drm_i915_private *dev_priv)
spin_unlock_irq(&dev_priv->irq_lock);
}
-static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ switch (encoder->hpd_pin) {
case HPD_PORT_A:
/*
* When CPU and PCH are on the same package, port A
@@ -2890,31 +2890,29 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_hpd_detection_setup(dev_priv);
}
-static u32 icp_ddi_hotplug_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32 icp_ddi_hotplug_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ switch (encoder->hpd_pin) {
case HPD_PORT_A:
case HPD_PORT_B:
case HPD_PORT_C:
case HPD_PORT_D:
- return SHOTPLUG_CTL_DDI_HPD_ENABLE(pin);
+ return SHOTPLUG_CTL_DDI_HPD_ENABLE(encoder->hpd_pin);
default:
return 0;
}
}
-static u32 icp_tc_hotplug_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32 icp_tc_hotplug_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ switch (encoder->hpd_pin) {
case HPD_PORT_TC1:
case HPD_PORT_TC2:
case HPD_PORT_TC3:
case HPD_PORT_TC4:
case HPD_PORT_TC5:
case HPD_PORT_TC6:
- return ICP_TC_HPD_ENABLE(pin);
+ return ICP_TC_HPD_ENABLE(encoder->hpd_pin);
default:
return 0;
}
@@ -2958,17 +2956,16 @@ static void icp_hpd_irq_setup(struct drm_i915_private
*dev_priv)
icp_tc_hpd_detection_setup(dev_priv);
}
-static u32 gen11_hotplug_enables(struct drm_i915_private *i915,
-enum hpd_pin pin)
+static u32 gen11_hotplug_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ switch (encoder->hpd_pin) {
case HPD_PORT_TC1:
case HPD_PORT_TC2:
case HPD_PORT_TC3:
case HPD_PORT_TC4:
case HPD_PORT_TC5:
case HPD_PORT_TC6:
- return GEN11_HOTPLUG_CTL_ENABLE(pin);
+ return GEN11_HOTPLUG_CTL_ENABLE(encoder->hpd_pin);
default:
return 0;
}
@@ -3031,10 +3028,9 @@ static void gen11_hpd_irq_setup(struct drm_i915_private
*dev_priv)
icp_hpd_irq_setup(dev_priv);
}
-static u32 spt_hotplug_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32 spt_hotplug_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ switch (encoder->hpd_pin) {
case HPD_PORT_A:
return PORTA_HOTPLUG_ENABLE;
case HPD_PORT_B:
@@ -3048,10 +3044,9 @@ static u32 spt_hotplug_enables(struct drm_i915_private
*i915,
}
}
-static u32 spt_hotplug2_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32 spt_hotplug2_enables(struct intel_encoder *encoder)
{
- switch (pin) {
+ switch (encoder->hpd_pin) {
case HPD_PORT_E:
return PORTE_HOTPLUG_ENABLE;
default:
@@ -3094,10 +3089,9 @@ static void spt_hpd_irq_setup(struct drm_i915_private
*dev_priv)
spt_hpd_detection_setup(dev_priv);
}
-static u32 ilk_hotplug_enables(struct drm_i915_private *i915,
- enum hpd_pin pin)
+static u32
[Intel-gfx] [PATCH 02/10] drm/i915: Move variables to loop context
From: Ville Syrjälä
Lot of the loops over VBT child devices have variables
declared outside the loop but only used inside the loop.
Move the variables to a tighter scope.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 32 +--
1 file changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 1cd8af88ce50..6ea7396728ce 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1201,9 +1201,7 @@ child_device_ptr(const struct bdb_general_definitions
*defs, int i)
static void
parse_sdvo_device_mapping(struct drm_i915_private *i915)
{
- struct sdvo_device_mapping *mapping;
const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
int count = 0;
/*
@@ -1216,7 +1214,8 @@ parse_sdvo_device_mapping(struct drm_i915_private *i915)
}
list_for_each_entry(devdata, &i915->display.vbt.display_devices, node) {
- child = &devdata->child;
+ const struct child_device_config *child = &devdata->child;
+ struct sdvo_device_mapping *mapping;
if (child->slave_addr != SLAVE_ADDR1 &&
child->slave_addr != SLAVE_ADDR2) {
@@ -2074,7 +2073,6 @@ parse_compression_parameters(struct drm_i915_private
*i915)
{
const struct bdb_compression_parameters *params;
struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
u16 block_size;
int index;
@@ -2099,7 +2097,7 @@ parse_compression_parameters(struct drm_i915_private
*i915)
}
list_for_each_entry(devdata, &i915->display.vbt.display_devices, node) {
- child = &devdata->child;
+ const struct child_device_config *child = &devdata->child;
if (!child->compression_enable)
continue;
@@ -2225,14 +2223,14 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8
vbt_pin)
static enum port get_port_by_ddc_pin(struct drm_i915_private *i915, u8 ddc_pin)
{
- const struct intel_bios_encoder_data *devdata;
enum port port;
if (!ddc_pin)
return PORT_NONE;
for_each_port(port) {
- devdata = i915->display.vbt.ports[port];
+ const struct intel_bios_encoder_data *devdata =
+ i915->display.vbt.ports[port];
if (devdata && ddc_pin == devdata->child.ddc_pin)
return port;
@@ -2291,14 +2289,14 @@ static void sanitize_ddc_pin(struct
intel_bios_encoder_data *devdata,
static enum port get_port_by_aux_ch(struct drm_i915_private *i915, u8 aux_ch)
{
- const struct intel_bios_encoder_data *devdata;
enum port port;
if (!aux_ch)
return PORT_NONE;
for_each_port(port) {
- devdata = i915->display.vbt.ports[port];
+ const struct intel_bios_encoder_data *devdata =
+ i915->display.vbt.ports[port];
if (devdata && aux_ch == devdata->child.aux_channel)
return port;
@@ -3305,7 +3303,6 @@ void intel_bios_fini_panel(struct intel_panel *panel)
bool intel_bios_is_tv_present(struct drm_i915_private *i915)
{
const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
if (!i915->display.vbt.int_tv_support)
return false;
@@ -3314,7 +3311,7 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*i915)
return true;
list_for_each_entry(devdata, &i915->display.vbt.display_devices, node) {
- child = &devdata->child;
+ const struct child_device_config *child = &devdata->child;
/*
* If the device type is not TV, continue.
@@ -3348,13 +3345,12 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*i915)
bool intel_bios_is_lvds_present(struct drm_i915_private *i915, u8 *i2c_pin)
{
const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
if (list_empty(&i915->display.vbt.display_devices))
return true;
list_for_each_entry(devdata, &i915->display.vbt.display_devices, node) {
- child = &devdata->child;
+ const struct child_device_config *child = &devdata->child;
/* If the device type is not LFP, continue.
* We have to check both the new identifiers as well as the
@@ -3456,17 +3452,14 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*i915,
enum port *port)
{
const struct intel_bios_encoder_data *devdata;
- const struct child_device_config *child;
- u8 dvo_port;
list_for_each_entry(
[Intel-gfx] [PATCH 03/10] drm/i915: Replace intel_bios_is_lspcon_present() with intel_bios_encoder_is_lspcon()
From: Ville Syrjälä
We always have encoder->devdata available on the platforms
that can have LSPCON. So let's start looking there instead
of digging it out from vbt.ports[].
And let's rename the function to fit the common pattern
for these things.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 24 ++---
drivers/gpu/drm/i915/display/intel_bios.h | 3 +--
drivers/gpu/drm/i915/display/intel_ddi.c| 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 13 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
6 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 6ea7396728ce..9646d68fdb0f 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2597,6 +2597,12 @@ intel_bios_encoder_supports_dsi(const struct
intel_bios_encoder_data *devdata)
return devdata->child.device_type & DEVICE_TYPE_MIPI_OUTPUT;
}
+bool
+intel_bios_encoder_is_lspcon(const struct intel_bios_encoder_data *devdata)
+{
+ return devdata && HAS_LSPCON(devdata->i915) && devdata->child.lspcon;
+}
+
static int _intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
*devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 158)
@@ -2663,7 +2669,7 @@ static void print_ddi_port(const struct
intel_bios_encoder_data *devdata,
drm_dbg_kms(&i915->drm,
"Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
DSI:%d LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
is_dsi,
- HAS_LSPCON(i915) && child->lspcon,
+ intel_bios_encoder_is_lspcon(devdata),
supports_typec_usb, supports_tbt,
devdata->dsc != NULL);
@@ -3587,22 +3593,6 @@ intel_bios_is_port_hpd_inverted(const struct
drm_i915_private *i915,
return devdata && devdata->child.hpd_invert;
}
-/**
- * intel_bios_is_lspcon_present - if LSPCON is attached on %port
- * @i915: i915 device instance
- * @port: port to check
- *
- * Return true if LSPCON is present on this port
- */
-bool
-intel_bios_is_lspcon_present(const struct drm_i915_private *i915,
-enum port port)
-{
- const struct intel_bios_encoder_data *devdata =
i915->display.vbt.ports[port];
-
- return HAS_LSPCON(i915) && devdata && devdata->child.lspcon;
-}
-
/**
* intel_bios_is_lane_reversal_needed - if lane reversal needed on port
* @i915: i915 device instance
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index d221f784aa88..ad3edfe6ec3a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -250,8 +250,6 @@ bool intel_bios_is_port_dp_dual_mode(struct
drm_i915_private *dev_priv, enum por
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
bool intel_bios_is_port_hpd_inverted(const struct drm_i915_private *i915,
enum port port);
-bool intel_bios_is_lspcon_present(const struct drm_i915_private *i915,
- enum port port);
bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
enum port port);
enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum
port port);
@@ -274,6 +272,7 @@ bool intel_bios_encoder_supports_hdmi(const struct
intel_bios_encoder_data *devd
bool intel_bios_encoder_supports_dp(const struct intel_bios_encoder_data
*devdata);
bool intel_bios_encoder_supports_typec_usb(const struct
intel_bios_encoder_data *devdata);
bool intel_bios_encoder_supports_tbt(const struct intel_bios_encoder_data
*devdata);
+bool intel_bios_encoder_is_lspcon(const struct intel_bios_encoder_data
*devdata);
int intel_bios_encoder_dp_boost_level(const struct intel_bios_encoder_data
*devdata);
int intel_bios_encoder_hdmi_boost_level(const struct intel_bios_encoder_data
*devdata);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 254559abedfb..2c64d5f4b8f3 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4305,7 +4305,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
intel_bios_encoder_supports_hdmi(devdata);
init_dp = intel_bios_encoder_supports_dp(devdata);
- if (intel_bios_is_lspcon_present(dev_priv, port)) {
+ if (intel_bios_encoder_is_lspcon(devdata)) {
/*
* Lspcon device needs to be driven with DP connector
* with special detection sequence. So make sure DP
diff --git a/drivers/gpu
[Intel-gfx] [PATCH 04/10] drm/i915: Replace intel_bios_is_lane_reversal_needed() with intel_bios_encoder_lane_reversal()
From: Ville Syrjälä
The sole user of intel_bios_is_lane_reversal_needed() has
the devdata already located, so pass it in directly instead
of digging it again from vbt.ports[].
And rename the function to follow the common pattern for
these things.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 21 +
drivers/gpu/drm/i915/display/intel_bios.h | 3 +--
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 9646d68fdb0f..cc7f5928935f 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3593,22 +3593,6 @@ intel_bios_is_port_hpd_inverted(const struct
drm_i915_private *i915,
return devdata && devdata->child.hpd_invert;
}
-/**
- * intel_bios_is_lane_reversal_needed - if lane reversal needed on port
- * @i915: i915 device instance
- * @port: port to check
- *
- * Return true if port requires lane reversal
- */
-bool
-intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
- enum port port)
-{
- const struct intel_bios_encoder_data *devdata =
i915->display.vbt.ports[port];
-
- return devdata && devdata->child.lane_reversal;
-}
-
enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *i915,
enum port port)
{
@@ -3773,6 +3757,11 @@ bool intel_bios_encoder_supports_tbt(const struct
intel_bios_encoder_data *devda
return devdata->i915->display.vbt.version >= 209 && devdata->child.tbt;
}
+bool intel_bios_encoder_lane_reversal(const struct intel_bios_encoder_data
*devdata)
+{
+ return devdata && devdata->child.lane_reversal;
+}
+
const struct intel_bios_encoder_data *
intel_bios_encoder_data_lookup(struct drm_i915_private *i915, enum port port)
{
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index ad3edfe6ec3a..29119145cf34 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -250,8 +250,6 @@ bool intel_bios_is_port_dp_dual_mode(struct
drm_i915_private *dev_priv, enum por
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
bool intel_bios_is_port_hpd_inverted(const struct drm_i915_private *i915,
enum port port);
-bool intel_bios_is_lane_reversal_needed(const struct drm_i915_private *i915,
- enum port port);
enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum
port port);
bool intel_bios_get_dsc_params(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -275,5 +273,6 @@ bool intel_bios_encoder_supports_tbt(const struct
intel_bios_encoder_data *devda
bool intel_bios_encoder_is_lspcon(const struct intel_bios_encoder_data
*devdata);
int intel_bios_encoder_dp_boost_level(const struct intel_bios_encoder_data
*devdata);
int intel_bios_encoder_hdmi_boost_level(const struct intel_bios_encoder_data
*devdata);
+bool intel_bios_encoder_lane_reversal(const struct intel_bios_encoder_data
*devdata);
#endif /* _INTEL_BIOS_H_ */
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2c64d5f4b8f3..136a68393608 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4500,7 +4500,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
intel_de_read(dev_priv, DDI_BUF_CTL(port))
& (DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
- if (intel_bios_is_lane_reversal_needed(dev_priv, port))
+ if (intel_bios_encoder_lane_reversal(devdata))
dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
dig_port->dp.output_reg = INVALID_MMIO_REG;
--
2.39.1
[Intel-gfx] [PATCH 05/10] drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert()
From: Ville Syrjälä
intel_bios_is_port_hpd_inverted() is only used on bxt/glk on
which we always have encoder->devdata available. So consult
that instead of digging around in vbt.ports[].
And rename the function to match the common pattern.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 25 +--
drivers/gpu/drm/i915/display/intel_bios.h | 3 +--
drivers/gpu/drm/i915/i915_irq.c | 7 +++
3 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index cc7f5928935f..ca6b7d90ee50 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -3573,26 +3573,6 @@ bool intel_bios_get_dsc_params(struct intel_encoder
*encoder,
return false;
}
-/**
- * intel_bios_is_port_hpd_inverted - is HPD inverted for %port
- * @i915: i915 device instance
- * @port: port to check
- *
- * Return true if HPD should be inverted for %port.
- */
-bool
-intel_bios_is_port_hpd_inverted(const struct drm_i915_private *i915,
- enum port port)
-{
- const struct intel_bios_encoder_data *devdata =
i915->display.vbt.ports[port];
-
- if (drm_WARN_ON_ONCE(&i915->drm,
-!IS_GEMINILAKE(i915) && !IS_BROXTON(i915)))
- return false;
-
- return devdata && devdata->child.hpd_invert;
-}
-
enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *i915,
enum port port)
{
@@ -3762,6 +3742,11 @@ bool intel_bios_encoder_lane_reversal(const struct
intel_bios_encoder_data *devd
return devdata && devdata->child.lane_reversal;
}
+bool intel_bios_encoder_hpd_invert(const struct intel_bios_encoder_data
*devdata)
+{
+ return devdata && devdata->child.hpd_invert;
+}
+
const struct intel_bios_encoder_data *
intel_bios_encoder_data_lookup(struct drm_i915_private *i915, enum port port)
{
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 29119145cf34..cf9fbf506790 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -248,8 +248,6 @@ bool intel_bios_is_port_present(struct drm_i915_private
*dev_priv, enum port por
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum
port port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
-bool intel_bios_is_port_hpd_inverted(const struct drm_i915_private *i915,
-enum port port);
enum aux_ch intel_bios_port_aux_ch(struct drm_i915_private *dev_priv, enum
port port);
bool intel_bios_get_dsc_params(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -274,5 +272,6 @@ bool intel_bios_encoder_is_lspcon(const struct
intel_bios_encoder_data *devdata)
int intel_bios_encoder_dp_boost_level(const struct intel_bios_encoder_data
*devdata);
int intel_bios_encoder_hdmi_boost_level(const struct intel_bios_encoder_data
*devdata);
bool intel_bios_encoder_lane_reversal(const struct intel_bios_encoder_data
*devdata);
+bool intel_bios_encoder_hpd_invert(const struct intel_bios_encoder_data
*devdata);
#endif /* _INTEL_BIOS_H_ */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ae0a3b07281a..b024a3a7ca19 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3131,23 +3131,22 @@ static void ilk_hpd_irq_setup(struct drm_i915_private
*dev_priv)
static u32 bxt_hotplug_enables(struct intel_encoder *encoder)
{
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
u32 hotplug;
switch (encoder->hpd_pin) {
case HPD_PORT_A:
hotplug = PORTA_HOTPLUG_ENABLE;
- if (intel_bios_is_port_hpd_inverted(i915, PORT_A))
+ if (intel_bios_encoder_hpd_invert(encoder->devdata))
hotplug |= BXT_DDIA_HPD_INVERT;
return hotplug;
case HPD_PORT_B:
hotplug = PORTB_HOTPLUG_ENABLE;
- if (intel_bios_is_port_hpd_inverted(i915, PORT_B))
+ if (intel_bios_encoder_hpd_invert(encoder->devdata))
hotplug |= BXT_DDIB_HPD_INVERT;
return hotplug;
case HPD_PORT_C:
hotplug = PORTC_HOTPLUG_ENABLE;
- if (intel_bios_is_port_hpd_inverted(i915, PORT_C))
+ if (intel_bios_encoder_hpd_invert(encoder->devdata))
hotplug |= BXT_DDIC_HPD_INVERT;
return hotplug;
default:
--
2.39.1
[Intel-gfx] [PATCH 06/10] drm/i915: Consult the registested encoders for the ICL combo PHY w/a
From: Ville Syrjälä
Display WA #1178 calls us to tweak some magic bits when doing AUX
to an external combo PHY port. Instead of looking to see if the VBT
has declared such a port (which could in theory even alias with a
declared eDP port on the same PHY) just check the real situation
based on the registered encoders.
The only slight chicken vs. egg situation here is during output
probing. But typically we'd register the eDP ports first and so
once we get to probe anything external on the combo PHY we have
already determined if it's eDP or not.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power_well.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 8710dd41ffd4..56a20bf5825b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -391,6 +391,19 @@ static void hsw_power_well_disable(struct drm_i915_private
*dev_priv,
hsw_wait_for_power_well_disable(dev_priv, power_well);
}
+static bool intel_port_is_edp(struct drm_i915_private *i915, enum port port)
+{
+ struct intel_encoder *encoder;
+
+ for_each_intel_encoder(&i915->drm, encoder) {
+ if (encoder->type == INTEL_OUTPUT_EDP &&
+ encoder->port == port)
+ return true;
+ }
+
+ return false;
+}
+
static void
icl_combo_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
@@ -416,7 +429,7 @@ icl_combo_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
/* Display WA #1178: icl */
if (pw_idx >= ICL_PW_CTL_IDX_AUX_A && pw_idx <= ICL_PW_CTL_IDX_AUX_B &&
- !intel_bios_is_port_edp(dev_priv, (enum port)phy)) {
+ !intel_port_is_edp(dev_priv, (enum port)phy)) {
val = intel_de_read(dev_priv, ICL_AUX_ANAOVRD1(pw_idx));
val |= ICL_AUX_ANAOVRD1_ENABLE | ICL_AUX_ANAOVRD1_LDO_BYPASS;
intel_de_write(dev_priv, ICL_AUX_ANAOVRD1(pw_idx), val);
--
2.39.1
[Intel-gfx] [PATCH 07/10] drm/i915: Populate encoder->devdata for g4x+ DP/HDMI ports
From: Ville Syrjälä
Let's make encoder->devdata (the VBT informaiton for the port)
available on g4x+ platforms as well. Much easier when you can
just grab it there instead of trying to find it from some global
list array based on the port.
Note that (unlike DDI platforms) we don't currently require
that each DP/HDMI port is actually declared in VBT. Perhaps
in the future we may want to rethink that, but for now just
stick in a debug+FIXME as a reminder.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 10 ++
drivers/gpu/drm/i915/display/g4x_hdmi.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index fa754038d669..0cc1531a03a3 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -1279,11 +1279,19 @@ static const struct drm_encoder_funcs
intel_dp_enc_funcs = {
bool g4x_dp_init(struct drm_i915_private *dev_priv,
i915_reg_t output_reg, enum port port)
{
+ const struct intel_bios_encoder_data *devdata;
struct intel_digital_port *dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
+ devdata = intel_bios_encoder_data_lookup(dev_priv, port);
+
+ /* FIXME bail? */
+ if (!devdata)
+ drm_dbg_kms(&dev_priv->drm, "No VBT child device for DP-%c\n",
+ port_name(port));
+
dig_port = kzalloc(sizeof(*dig_port), GFP_KERNEL);
if (!dig_port)
return false;
@@ -1295,6 +1303,8 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &dig_port->base;
encoder = &intel_encoder->base;
+ intel_encoder->devdata = devdata;
+
mutex_init(&dig_port->hdcp_mutex);
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 64c3b3990702..e9ae4c67b8a4 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -548,10 +548,18 @@ intel_hdmi_hotplug(struct intel_encoder *encoder,
void g4x_hdmi_init(struct drm_i915_private *dev_priv,
i915_reg_t hdmi_reg, enum port port)
{
+ const struct intel_bios_encoder_data *devdata;
struct intel_digital_port *dig_port;
struct intel_encoder *intel_encoder;
struct intel_connector *intel_connector;
+ devdata = intel_bios_encoder_data_lookup(dev_priv, port);
+
+ /* FIXME bail? */
+ if (!devdata)
+ drm_dbg_kms(&dev_priv->drm, "No VBT child device for HDMI-%c\n",
+ port_name(port));
+
dig_port = kzalloc(sizeof(*dig_port), GFP_KERNEL);
if (!dig_port)
return;
@@ -564,6 +572,8 @@ void g4x_hdmi_init(struct drm_i915_private *dev_priv,
intel_encoder = &dig_port->base;
+ intel_encoder->devdata = devdata;
+
mutex_init(&dig_port->hdcp_mutex);
drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
--
2.39.1
