Re: [Intel-gfx] [RFC PATCH 2/2] mdev: introduce device specific ops
On 2019/9/17 下午8:42, Cornelia Huck wrote:
On Thu, 12 Sep 2019 17:40:12 +0800
Jason Wang wrote:
Currently, except for the crate and remove. The rest fields of
mdev_parent_ops is just designed for vfio-mdev driver and may not help
for kernel mdev driver. So follow the device id support by previous
patch, this patch introduces device specific ops which points to
device specific ops (e.g vfio ops). This allows the future drivers
like virtio-mdev to implement its own device specific ops.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 14 +++---
drivers/s390/cio/vfio_ccw_ops.c | 14 +++---
drivers/s390/crypto/vfio_ap_ops.c | 10 +++--
drivers/vfio/mdev/vfio_mdev.c | 30 +++--
include/linux/mdev.h | 72 ++-
samples/vfio-mdev/mbochs.c| 16 ---
samples/vfio-mdev/mdpy.c | 16 ---
samples/vfio-mdev/mtty.c | 14 +++---
8 files changed, 113 insertions(+), 73 deletions(-)
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index f85045392120..3b8a76bc69cf 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -27,27 +27,9 @@ int mdev_set_iommu_device(struct device *dev, struct device
*iommu_device);
struct device *mdev_get_iommu_device(struct device *dev);
/**
- * struct mdev_parent_ops - Structure to be registered for each parent device
to
- * register the device to mdev module.
+ * struct vfio_mdev_parent_ops - Structure to be registered for each
+ * parent device to register the device to vfio-mdev module.
*
- * @owner: The module owner.
- * @dev_attr_groups: Attributes of the parent device.
- * @mdev_attr_groups: Attributes of the mediated device.
- * @supported_type_groups: Attributes to define supported types. It is
mandatory
- * to provide supported types.
- * @create:Called to allocate basic resources in parent device's
- * driver for a particular mediated device. It is
- * mandatory to provide create ops.
- * @kobj: kobject of type for which 'create' is called.
- * @mdev: mdev_device structure on of mediated device
- * that is being created
- * Returns integer: success (0) or error (< 0)
- * @remove:Called to free resources in parent device's driver for a
- * a mediated device. It is mandatory to provide 'remove'
- * ops.
- * @mdev: mdev_device device structure which is being
- *destroyed
- * Returns integer: success (0) or error (< 0)
* @open: Open mediated device.
*@mdev: mediated device.
*Returns integer: success (0) or error (< 0)
@@ -72,6 +54,43 @@ struct device *mdev_get_iommu_device(struct device *dev);
* @mmap: mmap callback
*@mdev: mediated device structure
*@vma: vma structure
+ */
+struct vfio_mdev_parent_ops {
+ int (*open)(struct mdev_device *mdev);
+ void(*release)(struct mdev_device *mdev);
+ ssize_t (*read)(struct mdev_device *mdev, char __user *buf,
+ size_t count, loff_t *ppos);
+ ssize_t (*write)(struct mdev_device *mdev, const char __user *buf,
+size_t count, loff_t *ppos);
+ long(*ioctl)(struct mdev_device *mdev, unsigned int cmd,
+unsigned long arg);
+ int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
+};
+
+/**
+ * struct mdev_parent_ops - Structure to be registered for each parent device
to
+ * register the device to mdev module.
+ *
+ * @owner: The module owner.
+ * @dev_attr_groups: Attributes of the parent device.
+ * @mdev_attr_groups: Attributes of the mediated device.
+ * @supported_type_groups: Attributes to define supported types. It is
mandatory
+ * to provide supported types.
+ * @create:Called to allocate basic resources in parent device's
+ * driver for a particular mediated device. It is
+ * mandatory to provide create ops.
+ * @kobj: kobject of type for which 'create' is called.
+ * @mdev: mdev_device structure on of mediated device
+ * that is being created
+ * Returns integer: success (0) or error (< 0)
+ * @remove:Called to free resources in parent device's driver for a
+ * a mediated device. It is mandatory to provide 'remove'
+ * ops.
+ * @mdev: mdev_device device structure which is being
+ *destroyed
+ * Returns integer: success (0) or error (< 0)
+ * @device_ops: Device
Re: [Intel-gfx] [RFC PATCH 1/2] mdev: device id support
On 2019/9/17 下午8:07, Cornelia Huck wrote:
On Thu, 12 Sep 2019 17:40:11 +0800
Jason Wang wrote:
Mdev bus only support vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
one example is virtio-mdev[1] driver. This means we need to add device
id support in bus match method to pair the mdev device and mdev driver
correctly.
Sounds reasonable.
So this patch add id_table to mdev_driver and id for mdev parent, and
implement the match method for mdev bus.
[1] https://lkml.org/lkml/2019/9/10/135
Signed-off-by: Jason Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
drivers/s390/cio/vfio_ccw_ops.c | 2 +-
drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
drivers/vfio/mdev/mdev_core.c | 14 --
drivers/vfio/mdev/mdev_driver.c | 14 ++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 ++
include/linux/mdev.h | 6 +-
include/linux/mod_devicetable.h | 6 ++
samples/vfio-mdev/mbochs.c| 2 +-
samples/vfio-mdev/mdpy.c | 2 +-
samples/vfio-mdev/mtty.c | 2 +-
12 files changed, 51 insertions(+), 9 deletions(-)
(...)
The transformations of the vendor drivers and the new interface look
sane.
(...)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5714fd35a83c..f1fc143df042 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -821,4 +821,10 @@ struct wmi_device_id {
const void *context;
};
+/* MDEV */
+
Maybe add some kerneldoc and give vfio as an example of what we're
matching here?
Will add when posting a non RFC patch.
+struct mdev_device_id {
+ __u8 id;
I agree with the suggestion to rename this to 'class_id'.
Let me change it.
Thanks
+};
+
#endif /* LINUX_MOD_DEVICETABLE_H */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix S0ix/S3 suspend stress issue
During S0ix/S3 suspend stress test on Cometlake chromebook,
after few iterations we are seeing failure wrt PSR link CRC
Error and stress test stops. This S0ix test is failing only
when there is a CRC mismatch. In case of CRC mismatch, panel
generates IRQ_HD and whenever there is CRC mismatch, we are
disabling PSR2 in driver.
By not disabling PSR2 in driver and only by writing 1 to clear
sticky bit 0 in DPCD 0x2006 in panel,issue goes away.
Completed 2500 S0ix/S3 test cycles on multiple CML chromebooks.
As per EDP spec for CRC mismatch, nothing has been mentioned
explicitly for Source device, only by writing 1 to clear
sticky bit 0 in DPCD 0x2006 in sink is mentioned.
Signed-off-by: Gaurav K Singh
---
drivers/gpu/drm/i915/display/intel_psr.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b3c7eef53bf3..502e29dbbea9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1325,15 +1325,11 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling
PSR\n");
if (val & DP_PSR_LINK_CRC_ERROR)
- DRM_ERROR("PSR Link CRC error, disabling PSR\n");
+ DRM_DEBUG_KMS("PSR Link CRC error, clearing PSR error status
DPCD\n");
if (val & ~errors)
DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
val & ~errors);
- if (val & errors) {
- intel_psr_disable_locked(intel_dp);
- psr->sink_not_reliable = true;
- }
/* clear status register */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
exit:
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/perf: Add support for report sizes that are not power of 2
On Tue, 17 Sep 2019 10:33:51 -0700, Umesh Nerlige Ramappa wrote: > > On Mon, Sep 16, 2019 at 09:11:58PM -0700, Ashutosh Dixit wrote: > > On Mon, 16 Sep 2019 12:17:54 -0700, Umesh Nerlige Ramappa wrote: > >> > >> On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote: > >> > On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote: > >> >> OA perf unit supports non-power of 2 report sizes. Enable support for > >> >> these sizes in the driver. > >> >> > >> >> Signed-off-by: Umesh Nerlige Ramappa > >> >> --- > >> >> drivers/gpu/drm/i915/i915_perf.c | 59 > >> >> 1 file changed, 21 insertions(+), 38 deletions(-) > >> >> > >> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c > >> >> b/drivers/gpu/drm/i915/i915_perf.c > >> >> index 50b6d154fd46..482fca3da7de 100644 > >> >> --- a/drivers/gpu/drm/i915/i915_perf.c > >> >> +++ b/drivers/gpu/drm/i915/i915_perf.c > >> >> @@ -450,7 +450,7 @@ static bool oa_buffer_check_unlocked(struct > >> >> i915_perf_stream *stream) > >> >> u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma); > >> >> int report_size = stream->oa_buffer.format_size; > >> >> unsigned long flags; > >> >> - u32 hw_tail; > >> >> + u32 hw_tail, aging_tail; > >> >> u64 now; > >> >> /* We have to consider the (unlikely) possibility that read() errors > >> >> @@ -459,16 +459,17 @@ static bool oa_buffer_check_unlocked(struct > >> >> i915_perf_stream *stream) > >> >> */ > >> >> spin_lock_irqsave(>oa_buffer.ptr_lock, flags); > >> >> - hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream); > >> >> + hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream) - > >> >> gtt_offset; > >> >> + aging_tail = stream->oa_buffer.aging_tail - gtt_offset; > >> >> /* The tail pointer increases in 64 byte increments, > >> >> * not in report_size steps... > >> >> */ > >> >> - hw_tail &= ~(report_size - 1); > >> >> + hw_tail = OA_TAKEN(hw_tail, (OA_TAKEN(hw_tail, aging_tail) % > >> >> report_size)); > >> > > >> > > >> > I'm struggling to parse this line above and I'm not 100% sure it's > >> > correct. > >> > > >> > Could add a comment to explain what is going on? > >> > >> The aging tail is always pointing to the boundary of a report whereas > >> the hw_tail is advancing in 64 byte increments. > >> > >> The innermost OA_TAKEN is returning the number of bytes between the > >> hw_tail and the aging_tail. The modulo is getting the size of the > >> partial report (if any). > >> > >> The outermost OA_TAKEN is subtracting the size of partial report from > >> the hw_tail to get a hw_tail that points to the boundary of the last > >> full report. > >> > >> The value of hw_tail would be the same as from the deleted line of code > >> above this line. > > > > Looks like aging_tail should not be needed (it is complicating the > > expression and is not there in the original expression). All we need is a > > "circular modulus". For example would the following work? > > original expression assumes all report sizes are powers of 2 and hence does > not need a reference (like aging_tail) to rounddown the hw_tail. > > > > >if (hw_tail < report_size) > >hw_tail += OA_BUFFER_SIZE; > > Assuming that this condition is detecting a report split across the OA > buffer boundary, the above check will not catch the split in cases where > there are multiple reports generated before we read the hw_tail. > > >hw_tail = rounddown(hw_tail, report_size); > > > > Another way (if we want to avoid the division) would be to maintain a > > cached copy of hw_tail in SW which is successively (and circularly) > > incremented by report_size till it catches up with hw_tail read from > > HW. But probably the first method above is simpler. > > aging_tail is a cached copy of the hw_tail that advances only in report > size increments. Umesh is right, the previous aging_tail needs to be taken into account. Basically we need to start from the previous aging_tail and continue incrementing by report_size till we catch up with the new hw_tail (at the previous report_size boundary, which gives the value of the new aging_tail). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for adding gamma state checker for icl+ platforms (rev2)
== Series Details == Series: adding gamma state checker for icl+ platforms (rev2) URL : https://patchwork.freedesktop.org/series/66811/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6909_full -> Patchwork_14432_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14432_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14432_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14432_full: ### IGT changes ### Possible regressions * igt@kms_color@pipe-a-ctm-0-75: - shard-iclb: NOTRUN -> [DMESG-FAIL][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb1/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_color@pipe-b-gamma: - shard-iclb: [PASS][2] -> [DMESG-WARN][3] +5 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb4/igt@kms_co...@pipe-b-gamma.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb1/igt@kms_co...@pipe-b-gamma.html * igt@kms_color@pipe-c-ctm-negative: - shard-iclb: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb2/igt@kms_co...@pipe-c-ctm-negative.html Warnings * igt@kms_color@pipe-b-ctm-0-25: - shard-iclb: [FAIL][5] ([fdo#110920]) -> [DMESG-FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb1/igt@kms_co...@pipe-b-ctm-0-25.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb1/igt@kms_co...@pipe-b-ctm-0-25.html * igt@kms_color@pipe-b-degamma: - shard-iclb: [FAIL][7] ([fdo#104782]) -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb4/igt@kms_co...@pipe-b-degamma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb2/igt@kms_co...@pipe-b-degamma.html Known issues Here are the changes found in Patchwork_14432_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb1/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb8/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#103313]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-kbl4/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-kbl6/igt@gem_exec_susp...@basic-s3.html * igt@gem_softpin@noreloc-s3: - shard-snb: [PASS][15] -> [DMESG-WARN][16] ([fdo#102365]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-snb2/igt@gem_soft...@noreloc-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-snb2/igt@gem_soft...@noreloc-s3.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-apl7/igt@gem_workarou...@suspend-resume-context.html - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb7/igt@gem_workarou...@suspend-resume-context.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-iclb7/igt@gem_workarou...@suspend-resume-context.html * igt@kms_busy@extended-pageflip-hang-oldfb-render-c: - shard-apl: [PASS][21] -> [SKIP][22] ([fdo#109271] / [fdo#109278]) +14 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl2/igt@kms_b...@extended-pageflip-hang-oldfb-render-c.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/shard-apl1/igt@kms_b...@extended-pageflip-hang-oldfb-render-c.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3)
== Series Details == Series: drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3) URL : https://patchwork.freedesktop.org/series/66625/ State : success == Summary == CI Bug Log - changes from CI_DRM_6909_full -> Patchwork_14431_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14431_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl1/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-apl7/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-skl10/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-skl6/igt@i915_susp...@debugfs-reader.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#103558]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge: - shard-apl: [PASS][11] -> [SKIP][12] ([fdo#109271] / [fdo#109278]) +17 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl1/igt@kms_cursor_edge_w...@pipe-a-64x64-top-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-apl1/igt@kms_cursor_edge_w...@pipe-a-64x64-top-edge.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_draw_crc@draw-method-xrgb-pwrite-ytiled: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103184] / [fdo#103232] / [fdo#108222]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-skl7/igt@kms_draw_...@draw-method-xrgb-pwrite-ytiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-skl5/igt@kms_draw_...@draw-method-xrgb-pwrite-ytiled.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#100368]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-glk3/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_flip@flip-vs-blocking-wf-vblank: - shard-apl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103927]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl5/igt@kms_f...@flip-vs-blocking-wf-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-apl2/igt@kms_f...@flip-vs-blocking-wf-vblank.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([fdo#103540]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-hsw5/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/shard-hsw4/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +7 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [24]:
Re: [Intel-gfx] [RFC PATCH 2/2] mdev: introduce device specific ops
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 17, 2019 6:17 PM
>
> On 2019/9/17 下午4:09, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Thursday, September 12, 2019 5:40 PM
> >>
> >> Currently, except for the crate and remove. The rest fields of
> >> mdev_parent_ops is just designed for vfio-mdev driver and may not
> help
> >> for kernel mdev driver. So follow the device id support by previous
> >> patch, this patch introduces device specific ops which points to
> >> device specific ops (e.g vfio ops). This allows the future drivers
> >> like virtio-mdev to implement its own device specific ops.
> > Can you give an example about what ops might be required to support
> > kernel mdev driver? I know you posted a link earlier, but putting a small
> > example here can save time and avoid inconsistent understanding. Then
> > it will help whether the proposed split makes sense or there is a
> > possibility of redefining the callbacks to meet the both requirements.
> > imo those callbacks fulfill some basic requirements when mediating
> > a device...
>
>
> I put it in the cover letter.
>
> The link is https://lkml.org/lkml/2019/9/10/135 which abuses the current
> VFIO based mdev parent ops.
>
> Thanks
So the main problem is the handling of userspace pointers vs.
kernel space pointers. You still implement read/write/ioctl
callbacks which is a subset of current parent_ops definition.
In that regard is it better to introduce some helper to handle
the pointer difference in mdev core, while still keeping the
same set of parent ops (in whatever form suitable for both)?
>
>
> >> Signed-off-by: Jason Wang
> >> ---
> >> drivers/gpu/drm/i915/gvt/kvmgt.c | 14 +++---
> >> drivers/s390/cio/vfio_ccw_ops.c | 14 +++---
> >> drivers/s390/crypto/vfio_ap_ops.c | 10 +++--
> >> drivers/vfio/mdev/vfio_mdev.c | 30 +++--
> >> include/linux/mdev.h | 72 ++-
> >> samples/vfio-mdev/mbochs.c| 16 ---
> >> samples/vfio-mdev/mdpy.c | 16 ---
> >> samples/vfio-mdev/mtty.c | 14 +++---
> >> 8 files changed, 113 insertions(+), 73 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> index 19d51a35f019..64823998fd58 100644
> >> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> >> @@ -1600,20 +1600,22 @@ static const struct attribute_group
> >> *intel_vgpu_groups[] = {
> >>NULL,
> >> };
> >>
> >> -static struct mdev_parent_ops intel_vgpu_ops = {
> >> - .mdev_attr_groups = intel_vgpu_groups,
> >> - .create = intel_vgpu_create,
> >> - .remove = intel_vgpu_remove,
> >> -
> >> +static struct vfio_mdev_parent_ops intel_vfio_vgpu_ops = {
> >>.open = intel_vgpu_open,
> >>.release= intel_vgpu_release,
> >> -
> >>.read = intel_vgpu_read,
> >>.write = intel_vgpu_write,
> >>.mmap = intel_vgpu_mmap,
> >>.ioctl = intel_vgpu_ioctl,
> >> };
> >>
> >> +static struct mdev_parent_ops intel_vgpu_ops = {
> >> + .mdev_attr_groups = intel_vgpu_groups,
> >> + .create = intel_vgpu_create,
> >> + .remove = intel_vgpu_remove,
> >> + .device_ops = _vfio_vgpu_ops,
> >> +};
> >> +
> >> static int kvmgt_host_init(struct device *dev, void *gvt, const void
> >> *ops)
> >> {
> >>struct attribute **kvm_type_attrs;
> >> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> >> b/drivers/s390/cio/vfio_ccw_ops.c
> >> index f87d9409e290..96e9f18100ae 100644
> >> --- a/drivers/s390/cio/vfio_ccw_ops.c
> >> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> >> @@ -564,11 +564,7 @@ static ssize_t vfio_ccw_mdev_ioctl(struct
> >> mdev_device *mdev,
> >>}
> >> }
> >>
> >> -static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
> >> - .owner = THIS_MODULE,
> >> - .supported_type_groups = mdev_type_groups,
> >> - .create = vfio_ccw_mdev_create,
> >> - .remove = vfio_ccw_mdev_remove,
> >> +static const struct vfio_mdev_parent_ops vfio_mdev_ops = {
> >>.open = vfio_ccw_mdev_open,
> >>.release= vfio_ccw_mdev_release,
> >>.read = vfio_ccw_mdev_read,
> >> @@ -576,6 +572,14 @@ static const struct mdev_parent_ops
> >> vfio_ccw_mdev_ops = {
> >>.ioctl = vfio_ccw_mdev_ioctl,
> >> };
> >>
> >> +static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
> >> + .owner = THIS_MODULE,
> >> + .supported_type_groups = mdev_type_groups,
> >> + .create = vfio_ccw_mdev_create,
> >> + .remove = vfio_ccw_mdev_remove,
> >> + .device_ops = _mdev_ops,
> >> +};
> >> +
> >> int vfio_ccw_mdev_reg(struct subchannel *sch)
> >> {
> >>return
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix DP MST error after unplugging TypeC cable
== Series Details ==
Series: drm/i915/dp: Fix DP MST error after unplugging TypeC cable
URL : https://patchwork.freedesktop.org/series/66837/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6911 -> Patchwork_14437
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/
Known issues
Here are the changes found in Patchwork_14437 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_auth@basic-auth:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@core_a...@basic-auth.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-icl-u3/igt@core_a...@basic-auth.html
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] /
[fdo#111214])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][5] -> [FAIL][6] ([fdo#108511])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#109483])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u2/igt@kms_chamel...@hdmi-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-icl-u2/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [PASS][9] -> [INCOMPLETE][10] ([fdo#107718])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_prop_blob@basic:
- {fi-icl-u4}:[DMESG-WARN][15] ([fdo#105602]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u4/igt@kms_prop_b...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/fi-icl-u4/igt@kms_prop_b...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 47)
--
Additional (1): fi-icl-guc
Missing(8): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6911 -> Patchwork_14437
CI-20190529: 20190529
CI_DRM_6911: 2e04def5afc3b2bd724dc6f3f6525c5ebf1f87d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14437: 90e757d078d4105644a710ee872565da671ddc9e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
90e757d078d4 drm/i915/dp: Fix DP MST error after unplugging TypeC cable
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14437/index.html
___
Intel-gfx mailing list
Re: [Intel-gfx] [RFC PATCH 0/2] Mdev: support mutiple kinds of devices
On Wed, 18 Sep 2019 01:54:43 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Wednesday, September 18, 2019 1:31 AM > > > > [cc +Parav] > > > > On Thu, 12 Sep 2019 17:40:10 +0800 > > Jason Wang wrote: > > > > > Hi all: > > > > > > During the development of virtio-mdev[1]. I find that mdev needs to be > > > extended to support devices other than vfio mdev device. So this > > > series tries to extend the mdev to be able to differ from different > > > devices by: > > > > > > - device id and matching for mdev bus > > > - device speicfic callbacks and move vfio callbacks there > > > > > > Sent for early reivew, compile test only! > > > > > > Thanks > > > > > > [1] https://lkml.org/lkml/2019/9/10/135 > > > > I expect Parav must have something similar in the works for their > > in-kernel networking mdev support. Link to discussion so far: > > > > https://lore.kernel.org/kvm/20190912094012.29653-1- > > jasow...@redhat.com/T/#t > > > > It links to the current thread. Is it intended or do you want > people to look at another thread driven by Parav? :-) Sorry, the link was provided for Parav since they weren't cc'd. Thanks, Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Clear Color Support for TGL Render Decompression
== Series Details == Series: Clear Color Support for TGL Render Decompression URL : https://patchwork.freedesktop.org/series/66814/ State : success == Summary == CI Bug Log - changes from CI_DRM_6909_full -> Patchwork_14430_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_14430_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14430_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14430_full: ### IGT changes ### Warnings * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [DMESG-WARN][1] ([fdo#108566]) -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html Known issues Here are the changes found in Patchwork_14430_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-iclb6/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_mmap_gtt@big-copy-xy: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl7/igt@gem_mmap_...@big-copy-xy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl2/igt@gem_mmap_...@big-copy-xy.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#103558]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103232]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html * igt@kms_cursor_edge_walk@pipe-a-64x64-top-edge: - shard-apl: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) +19 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl1/igt@kms_cursor_edge_w...@pipe-a-64x64-top-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl6/igt@kms_cursor_edge_w...@pipe-a-64x64-top-edge.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled: - shard-apl: [PASS][19] -> [SKIP][20] ([fdo#109271]) +177 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/shard-apl5/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/shard-apl6/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [PASS][21] -> [FAIL][22] ([fdo#105363]) [21]:
Re: [Intel-gfx] [RFC PATCH 0/2] Mdev: support mutiple kinds of devices
> From: Alex Williamson > Sent: Wednesday, September 18, 2019 1:31 AM > > [cc +Parav] > > On Thu, 12 Sep 2019 17:40:10 +0800 > Jason Wang wrote: > > > Hi all: > > > > During the development of virtio-mdev[1]. I find that mdev needs to be > > extended to support devices other than vfio mdev device. So this > > series tries to extend the mdev to be able to differ from different > > devices by: > > > > - device id and matching for mdev bus > > - device speicfic callbacks and move vfio callbacks there > > > > Sent for early reivew, compile test only! > > > > Thanks > > > > [1] https://lkml.org/lkml/2019/9/10/135 > > I expect Parav must have something similar in the works for their > in-kernel networking mdev support. Link to discussion so far: > > https://lore.kernel.org/kvm/20190912094012.29653-1- > jasow...@redhat.com/T/#t > It links to the current thread. Is it intended or do you want people to look at another thread driven by Parav? :-) Thanks Kevin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
From: Srinivasan S
This patch avoids DP MST payload error message in dmesg, as it is trying
to read the payload from the disconnected DP MST device. After the unplug
the connector status is disconnected and we should not be looking for the
payload and hence remove the error and throw the warning.
This details can be found in:
https://bugs.freedesktop.org/show_bug.cgi?id=111632
Signed-off-by: Srinivasan S
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index eeeb3f933aa4..5b2278fdf675 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder,
ret = drm_dp_update_payload_part1(_dp->mst_mgr);
if (ret) {
- DRM_ERROR("failed to update payload %d\n", ret);
+ if (!connector ||
+ connector->base.status != connector_status_connected) {
+ DRM_WARN("DP MST disconnect\n");
+ } else {
+ DRM_ERROR("failed to update payload %d\n", ret);
+ }
}
if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
== Series Details == Series: series starting with [CI,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync URL : https://patchwork.freedesktop.org/series/66835/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6911 -> Patchwork_14436 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14436 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14436, 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_14436/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14436: ### IGT changes ### Possible regressions * igt@kms_busy@basic-flip-a: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@kms_b...@basic-flip-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-icl-u3/igt@kms_b...@basic-flip-a.html - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u2/igt@kms_b...@basic-flip-a.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-icl-u2/igt@kms_b...@basic-flip-a.html Known issues Here are the changes found in Patchwork_14436 that come from known issues: ### IGT changes ### Issues hit * igt@i915_getparams_basic@basic-eu-total: - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@i915_getparams_ba...@basic-eu-total.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-icl-u3/igt@i915_getparams_ba...@basic-eu-total.html Possible fixes * igt@gem_mmap_gtt@basic-write-no-prefault: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-blb-e6850/igt@i915_module_l...@reload.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][11] ([fdo#111407]) -> [FAIL][12] ([fdo#111096]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 47) -- Additional (1): fi-icl-guc Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6911 -> Patchwork_14436 CI-20190529: 20190529 CI_DRM_6911: 2e04def5afc3b2bd724dc6f3f6525c5ebf1f87d2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14436: f3076b0b8007a2a5d424e3e7f19588cf519a180d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f3076b0b8007 drm/i915/display/icl: In port sync mode disable slaves first then master 7413f273f931 drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence afc2925b8f30 drm/i915/display/icl: Enable master-slaves in trans port sync 1e2980d136ba drm/i915/display/icl: HW state readout for transcoder port sync config c05137212238 drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports a6f2109d13c4 drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14436/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/tgl: Finish modular FIA support on registers
On Fri, 2019-09-13 at 23:24 -0700, Lucas De Marchi wrote:
> On Fri, Sep 13, 2019 at 3:33 PM José Roberto de Souza
> wrote:
> > If platform supports and has modular FIA is enabled, the registers
> > bits also change, example: reading TC3 registers with modular FIA
> > enabled, driver should read from FIA2 but with TC1 bits offsets.
> >
> > It is described in BSpec 50231 for DFLEXDPSP, other registers don't
> > have the BSpec description but testing in real hardware have proven
> > that it had moved for all other registers too.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 2 +
> > drivers/gpu/drm/i915/display/intel_tc.c | 52 --
> > --
> > drivers/gpu/drm/i915/display/intel_tc.h | 2 +
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > drivers/gpu/drm/i915/i915_reg.h | 45 --
> > ---
> > 5 files changed, 61 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 4e001113e828..cd0a248bfe49 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15384,6 +15384,8 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> > if (!HAS_DISPLAY(dev_priv))
> > return;
> >
> > + intel_tc_init(dev_priv);
> > +
> > if (INTEL_GEN(dev_priv) >= 12) {
> > /* TODO: initialize TC ports as well */
> > intel_ddi_init(dev_priv, PORT_A);
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 3a7302e360cc..fc5d0e73cf21 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -23,19 +23,21 @@ static const char *tc_port_mode_name(enum
> > tc_port_mode mode)
> > return names[mode];
> > }
> >
> > -static bool has_modular_fia(struct drm_i915_private *i915)
> > +void intel_tc_init(struct drm_i915_private *i915)
> > {
> > + u32 val;
> > +
> > if (!INTEL_INFO(i915)->display.has_modular_fia)
> > - return false;
> > + return;
> >
> > - return intel_uncore_read(>uncore,
> > -PORT_TX_DFLEXDPSP(FIA1)) &
> > MODULAR_FIA_MASK;
> > + val = intel_uncore_read(>uncore,
> > PORT_TX_DFLEXDPSP(FIA1));
> > + i915->has_modular_fia = val & MODULAR_FIA_MASK;
>
> Not a fan of stuffing tc-private details in i195 struct. Since this
> is
> only executed on initialization maybe it's
> not worth the few register reads we spare. If we go with this
> approach, then I think we should not use
> "has_" prefix so we don't get confused by the device_info fields.
>
> > }
> >
> > static enum phy_fia tc_port_to_fia(struct drm_i915_private *i915,
> >enum tc_port tc_port)
> > {
> > - if (!has_modular_fia(i915))
> > + if (!i915->has_modular_fia)
> > return FIA1;
> >
> > /*
> > @@ -51,14 +53,15 @@ u32 intel_tc_port_get_lane_mask(struct
> > intel_digital_port *dig_port)
> > enum tc_port tc_port = intel_port_to_tc(i915, dig_port-
> > >base.port);
> > struct intel_uncore *uncore = >uncore;
> > u32 lane_mask;
> > + bool mod_fia = i915->has_modular_fia;
>
> s/mod_fia/modular_fia/ or just don't add the additional var
>
> > lane_mask = intel_uncore_read(uncore,
> > PORT_TX_DFLEXDPSP(dig_port-
> > >tc_phy_fia));
> >
> > WARN_ON(lane_mask == 0x);
> >
> > - return (lane_mask & DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> > - DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> > + return (lane_mask & DP_LANE_ASSIGNMENT_MASK(mod_fia,
> > tc_port)) >>
> > + DP_LANE_ASSIGNMENT_SHIFT(mod_fia, tc_port);
> > }
> >
> > u32 intel_tc_port_get_pin_assignment_mask(struct
> > intel_digital_port *dig_port)
> > @@ -66,6 +69,7 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
> > intel_digital_port *dig_port)
> > struct drm_i915_private *i915 = to_i915(dig_port-
> > >base.base.dev);
> > enum tc_port tc_port = intel_port_to_tc(i915, dig_port-
> > >base.port);
> > struct intel_uncore *uncore = >uncore;
> > + bool mod_fia = i915->has_modular_fia;
> > u32 pin_mask;
> >
> > pin_mask = intel_uncore_read(uncore,
> > @@ -73,8 +77,8 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
> > intel_digital_port *dig_port)
> >
> > WARN_ON(pin_mask == 0x);
> >
> > - return (pin_mask & DP_PIN_ASSIGNMENT_MASK(tc_port)) >>
> > - DP_PIN_ASSIGNMENT_SHIFT(tc_port);
> > + return (pin_mask & DP_PIN_ASSIGNMENT_MASK(mod_fia,
> > tc_port)) >>
> > + DP_PIN_ASSIGNMENT_SHIFT(mod_fia, tc_port);
> > }
> >
> > int
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
== Series Details == Series: series starting with [CI,1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync URL : https://patchwork.freedesktop.org/series/66835/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/6] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
In case of tiled displays where different tiles are displayed across
different ports, we need to synchronize the transcoders involved.
This patch implements the transcoder port sync feature for
synchronizing one master transcoder with one or more slave
transcoders. This is only enbaled in slave transcoder
and the master transcoder is unaware that it is operating
in this mode.
This has been tested with tiled display connected to ICL.
v5:
* Add TRANSCODER_D case and MISSING_CASE (Maarten)
v4:
Rebase
v3:
* Check of DP_MST moved to atomic_check (Maarten)
v2:
* Do not use RMW, just write to the register in commit (Jani N)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 94ac63b38eb7..b0f76e47f5a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4395,6 +4395,49 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
+static void icl_enable_trans_port_sync(const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 trans_ddi_func_ctl2_val;
+ u8 master_select;
+
+ /*
+* Configure the master select and enable Transcoder Port Sync for
+* Slave CRTCs transcoder.
+*/
+ if (crtc_state->master_transcoder == INVALID_TRANSCODER)
+ return;
+
+ switch (crtc_state->master_transcoder) {
+ case TRANSCODER_A:
+ master_select = 1;
+ break;
+ case TRANSCODER_B:
+ master_select = 2;
+ break;
+ case TRANSCODER_C:
+ master_select = 3;
+ break;
+ case TRANSCODER_D:
+ master_select = 4;
+ break;
+ case TRANSCODER_EDP:
+ default:
+ MISSING_CASE(crtc_state->master_transcoder);
+ master_select = 0;
+ }
+ /* Set the master select bits for Tranascoder Port Sync */
+ trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
+ PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
+ /* Enable Transcoder Port Sync */
+ trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
+
+ I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
+ trans_ddi_func_ctl2_val);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -6463,6 +6506,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_set_pipe_timings(pipe_config);
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_enable_trans_port_sync(pipe_config);
+
intel_set_pipe_src_size(pipe_config);
if (cpu_transcoder != TRANSCODER_EDP &&
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/6] drm/i915/display/icl: Enable master-slaves in trans port sync
As per the display enable sequence, we need to follow the enable sequence
for slaves first with DP_TP_CTL set to Idle and configure the transcoder
port sync register to select the corersponding master, then follow the
enable sequence for master leaving DP_TP_CTL to idle.
At this point the transcoder port sync mode is configured and enabled
and the Vblanks of both ports are synchronized so then set DP_TP_CTL
for the slave and master to Normal and do post crtc enable updates.
v6:
* Modeset implies active_changed, remove one condition (Maarten)
v5:
* Fix checkpatch warning (Manasi)
v4:
* Reuse skl_commit_modeset_enables() hook (Maarten)
* Obtain slave crtc and states from master (Maarten)
v3:
* Rebase on drm-tip (Manasi)
v2:
* Create a icl_update_crtcs hook (Maarten, Danvet)
* This sequence only for CRTCs in trans port sync mode (Maarten)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 159 ++-
drivers/gpu/drm/i915/display/intel_display.h | 4 +
3 files changed, 162 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e6394139964..62e9f5602b6b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3347,7 +3347,8 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
true);
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_start_link_train(intel_dp);
- if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
+ if ((port != PORT_A || INTEL_GEN(dev_priv) >= 9) &&
+ !is_trans_port_sync_mode(dev_priv, crtc_state))
intel_dp_stop_link_train(intel_dp);
intel_ddi_enable_fec(encoder, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bea3f631ad36..045ca85089a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -521,6 +521,24 @@ needs_modeset(const struct intel_crtc_state *state)
return drm_atomic_crtc_needs_modeset(>base);
}
+bool
+is_trans_port_sync_mode(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *state)
+{
+ return (INTEL_GEN(dev_priv) >= 11 &&
+ (state->master_transcoder != INVALID_TRANSCODER ||
+state->sync_mode_slaves_mask));
+}
+
+static bool
+is_trans_port_sync_master(struct drm_i915_private *dev_priv,
+ const struct intel_crtc_state *state)
+{
+ return (INTEL_GEN(dev_priv) >= 11 &&
+ (state->master_transcoder == INVALID_TRANSCODER &&
+state->sync_mode_slaves_mask));
+}
+
/*
* Platform specific helpers to calculate the port PLL loopback- (clock.m),
* and post-divider (clock.p) values, pre- (clock.vco) and post-divided fast
@@ -13877,6 +13895,30 @@ static void intel_update_crtc(struct intel_crtc *crtc,
intel_finish_crtc_commit(state, crtc);
}
+static struct intel_crtc *intel_get_slave_crtc(struct drm_i915_private
*dev_priv,
+ struct intel_crtc_state
*new_crtc_state)
+{
+ if (new_crtc_state->sync_mode_slaves_mask &
+ BIT(TRANSCODER_A))
+ return intel_get_crtc_for_pipe(dev_priv,
+ PIPE_A);
+ else if (new_crtc_state->sync_mode_slaves_mask &
+BIT(TRANSCODER_B))
+ return intel_get_crtc_for_pipe(dev_priv,
+ PIPE_B);
+ else if (new_crtc_state->sync_mode_slaves_mask &
+BIT(TRANSCODER_C))
+ return intel_get_crtc_for_pipe(dev_priv,
+ PIPE_C);
+ else if (new_crtc_state->sync_mode_slaves_mask &
+BIT(TRANSCODER_D))
+ return intel_get_crtc_for_pipe(dev_priv,
+ PIPE_D);
+ /* should never happen */
+ WARN_ON(1);
+ return NULL;
+}
+
static void intel_old_crtc_state_disables(struct intel_atomic_state *state,
struct intel_crtc_state
*old_crtc_state,
struct intel_crtc_state
*new_crtc_state,
@@ -13955,6 +13997,104 @@ static void intel_commit_modeset_enables(struct
intel_atomic_state *state)
}
}
+static void intel_crtc_enable_trans_port_sync(struct intel_crtc *crtc,
+ struct intel_atomic_state *state,
+ struct intel_crtc_state
*new_crtc_state)
+{
+ struct drm_i915_private *dev_priv =
[Intel-gfx] [CI 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config
After the state is committed, we readout the HW registers and compare
the HW state with the SW state that we just committed.
For Transcdoer port sync, we add master_transcoder and the
salves bitmask to the crtc_state, hence we need to read those during
the HW state readout to avoid pipe state mismatch.
v2:
* Add Transcoder_D and MISSING_CASE (Maarten)
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 49
1 file changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b0f76e47f5a6..bea3f631ad36 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10439,6 +10439,52 @@ static void haswell_get_ddi_port_state(struct
intel_crtc *crtc,
}
}
+static void icelake_get_trans_port_sync_config(struct intel_crtc *crtc,
+ struct intel_crtc_state
*pipe_config)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 trans_port_sync, transcoders, master_select;
+ enum transcoder cpu_transcoder;
+
+ trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(pipe_config->cpu_transcoder));
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE) {
+ master_select = trans_port_sync &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK;
+ switch (master_select) {
+ case 1:
+ pipe_config->master_transcoder = TRANSCODER_A;
+ break;
+ case 2:
+ pipe_config->master_transcoder = TRANSCODER_B;
+ break;
+ case 3:
+ pipe_config->master_transcoder = TRANSCODER_C;
+ break;
+ case 4:
+ pipe_config->master_transcoder = TRANSCODER_D;
+ break;
+ default:
+ MISSING_CASE(master_select);
+ }
+
+ pipe_config->sync_mode_slaves_mask = 0;
+ } else {
+ pipe_config->master_transcoder = INVALID_TRANSCODER;
+
+ transcoders = BIT(TRANSCODER_EDP) |
+ BIT(TRANSCODER_A) |
+ BIT(TRANSCODER_B) |
+ BIT(TRANSCODER_C);
+ for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
transcoders) {
+ trans_port_sync =
I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
+
+ if (trans_port_sync & PORT_SYNC_MODE_ENABLE)
+ pipe_config->sync_mode_slaves_mask |=
BIT(cpu_transcoder);
+ }
+ }
+}
+
static bool haswell_get_pipe_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
@@ -10535,6 +10581,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->pixel_multiplier = 1;
}
+ if (INTEL_GEN(dev_priv) >= 11)
+ icelake_get_trans_port_sync_config(crtc, pipe_config);
+
out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put(dev_priv,
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 5/6] drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence
This clears the transcoder port sync bits of the TRANS_DDI_FUNC_CTL2
register during crtc_disable().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 23
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 045ca85089a6..66f9c388ced3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4456,6 +4456,26 @@ static void icl_enable_trans_port_sync(const struct
intel_crtc_state *crtc_state
trans_ddi_func_ctl2_val);
}
+static void icl_disable_transcoder_port_sync(const struct intel_crtc_state
*old_crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ i915_reg_t reg;
+ u32 trans_ddi_func_ctl2_val;
+
+ if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
+ return;
+
+ DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave Transcoder %s\n",
+ transcoder_name(old_crtc_state->cpu_transcoder));
+
+ reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
+ trans_ddi_func_ctl2_val = I915_READ(reg);
+ trans_ddi_func_ctl2_val &= ~(PORT_SYNC_MODE_ENABLE |
+PORT_SYNC_MODE_MASTER_SELECT_MASK);
+ I915_WRITE(reg, trans_ddi_func_ctl2_val);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -6705,6 +6725,9 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
+ if (INTEL_GEN(dev_priv) >= 11)
+ icl_disable_transcoder_port_sync(old_crtc_state);
+
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_disable_transcoder_func(old_crtc_state);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
In case of tiled displays when the two tiles are sent across two CRTCs
over two separate DP SST connectors, we need a mechanism to synchronize
the two CRTCs and their corresponding transcoders.
So use the master-slave mode where there is one master corresponding
to last horizontal and vertical tile that needs to be genlocked with
all other slave tiles.
This patch identifies saves the master transcoder in all the slave
CRTC states. This is needed to select the master CRTC/transcoder
while configuring transcoder port sync for the corresponding slaves.
v4:
* Rebase
v3:
* Use master_tramscoder instead of master_crtc for valid
HW state readouts (Ville)
v2:
* Move this to intel_mode_set_pipe_config(Jani N, Ville)
* Use slave_bitmask to save associated slaves in master crtc state (Ville)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 105 ++
drivers/gpu/drm/i915/display/intel_display.h | 1 +
.../drm/i915/display/intel_display_types.h| 6 +
3 files changed, 112 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cc74844d3ea..94ac63b38eb7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11760,6 +11760,91 @@ static bool c8_planes_changed(const struct
intel_crtc_state *new_crtc_state)
return !old_crtc_state->c8_planes != !new_crtc_state->c8_planes;
}
+static int icl_add_sync_mode_crtcs(struct drm_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct drm_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_connector *master_connector, *connector;
+ struct drm_connector_state *connector_state;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_crtc *master_crtc = NULL;
+ struct drm_crtc_state *master_crtc_state;
+ struct intel_crtc_state *master_pipe_config;
+ int i, tile_group_id;
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return 0;
+
+ /*
+* In case of tiled displays there could be one or more slaves but
there is
+* only one master. Lets make the CRTC used by the connector
corresponding
+* to the last horizonal and last vertical tile a master/genlock CRTC.
+* All the other CRTCs corresponding to other tiles of the same Tile
group
+* are the slave CRTCs and hold a pointer to their genlock CRTC.
+*/
+ for_each_new_connector_in_state(state, connector, connector_state, i) {
+ if (connector_state->crtc != crtc)
+ continue;
+ if (!connector->has_tile)
+ continue;
+ if (crtc_state->base.mode.hdisplay != connector->tile_h_size ||
+ crtc_state->base.mode.vdisplay != connector->tile_v_size)
+ return 0;
+ if (connector->tile_h_loc == connector->num_h_tile - 1 &&
+ connector->tile_v_loc == connector->num_v_tile - 1)
+ continue;
+ crtc_state->sync_mode_slaves_mask = 0;
+ tile_group_id = connector->tile_group->id;
+ drm_connector_list_iter_begin(_priv->drm, _iter);
+ drm_for_each_connector_iter(master_connector, _iter) {
+ struct drm_connector_state *master_conn_state = NULL;
+
+ if (!master_connector->has_tile)
+ continue;
+ if (master_connector->tile_h_loc !=
master_connector->num_h_tile - 1 ||
+ master_connector->tile_v_loc !=
master_connector->num_v_tile - 1)
+ continue;
+ if (master_connector->tile_group->id != tile_group_id)
+ continue;
+
+ master_conn_state =
drm_atomic_get_connector_state(state,
+
master_connector);
+ if (IS_ERR(master_conn_state)) {
+ drm_connector_list_iter_end(_iter);
+ return PTR_ERR(master_conn_state);
+ }
+ if (master_conn_state->crtc) {
+ master_crtc = master_conn_state->crtc;
+ break;
+ }
+ }
+ drm_connector_list_iter_end(_iter);
+
+ if (!master_crtc) {
+ DRM_DEBUG_KMS("Could not find Master CRTC for Slave
CRTC %d\n",
+ connector_state->crtc->base.id);
+ return -EINVAL;
[Intel-gfx] [CI 6/6] drm/i915/display/icl: In port sync mode disable slaves first then master
In the transcoder port sync mode, the slave transcoders mask their vblanks
until master transcoder's vblank so while disabling them, make
sure slaves are disabled first and then the masters.
v4:
* Obtain slave state from master (Maarten)
v3:
* Rebase
v2:
* Use the intel_old_crtc_state_disables() helper
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 62 ++--
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 66f9c388ced3..ce1fa47318af 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13977,8 +13977,42 @@ static void intel_old_crtc_state_disables(struct
intel_atomic_state *state,
new_crtc_state);
}
+static void intel_trans_port_sync_modeset_disables(struct intel_atomic_state
*state,
+ struct intel_crtc *crtc,
+ struct intel_crtc_state
*old_crtc_state,
+ struct intel_crtc_state
*new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_crtc *slave_crtc = intel_get_slave_crtc(dev_priv,
+new_crtc_state);
+ struct intel_crtc_state *new_slave_crtc_state =
+ intel_atomic_get_new_crtc_state(state, slave_crtc);
+ struct intel_crtc_state *old_slave_crtc_state =
+ intel_atomic_get_old_crtc_state(state, slave_crtc);
+
+ WARN_ON(!slave_crtc || !new_slave_crtc_state ||
+ !old_slave_crtc_state);
+
+ /* Disable Slave first */
+ intel_pre_plane_update(old_slave_crtc_state, new_slave_crtc_state);
+ if (old_slave_crtc_state->base.active)
+ intel_old_crtc_state_disables(state,
+ old_slave_crtc_state,
+ new_slave_crtc_state,
+ slave_crtc);
+
+ /* Disable Master */
+ intel_pre_plane_update(old_crtc_state, new_crtc_state);
+ if (old_crtc_state->base.active)
+ intel_old_crtc_state_disables(state,
+ old_crtc_state,
+ new_crtc_state,
+ crtc);
+}
+
static void intel_commit_modeset_disables(struct intel_atomic_state *state)
{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
int i;
@@ -13995,13 +14029,29 @@ static void intel_commit_modeset_disables(struct
intel_atomic_state *state)
if (!needs_modeset(new_crtc_state))
continue;
- intel_pre_plane_update(old_crtc_state, new_crtc_state);
+ /* In case of Transcoder port Sync master slave CRTCs can be
+* assigned in any order and we need to make sure that
+* slave CRTCs are disabled first and then master CRTC since
+* Slave vblanks are masked till Master Vblanks.
+*/
+ if (is_trans_port_sync_mode(dev_priv, new_crtc_state)) {
+ if (is_trans_port_sync_master(dev_priv,
+ new_crtc_state))
+ intel_trans_port_sync_modeset_disables(state,
+ crtc,
+
old_crtc_state,
+
new_crtc_state);
+ else
+ continue;
+ } else {
+ intel_pre_plane_update(old_crtc_state, new_crtc_state);
- if (old_crtc_state->base.active)
- intel_old_crtc_state_disables(state,
- old_crtc_state,
- new_crtc_state,
- crtc);
+ if (old_crtc_state->base.active)
+ intel_old_crtc_state_disables(state,
+ old_crtc_state,
+ new_crtc_state,
+ crtc);
+ }
}
}
--
2.19.1
Re: [Intel-gfx] [PATCH 04/14] drm/i915/tgl: Fix driver crash when update_active_dpll is called
On Fri, 2019-09-13 at 23:32 -0700, Lucas De Marchi wrote:
> On Fri, Sep 13, 2019 at 3:33 PM José Roberto de Souza
> wrote:
> > From: "Taylor, Clinton A"
> >
> > TGL PLL function table doesn't include and update_active_pll
> > function.
> > The driver attempts to make a call to this function and crashes
> > during
> > PLL changes.
>
> the crash would only occur if the port was initialized. The ordering
> in this series means this is
> not a "fix" but rather finishing the implementation for TC ports
> before initializing them. So we may
> want to adjust the commit message accordingly. The reason we missed
> that for TGL is that its need came
> in parallel to the TGL support hitting upstream.
>
Okay will change commit message and description to:
drm/i915/tgl/pll: Set update_active_dpll
Commit 24a7bfe0c2d7 ("drm/i915: Keep the TypeC port mode fixed when the
port is active") added this new hook while in parallel TGL upstream was
happening and this was missed.
Without this driver will crash when TC DDI is added and driver is
preparing to do a full modeset.
Sounds good?
> My nit with this hook is that `update_active_dpll` is exclusively
> used
> by *TC* ports on gen 11+ and
> a) it's not clear about that from the name and/or b) if it's generic
> it should not crash when it's missing.
>
> I think Imre had a patch to address it, at least renaming the hook, I
> don't remember. +Imre.
Well we can do that on top or in Imre series not planing to address
this in here.
>
> Lucas De Marchi
@Clint
Looks like git send-email don't like "," in the name and replaces your
email address to tay...@freedesktop.org so I'm going to replace your
signed-off-by to "Clinton A Taylor " or do
you prefer something else?
>
> > Signed-off-by: Taylor, Clinton A
> > ---
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index 98288edf88f0..84e734d44828 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -3479,6 +3479,7 @@ static const struct intel_dpll_mgr
> > tgl_pll_mgr = {
> > .dpll_info = tgl_plls,
> > .get_dplls = icl_get_dplls,
> > .put_dplls = icl_put_dplls,
> > + .update_active_dpll = icl_update_active_dpll,
> > .dump_hw_state = icl_dump_hw_state,
> > };
> >
> > --
> > 2.23.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Adding YUV444 packed format support for skl+
On Mon, Sep 16, 2019 at 10:39:55AM -0700, Bob Paauwe wrote:
> From: Stanislav Lisovskiy
>
> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> specification.
>
> v2: Edited commit message, removed redundant whitespaces.
>
> v3: Fixed fallthrough logic for the format switch cases.
>
> v4: Yet again fixed fallthrough logic, to reuse code from other case
> labels.
>
> v5: Started to use XYUV instead of AYUV, as we don't use alpha.
>
> v6: Removed unneeded initializer for new XYUV format.
>
> v7: Added scaling support for DRM_FORMAT_XYUV
>
> v8: Edited commit message to be more clear about skl+, renamed
> PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> doesn't support per-pixel alpha. Fixed minor code issues.
>
> v9: Moved DRM format check to proper place in intel_framebuffer_init.
>
> v10: Added missing XYUV format to sprite planes for skl+.
>
> v11: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV.
>
> v12: Fixed rebase conflicts
>
> V13: Rebased.
>
> v12:
> Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Stanislav Lisovskiy
> Signed-off-by: Bob Paauwe
The rebase of https://patchwork.freedesktop.org/patch/261142/ looks
correct, so
Reviewed-by: Matt Roper
but it looks like we'll also need an update to IGT before we merge this,
otherwise it will break CI testing for kms_plane and kms_plane_scaling.
IGT needs this new format added to formats[] in lib/igt_color_encoding.c
so that lookup_fourcc() won't return failures.
Matt
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 5 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 3 +++
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 12bb8f951edf..7b9fb9e7893d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2978,6 +2978,8 @@ int skl_format_to_fourcc(int format, bool rgb_order,
> bool alpha)
> return DRM_FORMAT_RGB565;
> case PLANE_CTL_FORMAT_NV12:
> return DRM_FORMAT_NV12;
> + case PLANE_CTL_FORMAT_XYUV:
> + return DRM_FORMAT_XYUV;
> case PLANE_CTL_FORMAT_P010:
> return DRM_FORMAT_P010;
> case PLANE_CTL_FORMAT_P012:
> @@ -3988,6 +3990,8 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
> case DRM_FORMAT_XRGB16161616F:
> case DRM_FORMAT_ARGB16161616F:
> return PLANE_CTL_FORMAT_XRGB_16161616F;
> + case DRM_FORMAT_XYUV:
> + return PLANE_CTL_FORMAT_XYUV;
> case DRM_FORMAT_YUYV:
> return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
> case DRM_FORMAT_YVYU:
> @@ -5581,6 +5585,7 @@ static int skl_update_scaler_plane(struct
> intel_crtc_state *crtc_state,
> case DRM_FORMAT_UYVY:
> case DRM_FORMAT_VYUY:
> case DRM_FORMAT_NV12:
> + case DRM_FORMAT_XYUV:
> case DRM_FORMAT_P010:
> case DRM_FORMAT_P012:
> case DRM_FORMAT_P016:
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7a7078d0ba23..b30809b28e17 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -2015,6 +2015,7 @@ static const u32 skl_plane_formats[] = {
> DRM_FORMAT_YVYU,
> DRM_FORMAT_UYVY,
> DRM_FORMAT_VYUY,
> + DRM_FORMAT_XYUV,
> };
>
> static const u32 skl_planar_formats[] = {
> @@ -2031,6 +2032,7 @@ static const u32 skl_planar_formats[] = {
> DRM_FORMAT_UYVY,
> DRM_FORMAT_VYUY,
> DRM_FORMAT_NV12,
> + DRM_FORMAT_XYUV,
> };
>
> static const u32 glk_planar_formats[] = {
> @@ -2273,6 +2275,7 @@ static bool skl_plane_format_mod_supported(struct
> drm_plane *_plane,
> case DRM_FORMAT_UYVY:
> case DRM_FORMAT_VYUY:
> case DRM_FORMAT_NV12:
> + case DRM_FORMAT_XYUV:
> case DRM_FORMAT_P010:
> case DRM_FORMAT_P012:
> case DRM_FORMAT_P016:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bf37ecebc82f..20cdffc23a95 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6656,7 +6656,7 @@ enum {
> #define PLANE_CTL_FORMAT_P012 (5 << 24)
> #define PLANE_CTL_FORMAT_XRGB_16161616F(6 << 24)
> #define PLANE_CTL_FORMAT_P016 (7 << 24)
> -#define PLANE_CTL_FORMAT_AYUV (8 << 24)
> +#define PLANE_CTL_FORMAT_XYUV (8 << 24)
> #define PLANE_CTL_FORMAT_INDEXED (12 << 24)
> #define PLANE_CTL_FORMAT_RGB_565 (14 << 24)
> #define ICL_PLANE_CTL_FORMAT_MASK (0x1f << 23)
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
>
Re: [Intel-gfx] [PATCH 6/6] drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
On Tue, Sep 17, 2019 at 05:11:55AM -0700, Radhakrishna Sripada wrote:
> Render Decompression is supported with Y-Tiled main surface. The CCS is
> linear and has 4 bits of data for each main surface cache line pair, a
> ratio of 1:256. Additional Clear Color information is passed from the
> user-space through an offset in the GEM BO. Add a new modifier to identify
> and parse new Clear Color information and extend Gen12 render decompression
> functionality to the newly added modifier.
>
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjala
> Cc: Shashank Sharma
> Cc: Rafael Antognolli
> Cc: Matt Roper
> Cc: Nanley G Chery
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 47 +--
> .../drm/i915/display/intel_display_types.h| 3 ++
> drivers/gpu/drm/i915/display/intel_sprite.c | 10 +++-
> drivers/gpu/drm/i915/i915_reg.h | 13 +
> 4 files changed, 69 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2da721a6abab..725b9724da49 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1913,6 +1913,7 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int color_plane)
> /* fall through */
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> if (color_plane == 1)
> return cpp;
> /* fall through */
> @@ -2051,6 +2052,7 @@ static unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> return 0;
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> return 4 * 4 * 1024;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> @@ -2256,6 +2258,7 @@ static bool is_surface_linear(u64 modifier, int
> color_plane)
> return true;
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> return color_plane == 1;
> default:
> return false;
> @@ -2448,6 +2451,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
> fb_modifier)
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> return I915_TILING_Y;
> default:
> return I915_TILING_NONE;
> @@ -2497,6 +2501,21 @@ static const struct drm_format_info
> gen12_ccs_formats[] = {
> .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
> };
>
> +/*
> + * Gen-12 compression uses 4 bits of CCS data for each cache line pair in the
> + * main surface. And each 64B CCS cache line represents an area of 4x1
> Y-tiles
> + * in the main surface. With 4 byte pixels and each Y-tile having dimensions
> of
> + * 32x32 pixels, the ratio turns out to 1B in the CCS for every 2 x 32
> pixels in
> + * the main surface. Additional surface is used to pass the Clear Color
> + * structure for the driver to program the DE.
> + */
> +static const struct drm_format_info gen12_ccs_cc_formats[] = {
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 3, .cpp = {
> 4, 1, 0}, .hsub = 2, .vsub = 32, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 3, .cpp = {
> 4, 1, 0}, .hsub = 2, .vsub = 32, },
> + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 3, .cpp = {
> 4, 1, 0}, .hsub = 2, .vsub = 32, },
> + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 3, .cpp = {
> 4, 1, 0}, .hsub = 2, .vsub = 32, },
I think these last two were supposed to have .has_alpha = true?
> +};
> +
> static const struct drm_format_info *
> lookup_format_info(const struct drm_format_info formats[],
> int num_formats, u32 format)
> @@ -2525,6 +2544,10 @@ intel_get_format_info(const struct drm_mode_fb_cmd2
> *cmd)
> return lookup_format_info(gen12_ccs_formats,
> ARRAY_SIZE(gen12_ccs_formats),
> cmd->pixel_format);
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
> + return lookup_format_info(gen12_ccs_formats,
> + ARRAY_SIZE(gen12_ccs_cc_formats),
> + cmd->pixel_format);
> default:
> return NULL;
> }
> @@ -2534,6 +2557,7 @@ bool is_ccs_modifier(u64 modifier)
> {
> return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
> modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
>
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/kms: Duct-tape for mode object lifetime checks
== Series Details == Series: series starting with [1/2] drm/kms: Duct-tape for mode object lifetime checks URL : https://patchwork.freedesktop.org/series/66812/ State : success == Summary == CI Bug Log - changes from CI_DRM_6908_full -> Patchwork_14429_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14429_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb2/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb6/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-skl6/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-skl8/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103167]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-skl3/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-move.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb2/igt@kms_psr2...@frontbuffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb3/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-hsw: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-hsw5/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-hsw5/igt@kms_setm...@basic.html * igt@tools_test@tools_test: - shard-kbl: [PASS][23] -> [SKIP][24] ([fdo#109271]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/shard-kbl3/igt@tools_test@tools_test.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/shard-kbl6/igt@tools_test@tools_test.html Possible fixes * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb:
Re: [Intel-gfx] [PATCH 02/14] drm/i915/tgl: TC helper function to return pin mapping
On Fri, 2019-09-13 at 22:54 -0700, Lucas De Marchi wrote:
> On Fri, Sep 13, 2019 at 3:33 PM José Roberto de Souza
> wrote:
> > From: "Taylor, Clinton A"
> >
> > Add a helper function to return pin map for use during dkl phy
> > DP_MODE settings, PORT_TX_DFLEXPA1 exist on ICL but we don't need
> > it.
> >
> > The user of this function will come in future TC patches.
>
> It's actually harder to review if the function is out of the context
> of those patches. Will it really be needed outside of intel_tc.c ?
It is used in intel_ddi.c, the user is added in "drm/i915/tgl: Add dkl
phy programming sequences" I guess I can move this patch right before
that one.
>
> > Signed-off-by: Taylor, Clinton A
>
> you need your s-o-b too if you are sending this patch.
>
> > ---
> > drivers/gpu/drm/i915/display/intel_tc.c | 16
> > drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > 3 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 85743a43bee2..3a7302e360cc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -61,6 +61,22 @@ u32 intel_tc_port_get_lane_mask(struct
> > intel_digital_port *dig_port)
> >DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> > }
> >
> > +u32 intel_tc_port_get_pin_assignment_mask(struct
> > intel_digital_port *dig_port)
> > +{
> > + struct drm_i915_private *i915 = to_i915(dig_port-
> > >base.base.dev);
> > + enum tc_port tc_port = intel_port_to_tc(i915, dig_port-
> > >base.port);
> > + struct intel_uncore *uncore = >uncore;
> > + u32 pin_mask;
> > +
> > + pin_mask = intel_uncore_read(uncore,
> > +PORT_TX_DFLEXPA1(dig_port-
> > >tc_phy_fia));
> > +
> > + WARN_ON(pin_mask == 0x);
> > +
> > + return (pin_mask & DP_PIN_ASSIGNMENT_MASK(tc_port)) >>
> > + DP_PIN_ASSIGNMENT_SHIFT(tc_port);
> > +}
> > +
> > int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > *dig_port)
> > {
> > struct drm_i915_private *i915 = to_i915(dig_port-
> > >base.base.dev);
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> > b/drivers/gpu/drm/i915/display/intel_tc.h
> > index 783d75531435..463f1b3c836f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> > @@ -13,6 +13,7 @@ struct intel_digital_port;
> >
> > bool intel_tc_port_connected(struct intel_digital_port *dig_port);
> > u32 intel_tc_port_get_lane_mask(struct intel_digital_port
> > *dig_port);
> > +u32 intel_tc_port_get_pin_assignment_mask(struct
> > intel_digital_port *dig_port);
> > int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > *dig_port);
> > void intel_tc_port_set_fia_lane_count(struct intel_digital_port
> > *dig_port,
> > int required_lanes);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index bf37ecebc82f..16d5548adb84 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -11683,4 +11683,9 @@ enum skl_power_gate {
> > #define PORT_TX_DFLEXDPCSSS(fia) _MMIO_FIA((fia),
> > 0x00894)
> > #define DP_PHY_MODE_STATUS_NOT_SAFE(tc_port) (1 <<
> > (tc_port))
> >
> > +#define PORT_TX_DFLEXPA1(fia) _MMIO_FIA((fia),
> > 0x00880)
> > +#define DP_PIN_ASSIGNMENT_SHIFT(tc_port) ((tc_port)
> > * 4)
> > +#define DP_PIN_ASSIGNMENT_MASK(tc_port) (0xf <<
> > ((tc_port) * 4))
>
> Use DP_PIN_ASSIGNMENT_SHIFT() here
>
> > +#define DP_PIN_ASSIGNMENT(tc_port, x)((x) << ((tc_port)
> > * 4))
>
> ditto.
>
> Lucas De Marchi
>
> > +
> > #endif /* _I915_REG_H_ */
> > --
> > 2.23.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Enable guc logging on guc log relay write
On Mon, Sep 16, 2019 at 03:50:18PM -0700, Robert M. Fosha wrote:
Creating and opening the GuC log relay file enables and starts
the relay potentially before the caller is ready to consume logs.
Change the behavior so that relay starts only on an explicit call
to the write function (with a value of '1'). Other values flush
the log relay as before.
v2: Style changes and fix typos. Add guc_log_relay_stop()
function. (Daniele)
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Robert M. Fosha
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 53 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 4 +-
drivers/gpu/drm/i915/i915_debugfs.c| 22 +++--
3 files changed, 62 insertions(+), 17 deletions(-)
Reviewed-by: Matthew Brost
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 36332064de9c..e26c7748358b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -226,7 +226,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log
*log)
mutex_lock(>relay.lock);
- if (WARN_ON(!intel_guc_log_relay_enabled(log)))
+ if (WARN_ON(!intel_guc_log_relay_created(log)))
goto out_unlock;
/* Get the pointer to shared GuC log buffer */
@@ -361,6 +361,7 @@ void intel_guc_log_init_early(struct intel_guc_log *log)
{
mutex_init(>relay.lock);
INIT_WORK(>relay.flush_work, capture_logs_work);
+ log->relay.started = false;
}
static int guc_log_relay_create(struct intel_guc_log *log)
@@ -546,7 +547,7 @@ int intel_guc_log_set_level(struct intel_guc_log *log, u32
level)
return ret;
}
-bool intel_guc_log_relay_enabled(const struct intel_guc_log *log)
+bool intel_guc_log_relay_created(const struct intel_guc_log *log)
{
return log->relay.buf_addr;
}
@@ -560,7 +561,7 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_lock(>relay.lock);
- if (intel_guc_log_relay_enabled(log)) {
+ if (intel_guc_log_relay_created(log)) {
ret = -EEXIST;
goto out_unlock;
}
@@ -585,6 +586,21 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
mutex_unlock(>relay.lock);
+ return 0;
+
+out_relay:
+ guc_log_relay_destroy(log);
+out_unlock:
+ mutex_unlock(>relay.lock);
+
+ return ret;
+}
+
+int intel_guc_log_relay_start(struct intel_guc_log *log)
+{
+ if (log->relay.started)
+ return -EEXIST;
+
guc_log_enable_flush_events(log);
/*
@@ -594,14 +610,9 @@ int intel_guc_log_relay_open(struct intel_guc_log *log)
*/
queue_work(system_highpri_wq, >relay.flush_work);
- return 0;
-
-out_relay:
- guc_log_relay_destroy(log);
-out_unlock:
- mutex_unlock(>relay.lock);
+ log->relay.started = true;
- return ret;
+ return 0;
}
void intel_guc_log_relay_flush(struct intel_guc_log *log)
@@ -610,6 +621,9 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
intel_wakeref_t wakeref;
+ if (!log->relay.started)
+ return;
+
/*
* Before initiating the forceful flush, wait for any pending/ongoing
* flush to complete otherwise forceful flush may not actually happen.
@@ -623,18 +637,33 @@ void intel_guc_log_relay_flush(struct intel_guc_log *log)
guc_log_capture_logs(log);
}
-void intel_guc_log_relay_close(struct intel_guc_log *log)
+/*
+ * Stops the relay log. Called from intel_guc_log_relay_close(), so no
+ * possibility of race with start/flush since relay_write cannot race
+ * relay_close.
+ */
+static void guc_log_relay_stop(struct intel_guc_log *log)
{
struct intel_guc *guc = log_to_guc(log);
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+ if (!log->relay.started)
+ return;
+
guc_log_disable_flush_events(log);
intel_synchronize_irq(i915);
flush_work(>relay.flush_work);
+ log->relay.started = false;
+}
+
+void intel_guc_log_relay_close(struct intel_guc_log *log)
+{
+ guc_log_relay_stop(log);
+
mutex_lock(>relay.lock);
- GEM_BUG_ON(!intel_guc_log_relay_enabled(log));
+ GEM_BUG_ON(!intel_guc_log_relay_created(log));
guc_log_unmap(log);
guc_log_relay_destroy(log);
mutex_unlock(>relay.lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 6f764879acb1..c252c022c5fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -47,6 +47,7 @@ struct intel_guc_log {
struct i915_vma *vma;
struct {
void *buf_addr;
+ bool started;
struct work_struct flush_work;
struct rchan *channel;
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
On 9/17/2019 12:49 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 20:45:02)
On 9/17/2019 11:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
---
@@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
sfc_forced_lock_ack_bit,
sfc_forced_lock_ack_bit,
1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ /* did we race the unlock? */
+ if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
+ DRM_ERROR("Wait for SFC forced lock ack failed\n");
What's our plan if this *ERROR* is ever triggered?
If it remains do nothing and check the logs on death, then it remains
just a debug splat. If there is a plan to actually do something to
handle the error, do it!
-Chris
AFAIU the only thing we can do is escalate to full gpu reset. However,
the probability of this failing should be next to non-existent (only one
engine can use the SFC at any time so there is no lock contention), so
I'm not convinced the fallback is worth the effort. The error is still
useful IMO to catch unexpected behavior on new platforms, as it happened
in this case with the media team reporting seeing this message on gen12
with the previous behavior. This said, I'm happy to add the extra logic
if you believe it is worth it.
We've see this message on every icl run!
-Chris
I've never noticed it, which tests are hitting it? My understanding from
what the HW team said is that on ICL the ack will always come back (even
if it is not part of the "official" SW/HW interface) and the HW tweak
that stops that is a gen12 change. Something else might be wrong is this
is firing off in our ICL CI, also because I don't think we have any test
case that actually uses the SFC, do we?
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
All icl, live_hangcheck or live_reset, for as long as I can remember.
-Chris
Thanks. I'm going to check with the HW team to see what their
recommended timeout value is, in case ours is too short. It could also
be that even on ICL the ack is not always returned if the SFC is not
actually in use.
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/gem_mmap_gtt: Run forked mmap tests on tgl
== Series Details == Series: i915/gem_mmap_gtt: Run forked mmap tests on tgl URL : https://patchwork.freedesktop.org/series/66809/ State : failure == Summary == CI Bug Log - changes from IGT_5189_full -> IGTPW_3470_full Summary --- **FAILURE** Serious unknown changes coming with IGTPW_3470_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_3470_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/66809/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in IGTPW_3470_full: ### IGT changes ### Possible regressions * igt@kms_color@pipe-b-ctm-max: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-apl2/igt@kms_co...@pipe-b-ctm-max.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-apl8/igt@kms_co...@pipe-b-ctm-max.html - shard-kbl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-kbl6/igt@kms_co...@pipe-b-ctm-max.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-kbl4/igt@kms_co...@pipe-b-ctm-max.html Warnings * igt@gem_mmap_gtt@forked-medium-copy: - shard-iclb: [FAIL][5] ([fdo#110882]) -> [FAIL][6] +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-iclb5/igt@gem_mmap_...@forked-medium-copy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-iclb3/igt@gem_mmap_...@forked-medium-copy.html Known issues Here are the changes found in IGTPW_3470_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@independent-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +19 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-iclb4/igt@gem_exec_sched...@independent-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-iclb7/igt@gem_exec_sched...@independent-bsd1.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-hsw5/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-hsw4/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-iclb5/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/shard-apl5/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/shard-apl5/igt@kms_setm...@basic.html Possible fixes * igt@gem_bad_reloc@negative-reloc-bsd2: -
Re: [Intel-gfx] [PATCH] drm/i915: Extend Haswell GT1 PSMI workaround to all
Quoting Chris Wilson (2019-09-17 21:23:01) > Quoting Chris Wilson (2019-09-17 20:47:46) > > A few times in CI, we have detected a GPU hang on our Haswell GT2 > > systems with the characteristic IPEHR of 0x780c. When the PSMI w/a > > was first introducted, it was applied to all Haswell, but later on we > > found an erratum that supposedly restricted the issue to GT1 and so > > constrained it only be applied on GT1. That may have been a mistake... > > Something else to bear in mind about why this is showing up now, is that > the enabling of iommu on these machines. It's the last instruction in > the context image... Could we need to expand the context? Fwiw, we say the maximum size for the haswell context is 70270, which even expanding for prefetch is well inside the next page boundary of 73728. Furthermore, no DMAR faults. The coincidence may be a timing artifact of the iommu indirection? Or just a mere coincidence. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend Haswell GT1 PSMI workaround to all
== Series Details ==
Series: drm/i915: Extend Haswell GT1 PSMI workaround to all
URL : https://patchwork.freedesktop.org/series/66826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6911 -> Patchwork_14435
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14435:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_render_tiled_blits@basic:
- {fi-tgl-u}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-tgl-u/igt@gem_render_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-tgl-u/igt@gem_render_tiled_bl...@basic.html
Known issues
Here are the changes found in Patchwork_14435 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-all:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@gem_b...@busy-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-icl-u3/igt@gem_b...@busy-all.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][7] -> [DMESG-FAIL][8] ([fdo#08])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Possible fixes
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#111407]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (54 -> 48)
--
Additional (1): fi-icl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6911 -> Patchwork_14435
CI-20190529: 20190529
CI_DRM_6911: 2e04def5afc3b2bd724dc6f3f6525c5ebf1f87d2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14435: 09bed8c03851e84a7c29f5b21e147f7848090617 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
09bed8c03851 drm/i915: Extend Haswell GT1 PSMI workaround to all
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14435/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Extend Haswell GT1 PSMI workaround to all
Quoting Chris Wilson (2019-09-17 20:47:46) > A few times in CI, we have detected a GPU hang on our Haswell GT2 > systems with the characteristic IPEHR of 0x780c. When the PSMI w/a > was first introducted, it was applied to all Haswell, but later on we > found an erratum that supposedly restricted the issue to GT1 and so > constrained it only be applied on GT1. That may have been a mistake... Something else to bear in mind about why this is showing up now, is that the enabling of iommu on these machines. It's the last instruction in the context image... Could we need to expand the context? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Extend Haswell GT1 PSMI workaround to all
== Series Details ==
Series: drm/i915: Extend Haswell GT1 PSMI workaround to all
URL : https://patchwork.freedesktop.org/series/66826/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
09bed8c03851 drm/i915: Extend Haswell GT1 PSMI workaround to all
-:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#14:
References: 2c550183476d ("drm/i915: Disable PSMI sleep messages on all rings
around context switches")
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 2c550183476d ("drm/i915: Disable
PSMI sleep messages on all rings around context switches")'
#14:
References: 2c550183476d ("drm/i915: Disable PSMI sleep messages on all rings
around context switches")
total: 1 errors, 1 warnings, 0 checks, 8 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
On Mon, Sep 16, 2019 at 09:50:00PM -0700, Saarinen, Jani wrote:
> HI,
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Matt
> > Roper
> > Sent: tiistai 17. syyskuuta 2019 3.35
> > To: Lucas De Marchi
> > Cc: Intel Graphics
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/cml: Add second PCH ID for CMP
> >
> > On Mon, Sep 16, 2019 at 05:26:10PM -0700, Lucas De Marchi wrote:
> > > On Mon, Sep 16, 2019 at 4:33 PM Matt Roper
> > wrote:
> > > >
> > > > The CMP PCH ID we have in the driver is correct for the CML-U
> > > > machines we have in our CI system, but the CML-S and CML-H CI
> > > > machines appear to use a
> > >
> > > CML-S is back to life, but CML-H is still failing. Is CML-H actually
> > > using the same PCH?
> > >
> >
> > According to the CI's lspci output for each machine, CML-S has 0x0681 and
> > CML-H
> > has 0x068C. We only care about the upper 9 bits, so a DEVICE_ID_TYPE of
> > 0x0680
> > should handle both of them.
> >
> > It looks like CML-H wasn't even attempted by CI (no failure for igt@runner
> > like we
> > had before, just no results at all for anything).
> > The CI BAT email say it wasn't a participating host (along with a handful
> > of others),
> > but I'm not sure what leads to that --- does it just mean the platform has
> > been
> > temporarily taken offline?
> No, it probably just did not boot properly or something else, Tomi?
> It did something:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14423/fi-cml-h/ ...
I re-sent this through trybot to see if I could get a valid result for
cml-h, but now cml-h appears to have completely disappeared from the
machine list:
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5035/index.html
and wasn't even listed as missing in the "participating hosts" part of
the report. It's also missing from the general results page at:
https://intel-gfx-ci.01.org/tree/drm-tip/index.html
Anyway, based on the cml-s results it appears this patch does do what we
hoped and fixes the PCH detection. Lucas, do you feel comfortable
giving it a r-b so we can apply it or do you want to wait until the
cml-h CI machine comes back?
Matt
>
> >
> >
> > Matt
> >
> > > Lucas De Marchi
> > >
> > > > different PCH ID, leading our driver to detect no PCH for them.
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Anusha Srivatsa
> > > > References: 729ae330a0f2e2 ("drm/i915/cml: Introduce Comet Lake
> > > > PCH")
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111461
> > > > Signed-off-by: Matt Roper
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pch.c | 1 +
> > > > drivers/gpu/drm/i915/intel_pch.h | 1 +
> > > > 2 files changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > > > b/drivers/gpu/drm/i915/intel_pch.c
> > > > index fa864d8f2b73..15f8bff141f9 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pch.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > > > @@ -69,6 +69,7 @@ intel_pch_type(const struct drm_i915_private
> > > > *dev_priv,
> > unsigned short id)
> > > > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > > > !IS_COFFEELAKE(dev_priv));
> > > > return PCH_CNP;
> > > > case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > > > + case INTEL_PCH_CMP2_DEVICE_ID_TYPE:
> > > > DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> > > > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > > > /* CometPoint is CNP Compatible */ diff --git
> > > > a/drivers/gpu/drm/i915/intel_pch.h
> > > > b/drivers/gpu/drm/i915/intel_pch.h
> > > > index e6a2d65f19c6..c29c81ec7971 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pch.h
> > > > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > > > @@ -41,6 +41,7 @@ enum intel_pch {
> > > > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > > > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > > > #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > > > +#define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
> > > > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > > > #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> > > > #define INTEL_PCH_MCC2_DEVICE_ID_TYPE 0x3880
> > > > --
> > > > 2.21.0
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > >
> > >
> > > --
> > > Lucas De Marchi
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
Quoting Daniele Ceraolo Spurio (2019-09-17 20:45:02)
>
>
> On 9/17/2019 11:57 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
> >>
> >> On 9/17/2019 12:57 AM, Chris Wilson wrote:
> >>> Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that the behavior is undefined; on ICL the HW
> ends up to returning the ack and ignoring our lock request, but this is
> not guaranteed and we shouldn't expect it going forward.
>
> Reported-by: Owen Zhang
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> ---
> @@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs
> *engine)
> sfc_forced_lock_ack_bit,
> sfc_forced_lock_ack_bit,
> 1000, 0, NULL)) {
> - DRM_DEBUG_DRIVER("Wait for SFC forced lock ack
> failed\n");
> + /* did we race the unlock? */
> + if (intel_uncore_read_fw(uncore, sfc_usage) &
> sfc_usage_bit)
> + DRM_ERROR("Wait for SFC forced lock ack
> failed\n");
> >>> What's our plan if this *ERROR* is ever triggered?
> >>>
> >>> If it remains do nothing and check the logs on death, then it remains
> >>> just a debug splat. If there is a plan to actually do something to
> >>> handle the error, do it!
> >>> -Chris
> >> AFAIU the only thing we can do is escalate to full gpu reset. However,
> >> the probability of this failing should be next to non-existent (only one
> >> engine can use the SFC at any time so there is no lock contention), so
> >> I'm not convinced the fallback is worth the effort. The error is still
> >> useful IMO to catch unexpected behavior on new platforms, as it happened
> >> in this case with the media team reporting seeing this message on gen12
> >> with the previous behavior. This said, I'm happy to add the extra logic
> >> if you believe it is worth it.
> > We've see this message on every icl run!
> > -Chris
>
> I've never noticed it, which tests are hitting it? My understanding from
> what the HW team said is that on ICL the ack will always come back (even
> if it is not part of the "official" SW/HW interface) and the HW tweak
> that stops that is a gen12 change. Something else might be wrong is this
> is firing off in our ICL CI, also because I don't think we have any test
> case that actually uses the SFC, do we?
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6911/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
All icl, live_hangcheck or live_reset, for as long as I can remember.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Extend Haswell GT1 PSMI workaround to all
A few times in CI, we have detected a GPU hang on our Haswell GT2
systems with the characteristic IPEHR of 0x780c. When the PSMI w/a
was first introducted, it was applied to all Haswell, but later on we
found an erratum that supposedly restricted the issue to GT1 and so
constrained it only be applied on GT1. That may have been a mistake...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111692
Fixes: 167bc759e823 ("drm/i915: Restrict PSMI context load w/a to Haswell GT1")
References: 2c550183476d ("drm/i915: Disable PSMI sleep messages on all rings
around context switches")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index a73296e6b13d..a25b84b12ef1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1574,7 +1574,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
struct intel_engine_cs *engine = rq->engine;
enum intel_engine_id id;
const int num_engines =
- IS_HSW_GT1(i915) ? RUNTIME_INFO(i915)->num_engines - 1 : 0;
+ IS_HASWELL(i915) ? RUNTIME_INFO(i915)->num_engines - 1 : 0;
bool force_restore = false;
int len;
u32 *cs;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/doc: Improve docs around connector (un)registration
Reviewed-by: Lyude Paul
On Tue, 2019-09-17 at 14:09 +0200, Daniel Vetter wrote:
> Current code is quite a mess unfortunately, so also add a todo.rst
> entry to maybe fix it up eventually.
>
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 12
> drivers/gpu/drm/drm_connector.c | 10 --
> drivers/gpu/drm/drm_dp_helper.c | 8
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 32787acff0a8..8dc147c93c9c 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -284,6 +284,18 @@ drm_fb_helper tasks
>removed: drm_fb_helper_single_add_all_connectors(),
>drm_fb_helper_add_one_connector() and
> drm_fb_helper_remove_one_connector().
>
> +connector register/unregister fixes
> +---
> +
> +- For most connectors it's a no-op to call
> drm_connector_register/unregister
> + directly from driver code, drm_dev_register/unregister take care of this
> + already. We can remove all of them.
> +
> +- For dp drivers it's a bit more a mess, since we need the connector to be
> + registered when calling drm_dp_aux_register. Fix this by instead calling
> + drm_dp_aux_init, and moving the actual registering into a late_register
> + callback as recommended in the kerneldoc.
> +
> Core refactorings
> =
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..cd5048ceab1d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -480,7 +480,10 @@ EXPORT_SYMBOL(drm_connector_cleanup);
> * drm_connector_register - register a connector
> * @connector: the connector to register
> *
> - * Register userspace interfaces for a connector
> + * Register userspace interfaces for a connector. Only call this for
> connectors
> + * which can be hotplugged after drm_dev_register() has been called
> already,
> + * e.g. DP MST connectors. All other connectors will be registered
> automatically
> + * when calling drm_dev_register().
> *
> * Returns:
> * Zero on success, error code on failure.
> @@ -526,7 +529,10 @@ EXPORT_SYMBOL(drm_connector_register);
> * drm_connector_unregister - unregister a connector
> * @connector: the connector to unregister
> *
> - * Unregister userspace interfaces for a connector
> + * Unregister userspace interfaces for a connector. Only call this for
> + * connectors which have registered explicitly by calling
> drm_dev_register(),
> + * since connectors are unregistered automatically when
> drm_dev_unregister() is
> + * called.
> */
> void drm_connector_unregister(struct drm_connector *connector)
> {
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..f373798d82f6 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1109,6 +1109,14 @@ EXPORT_SYMBOL(drm_dp_aux_init);
> * @aux: DisplayPort AUX channel
> *
> * Automatically calls drm_dp_aux_init() if this hasn't been done yet.
> + * This should only be called when the underlying drm_connector is
> + * initialiazed already. Therefore the best place to call this is from
> + * _connector_funcs.late_register. Not that drivers which don't follow
> this
> + * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled.
> + *
> + * Drivers which need to use the aux channel before that point (e.g. at
> driver
> + * load time, before drm_dev_register() has been called) need to call
> + * drm_dp_aux_init().
> *
> * Returns 0 on success or a negative error code on failure.
> */
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Add TigerLake bandwidth checking
On Tue, Sep 17, 2019 at 04:00:57PM +0300, Stanislav Lisovskiy wrote:
> Added bandwidth calculation algorithm and checks,
> similar way as it was done for ICL, some constants
> were corrected according to BSpec.
Heh - I'd been working in this same area, and had some code written up,
but your patch made it to the list first. :)
>
> Signed-off-by: Stanislav Lisovskiy
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111600
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 108 +++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 688858ebe4d0..e97d083f4f2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -132,7 +132,8 @@ static int icl_sagv_max_dclk(const struct intel_qgv_info
> *qi)
> }
>
> struct intel_sa_info {
> - u8 deburst, mpagesize, deprogbwlimit, displayrtids;
> + u8 deburst, mpagesize, deprogbwlimit;
> + u16 displayrtids;
> };
>
> static const struct intel_sa_info icl_sa_info = {
> @@ -142,6 +143,14 @@ static const struct intel_sa_info icl_sa_info = {
> .displayrtids = 128,
> };
>
> +static const struct intel_sa_info tgl_sa_info = {
> + .deburst = 16,
> + .mpagesize = 16,
This should be 16 only for DDR4, and 32 otherwise - however, it's not
actually used anywhere, so it doesn't matter, but a comment (in case it
needs to be used in the future) would be good.
> + .deprogbwlimit = 34, /* GB/s */
> + .displayrtids = 256,
> +};
> +
> +
> static int icl_get_bw_info(struct drm_i915_private *dev_priv)
> {
> struct intel_qgv_info qi = {};
> @@ -208,6 +217,74 @@ static int icl_get_bw_info(struct drm_i915_private
> *dev_priv)
> return 0;
> }
>
> +static int tgl_get_bw_info(struct drm_i915_private *dev_priv)
> +{
> + struct intel_qgv_info qi = {};
> + const struct intel_sa_info *sa = _sa_info;
> + bool is_y_tile = true; /* assume y tile may be used */
> + int num_channels;
> + int deinterleave;
> + int ipqdepth, ipqdepthpch;
> + int dclk_max;
> + int maxdebw;
> + int c3_derating = 10;
> + int c25_deprogbwpclimit = 60;
> + int i, ret;
> +
> + ret = icl_get_qgv_points(dev_priv, );
> + if (ret) {
> + DRM_DEBUG_KMS("Failed to get memory subsystem information,
> ignoring bandwidth limits");
> + return ret;
> + }
> + num_channels = qi.num_channels;
> +
> + deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
> + dclk_max = icl_sagv_max_dclk();
> +
> + ipqdepthpch = 16;
> +
> + maxdebw = min(sa->deprogbwlimit * 1000,
> + icl_calc_bw(dclk_max, 16 * c25_deprogbwpclimit, 100)); /*
> 60% */
> + ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
> +
> + for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
> + struct intel_bw_info *bi = _priv->max_bw[i];
> + int clpchgroup;
> + int j;
> +
> + clpchgroup = (sa->deburst * deinterleave / num_channels) << i;
> + bi->num_planes = (ipqdepth - clpchgroup) / clpchgroup;
> +
> + bi->num_qgv_points = qi.num_points;
> +
> + for (j = 0; j < qi.num_points; j++) {
> + const struct intel_qgv_point *sp = [j];
> + int ct, bw;
> +
> + /*
> + * Max row cycle time
> + *
> + * FIXME what is the logic behind the
> + * assumed burst length?
> + */
> + ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd +
> +(clpchgroup - 1) * qi.t_bl + sp->t_rdpre);
qi.t_bl also needs to be set dynamically based on memory type - for
DDR4, 4, otherwise 16
-James
> + bw = icl_calc_bw(sp->dclk, clpchgroup * 32 *
> num_channels, ct);
> +
> + bi->deratedbw[j] = min(maxdebw,
> +bw * (100 - c3_derating) / 100);
> /* 90% */
> +
> + DRM_DEBUG_KMS("BW%d / QGV %d: num_planes=%d
> deratedbw=%u\n",
> + i, j, bi->num_planes, bi->deratedbw[j]);
> + }
> +
> + if (bi->num_planes == 1)
> + break;
> + }
> +
> + return 0;
> +}
> +
> static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
> int num_planes, int qgv_point)
> {
> @@ -231,10 +308,35 @@ static unsigned int icl_max_bw(struct drm_i915_private
> *dev_priv,
> return 0;
> }
>
> +static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
> +int num_planes, int qgv_point)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
> + const struct intel_bw_info
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
On 9/17/2019 11:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
---
@@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
sfc_forced_lock_ack_bit,
sfc_forced_lock_ack_bit,
1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ /* did we race the unlock? */
+ if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
+ DRM_ERROR("Wait for SFC forced lock ack failed\n");
What's our plan if this *ERROR* is ever triggered?
If it remains do nothing and check the logs on death, then it remains
just a debug splat. If there is a plan to actually do something to
handle the error, do it!
-Chris
AFAIU the only thing we can do is escalate to full gpu reset. However,
the probability of this failing should be next to non-existent (only one
engine can use the SFC at any time so there is no lock contention), so
I'm not convinced the fallback is worth the effort. The error is still
useful IMO to catch unexpected behavior on new platforms, as it happened
in this case with the media team reporting seeing this message on gen12
with the previous behavior. This said, I'm happy to add the extra logic
if you believe it is worth it.
We've see this message on every icl run!
-Chris
I've never noticed it, which tests are hitting it? My understanding from
what the HW team said is that on ICL the ack will always come back (even
if it is not part of the "official" SW/HW interface) and the HW tweak
that stops that is a gen12 change. Something else might be wrong is this
is firing off in our ICL CI, also because I don't think we have any test
case that actually uses the SFC, do we?
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
Quoting Daniele Ceraolo Spurio (2019-09-17 19:36:35)
>
>
> On 9/17/2019 12:57 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> >> Our assumption that the we can ask the HW to lock the SFC even if not
> >> currently in use does not match the HW commitment. The expectation from
> >> the HW is that SW will not try to lock the SFC if the engine is not
> >> using it and if we do that the behavior is undefined; on ICL the HW
> >> ends up to returning the ack and ignoring our lock request, but this is
> >> not guaranteed and we shouldn't expect it going forward.
> >>
> >> Reported-by: Owen Zhang
> >> Signed-off-by: Daniele Ceraolo Spurio
> >> Cc: Tvrtko Ursulin
> >> ---
> >> @@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs
> >> *engine)
> >> sfc_forced_lock_ack_bit,
> >> sfc_forced_lock_ack_bit,
> >> 1000, 0, NULL)) {
> >> - DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
> >> + /* did we race the unlock? */
> >> + if (intel_uncore_read_fw(uncore, sfc_usage) &
> >> sfc_usage_bit)
> >> + DRM_ERROR("Wait for SFC forced lock ack failed\n");
> > What's our plan if this *ERROR* is ever triggered?
> >
> > If it remains do nothing and check the logs on death, then it remains
> > just a debug splat. If there is a plan to actually do something to
> > handle the error, do it!
> > -Chris
>
> AFAIU the only thing we can do is escalate to full gpu reset. However,
> the probability of this failing should be next to non-existent (only one
> engine can use the SFC at any time so there is no lock contention), so
> I'm not convinced the fallback is worth the effort. The error is still
> useful IMO to catch unexpected behavior on new platforms, as it happened
> in this case with the media team reporting seeing this message on gen12
> with the previous behavior. This said, I'm happy to add the extra logic
> if you believe it is worth it.
We've see this message on every icl run!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/21] drm/i915: Pull i915_vma_pin under the vm->mutex
Quoting Tvrtko Ursulin (2019-09-17 13:37:55)
> On 02/09/2019 05:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index 82db2b783123..9a8c307c5aeb 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -251,16 +251,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> > goto err_rpm;
> > }
> >
> > - ret = i915_mutex_lock_interruptible(dev);
> > - if (ret)
> > - goto err_reset;
> > -
> > - /* Access to snoopable pages through the GTT is incoherent. */
> > - if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(i915)) {
> > - ret = -EFAULT;
> > - goto err_unlock;
> > - }
> > -
> > /* Now pin it into the GTT as needed */
> > vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
> > PIN_MAPPABLE |
> > @@ -293,7 +283,13 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> > }
> > if (IS_ERR(vma)) {
> > ret = PTR_ERR(vma);
> > - goto err_unlock;
> > + goto err_reset;
> > + }
> > +
> > + /* Access to snoopable pages through the GTT is incoherent. */
> > + if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(i915)) {
> > + ret = -EFAULT;
> > + goto err_unpin;
> > }
>
> Why have you moved this check to after pinning?
Since we've dropped the lock around this check, the intent is to use the
pin as a guarantee that the vma cannot be changed. What we actually want
here, for clarity, is vma->cache_level.
> >
> > ret = i915_vma_pin_fence(vma);
> > @@ -321,14 +317,12 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
> > intel_wakeref_auto(>ggtt.userfault_wakeref,
> >
> > msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
> >
> > - i915_vma_set_ggtt_write(vma);
> > -
> > + if (write)
> > + i915_vma_set_ggtt_write(vma);
>
> Noise for what this patch is concerned?
Yeah, I had to stare at an incorrect __set_bit(GGTT_WRITE) for too long.
>
> > err_fence:
> > i915_vma_unpin_fence(vma);
> > err_unpin:
> > __i915_vma_unpin(vma);
> > -err_unlock:
> > - mutex_unlock(>struct_mutex);
> > err_reset:
> > intel_gt_reset_unlock(ggtt->vm.gt, srcu);
> > err_rpm:
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 0ef60dae23a7..dbf9be9a79f4 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -155,21 +155,30 @@ static void __i915_gem_free_objects(struct
> > drm_i915_private *i915,
> >
> > wakeref = intel_runtime_pm_get(>runtime_pm);
> > llist_for_each_entry_safe(obj, on, freed, freed) {
> > - struct i915_vma *vma, *vn;
> > -
> > trace_i915_gem_object_destroy(obj);
> >
> > - mutex_lock(>drm.struct_mutex);
> > -
> > - list_for_each_entry_safe(vma, vn, >vma.list, obj_link) {
> > - GEM_BUG_ON(i915_vma_is_active(vma));
> > - atomic_and(~I915_VMA_PIN_MASK, >flags);
> > - i915_vma_destroy(vma);
> > + if (!list_empty(>vma.list)) {
> > + struct i915_vma *vma;
> > +
> > + /*
> > + * Note that the vma keeps an object reference while
> > + * it is active, so it *should* not sleep while we
> > + * destroy it. Our debug code errs insits it *might*.
> > + * For the moment, play along.
> > + */
> > + spin_lock(>vma.lock);
> > + while ((vma = list_first_entry_or_null(>vma.list,
> > +struct
> > i915_vma,
> > +obj_link)))
>
> What is the point of having a while loop inside top-level if !list_empty
> check? Looks theoretically racy, and even if that is irrelevant, it
> would be clearer to just do the while loop.
We can't add more vma to the object, as there are no more refs to the
object. The challenge is in dropping the links. In the end it makes no
difference, it's an unlocked compare before the spinlock (and ugly
loop).
> > GEM_BUG_ON(!drm_mm_node_allocated(>node));
> >
> > + GEM_BUG_ON(vma->pages);
> > vma->pages = obj->mm.pages;
> > + atomic_set(>pages_count, I915_VMA_PAGES_ACTIVE);
>
> What is I915_VMA_PAGES_ACTIVE used for? Pinned? Has pages?
It's a counter for the number of unique binds as opposed to callers
merely acquiring the pages prior to binding; so that we can balance
vma_unbind_pages() which is called once (i915_vma_unbind) but
i915_vma_bind() can be called for
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
On 9/17/2019 12:57 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
---
@@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
sfc_forced_lock_ack_bit,
sfc_forced_lock_ack_bit,
1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ /* did we race the unlock? */
+ if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
+ DRM_ERROR("Wait for SFC forced lock ack failed\n");
What's our plan if this *ERROR* is ever triggered?
If it remains do nothing and check the logs on death, then it remains
just a debug splat. If there is a plan to actually do something to
handle the error, do it!
-Chris
AFAIU the only thing we can do is escalate to full gpu reset. However,
the probability of this failing should be next to non-existent (only one
engine can use the SFC at any time so there is no lock contention), so
I'm not convinced the fallback is worth the effort. The error is still
useful IMO to catch unexpected behavior on new platforms, as it happened
in this case with the media team reporting seeing this message on gen12
with the previous behavior. This said, I'm happy to add the extra logic
if you believe it is worth it.
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
On 9/17/2019 3:22 AM, Tvrtko Ursulin wrote:
On 16/09/2019 22:41, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 8327220ac558..900958804bd5 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -352,13 +352,15 @@ static u32 gen11_lock_sfc(struct
intel_engine_cs *engine)
}
/*
- * Tell the engine that a software reset is going to happen. The
engine
- * will then try to force lock the SFC (if currently locked, it
will
- * remain so until we tell the engine it is safe to unlock; if
currently
- * unlocked, it will ignore this and all new lock requests). If SFC
- * ends up being locked to the engine we want to reset, we have
to reset
- * it as well (we will unlock it once the reset sequence is
completed).
+ * If the engine is using a SFC, tell the engine that a software
reset
+ * is going to happen. The engine will then try to force lock
the SFC.
+ * If SFC ends up being locked to the engine we want to reset,
we have
+ * to reset it as well (we will unlock it once the reset
sequence is
+ * completed).
*/
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
+ return 0;
+
rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
if (__intel_wait_for_register_fw(uncore,
@@ -366,10 +368,13 @@ static u32 gen11_lock_sfc(struct
intel_engine_cs *engine)
sfc_forced_lock_ack_bit,
sfc_forced_lock_ack_bit,
1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ /* did we race the unlock? */
How do we race here? Are we not in complete control of the engine at
this point so the status of this engine using SFC or not should be
static, no?
The hang detection might be due to a long non-preemptable batch, in
which case there is in theory a chance for the batch to release the SFC
while we try to lock it. The chance is incredibly small though, so am I
being too paranoid?
+ if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
+ DRM_ERROR("Wait for SFC forced lock ack failed\n");
return 0;
}
+ /* The HW could return the ack even if the sfc is not in use */
But the function checked whether SFC wasn't in use and bailed out
early - so is this comment relevant? (I understand it is true against
the specs just wondering about our exact code.)
Same rationale as the above, if the engine relased the SFC while we were
locking it, the locking might have been rejected, but on ICL we still
get the ack.
if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
return sfc_reset_bit;
@@ -382,6 +387,7 @@ static void gen11_unlock_sfc(struct
intel_engine_cs *engine)
u8 vdbox_sfc_access =
RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
i915_reg_t sfc_forced_lock;
u32 sfc_forced_lock_bit;
+ u32 lock;
switch (engine->class) {
case VIDEO_DECODE_CLASS:
@@ -401,7 +407,10 @@ static void gen11_unlock_sfc(struct
intel_engine_cs *engine)
return;
}
- rmw_clear_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
+ lock = intel_uncore_read_fw(uncore, sfc_forced_lock);
+ if (lock & sfc_forced_lock_bit)
+ intel_uncore_write_fw(uncore, sfc_forced_lock,
+ lock & ~sfc_forced_lock_bit);
Here we can't rely on the return code from gen11_lock_sfc and have to
read the register ourselves? I guess it depends on my question about
the race comment.
In addition to this I now see that gen11_reset_engines does not use
the return value from gen11_lock_sfc when deciding which engines it
needs to unlock. Should we change that as well?
Paranoia here as well, in case something went wrong with the locking I'd
like to be sure the unlocking can still be performed independently so we
can recover. e.g. the locking might have succeeded after we hit the
timeout in gen11_lock_sfc , in which case the return from that function
won't reflect the status of the HW.
Thanks,
Daniele
}
static int gen11_reset_engines(struct intel_gt *gt,
Regards,
Tvrtko
___
Intel-gfx mailing list
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Lock signaler timeline while navigating (rev3)
== Series Details ==
Series: drm/i915: Lock signaler timeline while navigating (rev3)
URL : https://patchwork.freedesktop.org/series/66799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6910 -> Patchwork_14434
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/
Known issues
Here are the changes found in Patchwork_14434 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@gem_exec_fence@nb-await-default:
- {fi-tgl-u2}:[FAIL][5] ([fdo#111562] / [fdo#111597]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-tgl-u2/igt@gem_exec_fe...@nb-await-default.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-tgl-u2/igt@gem_exec_fe...@nb-await-default.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [DMESG-WARN][7] ([fdo#103558]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_busy@basic-wait-before-default:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][11] ([fdo#106387]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (52 -> 46)
--
Additional (1): fi-kbl-soraka
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-kbl-7500u fi-icl-y
fi-icl-dsi fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6910 -> Patchwork_14434
CI-20190529: 20190529
CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14434: 6677a773f1ea976bf4582de153d06eb271495327 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6677a773f1ea drm/i915: Lock signaler timeline while navigating
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14434/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/perf: Add support for report sizes that are not power of 2
On Mon, Sep 16, 2019 at 09:11:58PM -0700, Ashutosh Dixit wrote: On Mon, 16 Sep 2019 12:17:54 -0700, Umesh Nerlige Ramappa wrote: On Sun, Sep 15, 2019 at 02:24:41PM +0300, Lionel Landwerlin wrote: > On 14/09/2019 02:06, Umesh Nerlige Ramappa wrote: >> OA perf unit supports non-power of 2 report sizes. Enable support for >> these sizes in the driver. >> >> Signed-off-by: Umesh Nerlige Ramappa >> --- >> drivers/gpu/drm/i915/i915_perf.c | 59 >> 1 file changed, 21 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c >> index 50b6d154fd46..482fca3da7de 100644 >> --- a/drivers/gpu/drm/i915/i915_perf.c >> +++ b/drivers/gpu/drm/i915/i915_perf.c >> @@ -450,7 +450,7 @@ static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream) >>u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma); >>int report_size = stream->oa_buffer.format_size; >>unsigned long flags; >> - u32 hw_tail; >> + u32 hw_tail, aging_tail; >>u64 now; >>/* We have to consider the (unlikely) possibility that read() errors >> @@ -459,16 +459,17 @@ static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream) >> */ >>spin_lock_irqsave(>oa_buffer.ptr_lock, flags); >> - hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream); >> + hw_tail = dev_priv->perf.ops.oa_hw_tail_read(stream) - gtt_offset; >> + aging_tail = stream->oa_buffer.aging_tail - gtt_offset; >>/* The tail pointer increases in 64 byte increments, >> * not in report_size steps... >> */ >> - hw_tail &= ~(report_size - 1); >> + hw_tail = OA_TAKEN(hw_tail, (OA_TAKEN(hw_tail, aging_tail) % report_size)); > > > I'm struggling to parse this line above and I'm not 100% sure it's correct. > > Could add a comment to explain what is going on? The aging tail is always pointing to the boundary of a report whereas the hw_tail is advancing in 64 byte increments. The innermost OA_TAKEN is returning the number of bytes between the hw_tail and the aging_tail. The modulo is getting the size of the partial report (if any). The outermost OA_TAKEN is subtracting the size of partial report from the hw_tail to get a hw_tail that points to the boundary of the last full report. The value of hw_tail would be the same as from the deleted line of code above this line. Looks like aging_tail should not be needed (it is complicating the expression and is not there in the original expression). All we need is a "circular modulus". For example would the following work? original expression assumes all report sizes are powers of 2 and hence does not need a reference (like aging_tail) to rounddown the hw_tail. if (hw_tail < report_size) hw_tail += OA_BUFFER_SIZE; Assuming that this condition is detecting a report split across the OA buffer boundary, the above check will not catch the split in cases where there are multiple reports generated before we read the hw_tail. hw_tail = rounddown(hw_tail, report_size); Another way (if we want to avoid the division) would be to maintain a cached copy of hw_tail in SW which is successively (and circularly) incremented by report_size till it catches up with hw_tail read from HW. But probably the first method above is simpler. aging_tail is a cached copy of the hw_tail that advances only in report size increments. Thanks, Umesh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/2] Mdev: support mutiple kinds of devices
[cc +Parav] On Thu, 12 Sep 2019 17:40:10 +0800 Jason Wang wrote: > Hi all: > > During the development of virtio-mdev[1]. I find that mdev needs to be > extended to support devices other than vfio mdev device. So this > series tries to extend the mdev to be able to differ from different > devices by: > > - device id and matching for mdev bus > - device speicfic callbacks and move vfio callbacks there > > Sent for early reivew, compile test only! > > Thanks > > [1] https://lkml.org/lkml/2019/9/10/135 I expect Parav must have something similar in the works for their in-kernel networking mdev support. Link to discussion so far: https://lore.kernel.org/kvm/20190912094012.29653-1-jasow...@redhat.com/T/#t Thanks, Alex > Jason Wang (2): > mdev: device id support > mdev: introduce device specific ops > > drivers/gpu/drm/i915/gvt/kvmgt.c | 16 --- > drivers/s390/cio/vfio_ccw_ops.c | 16 --- > drivers/s390/crypto/vfio_ap_ops.c | 13 -- > drivers/vfio/mdev/mdev_core.c | 14 +- > drivers/vfio/mdev/mdev_driver.c | 14 ++ > drivers/vfio/mdev/mdev_private.h | 1 + > drivers/vfio/mdev/vfio_mdev.c | 36 ++- > include/linux/mdev.h | 76 +++ > include/linux/mod_devicetable.h | 6 +++ > samples/vfio-mdev/mbochs.c| 18 +--- > samples/vfio-mdev/mdpy.c | 18 +--- > samples/vfio-mdev/mtty.c | 16 --- > 12 files changed, 163 insertions(+), 81 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add TigerLake bandwidth checking
== Series Details ==
Series: drm/i915: Add TigerLake bandwidth checking
URL : https://patchwork.freedesktop.org/series/66817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6910 -> Patchwork_14433
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14433:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_render_tiled_blits@basic:
- {fi-tgl-u}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-tgl-u/igt@gem_render_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-tgl-u/igt@gem_render_tiled_bl...@basic.html
Known issues
Here are the changes found in Patchwork_14433 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-cml-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#110566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
* igt@prime_vgem@basic-fence-flip:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [WARN][7] ([fdo#109483]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [DMESG-WARN][9] ([fdo#103558]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_busy@basic-wait-before-default:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [DMESG-WARN][13] ([fdo#106387]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111096]) -> [FAIL][16] ([fdo#111407])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6910/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14433/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (52 -> 48)
--
Additional (1): fi-kbl-soraka
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-y fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6910 -> Patchwork_14433
CI-20190529: 20190529
CI_DRM_6910: 4bed63ef83f108048a4fe3e3ac651ef0a32540ef @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14433: b3e5a03f489ce9e2ef31dc1afbe533955fd90caa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
On Tue, Sep 17, 2019 at 04:52:54PM +0200, Maarten Lankhorst wrote:
> Op 09-09-2019 om 05:43 schreef Manasi Navare:
> > In case of tiled displays where different tiles are displayed across
> > different ports, we need to synchronize the transcoders involved.
> > This patch implements the transcoder port sync feature for
> > synchronizing one master transcoder with one or more slave
> > transcoders. This is only enbaled in slave transcoder
> > and the master transcoder is unaware that it is operating
> > in this mode.
> > This has been tested with tiled display connected to ICL.
> >
> > v4:
> > Rebase
> > v3:
> > * Check of DP_MST moved to atomic_check (Maarten)
> > v2:
> > * Do not use RMW, just write to the register in commit (Jani N)
> >
> > Cc: Daniel Vetter
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Matt Roper
> > Cc: Jani Nikula
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 43
> > 1 file changed, 43 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8942c905ae66..b8f7a919b6d3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4380,6 +4380,46 @@ static void icl_set_pipe_chicken(struct intel_crtc
> > *crtc)
> > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > }
> >
> > +static void icl_enable_trans_port_sync(const struct intel_crtc_state
> > *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + u32 trans_ddi_func_ctl2_val;
> > + u8 master_select;
> > +
> > + /*
> > +* Configure the master select and enable Transcoder Port Sync for
> > +* Slave CRTCs transcoder.
> > +*/
> > + if (crtc_state->master_transcoder == INVALID_TRANSCODER)
> > + return;
> > +
> > + switch (crtc_state->master_transcoder) {
> > + case TRANSCODER_A:
> > + master_select = 1;
> > + break;
> > + case TRANSCODER_B:
> > + master_select = 2;
> > + break;
> > + case TRANSCODER_C:
> > + master_select = 3;
> > + break;
> TRANSCODER_D btw?
Yes will add that
Manasi
> > + case TRANSCODER_EDP:
> > + default:
> > + master_select = 0;
> > + break;
> > + }
> > + /* Set the master select bits for Tranascoder Port Sync */
> > + trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> > + PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> > + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > + /* Enable Transcoder Port Sync */
> > + trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> > +
> > + I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> > + trans_ddi_func_ctl2_val);
> > +}
> > +
> > static void intel_update_pipe_config(const struct intel_crtc_state
> > *old_crtc_state,
> > const struct intel_crtc_state
> > *new_crtc_state)
> > {
> > @@ -6448,6 +6488,9 @@ static void haswell_crtc_enable(struct
> > intel_crtc_state *pipe_config,
> > if (!transcoder_is_dsi(cpu_transcoder))
> > intel_set_pipe_timings(pipe_config);
> >
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + icl_enable_trans_port_sync(pipe_config);
> > +
> > intel_set_pipe_src_size(pipe_config);
> >
> > if (cpu_transcoder != TRANSCODER_EDP &&
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add TigerLake bandwidth checking
== Series Details == Series: drm/i915: Add TigerLake bandwidth checking URL : https://patchwork.freedesktop.org/series/66817/ State : warning == Summary == $ dim checkpatch origin/drm-tip b3e5a03f489c drm/i915: Add TigerLake bandwidth checking -:39: CHECK:LINE_SPACING: Please don't use multiple blank lines #39: FILE: drivers/gpu/drm/i915/display/intel_bw.c:153: + + total: 0 errors, 0 warnings, 1 checks, 142 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence
On Tue, Sep 17, 2019 at 05:04:28PM +0200, Maarten Lankhorst wrote:
> Op 09-09-2019 om 05:43 schreef Manasi Navare:
> > This clears the transcoder port sync bits of the TRANS_DDI_FUNC_CTL2
> > register during crtc_disable().
> >
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Matt Roper
> > Cc: Jani Nikula
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 23
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 351c90ad7059..07deb0b93f5c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4438,6 +4438,26 @@ static void icl_enable_trans_port_sync(const struct
> > intel_crtc_state *crtc_state
> >trans_ddi_func_ctl2_val);
> > }
> >
> > +static void icl_disable_transcoder_port_sync(const struct intel_crtc_state
> > *old_crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > + i915_reg_t reg;
> > + u32 trans_ddi_func_ctl2_val;
> > +
> > + if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
> > + return;
> > +
> > + DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave Transcoder %s\n",
> > + transcoder_name(old_crtc_state->cpu_transcoder));
> > +
> > + reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
> > + trans_ddi_func_ctl2_val = I915_READ(reg);
> > + trans_ddi_func_ctl2_val &= ~(PORT_SYNC_MODE_ENABLE |
> > +PORT_SYNC_MODE_MASTER_SELECT_MASK);
> > + I915_WRITE(reg, trans_ddi_func_ctl2_val);
> > +}
> > +
> Would anything break if we just wrote 0 here?
We dont want to accidently reset other bits in the register which are for DSI
and not used currently but
to make this function more future proof, I have avoided writing a 0
But if you strongly feel against this, I can switch this to writing 0 directly.
Manasi
> > static void intel_update_pipe_config(const struct intel_crtc_state
> > *old_crtc_state,
> > const struct intel_crtc_state
> > *new_crtc_state)
> > {
> > @@ -6687,6 +6707,9 @@ static void haswell_crtc_disable(struct
> > intel_crtc_state *old_crtc_state,
> > if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
> > intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
> >
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + icl_disable_transcoder_port_sync(old_crtc_state);
> > +
> > if (!transcoder_is_dsi(cpu_transcoder))
> > intel_ddi_disable_transcoder_func(old_crtc_state);
> >
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for adding gamma state checker for icl+ platforms (rev2)
== Series Details ==
Series: adding gamma state checker for icl+ platforms (rev2)
URL : https://patchwork.freedesktop.org/series/66811/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6909 -> Patchwork_14432
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/
Known issues
Here are the changes found in Patchwork_14432 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][5] -> [DMESG-WARN][6] ([fdo#105602]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] /
[fdo#108569])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10] ([fdo#103558])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-apl-guc: [PASS][11] -> [SKIP][12] ([fdo#109271]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_module_load@reload-no-display:
- {fi-icl-u4}:[DMESG-WARN][13] ([fdo#105602]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[SKIP][15] ([fdo#109271]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][17] ([fdo#108511]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][19] ([fdo#08]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@vgem_basic@second-client:
- fi-icl-u3: [DMESG-WARN][21] ([fdo#107724]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u3/igt@vgem_ba...@second-client.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14432/fi-icl-u3/igt@vgem_ba...@second-client.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
Re: [Intel-gfx] [PATCH] drm/i915: fix SFC reset flow
Quoting Daniele Ceraolo Spurio (2019-09-16 22:41:04)
> @@ -401,7 +407,10 @@ static void gen11_unlock_sfc(struct intel_engine_cs
> *engine)
> return;
> }
>
> - rmw_clear_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
> + lock = intel_uncore_read_fw(uncore, sfc_forced_lock);
> + if (lock & sfc_forced_lock_bit)
> + intel_uncore_write_fw(uncore, sfc_forced_lock,
> + lock & ~sfc_forced_lock_bit);
This is handled by rmw_clear_fw() itself now,
80fa64d62067 ("drm/i915: Only apply a rmw mmio update if the value changes")
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for adding gamma state checker for icl+ platforms (rev2)
== Series Details ==
Series: adding gamma state checker for icl+ platforms (rev2)
URL : https://patchwork.freedesktop.org/series/66811/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
58295b9b8527 drm/i915/display: Fix formatting issues
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 46 lines checked
2d4f98e0b6e0 drm/i915/display: Extract icl_read_luts()
-:81: ERROR:TRAILING_WHITESPACE: trailing whitespace
#81: FILE: drivers/gpu/drm/i915/display/intel_color.c:1444:
+^I^Ireturn 16; $
-:87: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#87: FILE: drivers/gpu/drm/i915/display/intel_color.c:1450:
+
+}
-:279: WARNING:LONG_LINE: line over 100 characters
#279: FILE: drivers/gpu/drm/i915/display/intel_color.c:1893:
+ tmp_blob_data[i].green =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 |
-:291: WARNING:LONG_LINE: line over 100 characters
#291: FILE: drivers/gpu/drm/i915/display/intel_color.c:1905:
+ tmp_blob_data[i + 8].red =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, val2) << 6 |
-:293: WARNING:LONG_LINE: line over 100 characters
#293: FILE: drivers/gpu/drm/i915/display/intel_color.c:1907:
+ tmp_blob_data[i + 8].green =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 |
-:295: WARNING:LONG_LINE: line over 100 characters
#295: FILE: drivers/gpu/drm/i915/display/intel_color.c:1909:
+ tmp_blob_data[i + 8].blue =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, val2) << 6 |
-:303: WARNING:LONG_LINE: line over 100 characters
#303: FILE: drivers/gpu/drm/i915/display/intel_color.c:1917:
+ tmp_blob_data[i + 265].red =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, val2) << 6 |
-:305: WARNING:LONG_LINE: line over 100 characters
#305: FILE: drivers/gpu/drm/i915/display/intel_color.c:1919:
+ tmp_blob_data[i + 265].green =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 |
-:306: WARNING:LONG_LINE: line over 100 characters
#306: FILE: drivers/gpu/drm/i915/display/intel_color.c:1920:
+
REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_LDW_MASK, val1);
-:307: WARNING:LONG_LINE: line over 100 characters
#307: FILE: drivers/gpu/drm/i915/display/intel_color.c:1921:
+ tmp_blob_data[i + 265].blue =
REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, val2) << 6 |
total: 1 errors, 8 warnings, 1 checks, 344 lines checked
4760f8cc0e59 FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:16: WARNING:LONG_LINE: line over 100 characters
#16: FILE: drivers/gpu/drm/i915/display/intel_color.c:1477:
+ DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x
sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", lut2->red, lut1->red,
lut2->blue, lut1->blue, lut2->green, lut1->green);
total: 0 errors, 2 warnings, 0 checks, 8 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3)
== Series Details ==
Series: drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3)
URL : https://patchwork.freedesktop.org/series/66625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6909 -> Patchwork_14431
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/
Known issues
Here are the changes found in Patchwork_14431 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2] ([fdo#105602]) +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [PASS][3] -> [WARN][4] ([fdo#109483])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][5] -> [DMESG-WARN][6] ([fdo#102614])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([fdo#103558])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-apl-guc: [PASS][9] -> [SKIP][10] ([fdo#109271]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_render_tiled_blits@basic:
- {fi-tgl-u2}:[FAIL][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-tgl-u2/igt@gem_render_tiled_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-tgl-u2/igt@gem_render_tiled_bl...@basic.html
* igt@i915_module_load@reload-no-display:
- {fi-icl-u4}:[DMESG-WARN][13] ([fdo#105602]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[SKIP][15] ([fdo#109271]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][17] ([fdo#108511]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][19] ([fdo#08]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111407]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14431/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[Intel-gfx] [PATCH v3] drm/i915: Lock signaler timeline while navigating
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
v2: Tvrtko made me realise I was being lax and using annotations to
ignore the AB-BA deadlock from the timeline overlap. As it would be
possible to construct a second request that was using a semaphore from the
same timeline as ourselves, we could quite easily end up in a situation
where we deadlocked in our mutex waits. Avoid that by using a trylock
and falling back to a normal dma-fence await if contended.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 56 +++--
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..4e861673fe5c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(>link, >timeline->requests))
+ struct intel_timeline *tl = signal->timeline;
+ struct dma_fence *fence;
+ int err;
+
+ lockdep_assert_held(>timeline->mutex);
+ GEM_BUG_ON(rq->timeline == signal->timeline);
+
+ if (list_is_first(>link, >requests))
return 0;
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(rq->timeline, >fence))
+ if (!mutex_trylock(>mutex))
+ return -EBUSY;
+
+ fence = NULL;
+ if (!list_is_first(>link, >requests))
+ fence = dma_fence_get(_prev_entry(signal, link)->fence);
+
+ mutex_unlock(>mutex);
+ if (!fence)
return 0;
- return i915_sw_fence_await_dma_fence(>submit,
->fence, 0,
-I915_FENCE_GFP);
+ err = 0;
+ if (!intel_timeline_sync_is_later(rq->timeline, fence))
+ err = i915_sw_fence_await_dma_fence(>submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
@@ -804,30 +823,24 @@ emit_semaphore_wait(struct i915_request *to,
{
u32 hwsp_offset;
u32 *cs;
- int err;
GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
/* Just emit the first semaphore we see as request space is limited. */
if (already_busywaiting(to) & from->engine->mask)
- return i915_sw_fence_await_dma_fence(>submit,
->fence, 0,
-I915_FENCE_GFP);
+ goto await_fence;
- err = i915_request_await_start(to, from);
- if (err < 0)
- return err;
+ if (i915_request_await_start(to, from) < 0)
+ goto await_fence;
/* Only submit our spinner after the signaler is running! */
- err = __i915_request_await_execution(to, from, NULL, gfp);
- if (err)
- return err;
+ if (__i915_request_await_execution(to, from, NULL, gfp))
+ goto await_fence;
/* We need to pin the signaler's HWSP until we are finished reading. */
- err = intel_timeline_read_hwsp(from, to, _offset);
- if (err)
- return err;
+ if (intel_timeline_read_hwsp(from, to, _offset))
+ goto await_fence;
cs = intel_ring_begin(to, 4);
if (IS_ERR(cs))
@@ -853,6 +866,11 @@ emit_semaphore_wait(struct i915_request *to,
to->sched.semaphores |= from->engine->mask;
to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
return 0;
+
+await_fence:
+ return i915_sw_fence_await_dma_fence(>submit,
+>fence, 0,
+I915_FENCE_GFP);
}
static int
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3)
== Series Details == Series: drm/i915/tgl: Extend MI_SEMAPHORE_WAIT (rev3) URL : https://patchwork.freedesktop.org/series/66625/ State : warning == Summary == $ dim checkpatch origin/drm-tip 99968bd8d581 drm/i915/tgl: Extend MI_SEMAPHORE_WAIT -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: v2: Define the token shift while we are adding the updated MI_SEMAPHORE_WAIT total: 0 errors, 1 warnings, 0 checks, 172 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Clear Color Support for TGL Render Decompression
== Series Details ==
Series: Clear Color Support for TGL Render Decompression
URL : https://patchwork.freedesktop.org/series/66814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6909 -> Patchwork_14430
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/
Known issues
Here are the changes found in Patchwork_14430 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u3/igt@gem_ctx_e...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-icl-u3/igt@gem_ctx_e...@basic.html
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([fdo#105602]) +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724] /
[fdo#111214])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u3/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [PASS][7] -> [WARN][8] ([fdo#109483])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10] ([fdo#103558])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-apl-guc: [PASS][11] -> [SKIP][12] ([fdo#109271]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-apl-guc/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_module_load@reload-no-display:
- {fi-icl-u4}:[DMESG-WARN][13] ([fdo#105602]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[SKIP][15] ([fdo#109271]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [FAIL][17] ([fdo#108511]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][19] ([fdo#111407]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@vgem_basic@second-client:
- fi-icl-u3: [DMESG-WARN][21] ([fdo#107724]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6909/fi-icl-u3/igt@vgem_ba...@second-client.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14430/fi-icl-u3/igt@vgem_ba...@second-client.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Re: [Intel-gfx] [PATCH] drm/i915: Lock signaler timeline while navigating
On 17/09/2019 16:04, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-17 15:51:45)
On 17/09/2019 08:43, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 30 +++--
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..452ad7a8ff0c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request
*signal)
{
- if (list_is_first(>link, >timeline->requests))
+ struct intel_timeline *tl = signal->timeline;
+ struct dma_fence *fence;
+ int err;
+
+ if (list_is_first(>link, >requests))
return 0;
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(rq->timeline, >fence))
+ if (mutex_lock_interruptible_nested(>mutex, SINGLE_DEPTH_NESTING))
We are getting more and more these nested ones and it will become
unmanageable to remember which ones, why and on what paths. Perhaps we
need a comment next to the member in the structure definition?
The timeline mutex is held for request construction and retire; entry
and exit of the timeline->requests. Since we have a request, it should
be holding its rq->timeline->mutex; is that what you wish documented?
Similarly that signal->timeline != rq->timeline.
GEM_BUG_ON(signal->timeline == rq->timeline);
lockdep_assert_held(>timeline->mutex);
Yeah that helps.
+ return -EINTR;
+
+ if (list_is_first(>link, >requests)) {
+ fence = NULL;
+ } else {
+ signal = list_prev_entry(signal, link);
+ fence = dma_fence_get_rcu(>fence);
+ }
+ mutex_unlock(>mutex);
+ if (!fence)
Can it be no fence when it was obtained under the mutex?
Yes. The previous fence may have been retired and so removed from the
tl->requests before we acquire the mutex. It should not be freed while
it is still in the list, i.e. dma_fence_get_rcu() should never return
NULL.
I did not worry about the list_is_first check, just about
dma_fence_get_rcu. At least I'm happy that one is safe and v2 is even
better in this respect.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Lock signaler timeline while navigating
On 17/09/2019 16:09, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines.
---
drivers/gpu/drm/i915/i915_request.c | 31 +++--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..3966b330b5de 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(>link, >timeline->requests))
+ struct intel_timeline *tl = signal->timeline;
+ struct dma_fence *fence;
+ int err;
+
+ lockdep_assert_held(>timeline->mutex);
+ GEM_BUG_ON(rq->timeline == signal->timeline);
+
+ if (list_is_first(>link, >requests))
return 0;
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(rq->timeline, >fence))
+ if (mutex_lock_interruptible_nested(>mutex, SINGLE_DEPTH_NESTING))
+ return -EINTR;
+
+ fence = NULL;
+ if (!list_is_first(>link, >requests))
+ fence = dma_fence_get(_prev_entry(signal, link)->fence);
+
+ mutex_unlock(>mutex);
+ if (!fence)
return 0;
- return i915_sw_fence_await_dma_fence(>submit,
->fence, 0,
-I915_FENCE_GFP);
+ err = 0;
+ if (!intel_timeline_sync_is_later(rq->timeline, fence))
+ err = i915_sw_fence_await_dma_fence(>submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
Yes the asserts make it obvious now why the nested annotation is needed.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Verify the engine after acquiring the active.lock
Quoting Tvrtko Ursulin (2019-09-17 15:59:25)
>
> On 16/09/2019 12:38, Chris Wilson wrote:
> > When using virtual engines, the rq->engine is not stable until we hold
> > the engine->active.lock (as the virtual engine may be exchanged with the
> > sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
> > we may retire a request concurrently with resubmitting it to HW, we need
> > to be extra careful to verify we are holding the correct lock for the
> > request's active list. This is similar to the issue we saw with
> > rescheduling the virtual requests, see sched_lock_engine().
> >
> > Or else:
> >
> > <4> [876.736126] list_add corruption. prev->next should be next
> > (8883f931a1f8), but was dead0100. (prev=888361ffa610).
> > <4> [876.736136] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
> > __list_add_valid+0x4d/0x70
> > <4> [876.736137] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
> > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
> > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
> > snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether
> > usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm
> > btintel bluetooth ecdh_generic ecc [last unloaded: i915]
> > <4> [876.736154] CPU: 2 PID: 21 Comm: ksoftirqd/2 Tainted: G U
> > 5.3.0-CI-CI_DRM_6898+ #1
> > <4> [876.736156] Hardware name: Intel Corporation Ice Lake Client
> > Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS
> > ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
> > <4> [876.736157] RIP: 0010:__list_add_valid+0x4d/0x70
> > <4> [876.736159] Code: c3 48 89 d1 48 c7 c7 20 33 0e 82 48 89 c2 e8 4a 4a
> > bc ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 70 33 0e 82 e8 33 4a bc ff
> > <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 c0 33 0e 82 e8
> > <4> [876.736160] RSP: 0018:c918bd30 EFLAGS: 00010082
> > <4> [876.736162] RAX: RBX: 888361ffc840 RCX:
> > 0104
> > <4> [876.736163] RDX: 8104 RSI: RDI:
> >
> > <4> [876.736164] RBP: c918bd68 R08: R09:
> > 0001
> > <4> [876.736165] R10: aed95de3 R11: 7fe927eb R12:
> > 888361ffca10
> > <4> [876.736166] R13: 888361ffa610 R14: 888361ffc880 R15:
> > 8883f931a1f8
> > <4> [876.736168] FS: () GS:88849fd0()
> > knlGS:
> > <4> [876.736169] CS: 0010 DS: ES: CR0: 80050033
> > <4> [876.736170] CR2: 7f093a9173c0 CR3: 0003bba08005 CR4:
> > 00760ee0
> > <4> [876.736171] PKRU: 5554
> > <4> [876.736172] Call Trace:
> > <4> [876.736226] __i915_request_submit+0x152/0x370 [i915]
> > <4> [876.736263] __execlists_submission_tasklet+0x6da/0x1f50 [i915]
> > <4> [876.736293] ? execlists_submission_tasklet+0x29/0x50 [i915]
> > <4> [876.736321] execlists_submission_tasklet+0x34/0x50 [i915]
> > <4> [876.736325] tasklet_action_common.isra.5+0x47/0xb0
> > <4> [876.736328] __do_softirq+0xd8/0x4ae
> > <4> [876.736332] ? smpboot_thread_fn+0x23/0x280
> > <4> [876.736334] ? smpboot_thread_fn+0x6b/0x280
> > <4> [876.736336] run_ksoftirqd+0x2b/0x50
> > <4> [876.736338] smpboot_thread_fn+0x1d3/0x280
> > <4> [876.736341] ? sort_range+0x20/0x20
> > <4> [876.736343] kthread+0x119/0x130
> > <4> [876.736345] ? kthread_park+0xa0/0xa0
> > <4> [876.736347] ret_from_fork+0x24/0x50
> > <4> [876.736353] irq event stamp: 2290145
> > <4> [876.736356] hardirqs last enabled at (2290144): []
> > __slab_free+0x3e8/0x500
> > <4> [876.736358] hardirqs last disabled at (2290145): []
> > _raw_spin_lock_irqsave+0xd/0x50
> > <4> [876.736360] softirqs last enabled at (2290114): []
> > __do_softirq+0x33e/0x4ae
> > <4> [876.736361] softirqs last disabled at (2290119): []
> > run_ksoftirqd+0x2b/0x50
> > <4> [876.736363] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
> > __list_add_valid+0x4d/0x70
> > <4> [876.736364] ---[ end trace 3e58d6c7356c65bf ]---
> > <4> [876.736406] [ cut here ]
> > <4> [876.736415] list_del corruption. prev->next should be
> > 888361ffca10, but was 88840ac2c730
> > <4> [876.736421] WARNING: CPU: 2 PID: 5490 at lib/list_debug.c:53
> > __list_del_entry_valid+0x79/0x90
> > <4> [876.736422] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
> > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
> > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
> > snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether
> > usbnet mii snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm
> > btintel bluetooth ecdh_generic ecc [last unloaded: i915]
> > <4> [876.736433] CPU: 2 PID: 5490 Comm: i915_selftest Tainted: G U W
> > 5.3.0-CI-CI_DRM_6898+ #1
> > <4> [876.736435] Hardware name: Intel Corporation Ice
[Intel-gfx] [PATCH v2] drm/i915: Lock signaler timeline while navigating
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Add the lockdep assert and GEM_BUG_ON to note the overlapping timelines.
---
drivers/gpu/drm/i915/i915_request.c | 31 +++--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..3966b330b5de 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,35 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(>link, >timeline->requests))
+ struct intel_timeline *tl = signal->timeline;
+ struct dma_fence *fence;
+ int err;
+
+ lockdep_assert_held(>timeline->mutex);
+ GEM_BUG_ON(rq->timeline == signal->timeline);
+
+ if (list_is_first(>link, >requests))
return 0;
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(rq->timeline, >fence))
+ if (mutex_lock_interruptible_nested(>mutex, SINGLE_DEPTH_NESTING))
+ return -EINTR;
+
+ fence = NULL;
+ if (!list_is_first(>link, >requests))
+ fence = dma_fence_get(_prev_entry(signal, link)->fence);
+
+ mutex_unlock(>mutex);
+ if (!fence)
return 0;
- return i915_sw_fence_await_dma_fence(>submit,
->fence, 0,
-I915_FENCE_GFP);
+ err = 0;
+ if (!intel_timeline_sync_is_later(rq->timeline, fence))
+ err = i915_sw_fence_await_dma_fence(>submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/display/icl: In port sync mode disable slaves first then master
Op 09-09-2019 om 17:52 schreef Manasi Navare:
> In the transcoder port sync mode, the slave transcoders mask their vblanks
> until master transcoder's vblank so while disabling them, make
> sure slaves are disabled first and then the masters.
>
> v4:
> * Obtain slave state from master (Maarten)
> v3:
> * Rebase
> v2:
> * Use the intel_old_crtc_state_disables() helper
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 62 ++--
> 1 file changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ac6e880570ea..8c333280d8f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14074,8 +14074,42 @@ static void intel_old_crtc_state_disables(struct
> intel_atomic_state *state,
>new_crtc_state);
> }
>
> +static void intel_trans_port_sync_modeset_disables(struct intel_atomic_state
> *state,
> +struct intel_crtc *crtc,
> +struct intel_crtc_state
> *old_crtc_state,
> +struct intel_crtc_state
> *new_crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_crtc *slave_crtc = intel_get_slave_crtc(dev_priv,
> + new_crtc_state);
> + struct intel_crtc_state *new_slave_crtc_state =
> + intel_atomic_get_new_crtc_state(state, slave_crtc);
> + struct intel_crtc_state *old_slave_crtc_state =
> + intel_atomic_get_old_crtc_state(state, slave_crtc);
> +
> + WARN_ON(!slave_crtc || !new_slave_crtc_state ||
> + !old_slave_crtc_state);
> +
> + /* Disable Slave first */
> + intel_pre_plane_update(old_slave_crtc_state, new_slave_crtc_state);
> + if (old_slave_crtc_state->base.active)
> + intel_old_crtc_state_disables(state,
> + old_slave_crtc_state,
> + new_slave_crtc_state,
> + slave_crtc);
> +
> + /* Disable Master */
> + intel_pre_plane_update(old_crtc_state, new_crtc_state);
> + if (old_crtc_state->base.active)
> + intel_old_crtc_state_disables(state,
> + old_crtc_state,
> + new_crtc_state,
> + crtc);
> +}
> +
> static void intel_commit_modeset_disables(struct intel_atomic_state *state)
> {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> struct intel_crtc *crtc;
> int i;
> @@ -14092,13 +14126,29 @@ static void intel_commit_modeset_disables(struct
> intel_atomic_state *state)
> if (!needs_modeset(new_crtc_state))
> continue;
>
> - intel_pre_plane_update(old_crtc_state, new_crtc_state);
> + /* In case of Transcoder port Sync master slave CRTCs can be
> + * assigned in any order and we need to make sure that
> + * slave CRTCs are disabled first and then master CRTC since
> + * Slave vblanks are masked till Master Vblanks.
> + */
> + if (is_trans_port_sync_mode(dev_priv, new_crtc_state)) {
> + if (is_trans_port_sync_master(dev_priv,
> + new_crtc_state))
> + intel_trans_port_sync_modeset_disables(state,
> +crtc,
> +
> old_crtc_state,
> +
> new_crtc_state);
> + else
> + continue;
> + } else {
> + intel_pre_plane_update(old_crtc_state, new_crtc_state);
>
> - if (old_crtc_state->base.active)
> - intel_old_crtc_state_disables(state,
> - old_crtc_state,
> - new_crtc_state,
> - crtc);
> + if (old_crtc_state->base.active)
> + intel_old_crtc_state_disables(state,
> + old_crtc_state,
> + new_crtc_state,
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clear Color Support for TGL Render Decompression
== Series Details ==
Series: Clear Color Support for TGL Render Decompression
URL : https://patchwork.freedesktop.org/series/66814/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1b45d10a93b6 drm/framebuffer/tgl: Format modifier for Intel Gen-12 render
compression
8c34c16a8118 drm/i915/tgl: Gen-12 render decompression
7c0a2d4fecf3 drm/framebuffer/tgl: Format modifier for Intel Gen-12 media
compression
fa6f2cb7eb5e drm/i915/tgl: Gen-12 media compression
-:74: WARNING:MISSING_BREAK: Possible switch case/default not preceded by break
or fallthrough comment
#74: FILE: drivers/gpu/drm/i915/display/intel_display.c:2524:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
total: 0 errors, 1 warnings, 0 checks, 134 lines checked
e75d005d2b0a drm/framebuffer/tgl: Format modifier for Intel Gen 12 render
compression with Clear Color
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#7:
Gen12 display can decompress surfaces compressed by render engine with Clear
Color, add
total: 0 errors, 1 warnings, 0 checks, 17 lines checked
531124e8273e drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
-:71: WARNING:LONG_LINE: line over 100 characters
#71: FILE: drivers/gpu/drm/i915/display/intel_display.c:2513:
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 3, .cpp = {
4, 1, 0}, .hsub = 2, .vsub = 32, },
-:72: WARNING:LONG_LINE: line over 100 characters
#72: FILE: drivers/gpu/drm/i915/display/intel_display.c:2514:
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 3, .cpp = {
4, 1, 0}, .hsub = 2, .vsub = 32, },
-:73: WARNING:LONG_LINE: line over 100 characters
#73: FILE: drivers/gpu/drm/i915/display/intel_display.c:2515:
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 3, .cpp = {
4, 1, 0}, .hsub = 2, .vsub = 32, },
-:74: WARNING:LONG_LINE: line over 100 characters
#74: FILE: drivers/gpu/drm/i915/display/intel_display.c:2516:
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 3, .cpp = {
4, 1, 0}, .hsub = 2, .vsub = 32, },
-:242: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible
side-effects?
#242: FILE: drivers/gpu/drm/i915/i915_reg.h:6770:
+#define PLANE_CC_VAL(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_CC_VAL_1(pipe), _PLANE_CC_VAL_2(pipe))
total: 0 errors, 4 warnings, 1 checks, 193 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence
Op 09-09-2019 om 05:43 schreef Manasi Navare:
> This clears the transcoder port sync bits of the TRANS_DDI_FUNC_CTL2
> register during crtc_disable().
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 23
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 351c90ad7059..07deb0b93f5c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4438,6 +4438,26 @@ static void icl_enable_trans_port_sync(const struct
> intel_crtc_state *crtc_state
> trans_ddi_func_ctl2_val);
> }
>
> +static void icl_disable_transcoder_port_sync(const struct intel_crtc_state
> *old_crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + i915_reg_t reg;
> + u32 trans_ddi_func_ctl2_val;
> +
> + if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
> + return;
> +
> + DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave Transcoder %s\n",
> + transcoder_name(old_crtc_state->cpu_transcoder));
> +
> + reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
> + trans_ddi_func_ctl2_val = I915_READ(reg);
> + trans_ddi_func_ctl2_val &= ~(PORT_SYNC_MODE_ENABLE |
> + PORT_SYNC_MODE_MASTER_SELECT_MASK);
> + I915_WRITE(reg, trans_ddi_func_ctl2_val);
> +}
> +
Would anything break if we just wrote 0 here?
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -6687,6 +6707,9 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> if (intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST))
> intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_disable_transcoder_port_sync(old_crtc_state);
> +
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_ddi_disable_transcoder_func(old_crtc_state);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Lock signaler timeline while navigating
Quoting Tvrtko Ursulin (2019-09-17 15:51:45)
>
> On 17/09/2019 08:43, Chris Wilson wrote:
> > As we need to take a walk back along the signaler timeline to find the
> > fence before upon which we want to wait, we need to lock that timeline
> > to prevent it being modified as we walk. Similarly, we also need to
> > acquire a reference to the earlier fence while it still exists!
> >
> > Though we lack the correct locking today, we are saved by the
> > overarching struct_mutex -- but that protection is being removed.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 30 +++--
> > 1 file changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index f12358150097..452ad7a8ff0c 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
> > static int
> > i915_request_await_start(struct i915_request *rq, struct i915_request
> > *signal)
> > {
> > - if (list_is_first(>link, >timeline->requests))
> > + struct intel_timeline *tl = signal->timeline;
> > + struct dma_fence *fence;
> > + int err;
> > +
> > + if (list_is_first(>link, >requests))
> > return 0;
> >
> > - signal = list_prev_entry(signal, link);
> > - if (intel_timeline_sync_is_later(rq->timeline, >fence))
> > + if (mutex_lock_interruptible_nested(>mutex, SINGLE_DEPTH_NESTING))
>
> We are getting more and more these nested ones and it will become
> unmanageable to remember which ones, why and on what paths. Perhaps we
> need a comment next to the member in the structure definition?
The timeline mutex is held for request construction and retire; entry
and exit of the timeline->requests. Since we have a request, it should
be holding its rq->timeline->mutex; is that what you wish documented?
Similarly that signal->timeline != rq->timeline.
GEM_BUG_ON(signal->timeline == rq->timeline);
lockdep_assert_held(>timeline->mutex);
> > + return -EINTR;
> > +
> > + if (list_is_first(>link, >requests)) {
> > + fence = NULL;
> > + } else {
> > + signal = list_prev_entry(signal, link);
> > + fence = dma_fence_get_rcu(>fence);
> > + }
> > + mutex_unlock(>mutex);
> > + if (!fence)
>
> Can it be no fence when it was obtained under the mutex?
Yes. The previous fence may have been retired and so removed from the
tl->requests before we acquire the mutex. It should not be freed while
it is still in the list, i.e. dma_fence_get_rcu() should never return
NULL.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display/icl: Enable master-slaves in trans port sync
Op 09-09-2019 om 17:52 schreef Manasi Navare:
> As per the display enable sequence, we need to follow the enable sequence
> for slaves first with DP_TP_CTL set to Idle and configure the transcoder
> port sync register to select the corersponding master, then follow the
> enable sequence for master leaving DP_TP_CTL to idle.
> At this point the transcoder port sync mode is configured and enabled
> and the Vblanks of both ports are synchronized so then set DP_TP_CTL
> for the slave and master to Normal and do post crtc enable updates.
>
> v5:
> * Fix checkpatch warning (Manasi)
> v4:
> * Reuse skl_commit_modeset_enables() hook (Maarten)
> * Obtain slave crtc and states from master (Maarten)
> v3:
> * Rebase on drm-tip (Manasi)
> v2:
> * Create a icl_update_crtcs hook (Maarten, Danvet)
> * This sequence only for CRTCs in trans port sync mode (Maarten)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> drivers/gpu/drm/i915/display/intel_display.c | 158 ++-
> drivers/gpu/drm/i915/display/intel_display.h | 4 +
> 3 files changed, 162 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3e6394139964..62e9f5602b6b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3347,7 +3347,8 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
> *encoder,
> true);
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
> intel_dp_start_link_train(intel_dp);
> - if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> + if ((port != PORT_A || INTEL_GEN(dev_priv) >= 9) &&
> + !is_trans_port_sync_mode(dev_priv, crtc_state))
> intel_dp_stop_link_train(intel_dp);
>
> intel_ddi_enable_fec(encoder, crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 76ca1ca864c0..5e583e9157f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -521,6 +521,24 @@ needs_modeset(const struct intel_crtc_state *state)
> return drm_atomic_crtc_needs_modeset(>base);
> }
>
> +bool
> +is_trans_port_sync_mode(struct drm_i915_private *dev_priv,
> + const struct intel_crtc_state *state)
> +{
> + return (INTEL_GEN(dev_priv) >= 11 &&
> + (state->master_transcoder != INVALID_TRANSCODER ||
> + state->sync_mode_slaves_mask));
> +}
> +
> +static bool
> +is_trans_port_sync_master(struct drm_i915_private *dev_priv,
> + const struct intel_crtc_state *state)
> +{
> + return (INTEL_GEN(dev_priv) >= 11 &&
> + (state->master_transcoder == INVALID_TRANSCODER &&
> + state->sync_mode_slaves_mask));
> +}
> +
> /*
> * Platform specific helpers to calculate the port PLL loopback- (clock.m),
> * and post-divider (clock.p) values, pre- (clock.vco) and post-divided fast
> @@ -13974,6 +13992,30 @@ static void intel_update_crtc(struct intel_crtc
> *crtc,
> intel_finish_crtc_commit(state, crtc);
> }
>
> +static struct intel_crtc *intel_get_slave_crtc(struct drm_i915_private
> *dev_priv,
> +struct intel_crtc_state
> *new_crtc_state)
> +{
> + if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_A))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_A);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_B))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_B);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_C))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_C);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_D))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_D);
> + /* should never happen */
> + WARN_ON(1);
> + return NULL;
> +}
> +
> static void intel_old_crtc_state_disables(struct intel_atomic_state *state,
> struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state
> *new_crtc_state,
> @@ -14052,6 +14094,104 @@ static void intel_commit_modeset_enables(struct
> intel_atomic_state *state)
> }
> }
>
> +static void intel_crtc_enable_trans_port_sync(struct intel_crtc *crtc,
> + struct intel_atomic_state *state,
> + struct
Re: [Intel-gfx] [PATCH] drm/i915: Verify the engine after acquiring the active.lock
On 16/09/2019 12:38, Chris Wilson wrote:
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
we may retire a request concurrently with resubmitting it to HW, we need
to be extra careful to verify we are holding the correct lock for the
request's active list. This is similar to the issue we saw with
rescheduling the virtual requests, see sched_lock_engine().
Or else:
<4> [876.736126] list_add corruption. prev->next should be next
(8883f931a1f8), but was dead0100. (prev=888361ffa610).
<4> [876.736136] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736137] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii
snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth
ecdh_generic ecc [last unloaded: i915]
<4> [876.736154] CPU: 2 PID: 21 Comm: ksoftirqd/2 Tainted: G U
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736156] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411
05/02/2019
<4> [876.736157] RIP: 0010:__list_add_valid+0x4d/0x70
<4> [876.736159] Code: c3 48 89 d1 48 c7 c7 20 33 0e 82 48 89 c2 e8 4a 4a bc ff 0f 0b
31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 70 33 0e 82 e8 33 4a bc ff <0f> 0b 31 c0 c3 48 89
f2 4c 89 c1 48 89 fe 48 c7 c7 c0 33 0e 82 e8
<4> [876.736160] RSP: 0018:c918bd30 EFLAGS: 00010082
<4> [876.736162] RAX: RBX: 888361ffc840 RCX:
0104
<4> [876.736163] RDX: 8104 RSI: RDI:
<4> [876.736164] RBP: c918bd68 R08: R09:
0001
<4> [876.736165] R10: aed95de3 R11: 7fe927eb R12:
888361ffca10
<4> [876.736166] R13: 888361ffa610 R14: 888361ffc880 R15:
8883f931a1f8
<4> [876.736168] FS: () GS:88849fd0()
knlGS:
<4> [876.736169] CS: 0010 DS: ES: CR0: 80050033
<4> [876.736170] CR2: 7f093a9173c0 CR3: 0003bba08005 CR4:
00760ee0
<4> [876.736171] PKRU: 5554
<4> [876.736172] Call Trace:
<4> [876.736226] __i915_request_submit+0x152/0x370 [i915]
<4> [876.736263] __execlists_submission_tasklet+0x6da/0x1f50 [i915]
<4> [876.736293] ? execlists_submission_tasklet+0x29/0x50 [i915]
<4> [876.736321] execlists_submission_tasklet+0x34/0x50 [i915]
<4> [876.736325] tasklet_action_common.isra.5+0x47/0xb0
<4> [876.736328] __do_softirq+0xd8/0x4ae
<4> [876.736332] ? smpboot_thread_fn+0x23/0x280
<4> [876.736334] ? smpboot_thread_fn+0x6b/0x280
<4> [876.736336] run_ksoftirqd+0x2b/0x50
<4> [876.736338] smpboot_thread_fn+0x1d3/0x280
<4> [876.736341] ? sort_range+0x20/0x20
<4> [876.736343] kthread+0x119/0x130
<4> [876.736345] ? kthread_park+0xa0/0xa0
<4> [876.736347] ret_from_fork+0x24/0x50
<4> [876.736353] irq event stamp: 2290145
<4> [876.736356] hardirqs last enabled at (2290144): []
__slab_free+0x3e8/0x500
<4> [876.736358] hardirqs last disabled at (2290145): []
_raw_spin_lock_irqsave+0xd/0x50
<4> [876.736360] softirqs last enabled at (2290114): []
__do_softirq+0x33e/0x4ae
<4> [876.736361] softirqs last disabled at (2290119): []
run_ksoftirqd+0x2b/0x50
<4> [876.736363] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736364] ---[ end trace 3e58d6c7356c65bf ]---
<4> [876.736406] [ cut here ]
<4> [876.736415] list_del corruption. prev->next should be 888361ffca10,
but was 88840ac2c730
<4> [876.736421] WARNING: CPU: 2 PID: 5490 at lib/list_debug.c:53
__list_del_entry_valid+0x79/0x90
<4> [876.736422] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii
snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth
ecdh_generic ecc [last unloaded: i915]
<4> [876.736433] CPU: 2 PID: 5490 Comm: i915_selftest Tainted: G U W
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736435] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411
05/02/2019
<4> [876.736436] RIP: 0010:__list_del_entry_valid+0x79/0x90
<4> [876.736438] Code: 0b 31 c0 c3 48 89 fe 48 c7 c7 30 34 0e 82 e8 ae 49 bc ff 0f 0b
31 c0 c3 48 89 f2 48 89 fe 48 c7 c7 68 34 0e 82 e8 97 49 bc ff <0f> 0b 31 c0 c3 48 c7
c7 a8 34 0e 82 e8 86 49 bc ff 0f 0b 31 c0 c3
<4>
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
On Tue, Sep 17, 2019 at 4:47 PM Koenig, Christian
wrote:
>
> Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> > On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
> >> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> >>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> > On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> >> Ping? Any further comment on this or can't we merge at least the
> >> locking
> >> change?
> > I was at plumbers ...
> >> Christian.
> >>
> >> Am 11.09.19 um 12:53 schrieb Christian König:
> >>> Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> > This patch is a stripped down version of the locking changes
> > necessary to support dynamic DMA-buf handling.
> >
> > For compatibility we cache the DMA-buf mapping as soon as
> > exporter/importer disagree on the dynamic handling.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/dma-buf/dma-buf.c | 90
> > ---
> > include/linux/dma-buf.h | 51 +-
> > 2 files changed, 133 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 433d91d710e4..65052d52602b 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> > dma_buf_export_info *exp_info)
> > return ERR_PTR(-EINVAL);
> > }
> > +if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> > +exp_info->ops->dynamic_mapping))
> > +return ERR_PTR(-EINVAL);
> > +
> > if (!try_module_get(exp_info->owner))
> > return ERR_PTR(-ENOENT);
> > @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> > EXPORT_SYMBOL_GPL(dma_buf_put);
> >/**
> > - * dma_buf_attach - Add the device to dma_buf's attachments
> > list; optionally,
> > + * dma_buf_dynamic_attach - Add the device to dma_buf's
> > attachments list; optionally,
> > * calls attach() of dma_buf_ops to allow device-specific
> > attach functionality
> > - * @dmabuf:[in]buffer to attach device to.
> > - * @dev:[in]device to be attached.
> > + * @dmabuf:[in]buffer to attach device to.
> > + * @dev:[in]device to be attached.
> > + * @dynamic_mapping:[in]calling convention for map/unmap
> > *
> > * Returns struct dma_buf_attachment pointer for this
> > attachment. Attachments
> > * must be cleaned up by calling dma_buf_detach().
> > @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> > * accessible to @dev, and cannot be moved to a more suitable
> > place. This is
> > * indicated with the error code -EBUSY.
> > */
> > -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > - struct device *dev)
> > +struct dma_buf_attachment *
> > +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> > + bool dynamic_mapping)
> > {
> > struct dma_buf_attachment *attach;
> > int ret;
> > @@ -677,6 +683,7 @@ struct dma_buf_attachment
> > *dma_buf_attach(struct dma_buf *dmabuf,
> >attach->dev = dev;
> > attach->dmabuf = dmabuf;
> > +attach->dynamic_mapping = dynamic_mapping;
> >mutex_lock(>lock);
> > @@ -685,16 +692,64 @@ struct dma_buf_attachment
> > *dma_buf_attach(struct dma_buf *dmabuf,
> > if (ret)
> > goto err_attach;
> > }
> > +dma_resv_lock(dmabuf->resv, NULL);
> > list_add(>node, >attachments);
> > +dma_resv_unlock(dmabuf->resv);
> >mutex_unlock(>lock);
> > +/* When either the importer or the exporter can't handle
> > dynamic
> > + * mappings we cache the mapping here to avoid issues with the
> > + * reservation object lock.
> > + */
> > +if (dma_buf_attachment_is_dynamic(attach) !=
> > +dma_buf_is_dynamic(dmabuf)) {
> > +struct sg_table *sgt;
> > +
> > +if (dma_buf_is_dynamic(attach->dmabuf))
> > +dma_resv_lock(attach->dmabuf->resv,
Re: [Intel-gfx] [PATCH 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config
Op 09-09-2019 om 05:43 schreef Manasi Navare:
> After the state is committed, we readout the HW registers and compare
> the HW state with the SW state that we just committed.
> For Transcdoer port sync, we add master_transcoder and the
> salves bitmask to the crtc_state, hence we need to read those during
> the HW state readout to avoid pipe state mismatch.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 47
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b8f7a919b6d3..76ca1ca864c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10421,6 +10421,50 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> }
> }
>
> +static void icelake_get_trans_port_sync_config(struct intel_crtc *crtc,
> +struct intel_crtc_state
> *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + u32 trans_port_sync, transcoders, master_select;
> + enum transcoder cpu_transcoder;
> +
> + trans_port_sync =
> I915_READ(TRANS_DDI_FUNC_CTL2(pipe_config->cpu_transcoder));
> + if (trans_port_sync & PORT_SYNC_MODE_ENABLE) {
> + master_select = trans_port_sync &
> + PORT_SYNC_MODE_MASTER_SELECT_MASK;
> + switch (master_select) {
> + case 1:
> + pipe_config->master_transcoder = TRANSCODER_A;
> + break;
> + case 2:
> + pipe_config->master_transcoder = TRANSCODER_B;
> + break;
> + case 3:
> + pipe_config->master_transcoder = TRANSCODER_C;
> + break;
Same, TRANSCODER_D + MISSING_CASE()
> + default:
> + pipe_config->master_transcoder = TRANSCODER_EDP;
> + break;
> + }
> +
> + pipe_config->sync_mode_slaves_mask = 0;
> + } else {
> + pipe_config->master_transcoder = INVALID_TRANSCODER;
> +
> + transcoders = BIT(TRANSCODER_EDP) |
> + BIT(TRANSCODER_A) |
> + BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C);
> + for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> transcoders) {
> + trans_port_sync =
> I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> +
> + if (trans_port_sync & PORT_SYNC_MODE_ENABLE)
> + pipe_config->sync_mode_slaves_mask |=
> BIT(cpu_transcoder);
> + }
> + }
> +}
> +
> static bool haswell_get_pipe_config(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> @@ -10517,6 +10561,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->pixel_multiplier = 1;
> }
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icelake_get_trans_port_sync_config(crtc, pipe_config);
> +
> out:
> for_each_power_domain(power_domain, power_domain_mask)
> intel_display_power_put(dev_priv,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
Op 09-09-2019 om 05:43 schreef Manasi Navare:
> In case of tiled displays where different tiles are displayed across
> different ports, we need to synchronize the transcoders involved.
> This patch implements the transcoder port sync feature for
> synchronizing one master transcoder with one or more slave
> transcoders. This is only enbaled in slave transcoder
> and the master transcoder is unaware that it is operating
> in this mode.
> This has been tested with tiled display connected to ICL.
>
> v4:
> Rebase
> v3:
> * Check of DP_MST moved to atomic_check (Maarten)
> v2:
> * Do not use RMW, just write to the register in commit (Jani N)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 43
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8942c905ae66..b8f7a919b6d3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4380,6 +4380,46 @@ static void icl_set_pipe_chicken(struct intel_crtc
> *crtc)
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
> +static void icl_enable_trans_port_sync(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + u32 trans_ddi_func_ctl2_val;
> + u8 master_select;
> +
> + /*
> + * Configure the master select and enable Transcoder Port Sync for
> + * Slave CRTCs transcoder.
> + */
> + if (crtc_state->master_transcoder == INVALID_TRANSCODER)
> + return;
> +
> + switch (crtc_state->master_transcoder) {
> + case TRANSCODER_A:
> + master_select = 1;
> + break;
> + case TRANSCODER_B:
> + master_select = 2;
> + break;
> + case TRANSCODER_C:
> + master_select = 3;
> + break;
TRANSCODER_D btw?
> + case TRANSCODER_EDP:
> + default:
> + master_select = 0;
> + break;
> + }
> + /* Set the master select bits for Tranascoder Port Sync */
> + trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> +PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> + /* Enable Transcoder Port Sync */
> + trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> +
> + I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> +trans_ddi_func_ctl2_val);
> +}
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -6448,6 +6488,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_set_pipe_timings(pipe_config);
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_enable_trans_port_sync(pipe_config);
> +
> intel_set_pipe_src_size(pipe_config);
>
> if (cpu_transcoder != TRANSCODER_EDP &&
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
Op 09-09-2019 om 05:43 schreef Manasi Navare:
> In case of tiled displays where different tiles are displayed across
> different ports, we need to synchronize the transcoders involved.
> This patch implements the transcoder port sync feature for
> synchronizing one master transcoder with one or more slave
> transcoders. This is only enbaled in slave transcoder
> and the master transcoder is unaware that it is operating
> in this mode.
> This has been tested with tiled display connected to ICL.
>
> v4:
> Rebase
> v3:
> * Check of DP_MST moved to atomic_check (Maarten)
> v2:
> * Do not use RMW, just write to the register in commit (Jani N)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 43
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8942c905ae66..b8f7a919b6d3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4380,6 +4380,46 @@ static void icl_set_pipe_chicken(struct intel_crtc
> *crtc)
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
> +static void icl_enable_trans_port_sync(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + u32 trans_ddi_func_ctl2_val;
> + u8 master_select;
> +
> + /*
> + * Configure the master select and enable Transcoder Port Sync for
> + * Slave CRTCs transcoder.
> + */
> + if (crtc_state->master_transcoder == INVALID_TRANSCODER)
> + return;
> +
> + switch (crtc_state->master_transcoder) {
> + case TRANSCODER_A:
> + master_select = 1;
> + break;
> + case TRANSCODER_B:
> + master_select = 2;
> + break;
> + case TRANSCODER_C:
> + master_select = 3;
> + break;
> + case TRANSCODER_EDP:
> + default:
> + master_select = 0;
> + break;
> + }
default should use MISSING_CASE() Otherwise looks good.
> + /* Set the master select bits for Tranascoder Port Sync */
> + trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> +PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> + /* Enable Transcoder Port Sync */
> + trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> +
> + I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> +trans_ddi_func_ctl2_val);
> +}
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -6448,6 +6488,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_set_pipe_timings(pipe_config);
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_enable_trans_port_sync(pipe_config);
> +
> intel_set_pipe_src_size(pipe_config);
>
> if (cpu_transcoder != TRANSCODER_EDP &&
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
Op 09-09-2019 om 05:43 schreef Manasi Navare:
> In case of tiled displays when the two tiles are sent across two CRTCs
> over two separate DP SST connectors, we need a mechanism to synchronize
> the two CRTCs and their corresponding transcoders.
> So use the master-slave mode where there is one master corresponding
> to last horizontal and vertical tile that needs to be genlocked with
> all other slave tiles.
> This patch identifies saves the master transcoder in all the slave
> CRTC states. This is needed to select the master CRTC/transcoder
> while configuring transcoder port sync for the corresponding slaves.
>
> v3:
> * Use master_tramscoder instead of master_crtc for valid
> HW state readouts (Ville)
> v2:
> * Move this to intel_mode_set_pipe_config(Jani N, Ville)
> * Use slave_bitmask to save associated slaves in master crtc state (Ville)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 105 ++
> drivers/gpu/drm/i915/display/intel_display.h | 1 +
> .../drm/i915/display/intel_display_types.h| 6 +
> 3 files changed, 112 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4c30672bd108..8942c905ae66 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11745,6 +11745,91 @@ static bool c8_planes_changed(const struct
> intel_crtc_state *new_crtc_state)
> return !old_crtc_state->c8_planes != !new_crtc_state->c8_planes;
> }
>
> +static int icl_add_sync_mode_crtcs(struct drm_crtc *crtc,
> +struct intel_crtc_state *crtc_state,
> +struct drm_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> + struct drm_connector *master_connector, *connector;
> + struct drm_connector_state *connector_state;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_crtc *master_crtc = NULL;
> + struct drm_crtc_state *master_crtc_state;
> + struct intel_crtc_state *master_pipe_config;
> + int i, tile_group_id;
> +
> + if (INTEL_GEN(dev_priv) < 11)
> + return 0;
> +
> + /*
> + * In case of tiled displays there could be one or more slaves but
> there is
> + * only one master. Lets make the CRTC used by the connector
> corresponding
> + * to the last horizonal and last vertical tile a master/genlock CRTC.
> + * All the other CRTCs corresponding to other tiles of the same Tile
> group
> + * are the slave CRTCs and hold a pointer to their genlock CRTC.
> + */
> + for_each_new_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != crtc)
> + continue;
> + if (!connector->has_tile)
> + continue;
> + if (crtc_state->base.mode.hdisplay != connector->tile_h_size ||
> + crtc_state->base.mode.vdisplay != connector->tile_v_size)
> + return 0;
> + if (connector->tile_h_loc == connector->num_h_tile - 1 &&
> + connector->tile_v_loc == connector->num_v_tile - 1)
> + continue;
> + crtc_state->sync_mode_slaves_mask = 0;
> + tile_group_id = connector->tile_group->id;
> + drm_connector_list_iter_begin(_priv->drm, _iter);
> + drm_for_each_connector_iter(master_connector, _iter) {
> + struct drm_connector_state *master_conn_state = NULL;
> +
> + if (!master_connector->has_tile)
> + continue;
> + if (master_connector->tile_h_loc !=
> master_connector->num_h_tile - 1 ||
> + master_connector->tile_v_loc !=
> master_connector->num_v_tile - 1)
> + continue;
> + if (master_connector->tile_group->id != tile_group_id)
> + continue;
> +
> + master_conn_state =
> drm_atomic_get_connector_state(state,
> +
> master_connector);
> + if (IS_ERR(master_conn_state)) {
> + drm_connector_list_iter_end(_iter);
> + return PTR_ERR(master_conn_state);
> + }
> + if (master_conn_state->crtc) {
> + master_crtc = master_conn_state->crtc;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(_iter);
> +
> + if (!master_crtc) {
> + DRM_DEBUG_KMS("Could not find Master CRTC for Slave
> CRTC %d\n",
> +
Re: [Intel-gfx] [PATCH] drm/i915: Lock signaler timeline while navigating
On 17/09/2019 08:43, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 30 +++--
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f12358150097..452ad7a8ff0c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -767,16 +767,34 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(>link, >timeline->requests))
+ struct intel_timeline *tl = signal->timeline;
+ struct dma_fence *fence;
+ int err;
+
+ if (list_is_first(>link, >requests))
return 0;
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(rq->timeline, >fence))
+ if (mutex_lock_interruptible_nested(>mutex, SINGLE_DEPTH_NESTING))
We are getting more and more these nested ones and it will become
unmanageable to remember which ones, why and on what paths. Perhaps we
need a comment next to the member in the structure definition?
+ return -EINTR;
+
+ if (list_is_first(>link, >requests)) {
+ fence = NULL;
+ } else {
+ signal = list_prev_entry(signal, link);
+ fence = dma_fence_get_rcu(>fence);
+ }
+ mutex_unlock(>mutex);
+ if (!fence)
Can it be no fence when it was obtained under the mutex?
return 0;
- return i915_sw_fence_await_dma_fence(>submit,
->fence, 0,
-I915_FENCE_GFP);
+ err = 0;
+ if (!intel_timeline_sync_is_later(rq->timeline, fence))
+ err = i915_sw_fence_await_dma_fence(>submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/kms: Duct-tape for mode object lifetime checks
On 2019-09-17 2:09 p.m., Daniel Vetter wrote:
> commit 4f5368b5541a902f6596558b05f5c21a9770dd32
> Author: Daniel Vetter
> Date: Fri Jun 14 08:17:23 2019 +0200
>
> drm/kms: Catch mode_object lifetime errors
>
> uncovered a bit a mess in dp drivers. Most drivers (from a quick look,
> all except i915) register all the dp stuff in their init code, which
> is too early. With CONFIG_DRM_DP_AUX_CHARDEV this will blow up,
> because drm_dp_aux_register tries to add a child to a device in sysfs
> (the connector) which doesn't even exist yet.
>
> No one seems to have cared thus far. But with the above change I also
> moved the setting of dev->registered after the ->load callback, in an
> attempt to keep old drivers from hitting any WARN_ON backtraces. But
> that moved radeon.ko from the "working, by accident" to "now also
> broken" category.
>
> Since this is a huge mess I figured a revert would be simplest. But
> this check has already caught issues in i915:
>
> commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0
> Author: Ville Syrjälä
> Date: Tue Aug 20 19:16:57 2019 +0300
>
> drm/i915: Do not create a new max_bpc prop for MST connectors
>
> Hence I'd like to retain it. Fix the radeon regression by moving the
> setting of dev->registered back to were it was, and stop the
> backtraces with an explicit check for dev->driver->load.
>
> Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
> next patch will improve the kerneldoc and add a todo entry for this.
>
> Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors")
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Reported-by: Michel Dänzer
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
Reviewed-by: Michel Dänzer
Tested-by: Michel Dänzer
Thanks!
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
>> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am 03.09.19 um 10:05 schrieb Daniel Vetter:
On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> This patch is a stripped down version of the locking changes
> necessary to support dynamic DMA-buf handling.
>
> For compatibility we cache the DMA-buf mapping as soon as
> exporter/importer disagree on the dynamic handling.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 90
> ---
> include/linux/dma-buf.h | 51 +-
> 2 files changed, 133 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 433d91d710e4..65052d52602b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
> + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> + exp_info->ops->dynamic_mapping))
> + return ERR_PTR(-EINVAL);
> +
> if (!try_module_get(exp_info->owner))
> return ERR_PTR(-ENOENT);
> @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> EXPORT_SYMBOL_GPL(dma_buf_put);
> /**
> - * dma_buf_attach - Add the device to dma_buf's attachments
> list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's
> attachments list; optionally,
> * calls attach() of dma_buf_ops to allow device-specific
> attach functionality
> - * @dmabuf: [in] buffer to attach device to.
> - * @dev: [in] device to be attached.
> + * @dmabuf: [in] buffer to attach device to.
> + * @dev: [in] device to be attached.
> + * @dynamic_mapping: [in] calling convention for map/unmap
> *
> * Returns struct dma_buf_attachment pointer for this
> attachment. Attachments
> * must be cleaned up by calling dma_buf_detach().
> @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> * accessible to @dev, and cannot be moved to a more suitable
> place. This is
> * indicated with the error code -EBUSY.
> */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> - struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> + bool dynamic_mapping)
> {
> struct dma_buf_attachment *attach;
> int ret;
> @@ -677,6 +683,7 @@ struct dma_buf_attachment
> *dma_buf_attach(struct dma_buf *dmabuf,
> attach->dev = dev;
> attach->dmabuf = dmabuf;
> + attach->dynamic_mapping = dynamic_mapping;
> mutex_lock(>lock);
> @@ -685,16 +692,64 @@ struct dma_buf_attachment
> *dma_buf_attach(struct dma_buf *dmabuf,
> if (ret)
> goto err_attach;
> }
> + dma_resv_lock(dmabuf->resv, NULL);
> list_add(>node, >attachments);
> + dma_resv_unlock(dmabuf->resv);
> mutex_unlock(>lock);
> + /* When either the importer or the exporter can't handle
> dynamic
> + * mappings we cache the mapping here to avoid issues with the
> + * reservation object lock.
> + */
> + if (dma_buf_attachment_is_dynamic(attach) !=
> + dma_buf_is_dynamic(dmabuf)) {
> + struct sg_table *sgt;
> +
> + if (dma_buf_is_dynamic(attach->dmabuf))
> + dma_resv_lock(attach->dmabuf->resv, NULL);
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
Now we're back to enforcing DMA_BIDI, which works nicely around the
locking pain, but apparently upsets the arm-soc folks who want to
control
Re: [Intel-gfx] [PATCH] drm/i915: Only apply a rmw mmio update if the value changes
Chris Wilson writes:
> If we try to clear, or even set, a bit in the register that doesn't
> change the register state; skip the write. There's a slight danger in
> that the register acts as a latch-on-write, but I do not think we use a
> rmw cycle with any such latch registers.
>
> Suggested-by: Daniele Ceraolo Spurio
> Signed-off-by: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
My stance was that with clear ~0, user should be notified.
But I guess on this level of tooling, you should be free
to do the useless read.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_uncore.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h
> b/drivers/gpu/drm/i915/intel_uncore.h
> index 414fc2cb0459..dcfa243892c6 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -378,23 +378,23 @@ intel_uncore_read64_2x32(struct intel_uncore *uncore,
> static inline void intel_uncore_rmw(struct intel_uncore *uncore,
> i915_reg_t reg, u32 clear, u32 set)
> {
> - u32 val;
> + u32 old, val;
>
> - val = intel_uncore_read(uncore, reg);
> - val &= ~clear;
> - val |= set;
> - intel_uncore_write(uncore, reg, val);
> + old = intel_uncore_read(uncore, reg);
> + val = (old & ~clear) | set;
> + if (val != old)
> + intel_uncore_write(uncore, reg, val);
> }
>
> static inline void intel_uncore_rmw_fw(struct intel_uncore *uncore,
> i915_reg_t reg, u32 clear, u32 set)
> {
> - u32 val;
> + u32 old, val;
>
> - val = intel_uncore_read_fw(uncore, reg);
> - val &= ~clear;
> - val |= set;
> - intel_uncore_write_fw(uncore, reg, val);
> + old = intel_uncore_read_fw(uncore, reg);
> + val = (old & ~clear) | set;
> + if (val != old)
> + intel_uncore_write_fw(uncore, reg, val);
> }
>
> static inline int intel_uncore_write_and_verify(struct intel_uncore *uncore,
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
On Tue, Sep 17, 2019 at 01:24:10PM +, Koenig, Christian wrote:
> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> > On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> >> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> >>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> Ping? Any further comment on this or can't we merge at least the locking
> change?
> >>> I was at plumbers ...
> Christian.
>
> Am 11.09.19 um 12:53 schrieb Christian König:
> > Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> >> On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> >>> This patch is a stripped down version of the locking changes
> >>> necessary to support dynamic DMA-buf handling.
> >>>
> >>> For compatibility we cache the DMA-buf mapping as soon as
> >>> exporter/importer disagree on the dynamic handling.
> >>>
> >>> Signed-off-by: Christian König
> >>> ---
> >>> drivers/dma-buf/dma-buf.c | 90
> >>> ---
> >>> include/linux/dma-buf.h | 51 +-
> >>> 2 files changed, 133 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >>> index 433d91d710e4..65052d52602b 100644
> >>> --- a/drivers/dma-buf/dma-buf.c
> >>> +++ b/drivers/dma-buf/dma-buf.c
> >>> @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> >>> dma_buf_export_info *exp_info)
> >>> return ERR_PTR(-EINVAL);
> >>> }
> >>> + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> >>> + exp_info->ops->dynamic_mapping))
> >>> + return ERR_PTR(-EINVAL);
> >>> +
> >>> if (!try_module_get(exp_info->owner))
> >>> return ERR_PTR(-ENOENT);
> >>> @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> >>> EXPORT_SYMBOL_GPL(dma_buf_put);
> >>> /**
> >>> - * dma_buf_attach - Add the device to dma_buf's attachments
> >>> list; optionally,
> >>> + * dma_buf_dynamic_attach - Add the device to dma_buf's
> >>> attachments list; optionally,
> >>> * calls attach() of dma_buf_ops to allow device-specific
> >>> attach functionality
> >>> - * @dmabuf: [in] buffer to attach device to.
> >>> - * @dev: [in] device to be attached.
> >>> + * @dmabuf: [in] buffer to attach device to.
> >>> + * @dev: [in] device to be attached.
> >>> + * @dynamic_mapping: [in] calling convention for map/unmap
> >>> *
> >>> * Returns struct dma_buf_attachment pointer for this
> >>> attachment. Attachments
> >>> * must be cleaned up by calling dma_buf_detach().
> >>> @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> >>> * accessible to @dev, and cannot be moved to a more suitable
> >>> place. This is
> >>> * indicated with the error code -EBUSY.
> >>> */
> >>> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >>> - struct device *dev)
> >>> +struct dma_buf_attachment *
> >>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> >>> + bool dynamic_mapping)
> >>> {
> >>> struct dma_buf_attachment *attach;
> >>> int ret;
> >>> @@ -677,6 +683,7 @@ struct dma_buf_attachment
> >>> *dma_buf_attach(struct dma_buf *dmabuf,
> >>> attach->dev = dev;
> >>> attach->dmabuf = dmabuf;
> >>> + attach->dynamic_mapping = dynamic_mapping;
> >>> mutex_lock(>lock);
> >>> @@ -685,16 +692,64 @@ struct dma_buf_attachment
> >>> *dma_buf_attach(struct dma_buf *dmabuf,
> >>> if (ret)
> >>> goto err_attach;
> >>> }
> >>> + dma_resv_lock(dmabuf->resv, NULL);
> >>> list_add(>node, >attachments);
> >>> + dma_resv_unlock(dmabuf->resv);
> >>> mutex_unlock(>lock);
> >>> + /* When either the importer or the exporter can't handle
> >>> dynamic
> >>> + * mappings we cache the mapping here to avoid issues with the
> >>> + * reservation object lock.
> >>> + */
> >>> + if (dma_buf_attachment_is_dynamic(attach) !=
> >>> + dma_buf_is_dynamic(dmabuf)) {
> >>> + struct sg_table *sgt;
> >>> +
> >>> + if (dma_buf_is_dynamic(attach->dmabuf))
> >>> + dma_resv_lock(attach->dmabuf->resv, NULL);
> >>> +
> >>> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> >> Now we're back to enforcing DMA_BIDI, which works nicely around the
> >> locking pain, but apparently upsets the arm-soc folks who want to
> >> control
> >> this better.
> > Take another look at dma_buf_map_attachment(), we
Re: [Intel-gfx] [PATCH v1] drm/i915: Add TigerLake bandwidth checking
On Tue, Sep 17, 2019 at 04:00:57PM +0300, Stanislav Lisovskiy wrote:
> Added bandwidth calculation algorithm and checks,
> similar way as it was done for ICL, some constants
> were corrected according to BSpec.
>
> Signed-off-by: Stanislav Lisovskiy
>
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111600
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 108 +++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 688858ebe4d0..e97d083f4f2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -132,7 +132,8 @@ static int icl_sagv_max_dclk(const struct intel_qgv_info
> *qi)
> }
>
> struct intel_sa_info {
> - u8 deburst, mpagesize, deprogbwlimit, displayrtids;
> + u8 deburst, mpagesize, deprogbwlimit;
> + u16 displayrtids;
Put the u16 first to avoid holes in the middle of the struct.
> };
>
> static const struct intel_sa_info icl_sa_info = {
> @@ -142,6 +143,14 @@ static const struct intel_sa_info icl_sa_info = {
> .displayrtids = 128,
> };
>
> +static const struct intel_sa_info tgl_sa_info = {
> + .deburst = 16,
> + .mpagesize = 16,
> + .deprogbwlimit = 34, /* GB/s */
> + .displayrtids = 256,
> +};
> +
> +
> static int icl_get_bw_info(struct drm_i915_private *dev_priv)
> {
> struct intel_qgv_info qi = {};
> @@ -208,6 +217,74 @@ static int icl_get_bw_info(struct drm_i915_private
> *dev_priv)
> return 0;
> }
>
> +static int tgl_get_bw_info(struct drm_i915_private *dev_priv)
> +{
> + struct intel_qgv_info qi = {};
> + const struct intel_sa_info *sa = _sa_info;
> + bool is_y_tile = true; /* assume y tile may be used */
> + int num_channels;
> + int deinterleave;
> + int ipqdepth, ipqdepthpch;
> + int dclk_max;
> + int maxdebw;
> + int c3_derating = 10;
> + int c25_deprogbwpclimit = 60;
> + int i, ret;
> +
> + ret = icl_get_qgv_points(dev_priv, );
> + if (ret) {
> + DRM_DEBUG_KMS("Failed to get memory subsystem information,
> ignoring bandwidth limits");
> + return ret;
> + }
> + num_channels = qi.num_channels;
> +
> + deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
> + dclk_max = icl_sagv_max_dclk();
> +
> + ipqdepthpch = 16;
> +
> + maxdebw = min(sa->deprogbwlimit * 1000,
> + icl_calc_bw(dclk_max, 16 * c25_deprogbwpclimit, 100)); /*
> 60% */
> + ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
> +
> + for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
> + struct intel_bw_info *bi = _priv->max_bw[i];
> + int clpchgroup;
> + int j;
> +
> + clpchgroup = (sa->deburst * deinterleave / num_channels) << i;
> + bi->num_planes = (ipqdepth - clpchgroup) / clpchgroup;
> +
> + bi->num_qgv_points = qi.num_points;
> +
> + for (j = 0; j < qi.num_points; j++) {
> + const struct intel_qgv_point *sp = [j];
> + int ct, bw;
> +
> + /*
> + * Max row cycle time
> + *
> + * FIXME what is the logic behind the
> + * assumed burst length?
> + */
> + ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd +
> +(clpchgroup - 1) * qi.t_bl + sp->t_rdpre);
> + bw = icl_calc_bw(sp->dclk, clpchgroup * 32 *
> num_channels, ct);
> +
> + bi->deratedbw[j] = min(maxdebw,
> +bw * (100 - c3_derating) / 100);
> /* 90% */
> +
> + DRM_DEBUG_KMS("BW%d / QGV %d: num_planes=%d
> deratedbw=%u\n",
> + i, j, bi->num_planes, bi->deratedbw[j]);
> + }
> +
> + if (bi->num_planes == 1)
> + break;
> + }
We don't want to duplicate the entire function. Pretty much the
whole point of having the sa_info struct is to make this parametrized.
> +
> + return 0;
> +}
> +
> static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
> int num_planes, int qgv_point)
> {
> @@ -231,10 +308,35 @@ static unsigned int icl_max_bw(struct drm_i915_private
> *dev_priv,
> return 0;
> }
>
> +static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
> +int num_planes, int qgv_point)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
> + const struct intel_bw_info *bi =
> + _priv->max_bw[i];
> +
> + /*
> + * Pcode will not expose all QGV points when
> + * SAGV is forced to off/min/med/max.
> + */
> +
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Replace forked-mmaped tests with a lighter variant
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> Introduce a new 2-process fork test that is bound to a single cpu to
>> exercise contention during pagefaults. This is a much lighter variant of
>> the all-cpus test intended to be viable even on the legendary frozen
>> lakes of molasses.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
>> Signed-off-by: Chris Wilson
>> Cc: Mika Kuoppala
>> Cc: Martin Peres
>> ---
>> tests/i915/gem_mmap_gtt.c| 36 +---
>> tests/intel-ci/blacklist.txt | 2 +-
>> 2 files changed, 26 insertions(+), 12 deletions(-)
>>
>> diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
>> index ac439cdf8..0428a1372 100644
>> --- a/tests/i915/gem_mmap_gtt.c
>> +++ b/tests/i915/gem_mmap_gtt.c
>> @@ -792,9 +792,6 @@ test_huge_copy(int fd, int huge, int tiling_a, int
>> tiling_b, int ncpus)
>> uint64_t huge_object_size, i;
>> unsigned mode = CHECK_RAM;
>>
>> -igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
>> - "Please adjust your expectations,
>> https://bugs.freedesktop.org/show_bug.cgi?id=110882\n;);
>> -
>> switch (huge) {
>> case -2:
>> huge_object_size = gem_mappable_aperture_size() / 4;
>> @@ -1138,17 +1135,34 @@ igt_main
>> for (const struct copy_mode *m = copy_modes; m->suffix;
>> m++) {
>> igt_subtest_f("%s-copy%s", s->prefix, m->suffix)
>> test_huge_copy(fd,
>> -s->size,
>> -m->tiling_x,
>> -m->tiling_y,
>> -1);
>> + s->size,
>> + m->tiling_x,
>> + m->tiling_y,
>> + 1);
>> +
>> +igt_subtest_f("cpuset-%s-copy%s", s->prefix,
>> m->suffix) {
>> +cpu_set_t cpu, old;
>> +
>> +sched_getaffinity(0, sizeof(old), );
>> +
>> +CPU_ZERO();
>> +CPU_SET(0, );
>> +igt_assert(sched_setaffinity(0,
>> sizeof(cpu), ) == 0);
>> +test_huge_copy(fd,
>> + s->size,
>> + m->tiling_x,
>> + m->tiling_y,
>> + 2);
>> +
>> +igt_assert(sched_setaffinity(0,
>> sizeof(old), ) == 0);
>> +}
>>
>> igt_subtest_f("forked-%s-copy%s", s->prefix,
>> m->suffix)
>> test_huge_copy(fd,
>> -s->size,
>> -m->tiling_x,
>> -m->tiling_y,
>> -ncpus);
>> + s->size,
>> + m->tiling_x,
>> + m->tiling_y,
>> + ncpus);
>> }
>> }
>>
>> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
>> index 8e3dafa98..5fa91105f 100644
>> --- a/tests/intel-ci/blacklist.txt
>> +++ b/tests/intel-ci/blacklist.txt
>> @@ -47,7 +47,7 @@ igt@gem_gtt_hog(@.*)?
>> igt@gem_gtt_speed(@.*)?
>> igt@gem_hangcheck_forcewake(@.*)?
>> igt@gem_lut_handle(@.*)?
>> -igt@gem_mmap_gtt@.*(huge|swap|clflush).*
>> +igt@gem_mmap_gtt@.*(huge|swap|clflush|forked).*
>
> Dunno if this is enough for bat to pick it up. Regardless,
> patch does what it says, using 2 threads on single cpu.
>
> It should fly, even with maps of molasses.
Subtest cpuset-basic-small-copy: SUCCESS (2,965s)
Subtest cpuset-basic-small-copy-XY: SUCCESS (4,457s)
Subtest cpuset-big-copy-XY: SUCCESS (17,738s)
Subtest cpuset-medium-copy-XY: SUCCESS (8,871s)
-Mika
>
> Reviewed-by: Mika Kuoppala
>
>> igt@gem_mmap@.*(swap|huge).*
>> igt@gem_mocs_settings@.*(suspend|hibernate).*
>> igt@gem_pin(@.*)?
>> --
>> 2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Replace forked-mmaped tests with a lighter variant
Chris Wilson writes:
> Introduce a new 2-process fork test that is bound to a single cpu to
> exercise contention during pagefaults. This is a much lighter variant of
> the all-cpus test intended to be viable even on the legendary frozen
> lakes of molasses.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Martin Peres
> ---
> tests/i915/gem_mmap_gtt.c| 36 +---
> tests/intel-ci/blacklist.txt | 2 +-
> 2 files changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
> index ac439cdf8..0428a1372 100644
> --- a/tests/i915/gem_mmap_gtt.c
> +++ b/tests/i915/gem_mmap_gtt.c
> @@ -792,9 +792,6 @@ test_huge_copy(int fd, int huge, int tiling_a, int
> tiling_b, int ncpus)
> uint64_t huge_object_size, i;
> unsigned mode = CHECK_RAM;
>
> - igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
> - "Please adjust your expectations,
> https://bugs.freedesktop.org/show_bug.cgi?id=110882\n;);
> -
> switch (huge) {
> case -2:
> huge_object_size = gem_mappable_aperture_size() / 4;
> @@ -1138,17 +1135,34 @@ igt_main
> for (const struct copy_mode *m = copy_modes; m->suffix;
> m++) {
> igt_subtest_f("%s-copy%s", s->prefix, m->suffix)
> test_huge_copy(fd,
> - s->size,
> - m->tiling_x,
> - m->tiling_y,
> - 1);
> +s->size,
> +m->tiling_x,
> +m->tiling_y,
> +1);
> +
> + igt_subtest_f("cpuset-%s-copy%s", s->prefix,
> m->suffix) {
> + cpu_set_t cpu, old;
> +
> + sched_getaffinity(0, sizeof(old), );
> +
> + CPU_ZERO();
> + CPU_SET(0, );
> + igt_assert(sched_setaffinity(0,
> sizeof(cpu), ) == 0);
> + test_huge_copy(fd,
> +s->size,
> +m->tiling_x,
> +m->tiling_y,
> +2);
> +
> + igt_assert(sched_setaffinity(0,
> sizeof(old), ) == 0);
> + }
>
> igt_subtest_f("forked-%s-copy%s", s->prefix,
> m->suffix)
> test_huge_copy(fd,
> - s->size,
> - m->tiling_x,
> - m->tiling_y,
> - ncpus);
> +s->size,
> +m->tiling_x,
> +m->tiling_y,
> +ncpus);
> }
> }
>
> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> index 8e3dafa98..5fa91105f 100644
> --- a/tests/intel-ci/blacklist.txt
> +++ b/tests/intel-ci/blacklist.txt
> @@ -47,7 +47,7 @@ igt@gem_gtt_hog(@.*)?
> igt@gem_gtt_speed(@.*)?
> igt@gem_hangcheck_forcewake(@.*)?
> igt@gem_lut_handle(@.*)?
> -igt@gem_mmap_gtt@.*(huge|swap|clflush).*
> +igt@gem_mmap_gtt@.*(huge|swap|clflush|forked).*
Dunno if this is enough for bat to pick it up. Regardless,
patch does what it says, using 2 threads on single cpu.
It should fly, even with maps of molasses.
Reviewed-by: Mika Kuoppala
> igt@gem_mmap@.*(swap|huge).*
> igt@gem_mocs_settings@.*(suspend|hibernate).*
> igt@gem_pin(@.*)?
> --
> 2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/kms: Duct-tape for mode object lifetime checks
== Series Details ==
Series: series starting with [1/2] drm/kms: Duct-tape for mode object lifetime
checks
URL : https://patchwork.freedesktop.org/series/66812/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6908 -> Patchwork_14429
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/
Known issues
Here are the changes found in Patchwork_14429 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#08])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#109483])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u2/igt@kms_chamel...@hdmi-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-icl-u2/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@prime_busy@basic-wait-after-default:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
Possible fixes
* igt@gem_exec_fence@nb-await-default:
- {fi-tgl-u}: [WARN][9] ([fdo#111597]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (55 -> 47)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-bdw-samus fi-byt-clapper fi-skl-6700k2
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6908 -> Patchwork_14429
CI-20190529: 20190529
CI_DRM_6908: c09b47830224c06546b73417085f7c6880a3995a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5188: 933b84d5585698e15542ea1c5627d5d8d63ce230 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14429: b54d85a3890c61287745d72ef52f6ca4075564d5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b54d85a3890c drm/doc: Improve docs around connector (un)registration
ae5a3497bdd7 drm/kms: Duct-tape for mode object lifetime checks
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14429/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
>> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
>>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
Ping? Any further comment on this or can't we merge at least the locking
change?
>>> I was at plumbers ...
Christian.
Am 11.09.19 um 12:53 schrieb Christian König:
> Am 03.09.19 um 10:05 schrieb Daniel Vetter:
>> On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
>>> This patch is a stripped down version of the locking changes
>>> necessary to support dynamic DMA-buf handling.
>>>
>>> For compatibility we cache the DMA-buf mapping as soon as
>>> exporter/importer disagree on the dynamic handling.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/dma-buf/dma-buf.c | 90
>>> ---
>>> include/linux/dma-buf.h | 51 +-
>>> 2 files changed, 133 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 433d91d710e4..65052d52602b 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
>>> dma_buf_export_info *exp_info)
>>> return ERR_PTR(-EINVAL);
>>> }
>>> + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
>>> + exp_info->ops->dynamic_mapping))
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> if (!try_module_get(exp_info->owner))
>>> return ERR_PTR(-ENOENT);
>>> @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
>>> EXPORT_SYMBOL_GPL(dma_buf_put);
>>> /**
>>> - * dma_buf_attach - Add the device to dma_buf's attachments
>>> list; optionally,
>>> + * dma_buf_dynamic_attach - Add the device to dma_buf's
>>> attachments list; optionally,
>>> * calls attach() of dma_buf_ops to allow device-specific
>>> attach functionality
>>> - * @dmabuf: [in] buffer to attach device to.
>>> - * @dev: [in] device to be attached.
>>> + * @dmabuf: [in] buffer to attach device to.
>>> + * @dev: [in] device to be attached.
>>> + * @dynamic_mapping: [in] calling convention for map/unmap
>>> *
>>> * Returns struct dma_buf_attachment pointer for this
>>> attachment. Attachments
>>> * must be cleaned up by calling dma_buf_detach().
>>> @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>>> * accessible to @dev, and cannot be moved to a more suitable
>>> place. This is
>>> * indicated with the error code -EBUSY.
>>> */
>>> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>>> - struct device *dev)
>>> +struct dma_buf_attachment *
>>> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
>>> + bool dynamic_mapping)
>>> {
>>> struct dma_buf_attachment *attach;
>>> int ret;
>>> @@ -677,6 +683,7 @@ struct dma_buf_attachment
>>> *dma_buf_attach(struct dma_buf *dmabuf,
>>> attach->dev = dev;
>>> attach->dmabuf = dmabuf;
>>> + attach->dynamic_mapping = dynamic_mapping;
>>> mutex_lock(>lock);
>>> @@ -685,16 +692,64 @@ struct dma_buf_attachment
>>> *dma_buf_attach(struct dma_buf *dmabuf,
>>> if (ret)
>>> goto err_attach;
>>> }
>>> + dma_resv_lock(dmabuf->resv, NULL);
>>> list_add(>node, >attachments);
>>> + dma_resv_unlock(dmabuf->resv);
>>> mutex_unlock(>lock);
>>> + /* When either the importer or the exporter can't handle
>>> dynamic
>>> + * mappings we cache the mapping here to avoid issues with the
>>> + * reservation object lock.
>>> + */
>>> + if (dma_buf_attachment_is_dynamic(attach) !=
>>> + dma_buf_is_dynamic(dmabuf)) {
>>> + struct sg_table *sgt;
>>> +
>>> + if (dma_buf_is_dynamic(attach->dmabuf))
>>> + dma_resv_lock(attach->dmabuf->resv, NULL);
>>> +
>>> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
>> Now we're back to enforcing DMA_BIDI, which works nicely around the
>> locking pain, but apparently upsets the arm-soc folks who want to
>> control
>> this better.
> Take another look at dma_buf_map_attachment(), we still try to get the
> caching there for ARM.
>
> What we do here is to bidirectionally map the buffer to avoid the
> locking hydra when importer and exporter disagree on locking.
>
> So the ARM folks can easily avoid that by switching to dynamic
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Extend MI_SEMAPHORE_WAIT
Chris Wilson writes:
> On Tigerlake, MI_SEMAPHORE_WAIT grew an extra dword, so be sure to
> update the length field and emit that extra parameter and any padding
> noop as required.
>
> v2: Define the token shift while we are adding the updated MI_SEMAPHORE_WAIT
> v3: Use int instead of bool in the addition so that readers are not left
> wondering about the intricacies of the C spec. Now they just have to
> worry what the integer value of a boolean operation is...
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> Cc: Michal Winiarski
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 3 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 71 ++--
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> drivers/gpu/drm/i915/i915_request.c | 21 --
> 4 files changed, 84 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index fbad403ab7ac..f78b13d74e17 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -112,6 +112,7 @@
> #define MI_SEMAPHORE_SIGNAL MI_INSTR(0x1b, 0) /* GEN8+ */
> #define MI_SEMAPHORE_TARGET(engine)((engine)<<15)
> #define MI_SEMAPHORE_WAITMI_INSTR(0x1c, 2) /* GEN8+ */
> +#define MI_SEMAPHORE_WAIT_TOKEN MI_INSTR(0x1c, 3) /* GEN12+ */
> #define MI_SEMAPHORE_POLL (1 << 15)
> #define MI_SEMAPHORE_SAD_GT_SDD(0 << 12)
> #define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
> @@ -119,6 +120,8 @@
> #define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
> #define MI_SEMAPHORE_SAD_EQ_SDD(4 << 12)
> #define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
> +#define MI_SEMAPHORE_TOKEN_MASKREG_GENMASK(9, 5)
> +#define MI_SEMAPHORE_TOKEN_SHIFT 5
> #define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
> #define MI_STORE_DWORD_IMM_GEN4 MI_INSTR(0x20, 2)
> #define MI_MEM_VIRTUAL (1 << 22) /* 945,g33,965 */
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index a3f0e4999744..a99166a2d2eb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2879,6 +2879,22 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
> i915_request *request, u32 *cs)
> return gen8_emit_fini_breadcrumb_footer(request, cs);
> }
>
> +static u32 *
> +gen11_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs)
> +{
> + cs = gen8_emit_ggtt_write_rcs(cs,
> + request->fence.seqno,
> + request->timeline->hwsp_offset,
> + PIPE_CONTROL_CS_STALL |
> + PIPE_CONTROL_TILE_CACHE_FLUSH |
> + PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> + PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> + PIPE_CONTROL_DC_FLUSH_ENABLE |
> + PIPE_CONTROL_FLUSH_ENABLE);
> +
> + return gen8_emit_fini_breadcrumb_footer(request, cs);
> +}
> +
> /*
> * Note that the CS instruction pre-parser will not stall on the breadcrumb
> * flush and will continue pre-fetching the instructions after it before the
> @@ -2897,8 +2913,49 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
> i915_request *request, u32 *cs)
> * All the above applies only to the instructions themselves. Non-inline data
> * used by the instructions is not pre-fetched.
> */
> -static u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *request,
> -u32 *cs)
> +
> +static u32 *gen12_emit_preempt_busywait(struct i915_request *request, u32
> *cs)
> +{
> + *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
> + MI_SEMAPHORE_GLOBAL_GTT |
> + MI_SEMAPHORE_POLL |
> + MI_SEMAPHORE_SAD_EQ_SDD;
> + *cs++ = 0;
> + *cs++ = intel_hws_preempt_address(request->engine);
> + *cs++ = 0;
> + *cs++ = 0;
> + *cs++ = MI_NOOP;
> +
> + return cs;
> +}
> +
> +static __always_inline u32*
> +gen12_emit_fini_breadcrumb_footer(struct i915_request *request, u32 *cs)
> +{
> + *cs++ = MI_USER_INTERRUPT;
> +
> + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> + if (intel_engine_has_semaphores(request->engine))
> + cs = gen12_emit_preempt_busywait(request, cs);
> +
> + request->tail = intel_ring_offset(request, cs);
> + assert_ring_tail_valid(request->ring, request->tail);
> +
> + return gen8_emit_wa_tail(request, cs);
> +}
> +
> +static u32 *gen12_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
> +{
> + cs = gen8_emit_ggtt_write(cs,
> + request->fence.seqno,
> + request->timeline->hwsp_offset,
> + 0);
> +
> + return
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> > On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> >> Ping? Any further comment on this or can't we merge at least the locking
> >> change?
> > I was at plumbers ...
> >> Christian.
> >>
> >> Am 11.09.19 um 12:53 schrieb Christian König:
> >>> Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> > This patch is a stripped down version of the locking changes
> > necessary to support dynamic DMA-buf handling.
> >
> > For compatibility we cache the DMA-buf mapping as soon as
> > exporter/importer disagree on the dynamic handling.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/dma-buf/dma-buf.c | 90
> > ---
> > include/linux/dma-buf.h | 51 +-
> > 2 files changed, 133 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 433d91d710e4..65052d52602b 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> > dma_buf_export_info *exp_info)
> > return ERR_PTR(-EINVAL);
> > }
> > + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> > + exp_info->ops->dynamic_mapping))
> > + return ERR_PTR(-EINVAL);
> > +
> > if (!try_module_get(exp_info->owner))
> > return ERR_PTR(-ENOENT);
> > @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> > EXPORT_SYMBOL_GPL(dma_buf_put);
> > /**
> > - * dma_buf_attach - Add the device to dma_buf's attachments
> > list; optionally,
> > + * dma_buf_dynamic_attach - Add the device to dma_buf's
> > attachments list; optionally,
> > * calls attach() of dma_buf_ops to allow device-specific
> > attach functionality
> > - * @dmabuf: [in] buffer to attach device to.
> > - * @dev: [in] device to be attached.
> > + * @dmabuf: [in] buffer to attach device to.
> > + * @dev: [in] device to be attached.
> > + * @dynamic_mapping: [in] calling convention for map/unmap
> > *
> > * Returns struct dma_buf_attachment pointer for this
> > attachment. Attachments
> > * must be cleaned up by calling dma_buf_detach().
> > @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> > * accessible to @dev, and cannot be moved to a more suitable
> > place. This is
> > * indicated with the error code -EBUSY.
> > */
> > -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > - struct device *dev)
> > +struct dma_buf_attachment *
> > +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> > + bool dynamic_mapping)
> > {
> > struct dma_buf_attachment *attach;
> > int ret;
> > @@ -677,6 +683,7 @@ struct dma_buf_attachment
> > *dma_buf_attach(struct dma_buf *dmabuf,
> > attach->dev = dev;
> > attach->dmabuf = dmabuf;
> > + attach->dynamic_mapping = dynamic_mapping;
> > mutex_lock(>lock);
> > @@ -685,16 +692,64 @@ struct dma_buf_attachment
> > *dma_buf_attach(struct dma_buf *dmabuf,
> > if (ret)
> > goto err_attach;
> > }
> > + dma_resv_lock(dmabuf->resv, NULL);
> > list_add(>node, >attachments);
> > + dma_resv_unlock(dmabuf->resv);
> > mutex_unlock(>lock);
> > + /* When either the importer or the exporter can't handle dynamic
> > + * mappings we cache the mapping here to avoid issues with the
> > + * reservation object lock.
> > + */
> > + if (dma_buf_attachment_is_dynamic(attach) !=
> > + dma_buf_is_dynamic(dmabuf)) {
> > + struct sg_table *sgt;
> > +
> > + if (dma_buf_is_dynamic(attach->dmabuf))
> > + dma_resv_lock(attach->dmabuf->resv, NULL);
> > +
> > + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> Now we're back to enforcing DMA_BIDI, which works nicely around the
> locking pain, but apparently upsets the arm-soc folks who want to
> control
> this better.
> >>> Take another look at dma_buf_map_attachment(), we still try to get the
> >>> caching there for ARM.
> >>>
> >>> What we do here is to bidirectionally map the buffer to avoid the
> >>> locking hydra when importer and exporter disagree on locking.
> >>>
> >>> So the ARM folks can easily avoid that by switching to dynamic locking
> >>> for both.
> > So you still break the contract between importer and exporter,
[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Replace forked-mmaped tests with a lighter variant
Introduce a new 2-process fork test that is bound to a single cpu to
exercise contention during pagefaults. This is a much lighter variant of
the all-cpus test intended to be viable even on the legendary frozen
lakes of molasses.
References: https://bugs.freedesktop.org/show_bug.cgi?id=110882
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Martin Peres
---
tests/i915/gem_mmap_gtt.c| 36 +---
tests/intel-ci/blacklist.txt | 2 +-
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index ac439cdf8..0428a1372 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -792,9 +792,6 @@ test_huge_copy(int fd, int huge, int tiling_a, int
tiling_b, int ncpus)
uint64_t huge_object_size, i;
unsigned mode = CHECK_RAM;
- igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1,
- "Please adjust your expectations,
https://bugs.freedesktop.org/show_bug.cgi?id=110882\n;);
-
switch (huge) {
case -2:
huge_object_size = gem_mappable_aperture_size() / 4;
@@ -1138,17 +1135,34 @@ igt_main
for (const struct copy_mode *m = copy_modes; m->suffix;
m++) {
igt_subtest_f("%s-copy%s", s->prefix, m->suffix)
test_huge_copy(fd,
- s->size,
- m->tiling_x,
- m->tiling_y,
- 1);
+ s->size,
+ m->tiling_x,
+ m->tiling_y,
+ 1);
+
+ igt_subtest_f("cpuset-%s-copy%s", s->prefix,
m->suffix) {
+ cpu_set_t cpu, old;
+
+ sched_getaffinity(0, sizeof(old), );
+
+ CPU_ZERO();
+ CPU_SET(0, );
+ igt_assert(sched_setaffinity(0,
sizeof(cpu), ) == 0);
+ test_huge_copy(fd,
+ s->size,
+ m->tiling_x,
+ m->tiling_y,
+ 2);
+
+ igt_assert(sched_setaffinity(0,
sizeof(old), ) == 0);
+ }
igt_subtest_f("forked-%s-copy%s", s->prefix,
m->suffix)
test_huge_copy(fd,
- s->size,
- m->tiling_x,
- m->tiling_y,
- ncpus);
+ s->size,
+ m->tiling_x,
+ m->tiling_y,
+ ncpus);
}
}
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index 8e3dafa98..5fa91105f 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -47,7 +47,7 @@ igt@gem_gtt_hog(@.*)?
igt@gem_gtt_speed(@.*)?
igt@gem_hangcheck_forcewake(@.*)?
igt@gem_lut_handle(@.*)?
-igt@gem_mmap_gtt@.*(huge|swap|clflush).*
+igt@gem_mmap_gtt@.*(huge|swap|clflush|forked).*
igt@gem_mmap@.*(swap|huge).*
igt@gem_mocs_settings@.*(suspend|hibernate).*
igt@gem_pin(@.*)?
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/kms: Duct-tape for mode object lifetime checks
== Series Details ==
Series: series starting with [1/2] drm/kms: Duct-tape for mode object lifetime
checks
URL : https://patchwork.freedesktop.org/series/66812/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ae5a3497bdd7 drm/kms: Duct-tape for mode object lifetime checks
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 4f5368b5541a ("drm/kms: Catch
mode_object lifetime errors")'
#9:
commit 4f5368b5541a902f6596558b05f5c21a9770dd32
-:30: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 1b9bd09630d4 ("drm/i915: Do not
create a new max_bpc prop for MST connectors")'
#30:
commit 1b9bd09630d4db4827cc04d358a41a16a6bc2cb0
-:92: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 2 errors, 1 warnings, 0 checks, 32 lines checked
b54d85a3890c drm/doc: Improve docs around connector (un)registration
-:84: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 54 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Add TigerLake bandwidth checking
Added bandwidth calculation algorithm and checks,
similar way as it was done for ICL, some constants
were corrected according to BSpec.
Signed-off-by: Stanislav Lisovskiy
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111600
---
drivers/gpu/drm/i915/display/intel_bw.c | 108 +++-
1 file changed, 107 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 688858ebe4d0..e97d083f4f2a 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -132,7 +132,8 @@ static int icl_sagv_max_dclk(const struct intel_qgv_info
*qi)
}
struct intel_sa_info {
- u8 deburst, mpagesize, deprogbwlimit, displayrtids;
+ u8 deburst, mpagesize, deprogbwlimit;
+ u16 displayrtids;
};
static const struct intel_sa_info icl_sa_info = {
@@ -142,6 +143,14 @@ static const struct intel_sa_info icl_sa_info = {
.displayrtids = 128,
};
+static const struct intel_sa_info tgl_sa_info = {
+ .deburst = 16,
+ .mpagesize = 16,
+ .deprogbwlimit = 34, /* GB/s */
+ .displayrtids = 256,
+};
+
+
static int icl_get_bw_info(struct drm_i915_private *dev_priv)
{
struct intel_qgv_info qi = {};
@@ -208,6 +217,74 @@ static int icl_get_bw_info(struct drm_i915_private
*dev_priv)
return 0;
}
+static int tgl_get_bw_info(struct drm_i915_private *dev_priv)
+{
+ struct intel_qgv_info qi = {};
+ const struct intel_sa_info *sa = _sa_info;
+ bool is_y_tile = true; /* assume y tile may be used */
+ int num_channels;
+ int deinterleave;
+ int ipqdepth, ipqdepthpch;
+ int dclk_max;
+ int maxdebw;
+ int c3_derating = 10;
+ int c25_deprogbwpclimit = 60;
+ int i, ret;
+
+ ret = icl_get_qgv_points(dev_priv, );
+ if (ret) {
+ DRM_DEBUG_KMS("Failed to get memory subsystem information,
ignoring bandwidth limits");
+ return ret;
+ }
+ num_channels = qi.num_channels;
+
+ deinterleave = DIV_ROUND_UP(num_channels, is_y_tile ? 4 : 2);
+ dclk_max = icl_sagv_max_dclk();
+
+ ipqdepthpch = 16;
+
+ maxdebw = min(sa->deprogbwlimit * 1000,
+ icl_calc_bw(dclk_max, 16 * c25_deprogbwpclimit, 100)); /*
60% */
+ ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
+
+ for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
+ struct intel_bw_info *bi = _priv->max_bw[i];
+ int clpchgroup;
+ int j;
+
+ clpchgroup = (sa->deburst * deinterleave / num_channels) << i;
+ bi->num_planes = (ipqdepth - clpchgroup) / clpchgroup;
+
+ bi->num_qgv_points = qi.num_points;
+
+ for (j = 0; j < qi.num_points; j++) {
+ const struct intel_qgv_point *sp = [j];
+ int ct, bw;
+
+ /*
+* Max row cycle time
+*
+* FIXME what is the logic behind the
+* assumed burst length?
+*/
+ ct = max_t(int, sp->t_rc, sp->t_rp + sp->t_rcd +
+ (clpchgroup - 1) * qi.t_bl + sp->t_rdpre);
+ bw = icl_calc_bw(sp->dclk, clpchgroup * 32 *
num_channels, ct);
+
+ bi->deratedbw[j] = min(maxdebw,
+ bw * (100 - c3_derating) / 100);
/* 90% */
+
+ DRM_DEBUG_KMS("BW%d / QGV %d: num_planes=%d
deratedbw=%u\n",
+ i, j, bi->num_planes, bi->deratedbw[j]);
+ }
+
+ if (bi->num_planes == 1)
+ break;
+ }
+
+ return 0;
+}
+
static unsigned int icl_max_bw(struct drm_i915_private *dev_priv,
int num_planes, int qgv_point)
{
@@ -231,10 +308,35 @@ static unsigned int icl_max_bw(struct drm_i915_private
*dev_priv,
return 0;
}
+static unsigned int tgl_max_bw(struct drm_i915_private *dev_priv,
+ int num_planes, int qgv_point)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(dev_priv->max_bw); i++) {
+ const struct intel_bw_info *bi =
+ _priv->max_bw[i];
+
+ /*
+* Pcode will not expose all QGV points when
+* SAGV is forced to off/min/med/max.
+*/
+ if (qgv_point >= bi->num_qgv_points)
+ return UINT_MAX;
+
+ if (num_planes >= bi->num_planes)
+ return bi->deratedbw[qgv_point];
+ }
+
+ return 0;
+}
+
void intel_bw_init_hw(struct drm_i915_private *dev_priv)
{
if (IS_GEN(dev_priv, 11))
icl_get_bw_info(dev_priv);
+ else if (IS_GEN(dev_priv, 12))
[Intel-gfx] ✗ Fi.CI.BAT: failure for adding gamma state checker for icl+ platforms
== Series Details ==
Series: adding gamma state checker for icl+ platforms
URL : https://patchwork.freedesktop.org/series/66811/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6908 -> Patchwork_14428
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14428 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14428, 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_14428/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14428:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_gem_contexts:
- fi-kbl-x1275: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-kbl-x1275/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/fi-kbl-x1275/igt@i915_selftest@live_gem_contexts.html
Known issues
Here are the changes found in Patchwork_14428 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_fence_blits@basic:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u3/igt@gem_tiled_fence_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/fi-icl-u3/igt@gem_tiled_fence_bl...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
Warnings
* igt@i915_module_load@reload:
- fi-icl-u2: [DMESG-WARN][9] ([fdo#110595] / [fdo#111214]) ->
[DMESG-WARN][10] ([fdo#106107] / [fdo#110595] / [fdo#111214])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6908/fi-icl-u2/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/fi-icl-u2/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (55 -> 48)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6908 -> Patchwork_14428
CI-20190529: 20190529
CI_DRM_6908: c09b47830224c06546b73417085f7c6880a3995a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5188: 933b84d5585698e15542ea1c5627d5d8d63ce230 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14428: 903306d33c88e3bc4bdf0818d006d823effbf253 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
903306d33c88 drm/i915/display: Extract icl_read_luts()
2da6cea43f48 drm/i915/display: Fix formatting issues
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14428/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2][PATCH 1/3] drm/i915/display: Fix formatting issues
Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/display/intel_color.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 318308d..b1f0f7e 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -807,11 +807,11 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color) u32 i; /* -* Every entry in the multi-segment LUT is corresponding to a superfine -* segment step which is 1/(8 * 128 * 256). +* Program Super Fine segment (let's call it seg1)... * -* Superfine segment has 9 entries, corresponding to values -* 0, 1/(8 * 128 * 256), 2/(8 * 128 * 256) 8/(8 * 128 * 256). +* Super Fine segment's step is 1/(8 * 128 * 256) and it has +* 9 entries, corresponding to values 0, 1/(8 * 128 * 256), +* 2/(8 * 128 * 256) ... 8/(8 * 128 * 256). */ I915_WRITE(PREC_PAL_MULTI_SEG_INDEX(pipe), PAL_PREC_AUTO_INCREMENT); @@ -837,10 +837,9 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color) u32 i; /* -* * Program Fine segment (let's call it seg2)... * -* Fine segment's step is 1/(128 * 256) ie 1/(128 * 256), 2/(128*256) +* Fine segment's step is 1/(128 * 256) i.e. 1/(128 * 256), 2/(128*256) * ... 256/(128*256). So in order to program fine segment of LUT we * need to pick every 8'th entry in LUT, and program 256 indexes. * @@ -858,7 +857,7 @@ static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color) * Program Coarse segment (let's call it seg3)... * * Coarse segment's starts from index 0 and it's step is 1/256 ie 0, -* 1/256, 2/256 ...256/256. As per the description of each entry in LUT +* 1/256, 2/256 ... 256/256. As per the description of each entry in LUT * above, we need to pick every (8 * 128)th entry in LUT, and * program 256 of those. * @@ -890,12 +889,10 @@ static void icl_load_luts(const struct intel_crtc_state *crtc_state) case GAMMA_MODE_MODE_8BIT: i9xx_load_luts(crtc_state); break; - case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED: icl_program_gamma_superfine_segment(crtc_state); icl_program_gamma_multi_segment(crtc_state); break; - default: bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0)); ivb_load_lut_ext_max(crtc); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2][PATCH 3/3] FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 0008011..4bf098f 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1474,6 +1474,8 @@ int intel_color_get_gamma_bit_precision(const struct
intel_crtc_state *crtc_stat
static bool err_check(struct drm_color_lut *lut1,
struct drm_color_lut *lut2, u32 err)
{
+ DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x
sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", lut2->red, lut1->red,
lut2->blue, lut1->blue, lut2->green, lut1->green);
+
return ((abs((long)lut2->red - lut1->red)) <= err) &&
((abs((long)lut2->blue - lut1->blue)) <= err) &&
((abs((long)lut2->green - lut1->green)) <= err);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2][PATCH 0/3] adding gamma state checker for icl+ platforms
In this patch series, added state checker to validate gamma lut values for icelake+ platforms. It's extension of the patch series https://patchwork.freedesktop.org/patch/328246/?series=58039 which enabled the basic infrastructure and state checker for legacy platforms. Swati Sharma (3): drm/i915/display: Fix formatting issues drm/i915/display: Extract icl_read_luts() FOR_TESTING_ONLY: Print rgb values of hw and sw blobs drivers/gpu/drm/i915/display/intel_color.c | 260 + drivers/gpu/drm/i915/i915_reg.h| 7 + 2 files changed, 238 insertions(+), 29 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2][PATCH 2/3] drm/i915/display: Extract icl_read_luts()
For icl+, have hw read out to create hw blob of gamma
lut values. icl+ platforms supports multi segmented gamma
mode, add hw lut creation for this mode.
This will be used to validate gamma programming using dsb
(display state buffer) which is a tgl feature.
v2: -readout code for multisegmented gamma has to come
up with some intermediate entries that aren't preserved
in hardware (Jani N)
-linear interpolation (Ville)
-moved common code to check gamma_enable to specific funcs,
since icl doesn't support that
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_color.c | 243 ++---
drivers/gpu/drm/i915/i915_reg.h| 7 +
2 files changed, 230 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index b1f0f7e..0008011 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1370,6 +1370,9 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)
{
+ if (!crtc_state->gamma_enable)
+ return 0;
+
switch (crtc_state->gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
@@ -1383,6 +1386,9 @@ static int i9xx_gamma_precision(const struct
intel_crtc_state *crtc_state)
static int ilk_gamma_precision(const struct intel_crtc_state *crtc_state)
{
+ if (!crtc_state->gamma_enable)
+ return 0;
+
if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0)
return 0;
@@ -1399,6 +1405,9 @@ static int ilk_gamma_precision(const struct
intel_crtc_state *crtc_state)
static int chv_gamma_precision(const struct intel_crtc_state *crtc_state)
{
+ if (!crtc_state->gamma_enable)
+ return 0;
+
if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA)
return 10;
else
@@ -1407,6 +1416,9 @@ static int chv_gamma_precision(const struct
intel_crtc_state *crtc_state)
static int glk_gamma_precision(const struct intel_crtc_state *crtc_state)
{
+ if (!crtc_state->gamma_enable)
+ return 0;
+
switch (crtc_state->gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
return 8;
@@ -1418,21 +1430,39 @@ static int glk_gamma_precision(const struct
intel_crtc_state *crtc_state)
}
}
+static int icl_gamma_precision(const struct intel_crtc_state *crtc_state)
+{
+ if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
+ return 0;
+
+ switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
+ case GAMMA_MODE_MODE_8BIT:
+ return 8;
+ case GAMMA_MODE_MODE_10BIT:
+ return 10;
+ case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
+ return 16;
+ default:
+ MISSING_CASE(crtc_state->gamma_mode);
+ return 0;
+ }
+
+}
+
int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- if (!crtc_state->gamma_enable)
- return 0;
-
if (HAS_GMCH(dev_priv)) {
if (IS_CHERRYVIEW(dev_priv))
return chv_gamma_precision(crtc_state);
else
return i9xx_gamma_precision(crtc_state);
} else {
- if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 11)
+ return icl_gamma_precision(crtc_state);
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
return glk_gamma_precision(crtc_state);
else if (IS_IRONLAKE(dev_priv))
return ilk_gamma_precision(crtc_state);
@@ -1463,6 +1493,30 @@ static bool intel_color_lut_entry_equal(struct
drm_color_lut *lut1,
return true;
}
+static bool intel_color_lut_entry_multi_equal(struct drm_color_lut *lut1,
+ struct drm_color_lut *lut2,
+ int lut_size, u32 err)
+{
+ int i;
+
+ for (i = 0; i < 9; i++) {
+ if (!err_check([i], [i], err))
+ return false;
+ }
+
+ for (i = 1; i < 257; i++) {
+ if (!err_check([i * 8], [i * 8], err))
+ return false;
+ }
+
+ for (i = 0; i < 256; i++) {
+ if (!err_check([i * 8 * 128], [i * 8 * 128], err))
+ return false;
+ }
+
+ return true;
+}
+
bool intel_color_lut_equal(struct drm_property_blob *blob1,
struct drm_property_blob *blob2,
u32 gamma_mode, u32 bit_precision)
@@
Re: [Intel-gfx] [RFC PATCH 2/2] mdev: introduce device specific ops
On Thu, 12 Sep 2019 17:40:12 +0800
Jason Wang wrote:
> Currently, except for the crate and remove. The rest fields of
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch introduces device specific ops which points to
> device specific ops (e.g vfio ops). This allows the future drivers
> like virtio-mdev to implement its own device specific ops.
>
> Signed-off-by: Jason Wang
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 14 +++---
> drivers/s390/cio/vfio_ccw_ops.c | 14 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 10 +++--
> drivers/vfio/mdev/vfio_mdev.c | 30 +++--
> include/linux/mdev.h | 72 ++-
> samples/vfio-mdev/mbochs.c| 16 ---
> samples/vfio-mdev/mdpy.c | 16 ---
> samples/vfio-mdev/mtty.c | 14 +++---
> 8 files changed, 113 insertions(+), 73 deletions(-)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index f85045392120..3b8a76bc69cf 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -27,27 +27,9 @@ int mdev_set_iommu_device(struct device *dev, struct
> device *iommu_device);
> struct device *mdev_get_iommu_device(struct device *dev);
>
> /**
> - * struct mdev_parent_ops - Structure to be registered for each parent
> device to
> - * register the device to mdev module.
> + * struct vfio_mdev_parent_ops - Structure to be registered for each
> + * parent device to register the device to vfio-mdev module.
> *
> - * @owner: The module owner.
> - * @dev_attr_groups: Attributes of the parent device.
> - * @mdev_attr_groups:Attributes of the mediated device.
> - * @supported_type_groups: Attributes to define supported types. It is
> mandatory
> - * to provide supported types.
> - * @create: Called to allocate basic resources in parent device's
> - * driver for a particular mediated device. It is
> - * mandatory to provide create ops.
> - * @kobj: kobject of type for which 'create' is called.
> - * @mdev: mdev_device structure on of mediated device
> - * that is being created
> - * Returns integer: success (0) or error (< 0)
> - * @remove: Called to free resources in parent device's driver for a
> - * a mediated device. It is mandatory to provide 'remove'
> - * ops.
> - * @mdev: mdev_device device structure which is being
> - * destroyed
> - * Returns integer: success (0) or error (< 0)
> * @open:Open mediated device.
> * @mdev: mediated device.
> * Returns integer: success (0) or error (< 0)
> @@ -72,6 +54,43 @@ struct device *mdev_get_iommu_device(struct device *dev);
> * @mmap:mmap callback
> * @mdev: mediated device structure
> * @vma: vma structure
> + */
> +struct vfio_mdev_parent_ops {
> + int (*open)(struct mdev_device *mdev);
> + void(*release)(struct mdev_device *mdev);
> + ssize_t (*read)(struct mdev_device *mdev, char __user *buf,
> + size_t count, loff_t *ppos);
> + ssize_t (*write)(struct mdev_device *mdev, const char __user *buf,
> + size_t count, loff_t *ppos);
> + long(*ioctl)(struct mdev_device *mdev, unsigned int cmd,
> + unsigned long arg);
> + int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> +};
> +
> +/**
> + * struct mdev_parent_ops - Structure to be registered for each parent
> device to
> + * register the device to mdev module.
> + *
> + * @owner: The module owner.
> + * @dev_attr_groups: Attributes of the parent device.
> + * @mdev_attr_groups:Attributes of the mediated device.
> + * @supported_type_groups: Attributes to define supported types. It is
> mandatory
> + * to provide supported types.
> + * @create: Called to allocate basic resources in parent device's
> + * driver for a particular mediated device. It is
> + * mandatory to provide create ops.
> + * @kobj: kobject of type for which 'create' is called.
> + * @mdev: mdev_device structure on of mediated device
> + * that is being created
> + * Returns integer: success (0) or error (< 0)
> + * @remove: Called to free resources in parent device's driver for a
> + * a mediated device. It is mandatory to provide 'remove'
> + * ops.
> + * @mdev: mdev_device device structure which is being
> + * destroyed
> + * Returns integer: success (0)
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am 03.09.19 um 10:05 schrieb Daniel Vetter:
On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> This patch is a stripped down version of the locking changes
> necessary to support dynamic DMA-buf handling.
>
> For compatibility we cache the DMA-buf mapping as soon as
> exporter/importer disagree on the dynamic handling.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 90
> ---
> include/linux/dma-buf.h | 51 +-
> 2 files changed, 133 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 433d91d710e4..65052d52602b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
> + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> + exp_info->ops->dynamic_mapping))
> + return ERR_PTR(-EINVAL);
> +
> if (!try_module_get(exp_info->owner))
> return ERR_PTR(-ENOENT);
> @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> EXPORT_SYMBOL_GPL(dma_buf_put);
> /**
> - * dma_buf_attach - Add the device to dma_buf's attachments
> list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's
> attachments list; optionally,
> * calls attach() of dma_buf_ops to allow device-specific
> attach functionality
> - * @dmabuf: [in] buffer to attach device to.
> - * @dev: [in] device to be attached.
> + * @dmabuf: [in] buffer to attach device to.
> + * @dev: [in] device to be attached.
> + * @dynamic_mapping: [in] calling convention for map/unmap
> *
> * Returns struct dma_buf_attachment pointer for this
> attachment. Attachments
> * must be cleaned up by calling dma_buf_detach().
> @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> * accessible to @dev, and cannot be moved to a more suitable
> place. This is
> * indicated with the error code -EBUSY.
> */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> - struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> + bool dynamic_mapping)
> {
> struct dma_buf_attachment *attach;
> int ret;
> @@ -677,6 +683,7 @@ struct dma_buf_attachment
> *dma_buf_attach(struct dma_buf *dmabuf,
> attach->dev = dev;
> attach->dmabuf = dmabuf;
> + attach->dynamic_mapping = dynamic_mapping;
> mutex_lock(>lock);
> @@ -685,16 +692,64 @@ struct dma_buf_attachment
> *dma_buf_attach(struct dma_buf *dmabuf,
> if (ret)
> goto err_attach;
> }
> + dma_resv_lock(dmabuf->resv, NULL);
> list_add(>node, >attachments);
> + dma_resv_unlock(dmabuf->resv);
> mutex_unlock(>lock);
> + /* When either the importer or the exporter can't handle dynamic
> + * mappings we cache the mapping here to avoid issues with the
> + * reservation object lock.
> + */
> + if (dma_buf_attachment_is_dynamic(attach) !=
> + dma_buf_is_dynamic(dmabuf)) {
> + struct sg_table *sgt;
> +
> + if (dma_buf_is_dynamic(attach->dmabuf))
> + dma_resv_lock(attach->dmabuf->resv, NULL);
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
Now we're back to enforcing DMA_BIDI, which works nicely around the
locking pain, but apparently upsets the arm-soc folks who want to
control
this better.
>>> Take another look at dma_buf_map_attachment(), we still try to get the
>>> caching there for ARM.
>>>
>>> What we do here is to bidirectionally map the buffer to avoid the
>>> locking hydra when importer and exporter disagree on locking.
>>>
>>> So the ARM folks can easily avoid that by switching to dynamic locking
>>> for both.
> So you still break the contract between importer and exporter, except not
> for anything that's run in intel-gfx-ci so all is good?
No, the contract between importer and exporter stays exactly the same it
is currently as long as you don't switch to dynamic dma-buf handling.
There is no functional change for the ARM folks here. The only
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for adding gamma state checker for icl+ platforms
== Series Details == Series: adding gamma state checker for icl+ platforms URL : https://patchwork.freedesktop.org/series/66811/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2da6cea43f48 drm/i915/display: Fix formatting issues -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 46 lines checked 903306d33c88 drm/i915/display: Extract icl_read_luts() -:81: ERROR:TRAILING_WHITESPACE: trailing whitespace #81: FILE: drivers/gpu/drm/i915/display/intel_color.c:1444: +^I^Ireturn 16; $ -:87: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #87: FILE: drivers/gpu/drm/i915/display/intel_color.c:1450: + +} -:279: WARNING:LONG_LINE: line over 100 characters #279: FILE: drivers/gpu/drm/i915/display/intel_color.c:1893: + tmp_blob_data[i].green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 | -:291: WARNING:LONG_LINE: line over 100 characters #291: FILE: drivers/gpu/drm/i915/display/intel_color.c:1905: + tmp_blob_data[i + 8].red = REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, val2) << 6 | -:293: WARNING:LONG_LINE: line over 100 characters #293: FILE: drivers/gpu/drm/i915/display/intel_color.c:1907: + tmp_blob_data[i + 8].green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 | -:295: WARNING:LONG_LINE: line over 100 characters #295: FILE: drivers/gpu/drm/i915/display/intel_color.c:1909: + tmp_blob_data[i + 8].blue = REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, val2) << 6 | -:303: WARNING:LONG_LINE: line over 100 characters #303: FILE: drivers/gpu/drm/i915/display/intel_color.c:1917: + tmp_blob_data[i + 265].red = REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, val2) << 6 | -:305: WARNING:LONG_LINE: line over 100 characters #305: FILE: drivers/gpu/drm/i915/display/intel_color.c:1919: + tmp_blob_data[i + 265].green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, val2) << 6 | -:306: WARNING:LONG_LINE: line over 100 characters #306: FILE: drivers/gpu/drm/i915/display/intel_color.c:1920: + REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_LDW_MASK, val1); -:307: WARNING:LONG_LINE: line over 100 characters #307: FILE: drivers/gpu/drm/i915/display/intel_color.c:1921: + tmp_blob_data[i + 265].blue = REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, val2) << 6 | total: 1 errors, 8 warnings, 1 checks, 344 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gem_mmap_gtt: Run forked mmap tests on tgl
== Series Details ==
Series: i915/gem_mmap_gtt: Run forked mmap tests on tgl
URL : https://patchwork.freedesktop.org/series/66809/
State : success
== Summary ==
CI Bug Log - changes from IGT_5189 -> IGTPW_3470
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/66809/revisions/1/mbox/
Known issues
Here are the changes found in IGTPW_3470 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_linear_blits@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/fi-icl-u3/igt@gem_linear_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/fi-icl-u3/igt@gem_linear_bl...@basic.html
Possible fixes
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
* igt@i915_module_load@reload-no-display:
- {fi-icl-u4}:[DMESG-WARN][5] ([fdo#105602]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/fi-icl-u4/igt@i915_module_l...@reload-no-display.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111407]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5189/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (54 -> 47)
--
Additional (1): fi-tgl-u
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* IGT: IGT_5189 -> IGTPW_3470
CI-20190529: 20190529
CI_DRM_6908: c09b47830224c06546b73417085f7c6880a3995a @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3470: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/
IGT_5189: c78b9959fa4050725b16d55a5e56315884a2753d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3470/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention
On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
> Ping? Any further comment on this or can't we merge at least the locking
> change?
I was at plumbers ...
>
> Christian.
>
> Am 11.09.19 um 12:53 schrieb Christian König:
> > Am 03.09.19 um 10:05 schrieb Daniel Vetter:
> > > On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
> > > > This patch is a stripped down version of the locking changes
> > > > necessary to support dynamic DMA-buf handling.
> > > >
> > > > For compatibility we cache the DMA-buf mapping as soon as
> > > > exporter/importer disagree on the dynamic handling.
> > > >
> > > > Signed-off-by: Christian König
> > > > ---
> > > > drivers/dma-buf/dma-buf.c | 90
> > > > ---
> > > > include/linux/dma-buf.h | 51 +-
> > > > 2 files changed, 133 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > > index 433d91d710e4..65052d52602b 100644
> > > > --- a/drivers/dma-buf/dma-buf.c
> > > > +++ b/drivers/dma-buf/dma-buf.c
> > > > @@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
> > > > dma_buf_export_info *exp_info)
> > > > return ERR_PTR(-EINVAL);
> > > > }
> > > > + if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
> > > > + exp_info->ops->dynamic_mapping))
> > > > + return ERR_PTR(-EINVAL);
> > > > +
> > > > if (!try_module_get(exp_info->owner))
> > > > return ERR_PTR(-ENOENT);
> > > > @@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
> > > > EXPORT_SYMBOL_GPL(dma_buf_put);
> > > > /**
> > > > - * dma_buf_attach - Add the device to dma_buf's attachments
> > > > list; optionally,
> > > > + * dma_buf_dynamic_attach - Add the device to dma_buf's
> > > > attachments list; optionally,
> > > > * calls attach() of dma_buf_ops to allow device-specific
> > > > attach functionality
> > > > - * @dmabuf: [in] buffer to attach device to.
> > > > - * @dev: [in] device to be attached.
> > > > + * @dmabuf: [in] buffer to attach device to.
> > > > + * @dev: [in] device to be attached.
> > > > + * @dynamic_mapping: [in] calling convention for map/unmap
> > > > *
> > > > * Returns struct dma_buf_attachment pointer for this
> > > > attachment. Attachments
> > > > * must be cleaned up by calling dma_buf_detach().
> > > > @@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> > > > * accessible to @dev, and cannot be moved to a more suitable
> > > > place. This is
> > > > * indicated with the error code -EBUSY.
> > > > */
> > > > -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> > > > - struct device *dev)
> > > > +struct dma_buf_attachment *
> > > > +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> > > > + bool dynamic_mapping)
> > > > {
> > > > struct dma_buf_attachment *attach;
> > > > int ret;
> > > > @@ -677,6 +683,7 @@ struct dma_buf_attachment
> > > > *dma_buf_attach(struct dma_buf *dmabuf,
> > > > attach->dev = dev;
> > > > attach->dmabuf = dmabuf;
> > > > + attach->dynamic_mapping = dynamic_mapping;
> > > > mutex_lock(>lock);
> > > > @@ -685,16 +692,64 @@ struct dma_buf_attachment
> > > > *dma_buf_attach(struct dma_buf *dmabuf,
> > > > if (ret)
> > > > goto err_attach;
> > > > }
> > > > + dma_resv_lock(dmabuf->resv, NULL);
> > > > list_add(>node, >attachments);
> > > > + dma_resv_unlock(dmabuf->resv);
> > > > mutex_unlock(>lock);
> > > > + /* When either the importer or the exporter can't handle dynamic
> > > > + * mappings we cache the mapping here to avoid issues with the
> > > > + * reservation object lock.
> > > > + */
> > > > + if (dma_buf_attachment_is_dynamic(attach) !=
> > > > + dma_buf_is_dynamic(dmabuf)) {
> > > > + struct sg_table *sgt;
> > > > +
> > > > + if (dma_buf_is_dynamic(attach->dmabuf))
> > > > + dma_resv_lock(attach->dmabuf->resv, NULL);
> > > > +
> > > > + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> > > Now we're back to enforcing DMA_BIDI, which works nicely around the
> > > locking pain, but apparently upsets the arm-soc folks who want to
> > > control
> > > this better.
> >
> > Take another look at dma_buf_map_attachment(), we still try to get the
> > caching there for ARM.
> >
> > What we do here is to bidirectionally map the buffer to avoid the
> > locking hydra when importer and exporter disagree on locking.
> >
> > So the ARM folks can easily avoid that by switching to dynamic locking
> > for both.
So you still break the contract between importer and exporter, except not
for anything that's run in intel-gfx-ci so all is good?
The other issue with "we solve this with caching the mapping": Currently
map/unmap flush (at least on arm, at
[Intel-gfx] [PATCH] drm/i915/tgl: Extend MI_SEMAPHORE_WAIT
On Tigerlake, MI_SEMAPHORE_WAIT grew an extra dword, so be sure to
update the length field and emit that extra parameter and any padding
noop as required.
v2: Define the token shift while we are adding the updated MI_SEMAPHORE_WAIT
v3: Use int instead of bool in the addition so that readers are not left
wondering about the intricacies of the C spec. Now they just have to
worry what the integer value of a boolean operation is...
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 71 ++--
drivers/gpu/drm/i915/i915_pci.c | 1 -
drivers/gpu/drm/i915/i915_request.c | 21 --
4 files changed, 84 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index fbad403ab7ac..f78b13d74e17 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -112,6 +112,7 @@
#define MI_SEMAPHORE_SIGNALMI_INSTR(0x1b, 0) /* GEN8+ */
#define MI_SEMAPHORE_TARGET(engine) ((engine)<<15)
#define MI_SEMAPHORE_WAIT MI_INSTR(0x1c, 2) /* GEN8+ */
+#define MI_SEMAPHORE_WAIT_TOKENMI_INSTR(0x1c, 3) /* GEN12+ */
#define MI_SEMAPHORE_POLL(1 << 15)
#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
@@ -119,6 +120,8 @@
#define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
#define MI_SEMAPHORE_SAD_EQ_SDD (4 << 12)
#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
+#define MI_SEMAPHORE_TOKEN_MASK REG_GENMASK(9, 5)
+#define MI_SEMAPHORE_TOKEN_SHIFT 5
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_STORE_DWORD_IMM_GEN4MI_INSTR(0x20, 2)
#define MI_MEM_VIRTUAL (1 << 22) /* 945,g33,965 */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a3f0e4999744..a99166a2d2eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2879,6 +2879,22 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
return gen8_emit_fini_breadcrumb_footer(request, cs);
}
+static u32 *
+gen11_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs)
+{
+ cs = gen8_emit_ggtt_write_rcs(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_TILE_CACHE_FLUSH |
+ PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE |
+ PIPE_CONTROL_FLUSH_ENABLE);
+
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
+}
+
/*
* Note that the CS instruction pre-parser will not stall on the breadcrumb
* flush and will continue pre-fetching the instructions after it before the
@@ -2897,8 +2913,49 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
* All the above applies only to the instructions themselves. Non-inline data
* used by the instructions is not pre-fetched.
*/
-static u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *request,
- u32 *cs)
+
+static u32 *gen12_emit_preempt_busywait(struct i915_request *request, u32 *cs)
+{
+ *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
+ MI_SEMAPHORE_GLOBAL_GTT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD;
+ *cs++ = 0;
+ *cs++ = intel_hws_preempt_address(request->engine);
+ *cs++ = 0;
+ *cs++ = 0;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
+static __always_inline u32*
+gen12_emit_fini_breadcrumb_footer(struct i915_request *request, u32 *cs)
+{
+ *cs++ = MI_USER_INTERRUPT;
+
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ if (intel_engine_has_semaphores(request->engine))
+ cs = gen12_emit_preempt_busywait(request, cs);
+
+ request->tail = intel_ring_offset(request, cs);
+ assert_ring_tail_valid(request->ring, request->tail);
+
+ return gen8_emit_wa_tail(request, cs);
+}
+
+static u32 *gen12_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
+{
+ cs = gen8_emit_ggtt_write(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ 0);
+
+ return gen12_emit_fini_breadcrumb_footer(request, cs);
+}
+
+static u32 *
+gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs)
{
cs = gen8_emit_ggtt_write_rcs(cs,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only apply a rmw mmio update if the value changes
== Series Details == Series: drm/i915: Only apply a rmw mmio update if the value changes URL : https://patchwork.freedesktop.org/series/66800/ State : success == Summary == CI Bug Log - changes from CI_DRM_6906_full -> Patchwork_14427_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14427_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb4/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb8/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl9/igt@i915_pm_backlight@fade_with_suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-skl10/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-snb6/igt@i915_pm_rc6_reside...@rc6-accuracy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#110741]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_flip@dpms-vs-vblank-race: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#111609]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-glk4/igt@kms_f...@dpms-vs-vblank-race.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-glk3/igt@kms_f...@dpms-vs-vblank-race.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-kbl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-kbl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-panning: - shard-apl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103927]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-apl1/igt@kms_f...@flip-vs-panning.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-apl6/igt@kms_f...@flip-vs-panning.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#100368]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-skl5/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-skl6/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6906/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14427/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_lowres@pipe-a-tiling-y:
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Run forked mmap tests on tgl
Quoting Mika Kuoppala (2019-09-17 13:04:32) > Chris Wilson writes: > > > Tigerlake does not seem to be suffering from the same fault as Icelake > > did, so let the tests run as they should complete within the timeout. > > > > Early tgl results: > > > > basic-small-copy: SUCCESS (1,671s) > > forked-basic-small-copy: SUCCESS (37,568s) > > > > medium-copy: SUCCESS (3,307s) > > forked-medium-copy: SUCCESS (76,614s) > > forked-medium-copy-XY: SUCCESS (203,251s) > > forked-medium-copy-odd: SUCCESS (204,265s) > > > > Not great, but nowhere near as bad as icl, > >single forked > > glk:2.15s 2.89s > > icl:2.50s 281.08s > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=110882 > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > Cc: Martin Peres > > --- > > tests/i915/gem_mmap_gtt.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c > > index ac439cdf8..e2c6ad9a0 100644 > > --- a/tests/i915/gem_mmap_gtt.c > > +++ b/tests/i915/gem_mmap_gtt.c > > @@ -792,7 +792,7 @@ test_huge_copy(int fd, int huge, int tiling_a, int > > tiling_b, int ncpus) > > uint64_t huge_object_size, i; > > unsigned mode = CHECK_RAM; > > > > - igt_fail_on_f(intel_gen(devid) >= 11 && ncpus > 1, > > + igt_fail_on_f(intel_gen(devid) == 11 && ncpus > 1, > > "Please adjust your expectations, > > https://bugs.freedesktop.org/show_bug.cgi?id=110882\n;); > > It seems to be still exponential so how about, > > if (intel_gen(devid) >= 11) >ncpus = max(2, (ncpus-1)/2); > > Would drop the medium-odd to 14 seconds, without huge dent in coverage as > as odd number of cpus would be bouncing on it? My worry is that our discovery that they introduced this late change into Icelake is pure serendipity, and so I hesitate deviating too far from the test setup that originally found the problem. I'd rather extend the testing to study the correlation between ncpus and time than reduce it :( Thinking about the effects worth investigating here, doing a cpuset to bind the process to a single cpu, then forking two processes should minimally cover the uabi behaviour. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
