Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)
On Mon, Oct 14, 2019 at 10:23:42PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 09, 2019 at 09:12:23PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats
> > on SNB-BDW sprites (rev2)
> > URL : https://patchwork.freedesktop.org/series/67741/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7042_full -> Patchwork_14725_full
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_14725_full absolutely need
> > to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_14725_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_14725_full:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@gem_eio@in-flight-1us:
> > - shard-snb: [PASS][1] -> [FAIL][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-snb7/igt@gem_...@in-flight-1us.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-snb7/igt@gem_...@in-flight-1us.html
> >
> > * igt@kms_plane@pixel-format-pipe-a-planes:
> > - shard-iclb: [PASS][3] -> [FAIL][4] +13 similar issues
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-iclb7/igt@kms_pl...@pixel-format-pipe-a-planes.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-iclb8/igt@kms_pl...@pixel-format-pipe-a-planes.html
>
> IGT-Version: 1.24-ge501741f
> ...
> Testing format AR30(0x30335241) / modifier 0x103 on A.0
> (kms_plane:1411) igt_fb-CRITICAL: Conversion not implemented (from format
> 0x30335241 to 0x78464749)
>
> DRM_FORMAT_ARGB2101010 = 0x30335241
> IGT_FORMAT_FLOAT = 0x78464749
>
> { .name = "ARGB2101010", .depth = 30, .drm_id = DRM_FORMAT_ARGB2101010,
> .pixman_id = PIXMAN_a2r10g10b10,
>
> { .name = "IGT-FLOAT", .depth = -1, .drm_id = IGT_FORMAT_FLOAT,
> .pixman_id = PIXMAN_rgba_float,
>
> if ((drm_format_to_pixman(cvt->src.fb->drm_format) != PIXMAN_invalid) &&
> (drm_format_to_pixman(cvt->dst.fb->drm_format) != PIXMAN_invalid)) {
> cnvert_pixman(cvt);
> return;
> ...
> igt_assert_f(false, "Conversion not implemented ...);
>
> So wtf?
>
> Are we somehow compiling igt with an old pixman causing
> #if PIXMAN_VERSION < PIXMAN_VERSION_ENCODE(0, 36, 0)
> #define PIXMAN_rgba_float PIXMAN_invalid
> #endif
> to happen?
oof, seems like the building machine got downgraded somehow
ci-worker1:~$ dpkg -l '*pixman*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion
Architecture Description
+++-===---===
ii libpixman-1-0:amd64 0.34.0-2
amd64pixel-manipulation library for X and cairo
ii libpixman-1-dev:amd64 0.34.0-2
amd64pixel-manipulation library for X and cairo
(development files)
that's bad...
> But the reference run shows it testing all the fancy YUV formats so
> I don't think that can be the case.
That's the weird bit...
Anyway the building machine needs updating and apt-mark hold.
This can cause fallout and we need to file bugs to limit the noise.
There is quite some queue right now, but hopefully by tomorrow it will
be drained. I'll do the necessary updates and force IGT run to see what
is going to happen in the morning. Then I'll rerun this series.
--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 0/7] mdev based hardware virtio offloading support
On 2019/10/15 上午1:49, Stefan Hajnoczi wrote: On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote: There are hardware that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to talk with mdev device implementation. Though the series only contains kernel driver support, the goal is to make the transport generic enough to support userspace drivers. This means vhost-mdev[1] could be built on top as well by resuing the transport. A sample driver is also implemented which simulate a virito-net loopback ethernet device on top of vringh + workqueue. This could be used as a reference implementation for real hardware driver. Consider mdev framework only support VFIO device and driver right now, this series also extend it to support other types. This is done through introducing class id to the device and pairing it with id_talbe claimed by the driver. On top, this seris also decouple device specific parents ops out of the common ones. I was curious so I took a quick look and posted comments. I guess this driver runs inside the guest since it registers virtio devices? It could run in either guest or host. But the main focus is to run in the host then we can use virtio drivers in containers. If this is used with physical PCI devices that support datapath offloading then how are physical devices presented to the guest without SR-IOV? We will do control path meditation through vhost-mdev[1] and vhost-vfio[2]. Then we will present a full virtio compatible ethernet device for guest. SR-IOV is not a must, any mdev device that implements the API defined in patch 5 can be used by this framework. Thanks [1] https://lkml.org/lkml/2019/9/26/15 [2] https://patchwork.ozlabs.org/cover/984763/ Stefan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 6/7] virtio: introduce a mdev based transport
On 2019/10/15 上午1:39, Stefan Hajnoczi wrote:
On Fri, Oct 11, 2019 at 04:15:56PM +0800, Jason Wang wrote:
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ unsigned long version;
+
+ struct virtqueue **vqs;
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ struct list_head virtqueues;
Is this a list of struct virtio_mdev_vq_info? Please document the
actual type in a comment.
Ok.
+static int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs,
+ struct virtqueue *vqs[],
+ vq_callback_t *callbacks[],
+ const char * const names[],
+ const bool *ctx,
+ struct irq_affinity *desc)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
+ struct virtio_mdev_callback cb;
+ int i, err, queue_idx = 0;
+
+ vm_dev->vqs = kmalloc_array(queue_idx, sizeof(*vm_dev->vqs),
+ GFP_KERNEL);
kmalloc_array(0, ...)? I would have expected nvqs instead of queue_idx
(0).
What is this the purpose of vm_dev->vqs and does anything ever access it?
It's useless, will remove it.
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 5/7] mdev: introduce virtio device and its device ops
On 2019/10/15 上午1:23, Stefan Hajnoczi wrote: On Fri, Oct 11, 2019 at 04:15:55PM +0800, Jason Wang wrote: + * @set_vq_cb: Set the interrut calback function for s/interrut/interrupt/ s/calback/callback/ Fixed. Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Some cleanup near the SKL wm/ddb area (rev2)
== Series Details == Series: drm/i915: Some cleanup near the SKL wm/ddb area (rev2) URL : https://patchwork.freedesktop.org/series/67930/ State : success == Summary == CI Bug Log - changes from CI_DRM_7087_full -> Patchwork_14794_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14794_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_7087/shard-iclb1/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb8/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb5/igt@gem_exec_sched...@wide-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb4/igt@gem_exec_sched...@wide-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] / [fdo#108686] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#111870]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-snb4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-apl7/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-glk6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#110403]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb2/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html Possible fixes *
Re: [Intel-gfx] [PATCH] kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
On Mon, Oct 14, 2019 at 08:48:48PM +, tim.b...@sony.com wrote: > > > > -Original Message- > > From: Jani Nikula on October 13, 2019 11:00 PM > > On Sun, 13 Oct 2019, Changbin Du wrote: > > > The 'functions' directive is not only for functions, but also works for > > > structs/unions. So the name is misleading. This patch renames it to > > > 'specific', so now we have export/internal/specific directives to limit > > > the functions/types to be included in documentation. Meanwhile we > > improved > > > the warning message. > > > > Agreed on "functions" being less than perfect. It directly exposes the > > idiosyncrasies of scripts/kernel-doc. I'm not sure "specific" is any > > better, though. > > I strongly agree with this. 'specific' IMHO, has no semantic value and > I'd rather just leave the only-sometimes-wrong 'functions' than convert > to something that obscures the meaning always. > > > > > Perhaps "symbols" would be more self-explanatory. Or, actually make > > "functions" only work on functions, and add a separate keyword for other > > stuff. *shrug* > My preference would be to use 'symbols'. I tried to come up with something > but 'symbols' is better than anything I came up with. structures aren't symbols though ... How about 'identifier'? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Assert tasklet is locked for process_csb() (rev4)
== Series Details ==
Series: drm/i915/execlists: Assert tasklet is locked for process_csb() (rev4)
URL : https://patchwork.freedesktop.org/series/67957/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7087_full -> Patchwork_14793_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_14793_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- {shard-tglb}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
New tests
-
New tests have been introduced between CI_DRM_7087_full and
Patchwork_14793_full:
### New Piglit tests (1) ###
* spec@ext_transform_feedback@discard-drawpixels:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_14793_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-suspend:
- shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#104108])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-skl6/igt@gem_...@in-flight-suspend.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-skl9/igt@gem_...@in-flight-suspend.html
* igt@gem_eio@reset-stress:
- shard-snb: [PASS][4] -> [FAIL][5] ([fdo#109661])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-snb1/igt@gem_...@reset-stress.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-snb6/igt@gem_...@reset-stress.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#110854])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb1/igt@gem_exec_balan...@smoke.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-iclb7/igt@gem_exec_balan...@smoke.html
* igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#109276]) +12 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-iclb7/igt@gem_exec_sched...@fifo-bsd1.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#111325]) +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-iclb3/igt@gem_exec_sched...@preempt-bsd.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-iclb4/igt@gem_exec_sched...@preempt-bsd.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-snb: [PASS][12] -> [DMESG-WARN][13] ([fdo#111870]) +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
* igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl: [PASS][14] -> [INCOMPLETE][15] ([fdo#104108] /
[fdo#107807])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-skl6/igt@i915_pm_...@system-suspend-modeset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-skl7/igt@i915_pm_...@system-suspend-modeset.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][16] -> [DMESG-WARN][17] ([fdo#108566]) +5
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-apl4/igt@i915_susp...@sysfs-reader.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-apl4/igt@i915_susp...@sysfs-reader.html
* igt@kms_cursor_crc@pipe-b-cursor-64x64-random:
- shard-apl: [PASS][18] -> [INCOMPLETE][19] ([fdo#103927]) +4
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-apl5/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html
* igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic:
- shard-skl: [PASS][20] -> [DMESG-WARN][21] ([fdo#105541])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/shard-skl10/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/shard-skl5/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html
* igt@kms
[Intel-gfx] ✓ Fi.CI.BAT: success for Clear Color Support for TGL Render Decompression (rev5)
== Series Details ==
Series: Clear Color Support for TGL Render Decompression (rev5)
URL : https://patchwork.freedesktop.org/series/66814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7091 -> Patchwork_14803
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14803:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload-with-fault-injection:
- {fi-tgl-u}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-tgl-u/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/fi-tgl-u/igt@i915_module_l...@reload-with-fault-injection.html
Known issues
Here are the changes found in Patchwork_14803 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_render_linear_blits@basic:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_render_linear_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/fi-icl-u3/igt@gem_render_linear_bl...@basic.html
* igt@i915_selftest@live_hangcheck:
- fi-bsw-n3050: [PASS][5] -> [DMESG-FAIL][6] ([fdo# 111537])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111045] / [fdo#111096])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap_gtt@basic-read-no-prefault:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo# 111537]: https://bugs.freedesktop.org/show_bug.cgi?id= 111537
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
Participating hosts (52 -> 46)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7091 -> Patchwork_14803
CI-20190529: 20190529
CI_DRM_7091: d88a66d195bcf71e6e05db07ba79c9fab5651f22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14803: 4f8d40fcc90f255c3f838505ca7a2316ae8ab367 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4f8d40fcc90f drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
71d0a02d234b drm/framebuffer/tgl: Format modifier for Intel Gen 12 render
compression with Clear Color
0f52b8eef612 Gen-12 display can decompress surfaces compressed by the media
engine.
b4947111fb56 drm/fb: Extend format_info member arrays to handle four planes
e9aab6479891 drm/framebuffer: Format modifier for Intel Gen-12 media compression
8be18fc5f18e drm/i915: Extract framebufer CCS offset checks into a function
15027386 drm/i915/tgl: Gen-12 render decompression
43b42e53f492 drm/i915: Move CCS stride alignment W/A inside
intel_fb_stride_alignment
46a58f5e2541 drm/i915: Use intel_tile_height() instead of re-implementing
e84d0c20bec1 drm/framebuffer: Format modifier for Intel Gen-12 render
compression
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14803/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clear Color Support for TGL Render Decompression (rev5)
== Series Details ==
Series: Clear Color Support for TGL Render Decompression (rev5)
URL : https://patchwork.freedesktop.org/series/66814/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e84d0c20bec1 drm/framebuffer: Format modifier for Intel Gen-12 render
compression
46a58f5e2541 drm/i915: Use intel_tile_height() instead of re-implementing
43b42e53f492 drm/i915: Move CCS stride alignment W/A inside
intel_fb_stride_alignment
15027386 drm/i915/tgl: Gen-12 render decompression
8be18fc5f18e drm/i915: Extract framebufer CCS offset checks into a function
e9aab6479891 drm/framebuffer: Format modifier for Intel Gen-12 media compression
b4947111fb56 drm/fb: Extend format_info member arrays to handle four planes
0f52b8eef612 Gen-12 display can decompress surfaces compressed by the media
engine.
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
-:113: WARNING:LONG_LINE: line over 100 characters
#113: FILE: drivers/gpu/drm/i915/display/intel_display.c:2699:
+intel_fb_plane_get_subsampling(int *hsub, int *vsub, const struct
drm_framebuffer *fb, int color_plane)
-:120: WARNING:LONG_LINE: line over 100 characters
#120: FILE: drivers/gpu/drm/i915/display/intel_display.c:2706:
+ } mc_ccs_subsampling = {.cpp = {1, 1, 2, 1}, .hsub = {1, 8, 2,
16}, .vsub = {1, 32, 2, 32} };
total: 0 errors, 3 warnings, 0 checks, 509 lines checked
71d0a02d234b 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
4f8d40fcc90f drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
-:252: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible
side-effects?
#252: FILE: drivers/gpu/drm/i915/i915_reg.h:6791:
+#define PLANE_CC_VAL(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_CC_VAL_1(pipe), _PLANE_CC_VAL_2(pipe))
total: 0 errors, 0 warnings, 1 checks, 198 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
Gen12 display can decompress surfaces compressed by render engine with Clear
Color, add
a new modifier as the driver needs to know the surface was compressed by render
engine.
V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits in the comments(DK)
v4: Fix trailing whitespaces
Cc: Ville Syrjala
Cc: Dhinakaran Pandiyan
Cc: Kalyan Kondapally
Cc: Rafael Antognolli
Cc: Nanley Chery
Signed-off-by: Radhakrishna Sripada
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index dd9c85111e77..8979fdd5a414 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -434,6 +434,17 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+/*
+ * Intel color control surfaces Clear Color(CCS_CC) for Gen-12 render
compression.
+ *
+ * The main surface is Y-tiled and is at plane index 0 whereas CCS_CC is linear
+ * and at index 1. The clear color is stored at index 2, and the pitch should
+ * be ignored. The size of clear color should be 64 bits. A CCS_CC cache line
+ * corresponds to an area of 4x1 tiles in the main surface. The main surface
+ * pitch is required to be a multiple of 4 tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Add mipi dsi command mode support.
== Series Details ==
Series: Add mipi dsi command mode support.
URL : https://patchwork.freedesktop.org/series/67974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7086_full -> Patchwork_14792_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_14792_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_pm_dc@dc6-dpms}:
- {shard-tglb}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-tglb1/igt@i915_pm...@dc6-dpms.html
Known issues
Here are the changes found in Patchwork_14792_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vecs0-s3:
- shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#104108])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-skl5/igt@gem_ctx_isolat...@vecs0-s3.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-skl4/igt@gem_ctx_isolat...@vecs0-s3.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#110841])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
* igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#111325]) +4 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-iclb8/igt@gem_exec_as...@concurrent-writes-bsd.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html
* igt@gem_tiled_swapping@non-threaded:
- shard-glk: [PASS][8] -> [INCOMPLETE][9] ([fdo#103359] /
[fdo#108686] / [k.org#198133])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-glk8/igt@gem_tiled_swapp...@non-threaded.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html
* igt@gem_userptr_blits@dmabuf-unsync:
- shard-snb: [PASS][10] -> [DMESG-WARN][11] ([fdo#111870])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-snb7/igt@gem_userptr_bl...@dmabuf-unsync.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-snb5/igt@gem_userptr_bl...@dmabuf-unsync.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-hsw: [PASS][12] -> [DMESG-WARN][13] ([fdo#111870])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-hsw5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-hsw8/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
* igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl: [PASS][14] -> [INCOMPLETE][15] ([fdo#104108] /
[fdo#107807])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-skl7/igt@i915_pm_...@system-suspend-execbuf.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-skl7/igt@i915_pm_...@system-suspend-execbuf.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][16] -> [FAIL][17] ([fdo#103167]) +6 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
* igt@kms_plane@plane-position-hole-dpms-pipe-c-planes:
- shard-iclb: [PASS][18] -> [INCOMPLETE][19] ([fdo#107713])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-iclb2/igt@kms_pl...@plane-position-hole-dpms-pipe-c-planes.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-iclb7/igt@kms_pl...@plane-position-hole-dpms-pipe-c-planes.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/shard-iclb7/igt@kms_psr@psr2_cursor_blt.html
* igt@kms_vblank@pipe-b-ts-continuation-suspend:
- shard-apl: [PASS][22] -> [DMESG-WARN][23] ([fdo#108566]) +3
similar issues
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/shard-apl1/igt@kms_vbl...@pipe-b-ts-continu
[Intel-gfx] ✓ Fi.CI.BAT: success for Clear Color Support for TGL Render Decompression (rev4)
== Series Details ==
Series: Clear Color Support for TGL Render Decompression (rev4)
URL : https://patchwork.freedesktop.org/series/66814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7091 -> Patchwork_14802
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/index.html
Known issues
Here are the changes found in Patchwork_14802 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@rcs0:
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
* igt@gem_mmap_gtt@basic-copy:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/fi-icl-u3/igt@gem_mmap_...@basic-copy.html
Possible fixes
* igt@gem_mmap_gtt@basic-read-no-prefault:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-icl-guc fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7091 -> Patchwork_14802
CI-20190529: 20190529
CI_DRM_7091: d88a66d195bcf71e6e05db07ba79c9fab5651f22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14802: cb25ebee96c966a74afdf8e23a4004a82757e32d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cb25ebee96c9 drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
0a4f1ab7678c drm/framebuffer/tgl: Format modifier for Intel Gen 12 render
compression with Clear Color
6af18a7bd390 Gen-12 display can decompress surfaces compressed by the media
engine.
e81ef5974cd9 drm/fb: Extend format_info member arrays to handle four planes
3e0c8644766c drm/framebuffer: Format modifier for Intel Gen-12 media compression
922c0f17cfcb drm/i915: Extract framebufer CCS offset checks into a function
fe009ce2a753 drm/i915/tgl: Gen-12 render decompression
6e151153d384 drm/i915: Move CCS stride alignment W/A inside
intel_fb_stride_alignment
7ae892f52e6b drm/i915: Use intel_tile_height() instead of re-implementing
5b2a67fc7d74 drm/framebuffer: Format modifier for Intel Gen-12 render
compression
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14802/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Clear Color Support for TGL Render Decompression (rev4)
== Series Details ==
Series: Clear Color Support for TGL Render Decompression (rev4)
URL : https://patchwork.freedesktop.org/series/66814/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5b2a67fc7d74 drm/framebuffer: Format modifier for Intel Gen-12 render
compression
7ae892f52e6b drm/i915: Use intel_tile_height() instead of re-implementing
6e151153d384 drm/i915: Move CCS stride alignment W/A inside
intel_fb_stride_alignment
fe009ce2a753 drm/i915/tgl: Gen-12 render decompression
922c0f17cfcb drm/i915: Extract framebufer CCS offset checks into a function
3e0c8644766c drm/framebuffer: Format modifier for Intel Gen-12 media compression
e81ef5974cd9 drm/fb: Extend format_info member arrays to handle four planes
6af18a7bd390 Gen-12 display can decompress surfaces compressed by the media
engine.
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
-:113: WARNING:LONG_LINE: line over 100 characters
#113: FILE: drivers/gpu/drm/i915/display/intel_display.c:2699:
+intel_fb_plane_get_subsampling(int *hsub, int *vsub, const struct
drm_framebuffer *fb, int color_plane)
-:120: WARNING:LONG_LINE: line over 100 characters
#120: FILE: drivers/gpu/drm/i915/display/intel_display.c:2706:
+ } mc_ccs_subsampling = {.cpp = {1, 1, 2, 1}, .hsub = {1, 8, 2,
16}, .vsub = {1, 32, 2, 32} };
total: 0 errors, 3 warnings, 0 checks, 509 lines checked
0a4f1ab7678c 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
-:33: ERROR:TRAILING_WHITESPACE: trailing whitespace
#33: FILE: include/uapi/drm/drm_fourcc.h:442:
+ * be ignored. The size of clear color should be 64 bits. A CCS_CC cache line $
-:34: ERROR:TRAILING_WHITESPACE: trailing whitespace
#34: FILE: include/uapi/drm/drm_fourcc.h:443:
+ * corresponds to an area of 4x1 tiles in the main surface. The main surface $
total: 2 errors, 1 warnings, 0 checks, 17 lines checked
cb25ebee96c9 drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
-:252: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible
side-effects?
#252: FILE: drivers/gpu/drm/i915/i915_reg.h:6791:
+#define PLANE_CC_VAL(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_CC_VAL_1(pipe), _PLANE_CC_VAL_2(pipe))
total: 0 errors, 0 warnings, 1 checks, 198 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: Introduce Jasper Lake PCH (rev2)
== Series Details ==
Series: drm/i915: Introduce Jasper Lake PCH (rev2)
URL : https://patchwork.freedesktop.org/series/67992/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7091 -> Patchwork_14801
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/index.html
Known issues
Here are the changes found in Patchwork_14801 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-blb-e6850/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_hangcheck:
- fi-kbl-r: [PASS][3] -> [INCOMPLETE][4] ([fdo#108744])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-kbl-r/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-kbl-r/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([fdo#102614])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-busy-default:
- fi-icl-u3: [PASS][9] -> [DMESG-WARN][10] ([fdo#107724])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@prime_v...@basic-busy-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-icl-u3/igt@prime_v...@basic-busy-default.html
Possible fixes
* igt@gem_mmap_gtt@basic-read-no-prefault:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.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#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
[fdo#111678]: https://bugs.freedesktop.org/show_bug.cgi?id=111678
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-snb-2520m fi-icl-y fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7091 -> Patchwork_14801
CI-20190529: 20190529
CI_DRM_7091: d88a66d195bcf71e6e05db07ba79c9fab5651f22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14801: 38d9f7bf855d73f68b9d92c313e71f2d56311102 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
38d9f7bf855d drm/i915: Introduce Jasper Lake PCH
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14801/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 07/10] drm/fb: Extend format_info member arrays to handle four planes
From: Dhinakaran Pandiyan
addfb() uAPI has supported four planes for a while now, make format_info
compatible with that.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
include/drm/drm_fourcc.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 306d1efeb5e0..156b122c0ad5 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -78,7 +78,7 @@ struct drm_format_info {
* triplet @char_per_block, @block_w, @block_h for better
* describing the pixel format.
*/
- u8 cpp[3];
+ u8 cpp[4];
/**
* @char_per_block:
@@ -104,7 +104,7 @@ struct drm_format_info {
* information from their drm_mode_config.get_format_info hook
* if they want the core to be validating the pitch.
*/
- u8 char_per_block[3];
+ u8 char_per_block[4];
};
/**
@@ -113,7 +113,7 @@ struct drm_format_info {
* Block width in pixels, this is intended to be accessed through
* drm_format_info_block_width()
*/
- u8 block_w[3];
+ u8 block_w[4];
/**
* @block_h:
@@ -121,7 +121,7 @@ struct drm_format_info {
* Block height in pixels, this is intended to be accessed through
* drm_format_info_block_height()
*/
- u8 block_h[3];
+ u8 block_h[4];
/** @hsub: Horizontal chroma subsampling factor */
u8 hsub;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 05/10] drm/i915: Extract framebufer CCS offset checks into a function
From: Dhinakaran Pandiyan
intel_fill_fb_info() has grown quite large and wrapping the offset checks
into a separate function makes the loop a bit easier to follow.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 69
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a1dccca6a03d..be61dfdebb34 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2677,6 +2677,43 @@ static bool intel_plane_needs_remap(const struct
intel_plane_state *plane_state)
return stride > max_stride;
}
+static int
+intel_fb_check_ccs_xy(struct drm_framebuffer *fb, int x, int y)
+{
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ int hsub = fb->format->hsub;
+ int vsub = fb->format->vsub;
+ int tile_width, tile_height;
+ int ccs_x, ccs_y;
+ int main_x, main_y;
+
+ intel_tile_dims(fb, 1, &tile_width, &tile_height);
+
+ tile_width *= hsub;
+ tile_height *= vsub;
+
+ ccs_x = (x * hsub) % tile_width;
+ ccs_y = (y * vsub) % tile_height;
+ main_x = intel_fb->normal[0].x % tile_width;
+ main_y = intel_fb->normal[0].y % tile_height;
+
+ /*
+* CCS doesn't have its own x/y offset register, so the intra CCS tile
+* x/y offsets must match between CCS and the main surface.
+*/
+ if (main_x != ccs_x || main_y != ccs_y) {
+ DRM_DEBUG_KMS("Bad CCS x/y (main %d,%d ccs %d,%d) full (main
%d,%d ccs %d,%d)\n",
+ main_x, main_y,
+ ccs_x, ccs_y,
+ intel_fb->normal[0].x,
+ intel_fb->normal[0].y,
+ x, y);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -2708,35 +2745,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
}
if (is_ccs_modifier(fb->modifier) && i == 1) {
- int hsub = fb->format->hsub;
- int vsub = fb->format->vsub;
- int tile_width, tile_height;
- int main_x, main_y;
- int ccs_x, ccs_y;
-
- intel_tile_dims(fb, i, &tile_width, &tile_height);
-
- tile_width *= hsub;
- tile_height *= vsub;
-
- ccs_x = (x * hsub) % tile_width;
- ccs_y = (y * vsub) % tile_height;
- main_x = intel_fb->normal[0].x % tile_width;
- main_y = intel_fb->normal[0].y % tile_height;
-
- /*
-* CCS doesn't have its own x/y offset register, so the
intra CCS tile
-* x/y offsets must match between CCS and the main
surface.
-*/
- if (main_x != ccs_x || main_y != ccs_y) {
- DRM_DEBUG_KMS("Bad CCS x/y (main %d,%d ccs
%d,%d) full (main %d,%d ccs %d,%d)\n",
- main_x, main_y,
- ccs_x, ccs_y,
- intel_fb->normal[0].x,
- intel_fb->normal[0].y,
- x, y);
- return -EINVAL;
- }
+ ret = intel_fb_check_ccs_xy(fb, x, y);
+ if (ret)
+ return ret;
}
/*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 04/10] drm/i915/tgl: Gen-12 render decompression
From: Dhinakaran Pandiyan
Gen-12 display decompression operates on Y-tiled compressed main surface.
The CCS is linear and has 4 bits of metadata for each main surface cache
line pair, a size ratio of 1:256. Gen-12 display decompression is
incompatible with buffers compressed by earlier GPUs, so make use of a new
modifier to identify gen-12 compression. Another notable change is that
render decompression is supported on all planes except cursor and on all
pipes. Start by adding render decompression support for [A,X]BGR888 pixel
formats.
v2: Fix checkpatch warnings (Lucas)
v3:
Rebase, disable color clear, styling changes and modify
intel_tile_width_bytes and intel_tile_height to handle linear CCS
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 85
drivers/gpu/drm/i915/display/intel_sprite.c | 23 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
3 files changed, 84 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0a2f68dd7620..a1dccca6a03d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1909,6 +1909,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ if (color_plane == 1)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN(dev_priv, 2) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
@@ -1942,8 +1946,15 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
- return intel_tile_size(to_i915(fb->dev)) /
- intel_tile_width_bytes(fb, color_plane);
+ switch (fb->modifier) {
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ if (color_plane == 1)
+ return 1;
+ /* fall through */
+ default:
+ return intel_tile_size(to_i915(fb->dev)) /
+ intel_tile_width_bytes(fb, color_plane);
+ }
}
/* Return the tile dimensions in pixel units */
@@ -2042,6 +2053,8 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
@@ -2238,7 +2251,8 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
static bool is_surface_linear(u64 modifier, int color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR;
+ return modifier == DRM_FORMAT_MOD_LINEAR ||
+ (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2425,6 +2439,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
return I915_TILING_X;
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return I915_TILING_Y;
default:
return I915_TILING_NONE;
@@ -2445,7 +2460,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
* us a ratio of one byte in the CCS for each 8x16 pixels in the
* main surface.
*/
-static const struct drm_format_info ccs_formats[] = {
+static const struct drm_format_info skl_ccs_formats[] = {
{ .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
{ .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
@@ -2456,6 +2471,24 @@ static const struct drm_format_info ccs_formats[] = {
.cpp = { 4, 1, }, .hsub = 8, .vsub = 16, .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 2x32 pixels in
+ * the main surface.
+ */
+static const struct drm_format_info gen12_ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsub = 2, .vsub = 32, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
+ .cpp = { 4, 1, }, .hsu
[Intel-gfx] [PATCH v4 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color
Gen12 display can decompress surfaces compressed by render engine with Clear
Color, add
a new modifier as the driver needs to know the surface was compressed by render
engine.
V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits in the comments(DK)
Cc: Ville Syrjala
Cc: Dhinakaran Pandiyan
Cc: Kalyan Kondapally
Cc: Rafael Antognolli
Cc: Nanley Chery
Signed-off-by: Radhakrishna Sripada
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index dd9c85111e77..a20f2ea8ddc6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -434,6 +434,17 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+/*
+ * Intel color control surfaces Clear Color(CCS_CC) for Gen-12 render
compression.
+ *
+ * The main surface is Y-tiled and is at plane index 0 whereas CCS_CC is linear
+ * and at index 1. The clear color is stored at index 2, and the pitch should
+ * be ignored. The size of clear color should be 64 bits. A CCS_CC cache line
+ * corresponds to an area of 4x1 tiles in the main surface. The main surface
+ * pitch is required to be a multiple of 4 tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 06/10] drm/framebuffer: Format modifier for Intel Gen-12 media compression
From: Dhinakaran Pandiyan
Gen-12 display can decompress surfaces compressed by the media engine, add
a new modifier as the driver needs to know the surface was compressed by
the media or render engine.
Cc: Nanley G Chery
Cc: Matt Roper
Cc: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
include/uapi/drm/drm_fourcc.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 52107533994c..dd9c85111e77 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -421,6 +421,19 @@ extern "C" {
*/
#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 media compression
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths. For semi-planar formats like NV12, CCS plane follows the
+ * Y and UV planes i.e., planes 0 and 2 are used for Y and UV surfaces,
+ * planes 1 and 3 for the respective CCS.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 10/10] drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression
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.
v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
plane config(Matt). Fix Lookup error.
v3: Fix the panic while running kms_cube
v4: Add alignment check and reuse the comments for ge12_ccs_formats(Matt)
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 | 52 +++
.../drm/i915/display/intel_display_types.h| 3 ++
drivers/gpu/drm/i915/display/intel_sprite.c | 11 +++-
drivers/gpu/drm/i915/i915_reg.h | 12 +
4 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 448168a4d780..8835920cb005 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1917,6 +1917,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 64;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
+ if (color_plane == 1 || color_plane == 2)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN(dev_priv, 2) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
@@ -2058,6 +2062,7 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
return 256 * 1024;
return 0;
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
case I915_FORMAT_MOD_Yf_TILED_CCS:
@@ -2260,6 +2265,8 @@ static bool is_surface_linear(u64 modifier, int
color_plane)
return true;
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return color_plane == 1;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC:
+ return color_plane == 1 || color_plane == 2;
case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
return color_plane == 1 || color_plane == 3;
default:
@@ -2453,6 +2460,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;
@@ -2506,6 +2514,21 @@ static const struct drm_format_info gen12_ccs_formats[]
= {
.cpp = { 1, 1, 2, 1}, .hsub = 2, .vsub = 2, .is_yuv = true },
};
+/*
+ * Same as gen12_ccs_formats[] above, but with additional surface used
+ * top pass Clear Color information in plane 2 with 64 bits of data.
+ */
+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, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 3,
+ .cpp = { 4, 1, 0, }, .hsub = 2, .vsub = 32, .has_alpha = true },
+};
+
static const struct drm_format_info *
lookup_format_info(const struct drm_format_info formats[],
int num_formats, u32 format)
@@ -2533,6 +2556,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_cc_formats,
+ ARRAY_SIZE(gen12_ccs_cc_formats),
+ cmd->pixel_format);
default:
return NULL;
}
@@ -2542,6 +2569,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 ||
+ modifier == I915_FORM
[Intel-gfx] [PATCH v4 01/10] drm/framebuffer: Format modifier for Intel Gen-12 render compression
From: Dhinakaran Pandiyan
Gen-12 has a new compression format, add a new modifier to indicate that.
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Nanley G Chery
Cc: Jason Ekstrand
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
include/uapi/drm/drm_fourcc.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2376d36ea573..52107533994c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -410,6 +410,17 @@ extern "C" {
#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+/*
+ * Intel color control surfaces (CCS) for Gen-12 render compression.
+ *
+ * The main surface is Y-tiled and at plane index 0, the CCS is linear and
+ * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
+ * main surface. In other words, 4 bits in CCS map to a main surface cache
+ * line pair. The main surface pitch is required to be a multiple of four
+ * Y-tile widths.
+ */
+#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
+
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 03/10] drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment
From: Dhinakaran Pandiyan
Easier to read if all the alignment changes are in one place and contained
within a function.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 31 ++--
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 626046e97b40..0a2f68dd7620 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2546,7 +2546,22 @@ intel_fb_stride_alignment(const struct drm_framebuffer
*fb, int color_plane)
else
return 64;
} else {
- return intel_tile_width_bytes(fb, color_plane);
+ u32 tile_width = intel_tile_width_bytes(fb, color_plane);
+
+ /*
+* Display WA #0531: skl,bxt,kbl,glk
+*
+* Render decompression and plane width > 3840
+* combined with horizontal panning requires the
+* plane stride to be a multiple of 4. We'll just
+* require the entire fb to accommodate that to avoid
+* potential runtime errors at plane configuration time.
+*/
+ if (IS_GEN(dev_priv, 9) && is_ccs_modifier(fb->modifier) &&
+ color_plane == 0 && fb->width > 3840)
+ tile_width *= 4;
+
+ return tile_width;
}
}
@@ -15694,20 +15709,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
}
stride_alignment = intel_fb_stride_alignment(fb, i);
-
- /*
-* Display WA #0531: skl,bxt,kbl,glk
-*
-* Render decompression and plane width > 3840
-* combined with horizontal panning requires the
-* plane stride to be a multiple of 4. We'll just
-* require the entire fb to accommodate that to avoid
-* potential runtime errors at plane configuration time.
-*/
- if (IS_GEN(dev_priv, 9) && i == 0 && fb->width > 3840 &&
- is_ccs_modifier(fb->modifier))
- stride_alignment *= 4;
-
if (fb->pitches[i] & (stride_alignment - 1)) {
DRM_DEBUG_KMS("plane %d pitch (%d) must be at least %u
byte aligned\n",
i, fb->pitches[i], stride_alignment);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 02/10] drm/i915: Use intel_tile_height() instead of re-implementing
From: Dhinakaran Pandiyan intel_tile_dims() computes tile height using size and width, when there is already a function to do just that - intel_tile_height() Cc: Ville Syrjälä Cc: Matt Roper Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 3cf39fc153b3..626046e97b40 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -1955,7 +1955,7 @@ static void intel_tile_dims(const struct drm_framebuffer *fb, int color_plane, unsigned int cpp = fb->format->cpp[color_plane]; *tile_width = tile_width_bytes / cpp; - *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes; + *tile_height = intel_tile_height(fb, color_plane); } unsigned int -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 08/10] Gen-12 display can decompress surfaces compressed by the media engine.
From: Dhinakaran Pandiyan
Detect the modifier corresponding to media compression to enable
display decompression for YUV and xRGB packed formats. A new modifier is
added so that the driver can distinguish between media and render
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
support media decompression.
v2: Fix checkpatch warnings on code style (Lucas)
From DK:
Separate modifier array for planes that cannot decompress media (Ville)
v3: Support planar formats
Cc: Nanley G Chery
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 237 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 44 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 220 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index be61dfdebb34..448168a4d780 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1909,6 +1909,10 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
if (color_plane == 1)
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ if (color_plane == 3)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
if (color_plane == 1)
return 64;
@@ -2251,8 +2255,16 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
static bool is_surface_linear(u64 modifier, int color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR ||
- (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
+ switch (modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ return true;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ return color_plane == 1;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ return color_plane == 1 || color_plane == 3;
+ default:
+ return false;
+ }
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2440,6 +2452,7 @@ static unsigned int intel_fb_modifier_to_tiling(u64
fb_modifier)
case I915_FORMAT_MOD_Y_TILED:
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:
return I915_TILING_Y;
default:
return I915_TILING_NONE;
@@ -2487,6 +2500,10 @@ static const struct drm_format_info gen12_ccs_formats[]
= {
.cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
{ .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
.cpp = { 4, 1, }, .hsub = 2, .vsub = 32, .has_alpha = true },
+ { .format = DRM_FORMAT_YUYV, .num_planes = 2,
+ .cpp = { 2, 1, }, .hsub = 4, .vsub = 32, .is_yuv = true },
+ { .format = DRM_FORMAT_NV12, .num_planes = 4,
+ .cpp = { 1, 1, 2, 1}, .hsub = 2, .vsub = 2, .is_yuv = true },
};
static const struct drm_format_info *
@@ -2524,6 +2541,7 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
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 ||
modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
}
@@ -2587,7 +2605,7 @@ intel_fb_stride_alignment(const struct drm_framebuffer
*fb, int color_plane)
}
tile_width = intel_tile_width_bytes(fb, color_plane);
- if (is_ccs_modifier(fb->modifier) && color_plane == 0) {
+ if (is_ccs_modifier(fb->modifier)) {
/*
* Display WA #0531: skl,bxt,kbl,glk
*
@@ -2597,7 +2615,7 @@ intel_fb_stride_alignment(const struct drm_framebuffer
*fb, int color_plane)
* require the entire fb to accommodate that to avoid
* potential runtime errors at plane configuration time.
*/
- if (IS_GEN(dev_priv, 9) && fb->width > 3840)
+ if (IS_GEN(dev_priv, 9) && color_plane == 0 && fb->width > 3840)
tile_width *= 4;
/*
* The main surface pitch must be padded to a multiple of four
@@ -2677,25 +2695,71 @@ static bool intel_plane_needs_remap(const struct
intel_plane_state *plane_state)
return stride > max_stride;
}
+static void
+intel_fb_plane_get_subsampling(int *hsub, int *vsub, const struct
drm_framebuffer *fb, int color_plane)
+{
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS) {
+ static const struct {
+
[Intel-gfx] [PATCH v4 00/10] Clear Color Support for TGL Render Decompression
Support for Clear Color is contained in the last two patches submitted by Radhakrishna Sripada. The first 8 patches are currently undergoing review/revision changes. The first 8 patches are cherry-picked from the series https://patchwork.freedesktop.org/series/67078/ Expecting feedback for the last 2 patches. The series is tested with kms_cube and custom Mesa branch by Nanley. Dhinakaran Pandiyan (8): drm/framebuffer: Format modifier for Intel Gen-12 render compression drm/i915: Use intel_tile_height() instead of re-implementing drm/i915: Move CCS stride alignment W/A inside intel_fb_stride_alignment drm/i915/tgl: Gen-12 render decompression drm/i915: Extract framebufer CCS offset checks into a function drm/framebuffer: Format modifier for Intel Gen-12 media compression drm/fb: Extend format_info member arrays to handle four planes Gen-12 display can decompress surfaces compressed by the media engine. Radhakrishna Sripada (2): drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color drm/i915/tgl: Add Clear Color supoort for TGL Render Decompression drivers/gpu/drm/i915/display/intel_display.c | 434 ++ .../drm/i915/display/intel_display_types.h| 5 +- drivers/gpu/drm/i915/display/intel_sprite.c | 70 ++- drivers/gpu/drm/i915/i915_reg.h | 14 + include/drm/drm_fourcc.h | 8 +- include/uapi/drm/drm_fourcc.h | 35 ++ 6 files changed, 452 insertions(+), 114 deletions(-) -- 2.20.1 ___ 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 [01/10] drm/i915/gem: Distinguish each object type
== Series Details ==
Series: series starting with [01/10] drm/i915/gem: Distinguish each object type
URL : https://patchwork.freedesktop.org/series/67993/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7091 -> Patchwork_14800
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14800 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14800, 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_14800/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14800:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_execlists:
- fi-whl-u: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-whl-u/igt@i915_selftest@live_execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/fi-whl-u/igt@i915_selftest@live_execlists.html
Known issues
Here are the changes found in Patchwork_14800 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[fdo#111381])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r: [PASS][5] -> [DMESG-FAIL][6] ([fdo#111991])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111045] / [fdo#111096])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@kms_chamelium@hdmi-crc-fast:
- {fi-icl-u4}:[FAIL][9] ([fdo#111045]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u4/igt@kms_chamel...@hdmi-crc-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/fi-icl-u4/igt@kms_chamel...@hdmi-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
[fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3
fi-icl-y fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7091 -> Patchwork_14800
CI-20190529: 20190529
CI_DRM_7091: d88a66d195bcf71e6e05db07ba79c9fab5651f22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14800: b88cc9a5a4701e5ff615ca8b3e9aa357519d0e53 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b88cc9a5a470 drm/i915: Flush idle barriers when waiting
421c67f49932 drm/i915/execlist: Trim immediate timeslice expiry
34e034553df9 drm/i915: Replace hangcheck by heartbeats
cf3885efda88 drm/i915/gem: Cancel non-persistent contexts on close
93be9bc402fe drm/i915/execlists: Cancel banned contexts on schedule-out
f7572b61513c drm/i915/gt: Introduce barrier pulses along engines
830c4a550728 drm/i915/execlists: Force preemption
0d48df570887 drm/i915: Expose engine properties via sysfs
7b18d5f62f34 drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
560c3f3d40a2 drm/i915/gem: Distinguish each object type
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14800/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
> -Original Message- > From: Jani Nikula on October 13, 2019 11:00 PM > On Sun, 13 Oct 2019, Changbin Du wrote: > > The 'functions' directive is not only for functions, but also works for > > structs/unions. So the name is misleading. This patch renames it to > > 'specific', so now we have export/internal/specific directives to limit > > the functions/types to be included in documentation. Meanwhile we > improved > > the warning message. > > Agreed on "functions" being less than perfect. It directly exposes the > idiosyncrasies of scripts/kernel-doc. I'm not sure "specific" is any > better, though. I strongly agree with this. 'specific' IMHO, has no semantic value and I'd rather just leave the only-sometimes-wrong 'functions' than convert to something that obscures the meaning always. > > Perhaps "symbols" would be more self-explanatory. Or, actually make > "functions" only work on functions, and add a separate keyword for other > stuff. *shrug* My preference would be to use 'symbols'. I tried to come up with something but 'symbols' is better than anything I came up with. > > Seems like the patch is way too big. I'd probably add "symbols" (or > whatever) as a synonym for "functions" for starters, and convert > documents piecemeal, and finally drop the old one. > > The scripts/kernel-doc change should be a patch of its own. Agreed on these two points as well. Just adding my 2 cents. -- Tim ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] drm/i915/gem: Distinguish each object type
== Series Details == Series: series starting with [01/10] drm/i915/gem: Distinguish each object type URL : https://patchwork.freedesktop.org/series/67993/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/gem: Distinguish each object type Okay! Commit: drm/i915/execlists: Clear semaphore immediately upon ELSP promotion Okay! Commit: drm/i915: Expose engine properties via sysfs - +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:52:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:53:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:57:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:73:20: error: undefined identifier 'engine' +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:96:9: error: cannot size expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:99:9: error: cannot size expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:99:9: error: cannot size expression +drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:99:9: error: cannot size expression Commit: drm/i915/execlists: Force preemption Okay! Commit: drm/i915/gt: Introduce barrier pulses along engines Okay! Commit: drm/i915/execlists: Cancel banned contexts on schedule-out Okay! Commit: drm/i915/gem: Cancel non-persistent contexts on close Okay! Commit: drm/i915: Replace hangcheck by heartbeats Okay! Commit: drm/i915/execlist: Trim immediate timeslice expiry Okay! Commit: drm/i915: Flush idle barriers when waiting Okay! ___ 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 [01/10] drm/i915/gem: Distinguish each object type
== Series Details ==
Series: series starting with [01/10] drm/i915/gem: Distinguish each object type
URL : https://patchwork.freedesktop.org/series/67993/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
560c3f3d40a2 drm/i915/gem: Distinguish each object type
7b18d5f62f34 drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
0d48df570887 drm/i915: Expose engine properties via sysfs
-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#72:
new file mode 100644
-:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#77: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:1:
+/*
-:78: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#78: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:2:
+ * SPDX-License-Identifier: MIT
-:177: CHECK:SPACING: No space is necessary after a cast
#177: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:101:
+show_unknown ? BITS_PER_TYPE(typeof(caps)) : count) {
-:288: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#288: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.h:1:
+/*
-:289: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#289: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.h:2:
+ * SPDX-License-Identifier: MIT
total: 0 errors, 5 warnings, 1 checks, 244 lines checked
830c4a550728 drm/i915/execlists: Force preemption
f7572b61513c drm/i915/gt: Introduce barrier pulses along engines
-:29: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#29:
new file mode 100644
-:34: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#34: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:1:
+/*
-:35: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#35: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:2:
+ * SPDX-License-Identifier: MIT
-:96: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#96: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:1:
+/*
-:97: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#97: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:2:
+ * SPDX-License-Identifier: MIT
total: 0 errors, 5 warnings, 0 checks, 92 lines checked
93be9bc402fe drm/i915/execlists: Cancel banned contexts on schedule-out
cf3885efda88 drm/i915/gem: Cancel non-persistent contexts on close
34e034553df9 drm/i915: Replace hangcheck by heartbeats
-:267: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to
using 'heartbeat', this function's name, in a string
#267: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:99:
+ "stopped heartbeat on %s",
-:423: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#423: FILE: drivers/gpu/drm/i915/gt/intel_engine_sysfs.c:199:
+ heartbeat_interval_show, heartbeat_interval_store);$
-:566: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#566:
deleted file mode 100644
total: 0 errors, 3 warnings, 0 checks, 696 lines checked
421c67f49932 drm/i915/execlist: Trim immediate timeslice expiry
b88cc9a5a470 drm/i915: Flush idle barriers when waiting
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Introduce Jasper Lake PCH
== Series Details ==
Series: drm/i915: Introduce Jasper Lake PCH
URL : https://patchwork.freedesktop.org/series/67992/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7091 -> Patchwork_14799
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14799 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14799, 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_14799/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14799:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_active:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-skl-lmem/igt@i915_selftest@live_active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/fi-skl-lmem/igt@i915_selftest@live_active.html
Known issues
Here are the changes found in Patchwork_14799 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- 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_7091/fi-icl-u3/igt@gem_mmap_...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/fi-icl-u3/igt@gem_mmap_...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#109483])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bsw-n3050: [PASS][7] -> [FAIL][8] ([fdo#100368])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vblank.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vblank.html
Possible fixes
* igt@gem_mmap_gtt@basic-read-no-prefault:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7091/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
Participating hosts (52 -> 46)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7091 -> Patchwork_14799
CI-20190529: 20190529
CI_DRM_7091: d88a66d195bcf71e6e05db07ba79c9fab5651f22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14799: 6b73730cea4a58518b50c3616fd7802a133b0758 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6b73730cea4a drm/i915: Introduce Jasper Lake PCH
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14799/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Introduce Jasper Lake PCH
On Mon, 14 Oct 2019 15:43:41 -0700
Matt Roper wrote:
> The Jasper Lake PCH follows ICP/TGP's south display behavior and is
> identical to MCC graphics-wise except that it does not use the unusual
> (port C -> TC1) pin mapping that MCC does.
>
> Also, it turns out the extra PCH ID that we had previously thought
> was a form of MCC is actually a second ID for JSP (i.e., port C uses
> the port C pins instead of the TC1 pins).
>
> v2:
> - Also update the port masks (not just the pin table) in
>mcc_hpd_irq_setup. (Vivek)
>
> Cc: José Roberto de Souza
> Cc: James Ausmus
> Cc: Vivek Kasireddy
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_irq.c | 31 +--
> drivers/gpu/drm/i915/intel_pch.c | 6 +-
> drivers/gpu/drm/i915/intel_pch.h | 5 -
> 3 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index d20ca02d3166..81e9ed48ce9f
> 100644 --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2248,11 +2248,18 @@ static void icp_irq_handler(struct
> drm_i915_private *dev_priv, u32 pch_iir) tc_hotplug_trigger = pch_iir
> & SDE_TC_MASK_TGP; tc_port_hotplug_long_detect =
> tgp_tc_port_hotplug_long_detect; pins = hpd_tgp;
> + } else if (HAS_PCH_JSP(dev_priv)) {
> + ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
> + tc_hotplug_trigger = 0;
> + pins = hpd_tgp;
> } else if (HAS_PCH_MCC(dev_priv)) {
> ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> tc_hotplug_trigger = pch_iir &
> SDE_TC_HOTPLUG_ICP(PORT_TC1); pins = hpd_icp;
> } else {
> + WARN(!HAS_PCH_ICP(dev_priv),
> + "Unrecognized PCH type 0x%x\n",
> INTEL_PCH_TYPE(dev_priv)); +
> ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> tc_port_hotplug_long_detect =
> icp_tc_port_hotplug_long_detect; @@ -3373,15 +3380,27 @@ static void
> icp_hpd_irq_setup(struct drm_i915_private *dev_priv, }
>
> /*
> - * EHL doesn't need most of gen11_hpd_irq_setup, it's handling only
> the
> + * EHL/JSL don't need most of gen11_hpd_irq_setup, they're handling
> only the
> * equivalent of SDE.
> + *
> + * Note that MCC and JSP have different port C pin mappings, hence
> the use of
> + * ICP's masks & tables (hpd C on TC1) vs TGP's masks & tables (hpd
> C on DDIC)
> + * depending on platform.
> */
> static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> - icp_hpd_irq_setup(dev_priv,
> - SDE_DDI_MASK_ICP,
> SDE_TC_HOTPLUG_ICP(PORT_TC1),
> - ICP_DDI_HPD_ENABLE_MASK,
> ICP_TC_HPD_ENABLE(PORT_TC1),
> - hpd_icp);
> + if (HAS_PCH_JSP(dev_priv))
> + icp_hpd_irq_setup(dev_priv,
> + SDE_DDI_MASK_TGP, 0,
> + TGP_DDI_HPD_ENABLE_MASK, 0,
> + hpd_tgp);
> + else
> + icp_hpd_irq_setup(dev_priv,
> + SDE_DDI_MASK_ICP,
> + SDE_TC_HOTPLUG_ICP(PORT_TC1),
> + ICP_DDI_HPD_ENABLE_MASK,
> + ICP_TC_HPD_ENABLE(PORT_TC1),
> + hpd_icp);
Although MCC and JSL PCH are similar, wouldn't it be a bit cleaner if we
had a separate function for JSP? Something like jsp_hpd_irq_setup()...
Regarldess, this patch is
Reviewed-by: Vivek Kasireddy
Thanks,
Vivek
> }
>
> static void gen11_hpd_detection_setup(struct drm_i915_private
> *dev_priv) @@ -4315,7 +4334,7 @@ void intel_irq_init(struct
> drm_i915_private *dev_priv) if (I915_HAS_HOTPLUG(dev_priv))
> dev_priv->display.hpd_irq_setup =
> i915_hpd_irq_setup; } else {
> - if (HAS_PCH_MCC(dev_priv))
> + if (HAS_PCH_MCC(dev_priv) || HAS_PCH_JSP(dev_priv))
> dev_priv->display.hpd_irq_setup =
> mcc_hpd_irq_setup; else if (INTEL_GEN(dev_priv) >= 11)
> dev_priv->display.hpd_irq_setup =
> gen11_hpd_irq_setup; diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c index 15f8bff141f9..1035d3d46fd8
> 100644 --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -79,7 +79,6 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id) WARN_ON(!IS_ICELAKE(dev_priv));
> return PCH_ICP;
> case INTEL_PCH_MCC_DEVICE_ID_TYPE:
> - case INTEL_PCH_MCC2_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Mule Creek Canyon PCH\n");
> WARN_ON(!IS_ELKHARTLAKE(dev_priv));
> return PCH_MCC;
> @@ -87,6 +86,11 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id) DRM_DEBUG_KMS("Found Tiger Lake LP
> PCH\n"); WARN_ON(!IS_TIG
[Intel-gfx] [PATCH v2] drm/i915: Introduce Jasper Lake PCH
The Jasper Lake PCH follows ICP/TGP's south display behavior and is
identical to MCC graphics-wise except that it does not use the unusual
(port C -> TC1) pin mapping that MCC does.
Also, it turns out the extra PCH ID that we had previously thought was a
form of MCC is actually a second ID for JSP (i.e., port C uses the port
C pins instead of the TC1 pins).
v2:
- Also update the port masks (not just the pin table) in
mcc_hpd_irq_setup. (Vivek)
Cc: José Roberto de Souza
Cc: James Ausmus
Cc: Vivek Kasireddy
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 31 +--
drivers/gpu/drm/i915/intel_pch.c | 6 +-
drivers/gpu/drm/i915/intel_pch.h | 5 -
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d20ca02d3166..81e9ed48ce9f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2248,11 +2248,18 @@ static void icp_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_TGP;
tc_port_hotplug_long_detect = tgp_tc_port_hotplug_long_detect;
pins = hpd_tgp;
+ } else if (HAS_PCH_JSP(dev_priv)) {
+ ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+ tc_hotplug_trigger = 0;
+ pins = hpd_tgp;
} else if (HAS_PCH_MCC(dev_priv)) {
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
tc_hotplug_trigger = pch_iir & SDE_TC_HOTPLUG_ICP(PORT_TC1);
pins = hpd_icp;
} else {
+ WARN(!HAS_PCH_ICP(dev_priv),
+"Unrecognized PCH type 0x%x\n", INTEL_PCH_TYPE(dev_priv));
+
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
tc_port_hotplug_long_detect = icp_tc_port_hotplug_long_detect;
@@ -3373,15 +3380,27 @@ static void icp_hpd_irq_setup(struct drm_i915_private
*dev_priv,
}
/*
- * EHL doesn't need most of gen11_hpd_irq_setup, it's handling only the
+ * EHL/JSL don't need most of gen11_hpd_irq_setup, they're handling only the
* equivalent of SDE.
+ *
+ * Note that MCC and JSP have different port C pin mappings, hence the use of
+ * ICP's masks & tables (hpd C on TC1) vs TGP's masks & tables (hpd C on DDIC)
+ * depending on platform.
*/
static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
- icp_hpd_irq_setup(dev_priv,
- SDE_DDI_MASK_ICP, SDE_TC_HOTPLUG_ICP(PORT_TC1),
- ICP_DDI_HPD_ENABLE_MASK, ICP_TC_HPD_ENABLE(PORT_TC1),
- hpd_icp);
+ if (HAS_PCH_JSP(dev_priv))
+ icp_hpd_irq_setup(dev_priv,
+ SDE_DDI_MASK_TGP, 0,
+ TGP_DDI_HPD_ENABLE_MASK, 0,
+ hpd_tgp);
+ else
+ icp_hpd_irq_setup(dev_priv,
+ SDE_DDI_MASK_ICP,
+ SDE_TC_HOTPLUG_ICP(PORT_TC1),
+ ICP_DDI_HPD_ENABLE_MASK,
+ ICP_TC_HPD_ENABLE(PORT_TC1),
+ hpd_icp);
}
static void gen11_hpd_detection_setup(struct drm_i915_private *dev_priv)
@@ -4315,7 +4334,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (I915_HAS_HOTPLUG(dev_priv))
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else {
- if (HAS_PCH_MCC(dev_priv))
+ if (HAS_PCH_MCC(dev_priv) || HAS_PCH_JSP(dev_priv))
dev_priv->display.hpd_irq_setup = mcc_hpd_irq_setup;
else if (INTEL_GEN(dev_priv) >= 11)
dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index 15f8bff141f9..1035d3d46fd8 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -79,7 +79,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
WARN_ON(!IS_ICELAKE(dev_priv));
return PCH_ICP;
case INTEL_PCH_MCC_DEVICE_ID_TYPE:
- case INTEL_PCH_MCC2_DEVICE_ID_TYPE:
DRM_DEBUG_KMS("Found Mule Creek Canyon PCH\n");
WARN_ON(!IS_ELKHARTLAKE(dev_priv));
return PCH_MCC;
@@ -87,6 +86,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
DRM_DEBUG_KMS("Found Tiger Lake LP PCH\n");
WARN_ON(!IS_TIGERLAKE(dev_priv));
return PCH_TGP;
+ case INTEL_PCH_JSP_DEVICE_ID_TYPE:
+ case INTEL_PCH_JSP2_DEVICE_ID_TYPE:
+ DRM_DEBUG_KMS("Found Jasper Lake PCH\n");
+ WARN_ON(!IS_ELKHARTLAKE(dev_priv));
+
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/4] drm/i915/perf: introduce a versioning of the i915-perf uapi
== Series Details == Series: series starting with [CI,1/4] drm/i915/perf: introduce a versioning of the i915-perf uapi URL : https://patchwork.freedesktop.org/series/67990/ State : failure == Summary == Applying: drm/i915/perf: introduce a versioning of the i915-perf uapi Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_getparam.c M drivers/gpu/drm/i915/i915_perf.c M drivers/gpu/drm/i915/i915_perf.h M include/uapi/drm/i915_drm.h Falling back to patching base and 3-way merge... Auto-merging include/uapi/drm/i915_drm.h Auto-merging drivers/gpu/drm/i915/i915_perf.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_perf.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/perf: introduce a versioning of the i915-perf uapi When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/i915/perf: Add helper macros for comparing with whitelisted registers
== Series Details == Series: series starting with [1/3] drm/i915/perf: Add helper macros for comparing with whitelisted registers URL : https://patchwork.freedesktop.org/series/67987/ State : failure == Summary == Applying: drm/i915/perf: Add helper macros for comparing with whitelisted registers Applying: drm/i915/tgl: Add perf support on TGL error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_perf.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0002 drm/i915/tgl: Add perf support on TGL When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Replace hangcheck by heartbeats
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
The heartbeat interval can be adjusted per-engine using,
/sys/class/drm/card?/engine/*/heartbeat_interval_ms
v2: Couple in sysfs controls
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Reviewed-by: Jon Bloomfield
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Kconfig.profile | 14 +
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 -
drivers/gpu/drm/i915/gt/intel_engine.h| 32 --
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 128 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 5 +
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_sysfs.c | 40 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 17 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 1 -
drivers/gpu/drm/i915/gt/intel_gt.h| 4 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 9 -
drivers/gpu/drm/i915/gt/intel_hangcheck.c | 361 --
drivers/gpu/drm/i915/gt/intel_reset.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 -
drivers/gpu/drm/i915/i915_debugfs.c | 87 -
drivers/gpu/drm/i915/i915_drv.c | 3 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gpu_error.c | 33 +-
drivers/gpu/drm/i915/i915_gpu_error.h | 2 -
drivers/gpu/drm/i915/i915_priolist_types.h| 6 +
25 files changed, 218 insertions(+), 555 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/gt/intel_hangcheck.c
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 8fceea85937b..4bed293e1fb4 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -40,3 +40,17 @@ config DRM_I915_PREEMPT_TIMEOUT
/sys/class/drm/card?/engine/*/preempt_timeout_ms
May be 0 to disable the timeout.
+
+config DRM_I915_HEARTBEAT_INTERVAL
+ int "Interval between heartbeat pulses (ms)"
+ default 2500 # milliseconds
+ help
+ The driver sends a periodic heartbeat down all active engines to
+ check the health of the GPU and undertake regular house-keeping of
+ internal driver state.
+
+ This is adjustable via
+ /sys/class/drm/card?/engine/*/heartbeat_interval_ms
+
+ May be 0 to disable heartbeats and therefore disable automatic GPU
+ hang detection.
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cfab7c8585b3..59d356cc406c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,7 +88,6 @@ gt-y += \
gt/intel_gt_pm.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
- gt/intel_hangcheck.o \
gt/intel_lrc.o \
gt/intel_rc6.o \
gt/intel_renderstate.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3cf39fc153b3..a2ef4bcf9242 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14401,7 +14401,7 @@ static void intel_plane_unpin_fb(struct
intel_plane_state *old_plane_state)
static void fb_obj_bump_render_priority(struct drm_i915_gem_object *obj)
{
struct i915_sched_attr attr = {
- .priority = I915_PRIORITY_DISPLAY,
+ .priority = I915_USER_PRIORITY(I915_PRIORITY_DISPLAY),
};
i915_gem_object_wait_priority(obj, 0, &attr);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index b0245585b4d5..817ea0725e43 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -461,6 +461,5 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
const struct i915_sched_attr *attr);
-#define I915_PRIORITY_DISPLAY I915_USER_PRIORITY(I915_PRIORITY_MAX)
#endif
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 7987b54fb1f5..0e97520cb1bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -100,8 +100,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
intel_gt_suspend(&i915->gt);
intel_uc_suspend(&
[Intel-gfx] [PATCH 04/10] drm/i915/execlists: Force preemption
If the preempted context takes too long to relinquish control, e.g. it
is stuck inside a shader with arbitration disabled, evict that context
with an engine reset. This ensures that preemptions are reasonably
responsive, providing a tighter QoS for the more important context at
the cost of flagging unresponsive contexts more frequently (i.e. instead
of using an ~10s hangcheck, we now evict at ~100ms). The challenge of
lies in picking a timeout that can be reasonably serviced by HW for
typical workloads, balancing the existing clients against the needs for
responsiveness.
Note that coupled with timeslicing, this will lead to rapid GPU "hang"
detection with multiple active contexts vying for GPU time.
The preempt timeout can be adjusted per-engine using,
/sys/class/drm/card?/engine/*/preempt_timeout_ms
v2: Couple in sysfs control of preemption timeout
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/Kconfig.profile | 15 +++
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +
drivers/gpu/drm/i915/gt/intel_engine_sysfs.c | 33 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 127 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 98 ++
drivers/gpu/drm/i915/i915_params.h | 2 +-
7 files changed, 277 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 48df8889a88a..8fceea85937b 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -25,3 +25,18 @@ config DRM_I915_SPIN_REQUEST
May be 0 to disable the initial spin. In practice, we estimate
the cost of enabling the interrupt (if currently disabled) to be
a few microseconds.
+
+config DRM_I915_PREEMPT_TIMEOUT
+ int "Preempt timeout (ms)"
+ default 100 # milliseconds
+ help
+ How long to wait (in milliseconds) for a preemption event to occur
+ when submitting a new context via execlists. If the current context
+ does not hit an arbitration point and yield to HW before the timer
+ expires, the HW will be reset to allow the more important context
+ to execute.
+
+ This is adjustable via
+ /sys/class/drm/card?/engine/*/preempt_timeout_ms
+
+ May be 0 to disable the timeout.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c9d639c6becb..1eb51147839a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -304,6 +304,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->instance = info->instance;
__sprint_engine_name(engine);
+ engine->props.preempt_timeout = CONFIG_DRM_I915_PREEMPT_TIMEOUT;
+
/*
* To be overridden by the backend on setup. However to facilitate
* cleanup on error during setup, we always provide the destroy vfunc.
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
index 823153e56c67..1aae83eb4237 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
@@ -133,6 +133,34 @@ all_caps_show(struct kobject *kobj, struct kobj_attribute
*attr, char *buf)
static struct kobj_attribute all_caps_attr =
__ATTR(known_capabilities, 0444, all_caps_show, NULL);
+static ssize_t
+preempt_timeout_show(struct kobject *kobj, struct kobj_attribute *attr,
+char *buf)
+{
+ struct intel_engine_cs *engine = kobj_to_engine(kobj);
+
+ return sprintf(buf, "%lu\n", engine->props.preempt_timeout);
+}
+
+static ssize_t
+preempt_timeout_store(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct intel_engine_cs *engine = kobj_to_engine(kobj);
+ unsigned long timeout;
+ int err;
+
+ err = kstrtoul(buf, 0, &timeout);
+ if (err)
+ return err;
+
+ WRITE_ONCE(engine->props.preempt_timeout, timeout);
+ return count;
+}
+
+static struct kobj_attribute preempt_timeout_attr =
+__ATTR(preempt_timeout_ms, 0644, preempt_timeout_show, preempt_timeout_store);
+
static void kobj_engine_release(struct kobject *kobj)
{
kfree(kobj);
@@ -193,6 +221,11 @@ void intel_engines_add_sysfs(struct drm_i915_private *i915)
if (sysfs_create_files(kobj, files))
goto err_object;
+ if (CONFIG_DRM_I915_PREEMPT_TIMEOUT &&
+ intel_engine_has_preemption(engine) &&
+ sysfs_create_file(kobj, &preempt_timeout_attr.attr))
+ goto err_engine;
+
if (0) {
err_object:
kobject_put(kobj);
diff --git a/drive
[Intel-gfx] [PATCH 07/10] drm/i915/gem: Cancel non-persistent contexts on close
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangcheck mechanism. We are looking at perhaps replacing hangcheck
with a softer mechanism, that sends a pulse down the engine to check if
it is well. We can use the same preemptive pulse to flush an active
persistent context off the GPU upon context close, preventing resources
being lost and unkillable requests remaining on the GPU after process
termination. To avoid changing the ABI and accidentally breaking
existing userspace, we make the persistence of a context explicit and
enable it by default (matching current ABI). Userspace can opt out of
persistent mode (forcing requests to be cancelled when the context is
closed by process termination or explicitly) by a context parameter. To
facilitate existing use-cases of disabling hangcheck, if the modparam is
disabled (i915.enable_hangcheck=0), we disable persistence mode by
default. (Note, one of the outcomes for supporting endless mode will be
the removal of hangchecking, at which point opting into persistent mode
will be mandatory, or maybe the default perhaps controlled by cgroups.)
v2: Check for hangchecking at context termination, so that we are not
left with undying contexts from a crafty user.
v3: Force context termination even if forced-preemption is disabled.
Testcase: igt/gem_ctx_persistence
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Jon Bloomfield
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 189 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 2 +
include/uapi/drm/i915_drm.h | 15 ++
5 files changed, 222 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5d8221c7ba83..49f37bba5693 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -70,6 +70,7 @@
#include
#include "gt/intel_lrc_reg.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_user.h"
#include "i915_gem_context.h"
@@ -269,6 +270,135 @@ void i915_gem_context_release(struct kref *ref)
schedule_work(&gc->free_work);
}
+static inline struct i915_gem_engines *
+__context_engines_static(const struct i915_gem_context *ctx)
+{
+ return rcu_dereference_protected(ctx->engines, true);
+}
+
+static bool __reset_engine(struct intel_engine_cs *engine)
+{
+ struct intel_gt *gt = engine->gt;
+ bool success = false;
+
+ if (!intel_has_reset_engine(gt))
+ return false;
+
+ if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
+ >->reset.flags)) {
+ success = intel_engine_reset(engine, NULL) == 0;
+ clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
+ >->reset.flags);
+ }
+
+ return success;
+}
+
+static void __reset_context(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
+ "context closure in %s", ctx->name);
+}
+
+static bool __cancel_engine(struct intel_engine_cs *engine)
+{
+ /*
+* Send a "high priority pulse" down the engine to cause the
+* current request to be momentarily preempted. (If it fails to
+* be preempted, it will be reset). As we have marked our context
+* as banned, any incomplete request, including any running, will
+* be skipped following the preemption.
+*
+* If there is no hangchecking (one of the reasons why we try to
+* cancel the context) and no forced preemption, there may be no
+* means by which we reset the GPU and evict the persistent hog.
+* Ergo if we are unable to inject a preemptive pulse that can
+* kill the banned context, we fallback to doing a local reset
+* instead.
+*/
+ if (CONFIG_DRM_I915_PREEMPT_TIMEOUT && !intel_engine_pulse(engine))
+ return true;
+
+ /* If we are unable to send a pulse, try resetting this engine. */
+ return __reset_engine(engine);
+}
+
+static struct intel_engine_cs *
+active_engine(struct dma_fence *fence, struct intel_context *ce)
+{
+ struct i915_request *rq = to_request(fence);
+ struct intel_engine_cs *engine, *locked;
+
+ /*
+* Serialise with __i915_request_submit() so that it sees
+* is-banned?, or we know the request is already inflight.
+*/
+ locked = READ_ONCE(rq->engine);
+ spin_lock_i
[Intel-gfx] [PATCH 09/10] drm/i915/execlist: Trim immediate timeslice expiry
We perform timeslicing immediately upon receipt of a request that may be
put into the second ELSP slot. The idea behind this was that since we
didn't install the timer if the second ELSP slot was empty, we would not
have any idea of how long ELSP[0] had been running and so giving the
newcomer a chance on the GPU was fair. However, this causes us extra
busy work that we may be able to avoid if we wait a jiffie for the first
timeslice as normal.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 60e897c000b2..f9bf78032ad7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1613,7 +1613,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last->hw_context->lrc_desc |= CTX_DESC_FORCE_RESTORE;
last = NULL;
} else if (need_timeslice(engine, last) &&
- !timer_pending(&engine->execlists.timer)) {
+ timer_expired(&engine->execlists.timer)) {
GEM_TRACE("%s: expired last=%llx:%lld, prio=%d,
hint=%d\n",
engine->name,
last->fence.context,
@@ -2074,6 +2074,8 @@ static void process_csb(struct intel_engine_cs *engine)
if (enable_timeslice(execlists))
mod_timer(&execlists->timer, jiffies + 1);
+ else
+ cancel_timer(&execlists->timer);
WRITE_ONCE(execlists->pending[0], NULL);
} else {
@@ -3591,7 +3593,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request
*request, u32 *cs)
static void execlists_park(struct intel_engine_cs *engine)
{
- del_timer(&engine->execlists.timer);
+ cancel_timer(&engine->execlists.timer);
cancel_timer(&engine->execlists.preempt);
}
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Flush idle barriers when waiting
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 +
drivers/gpu/drm/i915/i915_active.c| 21 +--
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 3a43618693d4..23a8cd89fdeb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -182,3 +182,17 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
intel_engine_pm_put(engine);
return err;
}
+
+int intel_engine_flush_barriers(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ idle_pulse(engine, rq);
+ i915_request_add(rq);
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
index 39391004554d..0c1ad0fc091d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -15,5 +15,6 @@ void intel_engine_park_heartbeat(struct intel_engine_cs
*engine);
void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine);
int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_flush_barriers(struct intel_engine_cs *engine);
#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index aa37c07004b9..98d5fe1c7e19 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -6,6 +6,7 @@
#include
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_pm.h"
#include "i915_drv.h"
@@ -435,6 +436,21 @@ static void enable_signaling(struct i915_active_fence
*active)
dma_fence_put(fence);
}
+static int flush_barrier(struct active_node *it)
+{
+ struct intel_engine_cs *engine;
+
+ if (!is_barrier(&it->base))
+ return 0;
+
+ engine = __barrier_to_engine(it);
+ smp_rmb(); /* serialise with add_active_barriers */
+ if (!is_barrier(&it->base))
+ return 0;
+
+ return intel_engine_flush_barriers(engine);
+}
+
int i915_active_wait(struct i915_active *ref)
{
struct active_node *it, *n;
@@ -448,8 +464,9 @@ int i915_active_wait(struct i915_active *ref)
/* Flush lazy signals */
enable_signaling(&ref->excl);
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- if (is_barrier(&it->base)) /* unconnected idle barrier */
- continue;
+ err = flush_barrier(it); /* unconnected idle barrier? */
+ if (err)
+ break;
enable_signaling(&it->base);
}
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915/execlists: Cancel banned contexts on schedule-out
On schedule-out (CS completion) of a banned context, scrub the context
image so that we do not replay the active payload. The intent is that we
skip banned payloads on request submission so that the timeline
advancement continues on in the background. However, if we are returning
to a preempted request, i915_request_skip() is ineffective and instead we
need to patch up the context image so that it continues from the start
of the next request.
v2: Fixup cancellation so that we only scrub the payload of the active
request and do not short-circuit the breadcrumbs (which might cause
other contexts to execute out of order).
v3: Grammar pass
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 134 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c | 321 +
2 files changed, 414 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ae038af68c6e..60e897c000b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -234,6 +234,9 @@ static void execlists_init_reg_state(u32 *reg_state,
const struct intel_engine_cs *engine,
const struct intel_ring *ring,
bool close);
+static void
+__execlists_update_reg_state(const struct intel_context *ce,
+const struct intel_engine_cs *engine);
static void cancel_timer(struct timer_list *t)
{
@@ -270,6 +273,31 @@ static void mark_eio(struct i915_request *rq)
i915_request_mark_complete(rq);
}
+static struct i915_request *active_request(struct i915_request *rq)
+{
+ const struct intel_context * const ce = rq->hw_context;
+ struct i915_request *active = NULL;
+ struct list_head *list;
+
+ if (!i915_request_is_active(rq)) /* unwound, but incomplete! */
+ return rq;
+
+ rcu_read_lock();
+ list = &rcu_dereference(rq->timeline)->requests;
+ list_for_each_entry_from_reverse(rq, list, link) {
+ if (i915_request_completed(rq))
+ break;
+
+ if (rq->hw_context != ce)
+ break;
+
+ active = rq;
+ }
+ rcu_read_unlock();
+
+ return active;
+}
+
static inline u32 intel_hws_preempt_address(struct intel_engine_cs *engine)
{
return (i915_ggtt_offset(engine->status_page.vma) +
@@ -991,6 +1019,61 @@ static void kick_siblings(struct i915_request *rq, struct
intel_context *ce)
tasklet_schedule(&ve->base.execlists.tasklet);
}
+static void restore_default_state(struct intel_context *ce,
+ struct intel_engine_cs *engine)
+{
+ u32 *regs = ce->lrc_reg_state;
+
+ if (engine->pinned_default_state)
+ memcpy(regs, /* skip restoring the vanilla PPHWSP */
+ engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
+ engine->context_size - PAGE_SIZE);
+
+ execlists_init_reg_state(regs, ce, engine, ce->ring, false);
+}
+
+static void reset_active(struct i915_request *rq,
+struct intel_engine_cs *engine)
+{
+ struct intel_context * const ce = rq->hw_context;
+
+ /*
+* The executing context has been cancelled. We want to prevent
+* further execution along this context and propagate the error on
+* to anything depending on its results.
+*
+* In __i915_request_submit(), we apply the -EIO and remove the
+* requests' payloads for any banned requests. But first, we must
+* rewind the context back to the start of the incomplete request so
+* that we do not jump back into the middle of the batch.
+*
+* We preserve the breadcrumbs and semaphores of the incomplete
+* requests so that inter-timeline dependencies (i.e other timelines)
+* remain correctly ordered. And we defer to __i915_request_submit()
+* so that all asynchronous waits are correctly handled.
+*/
+ GEM_TRACE("%s(%s): { rq=%llx:%lld }\n",
+ __func__, engine->name, rq->fence.context, rq->fence.seqno);
+ __context_pin_acquire(ce);
+
+ /* On resubmission of the active request, payload will be scrubbed */
+ rq = active_request(rq);
+ if (rq)
+ ce->ring->head = intel_ring_wrap(ce->ring, rq->head);
+ else
+ ce->ring->head = ce->ring->tail;
+ intel_ring_update_space(ce->ring);
+
+ /* Scrub the context image to prevent replaying the previous batch */
+ restore_default_state(ce, engine);
+ __execlists_update_reg_state(ce, engine);
+
+ /* We've switched away, so this should be a no-op, but intent matters */
+ ce->lrc_desc |= CTX_DESC_FORCE_RESTORE;
+
+ __context_pin_re
[Intel-gfx] [PATCH 03/10] drm/i915: Expose engine properties via sysfs
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later we will add writeable sysadmin properties such
as per-engine timeout controls.
An example tree of the engine properties on Braswell:
/sys/class/drm/card0
└── engine
├── bcs0
│ ├── capabilities
│ ├── class
│ ├── instance
│ ├── known_capabilities
│ └── name
├── rcs0
│ ├── capabilities
│ ├── class
│ ├── instance
│ ├── known_capabilities
│ └── name
├── vcs0
│ ├── capabilities
│ ├── class
│ ├── instance
│ ├── known_capabilities
│ └── name
└── vecs0
├── capabilities
├── class
├── instance
├── known_capabilities
└── name
v2: Include stringified capabilities
v3: Include all known capabilities for futureproofing.
v4: Combine the two caps loops into one
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Acked-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/Makefile| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_sysfs.c | 205 +++
drivers/gpu/drm/i915/gt/intel_engine_sysfs.h | 14 ++
drivers/gpu/drm/i915/i915_sysfs.c| 3 +
4 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_sysfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e791d9323b51..cd9a10ba2516 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,8 +78,9 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
- gt/intel_engine_pool.o \
gt/intel_engine_pm.o \
+ gt/intel_engine_pool.o \
+ gt/intel_engine_sysfs.o \
gt/intel_engine_user.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
new file mode 100644
index ..823153e56c67
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_sysfs.c
@@ -0,0 +1,205 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+
+#include "i915_drv.h"
+#include "intel_engine.h"
+#include "intel_engine_sysfs.h"
+
+struct kobj_engine {
+ struct kobject base;
+ struct intel_engine_cs *engine;
+};
+
+static struct intel_engine_cs *kobj_to_engine(struct kobject *kobj)
+{
+ return container_of(kobj, struct kobj_engine, base)->engine;
+}
+
+static ssize_t
+name_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%s\n", kobj_to_engine(kobj)->name);
+}
+
+static struct kobj_attribute name_attr =
+__ATTR(name, 0444, name_show, NULL);
+
+static ssize_t
+class_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", kobj_to_engine(kobj)->uabi_class);
+}
+
+static struct kobj_attribute class_attr =
+__ATTR(class, 0444, class_show, NULL);
+
+static ssize_t
+inst_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", kobj_to_engine(kobj)->uabi_instance);
+}
+
+static struct kobj_attribute inst_attr =
+__ATTR(instance, 0444, inst_show, NULL);
+
+static const char * const vcs_caps[] = {
+ [ilog2(I915_VIDEO_CLASS_CAPABILITY_HEVC)] = "hevc",
+ [ilog2(I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC)] = "sfc",
+};
+
+static const char * const vecs_caps[] = {
+ [ilog2(I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC)] = "sfc",
+};
+
+static ssize_t repr_trim(char *buf, ssize_t len)
+{
+ /* Trim off the trailing space and replace with a newline */
+ if (len > PAGE_SIZE)
+ len = PAGE_SIZE;
+ if (len > 0)
+ buf[len - 1] = '\n';
+
+ return len;
+}
+
+static ssize_t
+__caps_show(struct intel_engine_cs *engine,
+ typeof(engine->uabi_capabilities) caps,
+ char *buf, bool show_unknown)
+{
+ const char * const *repr;
+ int count, n;
+ ssize_t len;
+
+ switch (engine->class) {
+ case VIDEO_DECODE_CLASS:
+ repr = vcs_caps;
+ count = ARRAY_SIZE(vcs_caps);
+ break;
+
+ case VIDEO_ENHANCEMENT_CLASS:
+ repr = vecs_caps;
+ count = ARRAY_SIZE(vecs_caps);
+ break;
+
+ default:
+ repr = NULL;
+ count = 0;
+ break;
+ }
+ GEM_BUG_ON(count > BITS_PER_TYPE(typeof(
[Intel-gfx] [PATCH 01/10] drm/i915/gem: Distinguish each object type
Separate each object class into a separate lock type to avoid lockdep
cross-contamination between paths (i.e. userptr!).
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
drivers/gpu/drm/i915/gem/selftests/huge_gem_object.c | 3 ++-
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8 +---
drivers/gpu/drm/i915/gvt/dmabuf.c| 3 ++-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 3 ++-
drivers/gpu/drm/i915/selftests/mock_region.c | 3 ++-
12 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 96ce95c8ac5a..eaea49d08eb5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -256,6 +256,7 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_dmabuf_ops = {
struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ static struct lock_class_key lock_class;
struct dma_buf_attachment *attach;
struct drm_i915_gem_object *obj;
int ret;
@@ -287,7 +288,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
}
drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
- i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops);
+ i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops, &lock_class);
obj->base.import_attach = attach;
obj->base.resv = dma_buf->resv;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index 5ae694c24df4..9cfb0e41ff06 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -164,6 +164,7 @@ struct drm_i915_gem_object *
i915_gem_object_create_internal(struct drm_i915_private *i915,
phys_addr_t size)
{
+ static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
unsigned int cache_level;
@@ -178,7 +179,7 @@ i915_gem_object_create_internal(struct drm_i915_private
*i915,
return ERR_PTR(-ENOMEM);
drm_gem_private_object_init(&i915->drm, &obj->base, size);
- i915_gem_object_init(obj, &i915_gem_object_internal_ops);
+ i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class);
/*
* Mark the object as volatile, such that the pages are marked as
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index dbf9be9a79f4..a50296cce0d8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -47,9 +47,10 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
}
void i915_gem_object_init(struct drm_i915_gem_object *obj,
- const struct drm_i915_gem_object_ops *ops)
+ const struct drm_i915_gem_object_ops *ops,
+ struct lock_class_key *key)
{
- mutex_init(&obj->mm.lock);
+ __mutex_init(&obj->mm.lock, "obj->mm.lock", key);
spin_lock_init(&obj->vma.lock);
INIT_LIST_HEAD(&obj->vma.list);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index c5e14c9c805c..b0245585b4d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -23,7 +23,8 @@ struct drm_i915_gem_object *i915_gem_object_alloc(void);
void i915_gem_object_free(struct drm_i915_gem_object *obj);
void i915_gem_object_init(struct drm_i915_gem_object *obj,
- const struct drm_i915_gem_object_ops *ops);
+ const struct drm_i915_gem_object_ops *ops,
+ struct lock_class_key *key);
struct drm_i915_gem_object *
i915_gem_object_create_shmem(struct drm_i915_private *i915, u64 size);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4c4954e8ce0a..f36f7d658380 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -458,6 +458,7 @@ static int create_shmem(struct drm_i915_private *i915,
struct drm_i915_gem_object *
i915_gem_object_create_shmem(struct drm_i915_private *i915, u64 size)
{
+ static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
[Intel-gfx] [PATCH 02/10] drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
There is no significance to our delay before clearing the semaphore the
engine is waiting on, so release it as soon as we acknowledge the CS
update following our preemption request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 484efe3b4273..21635db8d76c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1910,6 +1910,9 @@ static void process_csb(struct intel_engine_cs *engine)
else
promote = gen8_csb_parse(execlists, buf + 2 * head);
if (promote) {
+ if (!inject_preempt_hang(execlists))
+ ring_set_paused(engine, 0);
+
/* cancel old inflight, prepare for switch */
trace_ports(execlists, "preempted", execlists->active);
while (*execlists->active)
@@ -1926,9 +1929,6 @@ static void process_csb(struct intel_engine_cs *engine)
if (enable_timeslice(execlists))
mod_timer(&execlists->timer, jiffies + 1);
- if (!inject_preempt_hang(execlists))
- ring_set_paused(engine, 0);
-
WRITE_ONCE(execlists->pending[0], NULL);
} else {
GEM_BUG_ON(!*execlists->active);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915/gt: Introduce barrier pulses along engines
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushed, as part of a context cancellation mechanism, or as
part of a heartbeat mechanism to detect and reset a stuck GPU.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 56 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 14 +
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/i915_priolist_types.h| 1 +
5 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cd9a10ba2516..cfab7c8585b3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,6 +78,7 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
+ gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
gt/intel_engine_pool.o \
gt/intel_engine_sysfs.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
new file mode 100644
index ..2fc413f9d506
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -0,0 +1,56 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_request.h"
+
+#include "intel_context.h"
+#include "intel_engine_heartbeat.h"
+#include "intel_engine_pm.h"
+#include "intel_engine.h"
+#include "intel_gt.h"
+
+static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
+ i915_request_add_active_barriers(rq);
+}
+
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
+ struct intel_context *ce = engine->kernel_context;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (!intel_engine_has_preemption(engine))
+ return -ENODEV;
+
+ if (!intel_engine_pm_get_if_awake(engine))
+ return 0;
+
+ if (mutex_lock_interruptible(&ce->timeline->mutex))
+ goto out_rpm;
+
+ intel_context_enter(ce);
+ rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
+ intel_context_exit(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_unlock;
+ }
+
+ rq->flags |= I915_REQUEST_SENTINEL;
+ idle_pulse(engine, rq);
+
+ __i915_request_commit(rq);
+ __i915_request_queue(rq, &attr);
+
+out_unlock:
+ mutex_unlock(&ce->timeline->mutex);
+out_rpm:
+ intel_engine_pm_put(engine);
+ return err;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
new file mode 100644
index ..b950451b5998
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -0,0 +1,14 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef INTEL_ENGINE_HEARTBEAT_H
+#define INTEL_ENGINE_HEARTBEAT_H
+
+struct intel_engine_cs;
+
+int intel_engine_pulse(struct intel_engine_cs *engine);
+
+#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 67eb6183648a..7d76611d9df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -111,7 +111,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
i915_request_add_active_barriers(rq);
/* Install ourselves as a preemption barrier */
- rq->sched.attr.priority = I915_PRIORITY_UNPREEMPTABLE;
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
__i915_request_commit(rq);
/* Release our exclusive hold on the engine */
diff --git a/drivers/gpu/drm/i915/i915_priolist_types.h
b/drivers/gpu/drm/i915/i915_priolist_types.h
index 21037a2e2038..ae8bb3cb627e 100644
--- a/drivers/gpu/drm/i915/i915_priolist_types.h
+++ b/drivers/gpu/drm/i915/i915_priolist_types.h
@@ -39,6 +39,7 @@ enum {
* active request.
*/
#define I915_PRIORITY_UNPREEMPTABLE INT_MAX
+#define I915_PRIORITY_BARRIER INT_MAX
#define __NO_PREEMPTION (I915_PRIORITY_WAIT)
--
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: failure for series starting with [v3,1/3] drm/i915: Add microcontrollers documentation section
== Series Details ==
Series: series starting with [v3,1/3] drm/i915: Add microcontrollers
documentation section
URL : https://patchwork.freedesktop.org/series/67986/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7090 -> Patchwork_14796
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14796 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14796, 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_14796/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14796:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-bsw-kefka/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_14796 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: [PASS][2] -> [DMESG-WARN][3] ([fdo#107724]) +2
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][4] ([fdo#103927] / [fdo#111381]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_mmap_gtt@basic-write-gtt:
- fi-icl-u3: [DMESG-WARN][6] ([fdo#107724]) -> [PASS][7] +1
similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-icl-u3/igt@gem_mmap_...@basic-write-gtt.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-icl-u3/igt@gem_mmap_...@basic-write-gtt.html
* igt@gem_ringfill@basic-default-fd:
- {fi-icl-dsi}: [DMESG-WARN][8] ([fdo#106107]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-icl-dsi/igt@gem_ringf...@basic-default-fd.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-icl-dsi/igt@gem_ringf...@basic-default-fd.html
* igt@kms_busy@basic-flip-a:
- {fi-tgl-u2}:[DMESG-WARN][10] ([fdo#111600]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-tgl-u2/igt@kms_b...@basic-flip-a.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-tgl-u2/igt@kms_b...@basic-flip-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2: [FAIL][12] ([fdo#109635 ] / [fdo#110387]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][14] ([fdo#107718]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][16] ([fdo#111407]) -> [FAIL][17] ([fdo#111045]
/ [fdo#111096])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7090/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14796/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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#44]: https://bugs.freedesktop.org/show_bug.cgi?id=44
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.o
Re: [Intel-gfx] [PATCH] drm/i915: Introduce Jasper Lake PCH
On Mon, 14 Oct 2019 14:24:31 -0700
Matt Roper wrote:
> The Jasper Lake PCH follows ICP/TGP's south display behavior and is
> identical to MCC graphics-wise except that it does not use the unusual
> (port C -> TC1) pin mapping that MCC does.
>
> Also, it turns out the extra PCH ID that we had previously thought
> was a form of MCC is actually a second ID for JSP (i.e., port C uses
> the port C pins instead of the TC1 pins).
>
> Cc: José Roberto de Souza
> Cc: James Ausmus
> Cc: Vivek Kasireddy
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_irq.c | 17 ++---
> drivers/gpu/drm/i915/intel_pch.c | 6 +-
> drivers/gpu/drm/i915/intel_pch.h | 5 -
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index d20ca02d3166..de16576bb5fa
> 100644 --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2248,11 +2248,18 @@ static void icp_irq_handler(struct
> drm_i915_private *dev_priv, u32 pch_iir) tc_hotplug_trigger = pch_iir
> & SDE_TC_MASK_TGP; tc_port_hotplug_long_detect =
> tgp_tc_port_hotplug_long_detect; pins = hpd_tgp;
> + } else if (HAS_PCH_JSP(dev_priv)) {
> + ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
> + tc_hotplug_trigger = 0;
> + pins = hpd_tgp;
> } else if (HAS_PCH_MCC(dev_priv)) {
> ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> tc_hotplug_trigger = pch_iir &
> SDE_TC_HOTPLUG_ICP(PORT_TC1); pins = hpd_icp;
> } else {
> + WARN(!HAS_PCH_ICP(dev_priv),
> + "Unrecognized PCH type 0x%x\n",
> INTEL_PCH_TYPE(dev_priv)); +
> ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> tc_port_hotplug_long_detect =
> icp_tc_port_hotplug_long_detect; @@ -3373,15 +3380,19 @@ static void
> icp_hpd_irq_setup(struct drm_i915_private *dev_priv, }
>
> /*
> - * EHL doesn't need most of gen11_hpd_irq_setup, it's handling only
> the
> + * EHL/JSL don't need most of gen11_hpd_irq_setup, they're handling
> only the
> * equivalent of SDE.
> + *
> + * Note that MCC and JSP have different port C pin mappings, hence
> the use of
> + * ICP's table (hpd C on TC1) vs TGP's table (hpd C on DDIC)
> depending on
> + * platform.
> */
> static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> icp_hpd_irq_setup(dev_priv,
> SDE_DDI_MASK_ICP,
> SDE_TC_HOTPLUG_ICP(PORT_TC1), ICP_DDI_HPD_ENABLE_MASK,
> ICP_TC_HPD_ENABLE(PORT_TC1),
> - hpd_icp);
> + HAS_PCH_JSP(dev_priv) ? hpd_tgp : hpd_icp);
Unless I am misreading this, shouldn't you change the ddi_mask and
ddi_enable_mask to _TGP as well?
Thanks,
Vivek
> }
>
> static void gen11_hpd_detection_setup(struct drm_i915_private
> *dev_priv) @@ -4315,7 +4326,7 @@ void intel_irq_init(struct
> drm_i915_private *dev_priv) if (I915_HAS_HOTPLUG(dev_priv))
> dev_priv->display.hpd_irq_setup =
> i915_hpd_irq_setup; } else {
> - if (HAS_PCH_MCC(dev_priv))
> + if (HAS_PCH_MCC(dev_priv) || HAS_PCH_JSP(dev_priv))
> dev_priv->display.hpd_irq_setup =
> mcc_hpd_irq_setup; else if (INTEL_GEN(dev_priv) >= 11)
> dev_priv->display.hpd_irq_setup =
> gen11_hpd_irq_setup; diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c index 15f8bff141f9..1035d3d46fd8
> 100644 --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -79,7 +79,6 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id) WARN_ON(!IS_ICELAKE(dev_priv));
> return PCH_ICP;
> case INTEL_PCH_MCC_DEVICE_ID_TYPE:
> - case INTEL_PCH_MCC2_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Mule Creek Canyon PCH\n");
> WARN_ON(!IS_ELKHARTLAKE(dev_priv));
> return PCH_MCC;
> @@ -87,6 +86,11 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id) DRM_DEBUG_KMS("Found Tiger Lake LP
> PCH\n"); WARN_ON(!IS_TIGERLAKE(dev_priv));
> return PCH_TGP;
> + case INTEL_PCH_JSP_DEVICE_ID_TYPE:
> + case INTEL_PCH_JSP2_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Jasper Lake PCH\n");
> + WARN_ON(!IS_ELKHARTLAKE(dev_priv));
> + return PCH_JSP;
> default:
> return PCH_NONE;
> }
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h index c29c81ec7971..f4dc18c34291
> 100644 --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -23,6 +23,7 @@ enum intel_pch {
> PCH_SPT,/* Sunrisepoint/Kaby Lake PCH */
> PCH_CNP,/* Cannon/Comet Lake PCH */
> PCH_ICP,/* Ice Lake PCH */
> + PCH_JSP,/* Jasper Lak
[Intel-gfx] [PATCH] drm/i915: Introduce Jasper Lake PCH
The Jasper Lake PCH follows ICP/TGP's south display behavior and is
identical to MCC graphics-wise except that it does not use the unusual
(port C -> TC1) pin mapping that MCC does.
Also, it turns out the extra PCH ID that we had previously thought was a
form of MCC is actually a second ID for JSP (i.e., port C uses the port
C pins instead of the TC1 pins).
Cc: José Roberto de Souza
Cc: James Ausmus
Cc: Vivek Kasireddy
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 17 ++---
drivers/gpu/drm/i915/intel_pch.c | 6 +-
drivers/gpu/drm/i915/intel_pch.h | 5 -
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d20ca02d3166..de16576bb5fa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2248,11 +2248,18 @@ static void icp_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_TGP;
tc_port_hotplug_long_detect = tgp_tc_port_hotplug_long_detect;
pins = hpd_tgp;
+ } else if (HAS_PCH_JSP(dev_priv)) {
+ ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+ tc_hotplug_trigger = 0;
+ pins = hpd_tgp;
} else if (HAS_PCH_MCC(dev_priv)) {
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
tc_hotplug_trigger = pch_iir & SDE_TC_HOTPLUG_ICP(PORT_TC1);
pins = hpd_icp;
} else {
+ WARN(!HAS_PCH_ICP(dev_priv),
+"Unrecognized PCH type 0x%x\n", INTEL_PCH_TYPE(dev_priv));
+
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
tc_port_hotplug_long_detect = icp_tc_port_hotplug_long_detect;
@@ -3373,15 +3380,19 @@ static void icp_hpd_irq_setup(struct drm_i915_private
*dev_priv,
}
/*
- * EHL doesn't need most of gen11_hpd_irq_setup, it's handling only the
+ * EHL/JSL don't need most of gen11_hpd_irq_setup, they're handling only the
* equivalent of SDE.
+ *
+ * Note that MCC and JSP have different port C pin mappings, hence the use of
+ * ICP's table (hpd C on TC1) vs TGP's table (hpd C on DDIC) depending on
+ * platform.
*/
static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
icp_hpd_irq_setup(dev_priv,
SDE_DDI_MASK_ICP, SDE_TC_HOTPLUG_ICP(PORT_TC1),
ICP_DDI_HPD_ENABLE_MASK, ICP_TC_HPD_ENABLE(PORT_TC1),
- hpd_icp);
+ HAS_PCH_JSP(dev_priv) ? hpd_tgp : hpd_icp);
}
static void gen11_hpd_detection_setup(struct drm_i915_private *dev_priv)
@@ -4315,7 +4326,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
if (I915_HAS_HOTPLUG(dev_priv))
dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
} else {
- if (HAS_PCH_MCC(dev_priv))
+ if (HAS_PCH_MCC(dev_priv) || HAS_PCH_JSP(dev_priv))
dev_priv->display.hpd_irq_setup = mcc_hpd_irq_setup;
else if (INTEL_GEN(dev_priv) >= 11)
dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index 15f8bff141f9..1035d3d46fd8 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -79,7 +79,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
WARN_ON(!IS_ICELAKE(dev_priv));
return PCH_ICP;
case INTEL_PCH_MCC_DEVICE_ID_TYPE:
- case INTEL_PCH_MCC2_DEVICE_ID_TYPE:
DRM_DEBUG_KMS("Found Mule Creek Canyon PCH\n");
WARN_ON(!IS_ELKHARTLAKE(dev_priv));
return PCH_MCC;
@@ -87,6 +86,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
DRM_DEBUG_KMS("Found Tiger Lake LP PCH\n");
WARN_ON(!IS_TIGERLAKE(dev_priv));
return PCH_TGP;
+ case INTEL_PCH_JSP_DEVICE_ID_TYPE:
+ case INTEL_PCH_JSP2_DEVICE_ID_TYPE:
+ DRM_DEBUG_KMS("Found Jasper Lake PCH\n");
+ WARN_ON(!IS_ELKHARTLAKE(dev_priv));
+ return PCH_JSP;
default:
return PCH_NONE;
}
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index c29c81ec7971..f4dc18c34291 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -23,6 +23,7 @@ enum intel_pch {
PCH_SPT,/* Sunrisepoint/Kaby Lake PCH */
PCH_CNP,/* Cannon/Comet Lake PCH */
PCH_ICP,/* Ice Lake PCH */
+ PCH_JSP,/* Jasper Lake PCH */
PCH_MCC,/* Mule Creek Canyon PCH */
PCH_TGP,/* Tiger Lake PCH */
};
@@ -44,14 +45,1
[Intel-gfx] ✓ Fi.CI.BAT: success for kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
== Series Details ==
Series: kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
URL : https://patchwork.freedesktop.org/series/67984/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7089 -> Patchwork_14795
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/index.html
Known issues
Here are the changes found in Patchwork_14795 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-icl-u3/igt@gem_mmap_...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-icl-u3/igt@gem_mmap_...@basic.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#109635 ] / [fdo#110387])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#106766])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713] / [fdo#111381]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_ctx_switch@rcs0:
- {fi-cml-s}: [INCOMPLETE][9] ([fdo#110566]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-cml-s/igt@gem_ctx_swi...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-cml-s/igt@gem_ctx_swi...@rcs0.html
* igt@prime_self_import@basic-with_two_bos:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7089/fi-icl-u3/igt@prime_self_import@basic-with_two_bos.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/fi-icl-u3/igt@prime_self_import@basic-with_two_bos.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (52 -> 45)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7089 -> Patchwork_14795
CI-20190529: 20190529
CI_DRM_7089: f62c6f956e3237ae9262027b542af17ea588f5c3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14795: 8314c1dd258cbf157ab7dd0fe31afbd36787fa48 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8314c1dd258c kernel-doc: rename the kernel-doc directive 'functions' to
'specific'
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14795/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
== Series Details == Series: kernel-doc: rename the kernel-doc directive 'functions' to 'specific' URL : https://patchwork.freedesktop.org/series/67984/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8314c1dd258c kernel-doc: rename the kernel-doc directive 'functions' to 'specific' -:2242: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Changbin Du ' total: 0 errors, 1 warnings, 0 checks, 1937 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)
Quoting Ville Syrjälä (2019-10-14 20:23:42)
> On Wed, Oct 09, 2019 at 09:12:23PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats
> > on SNB-BDW sprites (rev2)
> > URL : https://patchwork.freedesktop.org/series/67741/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7042_full -> Patchwork_14725_full
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_14725_full absolutely need
> > to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_14725_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_14725_full:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@gem_eio@in-flight-1us:
> > - shard-snb: [PASS][1] -> [FAIL][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-snb7/igt@gem_...@in-flight-1us.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-snb7/igt@gem_...@in-flight-1us.html
> >
> > * igt@kms_plane@pixel-format-pipe-a-planes:
> > - shard-iclb: [PASS][3] -> [FAIL][4] +13 similar issues
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-iclb7/igt@kms_pl...@pixel-format-pipe-a-planes.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-iclb8/igt@kms_pl...@pixel-format-pipe-a-planes.html
>
> IGT-Version: 1.24-ge501741f
> ...
> Testing format AR30(0x30335241) / modifier 0x103 on A.0
> (kms_plane:1411) igt_fb-CRITICAL: Conversion not implemented (from format
> 0x30335241 to 0x78464749)
>
> DRM_FORMAT_ARGB2101010 = 0x30335241
> IGT_FORMAT_FLOAT = 0x78464749
>
> { .name = "ARGB2101010", .depth = 30, .drm_id = DRM_FORMAT_ARGB2101010,
> .pixman_id = PIXMAN_a2r10g10b10,
>
> { .name = "IGT-FLOAT", .depth = -1, .drm_id = IGT_FORMAT_FLOAT,
> .pixman_id = PIXMAN_rgba_float,
>
> if ((drm_format_to_pixman(cvt->src.fb->drm_format) != PIXMAN_invalid) &&
> (drm_format_to_pixman(cvt->dst.fb->drm_format) != PIXMAN_invalid)) {
> cnvert_pixman(cvt);
> return;
> ...
> igt_assert_f(false, "Conversion not implemented ...);
>
> So wtf?
>
> Are we somehow compiling igt with an old pixman causing
> #if PIXMAN_VERSION < PIXMAN_VERSION_ENCODE(0, 36, 0)
> #define PIXMAN_rgba_float PIXMAN_invalid
> #endif
> to happen?
That's the only way I can see, perhaps stick a #warn in there.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 0/7] mdev based hardware virtio offloading support
On Fri, Oct 11, 2019 at 04:15:50PM +0800, Jason Wang wrote: > There are hardware that can do virtio datapath offloading while having > its own control path. This path tries to implement a mdev based > unified API to support using kernel virtio driver to drive those > devices. This is done by introducing a new mdev transport for virtio > (virtio_mdev) and register itself as a new kind of mdev driver. Then > it provides a unified way for kernel virtio driver to talk with mdev > device implementation. > > Though the series only contains kernel driver support, the goal is to > make the transport generic enough to support userspace drivers. This > means vhost-mdev[1] could be built on top as well by resuing the > transport. > > A sample driver is also implemented which simulate a virito-net > loopback ethernet device on top of vringh + workqueue. This could be > used as a reference implementation for real hardware driver. > > Consider mdev framework only support VFIO device and driver right now, > this series also extend it to support other types. This is done > through introducing class id to the device and pairing it with > id_talbe claimed by the driver. On top, this seris also decouple > device specific parents ops out of the common ones. I was curious so I took a quick look and posted comments. I guess this driver runs inside the guest since it registers virtio devices? If this is used with physical PCI devices that support datapath offloading then how are physical devices presented to the guest without SR-IOV? Stefan signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 6/7] virtio: introduce a mdev based transport
On Fri, Oct 11, 2019 at 04:15:56PM +0800, Jason Wang wrote:
> +struct virtio_mdev_device {
> + struct virtio_device vdev;
> + struct mdev_device *mdev;
> + unsigned long version;
> +
> + struct virtqueue **vqs;
> + /* The lock to protect virtqueue list */
> + spinlock_t lock;
> + struct list_head virtqueues;
Is this a list of struct virtio_mdev_vq_info? Please document the
actual type in a comment.
> +static int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs,
> + struct virtqueue *vqs[],
> + vq_callback_t *callbacks[],
> + const char * const names[],
> + const bool *ctx,
> + struct irq_affinity *desc)
> +{
> + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
> + struct virtio_mdev_callback cb;
> + int i, err, queue_idx = 0;
> +
> + vm_dev->vqs = kmalloc_array(queue_idx, sizeof(*vm_dev->vqs),
> + GFP_KERNEL);
kmalloc_array(0, ...)? I would have expected nvqs instead of queue_idx
(0).
What is this the purpose of vm_dev->vqs and does anything ever access it?
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 5/7] mdev: introduce virtio device and its device ops
On Fri, Oct 11, 2019 at 04:15:55PM +0800, Jason Wang wrote: > + * @set_vq_cb: Set the interrut calback function for s/interrut/interrupt/ s/calback/callback/ signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915/perf: Allow dynamic reconfiguration of the OA stream
Introduce a new perf_ioctl command to change the OA configuration of the
active stream. This allows the OA stream to be reconfigured between
batch buffers, giving greater flexibility in sampling. We inject a
request into the OA context to reconfigure the stream asynchronously on
the GPU in between and ordered with execbuffer calls.
Original patch for dynamic reconfiguration by Lionel Landwerlin.
Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932
Signed-off-by: Chris Wilson
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 46 +++-
include/uapi/drm/i915_drm.h | 13 +
2 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 109782ea30ad..372c91f6a28e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2862,6 +2862,40 @@ static void i915_perf_disable_locked(struct
i915_perf_stream *stream)
stream->ops->disable(stream);
}
+static long i915_perf_config_locked(struct i915_perf_stream *stream,
+ unsigned long metrics_set)
+{
+ struct i915_oa_config *config;
+ long ret = stream->oa_config->id;
+
+ config = i915_perf_get_oa_config(stream->perf, metrics_set);
+ if (!config)
+ return -EINVAL;
+
+ if (config != stream->oa_config) {
+ int err;
+
+ /*
+* If OA is bound to a specific context, emit the
+* reconfiguration inline from that context. The update
+* will then be ordered with respect to submission on that
+* context.
+*
+* When set globally, we use a low priority kernel context,
+* so it will effectively take effect when idle.
+*/
+ err = emit_oa_config(stream, oa_context(stream));
+ if (err == 0)
+ config = xchg(&stream->oa_config, config);
+ else
+ ret = err;
+ }
+
+ i915_oa_config_put(config);
+
+ return ret;
+}
+
/**
* i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
* @stream: An i915 perf stream
@@ -2885,6 +2919,8 @@ static long i915_perf_ioctl_locked(struct
i915_perf_stream *stream,
case I915_PERF_IOCTL_DISABLE:
i915_perf_disable_locked(stream);
return 0;
+ case I915_PERF_IOCTL_CONFIG:
+ return i915_perf_config_locked(stream, arg);
}
return -EINVAL;
@@ -4023,7 +4059,15 @@ void i915_perf_fini(struct drm_i915_private *i915)
*/
int i915_perf_ioctl_version(void)
{
- return 1;
+ /*
+* 1: Initial version
+* I915_PERF_IOCTL_ENABLE
+* I915_PERF_IOCTL_DISABLE
+*
+* 2: Added runtime modification of OA config.
+* I915_PERF_IOCTL_CONFIG
+*/
+ return 2;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0c7b2815fbf1..b008ce8b4e6f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1932,6 +1932,19 @@ struct drm_i915_perf_open_param {
*/
#define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
+/**
+ * Change metrics_set captured by a stream.
+ *
+ * If the stream is bound to a specific context, the configuration change
+ * will performed inline with that context such that it takes effect before
+ * the next execbuf submission.
+ *
+ * Returns the previously bound metrics set id, or a negative error code.
+ *
+ * This ioctl is available in perf revision 2.
+ */
+#define I915_PERF_IOCTL_CONFIG _IO('i', 0x2)
+
/**
* Common to all i915 perf records
*/
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/4] drm/i915/perf: allow holding preemption on filtered ctx
From: Lionel Landwerlin
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of command buffer concept meant that
queries' duration could span multiple command buffers.
With that restriction gone in Vulkan, we would like to simplify
measuring performance just by measuring the deltas between the counter
snapshots written by 2 MI_RECORD_PERF_COUNT commands, rather than the
more complex scheme we currently have in the GL driver, using 2
MI_RECORD_PERF_COUNT commands and doing some post processing on the
stream of OA reports, coming from the global OA buffer, to remove any
unrelated deltas in between the 2 MI_RECORD_PERF_COUNT.
Disabling preemption only apply to a single context with which want to
query performance counters for and is considered a privileged
operation, by default protected by CAP_SYS_ADMIN. It is possible to
enable it for a normal user by disabling the paranoid stream setting.
v2: Store preemption setting in intel_context (Chris)
v3: Use priorities to avoid preemption rather than the HW mechanism
v4: Just modify the port priority reporting function
v5: Add nopreempt flag on gem context and always flag requests
appropriately, regarless of OA reconfiguration.
Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 18 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 ++
drivers/gpu/drm/i915/i915_perf.c | 34 +--
drivers/gpu/drm/i915/i915_perf_types.h| 8 +
include/uapi/drm/i915_drm.h | 11 ++
6 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 9234586830d1..cfe80590f0ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -114,6 +114,24 @@ i915_gem_context_clear_user_engines(struct
i915_gem_context *ctx)
clear_bit(CONTEXT_USER_ENGINES, &ctx->flags);
}
+static inline bool
+i915_gem_context_nopreempt(const struct i915_gem_context *ctx)
+{
+ return test_bit(CONTEXT_NOPREEMPT, &ctx->flags);
+}
+
+static inline void
+i915_gem_context_set_nopreempt(struct i915_gem_context *ctx)
+{
+ set_bit(CONTEXT_NOPREEMPT, &ctx->flags);
+}
+
+static inline void
+i915_gem_context_clear_nopreempt(struct i915_gem_context *ctx)
+{
+ clear_bit(CONTEXT_NOPREEMPT, &ctx->flags);
+}
+
static inline bool i915_gem_context_is_kernel(struct i915_gem_context *ctx)
{
return !ctx->file_priv;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index ab8e1367dfc8..fe97b8ba4fda 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -146,6 +146,7 @@ struct i915_gem_context {
#define CONTEXT_CLOSED 1
#define CONTEXT_FORCE_SINGLE_SUBMISSION2
#define CONTEXT_USER_ENGINES 3
+#define CONTEXT_NOPREEMPT 4
struct mutex mutex;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 98816c35ffc3..e96901888323 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2077,6 +2077,9 @@ static int eb_submit(struct i915_execbuffer *eb)
if (err)
return err;
+ if (i915_gem_context_nopreempt(eb->gem_context))
+ eb->request->flags |= I915_REQUEST_NOPREEMPT;
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 372c91f6a28e..54ec1c4190ac 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -344,6 +344,8 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
* struct perf_open_properties - for validated properties given to open a
stream
* @sample_flags: `DRM_I915_PERF_PROP_SAMPLE_*` properties are tracked as flags
* @single_context: Whether a single or all gpu contexts should be monitored
+ * @hold_preemption: Whether the preemption is disabled for the filtered
+ * context
* @ctx_handle: A gem ctx handle for use with @single_context
* @metrics_set: An ID for an OA unit metric set advertised via sysfs
* @oa_format: An OA unit HW report format
@@ -359,6 +361,7 @@ struct perf_open_properties {
u32 sample_flags;
u64 single_context:1;
+ u64 hold_preemption:1;
u64 ctx_handle;
/* OA sam
[Intel-gfx] [CI 2/4] drm/i915: add support for perf configuration queries
From: Lionel Landwerlin
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v2: Fix sparse warnings (Lionel)
Add support to query configuration using uuid (Lionel)
v3: Fix some inconsistency in uapi header (Lionel)
Fix unlocking when not locked issue (Lionel)
Add debug messages (Lionel)
v4: Fix missing unlock (Dan)
v5: Drop lock when copying config content to userspace (Chris)
v6: Drop lock when copying config list to userspace (Chris)
Fix deadlock when calling i915_perf_get_oa_config() under
perf.metrics_lock (Lionel)
Add i915_oa_config_get() (Chris)
Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_perf.c | 3 +-
drivers/gpu/drm/i915/i915_query.c | 296 ++
include/uapi/drm/i915_drm.h | 62 ++-
3 files changed, 358 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 220e3384af30..109782ea30ad 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3806,8 +3806,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev,
void *data,
GEM_BUG_ON(*arg != oa_config->id);
- sysfs_remove_group(perf->metrics_kobj,
- &oa_config->sysfs_metric);
+ sysfs_remove_group(perf->metrics_kobj, &oa_config->sysfs_metric);
idr_remove(&perf->metrics_idr, *arg);
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index abac5042da2b..c27cfef9281c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -7,6 +7,7 @@
#include
#include "i915_drv.h"
+#include "i915_perf.h"
#include "i915_query.h"
#include
@@ -140,10 +141,305 @@ query_engine_info(struct drm_i915_private *i915,
return len;
}
+static int can_copy_perf_config_registers_or_number(u32 user_n_regs,
+ u64 user_regs_ptr,
+ u32 kernel_n_regs)
+{
+ /*
+* We'll just put the number of registers, and won't copy the
+* register.
+*/
+ if (user_n_regs == 0)
+ return 0;
+
+ if (user_n_regs < kernel_n_regs)
+ return -EINVAL;
+
+ if (!access_ok(u64_to_user_ptr(user_regs_ptr),
+ 2 * sizeof(u32) * kernel_n_regs))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int copy_perf_config_registers_or_number(const struct i915_oa_reg
*kernel_regs,
+ u32 kernel_n_regs,
+ u64 user_regs_ptr,
+ u32 *user_n_regs)
+{
+ u32 r;
+
+ if (*user_n_regs == 0) {
+ *user_n_regs = kernel_n_regs;
+ return 0;
+ }
+
+ *user_n_regs = kernel_n_regs;
+
+ for (r = 0; r < kernel_n_regs; r++) {
+ u32 __user *user_reg_ptr =
+ u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2);
+ u32 __user *user_val_ptr =
+ u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2 +
+ sizeof(u32));
+ int ret;
+
+ ret = __put_user(i915_mmio_reg_offset(kernel_regs[r].addr),
+user_reg_ptr);
+ if (ret)
+ return -EFAULT;
+
+ ret = __put_user(kernel_regs[r].value, user_val_ptr);
+ if (ret)
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+static int query_perf_config_data(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item,
+ bool use_uuid)
+{
+ struct drm_i915_query_perf_config __user *user_query_config_ptr =
+ u64_to_user_ptr(query_item->data_ptr);
+ struct drm_i915_perf_oa_config __user *user_config_ptr =
+ u64_to_user_ptr(query_item->data_ptr +
+ sizeof(struct drm_i915_query_perf_config));
+ struct drm_i915_perf_oa_config user_config;
+ struct i915_perf *perf = &i915->perf;
+ struct i915_oa_config *oa_config;
+ char uuid[UUID_STRING_LEN + 1];
+ u64 config_id;
+ u32 flags, total_size;
+ int ret;
+
+ if (!perf->i915)
+ return -ENODEV;
+
+ total_size =
+ sizeof(struct drm_i915_query_perf_config) +
+ sizeof(struct drm_i915_perf_oa_config);
+
+ if (
[Intel-gfx] [CI 1/4] drm/i915/perf: introduce a versioning of the i915-perf uapi
From: Lionel Landwerlin
Reporting this version will help application figure out what level of
the support the running kernel provides.
v2: Add i915_perf_ioctl_version() (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_getparam.c | 4
drivers/gpu/drm/i915/i915_perf.c | 10 ++
drivers/gpu/drm/i915/i915_perf.h | 1 +
include/uapi/drm/i915_drm.h | 21 +
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index f4b3cbb1adce..ad33fbe90a28 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,7 @@
#include "gt/intel_engine_user.h"
#include "i915_drv.h"
+#include "i915_perf.h"
int i915_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -156,6 +157,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_MMAP_GTT_COHERENT:
value = INTEL_INFO(i915)->has_coherent_ggtt;
break;
+ case I915_PARAM_PERF_REVISION:
+ value = i915_perf_ioctl_version();
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 366580701ba2..220e3384af30 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4017,6 +4017,16 @@ void i915_perf_fini(struct drm_i915_private *i915)
perf->i915 = NULL;
}
+/**
+ * i915_perf_ioctl_version - Version of the i915-perf subsystem
+ *
+ * This version number is used by userspace to detect available features.
+ */
+int i915_perf_ioctl_version(void)
+{
+ return 1;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/i915_perf.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index 98e16be48a73..4ceebce72060 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -22,6 +22,7 @@ void i915_perf_init(struct drm_i915_private *i915);
void i915_perf_fini(struct drm_i915_private *i915);
void i915_perf_register(struct drm_i915_private *i915);
void i915_perf_unregister(struct drm_i915_private *i915);
+int i915_perf_ioctl_version(void);
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 30c542144016..c50c712b3771 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -611,6 +611,13 @@ typedef struct drm_i915_irq_wait {
* See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
*/
#define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
+
+/*
+ * Revision of the i915-perf uAPI. The value returned helps determine what
+ * i915-perf features are available. See drm_i915_perf_property_id.
+ */
+#define I915_PARAM_PERF_REVISION 54
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1844,23 +1851,31 @@ enum drm_i915_perf_property_id {
* Open the stream for a specific context handle (as used with
* execbuffer2). A stream opened for a specific context this way
* won't typically require root privileges.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_CTX_HANDLE = 1,
/**
* A value of 1 requests the inclusion of raw OA unit reports as
* part of stream samples.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_SAMPLE_OA,
/**
* The value specifies which set of OA unit metrics should be
* be configured, defining the contents of any OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_METRICS_SET,
/**
* The value specifies the size and layout of OA unit reports.
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_FORMAT,
@@ -1870,6 +1885,8 @@ enum drm_i915_perf_property_id {
* from this exponent as follows:
*
* 80ns * 2^(period_exponent + 1)
+*
+* This property is available in perf revision 1.
*/
DRM_I915_PERF_PROP_OA_EXPONENT,
@@ -1901,6 +1918,8 @@ struct drm_i915_perf_open_param {
* to close and re-open a stream with the same configuration.
*
* It's undefined whether any pending data for the stream will be lost.
+ *
+ * This ioctl is available in perf revision 1.
*/
#define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
@@ -1908,6 +1927,8 @@ struct drm_i915_perf_open_param {
* Disable data capture for a stream.
*
Re: [Intel-gfx] [PATCH 3/3] drm/i915/perf: enable OAR context save/restore of performance counters
Quoting Umesh Nerlige Ramappa (2019-10-14 19:55:31)
> @@ -2313,6 +2377,17 @@ static int lrc_configure_all_contexts(struct
> i915_perf_stream *stream,
> return err;
> }
>
> + /*
> +* For Gen12, performance counters are context
> +* saved/restored. Only enable it for the context that
> +* requested this.
> +*/
> + if (ctx == stream->ctx && IS_GEN(i915, 12)) {
> + err = gen12_configure_context_oar(ctx, oa_config !=
> NULL);
regs[CTX_CONTEXT_CONTROL] |= intel_lrc_make_ctx_control(engine);
can be modified with a plain LRI (at least I have successfully modified
INHIBIT_SYN_CTX before). Have you tried just emitting an LRI in the pinned
context?
-Chris
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on SNB-BDW sprites (rev2)
On Wed, Oct 09, 2019 at 09:12:23PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/9] drm/i915: Expose 10:10:10 XRGB formats on
> SNB-BDW sprites (rev2)
> URL : https://patchwork.freedesktop.org/series/67741/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7042_full -> Patchwork_14725_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_14725_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_14725_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_14725_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_eio@in-flight-1us:
> - shard-snb: [PASS][1] -> [FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-snb7/igt@gem_...@in-flight-1us.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-snb7/igt@gem_...@in-flight-1us.html
>
> * igt@kms_plane@pixel-format-pipe-a-planes:
> - shard-iclb: [PASS][3] -> [FAIL][4] +13 similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7042/shard-iclb7/igt@kms_pl...@pixel-format-pipe-a-planes.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14725/shard-iclb8/igt@kms_pl...@pixel-format-pipe-a-planes.html
IGT-Version: 1.24-ge501741f
...
Testing format AR30(0x30335241) / modifier 0x103 on A.0
(kms_plane:1411) igt_fb-CRITICAL: Conversion not implemented (from format
0x30335241 to 0x78464749)
DRM_FORMAT_ARGB2101010 = 0x30335241
IGT_FORMAT_FLOAT = 0x78464749
{ .name = "ARGB2101010", .depth = 30, .drm_id = DRM_FORMAT_ARGB2101010,
.pixman_id = PIXMAN_a2r10g10b10,
{ .name = "IGT-FLOAT", .depth = -1, .drm_id = IGT_FORMAT_FLOAT,
.pixman_id = PIXMAN_rgba_float,
if ((drm_format_to_pixman(cvt->src.fb->drm_format) != PIXMAN_invalid) &&
(drm_format_to_pixman(cvt->dst.fb->drm_format) != PIXMAN_invalid)) {
cnvert_pixman(cvt);
return;
...
igt_assert_f(false, "Conversion not implemented ...);
So wtf?
Are we somehow compiling igt with an old pixman causing
#if PIXMAN_VERSION < PIXMAN_VERSION_ENCODE(0, 36, 0)
#define PIXMAN_rgba_float PIXMAN_invalid
#endif
to happen?
But the reference run shows it testing all the fancy YUV formats so
I don't think that can be the case.
And my CHV can run this test with ARGB2101010 just fine so
the code can't be totally broken.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/perf: enable OAR context save/restore of performance counters
From: Lionel Landwerlin
We want this so we can preempt performance queries and keep the system
responsive even when long running queries are ongoing. We avoid doing
it for all contexts.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 23 +---
drivers/gpu/drm/i915/gt/intel_lrc.h | 3 +
drivers/gpu/drm/i915/i915_perf.c| 89 +
3 files changed, 107 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9d8eaf8edaab..1bab671dc7a0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1218,6 +1218,19 @@ static bool can_merge_rq(const struct i915_request *prev,
return true;
}
+u32 intel_lrc_make_ctx_control(const struct intel_engine_cs *engine)
+{
+ u32 value =
+ _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT) |
+ _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
+
+ if (INTEL_GEN(engine->i915) < 11)
+ value |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT |
+ CTX_CTRL_RS_CTX_ENABLE);
+
+ return value;
+}
+
static void virtual_update_register_offsets(u32 *regs,
struct intel_engine_cs *engine)
{
@@ -2124,6 +2137,7 @@ __execlists_update_reg_state(const struct intel_context
*ce,
i915_oa_init_reg_state(ce, engine);
}
+ regs[CTX_CONTEXT_CONTROL] |= intel_lrc_make_ctx_control(engine);
}
static int
@@ -3628,14 +3642,7 @@ static void init_common_reg_state(u32 * const regs,
const struct intel_engine_cs *engine,
const struct intel_ring *ring)
{
- regs[CTX_CONTEXT_CONTROL] =
- _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT) |
- _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
- if (INTEL_GEN(engine->i915) < 11)
- regs[CTX_CONTEXT_CONTROL] |=
- _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT |
- CTX_CTRL_RS_CTX_ENABLE);
-
+ regs[CTX_CONTEXT_CONTROL] = intel_lrc_make_ctx_control(engine);
regs[CTX_RING_BUFFER_CONTROL] = RING_CTL_SIZE(ring->size) | RING_VALID;
regs[CTX_BB_STATE] = RING_BB_PPGTT;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index 99dc576a4e25..6b2b196f09e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -43,6 +43,7 @@ struct intel_engine_cs;
#define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0)
#define CTX_CTRL_RS_CTX_ENABLE (1 << 1)
#define CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT (1 << 2)
+#define GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE (1 << 8)
#define RING_CONTEXT_STATUS_PTR(base) _MMIO((base) + 0x3a0)
#define RING_EXECLIST_SQ_CONTENTS(base)_MMIO((base) + 0x510)
#define RING_EXECLIST_CONTROL(base)_MMIO((base) + 0x550)
@@ -145,4 +146,6 @@ struct intel_engine_cs *
intel_virtual_engine_get_sibling(struct intel_engine_cs *engine,
unsigned int sibling);
+u32 intel_lrc_make_ctx_control(const struct intel_engine_cs *engine);
+
#endif /* _INTEL_LRC_H_ */
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index df3b6976ba5b..d0ddd37dc078 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2208,6 +2208,70 @@ static int gen8_configure_context(struct
i915_gem_context *ctx,
return err;
}
+static int gen12_emit_oar_config(struct intel_context *ce, bool enable)
+{
+ struct i915_request *rq;
+ u32 *cs, offset;
+ int err = 0;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ cs = intel_ring_begin(rq, 4);
+ if (IS_ERR(cs)) {
+ err = PTR_ERR(cs);
+ goto out;
+ }
+
+ offset = i915_ggtt_offset(ce->state) + LRC_STATE_PN * PAGE_SIZE;
+
+ *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+ *cs++ = offset + CTX_CONTEXT_CONTROL * sizeof(u32);
+ *cs++ = 0;
+ *cs++ = intel_lrc_make_ctx_control(ce->engine) |
+ (enable ?
+_MASKED_BIT_ENABLE(GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE) :
+_MASKED_BIT_DISABLE(GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE));
+
+ intel_ring_advance(rq, cs);
+
+out:
+ i915_request_add(rq);
+
+ return err;
+}
+
+static int gen12_configure_context_oar(struct i915_gem_context *ctx,
+ bool enable)
+{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ int err = 0;
+
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ GEM_BUG_ON(ce =
[Intel-gfx] [PATCH 2/3] drm/i915/tgl: Add perf support on TGL
From: Lionel Landwerlin
The design of the OA unit has been split into several units. We now
have a global unit (OAG) and a render specific unit (OAR). This leads
to some changes on how we program things. Some details :
OAR:
- has its own set of counter registers, they are per-context
saved/restored
- counters are not written to the circular OA buffer
- a snapshot of the counters can be acquired with
MI_RECORD_PERF_COUNT, or a single counter can be read with
MI_STORE_REGISTER_MEM.
OAG:
- has global counters that increment across context switches
- counters are written into the circular OA buffer (if requested)
v2: Fix checkpatch warnings on code style (Lucas)
v3: (Umesh)
- Update register from which tail, status and head are read
- Update logic to sample context reports
- Update whitelist mux and b counter regs
BSpec: 28727, 30021
Signed-off-by: Lionel Landwerlin
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 280 +++---
drivers/gpu/drm/i915/i915_reg.h | 103 ++
drivers/gpu/drm/i915/oa/i915_oa_tgl.c | 121 +++
drivers/gpu/drm/i915/oa/i915_oa_tgl.h | 16 ++
5 files changed, 492 insertions(+), 31 deletions(-)
create mode 100644 drivers/gpu/drm/i915/oa/i915_oa_tgl.c
create mode 100644 drivers/gpu/drm/i915/oa/i915_oa_tgl.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e791d9323b51..0ec9fee58baa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -242,7 +242,8 @@ i915-y += \
oa/i915_oa_cflgt2.o \
oa/i915_oa_cflgt3.o \
oa/i915_oa_cnl.o \
- oa/i915_oa_icl.o
+ oa/i915_oa_icl.o \
+ oa/i915_oa_tgl.o
i915-y += i915_perf.o
# Post-mortem debug and GPU hang state capture
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d54d3a41ceca..df3b6976ba5b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -217,6 +217,7 @@
#include "oa/i915_oa_cflgt3.h"
#include "oa/i915_oa_cnl.h"
#include "oa/i915_oa_icl.h"
+#include "oa/i915_oa_tgl.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -292,7 +293,8 @@ static u32 i915_perf_stream_paranoid = true;
#define INVALID_CTX_ID 0x
/* On Gen8+ automatically triggered OA reports include a 'reason' field... */
-#define OAREPORT_REASON_MASK 0x3f
+#define OAREPORT_REASON_MASK (IS_GEN(stream->perf->i915, 12) ? \
+ 0x7f : 0x3f)
#define OAREPORT_REASON_SHIFT 19
#define OAREPORT_REASON_TIMER (1<<0)
#define OAREPORT_REASON_CTX_SWITCH (1<<3)
@@ -338,6 +340,10 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_C4_B8] = { 7, 64 },
};
+static const struct i915_oa_format gen12_oa_formats[I915_OA_FORMAT_MAX] = {
+ [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+};
+
#define SAMPLE_OA_REPORT (1<<0)
/**
@@ -415,6 +421,14 @@ static void free_oa_config_bo(struct i915_oa_config_bo
*oa_bo)
kfree(oa_bo);
}
+static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream)
+{
+ struct intel_uncore *uncore = stream->uncore;
+
+ return intel_uncore_read(uncore, GEN12_OAG_OATAILPTR) &
+ GEN12_OAG_OATAILPTR_MASK;
+}
+
static u32 gen8_oa_hw_tail_read(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
@@ -535,7 +549,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
aging_tail = hw_tail;
stream->oa_buffer.aging_timestamp = now;
} else {
- DRM_ERROR("Ignoring spurious out of range OA buffer
tail pointer = %u\n",
+ DRM_ERROR("Ignoring spurious out of range OA buffer
tail pointer = %x\n",
hw_tail);
}
}
@@ -754,7 +768,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* Note: that we don't clear the valid_ctx_bit so userspace can
* understand that the ID has been squashed by the kernel.
*/
- if (!(report32[0] & stream->perf->gen8_valid_ctx_bit))
+ if (!(report32[0] & stream->perf->gen8_valid_ctx_bit) &&
+ INTEL_GEN(stream->perf->i915) <= 11)
ctx_id = report32[2] = INVALID_CTX_ID;
/*
@@ -821,6 +836,11 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
}
if (start_offset != *offset) {
+ i915_reg_t oaheadptr;
+
+ oaheadptr = IS_GEN(stream->perf->i915, 12) ?
+
[Intel-gfx] [PATCH 1/3] drm/i915/perf: Add helper macros for comparing with whitelisted registers
Add helper macros for range and equality comparisons and use them to
check with whitelisted registers in oa configurations.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 54 +---
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 366580701ba2..d54d3a41ceca 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3455,56 +3455,58 @@ static bool gen8_is_valid_flex_addr(struct i915_perf
*perf, u32 addr)
return false;
}
+#define ADDR_IN_RANGE(addr, start, end) \
+ ((addr) >= (start) && \
+(addr) <= (end))
+
+#define REG_IN_RANGE(addr, start, end) \
+ ((addr) >= i915_mmio_reg_offset(start) && \
+(addr) <= i915_mmio_reg_offset(end))
+
+#define REG_EQUAL(addr, mmio) \
+ ((addr) == i915_mmio_reg_offset(mmio))
+
static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
{
- return (addr >= i915_mmio_reg_offset(OASTARTTRIG1) &&
- addr <= i915_mmio_reg_offset(OASTARTTRIG8)) ||
- (addr >= i915_mmio_reg_offset(OAREPORTTRIG1) &&
-addr <= i915_mmio_reg_offset(OAREPORTTRIG8)) ||
- (addr >= i915_mmio_reg_offset(OACEC0_0) &&
-addr <= i915_mmio_reg_offset(OACEC7_1));
+ return REG_IN_RANGE(addr, OASTARTTRIG1, OASTARTTRIG8) ||
+ REG_IN_RANGE(addr, OAREPORTTRIG1, OAREPORTTRIG8) ||
+ REG_IN_RANGE(addr, OACEC0_0, OACEC7_1);
}
static bool gen7_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
- return addr == i915_mmio_reg_offset(HALF_SLICE_CHICKEN2) ||
- (addr >= i915_mmio_reg_offset(MICRO_BP0_0) &&
-addr <= i915_mmio_reg_offset(NOA_WRITE)) ||
- (addr >= i915_mmio_reg_offset(OA_PERFCNT1_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFCNT2_HI)) ||
- (addr >= i915_mmio_reg_offset(OA_PERFMATRIX_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFMATRIX_HI));
+ return REG_EQUAL(addr, HALF_SLICE_CHICKEN2) ||
+ REG_IN_RANGE(addr, MICRO_BP0_0, NOA_WRITE) ||
+ REG_IN_RANGE(addr, OA_PERFCNT1_LO, OA_PERFCNT2_HI) ||
+ REG_IN_RANGE(addr, OA_PERFMATRIX_LO, OA_PERFMATRIX_HI);
}
static bool gen8_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- addr == i915_mmio_reg_offset(WAIT_FOR_RC6_EXIT) ||
- (addr >= i915_mmio_reg_offset(RPM_CONFIG0) &&
-addr <= i915_mmio_reg_offset(NOA_CONFIG(8)));
+ REG_EQUAL(addr, WAIT_FOR_RC6_EXIT) ||
+ REG_IN_RANGE(addr, RPM_CONFIG0, NOA_CONFIG(8));
}
static bool gen10_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen8_is_valid_mux_addr(perf, addr) ||
- addr == i915_mmio_reg_offset(GEN10_NOA_WRITE_HIGH) ||
- (addr >= i915_mmio_reg_offset(OA_PERFCNT3_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFCNT4_HI));
+ REG_EQUAL(addr, GEN10_NOA_WRITE_HIGH) ||
+ REG_IN_RANGE(addr, OA_PERFCNT3_LO, OA_PERFCNT4_HI);
}
static bool hsw_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- (addr >= 0x25100 && addr <= 0x2FF90) ||
- (addr >= i915_mmio_reg_offset(HSW_MBVID2_NOA0) &&
-addr <= i915_mmio_reg_offset(HSW_MBVID2_NOA9)) ||
- addr == i915_mmio_reg_offset(HSW_MBVID2_MISR0);
+ ADDR_IN_RANGE(addr, 0x25100, 0x2FF90) ||
+ REG_IN_RANGE(addr, HSW_MBVID2_NOA0, HSW_MBVID2_NOA9) ||
+ REG_EQUAL(addr, HSW_MBVID2_MISR0);
}
static bool chv_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- (addr >= 0x182300 && addr <= 0x1823A4);
+ ADDR_IN_RANGE(addr, 0x182300, 0x1823A4);
}
static u32 mask_reg_value(u32 reg, u32 val)
@@ -3513,14 +3515,14 @@ static u32 mask_reg_value(u32 reg, u32 val)
* WaDisableSTUnitPowerOptimization workaround. Make sure the value
* programmed by userspace doesn't change this.
*/
- if (i915_mmio_reg_offset(HALF_SLICE_CHICKEN2) == reg)
+ if (REG_EQUAL(reg, HALF_SLICE_CHICKEN2))
val = val & ~_MASKED_BIT_ENABLE(GEN8_ST_PO_DISABLE);
/* WAIT_FOR_RC6_EXIT has only one bit fullfilling the function
* indicated by its name and a bunch of selection fields used by OA
* configs.
*/
- if (i915_mmio_reg_offset(WAIT_FOR_RC6_EXIT) == reg)
+ if (REG_EQUAL(reg, WAIT_FOR_RC6_EXIT))
val = val & ~_MASKED_BIT_ENABLE(HSW_WAIT_FOR_RC6_EXIT_ENABLE);
return val;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskt
[Intel-gfx] [PATCH v3 3/3] drm/i915/huc: improve documentation
Better explain the usage of the microcontroller and what i915 is
responsible of. While at it, fix the documentation for the auth
function, which doesn't do any pinning anymore.
v2: add a comment on HuC being optional and descrive how HuC accesses
memory (Martin)
v3: add extra newline for better text organization (Martin)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Martin Peres
Acked-by: Anna Karas
Reviewed-by: Martin Peres
---
Documentation/gpu/i915.rst| 16 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 35 ---
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 15 --
3 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 357e9dfa7de1..60bd6e6403da 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -471,8 +471,20 @@ GuC-based command submission
HuC
---
-.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
- :doc: HuC Firmware
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
+ :doc: HuC
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
+ :functions: intel_huc_auth
+
+HuC Memory Management
+~
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
+ :doc: HuC Memory Management
+
+HuC Firmware Layout
+~~~
+The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_
DMC
---
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 33608a114d4e..8be515c8d0f0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -9,6 +9,34 @@
#include "intel_huc.h"
#include "i915_drv.h"
+/**
+ * DOC: HuC
+ *
+ * The HuC is a dedicated microcontroller for usage in media HEVC (High
+ * Efficiency Video Coding) operations. Userspace can directly use the firmware
+ * capabilities by adding HuC specific commands to batch buffers.
+ *
+ * The kernel driver is only responsible for loading the HuC firmware and
+ * triggering its security authentication, which is performed by the GuC. For
+ * The GuC to correctly perform the authentication, the HuC binary must be
+ * loaded before the GuC one. Loading the HuC is optional; however, not using
+ * the HuC might negatively impact power usage and/or performance of media
+ * workloads, depending on the use-cases.
+ *
+ * See https://github.com/intel/media-driver for the latest details on HuC
+ * functionality.
+ */
+
+/**
+ * DOC: HuC Memory Management
+ *
+ * Similarly to the GuC, the HuC can't do any memory allocations on its own,
+ * with the difference being that the allocations for HuC usage are handled by
+ * the userspace driver instead of the kernel one. The HuC accesses the memory
+ * via the PPGTT belonging to the context loaded on the VCS executing the
+ * HuC-specific commands.
+ */
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
@@ -118,10 +146,9 @@ void intel_huc_fini(struct intel_huc *huc)
*
* Called after HuC and GuC firmware loading during intel_uc_init_hw().
*
- * This function pins HuC firmware image object into GGTT.
- * Then it invokes GuC action to authenticate passing the offset to RSA
- * signature through intel_guc_auth_huc(). It then waits for 50ms for
- * firmware verification ACK and unpins the object.
+ * This function invokes the GuC action to authenticate the HuC firmware,
+ * passing the offset of the RSA signature to intel_guc_auth_huc(). It then
+ * waits for up to 50ms for firmware verification ACK.
*/
int intel_huc_auth(struct intel_huc *huc)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 74602487ed67..d654340d4d03 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -7,21 +7,6 @@
#include "intel_huc_fw.h"
#include "i915_drv.h"
-/**
- * DOC: HuC Firmware
- *
- * Motivation:
- * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
- * Efficiency Video Coding) operations. Userspace can use the firmware
- * capabilities by adding HuC specific commands to batch buffers.
- *
- * Implementation:
- * The same firmware loader is used as the GuC. However, the actual
- * loading to HW is deferred until GEM initialization is done.
- *
- * Note that HuC firmware loading must be done before GuC loading.
- */
-
/**
* intel_huc_fw_init_early() - initializes HuC firmware struct
* @huc: intel_huc struct
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/i915: Add microcontrollers documentation section
To better organize the information, add a microcontrollers section and move/link the GuC, HuC and DMC documentation under it. Also add a small intro. Signed-off-by: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Acked-by: Anna Karas Reviewed-by: Martin Peres --- Documentation/gpu/i915.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 465779670fd4..f1bae7867045 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -415,6 +415,15 @@ Object Tiling IOCTLs .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c :doc: buffer object tiling +Microcontrollers + + +Starting from gen9, three microcontrollers are available on the HW: the +graphics microcontroller (GuC), the HEVC/H.265 microcontroller (HuC) and the +display microcontroller (DMC). The driver is responsible for loading the +firmwares on the microcontrollers; the GuC and HuC firmwares are transferred +to WOPCM using the DMA engine, while the DMC firmware is written through MMIO. + WOPCM - @@ -454,6 +463,15 @@ GuC Address Space .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c :doc: GuC Address Space +HuC +--- +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c + :doc: HuC Firmware + +DMC +--- +See `CSR firmware support for DMC`_ + Tracing === -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: improve documentation
Add a short description of what we expect from GuC and some minor
improvements to existing documentation. Also remove a comment about a
difference between GuC and HuC that is not true anymore.
v2: add that the GuC is not mandatory (Martin)
v3: add extra newline for better text organization (Martin)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Matthew Brost
Cc: Martin Peres
Acked-by: Anna Karas
Reviewed-by: Martin Peres
---
Documentation/gpu/i915.rst| 22 -
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 31 +--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 3 --
4 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index f1bae7867045..357e9dfa7de1 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -436,12 +436,24 @@ WOPCM Layout
GuC
---
-Firmware Layout
-~~~
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
+ :doc: GuC
+
+GuC Firmware Layout
+~~~
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
:doc: Firmware Layout
+GuC Memory Management
+~
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
+ :doc: GuC Memory Management
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
+ :functions: intel_guc_allocate_vma
+
+
GuC-specific firmware loader
@@ -457,12 +469,6 @@ GuC-based command submission
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
:internal:
-GuC Address Space
-~
-
-.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c
- :doc: GuC Address Space
-
HuC
---
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 249c747e9756..37f7bcbf7dac 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -9,6 +9,27 @@
#include "intel_guc_submission.h"
#include "i915_drv.h"
+/**
+ * DOC: GuC
+ *
+ * The GuC is a microcontroller inside the GT HW, introduced in gen9. The GuC
is
+ * designed to offload some of the functionality usually performed by the host
+ * driver; currently the main operations it can take care of are:
+ *
+ * - Authentication of the HuC, which is required to fully enable HuC usage.
+ * - Low latency graphics context scheduling (a.k.a. GuC submission).
+ * - GT Power management.
+ *
+ * The enable_guc module parameter can be used to select which of those
+ * operations to enable within GuC. Note that not all the operations are
+ * supported on all gen9+ platforms.
+ *
+ * Enabling the GuC is not mandatory and therefore the firmware is only loaded
+ * if at least one of the operations is selected. However, not loading the GuC
+ * might result in the loss of some features that do require the GuC (currently
+ * just the HuC, but more are expected to land in the future).
+ */
+
static void gen8_guc_raise_irq(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
@@ -548,9 +569,15 @@ int intel_guc_resume(struct intel_guc *guc)
}
/**
- * DOC: GuC Address Space
+ * DOC: GuC Memory Management
*
- * The layout of GuC address space is shown below:
+ * GuC can't allocate any memory for its own usage, so all the allocations must
+ * be handled by the host driver. GuC accesses the memory via the GGTT, with
the
+ * exception of the top and bottom parts of the 4GB address space, which are
+ * instead re-mapped by the GuC HW to memory location of the FW itself (WOPCM)
+ * or other parts of the HW. The driver must take care not to place objects
that
+ * the GuC is going to access in these reserved ranges. The layout of the GuC
+ * address space is shown below:
*
* ::
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f325d3dd564f..849a44add424 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -29,6 +29,12 @@ enum {
/**
* DOC: GuC-based command submission
*
+ * IMPORTANT NOTE: GuC submission is currently not supported in i915. The GuC
+ * firmware is moving to an updated submission interface and we plan to
+ * turn submission back on when that lands. The below documentation (and
related
+ * code) matches the old submission model and will be updated as part of the
+ * upgrade to the new flow.
+ *
* GuC client:
* A intel_guc_client refers to a submission path through GuC. Currently, there
* is only one client, which is charged with all submissions to the GuC. This
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
index f8f6c91a0df6..029214cdedd5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
+++ b/drivers/gpu/drm/i915/gt/u
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Mon, 2019-10-14 at 19:51 +0200, Daniel Vetter wrote:
> On Mon, Oct 14, 2019 at 6:21 PM Li, Juston
> wrote:
> > On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> > > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > > > From: Daniel Stone
> > > >
> > > > getfb2 allows us to pass multiple planes and modifiers, just
> > > > like
> > > > addfb2
> > > > over addfb.
> > > >
> > > > Changes since v1:
> > > > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > > > - update ioctl number
> > > >
> > > > Signed-off-by: Daniel Stone
> > > > Signed-off-by: Juston Li
> > >
> > > Looks all good from a very quick glance (kernel, libdrm, igt),
> > > but
> > > where's
> > > the userspace? Link to weston/drm_hwc/whatever MR good enough.
> > > -Daniel
> >
> > My use case is a screenshot utility in chromiuomos that breaks with
> > y-
> > tiled ccs enabled.
> > Review linked is just WIP hack for now since it depends on this
> > merging:
> > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146
>
> Adding Sean & Daniele to confirm this is real cros.
> -Daniel
+Mark, who I've been talking about enabling render buffer compression.
This patch allows me to fix a regression w/ screenshot utility when
enabling RBC:
https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/1759155
Thanks
Juston
> > > > ---
> > > > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > > > drivers/gpu/drm/drm_framebuffer.c | 110
> > > >
> > > > drivers/gpu/drm/drm_ioctl.c | 1 +
> > > > include/uapi/drm/drm.h | 2 +
> > > > 4 files changed, 115 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > > > b/drivers/gpu/drm/drm_crtc_internal.h
> > > > index c7d5e4c21423..16f2413403aa 100644
> > > > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > > > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > > > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device
> > > > *dev,
> > > > void *data, struct drm_file *file_priv);
> > > > int drm_mode_getfb(struct drm_device *dev,
> > > >void *data, struct drm_file *file_priv);
> > > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > > + void *data, struct drm_file *file_priv);
> > > > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> > > >void *data, struct drm_file *file_priv);
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > > > b/drivers/gpu/drm/drm_framebuffer.c
> > > > index 57564318ceea..6db54f177443 100644
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -31,6 +31,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device
> > > > *dev,
> > > >
> > > > out:
> > > > drm_framebuffer_put(fb);
> > > > + return ret;
> > > > +}
> > > > +
> > > > +/**
> > > > + * drm_mode_getfb2 - get extended FB info
> > > > + * @dev: drm device for the ioctl
> > > > + * @data: data pointer for the ioctl
> > > > + * @file_priv: drm file for the ioctl call
> > > > + *
> > > > + * Lookup the FB given its ID and return info about it.
> > > > + *
> > > > + * Called by the user via ioctl.
> > > > + *
> > > > + * Returns:
> > > > + * Zero on success, negative errno on failure.
> > > > + */
> > > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > > + void *data, struct drm_file *file_priv)
> > > > +{
> > > > + struct drm_mode_fb_cmd2 *r = data;
> > > > + struct drm_framebuffer *fb;
> > > > + unsigned int i;
> > > > + int ret;
> > > > +
> > > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > > + return -EINVAL;
> > > > +
> > > > + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > > > + if (!fb)
> > > > + return -ENOENT;
> > > > +
> > > > + /* For multi-plane framebuffers, we require the driver to
> > > > place
> > > > the
> > > > +* GEM objects directly in the drm_framebuffer. For single-
> > > > plane
> > > > +* framebuffers, we can fall back to create_handle.
> > > > +*/
> > > > + if (!fb->obj[0] &&
> > > > + (fb->format->num_planes > 1 || !fb->funcs-
> > > > >create_handle))
> > > > {
> > > > + ret = -ENODEV;
> > > > + goto out;
> > > > + }
> > > > +
> > > > + r->height = fb->height;
> > > > + r->width = fb->width;
> > > > + r->pixel_format = fb->format->format;
> > > > +
> > > > + r->flags = 0;
> > > > + if (dev->mode_config.allow_fb_modifiers)
> > > > + r->flags |= DRM_MODE_FB_MODIFIERS;
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> > > > + r->handles[i] = 0;
> > > > + r->pitches[i] = 0;
> > > > + r->offsets[i] = 0;
> > > > + r->modifier[i] = 0;
> > > > +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Some cleanup near the SKL wm/ddb area (rev2)
== Series Details ==
Series: drm/i915: Some cleanup near the SKL wm/ddb area (rev2)
URL : https://patchwork.freedesktop.org/series/67930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7087 -> Patchwork_14794
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/index.html
Known issues
Here are the changes found in Patchwork_14794 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
* igt@i915_selftest@live_gem_contexts:
- fi-kbl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#112002])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-kbl-guc/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/fi-kbl-guc/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_mmap_gtt@basic-write-read:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u3/igt@gem_mmap_...@basic-write-read.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/fi-icl-u3/igt@gem_mmap_...@basic-write-read.html
* igt@i915_selftest@live_execlists:
- {fi-icl-u4}:[INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u4/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/fi-icl-u4/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][9] ([fdo#111045]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#112002]: https://bugs.freedesktop.org/show_bug.cgi?id=112002
Participating hosts (52 -> 44)
--
Missing(8): fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-skl-6600u
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7087 -> Patchwork_14794
CI-20190529: 20190529
CI_DRM_7087: a2b54a43afb778438edaa8c4e13d2c7cc0a6909a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14794: 824abde942f8fcef3ca2ae9d1116cbcc0a5859aa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
824abde942f8 drm/i915: Nuke skl wm.dirty_pipes bitmask
c1459a6918f8 drm/i915: Move linetime wms into the crtc state
7a9995b69471 drm/i915: Polish WM_LINETIME register stuff
b7f58101c4e5 drm/i915: Streamline skl_commit_modeset_enables()
0e684dc72d96 drm/i915: Don't set undefined bits in dirty_pipes
daba17a895b9 drm/i915: Make dirty_pipes refer to pipes
cf6f9a8c5c4c drm/i915: Nuke 'realloc_pipes'
73c0b3dc5dda drm/i915: Nuke the useless changed param from
skl_ddb_add_affected_pipes()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14794/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: cleanup unused returns on DP-MST
On Fri, Oct 11, 2019 at 02:48:12PM +0300, Ville Syrjälä wrote:
On Thu, Oct 10, 2019 at 06:09:02PM -0700, Lucas De Marchi wrote:
Those init functions mark their success in the intel_dig_port
struct, the return values are not really used.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +--
drivers/gpu/drm/i915/display/intel_dp_mst.h | 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2203be28ea01..c2bbba1effc1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -634,7 +634,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
}
-static bool
+static void
intel_dp_create_fake_mst_encoders(struct intel_digital_port *intel_dig_port)
{
struct intel_dp *intel_dp = &intel_dig_port->dp;
@@ -643,7 +643,6 @@ intel_dp_create_fake_mst_encoders(struct intel_digital_port
*intel_dig_port)
for_each_pipe(dev_priv, pipe)
intel_dp->mst_encoders[pipe] =
intel_dp_create_fake_mst_encoder(intel_dig_port, pipe);
- return true;
}
int
@@ -652,14 +651,13 @@ intel_dp_mst_encoder_active_links(struct
intel_digital_port *intel_dig_port)
return intel_dig_port->dp.active_mst_links;
}
-int
+void
intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_base_id)
{
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct drm_device *dev = intel_dig_port->base.base.dev;
int ret;
- intel_dp->can_mst = true;
intel_dp->mst_mgr.cbs = &mst_cbs;
/* create encoders */
@@ -668,9 +666,10 @@ intel_dp_mst_encoder_init(struct intel_digital_port
*intel_dig_port, int conn_ba
&intel_dp->aux, 16, 3, conn_base_id);
if (ret) {
intel_dp->can_mst = false;
- return ret;
+ return;
}
- return 0;
I don't really like the silent failure mode. Maybe we should just fail
the entire connector init when this happens?
ok. For now I will just drop this patch.
Lucas De Marchi
+
+ intel_dp->can_mst = true;
}
void
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.h
b/drivers/gpu/drm/i915/display/intel_dp_mst.h
index f660ad80db04..f2478c17a8fd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.h
@@ -8,7 +8,7 @@
struct intel_digital_port;
-int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
+void intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
void intel_dp_mst_encoder_cleanup(struct intel_digital_port *intel_dig_port);
int intel_dp_mst_encoder_active_links(struct intel_digital_port
*intel_dig_port);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Mon, Oct 14, 2019 at 6:21 PM Li, Juston wrote:
>
> On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > > From: Daniel Stone
> > >
> > > getfb2 allows us to pass multiple planes and modifiers, just like
> > > addfb2
> > > over addfb.
> > >
> > > Changes since v1:
> > > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > > - update ioctl number
> > >
> > > Signed-off-by: Daniel Stone
> > > Signed-off-by: Juston Li
> >
> > Looks all good from a very quick glance (kernel, libdrm, igt), but
> > where's
> > the userspace? Link to weston/drm_hwc/whatever MR good enough.
> > -Daniel
>
> My use case is a screenshot utility in chromiuomos that breaks with y-
> tiled ccs enabled.
> Review linked is just WIP hack for now since it depends on this
> merging:
> https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146
Adding Sean & Daniele to confirm this is real cros.
-Daniel
>
> Thanks
> Juston
>
> > > ---
> > > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > > drivers/gpu/drm/drm_framebuffer.c | 110
> > >
> > > drivers/gpu/drm/drm_ioctl.c | 1 +
> > > include/uapi/drm/drm.h | 2 +
> > > 4 files changed, 115 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > > b/drivers/gpu/drm/drm_crtc_internal.h
> > > index c7d5e4c21423..16f2413403aa 100644
> > > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
> > > void *data, struct drm_file *file_priv);
> > > int drm_mode_getfb(struct drm_device *dev,
> > >void *data, struct drm_file *file_priv);
> > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > + void *data, struct drm_file *file_priv);
> > > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> > >void *data, struct drm_file *file_priv);
> > >
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > > b/drivers/gpu/drm/drm_framebuffer.c
> > > index 57564318ceea..6db54f177443 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -31,6 +31,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device *dev,
> > >
> > > out:
> > > drm_framebuffer_put(fb);
> > > + return ret;
> > > +}
> > > +
> > > +/**
> > > + * drm_mode_getfb2 - get extended FB info
> > > + * @dev: drm device for the ioctl
> > > + * @data: data pointer for the ioctl
> > > + * @file_priv: drm file for the ioctl call
> > > + *
> > > + * Lookup the FB given its ID and return info about it.
> > > + *
> > > + * Called by the user via ioctl.
> > > + *
> > > + * Returns:
> > > + * Zero on success, negative errno on failure.
> > > + */
> > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > + void *data, struct drm_file *file_priv)
> > > +{
> > > + struct drm_mode_fb_cmd2 *r = data;
> > > + struct drm_framebuffer *fb;
> > > + unsigned int i;
> > > + int ret;
> > > +
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > + return -EINVAL;
> > > +
> > > + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > > + if (!fb)
> > > + return -ENOENT;
> > > +
> > > + /* For multi-plane framebuffers, we require the driver to place
> > > the
> > > +* GEM objects directly in the drm_framebuffer. For single-
> > > plane
> > > +* framebuffers, we can fall back to create_handle.
> > > +*/
> > > + if (!fb->obj[0] &&
> > > + (fb->format->num_planes > 1 || !fb->funcs->create_handle))
> > > {
> > > + ret = -ENODEV;
> > > + goto out;
> > > + }
> > > +
> > > + r->height = fb->height;
> > > + r->width = fb->width;
> > > + r->pixel_format = fb->format->format;
> > > +
> > > + r->flags = 0;
> > > + if (dev->mode_config.allow_fb_modifiers)
> > > + r->flags |= DRM_MODE_FB_MODIFIERS;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> > > + r->handles[i] = 0;
> > > + r->pitches[i] = 0;
> > > + r->offsets[i] = 0;
> > > + r->modifier[i] = 0;
> > > + }
> > >
> > > + for (i = 0; i < fb->format->num_planes; i++) {
> > > + int j;
> > > +
> > > + r->pitches[i] = fb->pitches[i];
> > > + r->offsets[i] = fb->offsets[i];
> > > + if (dev->mode_config.allow_fb_modifiers)
> > > + r->modifier[i] = fb->modifier;
> > > +
> > > + /* If we reuse the same object for multiple planes,
> > > also
> > > +* return the same handle.
> > > +*/
> > > + for (j = 0; j < i; j++) {
> > > + if (fb->obj[i] == fb->obj[j]) {
> > > +
Re: [Intel-gfx] [PATCH 7/7] drm/dp-mst: fix warning on unused var
On Fri, Oct 11, 2019 at 10:58:13AM -0700, Lucas De Marchi wrote:
> +dri, +Daniel
>
> On Thu, Oct 10, 2019 at 06:09:07PM -0700, Lucas De Marchi wrote:
> > Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 9364e4f42975..95e63309 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4184,8 +4184,6 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
> > struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
> > drm_atomic_state *state,
> > struct
> > drm_dp_mst_topology_mgr *mgr)
> > {
> > - struct drm_device *dev = mgr->dev;
> > -
> > return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state,
> > &mgr->base));
> > }
> > EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
Thanks for fixing this, pushed.
-Daniel
> > --
> > 2.23.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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/execlists: Assert tasklet is locked for process_csb() (rev4)
== Series Details ==
Series: drm/i915/execlists: Assert tasklet is locked for process_csb() (rev4)
URL : https://patchwork.freedesktop.org/series/67957/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7087 -> Patchwork_14793
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/index.html
Known issues
Here are the changes found in Patchwork_14793 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#109635 ] / [fdo#110387])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.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_7087/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][7] ([fdo#111045]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [FAIL][10] ([fdo#111045]
/ [fdo#111096])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7087/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/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#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#55]: https://bugs.freedesktop.org/show_bug.cgi?id=55
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
Participating hosts (52 -> 45)
--
Missing(7): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7087 -> Patchwork_14793
CI-20190529: 20190529
CI_DRM_7087: a2b54a43afb778438edaa8c4e13d2c7cc0a6909a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14793: e786027ace74687e5a8e403bf97324fb4538db91 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e786027ace74 drm/i915/execlists: Assert tasklet is locked for process_csb()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14793/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add mipi dsi command mode support.
== Series Details ==
Series: Add mipi dsi command mode support.
URL : https://patchwork.freedesktop.org/series/67974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7086 -> Patchwork_14792
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/index.html
Known issues
Here are the changes found in Patchwork_14792 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_7086/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-write-read-distinct:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-icl-u3/igt@gem_mmap_...@basic-write-read-distinct.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-icl-u3/igt@gem_mmap_...@basic-write-read-distinct.html
* igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r: [PASS][5] -> [DMESG-FAIL][6] ([fdo#111991])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111407])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-blb-e6850/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/fi-blb-e6850/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#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[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#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
[fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
Participating hosts (52 -> 46)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7086 -> Patchwork_14792
CI-20190529: 20190529
CI_DRM_7086: cb64ca78fe223a03a902aa10ddbfb672ccad1630 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14792: db7de625fd49b6e33788b8f84c5ae54204e43dcd @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
db7de625fd49 drm/i915/dsi: Initiate frame request in cmd mode
e600d6ff8306 drm/i915/dsi: Add TE handler for dsi cmd mode.
7a4fc89a244f drm/i915/dsi: Configure TE interrupt for cmd mode
91f92b97148b drm/i915/dsi: Helper to find dsi encoder in cmd mode
c778fa65e35c drm/i915/dsi: Add vblank calculation for command mode
900d9ba2700a drm/i915/dsi: Configure transcoder operation for command mode.
83c4c64b055f drm/i915/dsi: Define command mode registers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14792/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Mon, Oct 14, 2019 at 09:33:32AM -0700, James Ausmus wrote:
> On Mon, Oct 14, 2019 at 05:50:18PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> > > On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > > > + new_qgv_points_mask |= new_mask_bit;
> > > > > + }
> > > > > +
> > > > > + ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > > > new_qgv_points_mask);
> > > > > + if (ret < 0)
> > > > > + DRM_DEBUG_KMS("Could not restrict required gqv
> > > > > points(%d)\n", ret);
> > > >
> > > > s/gqv/qgv/
> > > >
> > > >
> > > > Also, if we fail masking off the qgv points that can't support our BW
> > > > req, shouldn't we handle that failure somehow - maybe just disable
> > > > SAGV
> > > > entirely? Better we lose power than have flickering screens...
> >
> > Sounds like dead code to me. My approach is: don't deal with hw/firmware
> > failures until they are proven to exist.
> >
> > The debug msg should be an error so that we get a bug report if this
> > ever happens.
>
> That works - however, I think we should return the error rather than
> continuing.
No. We're way past the point of no return.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> -Original Message-
> From: Ville Syrjala
> Sent: Friday, October 4, 2019 10:19 PM
> To: dri-de...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org; Lin, Wayne
> Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
>
> From: Ville Syrjälä
>
> I think this should provide most of necessary logic for adding aspecr ratios
> to
> the HDMI 4k modes.
>
> Cc: Wayne Lin
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 37 +++--
> 1 file changed, 31 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> c7f9f7ca75a2..c76814edc784 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> drm_get_cea_aspect_ratio(const u8 video_code)
> return edid_cea_modes[video_code].picture_aspect_ratio;
> }
>
> +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> +video_code) {
> + return edid_4k_modes[video_code].picture_aspect_ratio;
> +}
> +
There are no picture_aspect_ratio attributes defined for modes in
edid_4k_modes[] now. Should add on those definitions.
> /*
> * Calculate the alternate clock for HDMI modes (those from the HDMI
> vendor
> * specific block).
> @@ -3236,6 +3241,9 @@ static u8
> drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_
> if (!to_match->clock)
> return 0;
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
> for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> unsigned int clock1, clock2;
> @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const struct
> drm_display_mode *to_match)
> if (!to_match->clock)
> return 0;
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
> for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> unsigned int clock1, clock2;
Current code in drm_match_hdmi_mdoe() & drm_match_hdmi_mode_clock_tolerance()
use hdmi_mode_alternate_clock() to find alternate clocks.
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode
(4096x2160@24)
due to there is no alternate clock defined for that mode in HDMI1.4b. But
HDMI2.0 adds
23.98Hz for that mode. Maybe we should also revise that part.
> @@ -5218,6 +5229,7 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
>const struct drm_display_mode *mode) {
> enum hdmi_picture_aspect picture_aspect;
> + u8 vic, hdmi_vic;
> int err;
>
> if (!frame || !mode)
> @@ -5230,7 +5242,8 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> frame->pixel_repeat = 1;
>
> - frame->video_code = drm_mode_cea_vic(connector, mode);
> + vic = drm_mode_cea_vic(connector, mode);
> + hdmi_vic = drm_mode_hdmi_vic(connector, mode);
>
> frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
>
> @@ -5244,11 +5257,15 @@
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> *frame,
>
> /*
>* Populate picture aspect ratio from either
> - * user input (if specified) or from the CEA mode list.
> + * user input (if specified) or from the CEA/HDMI mode lists.
>*/
> picture_aspect = mode->picture_aspect_ratio;
> - if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> - picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) {
> + if (vic)
> + picture_aspect = drm_get_cea_aspect_ratio(vic);
> + else if (hdmi_vic)
> + picture_aspect = drm_get_hdmi_aspect_ratio(hdmi_vic);
> + }
>
> /*
>* The infoframe can't convey anything but none, 4:3 @@ -5256,12
> +5273,20 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
>* we can only satisfy it by specifying the right VIC.
>*/
> if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> - if (picture_aspect !=
> - drm_get_cea_aspect_ratio(frame->video_code))
> + if (vic) {
> + if (picture_aspect != drm_get_cea_aspect_ratio(vic))
> + return -EINVAL;
> + } else if (hdmi_vic) {
> + if (picture_aspect !=
> drm_get_hdmi_aspect_ratio(hdmi_vic))
> + return -EINVAL;
> + } else {
> return -EINVAL;
> + }
> +
> picture_aspect = HDMI_
[Intel-gfx] [PATCH] kernel-doc: rename the kernel-doc directive 'functions' to 'specific'
The 'functions' directive is not only for functions, but also works for structs/unions. So the name is misleading. This patch renames it to 'specific', so now we have export/internal/specific directives to limit the functions/types to be included in documentation. Meanwhile we improved the warning message. Signed-off-by: Changbin Du --- Documentation/PCI/pci.rst | 4 +- Documentation/core-api/boot-time-mm.rst | 2 +- Documentation/core-api/debug-objects.rst | 14 +- Documentation/core-api/genalloc.rst | 34 +-- Documentation/core-api/generic-radix-tree.rst | 2 +- .../core-api/gfp_mask-from-fs-io.rst | 4 +- Documentation/core-api/idr.rst| 4 +- Documentation/core-api/kernel-api.rst | 12 +- Documentation/core-api/mm-api.rst | 4 +- Documentation/crypto/api-aead.rst | 6 +- Documentation/crypto/api-akcipher.rst | 6 +- Documentation/crypto/api-digest.rst | 8 +- Documentation/crypto/api-kpp.rst | 10 +- Documentation/crypto/api-rng.rst | 4 +- Documentation/crypto/api-skcipher.rst | 14 +- Documentation/dev-tools/kselftest.rst | 4 +- Documentation/doc-guide/kernel-doc.rst| 26 +-- Documentation/driver-api/80211/cfg80211.rst | 200 +- .../driver-api/80211/mac80211-advanced.rst| 88 Documentation/driver-api/80211/mac80211.rst | 80 +++ .../driver-api/device_connection.rst | 2 +- Documentation/driver-api/device_link.rst | 4 +- .../firmware/fallback-mechanisms.rst | 2 +- .../driver-api/firmware/other_interfaces.rst | 10 +- .../driver-api/firmware/request_firmware.rst | 12 +- Documentation/driver-api/fpga/fpga-bridge.rst | 10 +- Documentation/driver-api/fpga/fpga-mgr.rst| 12 +- .../driver-api/fpga/fpga-programming.rst | 8 +- Documentation/driver-api/fpga/fpga-region.rst | 20 +- Documentation/driver-api/i2c.rst | 2 +- Documentation/driver-api/mei/hdcp.rst | 2 +- Documentation/driver-api/spi.rst | 2 +- Documentation/driver-api/usb/typec.rst| 26 +-- Documentation/driver-api/usb/typec_bus.rst| 10 +- Documentation/gpu/amdgpu-dc.rst | 6 +- Documentation/gpu/drm-kms-helpers.rst | 2 +- Documentation/gpu/i915.rst| 70 +++--- Documentation/gpu/vga-switcheroo.rst | 14 +- Documentation/security/tpm/tpm_vtpm_proxy.rst | 2 +- Documentation/sphinx/kerneldoc.py | 10 +- .../it_IT/doc-guide/kernel-doc.rst| 2 +- Documentation/vm/ksm.rst | 2 +- scripts/kernel-doc| 9 +- 43 files changed, 385 insertions(+), 380 deletions(-) diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 6864f9a70f5f..6f310807f74c 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -79,13 +79,13 @@ initialization with a pointer to a structure describing the driver (``struct pci_driver``): .. kernel-doc:: include/linux/pci.h - :functions: pci_driver + :specific: pci_driver The ID table is an array of ``struct pci_device_id`` entries ending with an all-zero entry. Definitions with static const are generally preferred. .. kernel-doc:: include/linux/mod_devicetable.h - :functions: pci_device_id + :specific: pci_device_id Most drivers only need ``PCI_DEVICE()`` or ``PCI_DEVICE_CLASS()`` to set up a pci_device_id table. diff --git a/Documentation/core-api/boot-time-mm.rst b/Documentation/core-api/boot-time-mm.rst index e5ec9f1a563d..54824740d010 100644 --- a/Documentation/core-api/boot-time-mm.rst +++ b/Documentation/core-api/boot-time-mm.rst @@ -38,4 +38,4 @@ really happens under the hood. .. kernel-doc:: include/linux/memblock.h .. kernel-doc:: mm/memblock.c - :functions: + :specific: diff --git a/Documentation/core-api/debug-objects.rst b/Documentation/core-api/debug-objects.rst index ac926fd55a64..352fc2d8abbd 100644 --- a/Documentation/core-api/debug-objects.rst +++ b/Documentation/core-api/debug-objects.rst @@ -65,7 +65,7 @@ Debug functions === .. kernel-doc:: lib/debugobjects.c - :functions: debug_object_init + :specific: debug_object_init This function is called whenever the initialization function of a real object is called. @@ -88,7 +88,7 @@ calling code must use debug_object_init_on_stack() and remove the object before leaving the function which allocated it. See next section. .. kernel-doc:: lib/debugobjects.c - :functions: debug_object_init_on_stack + :specific: debug_object_init_on_stack This function is called whenever the initialization function of a real object which resides on the stack is called. @@ -112,7 +112,7 @@ calling debug_object_free() before the function which allocates the object returns. Otherwise we keep track of stale objects. .
Re: [Intel-gfx] [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Mon, Oct 14, 2019 at 05:50:18PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> > On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > > + new_qgv_points_mask |= new_mask_bit;
> > > > + }
> > > > +
> > > > + ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > > new_qgv_points_mask);
> > > > + if (ret < 0)
> > > > + DRM_DEBUG_KMS("Could not restrict required gqv
> > > > points(%d)\n", ret);
> > >
> > > s/gqv/qgv/
> > >
> > >
> > > Also, if we fail masking off the qgv points that can't support our BW
> > > req, shouldn't we handle that failure somehow - maybe just disable
> > > SAGV
> > > entirely? Better we lose power than have flickering screens...
>
> Sounds like dead code to me. My approach is: don't deal with hw/firmware
> failures until they are proven to exist.
>
> The debug msg should be an error so that we get a bug report if this
> ever happens.
That works - however, I think we should return the error rather than
continuing.
-James
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Mon, Oct 14, 2019 at 04:13:31AM -0700, Lisovskiy, Stanislav wrote:
> On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > On Wed, Sep 25, 2019 at 03:17:37PM +0300, Stanislav Lisovskiy wrote:
> > > According to BSpec 53998, we should try to
> > > restrict qgv points, which can't provide
> > > enough bandwidth for desired display configuration.
> > >
> > > Currently we are just comparing against all of
> > > those and take minimum(worst case).
> > >
> > > v2: Fixed wrong PCode reply mask, removed hardcoded
> > > values.
> > >
> > > v3: Forbid simultaneous legacy SAGV PCode requests and
> > > restricting qgv points. Put the actual restriction
> > > to commit function, added serialization(thanks to Ville)
> > > to prevent commit being applied out of order in case of
> > > nonblocking and/or nomodeset commits.
>
> Hi James,
>
> Thank you for great review!
>
> While many of your comments are definitely
> good findings, still will leave reply to a few,
> just to keep things clear.
>
>
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > Cc: Ville Syrjälä
> > > Cc: James Ausmus
> > > ---
> > > drivers/gpu/drm/i915/display/intel_atomic.c | 16
> > > drivers/gpu/drm/i915/display/intel_atomic.h | 3 +
> > > drivers/gpu/drm/i915/display/intel_bw.c | 79 +
> > > --
> > > drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> > > drivers/gpu/drm/i915/display/intel_display.c | 78
> > > +-
> > > .../drm/i915/display/intel_display_types.h| 3 +
> > > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > > drivers/gpu/drm/i915/i915_reg.h | 3 +
> > > 8 files changed, 160 insertions(+), 26 deletions(-)
>
> > if (max_data_rate >= data_rate)
> > allowed_points |= 1 << i;
> > DRM_DEBUG_KMS...
> >
> > > + allowed_points |= 1 << i;
> > > + }
> >
> > According to the BSpec page, we also need to save off the QGV point
> > that has
> > the most available bandwidth:
> >
> > "At least one GV point must always remain unmasked. The point
> > providing the
> > highest bandwidth for display must always remain unmasked."
> >
> > We should stash that point separately, and ensure it always remains
> > unmasked.
> >
> > > + }
> > > +
> > > + if (allowed_points == 0) {
> > > + DRM_DEBUG_KMS("Could not find any suitable QGV
> > > points\n");
> > > return -EINVAL;
> > > }
>
> This actually guarantees that, I think - we will never allow a
> config which will require us to mask all of the points to work.
Yeah, fair enough - if *any* points allow a high enough bandwidth, then
it's certain that the *highest* BW point will be unmasked. If *no*
points allow enough BW, then it doesn't matter anyway because we're
going to fail out and not allow that config...
Thanks!
-James
>
> > >
> > > + state->qgv_points_mask = (~allowed_points) & ((1 <<
> > > qi.num_points) - 1);
> > > +
> > > + /*
> > > + * If the actual mask had changed we need to make sure that
> > > + * the commits are serialized(in case this is a nomodeset,
> > > nonblocking)
> > > + */
> > > + if (state->qgv_points_mask != dev_priv->qgv_points_mask) {
> > > + ret = intel_atomic_serialize_global_state(state);
> > > + if (ret) {
> > > + DRM_DEBUG_KMS("Could not serialize global
> > > state\n");
> > > + return ret;
> > > + }
> > > + }
> > > +
> > > return 0;
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index 9db10af012f4..66bf9bc10b73 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -28,5 +28,7 @@ int intel_bw_init(struct drm_i915_private
> > > *dev_priv);
> > > int intel_bw_atomic_check(struct intel_atomic_state *state);
> > > void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > > const struct intel_crtc_state *crtc_state);
> > > +int icl_pcode_restrict_qgv_points(struct drm_i915_private
> > > *dev_priv,
> > > + u32 points_mask);
> > >
> > > #endif /* __INTEL_BW_H__ */
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 5ecf54270181..c3196d0e4be3 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -13960,6 +13960,68 @@ static void
> > > intel_atomic_cleanup_work(struct work_struct *work)
> > > intel_atomic_helper_free_state(i915);
> > > }
> > >
> > > +static void intel_qgv_point_pre_update(struct intel_atomic_state
> > > *state)
> >
> > It would be nice to name this either "mask" or "unmask", so it's
> > easier
> > at first glance to see which function is turning on masked bits vs
> > toggling them off.
> >
> > > +{
> > > + struct drm_device *dev = state->base.dev;
> > > + struct drm_i9
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add mipi dsi command mode support.
== Series Details == Series: Add mipi dsi command mode support. URL : https://patchwork.freedesktop.org/series/67974/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dsi: Define command mode registers Okay! Commit: drm/i915/dsi: Configure transcoder operation for command mode. Okay! Commit: drm/i915/dsi: Add vblank calculation for command mode Okay! Commit: drm/i915/dsi: Helper to find dsi encoder in cmd mode Okay! Commit: drm/i915/dsi: Configure TE interrupt for cmd mode Okay! Commit: drm/i915/dsi: Add TE handler for dsi cmd mode. - +drivers/gpu/drm/i915/i915_irq.c:2631:6: warning: symbol 'gen11_dsi_te_interrupt_handler' was not declared. Should it be static? Commit: drm/i915/dsi: Initiate frame request in cmd mode Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2 2/2] NOMERGE: Import drm.h up to 54ecb8f7028c
On Wed, 2019-10-09 at 17:49 +0200, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:46:28AM -0700, Juston Li wrote:
> > Depends on ummerged kernel code for getfb2
> >
> > Rest of drm.h taken from:
> > commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
> > Author: Linus Torvalds
> > Date: Mon Sep 30 10:35:40 2019 -0700
> >
> > Linux 5.4-rc1
> >
> > Signed-off-by: Juston Li
>
> I guess this should be first, then the patch that uses it?
> -Daniel
Yes, apologies. I'll swap the order around.
Thanks
Juston
> > ---
> > include/drm-uapi/drm.h | 39
> > +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> > index 85c685a2075e..0b02f4c92d1e 100644
> > --- a/include/drm-uapi/drm.h
> > +++ b/include/drm-uapi/drm.h
> > @@ -643,6 +643,7 @@ struct drm_gem_open {
> > #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> > #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
> > #define DRM_CAP_SYNCOBJ0x13
> > +#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
> >
> > /** DRM_IOCTL_GET_CAP ioctl argument type */
> > struct drm_get_cap {
> > @@ -729,8 +730,18 @@ struct drm_syncobj_handle {
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_transfer {
> > + __u32 src_handle;
> > + __u32 dst_handle;
> > + __u64 src_point;
> > + __u64 dst_point;
> > + __u32 flags;
> > + __u32 pad;
> > +};
> > +
> > #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
> > #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> > +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for
> > time point to become available */
> > struct drm_syncobj_wait {
> > __u64 handles;
> > /* absolute timeout */
> > @@ -741,12 +752,33 @@ struct drm_syncobj_wait {
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_timeline_wait {
> > + __u64 handles;
> > + /* wait on specific timeline point for every handles*/
> > + __u64 points;
> > + /* absolute timeout */
> > + __s64 timeout_nsec;
> > + __u32 count_handles;
> > + __u32 flags;
> > + __u32 first_signaled; /* only valid when not waiting all */
> > + __u32 pad;
> > +};
> > +
> > +
> > struct drm_syncobj_array {
> > __u64 handles;
> > __u32 count_handles;
> > __u32 pad;
> > };
> >
> > +struct drm_syncobj_timeline_array {
> > + __u64 handles;
> > + __u64 points;
> > + __u32 count_handles;
> > + __u32 pad;
> > +};
> > +
> > +
> > /* Query current scanout sequence number */
> > struct drm_crtc_get_sequence {
> > __u32 crtc_id; /* requested crtc_id */
> > @@ -903,6 +935,13 @@ extern "C" {
> > #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
> > drm_mode_get_lease)
> > #define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
> > drm_mode_revoke_lease)
> >
> > +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
> > drm_syncobj_timeline_wait)
> > +#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
> > drm_syncobj_timeline_array)
> > +#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
> > drm_syncobj_transfer)
> > +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
> > drm_syncobj_timeline_array)
> > +
> > +#define DRM_IOCTL_MODE_GETFB2 DRM_IOWR(0xCE, struct
> > drm_mode_fb_cmd2)
> > +
> > /**
> > * Device specific ioctls should only be in their respective
> > headers
> > * The device specific ioctl range is from 0x40 to 0x9f.
> > --
> > 2.21.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] [RESEND PATCH v2] drm: Add getfb2 ioctl
On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > From: Daniel Stone
> >
> > getfb2 allows us to pass multiple planes and modifiers, just like
> > addfb2
> > over addfb.
> >
> > Changes since v1:
> > - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > - update ioctl number
> >
> > Signed-off-by: Daniel Stone
> > Signed-off-by: Juston Li
>
> Looks all good from a very quick glance (kernel, libdrm, igt), but
> where's
> the userspace? Link to weston/drm_hwc/whatever MR good enough.
> -Daniel
My use case is a screenshot utility in chromiuomos that breaks with y-
tiled ccs enabled.
Review linked is just WIP hack for now since it depends on this
merging:
https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146
Thanks
Juston
> > ---
> > drivers/gpu/drm/drm_crtc_internal.h | 2 +
> > drivers/gpu/drm/drm_framebuffer.c | 110
> >
> > drivers/gpu/drm/drm_ioctl.c | 1 +
> > include/uapi/drm/drm.h | 2 +
> > 4 files changed, 115 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index c7d5e4c21423..16f2413403aa 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv);
> > int drm_mode_getfb(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv);
> > int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> >void *data, struct drm_file *file_priv);
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 57564318ceea..6db54f177443 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device *dev,
> >
> > out:
> > drm_framebuffer_put(fb);
> > + return ret;
> > +}
> > +
> > +/**
> > + * drm_mode_getfb2 - get extended FB info
> > + * @dev: drm device for the ioctl
> > + * @data: data pointer for the ioctl
> > + * @file_priv: drm file for the ioctl call
> > + *
> > + * Lookup the FB given its ID and return info about it.
> > + *
> > + * Called by the user via ioctl.
> > + *
> > + * Returns:
> > + * Zero on success, negative errno on failure.
> > + */
> > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv)
> > +{
> > + struct drm_mode_fb_cmd2 *r = data;
> > + struct drm_framebuffer *fb;
> > + unsigned int i;
> > + int ret;
> > +
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -EINVAL;
> > +
> > + fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > + if (!fb)
> > + return -ENOENT;
> > +
> > + /* For multi-plane framebuffers, we require the driver to place
> > the
> > +* GEM objects directly in the drm_framebuffer. For single-
> > plane
> > +* framebuffers, we can fall back to create_handle.
> > +*/
> > + if (!fb->obj[0] &&
> > + (fb->format->num_planes > 1 || !fb->funcs->create_handle))
> > {
> > + ret = -ENODEV;
> > + goto out;
> > + }
> > +
> > + r->height = fb->height;
> > + r->width = fb->width;
> > + r->pixel_format = fb->format->format;
> > +
> > + r->flags = 0;
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->flags |= DRM_MODE_FB_MODIFIERS;
> > +
> > + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> > + r->handles[i] = 0;
> > + r->pitches[i] = 0;
> > + r->offsets[i] = 0;
> > + r->modifier[i] = 0;
> > + }
> >
> > + for (i = 0; i < fb->format->num_planes; i++) {
> > + int j;
> > +
> > + r->pitches[i] = fb->pitches[i];
> > + r->offsets[i] = fb->offsets[i];
> > + if (dev->mode_config.allow_fb_modifiers)
> > + r->modifier[i] = fb->modifier;
> > +
> > + /* If we reuse the same object for multiple planes,
> > also
> > +* return the same handle.
> > +*/
> > + for (j = 0; j < i; j++) {
> > + if (fb->obj[i] == fb->obj[j]) {
> > + r->handles[i] = r->handles[j];
> > + break;
> > + }
> > + }
> > +
> > + if (r->handles[i])
> > + continue;
> > +
> > + if (fb->obj[i]) {
> > + ret = drm_gem_handle_create(file_priv, fb-
> > >obj[i],
> > + &r->handles[
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add mipi dsi command mode support.
== Series Details ==
Series: Add mipi dsi command mode support.
URL : https://patchwork.freedesktop.org/series/67974/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
83c4c64b055f drm/i915/dsi: Define command mode registers
900d9ba2700a drm/i915/dsi: Configure transcoder operation for command mode.
-:40: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'intel_dsi->dual_link'
#40: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:967:
+ if (is_vid_mode(intel_dsi) || (intel_dsi->dual_link))
total: 0 errors, 0 warnings, 1 checks, 56 lines checked
c778fa65e35c drm/i915/dsi: Add vblank calculation for command mode
-:53: WARNING:LONG_LINE: line over 100 characters
#53: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:862:
+ line_time_us = (htotal * (bpp / 8) *
byte_clk_period_ns) / (1000 * intel_dsi->lane_count);
-:60: CHECK:LINE_SPACING: Please don't use multiple blank lines
#60: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:869:
+
total: 0 errors, 1 warnings, 1 checks, 83 lines checked
91f92b97148b drm/i915/dsi: Helper to find dsi encoder in cmd mode
7a4fc89a244f drm/i915/dsi: Configure TE interrupt for cmd mode
-:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#60: FILE: drivers/gpu/drm/i915/i915_irq.c:2997:
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DSI))) {
-:78: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#78: FILE: drivers/gpu/drm/i915/i915_irq.c:3072:
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DSI))) {
total: 0 errors, 0 warnings, 2 checks, 81 lines checked
e600d6ff8306 drm/i915/dsi: Add TE handler for dsi cmd mode.
-:82: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#82: FILE: drivers/gpu/drm/i915/i915_irq.c:2751:
+ if ((INTEL_GEN(dev_priv) >= 11) &&
+ (iir & (ICL_DSI_0 | ICL_DSI_1))) {
total: 0 errors, 0 warnings, 1 checks, 73 lines checked
db7de625fd49 drm/i915/dsi: Initiate frame request in cmd mode
-:60: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#60: FILE: drivers/gpu/drm/i915/display/intel_display.c:11862:
+ if ((INTEL_GEN(dev_priv) >= 11) &&
+ (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))) {
-:71: CHECK:LINE_SPACING: Please don't use multiple blank lines
#71: FILE: drivers/gpu/drm/i915/display/intel_display.c:13626:
+
total: 0 errors, 0 warnings, 2 checks, 85 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/ehl: Port C's hotplug interrupt is associated with TC1 bits
On Thu, Oct 10, 2019 at 05:26:18PM -0700, Vivek Kasireddy wrote:
> On some platforms that have the MCC PCH, Port C's hotplug interrupt
> bits are mapped to TC1 bits.
>
> Suggested-by: Matt Roper
> Signed-off-by: Vivek Kasireddy
As Jose pointed out, the "some" in the message here isn't correct; all
MCC platforms should behave this way, and the other PCH we were working
with previously turned out to be something different (not actually MCC);
I'll send a separate patch to deal with that other PCH in the next day
or two.
Aside from that,
Reviewed-by: Matt Roper
Applied to dinq (with a tweaked commit message). Thanks for the patch.
Matt
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
> drivers/gpu/drm/i915/i915_irq.c | 8
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0e45c61d7331..6594f2af1257 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5282,6 +5282,9 @@ static bool icl_combo_port_connected(struct
> drm_i915_private *dev_priv,
> {
> enum port port = intel_dig_port->base.port;
>
> + if (HAS_PCH_MCC(dev_priv) && port == PORT_C)
> + return I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(PORT_TC1);
> +
> return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 3af7f7914c40..a7c968b01af3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2249,8 +2249,8 @@ static void icp_irq_handler(struct drm_i915_private
> *dev_priv, u32 pch_iir)
> tc_port_hotplug_long_detect = tgp_tc_port_hotplug_long_detect;
> pins = hpd_tgp;
> } else if (HAS_PCH_MCC(dev_priv)) {
> - ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
> - tc_hotplug_trigger = 0;
> + ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> + tc_hotplug_trigger = pch_iir & SDE_TC_HOTPLUG_ICP(PORT_TC1);
> pins = hpd_icp;
> } else {
> ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> @@ -3377,8 +3377,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private
> *dev_priv,
> static void mcc_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> icp_hpd_irq_setup(dev_priv,
> - SDE_DDI_MASK_TGP, 0,
> - TGP_DDI_HPD_ENABLE_MASK, 0,
> + SDE_DDI_MASK_ICP, SDE_TC_HOTPLUG_ICP(PORT_TC1),
> + ICP_DDI_HPD_ENABLE_MASK, ICP_TC_HPD_ENABLE(PORT_TC1),
> hpd_icp);
> }
>
> --
> 2.21.0
>
--
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
Re: [Intel-gfx] [RFC 1/7] drm/i915/dsi: Define command mode registers
On 2019-10-14 at 16:31:16 +0530, Vandita Kulkarni wrote:
> Adding all the register definitions needed
> for mipi dsi command mode.
>
> Signed-off-by: Madhav Chauhan
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 76 +
> 1 file changed, 68 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e24991e54897..73bc85855b79 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4919,14 +4919,20 @@ enum {
> #define BLM_PCH_POLARITY (1 << 29)
> #define BLC_PWM_PCH_CTL2 _MMIO(0xc8254)
>
> -#define UTIL_PIN_CTL _MMIO(0x48400)
> -#define UTIL_PIN_ENABLE(1 << 31)
> -
> -#define UTIL_PIN_PIPE(x) ((x) << 29)
> -#define UTIL_PIN_PIPE_MASK (3 << 29)
> -#define UTIL_PIN_MODE_PWM(1 << 24)
> -#define UTIL_PIN_MODE_MASK (0xf << 24)
> -#define UTIL_PIN_POLARITY(1 << 22)
> +#define UTIL_PIN_CTL _MMIO(0x48400)
> +#define UTIL_PIN_ENABLE (1 << 31)
> +#define UTIL_PIN_PIPE_MASK (3 << 29)
> +#define UTIL_PIN_PIPE(x)((x) << 29)
> +#define UTIL_PIN_MODE_MASK (0xf << 24)
> +#define UTIL_PIN_MODE_DATA (0 << 24)
> +#define UTIL_PIN_MODE_PWM (1 << 24)
> +#define UTIL_PIN_MODE_VBLANK(4 << 24)
> +#define UTIL_PIN_MODE_VSYNC (5 << 24)
> +#define UTIL_PIN_MODE_EYE_LEVEL (8 << 24)
> +#define UTIL_PIN_OP_DATA(1 << 23)
> +#define UTIL_PIN_POLARITY (1 << 22)
> +#define ICL_UTIL_PIN_DIRECTION (1 << 19)
> +#define ICL_UTIL_PIN_IP_DATA(1 << 16)
Could we drop this ICL prefix to align with existing bit definitions?
>
> /* BXT backlight register definition. */
> #define _BXT_BLC_PWM_CTL10xC8250
> @@ -7407,6 +7413,8 @@ enum {
> #define GEN8_DE_PORT_IMR _MMIO(0x4)
> #define GEN8_DE_PORT_IIR _MMIO(0x8)
> #define GEN8_DE_PORT_IER _MMIO(0xc)
> +#define ICL_DSI_1 (1 << 31)
> +#define ICL_DSI_0 (1 << 30)
> #define ICL_AUX_CHANNEL_E (1 << 29)
> #define CNL_AUX_CHANNEL_F (1 << 28)
> #define GEN9_AUX_CHANNEL_D (1 << 27)
> @@ -10659,6 +10667,57 @@ enum skl_power_gate {
> #define ICL_ESC_CLK_DIV_SHIFT 0
> #define DSI_MAX_ESC_CLK 2 /* in KHz */
>
> +#define _ICL_DSI_CMD_FRMCTL_00x6b034
> +#define _ICL_DSI_CMD_FRMCTL_10x6b834
> +#define ICL_DSI_CMD_FRMCTL(port) _MMIO_PORT(port,\
> + _ICL_DSI_CMD_FRMCTL_0,\
> + _ICL_DSI_CMD_FRMCTL_1)
might want to align with first char after (.
> +#define ICL_FRAME_UPDATE_REQUEST(1 << 31)
> +#define ICL_PERIODIC_FRAME_UPDATE_ENABLE(1 << 29)
> +#define ICL_NULL_PACKET_ENABLE (1 << 28)
> +#define ICL_FRAME_IN_PROGRESS (1 << 0)
> +
> +#define _ICL_DSI_INTR_MASK_REG_0 0x6b070
> +#define _ICL_DSI_INTR_MASK_REG_1 0x6b870
> +#define ICL_DSI_INTR_MASK_REG(port) _MMIO_PORT(port,\
> + _ICL_DSI_INTR_MASK_REG_0,\
> + _ICL_DSI_INTR_MASK_REG_1)
same here. and all below lines...
> +
> +#define _ICL_DSI_INTR_IDENT_REG_00x6b074
> +#define _ICL_DSI_INTR_IDENT_REG_10x6b874
> +#define ICL_DSI_INTR_IDENT_REG(port) _MMIO_PORT(port,\
> + _ICL_DSI_INTR_IDENT_REG_0,\
> + _ICL_DSI_INTR_IDENT_REG_1)
> +#define ICL_TE_EVENT(1 << 31)
> +#define ICL_RX_DATA_OR_BTA_TERMINATED (1 << 30)
> +#define ICL_TX_DATA (1 << 29)
> +#define ICL_ULPS_ENTRY_DONE (1 << 28)
> +#define ICL_NON_TE_TRIGGER_RECEIVED (1 << 27)
> +#define ICL_HOST_CHKSUM_ERROR (1 << 26)
> +#define ICL_HOST_MULTI_ECC_ERROR(1 << 25)
> +#define ICL_HOST_SINGL_ECC_ERROR(1 << 24)
> +#define ICL_HOST_CONTENTION_DETECTED(1 << 23)
> +#define ICL_HOST_FALSE_CONTROL_ERROR(1 << 22)
> +#define ICL_HOST_TIMEOUT_ERROR (1 << 21)
> +#define ICL_HOST_LOW_POWER_TX_SYNC_ERROR(1 << 20)
> +#define ICL_HOST_ESCAPE_MODE_ENTRY_ERROR(1 << 19)
> +#define ICL_FRAME_UPDATE_DONE (1 << 16)
> +#define ICL_PROTOCOL_VIOLATION_REPORTED (1 << 15)
> +#define ICL_INVALID_TX_LENGTH (1 << 13)
> +#define ICL_INVALID_VC (1 << 12)
> +#define ICL_INVALID_DATA_TYPE (1 << 11)
> +#define ICL_PERIPHERAL_CHKSUM_ERROR
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
== Series Details ==
Series: drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
URL : https://patchwork.freedesktop.org/series/67955/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7086 -> Patchwork_14789
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14789 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14789, 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_14789/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14789:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_coherency:
- fi-icl-u2: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-icl-u2/igt@i915_selftest@live_coherency.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-icl-u2/igt@i915_selftest@live_coherency.html
Known issues
Here are the changes found in Patchwork_14789 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@vgem_basic@dmabuf-fence:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-icl-u3/igt@vgem_ba...@dmabuf-fence.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-icl-u3/igt@vgem_ba...@dmabuf-fence.html
Possible fixes
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.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_7086/fi-blb-e6850/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_busy@basic-flip-a:
- {fi-tgl-u2}:[DMESG-WARN][11] ([fdo#111600]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7086/fi-tgl-u2/igt@kms_b...@basic-flip-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/fi-tgl-u2/igt@kms_b...@basic-flip-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
Participating hosts (52 -> 46)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7086 -> Patchwork_14789
CI-20190529: 20190529
CI_DRM_7086: cb64ca78fe223a03a902aa10ddbfb672ccad1630 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5225: 991ce4eede1c52f76378aebf162a13c20d6f6293 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14789: 331a8c3bc5fe3fe17edccf2ef38717183d5363b6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
331a8c3bc5fe drm/i915/execlists: Clear semaphore immediately upon ELSP promotion
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14789/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [01/15] drm/i915/display: Squelch kerneldoc warnings
== Series Details == Series: series starting with [01/15] drm/i915/display: Squelch kerneldoc warnings URL : https://patchwork.freedesktop.org/series/67970/ State : failure == Summary == Applying: drm/i915/display: Squelch kerneldoc warnings Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_display.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/i915/gem: Distinguish each object type Applying: drm/i915/execlists: Assert tasklet is locked for process_csb() Applying: drm/i915/execlists: Clear semaphore immediately upon ELSP promotion Applying: drm/i915/execlists: Tweak virtual unsubmission Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_lrc.c M drivers/gpu/drm/i915/i915_request.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/i915/selftests: Check known register values within the context Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/selftest_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/selftest_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gt/selftest_lrc.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0006 drm/i915/selftests: Check known register values within the context When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/execlists: Tweak virtual unsubmission
== Series Details == Series: drm/i915/execlists: Tweak virtual unsubmission URL : https://patchwork.freedesktop.org/series/67958/ State : failure == Summary == Applying: drm/i915/execlists: Tweak virtual unsubmission error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gt/intel_lrc.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/execlists: Tweak virtual unsubmission When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock
On 2019-10-10 21:30:35 [+0100], Chris Wilson wrote: > > | spin_lock_irq(&rq->engine->active.lock); > > | list_del(&rq->sched.link); > > | spin_unlock_irq(&rq->engine->active.lock); > > | > > | spin_lock_irq(&rq->lock); > > | i915_request_mark_complete(rq); > > … > > | spin_unlock_irq(&rq->lock); > > > > has been avoided because an interrupt here could change something or if > > this is just an optimisation. > > Just avoiding the back-to-back enable/disable. as I assumed. Is the patch okay? > -Chris Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915/gem: Cancel non-persistent contexts on close
On 14/10/2019 14:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 14:10:30)
On 14/10/2019 13:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 13:11:46)
On 14/10/2019 10:07, Chris Wilson wrote:
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangcheck mechanism. We are looking at perhaps replacing hangcheck
with a softer mechanism, that sends a pulse down the engine to check if
it is well. We can use the same preemptive pulse to flush an active
persistent context off the GPU upon context close, preventing resources
being lost and unkillable requests remaining on the GPU after process
termination. To avoid changing the ABI and accidentally breaking
existing userspace, we make the persistence of a context explicit and
enable it by default (matching current ABI). Userspace can opt out of
persistent mode (forcing requests to be cancelled when the context is
closed by process termination or explicitly) by a context parameter. To
facilitate existing use-cases of disabling hangcheck, if the modparam is
disabled (i915.enable_hangcheck=0), we disable persistence mode by
default. (Note, one of the outcomes for supporting endless mode will be
the removal of hangchecking, at which point opting into persistent mode
will be mandatory, or maybe the default perhaps controlled by cgroups.)
v2: Check for hangchecking at context termination, so that we are not
left with undying contexts from a crafty user.
v3: Force context termination even if forced-preemption is disabled.
Testcase: igt/gem_ctx_persistence
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Jon Bloomfield
Reviewed-by: Jon Bloomfield
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 182 ++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 ++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 2 +
include/uapi/drm/i915_drm.h | 15 ++
5 files changed, 215 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5d8221c7ba83..70b72456e2c4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -70,6 +70,7 @@
#include
#include "gt/intel_lrc_reg.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_user.h"
#include "i915_gem_context.h"
@@ -269,6 +270,128 @@ void i915_gem_context_release(struct kref *ref)
schedule_work(&gc->free_work);
}
+static inline struct i915_gem_engines *
+__context_engines_static(const struct i915_gem_context *ctx)
+{
+ return rcu_dereference_protected(ctx->engines, true);
+}
+
+static bool __reset_engine(struct intel_engine_cs *engine)
+{
+ struct intel_gt *gt = engine->gt;
+ bool success = false;
+
+ if (!intel_has_reset_engine(gt))
+ return false;
+
+ if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
+ >->reset.flags)) {
+ success = intel_engine_reset(engine, NULL) == 0;
+ clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
+ >->reset.flags);
+ }
+
+ return success;
+}
+
+static void __reset_context(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
+ "context closure in %s", ctx->name);
+}
+
+static bool __cancel_engine(struct intel_engine_cs *engine)
+{
+ /*
+ * Send a "high priority pulse" down the engine to cause the
+ * current request to be momentarily preempted. (If it fails to
+ * be preempted, it will be reset). As we have marked our context
+ * as banned, any incomplete request, including any running, will
+ * be skipped following the preemption.
+ */
+ if (CONFIG_DRM_I915_PREEMPT_TIMEOUT && !intel_engine_pulse(engine))
+ return true;
Maybe I lost the train of thought here.. But why not even try with the
pulse even if forced preemption is not compiled in? There is a chance it
may preempt normally, no?
If there is no reset-on-preemption failure and no hangchecking, there is
no reset and we are left with the denial-of-service that we are seeking
to close.
Because there is no mechanism to send a pulse, see if it managed to
preempt, but if it did not come come back later and reset?
What are you going to preempt with? The mechanism you describe is what
the pulse + forced-preempt is meant to be handling. (I was going to use
a 2 birds with one stone allegory for the various features all pulling
together, but it's more like a flock with
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Fixup naked 64b divide (rev2)
== Series Details == Series: drm/i915/selftests: Fixup naked 64b divide (rev2) URL : https://patchwork.freedesktop.org/series/67947/ State : failure == Summary == Applying: drm/i915/selftests: Fixup naked 64b divide Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/intel_memory_region.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/perf: Avoid polluting the i915_oa_config with error pointers
== Series Details == Series: drm/i915/perf: Avoid polluting the i915_oa_config with error pointers URL : https://patchwork.freedesktop.org/series/67949/ State : failure == Summary == Applying: drm/i915/perf: Avoid polluting the i915_oa_config with error pointers Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_perf.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14782/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/8] drm/i915: Polish WM_LINETIME register stuff
From: Ville Syrjälä
Let's store the normal and IPS linetime watermarks individually,
and while at it we'll pimp the register definitions as well.
v2: Deal with gvt
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/gvt/handlers.c | 6 +-
drivers/gpu/drm/i915/i915_reg.h | 14 ++--
drivers/gpu/drm/i915/intel_pm.c | 72 ++-
4 files changed, 52 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 40390d855815..841952332c7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -631,7 +631,8 @@ struct intel_crtc_scaler_state {
struct intel_pipe_wm {
struct intel_wm_level wm[5];
- u32 linetime;
+ u16 linetime;
+ u16 ips_linetime;
bool fbc_wm_enabled;
bool pipe_enabled;
bool sprites_enabled;
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 45a9124e53b6..f2ad477ede6b 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2397,9 +2397,9 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
MMIO_F(_MMIO(0x7144c), 0xc, 0, 0, 0, D_PRE_SKL, NULL, NULL);
MMIO_F(_MMIO(0x7244c), 0xc, 0, 0, 0, D_PRE_SKL, NULL, NULL);
- MMIO_D(PIPE_WM_LINETIME(PIPE_A), D_ALL);
- MMIO_D(PIPE_WM_LINETIME(PIPE_B), D_ALL);
- MMIO_D(PIPE_WM_LINETIME(PIPE_C), D_ALL);
+ MMIO_D(WM_LINETIME(PIPE_A), D_ALL);
+ MMIO_D(WM_LINETIME(PIPE_B), D_ALL);
+ MMIO_D(WM_LINETIME(PIPE_C), D_ALL);
MMIO_D(SPLL_CTL, D_ALL);
MMIO_D(_MMIO(_WRPLL_CTL1), D_ALL);
MMIO_D(_MMIO(_WRPLL_CTL2), D_ALL);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0fb9030b89f1..e1db85768084 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10394,13 +10394,13 @@ enum skl_power_gate {
#define D_COMP_COMP_DISABLE (1 << 0)
/* Pipe WM_LINETIME - watermark line time */
-#define _PIPE_WM_LINETIME_A0x45270
-#define _PIPE_WM_LINETIME_B0x45274
-#define PIPE_WM_LINETIME(pipe) _MMIO_PIPE(pipe, _PIPE_WM_LINETIME_A,
_PIPE_WM_LINETIME_B)
-#define PIPE_WM_LINETIME_MASK(0x1ff)
-#define PIPE_WM_LINETIME_TIME(x) ((x))
-#define PIPE_WM_LINETIME_IPS_LINETIME_MASK (0x1ff << 16)
-#define PIPE_WM_LINETIME_IPS_LINETIME(x) ((x) << 16)
+#define _WM_LINETIME_A 0x45270
+#define _WM_LINETIME_B 0x45274
+#define WM_LINETIME(pipe) _MMIO_PIPE(pipe, _WM_LINETIME_A, _WM_LINETIME_B)
+#define HSW_LINETIME_MASK REG_GENMASK(8, 0)
+#define HSW_LINETIME(x) REG_FIELD_PREP(HSW_LINETIME_MASK, (x))
+#define HSW_IPS_LINETIME_MASK REG_GENMASK(24, 16)
+#define HSW_IPS_LINETIME(x) REG_FIELD_PREP(HSW_IPS_LINETIME_MASK, (x))
/* SFUSE_STRAP */
#define SFUSE_STRAP_MMIO(0xc2014)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f21eb9250d23..f6893b771078 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2764,31 +2764,31 @@ static void ilk_compute_wm_level(const struct
drm_i915_private *dev_priv,
}
static u32
-hsw_compute_linetime_wm(const struct intel_crtc_state *crtc_state)
+hsw_linetime_wm(const struct intel_crtc_state *crtc_state)
{
- const struct intel_atomic_state *intel_state =
- to_intel_atomic_state(crtc_state->base.state);
const struct drm_display_mode *adjusted_mode =
&crtc_state->base.adjusted_mode;
- u32 linetime, ips_linetime;
if (!crtc_state->base.active)
return 0;
- if (WARN_ON(adjusted_mode->crtc_clock == 0))
- return 0;
- if (WARN_ON(intel_state->cdclk.logical.cdclk == 0))
- return 0;
- /* The WM are computed with base on how long it takes to fill a single
-* row at the given clock rate, multiplied by 8.
-* */
- linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
-adjusted_mode->crtc_clock);
- ips_linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
-intel_state->cdclk.logical.cdclk);
+ return DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8,
+adjusted_mode->crtc_clock);
+}
+
+static u32
+hsw_ips_linetime_wm(const struct intel_crtc_state *crtc_state)
+{
+ const struct intel_atomic_state *state =
+ to_intel_atomic_state(crtc_state->base.state);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
- return PIPE_WM_LINETIME_IPS_LINETIME(ips_linetime) |
-
Re: [Intel-gfx] [PATCH v3] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Mon, Oct 14, 2019 at 02:13:31PM +0300, Lisovskiy, Stanislav wrote:
> On Fri, 2019-10-11 at 16:49 -0700, James Ausmus wrote:
> > > + new_qgv_points_mask |= new_mask_bit;
> > > + }
> > > +
> > > + ret = icl_pcode_restrict_qgv_points(dev_priv,
> > > new_qgv_points_mask);
> > > + if (ret < 0)
> > > + DRM_DEBUG_KMS("Could not restrict required gqv
> > > points(%d)\n", ret);
> >
> > s/gqv/qgv/
> >
> >
> > Also, if we fail masking off the qgv points that can't support our BW
> > req, shouldn't we handle that failure somehow - maybe just disable
> > SAGV
> > entirely? Better we lose power than have flickering screens...
Sounds like dead code to me. My approach is: don't deal with hw/firmware
failures until they are proven to exist.
The debug msg should be an error so that we get a bug report if this
ever happens.
--
Ville Syrjälä
Intel
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
On Mon, Oct 14, 2019 at 09:27:07AM +, Lin, Wayne wrote:
>
>
> > -Original Message-
> > From: Ville Syrjala
> > Sent: Friday, October 4, 2019 10:19 PM
> > To: dri-de...@lists.freedesktop.org
> > Cc: intel-gfx@lists.freedesktop.org; Lin, Wayne
> > Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> >
> > From: Ville Syrjälä
> >
> > I think this should provide most of necessary logic for adding aspecr
> > ratios to
> > the HDMI 4k modes.
> >
> > Cc: Wayne Lin
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 37 +++--
> > 1 file changed, 31 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
> > c7f9f7ca75a2..c76814edc784 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> > drm_get_cea_aspect_ratio(const u8 video_code)
> > return edid_cea_modes[video_code].picture_aspect_ratio;
> > }
> >
> > +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> > +video_code) {
> > + return edid_4k_modes[video_code].picture_aspect_ratio;
> > +}
> > +
>
> There are no picture_aspect_ratio attributes defined for modes in
> edid_4k_modes[] now. Should add on those definitions.
>
> > /*
> > * Calculate the alternate clock for HDMI modes (those from the HDMI
> > vendor
> > * specific block).
> > @@ -3236,6 +3241,9 @@ static u8
> > drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_
> > if (!to_match->clock)
> > return 0;
> >
> > + if (to_match->picture_aspect_ratio)
> > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > const struct drm_display_mode *hdmi_mode =
> > &edid_4k_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const struct
> > drm_display_mode *to_match)
> > if (!to_match->clock)
> > return 0;
> >
> > + if (to_match->picture_aspect_ratio)
> > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > const struct drm_display_mode *hdmi_mode =
> > &edid_4k_modes[vic];
> > unsigned int clock1, clock2;
>
> Current code in drm_match_hdmi_mdoe() & drm_match_hdmi_mode_clock_tolerance()
> use hdmi_mode_alternate_clock() to find alternate clocks.
> In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode
> (4096x2160@24)
> due to there is no alternate clock defined for that mode in HDMI1.4b. But
> HDMI2.0 adds
> 23.98Hz for that mode. Maybe we should also revise that part.
I'm tempted to just remove that exception. I have a hard time imagining
it causing serious problems.
>
> > @@ -5218,6 +5229,7 @@
> > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > *frame,
> > const struct drm_display_mode *mode) {
> > enum hdmi_picture_aspect picture_aspect;
> > + u8 vic, hdmi_vic;
> > int err;
> >
> > if (!frame || !mode)
> > @@ -5230,7 +5242,8 @@
> > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > *frame,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > frame->pixel_repeat = 1;
> >
> > - frame->video_code = drm_mode_cea_vic(connector, mode);
> > + vic = drm_mode_cea_vic(connector, mode);
> > + hdmi_vic = drm_mode_hdmi_vic(connector, mode);
> >
> > frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> >
> > @@ -5244,11 +5257,15 @@
> > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > *frame,
> >
> > /*
> > * Populate picture aspect ratio from either
> > -* user input (if specified) or from the CEA mode list.
> > +* user input (if specified) or from the CEA/HDMI mode lists.
> > */
> > picture_aspect = mode->picture_aspect_ratio;
> > - if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> > - picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> > + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) {
> > + if (vic)
> > + picture_aspect = drm_get_cea_aspect_ratio(vic);
> > + else if (hdmi_vic)
> > + picture_aspect = drm_get_hdmi_aspect_ratio(hdmi_vic);
> > + }
> >
> > /*
> > * The infoframe can't convey anything but none, 4:3 @@ -5256,12
> > +5273,20 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> > hdmi_avi_infoframe *frame,
> > * we can only satisfy it by specifying the right VIC.
> > */
> > if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> > - if (picture_aspect !=
> > - drm_get_cea_aspect_ratio(frame->video_code))
> > + if (vic) {
> > + if (picture_aspect != drm_get_cea_aspect_ratio(vic))
> > +
Re: [Intel-gfx] [PATCH 11/15] drm/i915/execlists: Cancel banned contexts on schedule-out
On 14/10/2019 14:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 14:19:19)
On 14/10/2019 14:13, Chris Wilson wrote:
Quoting Chris Wilson (2019-10-14 13:34:35)
Quoting Tvrtko Ursulin (2019-10-14 13:25:58)
On 14/10/2019 13:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 13:00:01)
On 14/10/2019 10:07, Chris Wilson wrote:
+static void cancel_active(struct i915_request *rq,
+ struct intel_engine_cs *engine)
+{
+ struct intel_context * const ce = rq->hw_context;
+
+ /*
+ * The executing context has been cancelled. Fixup the context so that
+ * it will be marked as incomplete [-EIO] upon resubmission and not
(read below first)
... and not misleadingly say "Fixup the context so that it will be
marked as incomplete" because there is nothing in this function which
does that. It mostly happens by the virtual of context already being
marked as banned somewhere else. This comment should just explain the
decision to rewind the ring->head for more determinism. It can still
mention canceling of user payload and -EIO. Just needs to be clear of
the single extra thing achieved here by the head rewind and context edit.
I thought I was clear: "upon resubmission". So use a more active voice to
reduce ambiguity, gotcha.
/*
* The executing context has been cancelled. We want to prevent
* further execution along this context and propagate the error on
* to anything depending on its results.
*
* In __i915_request_submit(), we apply the -EIO and remove the
* requests payload for any banned requests. But first, we must
* rewind the context back to the start of the incomplete request so
* that we don't jump back into the middle of the batch.
*
* We preserve the breadcrumbs and semaphores of the incomplete
* requests so that inter-timeline dependencies (i.e other timelines)
* remain correctly ordered.
*/
Sounds good.
Btw.. does this work? :) If context was preempted in the middle of a
batch buffer there must be some other state saved (other than RING_HEAD)
which on context restore enables it to continue from the right place
*within* the batch. Is this code zapping that state as well so GPU will
fully forget it was inside the batch?
Yes. We are resetting the context image back to vanilla, and then
restore the ring registers to restart from this request. The selftests
are using spinning batches to simulate the banned context.
Okay, in that case:
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 10/10] drm/i915: Flush idle barriers when waiting
Quoting Tvrtko Ursulin (2019-10-14 14:08:12) > > On 11/10/2019 16:11, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-10-11 15:56:35) > >> > >> On 10/10/2019 08:14, Chris Wilson wrote: > >>> If we do find ourselves with an idle barrier inside our active while > >>> waiting, attempt to flush it by emitting a pulse using the kernel > >>> context. > >> > >> The point of this one completely escapes me at the moment. Idle barriers > >> are kept in there to be consumed by the engine_pm parking, so if any > >> random waiter finds some (there will always be some, as long as the > >> engine executed some user context, right?), > > > > Not any random waiter; the waiter has to be waiting on a context that > > was active and so setup a barrier. > > > >> why would it want to handle > >> them? Again just to use the opportunity for some house keeping? But what > >> if the system is otherwise quite busy and a low-priority client just > >> happens to want to wait on something silly? > > > > There's no guarantee that it will ever be flushed. So why wouldn't we > > use a low priority request to give a semblance of forward progress and > > give a guarantee that the wait will complete. > > > > It's a hypothetical point, there are no waiters that need to wait upon > > their own barriers at present. We are just completing the picture for > > idle barrier tracking. > > Hm I was mistakenly remembering things like rpcs reconfiguration would > wait on ce->active, but I forgot about your trick with putting kernel > context request on an user timeline. > > I guess it is fine there, but since, and as you have said, it is > hypothetical, then this patch is dead code and can wait. Why would we even bother checking against the potential invalid pointer dereference then?... :-p -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/i915/gem: Cancel non-persistent contexts on close
Quoting Tvrtko Ursulin (2019-10-14 14:10:30)
>
> On 14/10/2019 13:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-10-14 13:11:46)
> >>
> >> On 14/10/2019 10:07, Chris Wilson wrote:
> >>> Normally, we rely on our hangcheck to prevent persistent batches from
> >>> hogging the GPU. However, if the user disables hangcheck, this mechanism
> >>> breaks down. Despite our insistence that this is unsafe, the users are
> >>> equally insistent that they want to use endless batches and will disable
> >>> the hangcheck mechanism. We are looking at perhaps replacing hangcheck
> >>> with a softer mechanism, that sends a pulse down the engine to check if
> >>> it is well. We can use the same preemptive pulse to flush an active
> >>> persistent context off the GPU upon context close, preventing resources
> >>> being lost and unkillable requests remaining on the GPU after process
> >>> termination. To avoid changing the ABI and accidentally breaking
> >>> existing userspace, we make the persistence of a context explicit and
> >>> enable it by default (matching current ABI). Userspace can opt out of
> >>> persistent mode (forcing requests to be cancelled when the context is
> >>> closed by process termination or explicitly) by a context parameter. To
> >>> facilitate existing use-cases of disabling hangcheck, if the modparam is
> >>> disabled (i915.enable_hangcheck=0), we disable persistence mode by
> >>> default. (Note, one of the outcomes for supporting endless mode will be
> >>> the removal of hangchecking, at which point opting into persistent mode
> >>> will be mandatory, or maybe the default perhaps controlled by cgroups.)
> >>>
> >>> v2: Check for hangchecking at context termination, so that we are not
> >>> left with undying contexts from a crafty user.
> >>> v3: Force context termination even if forced-preemption is disabled.
> >>>
> >>> Testcase: igt/gem_ctx_persistence
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Joonas Lahtinen
> >>> Cc: Michał Winiarski
> >>> Cc: Jon Bloomfield
> >>> Reviewed-by: Jon Bloomfield
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_context.c | 182 ++
> >>>drivers/gpu/drm/i915/gem/i915_gem_context.h | 15 ++
> >>>.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> >>>.../gpu/drm/i915/gem/selftests/mock_context.c | 2 +
> >>>include/uapi/drm/i915_drm.h | 15 ++
> >>>5 files changed, 215 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> index 5d8221c7ba83..70b72456e2c4 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> @@ -70,6 +70,7 @@
> >>>#include
> >>>
> >>>#include "gt/intel_lrc_reg.h"
> >>> +#include "gt/intel_engine_heartbeat.h"
> >>>#include "gt/intel_engine_user.h"
> >>>
> >>>#include "i915_gem_context.h"
> >>> @@ -269,6 +270,128 @@ void i915_gem_context_release(struct kref *ref)
> >>>schedule_work(&gc->free_work);
> >>>}
> >>>
> >>> +static inline struct i915_gem_engines *
> >>> +__context_engines_static(const struct i915_gem_context *ctx)
> >>> +{
> >>> + return rcu_dereference_protected(ctx->engines, true);
> >>> +}
> >>> +
> >>> +static bool __reset_engine(struct intel_engine_cs *engine)
> >>> +{
> >>> + struct intel_gt *gt = engine->gt;
> >>> + bool success = false;
> >>> +
> >>> + if (!intel_has_reset_engine(gt))
> >>> + return false;
> >>> +
> >>> + if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
> >>> + >->reset.flags)) {
> >>> + success = intel_engine_reset(engine, NULL) == 0;
> >>> + clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
> >>> + >->reset.flags);
> >>> + }
> >>> +
> >>> + return success;
> >>> +}
> >>> +
> >>> +static void __reset_context(struct i915_gem_context *ctx,
> >>> + struct intel_engine_cs *engine)
> >>> +{
> >>> + intel_gt_handle_error(engine->gt, engine->mask, 0,
> >>> + "context closure in %s", ctx->name);
> >>> +}
> >>> +
> >>> +static bool __cancel_engine(struct intel_engine_cs *engine)
> >>> +{
> >>> + /*
> >>> + * Send a "high priority pulse" down the engine to cause the
> >>> + * current request to be momentarily preempted. (If it fails to
> >>> + * be preempted, it will be reset). As we have marked our context
> >>> + * as banned, any incomplete request, including any running, will
> >>> + * be skipped following the preemption.
> >>> + */
> >>> + if (CONFIG_DRM_I915_PREEMPT_TIMEOUT && !intel_engine_pulse(engine))
> >>> + return true;
> >>
> >> Maybe I lost the train of thought here.. But why not even try with the
> >> pulse even if forced preemption is not compiled in? There is a chance it
> >> may preempt normally,
Re: [Intel-gfx] [PATCH 11/15] drm/i915/execlists: Cancel banned contexts on schedule-out
Quoting Tvrtko Ursulin (2019-10-14 14:19:19)
>
> On 14/10/2019 14:13, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-10-14 13:34:35)
> >> Quoting Tvrtko Ursulin (2019-10-14 13:25:58)
> >>>
> >>> On 14/10/2019 13:06, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-10-14 13:00:01)
> >
> > On 14/10/2019 10:07, Chris Wilson wrote:
> >> +static void cancel_active(struct i915_request *rq,
> >> + struct intel_engine_cs *engine)
> >> +{
> >> + struct intel_context * const ce = rq->hw_context;
> >> +
> >> + /*
> >> + * The executing context has been cancelled. Fixup the context
> >> so that
> >> + * it will be marked as incomplete [-EIO] upon resubmission and
> >> not
> >>>
> >>> (read below first)
> >>>
> >>> ... and not misleadingly say "Fixup the context so that it will be
> >>> marked as incomplete" because there is nothing in this function which
> >>> does that. It mostly happens by the virtual of context already being
> >>> marked as banned somewhere else. This comment should just explain the
> >>> decision to rewind the ring->head for more determinism. It can still
> >>> mention canceling of user payload and -EIO. Just needs to be clear of
> >>> the single extra thing achieved here by the head rewind and context edit.
> >>
> >> I thought I was clear: "upon resubmission". So use a more active voice to
> >> reduce ambiguity, gotcha.
> >
> > /*
> > * The executing context has been cancelled. We want to prevent
> > * further execution along this context and propagate the error on
> > * to anything depending on its results.
> > *
> > * In __i915_request_submit(), we apply the -EIO and remove the
> > * requests payload for any banned requests. But first, we must
> > * rewind the context back to the start of the incomplete request
> > so
> > * that we don't jump back into the middle of the batch.
> > *
> > * We preserve the breadcrumbs and semaphores of the incomplete
> > * requests so that inter-timeline dependencies (i.e other
> > timelines)
> > * remain correctly ordered.
> > */
> >
>
> Sounds good.
>
> Btw.. does this work? :) If context was preempted in the middle of a
> batch buffer there must be some other state saved (other than RING_HEAD)
> which on context restore enables it to continue from the right place
> *within* the batch. Is this code zapping that state as well so GPU will
> fully forget it was inside the batch?
Yes. We are resetting the context image back to vanilla, and then
restore the ring registers to restart from this request. The selftests
are using spinning batches to simulate the banned context.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915/execlists: Cancel banned contexts on schedule-out
On 14/10/2019 14:13, Chris Wilson wrote:
Quoting Chris Wilson (2019-10-14 13:34:35)
Quoting Tvrtko Ursulin (2019-10-14 13:25:58)
On 14/10/2019 13:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 13:00:01)
On 14/10/2019 10:07, Chris Wilson wrote:
+static void cancel_active(struct i915_request *rq,
+ struct intel_engine_cs *engine)
+{
+ struct intel_context * const ce = rq->hw_context;
+
+ /*
+ * The executing context has been cancelled. Fixup the context so that
+ * it will be marked as incomplete [-EIO] upon resubmission and not
(read below first)
... and not misleadingly say "Fixup the context so that it will be
marked as incomplete" because there is nothing in this function which
does that. It mostly happens by the virtual of context already being
marked as banned somewhere else. This comment should just explain the
decision to rewind the ring->head for more determinism. It can still
mention canceling of user payload and -EIO. Just needs to be clear of
the single extra thing achieved here by the head rewind and context edit.
I thought I was clear: "upon resubmission". So use a more active voice to
reduce ambiguity, gotcha.
/*
* The executing context has been cancelled. We want to prevent
* further execution along this context and propagate the error on
* to anything depending on its results.
*
* In __i915_request_submit(), we apply the -EIO and remove the
* requests payload for any banned requests. But first, we must
* rewind the context back to the start of the incomplete request so
* that we don't jump back into the middle of the batch.
*
* We preserve the breadcrumbs and semaphores of the incomplete
* requests so that inter-timeline dependencies (i.e other timelines)
* remain correctly ordered.
*/
Sounds good.
Btw.. does this work? :) If context was preempted in the middle of a
batch buffer there must be some other state saved (other than RING_HEAD)
which on context restore enables it to continue from the right place
*within* the batch. Is this code zapping that state as well so GPU will
fully forget it was inside the batch?
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/execlists: Tweak virtual unsubmission
On 14/10/2019 10:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 10:50:25)
On 14/10/2019 10:41, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-14 10:34:31)
On 13/10/2019 21:30, Chris Wilson wrote:
Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from
overtaking each other on preemption") we have restricted requests to run
on their chosen engine across preemption events. We can take this
restriction into account to know that we will want to resubmit those
requests onto the same physical engine, and so can shortcircuit the
virtual engine selection process and keep the request on the same
engine during unwind.
References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each
other on preemption")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++---
drivers/gpu/drm/i915/i915_request.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e6bf633b48d5..03732e3f5ec7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -895,7 +895,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
list_for_each_entry_safe_reverse(rq, rn,
&engine->active.requests,
sched.link) {
- struct intel_engine_cs *owner;
if (i915_request_completed(rq))
continue; /* XXX */
@@ -910,8 +909,7 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
* engine so that it can be moved across onto another physical
* engine as load dictates.
*/
- owner = rq->hw_context->engine;
- if (likely(owner == engine)) {
+ if (likely(rq->execution_mask == engine->mask)) {
GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
if (rq_prio(rq) != prio) {
prio = rq_prio(rq);
@@ -922,6 +920,8 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
list_move(&rq->sched.link, pl);
active = rq;
} else {
+ struct intel_engine_cs *owner = rq->hw_context->engine;
I guess there is some benefit in doing fewer operations as long as we
are fixing the engine anyway (at the moment at least).
However on this branch here the concern was request completion racing
with preemption handling and with this change the breadcrumb will not
get canceled any longer and may get signaled on the virtual engine.
Which then leads to the explosion this branch fixed. At least that's
what I remembered in combination with the comment below..
No, we don't change back to the virtual engine, so that is not an issue.
The problem was only because of the rq->engine = owner where the
breadcrumbs were still on the previous engine lists and assumed to be
under that engine->breadcrumbs.lock (but would in future be assumed to be
under rq->engine->breadcrumbs.lock).
Breadcrumb signaling can only be set up on the physical engine? Hm, must
be fine since without preemption that would be the scenario exactly.
Okay, I see there is r-b from Ram already so no need for another one.
With no disrespect to Ram, as the expert you raised a technical point that
I would be happier to record as resolved with an r-b from yourself.
I went back to the patch I reviewed in July and it checks out.
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 11/15] drm/i915/execlists: Cancel banned contexts on schedule-out
Quoting Chris Wilson (2019-10-14 13:34:35)
> Quoting Tvrtko Ursulin (2019-10-14 13:25:58)
> >
> > On 14/10/2019 13:06, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2019-10-14 13:00:01)
> > >>
> > >> On 14/10/2019 10:07, Chris Wilson wrote:
> > >>> +static void cancel_active(struct i915_request *rq,
> > >>> + struct intel_engine_cs *engine)
> > >>> +{
> > >>> + struct intel_context * const ce = rq->hw_context;
> > >>> +
> > >>> + /*
> > >>> + * The executing context has been cancelled. Fixup the context so
> > >>> that
> > >>> + * it will be marked as incomplete [-EIO] upon resubmission and
> > >>> not
> >
> > (read below first)
> >
> > ... and not misleadingly say "Fixup the context so that it will be
> > marked as incomplete" because there is nothing in this function which
> > does that. It mostly happens by the virtual of context already being
> > marked as banned somewhere else. This comment should just explain the
> > decision to rewind the ring->head for more determinism. It can still
> > mention canceling of user payload and -EIO. Just needs to be clear of
> > the single extra thing achieved here by the head rewind and context edit.
>
> I thought I was clear: "upon resubmission". So use a more active voice to
> reduce ambiguity, gotcha.
/*
* The executing context has been cancelled. We want to prevent
* further execution along this context and propagate the error on
* to anything depending on its results.
*
* In __i915_request_submit(), we apply the -EIO and remove the
* requests payload for any banned requests. But first, we must
* rewind the context back to the start of the incomplete request so
* that we don't jump back into the middle of the batch.
*
* We preserve the breadcrumbs and semaphores of the incomplete
* requests so that inter-timeline dependencies (i.e other timelines)
* remain correctly ordered.
*/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
