[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vGPU kernel context kmemleak
== Series Details ==
Series: drm/i915: Fix vGPU kernel context kmemleak
URL : https://patchwork.freedesktop.org/series/71027/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7578 -> Patchwork_15807
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/index.html
Known issues
Here are the changes found in Patchwork_15807 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [TIMEOUT][2] ([i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4] ([i915#592])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-skl-lmem/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-skl-lmem/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_exec_parallel@basic:
- {fi-tgl-u}: [INCOMPLETE][5] ([i915#476]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-tgl-u/igt@gem_exec_paral...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-tgl-u/igt@gem_exec_paral...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-icl-u2: [FAIL][7] ([fdo#103375]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u2: [FAIL][9] ([fdo#111550]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [DMESG-FAIL][11] ([i915#722]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
- fi-cfl-guc: [DMESG-FAIL][13] ([i915#730]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2: [INCOMPLETE][15] ([i915#140]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#109635] / [i915#217]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][19] ([fdo#111096] / [i915#323]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][23] ([i915#553] / [i915#725]) ->
[DMESG-FAIL][24] ([i915#770])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-4770/igt@i915_selftest@live_blt.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/fi-hsw-4770/igt@i915_selftest@live_blt.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][26] ([i915#62] / [i915#92]) +7 similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[26]:
https://int
Re: [Intel-gfx] [CI 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Mon, 16 Dec 2019, Hans de Goede wrote: > At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 > different PWM controllers for controlling the LCD's backlight brightness. > > Either the one integrated into the PMIC or the one integrated into the > SoC (the 1st LPSS PWM controller). > > So far in the LPSS code on BYT we have skipped registering the LPSS PWM > controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is > present, assuming that in this case the PMIC PWM controller will be used. > > On CHT we have been relying on only 1 of the 2 PWM controllers being > enabled in the DSDT at the same time; and always registered the lookup. > > So far this has been working, but the correct way to determine which PWM > controller needs to be used is by checking a bit in the VBT table and > recently I've learned about 2 different BYT devices: > Point of View MOBII TAB-P800W > Acer Switch 10 SW5-012 > > Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS > PWM controller (and the VBT correctly indicates this), so here our old > heuristics fail. > > Since only the i915 driver has access to the VBT, this commit renames > the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM > controller to "pwm_pmic_backlight" so that the i915 driver can do a > pwm_get() for the right controller depending on the VBT bit, instead of > the i915 driver relying on a "pwm_backlight" lookup getting registered > which magically points to the right controller. > > Acked-by: Jani Nikula > Reviewed-by: Andy Shevchenko > Signed-off-by: Hans de Goede > --- > drivers/mfd/intel_soc_pmic_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/dsi: Move Crystal Cove PMIC panel GPIO lookup from mfd to the i915 driver
On Mon, 16 Dec 2019, Hans de Goede wrote: > Move the Crystal Cove PMIC panel GPIO lookup-table from > drivers/mfd/intel_soc_pmic_core.c to the i915 driver. > > The moved looked-up table is adding a GPIO lookup to the i915 PCI > device and the GPIO subsys allows only one lookup table per device, > > The intel_soc_pmic_core.c code only adds lookup-table entries for the > PMIC panel GPIO (as it deals only with the PMIC), but we also need to be > able to access some GPIOs on the SoC itself, which requires entries for > these GPIOs in the lookup-table. > > Since the lookup-table is attached to the i915 PCI device it really > should be part of the i915 driver, this will also allow us to extend > it with GPIOs from other sources when necessary. > > Acked-by: Linus Walleij > Reviewed-by: Andy Shevchenko > Reviewed-by: Ville Syrjälä > Signed-off-by: Hans de Goede > --- > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 23 +++- > drivers/mfd/intel_soc_pmic_core.c| 19 > 2 files changed, 22 insertions(+), 20 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Mon, 16 Dec 2019, Hans de Goede wrote:
> Hi,
>
> On 16-12-2019 10:30, Lee Jones wrote:
> > [...]
> >
> > > > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected
> > > > > > > > > > > to the SoC/LPSS
> > > > > > > > > > > PWM controller (and the VBT correctly indicates this), so
> > > > > > > > > > > here our old
> > > > > > > > > > > heuristics fail.
> > > > > > > > > > >
> > > > > > > > > > > Since only the i915 driver has access to the VBT, this
> > > > > > > > > > > commit renames
> > > > > > > > > > > the "pwm_backlight" lookup entries for the Crystal Cove
> > > > > > > > > > > PMIC's PWM
> > > > > > > > > > > controller to "pwm_pmic_backlight" so that the i915
> > > > > > > > > > > driver can do a
> > > > > > > > > > > pwm_get() for the right controller depending on the VBT
> > > > > > > > > > > bit, instead of
> > > > > > > > > > > the i915 driver relying on a "pwm_backlight" lookup
> > > > > > > > > > > getting registered
> > > > > > > > > > > which magically points to the right controller.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans de Goede
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/mfd/intel_soc_pmic_core.c | 2 +-
> > > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > For my own reference:
> > > > > > > > > >Acked-for-MFD-by: Lee Jones
> > > > > > > > >
> > > > > > > > > As mentioned in the cover-letter, to avoid breaking
> > > > > > > > > bi-sectability
> > > > > > > > > as well as to avoid breaking the intel-gfx CI we need to
> > > > > > > > > merge this series
> > > > > > > > > in one go through one tree. Specifically through the
> > > > > > > > > drm-intel tree.
> > > > > > > > > Is that ok with you ?
> > > > > > > > >
> > > > > > > > > If this is ok with you, then you do not have to do anything,
> > > > > > > > > I will just push
> > > > > > > > > the entire series to drm-intel.
> > > > > > > > > drivers/mfd/intel_soc_pmic_core.c
> > > > > > > > > does not see much changes so I do not expect this to lead to
> > > > > > > > > any conflicts.
> > > > > > > >
> > > > > > > > It's fine, so long as a minimal immutable pull-request is
> > > > > > > > provided.
> > > > > > > > Whether it's pulled or not will depend on a number of factors,
> > > > > > > > but it
> > > > > > > > needs to be an option.
> > > > > > >
> > > > > > > The way the drm subsys works that is not really a readily
> > > > > > > available
> > > > > > > option. The struct definition which this patch changes a single
> > > > > > > line in
> > > > > > > has not been touched since 2015-06-26 so I really doubt we will
> > > > > > > get a
> > > > > > > conflict from this.
> > > > > >
> > > > > > Always with the exceptions ...
> > > > > >
> > > > > > OOI, why does this *have* to go through the DRM tree?
> > > > >
> > > > > This patch renames the name used to lookup the pwm controller from
> > > > > "pwm_backlight" to "pwm_pmic_backlight" because there are 2 possible
> > > > > pwm controllers which may be used, one in the SoC itself and one
> > > > > in the PMIC. Which controller should be used is described in a table
> > > > > in the Video BIOS, so another part of this series adds this code to
> > > > > the i915 driver:
> > > > >
> > > > > - panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight");
> > > > > + /* Get the right PWM chip for DSI backlight according to VBT */
> > > > > + if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
> > > > > + panel->backlight.pwm = pwm_get(dev->dev,
> > > > > "pwm_pmic_backlight");
> > > > > + desc = "PMIC";
> > > > > + } else {
> > > > > + panel->backlight.pwm = pwm_get(dev->dev,
> > > > > "pwm_soc_backlight");
> > > > > + desc = "SoC";
> > > > > + }
> > > > >
> > > > > So both not to break bisectability, but also so as to not break the
> > > > > extensive
> > > > > CI system which is used to test the i915 driver we need the MFD
> > > > > change doing
> > > > > the rename to go upstrream through the same tree as the i915 change.
> > > > >
> > > > > I have even considered just squashing the 2 commits together as
> > > > > having only 1
> > > > > present, but not the other breaks stuff left and right.
> > > >
> > > > That doesn't answer the question.
> > > >
> > > > Why do they all *have* to go in via the DRM tree specifically?
> > >
> > > 1. As explained these chanegs need to stay together
> > > 2. This change is primarily a drm/i915 change. Also the i915 code sees
> > > lots
> > > of changes every cycle, where as the change to the mfd code touches a
> > > block
> > > of code which has not been touched since 2015-06-26, so the chance of
> > > conflicts
> > > is much bigger if this goes on through another tree.
> > >
> > > I honestly do not see the problem here? Let me reverse the question why
> > > should this
> > > NOT go in through the drm tree?
> >
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix vGPU kernel context kmemleak
Quoting Zhenyu Wang (2019-12-17 07:13:54) > Current GVT allocates kernel context as vGPU submission context. > For vGPU destroy, the kernel context needs to be close then released, > otherwise context's vm ppgtt resource would cause memleak issue like > below. This trys to add new helper to destroy kernel context for that. There's only been patches to remove the last of the kernel context for that last year, after which this is moot. -Chris ___ 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/2] drm/i915/dsi: Remove readback of panel orientation on BYT / CHT (rev2)
Hi all,
On 16-12-2019 21:55, Patchwork wrote:
== Series Details ==
Series: series starting with [1/2] drm/i915/dsi: Remove readback of panel
orientation on BYT / CHT (rev2)
URL : https://patchwork.freedesktop.org/series/70952/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7574_full -> Patchwork_15786_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15786_full absolutely need to
be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15786_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_15786_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@linear-16bpp-rotate-180:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7574/shard-tglb3/igt@kms_big...@linear-16bpp-rotate-180.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15786/shard-tglb8/igt@kms_big...@linear-16bpp-rotate-180.html
False positive, the dmesg-warn is a lockdep splat and this patch does not touch
any locking.
Regards,
Hans
### Piglit changes ###
Possible regressions
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 8
2 (NEW):
- {pig-hsw-4770r}:NOTRUN -> [FAIL][3] +19 similar issues
[3]: None
New tests
-
New tests have been introduced between CI_DRM_7574_full and
Patchwork_15786_full:
### New Piglit tests (20) ###
* object namespace pollution@texture with glcopyimagesubdata:
- Statuses : 1 fail(s)
- Exec time: [0.10] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-1-float-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.95] s
* spec@arb_query_buffer_object@coherency:
- Statuses : 1 fail(s)
- Exec time: [5.09] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 8 64
3:
- Statuses : 1 fail(s)
- Exec time: [0.11] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 8 64
8:
- Statuses : 1 fail(s)
- Exec time: [0.08] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 8 8
8:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8
128 1:
- Statuses : 1 fail(s)
- Exec time: [0.26] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8
128 8:
- Statuses : 1 fail(s)
- Exec time: [0.24] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 64
1:
- Statuses : 1 fail(s)
- Exec time: [0.23] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 64
4:
- Statuses : 1 fail(s)
- Exec time: [0.33] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 8
1:
- Statuses : 1 fail(s)
- Exec time: [0.22] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 8
3:
- Statuses : 1 fail(s)
- Exec time: [0.25] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 8
4:
- Statuses : 1 fail(s)
- Exec time: [0.24] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 8
7:
- Statuses : 1 fail(s)
- Exec time: [0.24] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 8
8:
- Statuses : 1 fail(s)
- Exec time: [0.28] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1
128 7:
- Statuses : 1 fail(s)
- Exec time: [0.17] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1
128 8:
- Statuses : 1 fail(s)
- Exec time: [0.18] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 8
2:
- Statuses : 1 fail(s)
- Exec time: [0.18] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 8
8:
- Statuses : 1 fail(s)
- Exec time: [0.13] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-uint_uvec2_array3-double_dmat3x2:
- Statuses : 1 fail(s)
- Exec time: [0.18] s
Known issues
Here are the changes found in Patchwork_15786_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vcs1-reset:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#109276] / [fdo#112080])
+1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7574/shard-iclb2/igt@gem_ctx_isolat...@vcs1-reset.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patc
[Intel-gfx] [PULL] drm-misc-next
Hey, First pull for v5.6! Enjoy! ~Maarten drm-misc-next-2019-12-16: drm-misc-next for v5.6: UAPI Changes: - Add support for DMA-BUF HEAPS. Cross-subsystem Changes: - mipi dsi definition updates, pulled into drm-intel as well. - Add lockdep annotations for dma_resv vs mmap_sem and fs_reclaim. - Remove support for dma-buf kmap/kunmap. - Constify fb_ops in all fbdev drivers, including drm drivers and drm-core, and media as well. Core Changes: - Small cleanups to ttm. - Fix SCDC definition. - Assorted cleanups to core. - Add todo to remove load/unload hooks, and use generic fbdev emulation. - Assorted documentation updates. - Use blocking ww lock in ttm fault handler. - Remove drm_fb_helper_fbdev_setup/teardown. - Warning fixes with W=1 for atomic. - Use drm_debug_enabled() instead of drm_debug flag testing in various drivers. - Fallback to nontiled mode in fbdev emulation when not all tiles are present. (Later on reverted) - Various kconfig indentation fixes in core and drivers. - Fix freeing transactions in dp-mst correctly. - Sean Paul is steping down as core maintainer. :-( - Add lockdep annotations for atomic locks vs dma-resv. - Prevent use-after-free for a bad job in drm_scheduler. - Fill out all block sizes in the P01x and P210 definitions. - Avoid division by zero in drm/rect, and fix bounds. - Add drm/rect selftests. - Add aspect ratio and alternate clocks for HDMI 4k modes. - Add todo for drm_framebuffer_funcs and fb_create cleanup. - Drop DRM_AUTH for prime import/export ioctls. - Clear DP-MST payload id tables downstream when initializating. - Fix for DSC throughput definition. - Add extra FEC definitions. - Fix fake offset in drm_gem_object_funs.mmap. - Stop using encoder->bridge in core directly - Handle bridge chaining slightly better. - Add backlight support to drm/panel, and use it in many panel drivers. - Increase max number of y420 modes from 128 to 256, as preparation to add the new modes. Driver Changes: - Small fixes all over. - Fix documentation in vkms. - Fix mmap_sem vs dma_resv in nouveau. - Small cleanup in komeda. - Add page flip support in gma500 for psb/cdv. - Add ddc symlink in the connector sysfs directory for many drivers. - Add support for analogic an6345, and fix small bugs in it. - Add atomic modesetting support to ast. - Fix radeon fault handler VMA race. - Switch udl to use generic shmem helpers. - Unconditional vblank handling for mcde. - Miscellaneous fixes to mcde. - Tweak debug output from komeda using debugfs. - Add gamma and color transform support to komeda for DOU-IPS. - Add support for sony acx424AKP panel. - Various small cleanups to gma500. - Use generic fbdev emulation in udl, and replace udl_framebuffer with generic implementation. - Add support for Logic PD Type 28 panel. - Use drm_panel_* wrapper functions in exynos/tegra/msm. - Add devicetree bindings for generic DSI panels. - Don't include drm_pci.h directly in many drivers. - Add support for begin/end_cpu_access in udmabuf. - Stop using drm_get_pci_dev in gma500 and mga200. - Fixes to UDL damage handling, and use dma_buf_begin/end_cpu_access. - Add devfreq thermal support to panfrost. - Fix hotplug with daisy chained monitors by removing VCPI when disabling topology manager. - meson: Add support for OSD1 plane AFBC commit. - Stop displaying garbage when toggling ast primary plane on/off. - More cleanups and fixes to UDL. - Add D32 suport to komeda. - Remove globle copy of drm_dev in gma500. - Add support for Boe Himax8279d MIPI-DSI LCD panel. - Add support for ingenic JZ4770 panel. - Small null pointer deference fix in ingenic. - Remove support for the special tfp420 driver, as there is a generic way to do it. The following changes since commit fae7d7d5f374eadbb0b5dd31b39162e7176e9c3d: Revert "dma-buf: Add dma-buf heaps framework" (2019-10-30 16:41:49 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-12-16 for you to fetch changes up to 2156873f08c7893811f34177aa923ab1ea486591: drm/tilcdc: Remove obsolete bundled tilcdc tfp410 driver (2019-12-16 10:45:43 +0200) drm-misc-next for v5.6: UAPI Changes: - Add support for DMA-BUF HEAPS. Cross-subsystem Changes: - mipi dsi definition updates, pulled into drm-intel as well. - Add lockdep annotations for dma_resv vs mmap_sem and fs_reclaim. - Remove support for dma-buf kmap/kunmap. - Constify fb_ops in all fbdev drivers, including drm drivers and drm-core, and media as well. Core Changes: - Small cleanups to ttm. - Fix SCDC definition. - Assorted cleanups to core. - Add todo to remove load/unload hooks, and use generic fbdev emulation. - Assorted documentation updates. - Use blocking ww lock in ttm fault handler. - Remove drm_fb_helper_fbdev_setup/teardown. - Warning fixes with W=1 for atomic. - Use drm_debug_enabled() instead of drm_debug flag testing in various drivers. - Fallback to nontiled mode in fbd
[Intel-gfx] [PATCH] drm/i915/gt: Avoid multi-LRI on Sandybridge
Sandybridge is the gen that didn't handle multiple registers in a single
LRI packet. Don't forget it!
Fixes: 902eb748e5c3 ("drm/i915/gt: Tidy up full-ppgtt on Ivybridge")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 00d1fb582e95..1539362fb41d 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1370,17 +1370,17 @@ static int load_pd_dir(struct i915_request *rq,
const struct intel_engine_cs * const engine = rq->engine;
u32 *cs;
- cs = intel_ring_begin(rq, 10);
+ cs = intel_ring_begin(rq, 12);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(3);
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base));
*cs++ = valid;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
*cs++ = px_base(ppgtt->pd)->ggtt_offset << 10;
- *cs++ = i915_mmio_reg_offset(RING_INSTPM(engine->mmio_base));
- *cs++ = _MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE);
/* Stall until the page table load is complete? */
*cs++ = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
@@ -1388,6 +1388,11 @@ static int load_pd_dir(struct i915_request *rq,
*cs++ = intel_gt_scratch_offset(engine->gt,
INTEL_GT_SCRATCH_FIELD_DEFAULT);
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(RING_INSTPM(engine->mmio_base));
+ *cs++ = _MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE);
+
+
intel_ring_advance(rq, cs);
return 0;
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Avoid multi-LRI on Sandybridge
== Series Details == Series: drm/i915/gt: Avoid multi-LRI on Sandybridge URL : https://patchwork.freedesktop.org/series/71029/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9825d1f6a29e drm/i915/gt: Avoid multi-LRI on Sandybridge -:47: CHECK:LINE_SPACING: Please don't use multiple blank lines #47: FILE: drivers/gpu/drm/i915/gt/intel_ring_submission.c:1395: + + total: 0 errors, 0 warnings, 1 checks, 32 lines checked ___ 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 / LPSS / mfd: Select correct PWM controller to use based on VBT (rev3)
== Series Details == Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT (rev3) URL : https://patchwork.freedesktop.org/series/69686/ State : success == Summary == CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15800_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15800_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs0-s3: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl9/igt@gem_ctx_isolat...@vcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-skl7/igt@gem_ctx_isolat...@vcs0-s3.html * igt@gem_ctx_persistence@vcs1-cleanup: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_ctx_persiste...@vcs1-cleanup.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-iclb5/igt@gem_ctx_persiste...@vcs1-cleanup.html * igt@gem_exec_basic@readonly-vcs1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_ba...@readonly-vcs1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-iclb5/igt@gem_exec_ba...@readonly-vcs1.html * igt@gem_exec_create@basic: - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111736]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb4/igt@gem_exec_cre...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-tglb6/igt@gem_exec_cre...@basic.html * igt@gem_exec_gttfill@basic: - shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111593]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@gem_exec_gttf...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-tglb5/igt@gem_exec_gttf...@basic.html * igt@gem_exec_nop@basic-series: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#435]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@gem_exec_...@basic-series.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-tglb6/igt@gem_exec_...@basic-series.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-iclb5/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][19] -> [FAIL][20] ([i915#454]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb2/igt@i915_pm...@dc6-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_selftest@live_gem_contexts: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#455]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb2/igt@i915_selftest@live_gem_contexts.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-tglb6/igt@i915_selftest@live_gem_contexts.html * igt@kms_color@pipe-b-ctm-0-5: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([i915#109]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl10/igt@kms_co...@pipe-b-ctm-0-5.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-skl9/igt@kms_co...@pipe-b-ctm-0-5.html * igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#54]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-256x256-sliding.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15800/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-2
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/perf: open access for CAP_SYS_PERFMON privileged process
On 16/12/2019 22:03, Alexey Budankov wrote: Open access to i915_perf monitoring for CAP_SYS_PERFMON privileged processes. For backward compatibility reasons access to i915_perf subsystem remains open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure i915_perf monitoring is discouraged with respect to CAP_SYS_PERFMON capability. Signed-off-by: Alexey Budankov Assuming people are fine with this new cap, I like this idea of a lighter privilege for i915-perf. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/selftests: Disable heartbeats around long queues
For some execlists scheduler tests we assume very precise layout of the
inflight queue and become angry if the heartbeat interferes by
reprioritising our contexts (because we happen to be using the same
engine->kernel_context for our test).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 42 +-
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index ac8b9116d307..54bce282717a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -50,6 +50,24 @@ static struct i915_vma *create_scratch(struct intel_gt *gt)
return vma;
}
+static void engine_heartbeat_disable(struct intel_engine_cs *engine,
+unsigned long *saved)
+{
+ *saved = engine->props.heartbeat_interval_ms;
+ engine->props.heartbeat_interval_ms = 0;
+
+ intel_engine_pm_get(engine);
+ intel_engine_park_heartbeat(engine);
+}
+
+static void engine_heartbeat_enable(struct intel_engine_cs *engine,
+ unsigned long saved)
+{
+ intel_engine_pm_put(engine);
+
+ engine->props.heartbeat_interval_ms = saved;
+}
+
static int live_sanitycheck(void *arg)
{
struct intel_gt *gt = arg;
@@ -128,6 +146,7 @@ static int live_unlite_restore(struct intel_gt *gt, int
prio)
struct intel_context *ce[2] = {};
struct i915_request *rq[2];
struct igt_live_test t;
+ unsigned long saved;
int n;
if (prio && !intel_engine_has_preemption(engine))
@@ -140,6 +159,7 @@ static int live_unlite_restore(struct intel_gt *gt, int
prio)
err = -EIO;
break;
}
+ engine_heartbeat_disable(engine, &saved);
for (n = 0; n < ARRAY_SIZE(ce); n++) {
struct intel_context *tmp;
@@ -247,6 +267,7 @@ static int live_unlite_restore(struct intel_gt *gt, int
prio)
intel_context_put(ce[n]);
}
+ engine_heartbeat_enable(engine, saved);
if (igt_live_test_end(&t))
err = -EIO;
if (err)
@@ -468,12 +489,16 @@ static int live_timeslice_preempt(void *arg)
enum intel_engine_id id;
for_each_engine(engine, gt, id) {
+ unsigned long saved;
+
if (!intel_engine_has_preemption(engine))
continue;
memset(vaddr, 0, PAGE_SIZE);
+ engine_heartbeat_disable(engine, &saved);
err = slice_semaphore_queue(engine, vma, count);
+ engine_heartbeat_enable(engine, saved);
if (err)
goto err_pin;
@@ -566,17 +591,19 @@ static int live_timeslice_queue(void *arg)
.priority = I915_USER_PRIORITY(I915_PRIORITY_MAX),
};
struct i915_request *rq, *nop;
+ unsigned long saved;
if (!intel_engine_has_preemption(engine))
continue;
+ engine_heartbeat_disable(engine, &saved);
memset(vaddr, 0, PAGE_SIZE);
/* ELSP[0]: semaphore wait */
rq = semaphore_queue(engine, vma, 0);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_pin;
+ goto err_heartbeat;
}
engine->schedule(rq, &attr);
wait_for_submit(engine, rq);
@@ -585,8 +612,7 @@ static int live_timeslice_queue(void *arg)
nop = nop_request(engine);
if (IS_ERR(nop)) {
err = PTR_ERR(nop);
- i915_request_put(rq);
- goto err_pin;
+ goto err_rq;
}
wait_for_submit(engine, nop);
i915_request_put(nop);
@@ -596,10 +622,8 @@ static int live_timeslice_queue(void *arg)
/* Queue: semaphore signal, matching priority as semaphore */
err = release_queue(engine, vma, 1, effective_prio(rq));
- if (err) {
- i915_request_put(rq);
- goto err_pin;
- }
+ if (err)
+ goto err_rq;
intel_engine_flush_submission(engine);
if (!READ_ONCE(engine->execlists.timer.expires) &&
@@ -630,12 +654,14 @@ static int live_timeslice_queue(void *arg)
memset(vaddr, 0xff, PAGE_SIZE);
err = -EIO;
}
+err_rq:
i915_request_put(rq);
+err_heartbeat:
+
[Intel-gfx] [PATCH 2/8] drm/i915: Hold reference to intel_frontbuffer as we track activity
Since obj->frontbuffer is no longer protected by the struct_mutex, as we
are processing the execbuf, it may be removed. Mark the
intel_frontbuffer as rcu protected, and so acquire a reference to
the struct as we track activity upon it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/827
Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: # v5.4+
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
.../gpu/drm/i915/display/intel_frontbuffer.c | 16 -
.../gpu/drm/i915/display/intel_frontbuffer.h | 34 +--
drivers/gpu/drm/i915/display/intel_overlay.c | 17 +++---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 4 +--
drivers/gpu/drm/i915/gem/i915_gem_object.c| 26 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 23 -
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
drivers/gpu/drm/i915/i915_vma.c | 10 --
11 files changed, 116 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 64e4bfb0dfc9..e18ee1f17d6e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15186,7 +15186,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
return ret;
fb_obj_bump_render_priority(obj);
- intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_DIRTYFB);
+ i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
if (!new_plane_state->uapi.fence) { /* implicit fencing */
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 84b164f31895..6cb02c912acc 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -229,11 +229,11 @@ static void frontbuffer_release(struct kref *ref)
vma->display_alignment = I915_GTT_MIN_ALIGNMENT;
spin_unlock(&obj->vma.lock);
- obj->frontbuffer = NULL;
+ RCU_INIT_POINTER(obj->frontbuffer, NULL);
spin_unlock(&to_i915(obj->base.dev)->fb_tracking.lock);
i915_gem_object_put(obj);
- kfree(front);
+ kfree_rcu(front, rcu);
}
struct intel_frontbuffer *
@@ -242,11 +242,7 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct intel_frontbuffer *front;
- spin_lock(&i915->fb_tracking.lock);
- front = obj->frontbuffer;
- if (front)
- kref_get(&front->ref);
- spin_unlock(&i915->fb_tracking.lock);
+ front = __intel_frontbuffer_get(obj);
if (front)
return front;
@@ -262,13 +258,13 @@ intel_frontbuffer_get(struct drm_i915_gem_object *obj)
i915_active_may_sleep(frontbuffer_retire));
spin_lock(&i915->fb_tracking.lock);
- if (obj->frontbuffer) {
+ if (rcu_access_pointer(obj->frontbuffer)) {
kfree(front);
- front = obj->frontbuffer;
+ front = rcu_dereference_protected(obj->frontbuffer, true);
kref_get(&front->ref);
} else {
i915_gem_object_get(obj);
- obj->frontbuffer = front;
+ rcu_assign_pointer(obj->frontbuffer, front);
}
spin_unlock(&i915->fb_tracking.lock);
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
index adc64d61a4a5..ae4a1fff9f41 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
@@ -27,10 +27,10 @@
#include
#include
+#include "gem/i915_gem_object_types.h"
#include "i915_active.h"
struct drm_i915_private;
-struct drm_i915_gem_object;
enum fb_op_origin {
ORIGIN_GTT,
@@ -45,6 +45,7 @@ struct intel_frontbuffer {
atomic_t bits;
struct i915_active write;
struct drm_i915_gem_object *obj;
+ struct rcu_head rcu;
};
void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
@@ -54,6 +55,35 @@ void intel_frontbuffer_flip_complete(struct drm_i915_private
*i915,
void intel_frontbuffer_flip(struct drm_i915_private *i915,
unsigned frontbuffer_bits);
+void intel_frontbuffer_put(struct intel_frontbuffer *front);
+
+static inline struct intel_frontbuffer *
+__intel_frontbuffer_get(const struct drm_i915_gem_object *obj)
+{
+ struct intel_frontbuffer *front;
+
+ if (likely(!rcu_access_pointer(obj->frontbuffer)))
+ return NULL;
+
+ rcu_read_lock();
+ do {
+ front = rcu_dereference(obj->frontbuffer);
+ if (!fr
[Intel-gfx] [PATCH 6/8] drm/i915/selftests: Impose a timeout for request submission
Avoid spinning indefinitely waiting for the request to be submitted, and
instead apply a timeout. A secondary benefit is that the error message
will show which suspect is blocked.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 54bce282717a..3976198eff37 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -532,13 +532,19 @@ static struct i915_request *nop_request(struct
intel_engine_cs *engine)
return rq;
}
-static void wait_for_submit(struct intel_engine_cs *engine,
- struct i915_request *rq)
+static int wait_for_submit(struct intel_engine_cs *engine,
+ struct i915_request *rq,
+ unsigned long timeout)
{
+ timeout += jiffies;
do {
cond_resched();
intel_engine_flush_submission(engine);
- } while (!i915_request_is_active(rq));
+ if (i915_request_is_active(rq))
+ return 0;
+ } while (time_before(jiffies, timeout));
+
+ return -ETIME;
}
static long timeslice_threshold(const struct intel_engine_cs *engine)
@@ -606,7 +612,12 @@ static int live_timeslice_queue(void *arg)
goto err_heartbeat;
}
engine->schedule(rq, &attr);
- wait_for_submit(engine, rq);
+ err = wait_for_submit(engine, rq, HZ / 2);
+ if (err) {
+ pr_err("%s: Timed out trying to submit semaphores\n",
+ engine->name);
+ goto err_rq;
+ }
/* ELSP[1]: nop request */
nop = nop_request(engine);
@@ -614,8 +625,13 @@ static int live_timeslice_queue(void *arg)
err = PTR_ERR(nop);
goto err_rq;
}
- wait_for_submit(engine, nop);
+ err = wait_for_submit(engine, nop, HZ / 2);
i915_request_put(nop);
+ if (err) {
+ pr_err("%s: Timed out trying to submit nop\n",
+ engine->name);
+ goto err_rq;
+ }
GEM_BUG_ON(i915_request_completed(rq));
GEM_BUG_ON(execlists_active(&engine->execlists) != rq);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Unpin vma->obj on early error
If we inherit an error along the fence chain, we skip the main work
callback and go straight to the error. In the case of the vma bind
worker, we only dropped the pinned pages from the worker.
In the process, make sure we call the release earlier rather than wait
until the final reference to the fence is dropped (as a reference is
kept while being listened upon).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 11 ---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 15 ++-
drivers/gpu/drm/i915/i915_vma.c | 17 +
3 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index b9f504ba3b32..5448efa77710 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -26,27 +26,24 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
static int clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
- struct drm_i915_gem_object *obj = fetch_and_zero(&clflush->obj);
+ struct drm_i915_gem_object *obj = clflush->obj;
int err;
err = i915_gem_object_pin_pages(obj);
if (err)
- goto put;
+ return err;
__do_clflush(obj);
i915_gem_object_unpin_pages(obj);
-put:
- i915_gem_object_put(obj);
- return err;
+ return 0;
}
static void clflush_release(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
- if (clflush->obj)
- i915_gem_object_put(clflush->obj);
+ i915_gem_object_put(clflush->obj);
}
static const struct dma_fence_work_ops clflush_ops = {
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 8538ee7a521d..997b2998f1f2 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -6,6 +6,13 @@
#include "i915_sw_fence_work.h"
+static void fence_complete(struct dma_fence_work *f)
+{
+ if (f->ops->release)
+ f->ops->release(f);
+ dma_fence_signal(&f->dma);
+}
+
static void fence_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
@@ -14,7 +21,8 @@ static void fence_work(struct work_struct *work)
err = f->ops->work(f);
if (err)
dma_fence_set_error(&f->dma, err);
- dma_fence_signal(&f->dma);
+
+ fence_complete(f);
dma_fence_put(&f->dma);
}
@@ -32,7 +40,7 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
dma_fence_get(&f->dma);
queue_work(system_unbound_wq, &f->work);
} else {
- dma_fence_signal(&f->dma);
+ fence_complete(f);
}
break;
@@ -60,9 +68,6 @@ static void fence_release(struct dma_fence *fence)
{
struct dma_fence_work *f = container_of(fence, typeof(*f), dma);
- if (f->ops->release)
- f->ops->release(f);
-
i915_sw_fence_fini(&f->chain);
BUILD_BUG_ON(offsetof(typeof(*f), dma));
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6794c742fbbf..878975b37a45 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -292,6 +292,7 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
struct i915_vma_work {
struct dma_fence_work base;
struct i915_vma *vma;
+ struct drm_i915_gem_object *pin;
enum i915_cache_level cache_level;
unsigned int flags;
};
@@ -306,15 +307,21 @@ static int __vma_bind(struct dma_fence_work *work)
if (err)
atomic_or(I915_VMA_ERROR, &vma->flags);
- if (vma->obj)
- __i915_gem_object_unpin_pages(vma->obj);
-
return err;
}
+static void __vma_release(struct dma_fence_work *work)
+{
+ struct i915_vma_work *vw = container_of(work, typeof(*vw), base);
+
+ if (vw->pin)
+ __i915_gem_object_unpin_pages(vw->pin);
+}
+
static const struct dma_fence_work_ops bind_ops = {
.name = "bind",
.work = __vma_bind,
+ .release = __vma_release,
};
struct i915_vma_work *i915_vma_work(void)
@@ -395,8 +402,10 @@ int i915_vma_bind(struct i915_vma *vma,
i915_active_set_exclusive(&vma->active, &work->base.dma);
work->base.dma.error = 0; /* enable the queue_work() */
- if (vma->obj)
+ if (vma->obj) {
__i915_gem_object_pin_pages(vma->obj);
+ work->pin = vma->obj;
+ }
} else {
GEM_BUG_ON((bind_flags & ~vma_flags) &
vma->vm->bind_async_flags);
[Intel-gfx] [PATCH 3/8] drm/i915/display: Silence powerwell debug
As we may try to toggle the powerwell several hundred thousand times a
second, emitting several debug messages for each event simply
overwhelms the reader, cibuglog and the filesystem!
TLDR; logging overload.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/Kconfig.debug| 12 +++
.../drm/i915/display/intel_display_power.c| 74 ++-
2 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 206882e154bc..8168c76aa24c 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -221,3 +221,15 @@ config DRM_I915_DEBUG_RUNTIME_PM
driver loading, suspend and resume operations.
If in doubt, say "N"
+
+config DRM_I915_DEBUG_DISPLAY_POWERWELL
+ bool "Enable extra state checking for display powerwels"
+ depends on DRM_I915
+ default n
+ help
+ Choose this option to turn on extra state checking for the
+ display powerwells (part of the runtime power management
+ functionality). This may introduce overhead during execution
+ and excessive log space consumption.
+
+ If in doubt, say "N"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 679457156797..99b32bfbbda3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -19,6 +19,12 @@
#include "intel_tc.h"
#include "intel_vga.h"
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_DISPLAY_POWERWELL)
+#define DBG(...) DRM_DEBUG_KMS(__VA_ARGS)
+#else
+#define DBG(...) do { } while (0)
+#endif
+
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
enum i915_power_well_id power_well_id);
@@ -159,7 +165,7 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
static void intel_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- DRM_DEBUG_KMS("enabling %s\n", power_well->desc->name);
+ DBG("enabling %s\n", power_well->desc->name);
power_well->desc->ops->enable(dev_priv, power_well);
power_well->hw_enabled = true;
}
@@ -167,7 +173,7 @@ static void intel_power_well_enable(struct drm_i915_private
*dev_priv,
static void intel_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- DRM_DEBUG_KMS("disabling %s\n", power_well->desc->name);
+ DBG("disabling %s\n", power_well->desc->name);
power_well->hw_enabled = false;
power_well->desc->ops->disable(dev_priv, power_well);
}
@@ -289,8 +295,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
- DRM_DEBUG_KMS("%s power well enable timeout\n",
- power_well->desc->name);
+ DBG("%s power well enable timeout\n", power_well->desc->name);
/* An AUX timeout is expected if the TBT DP tunnel is down. */
WARN_ON(!power_well->desc->hsw.is_tc_tbt);
@@ -336,9 +341,9 @@ static void hsw_wait_for_power_well_disable(struct
drm_i915_private *dev_priv,
if (disabled)
return;
- DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
- power_well->desc->name,
- !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
+ DBG("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
+ power_well->desc->name,
+ !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
}
static void gen9_wait_for_power_well_fuses(struct drm_i915_private *dev_priv,
@@ -681,8 +686,7 @@ static void gen9_write_dc_state(struct drm_i915_private
*dev_priv,
/* Most of the times we need one retry, avoid spam */
if (rewrites > 1)
- DRM_DEBUG_KMS("Rewrote dc state to 0x%x %d times\n",
- state, rewrites);
+ DBG("Rewrote dc state to 0x%x %d times\n", state, rewrites);
}
static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
@@ -710,8 +714,8 @@ static void gen9_sanitize_dc_state(struct drm_i915_private
*dev_priv)
val = I915_READ(DC_STATE_EN) & gen9_dc_mask(dev_priv);
- DRM_DEBUG_KMS("Resetting DC state tracking from %02x to %02x\n",
- dev_priv->csr.dc_state, val);
+ DBG("Resetting DC state tracking from %02x to %02x\n",
+ dev_priv->csr.dc_state, val);
dev_priv->csr.dc_state = val;
}
@@ -748,8 +752,7 @@ static void gen9_set_d
[Intel-gfx] [PATCH 4/8] drm/i915/gt: Eliminate the trylock for reading a timeline's hwsp
As we stash a pointer to the HWSP cacheline on the request, when reading
it we only need confirm that the cacheline is still valid by checking
that the request and timeline are still intact.
v2: Protect hwsp_cachline with RCU
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 64 +++
.../gpu/drm/i915/gt/intel_timeline_types.h| 12 +++-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_request.h | 5 +-
4 files changed, 39 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index d71aafb66d6e..ee5dc4fbdeb9 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -15,6 +15,9 @@
#define ptr_set_bit(ptr, bit) ((typeof(ptr))((unsigned long)(ptr) | BIT(bit)))
#define ptr_test_bit(ptr, bit) ((unsigned long)(ptr) & BIT(bit))
+#define CACHELINE_BITS 6
+#define CACHELINE_FREE CACHELINE_BITS
+
struct intel_timeline_hwsp {
struct intel_gt *gt;
struct intel_gt_timelines *gt_timelines;
@@ -23,14 +26,6 @@ struct intel_timeline_hwsp {
u64 free_bitmap;
};
-struct intel_timeline_cacheline {
- struct i915_active active;
- struct intel_timeline_hwsp *hwsp;
- void *vaddr;
-#define CACHELINE_BITS 6
-#define CACHELINE_FREE CACHELINE_BITS
-};
-
static struct i915_vma *__hwsp_alloc(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -133,7 +128,7 @@ static void __idle_cacheline_free(struct
intel_timeline_cacheline *cl)
__idle_hwsp_free(cl->hwsp, ptr_unmask_bits(cl->vaddr, CACHELINE_BITS));
i915_active_fini(&cl->active);
- kfree(cl);
+ kfree_rcu(cl, rcu);
}
__i915_active_call
@@ -514,46 +509,35 @@ int intel_timeline_read_hwsp(struct i915_request *from,
struct i915_request *to,
u32 *hwsp)
{
- struct intel_timeline *tl;
+ struct intel_timeline_cacheline *cl;
int err;
+ GEM_BUG_ON(!rcu_access_pointer(from->hwsp_cacheline));
+
rcu_read_lock();
- tl = rcu_dereference(from->timeline);
- if (i915_request_completed(from) || !kref_get_unless_zero(&tl->kref))
- tl = NULL;
+ cl = rcu_dereference(from->hwsp_cacheline);
+ if (unlikely(!i915_active_acquire_if_busy(&cl->active)))
+ goto unlock; /* seqno wrapped and completed! */
+ if (unlikely(i915_request_completed(from)))
+ goto release;
rcu_read_unlock();
- if (!tl) /* already completed */
- return 1;
- GEM_BUG_ON(rcu_access_pointer(to->timeline) == tl);
-
- err = -EAGAIN;
- if (mutex_trylock(&tl->mutex)) {
- struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
-
- if (i915_request_completed(from)) {
- err = 1;
- goto unlock;
- }
+ err = cacheline_ref(cl, to);
+ if (err)
+ goto out;
- err = cacheline_ref(cl, to);
- if (err)
- goto unlock;
+ *hwsp = i915_ggtt_offset(cl->hwsp->vma) +
+ ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) * CACHELINE_BYTES;
- if (likely(cl == tl->hwsp_cacheline)) {
- *hwsp = tl->hwsp_offset;
- } else { /* across a seqno wrap, recover the original offset */
- *hwsp = i915_ggtt_offset(cl->hwsp->vma) +
- ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) *
- CACHELINE_BYTES;
- }
+out:
+ i915_active_release(&cl->active);
+ return err;
+release:
+ i915_active_release(&cl->active);
unlock:
- mutex_unlock(&tl->mutex);
- }
- intel_timeline_put(tl);
-
- return err;
+ rcu_read_unlock();
+ return 1;
}
void intel_timeline_unpin(struct intel_timeline *tl)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
index aaf15cbe1ce1..24d040f14e89 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
@@ -10,14 +10,15 @@
#include
#include
#include
+#include
#include
#include "i915_active_types.h"
struct drm_i915_private;
struct i915_vma;
-struct intel_timeline_cacheline;
struct i915_syncmap;
+struct intel_timeline_hwsp;
struct intel_timeline {
u64 fence_context;
@@ -87,4 +88,13 @@ struct intel_timeline {
struct rcu_head rcu;
};
+struct intel_timeline_cacheline {
+ struct i915_active active;
+
+ struct intel_timeline_hwsp *hwsp;
+ void *vaddr;
+
+ struct rcu_head rcu;
+};
+
#endif /* __I915_TIMELINE_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/
[Intel-gfx] [PATCH 8/8] drm/i915: Tweak scheduler's kick_submission()
Skip useless priority bumping on adding a new dependency, but otherwise
prevent tasklet scheduling until we have completed all the potential
rescheduling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 2bc2aa46a1b9..00f5d107f2b7 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -216,12 +216,13 @@ static void kick_submission(struct intel_engine_cs
*engine,
if (inflight->hw_context == rq->hw_context)
goto unlock;
- engine->execlists.queue_priority_hint = prio;
if (need_preempt(prio, rq_prio(inflight)))
tasklet_hi_schedule(&engine->execlists.tasklet);
unlock:
rcu_read_unlock();
+
+ engine->execlists.queue_priority_hint = prio;
}
static void __i915_schedule(struct i915_sched_node *node,
@@ -365,6 +366,9 @@ static void __bump_priority(struct i915_sched_node *node,
unsigned int bump)
{
struct i915_sched_attr attr = node->attr;
+ if (attr.priority & bump)
+ return;
+
attr.priority |= bump;
__i915_schedule(node, &attr);
}
@@ -463,11 +467,15 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
if (!dep)
return -ENOMEM;
+ local_bh_disable();
+
if (!__i915_sched_node_add_dependency(node, signal, dep,
I915_DEPENDENCY_EXTERNAL |
I915_DEPENDENCY_ALLOC))
i915_dependency_free(dep);
+ local_bh_enable(); /* kick submission tasklet */
+
return 0;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/gt: Remove direct invocation of breadcrumb signaling
Only signal the breadcrumbs from inside the irq_work, simplifying our
interface and calling conventions. The micro-optimisation here is that
by always using the irq_work interface, we know we are always inside an
irq-off critical section for the breadcrumb signaling and can ellide
save/restore of the irq flags.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 27 +++
drivers/gpu/drm/i915/gt/intel_engine.h| 4 +--
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 12 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 4 +--
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 +++---
drivers/gpu/drm/i915/i915_request.c | 2 +-
10 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 8a9facf4f3b6..5fa4d621528e 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -130,16 +130,15 @@ __dma_fence_signal__notify(struct dma_fence *fence,
}
}
-void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine)
+static void signal_irq_work(struct irq_work *work)
{
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- unsigned long flags;
LIST_HEAD(signal);
- spin_lock_irqsave(&b->irq_lock, flags);
+ spin_lock(&b->irq_lock);
if (b->irq_armed && list_empty(&b->signalers))
__intel_breadcrumbs_disarm_irq(b);
@@ -185,31 +184,23 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
}
}
- spin_unlock_irqrestore(&b->irq_lock, flags);
+ spin_unlock(&b->irq_lock);
list_for_each_safe(pos, next, &signal) {
struct i915_request *rq =
list_entry(pos, typeof(*rq), signal_link);
struct list_head cb_list;
- spin_lock_irqsave(&rq->lock, flags);
+ spin_lock(&rq->lock);
list_replace(&rq->fence.cb_list, &cb_list);
__dma_fence_signal__timestamp(&rq->fence, timestamp);
__dma_fence_signal__notify(&rq->fence, &cb_list);
- spin_unlock_irqrestore(&rq->lock, flags);
+ spin_unlock(&rq->lock);
i915_request_put(rq);
}
}
-static void signal_irq_work(struct irq_work *work)
-{
- struct intel_engine_cs *engine =
- container_of(work, typeof(*engine), breadcrumbs.irq_work);
-
- intel_engine_breadcrumbs_irq(engine);
-}
-
static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
struct intel_engine_cs *engine =
@@ -290,9 +281,9 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
/*
* We keep the seqno in retirement order, so we can break
-* inside intel_engine_breadcrumbs_irq as soon as we've passed
-* the last completed request (or seen a request that hasn't
-* event started). We could iterate the timeline->requests list,
+* inside intel_engine_signal_breadcrumbs as soon as we've
+* passed the last completed request (or seen a request that
+* hasn't event started). We could walk the timeline->requests,
* but keeping a separate signalers_list has the advantage of
* hopefully being much smaller than the full list and so
* provides faster iteration and detection when there are no
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0926ecea9147..b21c20ee9e23 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -213,13 +213,11 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
-intel_engine_queue_breadcrumbs(struct intel_engine_cs *engine)
+intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
{
irq_work_queue(&engine->breadcrumbs.irq_work);
}
-void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine);
-
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 332b12a574fb..f796bdf1ed30 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Avoid multi-LRI on Sandybridge
== Series Details ==
Series: drm/i915/gt: Avoid multi-LRI on Sandybridge
URL : https://patchwork.freedesktop.org/series/71029/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7578 -> Patchwork_15808
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/index.html
Known issues
Here are the changes found in Patchwork_15808 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [TIMEOUT][2] ([i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
Possible fixes
* igt@gem_exec_parallel@basic:
- {fi-tgl-u}: [INCOMPLETE][3] ([i915#476]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-tgl-u/igt@gem_exec_paral...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-tgl-u/igt@gem_exec_paral...@basic.html
* igt@i915_selftest@live_blt:
- fi-ivb-3770:[DMESG-FAIL][5] ([i915#725]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-ivb-3770/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-ivb-3770/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [DMESG-FAIL][7] ([i915#730]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2: [INCOMPLETE][9] ([i915#140]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#109635] / [i915#217]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111096] / [i915#323]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [DMESG-FAIL][17] ([i915#722]) -> [DMESG-FAIL][18]
([i915#830])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#62] / [i915#92]) +11 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#476]: https://gitlab.freedesktop.org/drm/intel/issues/476
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722
[i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
[i915#730]: https://gitlab.freedesktop.org/drm/intel/issues/730
[i915#816]: https://gitlab.freedesktop.org/drm/inte
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: Control panel and backlight enable GPIOs from VBT (rev2)
== Series Details == Series: drm/i915/dsi: Control panel and backlight enable GPIOs from VBT (rev2) URL : https://patchwork.freedesktop.org/series/70945/ State : success == Summary == CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15801_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15801_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html - shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_persistence@vcs1-cleanup: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_ctx_persiste...@vcs1-cleanup.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-iclb8/igt@gem_ctx_persiste...@vcs1-cleanup.html * igt@gem_ctx_persistence@vcs1-mixed-process: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#679]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_ctx_persiste...@vcs1-mixed-process.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb5/igt@gem_ctx_persiste...@vcs1-mixed-process.html * igt@gem_exec_basic@readonly-vcs1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_ba...@readonly-vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-iclb8/igt@gem_exec_ba...@readonly-vcs1.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-iclb8/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_suspend@basic-s0: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#472]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb8/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb6/igt@gem_exec_susp...@basic-s0.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-tglb: [PASS][15] -> [TIMEOUT][16] ([fdo#112126] / [i915#530]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb7/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb3/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-glk3/igt@gem_pp...@flink-and-close-vma-leak.html - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-kbl6/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_sync@basic-store-each: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#435] / [i915#472]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb8/igt@gem_s...@basic-store-each.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb6/igt@gem_s...@basic-store-each.html * igt@i915_pm_backlight@fade_with_suspend: - shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([i915#456] / [i915#460]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb4/igt@i915_pm_backlight@fade_with_suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15801/shard-tglb7/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-apl3/igt@i915_susp...@sysfs-reader.html
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/8] drm/i915: Unpin vma->obj on early error
== Series Details ==
Series: series starting with [1/8] drm/i915: Unpin vma->obj on early error
URL : https://patchwork.freedesktop.org/series/71031/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7578 -> Patchwork_15809
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15809 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15809, 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_15809/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_15809:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_execlists:
- fi-kbl-guc: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-guc/igt@i915_selftest@live_execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-kbl-guc/igt@i915_selftest@live_execlists.html
- fi-bxt-dsi: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-bxt-dsi/igt@i915_selftest@live_execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-bxt-dsi/igt@i915_selftest@live_execlists.html
- fi-skl-lmem:[PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-skl-lmem/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-skl-lmem/igt@i915_selftest@live_execlists.html
Known issues
Here are the changes found in Patchwork_15809 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [PASS][7] -> [DMESG-FAIL][8] ([i915#770])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-hsw-4770r/igt@i915_selftest@live_blt.html
Possible fixes
* igt@gem_exec_parallel@basic:
- {fi-tgl-u}: [INCOMPLETE][9] ([i915#476]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-tgl-u/igt@gem_exec_paral...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-tgl-u/igt@gem_exec_paral...@basic.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][11] ([i915#553] / [i915#725]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-4770/igt@i915_selftest@live_blt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-hsw-4770/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [DMESG-FAIL][13] ([i915#722]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
- fi-cfl-guc: [DMESG-FAIL][15] ([i915#730]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2: [INCOMPLETE][17] ([i915#140]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][19] ([fdo#109635] / [i915#217]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111096] / [i915#323]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15809/
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset
On Mon, Dec 16, 2019 at 02:58:13PM -0800, Manasi Navare wrote:
> On Mon, Dec 16, 2019 at 02:33:10PM -0800, Manasi Navare wrote:
> > On Mon, Dec 16, 2019 at 11:37:38PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 16, 2019 at 11:13:09AM -0800, Manasi Navare wrote:
> > > > On Mon, Dec 16, 2019 at 04:37:38PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Dec 11, 2019 at 01:14:23PM -0800, Manasi Navare wrote:
> > > > > > In case of tiled displays, all the tiles are linke dto each other
> > > > > > for transcoder port sync. So in intel_atomic_check() we need to make
> > > > > > sure that we add all the tiles to the modeset and if one of the
> > > > > > tiles needs a full modeset then mark all other tiles for a full
> > > > > > modeset.
> > > > > >
> > > > > > Suggested-by: Ville Syrjälä
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: José Roberto de Souza
> > > > > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/5
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 78
> > > > > >
> > > > > > 1 file changed, 78 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index 803993a01ca7..7263eaa66cda 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -14066,6 +14066,80 @@ static int intel_atomic_check_crtcs(struct
> > > > > > intel_atomic_state *state)
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static int
> > > > > > +intel_dp_modeset_all_tiles(struct drm_i915_private *dev_priv,
> > > > > > + struct intel_atomic_state *state, int
> > > > > > tile_grp_id)
> > > > > > +{
> > > > > > + struct drm_connector *conn_iter;
> > > > > > + struct drm_connector_list_iter conn_list_iter;
> > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > +
> > > > > > + drm_connector_list_iter_begin(&dev_priv->drm, &conn_list_iter);
> > > > > > + drm_for_each_connector_iter(conn_iter, &conn_list_iter) {
> > > > > > + struct drm_connector_state *conn_iter_state;
> > > > > > +
> > > > > > + if (!conn_iter->has_tile)
> > > > > > + continue;
> > > > > > + conn_iter_state =
> > > > > > drm_atomic_get_connector_state(&state->base,
> > > > > > +
> > > > > > conn_iter);
> > > > > > + if (IS_ERR(conn_iter_state)) {
> > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > + return PTR_ERR(conn_iter_state);
> > > > > > + }
> > > > > > +
> > > > > > + if (!conn_iter_state->crtc)
> > > > > > + continue;
> > > > > > +
> > > > > > + if (conn_iter->tile_group->id != tile_grp_id)
> > > > > > + continue;
> > > > > > +
> > > > > > + crtc_state = drm_atomic_get_crtc_state(&state->base,
> > > > > > conn_iter_state->crtc);
> > > > > > + if (IS_ERR(crtc_state)) {
> > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > + return PTR_ERR(conn_iter_state);
> > > > > > + }
> > > > > > + crtc_state->mode_changed = true;
> > > > > > + }
> > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static int
> > > > > > +intel_dp_atomic_trans_port_sync_check(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > + struct intel_atomic_state *state)
> > > > > > +{
> > > > > > + struct drm_connector *connector;
> > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > + struct drm_connector_state *connector_state;
> > > > > > + int i, ret, tile_grp_id = 0;
> > > > > > +
> > > > > > + if (INTEL_GEN(dev_priv) < 11)
> > > > > > + return 0;
> > > > > > +
> > > > > > + /* Is tiled, mark all other tiled CRTCs as needing a modeset */
> > > > > > + for_each_new_connector_in_state(&state->base, connector,
> > > > > > connector_state, i) {
> > > > > > + if (!connector->has_tile)
> > > > > > + continue;
> > > > > > + if (connector_state->crtc &&
> > > > > > + tile_grp_id != connector->tile_group->id) {
> > > > > > + crtc_state =
> > > > > > drm_atomic_get_new_crtc_state(&state->base,
> > > > > > +
> > > > > > connector_state->crtc);
> > > > > > + if (!drm_atomic_crtc_needs_modeset(crtc_state))
> > > > > > + continue;
> > > > > > +
> > > > > > + tile_grp_id = connector->tile_group->id;
> > > > > > + } else
> > > > > > + contin
Re: [Intel-gfx] [CI 0/3] drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
On Mon, 16 Dec 2019, Hans de Goede wrote: > Hi All, > > Somehow the CI system did not pick up this series the first time, there > are no test results recorded for it: > https://patchwork.freedesktop.org/series/69685 > > So this is a resend for CI to do its thing. As soon as CI is happy with > this I will push this to drm-intel-next-queued. Thanks, please go ahead. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915/perf: open access for CAP_SYS_PERFMON privileged process
On 17.12.2019 12:45, Lionel Landwerlin wrote: > On 16/12/2019 22:03, Alexey Budankov wrote: >> Open access to i915_perf monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to i915_perf subsystem remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> i915_perf monitoring is discouraged with respect to CAP_SYS_PERFMON >> capability. >> >> Signed-off-by: Alexey Budankov > > > Assuming people are fine with this new cap, I like this idea of a lighter > privilege for i915-perf. Lionel, thanks for your meaningful input! Appreciate your collaboration. Regards, Alexey > > > -Lionel > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev3)
== Series Details == Series: series starting with [1/5] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev3) URL : https://patchwork.freedesktop.org/series/69129/ State : success == Summary == CI Bug Log - changes from CI_DRM_7578 -> Patchwork_15797 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/index.html Known issues Here are the changes found in Patchwork_15797 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_blt: - fi-byt-j1900: [PASS][1] -> [DMESG-FAIL][2] ([i915#725]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-byt-j1900/igt@i915_selftest@live_blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-byt-j1900/igt@i915_selftest@live_blt.html - fi-hsw-4770r: [PASS][3] -> [DMESG-FAIL][4] ([i915#553] / [i915#725]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-4770r/igt@i915_selftest@live_blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-hsw-4770r/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_execlists: - fi-whl-u: [PASS][5] -> [DMESG-FAIL][6] ([i915#841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-whl-u/igt@i915_selftest@live_execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-whl-u/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_gem_contexts: - fi-cfl-8700k: [PASS][7] -> [INCOMPLETE][8] ([i915#424]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html - fi-hsw-peppy: [PASS][9] -> [INCOMPLETE][10] ([i915#694]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-icl-u2: [FAIL][11] ([fdo#103375]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-icl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_suspend@basic-s4-devices: - fi-icl-u2: [FAIL][13] ([fdo#111550]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-icl-u2/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_blt: - fi-ivb-3770:[DMESG-FAIL][15] ([i915#725]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-ivb-3770/igt@i915_selftest@live_blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-ivb-3770/igt@i915_selftest@live_blt.html - fi-hsw-4770:[DMESG-FAIL][17] ([i915#553] / [i915#725]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-hsw-4770/igt@i915_selftest@live_blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-hsw-4770/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_gem_contexts: - fi-cfl-guc: [DMESG-FAIL][19] ([i915#730]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html * igt@kms_busy@basic-flip-pipe-a: - fi-icl-u2: [INCOMPLETE][21] ([i915#140]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][23] ([fdo#109635] / [i915#217]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live_g
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Add selftest for memory region PF handling
Instead of testing individually our new fault handlers, iterate over all
memory regions and test all from one interface.
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 226 --
1 file changed, 153 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 591435c5f368..e98ec15e7c51 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -9,6 +9,8 @@
#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
+#include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_region.h"
#include "huge_gem_object.h"
#include "i915_selftest.h"
#include "selftests/i915_random.h"
@@ -725,44 +727,94 @@ static int igt_mmap_offset_exhaustion(void *arg)
goto out;
}
+typedef int (*obj_set_fn_t)(struct drm_i915_gem_object *obj, bool init);
+
+static int gtt_obj_set(struct drm_i915_gem_object *obj, bool init)
+{
+ u32 __iomem *map;
+ struct i915_vma *vma;
+ int err = 0;
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_gtt_domain(obj, true);
+ i915_gem_object_unlock(obj);
+ if (err)
+ return err;
+
+ vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ intel_gt_pm_get(vma->vm->gt);
+ map = i915_vma_pin_iomap(vma);
+ i915_vma_unpin(vma);
+ if (IS_ERR(map)) {
+ err = PTR_ERR(map);
+ goto out;
+ }
+
+ if (init) {
+ memset_io(map, POISON_INUSE, PAGE_SIZE);
+ i915_gem_object_flush_map(obj);
+ } else {
+ if (memchr_inv(map, POISON_FREE, PAGE_SIZE)) {
+ pr_err("Write via mmap did not land in backing
store\n");
+ err = -EINVAL;
+ }
+ }
+ i915_vma_unpin_iomap(vma);
+
+out:
+ intel_gt_pm_put(vma->vm->gt);
+ return err;
+}
+
+static int cpu_obj_set(struct drm_i915_gem_object *obj, bool init)
+{
+ int err = 0;
+ void *vaddr = i915_gem_object_pin_map(obj, i915_gem_object_is_lmem(obj)
?
+ I915_MAP_WC : I915_MAP_WB);
+ if (IS_ERR(vaddr))
+ return PTR_ERR(vaddr);
+
+ if (init) {
+ memset(vaddr, POISON_INUSE, PAGE_SIZE);
+ i915_gem_object_flush_map(obj);
+ } else {
+ if (memchr_inv(vaddr, POISON_FREE, PAGE_SIZE)) {
+ pr_err("Write via mmap did not land in backing
store\n");
+ err = -EINVAL;
+ }
+ }
+ i915_gem_object_unpin_map(obj);
+
+ return err;
+}
+
#define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24))
-static int igt_mmap(void *arg, enum i915_mmap_type type)
+static int igt_mmap(struct drm_i915_private *i915, struct drm_i915_gem_object
*obj,
+ enum i915_mmap_type type, obj_set_fn_t obj_set_fn)
{
- struct drm_i915_private *i915 = arg;
- struct drm_i915_gem_object *obj;
struct i915_mmap_offset *mmo;
struct vm_area_struct *area;
unsigned long addr;
- void *vaddr;
- int err = 0, i;
+ int err = 0, out_err = 0, i;
- if (!i915_ggtt_has_aperture(&i915->ggtt))
+ if (!i915_ggtt_has_aperture(&i915->ggtt) &&
+ type == I915_MMAP_TYPE_GTT)
return 0;
- obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(vaddr)) {
- err = PTR_ERR(vaddr);
- goto out;
- }
- memset(vaddr, POISON_INUSE, PAGE_SIZE);
- i915_gem_object_flush_map(obj);
- i915_gem_object_unpin_map(obj);
+ err = obj_set_fn(obj, true);
+ if (err)
+ return err;
mmo = mmap_offset_attach(obj, type, NULL);
- if (IS_ERR(mmo)) {
- err = PTR_ERR(mmo);
- goto out;
- }
+ if (IS_ERR(mmo))
+ return PTR_ERR(mmo);
addr = igt_mmap_node(i915, &mmo->vma_node, 0, PROT_WRITE, MAP_SHARED);
- if (IS_ERR_VALUE(addr)) {
- err = addr;
- goto out;
- }
+ if (IS_ERR_VALUE(addr))
+ return addr;
pr_debug("igt_mmap() @ %lx\n", addr);
@@ -808,31 +860,46 @@ static int igt_mmap(void *arg, enum i915_mmap_type type)
out_unmap:
vm_munmap(addr, PAGE_SIZE);
+ out_err = obj_set_fn(obj, false);
+ if (out_err)
+ err = out_err;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_FORCE_WC);
- if (IS_ERR(vaddr)) {
- err = PTR_ER
[Intel-gfx] [PATCH 1/2] drm/i915: Add lmem fault handler
Fault handler to handle missing pages for lmem objects.
v4: Restore non-contigous fault handling in addition to remap_io_mapping
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 13 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 ++
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 71 ++--
3 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 520cc9cac471..e8326d8b66f7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -6,6 +6,7 @@
#include "intel_memory_region.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
#include "i915_drv.h"
const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
@@ -56,6 +57,18 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
}
+unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ struct intel_memory_region *mem = obj->mm.region;
+ resource_size_t offset;
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+ offset -= mem->region.start;
+
+ return (mem->io_start + offset) >> PAGE_SHIFT;
+}
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
return obj->ops == &i915_gem_lmem_obj_ops;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index 7c176b8b7d2f..4d5fca1a3e0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -7,6 +7,7 @@
#define __I915_GEM_LMEM_H
#include
+#include
struct drm_i915_private;
struct drm_i915_gem_object;
@@ -22,6 +23,9 @@ void __iomem *
i915_gem_object_lmem_io_map_page_atomic(struct drm_i915_gem_object *obj,
unsigned long n);
+unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
+ unsigned long n);
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 879fff8adc48..f5f7af745d1d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -11,6 +11,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_gt_requests.h"
+#include "i915_gem_lmem.h"
#include "i915_drv.h"
#include "i915_gem_gtt.h"
#include "i915_gem_ioctls.h"
@@ -216,6 +217,7 @@ static vm_fault_t i915_error_to_vmf_fault(int err)
case -ENOSPC: /* shmemfs allocation failure */
case -ENOMEM: /* our allocation failure */
+ case -ENXIO:
return VM_FAULT_OOM;
case 0:
@@ -274,6 +276,47 @@ static vm_fault_t vm_fault_cpu(struct vm_fault *vmf)
return ret;
}
+vm_fault_t vm_fault_iomem(struct vm_fault *vmf)
+{
+ struct vm_area_struct *area = vmf->vma;
+ struct i915_mmap_offset *priv = area->vm_private_data;
+ struct drm_i915_gem_object *obj = priv->obj;
+ struct intel_memory_region *mem = obj->mm.region;
+ unsigned long i, size = area->vm_end - area->vm_start;
+ bool write = area->vm_flags & VM_WRITE;
+ int ret;
+
+ /* Sanity check that we allow writing into this object */
+ if (i915_gem_object_is_readonly(obj) && write)
+ return VM_FAULT_SIGBUS;
+
+ ret = i915_gem_object_pin_pages(obj);
+ if (ret)
+ return i915_error_to_vmf_fault(ret);
+
+ if (obj->flags & I915_BO_ALLOC_CONTIGUOUS) {
+ ret = remap_io_mapping(area, area->vm_start,
+ i915_gem_object_lmem_io_pfn(obj, 0),
size,
+ &mem->iomap);
+ i915_gem_object_unpin_pages(obj);
+ return i915_error_to_vmf_fault(ret);
+ } else {
+ vm_fault_t vmf_ret = VM_FAULT_SIGBUS;
+ if (GEM_WARN_ON(size < PAGE_SIZE))
+ return vmf_ret;
+
+ for (i = 0; i < size >> PAGE_SHIFT; i++) {
+ vmf_ret = vmf_insert_pfn(area,
+(unsigned long)area->vm_start
+ i * PAGE_SIZE,
+
i915_gem_object_lmem_io_pfn(obj, i));
+ if (vmf_ret != VM_FAULT_NOPAGE)
+ break;
+ }
+ i915_gem_object_unpin_pages(obj);
+ return vmf_ret;
+ }
+}
+
static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
{
#define MIN_CHUNK_PAGES (SZ_1M >> PAGE_SHIFT)
@@ -560,7 +603,8 @@ __assign_mmap_offset(struct drm_file *fi
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On 17/12/2019 06:37, Randy Dunlap wrote:
> On 12/16/19 9:42 PM, Sam Ravnborg wrote:
>> Hi Randy.
>>
>> On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
>>> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
Hi all,
Changes since 20191213:
>>>
>>> on x86_64:
>>>
>>> ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight':
>>> (.text+0x2ee): undefined reference to `devm_of_find_backlight'
>>>
>>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>>> `intel_backlight_device_register':
>>> intel_panel.c:(.text+0x593e): undefined reference to
>>> `backlight_device_register'
>>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>>> `intel_backlight_device_unregister':
>>> intel_panel.c:(.text+0x5a04): undefined reference to
>>> `backlight_device_unregister'
>>>
>>> CONFIG_DRM_PANEL=y
>>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
>>> CONFIG_DRM_I915=y
>>>
>>> Full randconfig file is attached.
>>
>> Can you please verify if you have:
>> 907aa265fde6589b8059dc51649c6d1f49ade2f3
>> ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
>>
>> This commit is supposed to fix it.
>>
>> Sam
>>
>
> Hi Sam,
> I don't have the linux-next.git tree so I can't check that.
> I just built whatever is in linux-next of 20191216.
>
907aa265fde6589b8059dc51649c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
error above is for backlight_device_register().
>From what I can tell, that commit is actually the cause of the error -
now intel_backlight_device_register() is being included in the kernel
even though it calls backlight_device_register() which is in a module.
Of course it also fixed the original error, so reverting it isn't any
use.
The below Kconfig change fixes the build for me, but I've no idea
whether this is the correct fix.
Steve
8<-
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index ba9595960bbe..6b69dab683ae 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -16,7 +16,7 @@ config DRM_I915
select IRQ_WORK
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_CLASS_DEVICE if ACPI
+ select BACKLIGHT_CLASS_DEVICE
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add lmem fault handler
Quoting Abdiel Janulgue (2019-12-17 11:57:49)
> Fault handler to handle missing pages for lmem objects.
>
> v4: Restore non-contigous fault handling in addition to remap_io_mapping
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 13 +
> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 ++
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 71 ++--
> 3 files changed, 84 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index 520cc9cac471..e8326d8b66f7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -6,6 +6,7 @@
> #include "intel_memory_region.h"
> #include "gem/i915_gem_region.h"
> #include "gem/i915_gem_lmem.h"
> +#include "gem/i915_gem_mman.h"
> #include "i915_drv.h"
>
> const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
> @@ -56,6 +57,18 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object
> *obj,
> return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
> }
>
> +unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
> + unsigned long n)
> +{
> + struct intel_memory_region *mem = obj->mm.region;
> + resource_size_t offset;
> +
> + offset = i915_gem_object_get_dma_address(obj, n);
> + offset -= mem->region.start;
> +
> + return (mem->io_start + offset) >> PAGE_SHIFT;
> +}
> +
> bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
> {
> return obj->ops == &i915_gem_lmem_obj_ops;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> index 7c176b8b7d2f..4d5fca1a3e0e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> @@ -7,6 +7,7 @@
> #define __I915_GEM_LMEM_H
>
> #include
> +#include
>
> struct drm_i915_private;
> struct drm_i915_gem_object;
> @@ -22,6 +23,9 @@ void __iomem *
> i915_gem_object_lmem_io_map_page_atomic(struct drm_i915_gem_object *obj,
> unsigned long n);
>
> +unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
> + unsigned long n);
> +
> bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
>
> struct drm_i915_gem_object *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 879fff8adc48..f5f7af745d1d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -11,6 +11,7 @@
> #include "gt/intel_gt.h"
> #include "gt/intel_gt_requests.h"
>
> +#include "i915_gem_lmem.h"
> #include "i915_drv.h"
> #include "i915_gem_gtt.h"
> #include "i915_gem_ioctls.h"
> @@ -216,6 +217,7 @@ static vm_fault_t i915_error_to_vmf_fault(int err)
>
> case -ENOSPC: /* shmemfs allocation failure */
> case -ENOMEM: /* our allocation failure */
> + case -ENXIO:
> return VM_FAULT_OOM;
>
> case 0:
> @@ -274,6 +276,47 @@ static vm_fault_t vm_fault_cpu(struct vm_fault *vmf)
> return ret;
> }
>
> +vm_fault_t vm_fault_iomem(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *area = vmf->vma;
> + struct i915_mmap_offset *priv = area->vm_private_data;
> + struct drm_i915_gem_object *obj = priv->obj;
> + struct intel_memory_region *mem = obj->mm.region;
> + unsigned long i, size = area->vm_end - area->vm_start;
> + bool write = area->vm_flags & VM_WRITE;
> + int ret;
> +
> + /* Sanity check that we allow writing into this object */
> + if (i915_gem_object_is_readonly(obj) && write)
> + return VM_FAULT_SIGBUS;
> +
> + ret = i915_gem_object_pin_pages(obj);
> + if (ret)
> + return i915_error_to_vmf_fault(ret);
> +
> + if (obj->flags & I915_BO_ALLOC_CONTIGUOUS) {
> + ret = remap_io_mapping(area, area->vm_start,
> + i915_gem_object_lmem_io_pfn(obj, 0),
> size,
> + &mem->iomap);
> + i915_gem_object_unpin_pages(obj);
> + return i915_error_to_vmf_fault(ret);
> + } else {
> + vm_fault_t vmf_ret = VM_FAULT_SIGBUS;
> + if (GEM_WARN_ON(size < PAGE_SIZE))
> + return vmf_ret;
> +
> + for (i = 0; i < size >> PAGE_SHIFT; i++) {
> + vmf_ret = vmf_insert_pfn(area,
> +(unsigned
> long)area->vm_start + i * PAGE_SIZE,
> +
> i915_gem_object_lmem_io_pfn(obj, i));
Sigh.
-Chris
___
Int
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add lmem fault handler
On 17/12/2019 14.14, Chris Wilson wrote:
> Quoting Abdiel Janulgue (2019-12-17 11:57:49)
>> Fault handler to handle missing pages for lmem objects.
>>
>> v4: Restore non-contigous fault handling in addition to remap_io_mapping
>>
>> Signed-off-by: Abdiel Janulgue
>> Signed-off-by: Matthew Auld
>> Cc: Chris Wilson
>> Cc: Joonas Lahtinen
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 13 +
>> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 ++
>> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 71 ++--
>> 3 files changed, 84 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
>> index 520cc9cac471..e8326d8b66f7 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
>> @@ -6,6 +6,7 @@
>> #include "intel_memory_region.h"
>> #include "gem/i915_gem_region.h"
>> #include "gem/i915_gem_lmem.h"
>> +#include "gem/i915_gem_mman.h"
>> #include "i915_drv.h"
>>
>> const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
>> @@ -56,6 +57,18 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object
>> *obj,
>> return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
>> }
>>
>> +unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
>> + unsigned long n)
>> +{
>> + struct intel_memory_region *mem = obj->mm.region;
>> + resource_size_t offset;
>> +
>> + offset = i915_gem_object_get_dma_address(obj, n);
>> + offset -= mem->region.start;
>> +
>> + return (mem->io_start + offset) >> PAGE_SHIFT;
>> +}
>> +
>> bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
>> {
>> return obj->ops == &i915_gem_lmem_obj_ops;
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
>> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
>> index 7c176b8b7d2f..4d5fca1a3e0e 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
>> @@ -7,6 +7,7 @@
>> #define __I915_GEM_LMEM_H
>>
>> #include
>> +#include
>>
>> struct drm_i915_private;
>> struct drm_i915_gem_object;
>> @@ -22,6 +23,9 @@ void __iomem *
>> i915_gem_object_lmem_io_map_page_atomic(struct drm_i915_gem_object *obj,
>> unsigned long n);
>>
>> +unsigned long i915_gem_object_lmem_io_pfn(struct drm_i915_gem_object *obj,
>> + unsigned long n);
>> +
>> bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
>>
>> struct drm_i915_gem_object *
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> index 879fff8adc48..f5f7af745d1d 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>> @@ -11,6 +11,7 @@
>> #include "gt/intel_gt.h"
>> #include "gt/intel_gt_requests.h"
>>
>> +#include "i915_gem_lmem.h"
>> #include "i915_drv.h"
>> #include "i915_gem_gtt.h"
>> #include "i915_gem_ioctls.h"
>> @@ -216,6 +217,7 @@ static vm_fault_t i915_error_to_vmf_fault(int err)
>>
>> case -ENOSPC: /* shmemfs allocation failure */
>> case -ENOMEM: /* our allocation failure */
>> + case -ENXIO:
>> return VM_FAULT_OOM;
>>
>> case 0:
>> @@ -274,6 +276,47 @@ static vm_fault_t vm_fault_cpu(struct vm_fault *vmf)
>> return ret;
>> }
>>
>> +vm_fault_t vm_fault_iomem(struct vm_fault *vmf)
>> +{
>> + struct vm_area_struct *area = vmf->vma;
>> + struct i915_mmap_offset *priv = area->vm_private_data;
>> + struct drm_i915_gem_object *obj = priv->obj;
>> + struct intel_memory_region *mem = obj->mm.region;
>> + unsigned long i, size = area->vm_end - area->vm_start;
>> + bool write = area->vm_flags & VM_WRITE;
>> + int ret;
>> +
>> + /* Sanity check that we allow writing into this object */
>> + if (i915_gem_object_is_readonly(obj) && write)
>> + return VM_FAULT_SIGBUS;
>> +
>> + ret = i915_gem_object_pin_pages(obj);
>> + if (ret)
>> + return i915_error_to_vmf_fault(ret);
>> +
>> + if (obj->flags & I915_BO_ALLOC_CONTIGUOUS) {
>> + ret = remap_io_mapping(area, area->vm_start,
>> + i915_gem_object_lmem_io_pfn(obj, 0),
>> size,
>> + &mem->iomap);
>> + i915_gem_object_unpin_pages(obj);
>> + return i915_error_to_vmf_fault(ret);
>> + } else {
>> + vm_fault_t vmf_ret = VM_FAULT_SIGBUS;
>> + if (GEM_WARN_ON(size < PAGE_SIZE))
>> + return vmf_ret;
>> +
>> + for (i = 0; i < size >> PAGE_SHIFT; i++) {
>> + vmf_ret = vmf_insert_pfn(area,
>> +(unsigned
>> long)area->vm_start +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Add lmem fault handler
== Series Details ==
Series: series starting with [1/2] drm/i915: Add lmem fault handler
URL : https://patchwork.freedesktop.org/series/71051/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21b92ebb9c01 drm/i915: Add lmem fault handler
-:116: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#116: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:303:
+ return i915_error_to_vmf_fault(ret);
+ } else {
-:118: WARNING:LINE_SPACING: Missing a blank line after declarations
#118: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:305:
+ vm_fault_t vmf_ret = VM_FAULT_SIGBUS;
+ if (GEM_WARN_ON(size < PAGE_SIZE))
-:151: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#151: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:742:
+ .fault = vm_fault_iomem,$
-:152: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#152: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:743:
+ .open = vm_open,$
-:153: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#153: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:744:
+ .close = vm_close,$
total: 0 errors, 5 warnings, 0 checks, 157 lines checked
ded079f2d6fc drm/i915/selftests: Add selftest for memory region PF handling
___
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 [1/2] drm/i915: Add lmem fault handler
== Series Details == Series: series starting with [1/2] drm/i915: Add lmem fault handler URL : https://patchwork.freedesktop.org/series/71051/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Add lmem fault handler - +drivers/gpu/drm/i915/gem/i915_gem_mman.c:279:12: warning: symbol 'vm_fault_iomem' was not declared. Should it be static? Commit: drm/i915/selftests: Add selftest for memory region PF handling +drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:760:32:expected void const *s +drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:760:32:got unsigned int [noderef] [usertype] *[assigned] map +drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c:760:32: warning: incorrect type in argument 1 (different address spaces) ___ 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/gt: Eliminate the trylock for reading a timeline's hwsp (rev3)
== Series Details == Series: drm/i915/gt: Eliminate the trylock for reading a timeline's hwsp (rev3) URL : https://patchwork.freedesktop.org/series/70997/ State : success == Summary == CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15804_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15804_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_persistence@processes: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#570]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb1/igt@gem_ctx_persiste...@processes.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-tglb4/igt@gem_ctx_persiste...@processes.html * igt@gem_ctx_persistence@vcs0-mixed-process: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#679]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb4/igt@gem_ctx_persiste...@vcs0-mixed-process.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-tglb9/igt@gem_ctx_persiste...@vcs0-mixed-process.html * igt@gem_ctx_persistence@vcs1-mixed: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb2/igt@gem_ctx_persiste...@vcs1-mixed.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-iclb3/igt@gem_ctx_persiste...@vcs1-mixed.html * igt@gem_ctx_shared@q-independent-blt: - shard-kbl: [PASS][9] -> [FAIL][10] ([fdo#112118]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-kbl6/igt@gem_ctx_sha...@q-independent-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-kbl7/igt@gem_ctx_sha...@q-independent-blt.html * igt@gem_exec_await@wide-contexts: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111736]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb7/igt@gem_exec_aw...@wide-contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-tglb6/igt@gem_exec_aw...@wide-contexts.html * igt@gem_exec_parallel@fds: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#470]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_exec_paral...@fds.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-tglb3/igt@gem_exec_paral...@fds.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-iclb6/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-blt: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111677]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb2/igt@gem_exec_sched...@preempt-queue-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-tglb6/igt@gem_exec_sched...@preempt-queue-blt.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-iclb: [PASS][21] -> [TIMEOUT][22] ([i915#530]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb2/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-iclb4/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#644]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15804/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html - shard-apl: [PASS][25] -> [FAIL][26] ([i915#644]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-apl8/igt@gem_pp...@flink-an
Re: [Intel-gfx] [PULL] drm-misc-next
On Tue, Dec 17, 2019 at 09:48:53AM +0100, Maarten Lankhorst wrote: > Hey, > > First pull for v5.6! > > Enjoy! > > ~Maarten > > drm-misc-next-2019-12-16: > drm-misc-next for v5.6: > > UAPI Changes: > - Add support for DMA-BUF HEAPS. > > Cross-subsystem Changes: > - mipi dsi definition updates, pulled into drm-intel as well. > - Add lockdep annotations for dma_resv vs mmap_sem and fs_reclaim. > - Remove support for dma-buf kmap/kunmap. > - Constify fb_ops in all fbdev drivers, including drm drivers and drm-core, > and media as well. > > Core Changes: > - Small cleanups to ttm. > - Fix SCDC definition. > - Assorted cleanups to core. > - Add todo to remove load/unload hooks, and use generic fbdev emulation. > - Assorted documentation updates. > - Use blocking ww lock in ttm fault handler. > - Remove drm_fb_helper_fbdev_setup/teardown. > - Warning fixes with W=1 for atomic. > - Use drm_debug_enabled() instead of drm_debug flag testing in various > drivers. > - Fallback to nontiled mode in fbdev emulation when not all tiles are > present. (Later on reverted) > - Various kconfig indentation fixes in core and drivers. > - Fix freeing transactions in dp-mst correctly. > - Sean Paul is steping down as core maintainer. :-( > - Add lockdep annotations for atomic locks vs dma-resv. > - Prevent use-after-free for a bad job in drm_scheduler. > - Fill out all block sizes in the P01x and P210 definitions. > - Avoid division by zero in drm/rect, and fix bounds. > - Add drm/rect selftests. > - Add aspect ratio and alternate clocks for HDMI 4k modes. > - Add todo for drm_framebuffer_funcs and fb_create cleanup. > - Drop DRM_AUTH for prime import/export ioctls. > - Clear DP-MST payload id tables downstream when initializating. > - Fix for DSC throughput definition. > - Add extra FEC definitions. > - Fix fake offset in drm_gem_object_funs.mmap. > - Stop using encoder->bridge in core directly > - Handle bridge chaining slightly better. > - Add backlight support to drm/panel, and use it in many panel drivers. > - Increase max number of y420 modes from 128 to 256, as preparation to add > the new modes. > > Driver Changes: > - Small fixes all over. > - Fix documentation in vkms. > - Fix mmap_sem vs dma_resv in nouveau. > - Small cleanup in komeda. > - Add page flip support in gma500 for psb/cdv. > - Add ddc symlink in the connector sysfs directory for many drivers. > - Add support for analogic an6345, and fix small bugs in it. > - Add atomic modesetting support to ast. > - Fix radeon fault handler VMA race. > - Switch udl to use generic shmem helpers. > - Unconditional vblank handling for mcde. > - Miscellaneous fixes to mcde. > - Tweak debug output from komeda using debugfs. > - Add gamma and color transform support to komeda for DOU-IPS. > - Add support for sony acx424AKP panel. > - Various small cleanups to gma500. > - Use generic fbdev emulation in udl, and replace udl_framebuffer with > generic implementation. > - Add support for Logic PD Type 28 panel. > - Use drm_panel_* wrapper functions in exynos/tegra/msm. > - Add devicetree bindings for generic DSI panels. > - Don't include drm_pci.h directly in many drivers. > - Add support for begin/end_cpu_access in udmabuf. > - Stop using drm_get_pci_dev in gma500 and mga200. > - Fixes to UDL damage handling, and use dma_buf_begin/end_cpu_access. > - Add devfreq thermal support to panfrost. > - Fix hotplug with daisy chained monitors by removing VCPI when disabling > topology manager. > - meson: Add support for OSD1 plane AFBC commit. > - Stop displaying garbage when toggling ast primary plane on/off. > - More cleanups and fixes to UDL. > - Add D32 suport to komeda. > - Remove globle copy of drm_dev in gma500. > - Add support for Boe Himax8279d MIPI-DSI LCD panel. > - Add support for ingenic JZ4770 panel. > - Small null pointer deference fix in ingenic. > - Remove support for the special tfp420 driver, as there is a generic way to > do it. > The following changes since commit fae7d7d5f374eadbb0b5dd31b39162e7176e9c3d: > > Revert "dma-buf: Add dma-buf heaps framework" (2019-10-30 16:41:49 -0400) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-12-16 Pulled, and many thanks for the careful summary. -Daniel > > for you to fetch changes up to 2156873f08c7893811f34177aa923ab1ea486591: > > drm/tilcdc: Remove obsolete bundled tilcdc tfp410 driver (2019-12-16 > 10:45:43 +0200) > > > drm-misc-next for v5.6: > > UAPI Changes: > - Add support for DMA-BUF HEAPS. > > Cross-subsystem Changes: > - mipi dsi definition updates, pulled into drm-intel as well. > - Add lockdep annotations for dma_resv vs mmap_sem and fs_reclaim. > - Remove support for dma-buf kmap/kunmap. > - Constify fb_ops in all fbdev drivers, including drm drivers and drm-core, > and media as well. > > Core Changes: > - Small cleanups to ttm. > - Fix SCDC definition. > -
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add lmem fault handler
== Series Details == Series: series starting with [1/2] drm/i915: Add lmem fault handler URL : https://patchwork.freedesktop.org/series/71051/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7580 -> Patchwork_15810 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15810 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15810, 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_15810/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_15810: ### IGT changes ### Possible regressions * igt@i915_selftest@live_mman: - fi-ilk-650: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-ilk-650/igt@i915_selftest@live_mman.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ilk-650/igt@i915_selftest@live_mman.html - fi-bsw-n3050: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-n3050/igt@i915_selftest@live_mman.html - fi-ivb-3770:[PASS][4] -> [DMESG-FAIL][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-ivb-3770/igt@i915_selftest@live_mman.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ivb-3770/igt@i915_selftest@live_mman.html - fi-hsw-4770r: [PASS][6] -> [DMESG-FAIL][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-hsw-4770r/igt@i915_selftest@live_mman.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-hsw-4770r/igt@i915_selftest@live_mman.html - fi-bsw-kefka: [PASS][8] -> [INCOMPLETE][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bsw-kefka/igt@i915_selftest@live_mman.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-kefka/igt@i915_selftest@live_mman.html - fi-blb-e6850: [PASS][10] -> [INCOMPLETE][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-blb-e6850/igt@i915_selftest@live_mman.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-blb-e6850/igt@i915_selftest@live_mman.html - fi-bwr-2160:[PASS][12] -> [INCOMPLETE][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bwr-2160/igt@i915_selftest@live_mman.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bwr-2160/igt@i915_selftest@live_mman.html - fi-kbl-8809g: [PASS][14] -> [DMESG-FAIL][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-kbl-8809g/igt@i915_selftest@live_mman.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-kbl-8809g/igt@i915_selftest@live_mman.html - fi-bsw-nick:[PASS][16] -> [INCOMPLETE][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bsw-nick/igt@i915_selftest@live_mman.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-nick/igt@i915_selftest@live_mman.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][18] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ilk-650/igt@run...@aborted.html - fi-pnv-d510:NOTRUN -> [FAIL][19] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-pnv-d510/igt@run...@aborted.html - fi-bxt-dsi: NOTRUN -> [FAIL][20] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bxt-dsi/igt@run...@aborted.html - fi-bsw-n3050: NOTRUN -> [FAIL][21] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-n3050/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][22] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-blb-e6850/igt@run...@aborted.html - fi-bsw-kefka: NOTRUN -> [FAIL][23] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-kefka/igt@run...@aborted.html - fi-bsw-nick:NOTRUN -> [FAIL][24] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-nick/igt@run...@aborted.html - fi-elk-e7500: NOTRUN -> [FAIL][25] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-elk-e7500/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_15810 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-tgl-y: [PASS][26] -> [INCOMPLETE][27] ([fdo#111593]) [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-tgl-y/igt@gem_exec_gttf...@basic.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-tgl-y/igt@gem_exec_gttf...@bas
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for linux-next: Tree for Dec 16 (drm_panel & intel_panel)
== Series Details ==
Series: linux-next: Tree for Dec 16 (drm_panel & intel_panel)
URL : https://patchwork.freedesktop.org/series/71052/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f9c2e2f3e3a linux-next: Tree for Dec 16 (drm_panel & intel_panel)
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#22:
>>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>>> `intel_backlight_device_register':
-:34: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 907aa265fde6 ("drm/drm_panel:
fix EXPORT of drm_panel_of_backlight")'
#34:
>> 907aa265fde6589b8059dc51649c6d1f49ade2f3
-:47: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 907aa265fde6 ("drm/drm_panel:
fix EXPORT of drm_panel_of_backlight")'
#47:
907aa265fde6589b8059dc51649c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
-:76: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 3 errors, 1 warnings, 0 checks, 8 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On Mon, Dec 16, 2019 at 12:23:31PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c: In function
> 'anx6345_i2c_probe':
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:30: error: implicit
> declaration of function 'i2c_new_dummy'
> [-Werror=implicit-function-declaration]
> 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> | ^
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:28: warning:
> assignment to 'struct i2c_client *' from 'int' makes pointer from integer
> without a cast [-Wint-conversion]
> 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> |^
>
> Caused by commit
>
> 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
>
> interacting with commit
>
> 2c2f00ab1641 ("i2c: remove i2c_new_dummy() API")
>
> From Linus' tree.
>
> I have applied the following fix up patch for today:
>
> From: Stephen Rothwell
> Date: Mon, 16 Dec 2019 12:11:19 +1100
> Subject: [PATCH] drm/bridge: fix up for removal of i2c_new_dummy()
>
> Signed-off-by: Stephen Rothwell
Thanks pulled into drm-next since I just processed the first drm-misc-next
pull.
-Daniel
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 9917ce0d86a0..56f55c53abfd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -735,13 +735,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
> /* Map slave addresses of ANX6345 */
> for (i = 0; i < I2C_NUM_ADDRESSES; i++) {
> if (anx6345_i2c_addresses[i] >> 1 != client->addr)
> - anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> + anx6345->i2c_clients[i] =
> i2c_new_dummy_device(client->adapter,
> anx6345_i2c_addresses[i] >> 1);
> else
> anx6345->i2c_clients[i] = client;
>
> - if (!anx6345->i2c_clients[i]) {
> - err = -ENOMEM;
> + if (IS_ERR(anx6345->i2c_clients[i])) {
> + err = PTR_ERR(anx6345->i2c_clients[i]);
> DRM_ERROR("Failed to reserve I2C bus %02x\n",
> anx6345_i2c_addresses[i]);
> goto err_unregister_i2c;
> --
> 2.24.0
>
> --
> Cheers,
> Stephen Rothwell
--
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
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Tue, 17 Dec 2019, Lee Jones wrote: > On Mon, 16 Dec 2019, Hans de Goede wrote: > >> Hi, >> >> Doing immutable branches assumes that there is a base point, >> e.g. 5.5-rc1 where the immutable branch can then be based on and >> that the branch can then be merged without issues into both subsystems. >> >> drm is constantly evolving to deal with and mostly catch up with new >> hardware as both GPUs and display-pipelines are evolving quite rapidly >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an >> immutable branch I can either base it on drm-intel-next which >> violates your request for a clean minimal branch to merge; or I can >> base it on 5.5-rc1 which leads to a big chance of problems when >> merging it given to large amount of churn in drm-intel-next. > > This is a *slightly* more compelling reason than the ones you've > previously provided. > >> So instead of the normal case of 2 subsystems seeing some changes >> on both side the case we have here is a part of a file which has >> not changed since 2015-06-26 in one subsys (and changing only >> a single line there!) and OTOH we have bigger changes to a subsys >> which see 400 patches land in the first week since rc1 . > > This is not. > >> I hope that you agree that in this case given the large amount of >> churn in drm-intel-next it makes since to just straight forward >> apply these patches on top of drm-intel-next. > > I have Acked this patch, but remember *this* is the exception rather > than the rule. If/when we have a case where a contributor works > cross-subsystem with DRM and the code/file adapted is live (more > likely to change), I will have to insist on an immutable branch > strategy. DRM will have to deal with that appropriately. Hi, thanks for the ack and reaching an agreement with Hans, and sorry for not responding earlier. It's not unusual for us to have topic branches for cross-subsystem or cross-driver changes, and I think usually we try to be accommodating in merging stuff through whichever tree it makes most sense. In fact my ack to do just that was my first response on this series [1]. So I don't really know why the fuss. We'll anyway deal with any cross-subsystem series on a case by case basis, depending on what makes most sense, and what suits all maintainers involved. Thanks again, Jani. [1] http://mid.mail-archive.com/87pnhnyir8.fsf@intel.com -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/7] drm/i915/guc: Merge communication_stop and communication_disable
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/guc: Merge communication_stop
and communication_disable
URL : https://patchwork.freedesktop.org/series/71020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15805_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_15805_full:
### Piglit changes ###
Possible regressions
* spec@ext_framebuffer_multisample@bitmap 6 (NEW):
- {pig-hsw-4770r}:NOTRUN -> [FAIL][1] +4 similar issues
[1]: None
New tests
-
New tests have been introduced between CI_DRM_7578_full and
Patchwork_15805_full:
### New Piglit tests (5) ###
* spec@arb_gpu_shader5@texturegatheroffset@vs-rg-0-unorm-2darray-const:
- Statuses : 1 fail(s)
- Exec time: [7.36] s
* spec@arb_stencil_texturing@draw:
- Statuses : 1 fail(s)
- Exec time: [0.11] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-float_mat3_array3-position-double_dvec3_array2:
- Statuses : 1 fail(s)
- Exec time: [0.17] s
* spec@ext_framebuffer_multisample@bitmap 6:
- Statuses : 1 fail(s)
- Exec time: [0.23] s
*
spec@glsl-4.10@execution@vs_in@vs-input-uint_uvec4_array3-double_double_array2-position:
- Statuses : 1 fail(s)
- Exec time: [0.23] s
Known issues
Here are the changes found in Patchwork_15805_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vcs1-none:
- shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#109276] / [fdo#112080])
+1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb1/igt@gem_ctx_isolat...@vcs1-none.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-iclb3/igt@gem_ctx_isolat...@vcs1-none.html
* igt@gem_eio@in-flight-suspend:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5] ([i915#456] / [i915#460]
/ [i915#534])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_...@in-flight-suspend.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-tglb3/igt@gem_...@in-flight-suspend.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#476])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb7/igt@gem_...@kms.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-tglb8/igt@gem_...@kms.html
* igt@gem_exec_parallel@fds:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#470])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_exec_paral...@fds.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-tglb9/igt@gem_exec_paral...@fds.html
* igt@gem_exec_parallel@vecs0:
- shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111736])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb3/igt@gem_exec_paral...@vecs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-tglb2/igt@gem_exec_paral...@vecs0.html
* igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276]) +5 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-iclb6/igt@gem_exec_sched...@fifo-bsd1.html
* igt@gem_exec_schedule@independent-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb3/igt@gem_exec_sched...@independent-bsd.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-iclb1/igt@gem_exec_sched...@independent-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [PASS][16] -> [FAIL][17] ([i915#644])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-glk2/igt@gem_pp...@flink-and-close-vma-leak.html
* igt@gem_sync@basic-store-all:
- shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([i915#472])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb9/igt@gem_s...@basic-store-all.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-tglb6/igt@gem_s...@basic-store-all.html
* igt@i915_hangman@error-state-capture-vcs1:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#112080]) +6 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb1/igt@i915_hang...@error-state-capture-vcs1.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15805/shard-iclb3/igt@i915_han
[Intel-gfx] ✓ Fi.CI.BAT: success for linux-next: Tree for Dec 16 (drm_panel & intel_panel)
== Series Details ==
Series: linux-next: Tree for Dec 16 (drm_panel & intel_panel)
URL : https://patchwork.freedesktop.org/series/71052/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7580 -> Patchwork_15811
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/index.html
Known issues
Here are the changes found in Patchwork_15811 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [TIMEOUT][2] ([i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_blt:
- fi-bsw-nick:[PASS][3] -> [DMESG-FAIL][4] ([i915#723])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bsw-nick/igt@i915_selftest@live_blt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-bsw-nick/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy: [PASS][5] -> [INCOMPLETE][6] ([i915#694])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [TIMEOUT][7] ([i915#816]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_gttfill@basic:
- {fi-tgl-u}: [INCOMPLETE][9] ([fdo#111593]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-tgl-u/igt@gem_exec_gttf...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-tgl-u/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:[INCOMPLETE][11] ([i915#424]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
Warnings
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-x1275: [DMESG-WARN][13] ([fdo#107139] / [i915#62] /
[i915#92]) -> [DMESG-WARN][14] ([fdo#107139] / [i915#62] / [i915#92] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-kbl-x1275/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][15] ([i915#553] / [i915#725]) ->
[DMESG-FAIL][16] ([i915#725])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-hsw-4770/igt@i915_selftest@live_blt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-hsw-4770/igt@i915_selftest@live_blt.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15811/fi-kbl-x1275/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#723]: https://gitlab.freedesktop.org/drm/intel/issues/723
[i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
[i915#816]: https://gitlab.f
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Add lmem fault handler
On 17/12/2019 15.00, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Add lmem fault handler > URL : https://patchwork.freedesktop.org/series/71051/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7580 -> Patchwork_15810 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_15810 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_15810, 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_15810/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_15810: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_mman: > - fi-ilk-650: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-ilk-650/igt@i915_selftest@live_mman.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ilk-650/igt@i915_selftest@live_mman.html > - fi-bsw-n3050: NOTRUN -> [INCOMPLETE][3] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-n3050/igt@i915_selftest@live_mman.html > - fi-ivb-3770:[PASS][4] -> [DMESG-FAIL][5] >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-ivb-3770/igt@i915_selftest@live_mman.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ivb-3770/igt@i915_selftest@live_mman.html > - fi-hsw-4770r: [PASS][6] -> [DMESG-FAIL][7] >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-hsw-4770r/igt@i915_selftest@live_mman.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-hsw-4770r/igt@i915_selftest@live_mman.html > - fi-bsw-kefka: [PASS][8] -> [INCOMPLETE][9] >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bsw-kefka/igt@i915_selftest@live_mman.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-kefka/igt@i915_selftest@live_mman.html > - fi-blb-e6850: [PASS][10] -> [INCOMPLETE][11] >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-blb-e6850/igt@i915_selftest@live_mman.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-blb-e6850/igt@i915_selftest@live_mman.html > - fi-bwr-2160:[PASS][12] -> [INCOMPLETE][13] >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bwr-2160/igt@i915_selftest@live_mman.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bwr-2160/igt@i915_selftest@live_mman.html > - fi-kbl-8809g: [PASS][14] -> [DMESG-FAIL][15] >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-kbl-8809g/igt@i915_selftest@live_mman.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-kbl-8809g/igt@i915_selftest@live_mman.html > - fi-bsw-nick:[PASS][16] -> [INCOMPLETE][17] >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7580/fi-bsw-nick/igt@i915_selftest@live_mman.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-nick/igt@i915_selftest@live_mman.html > hmm, doesn't look too good with the memory regions. > * igt@runner@aborted: > - fi-ilk-650: NOTRUN -> [FAIL][18] >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-ilk-650/igt@run...@aborted.html > - fi-pnv-d510:NOTRUN -> [FAIL][19] >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-pnv-d510/igt@run...@aborted.html > - fi-bxt-dsi: NOTRUN -> [FAIL][20] >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bxt-dsi/igt@run...@aborted.html > - fi-bsw-n3050: NOTRUN -> [FAIL][21] >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-n3050/igt@run...@aborted.html > - fi-blb-e6850: NOTRUN -> [FAIL][22] >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-blb-e6850/igt@run...@aborted.html > - fi-bsw-kefka: NOTRUN -> [FAIL][23] >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-kefka/igt@run...@aborted.html > - fi-bsw-nick:NOTRUN -> [FAIL][24] >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-bsw-nick/igt@run...@aborted.html > - fi-elk-e7500: NOTRUN -> [FAIL][25] >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15810/fi-elk-e7500/igt@run...@aborted.html > > > Known issues > > > Here are the changes found in Patchwork_15810 that come from known issues: > > ### IGT changes ### > > ##
[Intel-gfx] [PATCH] drm/i915/gem: Keep request alive while attaching fences
Since commit e5dadff4b093 ("drm/i915: Protect request retirement with
timeline->mutex"), the request retirement can happen outside of the
struct_mutex serialised only by the timeline->mutex. We drop the
timeline->mutex on submitting the request (i915_request_add) so after
that point, it is liable to be freed. Make sure our local reference is
kept alive until we have finished attaching it to the signalers. (Note
that this erodes the argument that i915_request_add should consume the
reference, but that is a slightly larger patch!)
Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with
timeline->mutex")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 81eaf812c9da..7d07131aa3f7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2730,6 +2730,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err = eb_submit(&eb);
err_request:
add_to_client(eb.request, file);
+ i915_request_get(eb.request);
i915_request_add(eb.request);
if (fences)
@@ -2745,6 +2746,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
fput(out_fence->file);
}
}
+ i915_request_put(eb.request);
err_batch_unpin:
if (eb.batch_flags & I915_DISPATCH_SECURE)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight
On Tue, 17 Dec 2019, Jani Nikula wrote: > On Tue, 17 Dec 2019, Lee Jones wrote: > > On Mon, 16 Dec 2019, Hans de Goede wrote: > > > >> Hi, > >> > >> Doing immutable branches assumes that there is a base point, > >> e.g. 5.5-rc1 where the immutable branch can then be based on and > >> that the branch can then be merged without issues into both subsystems. > >> > >> drm is constantly evolving to deal with and mostly catch up with new > >> hardware as both GPUs and display-pipelines are evolving quite rapidly > >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an > >> immutable branch I can either base it on drm-intel-next which > >> violates your request for a clean minimal branch to merge; or I can > >> base it on 5.5-rc1 which leads to a big chance of problems when > >> merging it given to large amount of churn in drm-intel-next. > > > > This is a *slightly* more compelling reason than the ones you've > > previously provided. > > > >> So instead of the normal case of 2 subsystems seeing some changes > >> on both side the case we have here is a part of a file which has > >> not changed since 2015-06-26 in one subsys (and changing only > >> a single line there!) and OTOH we have bigger changes to a subsys > >> which see 400 patches land in the first week since rc1 . > > > > This is not. > > > >> I hope that you agree that in this case given the large amount of > >> churn in drm-intel-next it makes since to just straight forward > >> apply these patches on top of drm-intel-next. > > > > I have Acked this patch, but remember *this* is the exception rather > > than the rule. If/when we have a case where a contributor works > > cross-subsystem with DRM and the code/file adapted is live (more > > likely to change), I will have to insist on an immutable branch > > strategy. DRM will have to deal with that appropriately. > > Hi, thanks for the ack and reaching an agreement with Hans, and sorry > for not responding earlier. > > It's not unusual for us to have topic branches for cross-subsystem or > cross-driver changes, and I think usually we try to be accommodating in > merging stuff through whichever tree it makes most sense. In fact my ack > to do just that was my first response on this series [1]. > > So I don't really know why the fuss. We'll anyway deal with any > cross-subsystem series on a case by case basis, depending on what makes > most sense, and what suits all maintainers involved. Perfect. Thanks for the clarification. I look forward to working with you guys in the future. Hans was making the case that this was impractical for DRM, due to the amount of churn you guys receive, hence the discussion. I'm very pleased that this is not the case. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/display: Force the state compute phase once to enable PSR
Recent improvements in the state tracking in i915 caused PSR to not be
enabled when reusing firmware/BIOS modeset, this is due to all initial
commits returning ealier in intel_atomic_check() as needs_modeset()
is always false.
To fix that here forcing the state compute phase in CRTC that is
driving the eDP that supports PSR once. Enable or disable PSR do not
require a fullmodeset, so user will still experience glitch free boot
process plus the power savings that PSR brings.
It was tried to set mode_changed in intel_initial_commit() but at
this point the connectors are not registered causing a crash when
computing encoder state.
v2:
- removed function return
- change arguments to match intel_hdcp_atomic_check
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253
Reported-by:
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/display/intel_psr.c| 24 +
drivers/gpu/drm/i915/display/intel_psr.h| 6 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index fd0026fc3618..59be1d0c4f36 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -37,6 +37,7 @@
#include "intel_atomic.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
+#include "intel_psr.h"
#include "intel_sprite.h"
/**
@@ -129,6 +130,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
struct drm_crtc_state *crtc_state;
intel_hdcp_atomic_check(conn, old_state, new_state);
+ intel_psr_atomic_check(conn, old_state, new_state);
if (!new_state->crtc)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 16e9ff47d519..e3fd5f1e2d21 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1523,3 +1523,27 @@ bool intel_psr_enabled(struct intel_dp *intel_dp)
return ret;
}
+
+void intel_psr_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *old_state,
+ struct drm_connector_state *new_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_connector *intel_connector;
+ struct intel_digital_port *dig_port;
+ struct drm_crtc_state *crtc_state;
+
+ if (!CAN_PSR(dev_priv) || !new_state->crtc ||
+ dev_priv->psr.initially_probed)
+ return;
+
+ intel_connector = to_intel_connector(connector);
+ dig_port = enc_to_dig_port(&intel_connector->encoder->base);
+ if (dev_priv->psr.dp != &dig_port->dp)
+ return;
+
+ crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
+ new_state->crtc);
+ crtc_state->mode_changed = true;
+ dev_priv->psr.initially_probed = true;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
b/drivers/gpu/drm/i915/display/intel_psr.h
index 46e4de8b8cd5..6348df32baed 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -6,6 +6,9 @@
#ifndef __INTEL_PSR_H__
#define __INTEL_PSR_H__
+#include
+#include
+
#include "intel_frontbuffer.h"
struct drm_i915_private;
@@ -35,5 +38,8 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp);
int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
u32 *out_value);
bool intel_psr_enabled(struct intel_dp *intel_dp);
+void intel_psr_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *old_state,
+ struct drm_connector_state *new_state);
#endif /* __INTEL_PSR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0781b6326b8c..873eec1e37e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -505,6 +505,7 @@ struct i915_psr {
bool dc3co_enabled;
u32 dc3co_exit_delay;
struct delayed_work idle_work;
+ bool initially_probed;
};
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Keep request alive while attaching fences
On Tue, 17 Dec 2019 at 13:47, Chris Wilson wrote:
>
> Since commit e5dadff4b093 ("drm/i915: Protect request retirement with
> timeline->mutex"), the request retirement can happen outside of the
> struct_mutex serialised only by the timeline->mutex. We drop the
> timeline->mutex on submitting the request (i915_request_add) so after
> that point, it is liable to be freed. Make sure our local reference is
> kept alive until we have finished attaching it to the signalers. (Note
> that this erodes the argument that i915_request_add should consume the
> reference, but that is a slightly larger patch!)
>
> Fixes: e5dadff4b093 ("drm/i915: Protect request retirement with
> timeline->mutex")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Tvrtko Ursulin
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote:
> On 17/12/2019 06:37, Randy Dunlap wrote:
> > On 12/16/19 9:42 PM, Sam Ravnborg wrote:
> >> On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
> >>> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
> >>> on x86_64:
> >>>
> >>> ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight':
> >>> (.text+0x2ee): undefined reference to `devm_of_find_backlight'
> >>>
> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
> >>> `intel_backlight_device_register':
> >>> intel_panel.c:(.text+0x593e): undefined reference to
> >>> `backlight_device_register'
> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
> >>> `intel_backlight_device_unregister':
> >>> intel_panel.c:(.text+0x5a04): undefined reference to
> >>> `backlight_device_unregister'
> >>>
> >>> CONFIG_DRM_PANEL=y
> >>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
> >>> CONFIG_DRM_I915=y
> >>>
> >>> Full randconfig file is attached.
> >>
> >> Can you please verify if you have:
> >> 907aa265fde6589b8059dc51649c6d1f49ade2f3
> >> ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
> >>
> >> This commit is supposed to fix it.
> >>
> >> Sam
> >>
> >
> > Hi Sam,
> > I don't have the linux-next.git tree so I can't check that.
> > I just built whatever is in linux-next of 20191216.
> >
>
> 907aa265fde6589b8059dc51649c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
> drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
> error above is for backlight_device_register().
>
> From what I can tell, that commit is actually the cause of the error -
> now intel_backlight_device_register() is being included in the kernel
> even though it calls backlight_device_register() which is in a module.
> Of course it also fixed the original error, so reverting it isn't any
> use.
>
> The below Kconfig change fixes the build for me, but I've no idea
> whether this is the correct fix.
I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/.
It fixes issue for me.
Should I send a patch?
--
With Best Regards,
Andy Shevchenko
___
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 [v2,rebased,01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev2)
== Series Details ==
Series: series starting with [v2,rebased,01/11] drm: Add
__drm_atomic_helper_crtc_state_reset() & co. (rev2)
URL : https://patchwork.freedesktop.org/series/70775/
State : failure
== Summary ==
Applying: drm: Add __drm_atomic_helper_crtc_state_reset() & co.
Applying: drm/i915: s/intel_crtc/crtc/ in intel_crtc_init()
Applying: drm/i915: Introduce intel_crtc_{alloc, free}()
Applying: drm/i915: Introduce intel_crtc_state_reset()
Applying: drm/i915: Introduce intel_plane_state_reset()
Applying: drm/i915/display: Share intel_connector_needs_modeset()
Applying: drm/i915/tgl: Select master transcoder for MST stream
Applying: drm/i915/display: Always enables MST master pipe first
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...
Auto-merging drivers/gpu/drm/i915/display/intel_display.c
CONFLICT (content): Merge conflict in
drivers/gpu/drm/i915/display/intel_display.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0008 drm/i915/display: Always enables MST master pipe first
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 v2] drm/i915/pmu: Ensure monotonic rc6
From: Tvrtko Ursulin
Avoid rc6 counter going backward in close to 0% RC6 scenarios like:
15.005477996114,246,613 ns i915/rc6-residency/
16.005876662667,657 ns i915/rc6-residency/
17.006131417 7,286 ns i915/rc6-residency/
18.006615031 18,446,744,073,708,914,688 ns i915/rc6-residency/
19.007158361 18,446,744,073,709,447,168 ns i915/rc6-residency/
20.007806498 0 ns i915/rc6-residency/
21.008227495 1,440,403 ns i915/rc6-residency/
There are two aspects to this fix.
First is not assuming rc6 value zero means GT is asleep since that can
also mean GPU is fully busy and we do not want to enter the estimation
path in that case.
Second is ensuring monotonicity on the estimation path itself. I suspect
what is happening is with extremely rapid park/unpark cycles we get no
updates on the real rc6 and therefore have to careful not to
unconditionally trust use last known real rc6 when creating a new
estimation.
v2:
* Simplify logic by not tracking the estimate but last reported value.
Signed-off-by: Tvrtko Ursulin
Fixes: 16ffe73c186b ("drm/i915/pmu: Use GT parked for estimating RC6 while
asleep")
Cc: Chris Wilson
Reviewed-by: Chris Wilson # v1
---
drivers/gpu/drm/i915/i915_pmu.c | 73 +
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
2 files changed, 21 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 5f2adfbf85be..c6cb77c8249b 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -144,61 +144,40 @@ static inline s64 ktime_since(const ktime_t kt)
return ktime_to_ns(ktime_sub(ktime_get(), kt));
}
-static u64 __pmu_estimate_rc6(struct i915_pmu *pmu)
-{
- u64 val;
-
- /*
-* We think we are runtime suspended.
-*
-* Report the delta from when the device was suspended to now,
-* on top of the last known real value, as the approximated RC6
-* counter value.
-*/
- val = ktime_since(pmu->sleep_last);
- val += pmu->sample[__I915_SAMPLE_RC6].cur;
-
- pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
-
- return val;
-}
-
-static u64 __pmu_update_rc6(struct i915_pmu *pmu, u64 val)
-{
- /*
-* If we are coming back from being runtime suspended we must
-* be careful not to report a larger value than returned
-* previously.
-*/
- if (val >= pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
- pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
- pmu->sample[__I915_SAMPLE_RC6].cur = val;
- } else {
- val = pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
- }
-
- return val;
-}
-
static u64 get_rc6(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
struct i915_pmu *pmu = &i915->pmu;
unsigned long flags;
+ bool awake = false;
u64 val;
- val = 0;
if (intel_gt_pm_get_if_awake(gt)) {
val = __get_rc6(gt);
intel_gt_pm_put_async(gt);
+ awake = true;
}
spin_lock_irqsave(&pmu->lock, flags);
- if (val)
- val = __pmu_update_rc6(pmu, val);
+ if (awake) {
+ pmu->sample[__I915_SAMPLE_RC6].cur = val;
+ } else {
+ /*
+* We think we are runtime suspended.
+*
+* Report the delta from when the device was suspended to now,
+* on top of the last known real value, as the approximated RC6
+* counter value.
+*/
+ val = ktime_since(pmu->sleep_last);
+ val += pmu->sample[__I915_SAMPLE_RC6].cur;
+ }
+
+ if (val < pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur)
+ val = pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur;
else
- val = __pmu_estimate_rc6(pmu);
+ pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
spin_unlock_irqrestore(&pmu->lock, flags);
@@ -210,20 +189,11 @@ static void park_rc6(struct drm_i915_private *i915)
struct i915_pmu *pmu = &i915->pmu;
if (pmu->enable & config_enabled_mask(I915_PMU_RC6_RESIDENCY))
- __pmu_update_rc6(pmu, __get_rc6(&i915->gt));
+ pmu->sample[__I915_SAMPLE_RC6].cur = __get_rc6(&i915->gt);
pmu->sleep_last = ktime_get();
}
-static void unpark_rc6(struct drm_i915_private *i915)
-{
- struct i915_pmu *pmu = &i915->pmu;
-
- /* Estimate how long we slept and accumulate that into rc6 counters */
- if (pmu->enable & config_enabled_mask(I915_PMU_RC6_RESIDENCY))
- __pmu_estimate_rc6(pmu);
-}
-
#else
static u64 get_rc6(struct intel_gt *gt)
@@ -232,7 +202,6 @@ static u64 get_rc6(struct intel_gt *gt)
}
static void park_rc6(struct
Re: [Intel-gfx] [PATCH v2] drm/i915/pmu: Ensure monotonic rc6
Quoting Tvrtko Ursulin (2019-12-17 14:20:57)
> From: Tvrtko Ursulin
>
> Avoid rc6 counter going backward in close to 0% RC6 scenarios like:
>
> 15.005477996114,246,613 ns i915/rc6-residency/
> 16.005876662667,657 ns i915/rc6-residency/
> 17.006131417 7,286 ns i915/rc6-residency/
> 18.006615031 18,446,744,073,708,914,688 ns i915/rc6-residency/
> 19.007158361 18,446,744,073,709,447,168 ns i915/rc6-residency/
> 20.007806498 0 ns i915/rc6-residency/
> 21.008227495 1,440,403 ns i915/rc6-residency/
>
> There are two aspects to this fix.
>
> First is not assuming rc6 value zero means GT is asleep since that can
> also mean GPU is fully busy and we do not want to enter the estimation
> path in that case.
>
> Second is ensuring monotonicity on the estimation path itself. I suspect
> what is happening is with extremely rapid park/unpark cycles we get no
> updates on the real rc6 and therefore have to careful not to
> unconditionally trust use last known real rc6 when creating a new
> estimation.
>
> v2:
> * Simplify logic by not tracking the estimate but last reported value.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 16ffe73c186b ("drm/i915/pmu: Use GT parked for estimating RC6 while
> asleep")
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson # v1
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 73 +
> drivers/gpu/drm/i915/i915_pmu.h | 2 +-
> 2 files changed, 21 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 5f2adfbf85be..c6cb77c8249b 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -144,61 +144,40 @@ static inline s64 ktime_since(const ktime_t kt)
> return ktime_to_ns(ktime_sub(ktime_get(), kt));
> }
>
> -static u64 __pmu_estimate_rc6(struct i915_pmu *pmu)
> -{
> - u64 val;
> -
> - /*
> -* We think we are runtime suspended.
> -*
> -* Report the delta from when the device was suspended to now,
> -* on top of the last known real value, as the approximated RC6
> -* counter value.
> -*/
> - val = ktime_since(pmu->sleep_last);
> - val += pmu->sample[__I915_SAMPLE_RC6].cur;
> -
> - pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
> -
> - return val;
> -}
> -
> -static u64 __pmu_update_rc6(struct i915_pmu *pmu, u64 val)
> -{
> - /*
> -* If we are coming back from being runtime suspended we must
> -* be careful not to report a larger value than returned
> -* previously.
> -*/
> - if (val >= pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
> - pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
> - pmu->sample[__I915_SAMPLE_RC6].cur = val;
> - } else {
> - val = pmu->sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
> - }
> -
> - return val;
> -}
> -
> static u64 get_rc6(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> struct i915_pmu *pmu = &i915->pmu;
> unsigned long flags;
> + bool awake = false;
> u64 val;
>
> - val = 0;
> if (intel_gt_pm_get_if_awake(gt)) {
> val = __get_rc6(gt);
> intel_gt_pm_put_async(gt);
> + awake = true;
> }
>
> spin_lock_irqsave(&pmu->lock, flags);
>
> - if (val)
> - val = __pmu_update_rc6(pmu, val);
> + if (awake) {
> + pmu->sample[__I915_SAMPLE_RC6].cur = val;
> + } else {
> + /*
> +* We think we are runtime suspended.
> +*
> +* Report the delta from when the device was suspended to now,
> +* on top of the last known real value, as the approximated
> RC6
> +* counter value.
> +*/
> + val = ktime_since(pmu->sleep_last);
> + val += pmu->sample[__I915_SAMPLE_RC6].cur;
> + }
> +
> + if (val < pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur)
> + val = pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur;
> else
> - val = __pmu_estimate_rc6(pmu);
> + pmu->sample[__I915_SAMPLE_RC6_LAST_REPORTED].cur = val;
Ok, that makes sense and seems benign with respect to pm races. I hope it
holds up in practice :)
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Add getfb2 ioctl (rev2)
== Series Details ==
Series: drm: Add getfb2 ioctl (rev2)
URL : https://patchwork.freedesktop.org/series/67553/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15806_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15806_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15806_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_15806_full:
### IGT changes ###
Possible regressions
* igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- shard-apl: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-apl3/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15806/shard-apl1/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html
### Piglit changes ###
Possible regressions
* spec@glsl-1.30@execution@texelfetch@fs-texelfetch-isampler1darray (NEW):
- {pig-hsw-4770r}:NOTRUN -> [FAIL][3] +958 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15806/pig-hsw-4770r/spec@glsl-1.30@execution@texelfe...@fs-texelfetch-isampler1darray.html
New tests
-
New tests have been introduced between CI_DRM_7578_full and
Patchwork_15806_full:
### New Piglit tests (960) ###
* object namespace pollution@texture with glcopyimagesubdata:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
* object namespace pollution@texture with gldrawpixels:
- Statuses : 1 fail(s)
- Exec time: [0.17] s
* object namespace pollution@texture with glgetteximage-compressed:
- Statuses : 1 fail(s)
- Exec time: [0.32] s
* shaders@glsl-fs-frontfacing-not:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
* spec@!opengl 1.1@depthstencil-default_fb-copypixels samples=2:
- Statuses : 1 fail(s)
- Exec time: [0.09] s
* spec@!opengl 1.1@depthstencil-default_fb-drawpixels-24_8 samples=2:
- Statuses : 1 fail(s)
- Exec time: [0.09] s
* spec@!opengl 1.1@depthstencil-default_fb-drawpixels-float-and-ushort:
- Statuses : 1 fail(s)
- Exec time: [0.08] s
* spec@!opengl 1.1@depthstencil-default_fb-drawpixels-float-and-ushort
samples=2:
- Statuses : 1 fail(s)
- Exec time: [0.09] s
* spec@!opengl 1.1@depthstencil-default_fb-readpixels-32f_24_8_rev samples=2:
- Statuses : 1 fail(s)
- Exec time: [0.08] s
* spec@!opengl 1.1@draw-pixels:
- Statuses : 1 fail(s)
- Exec time: [0.99] s
* spec@!opengl 1.1@getteximage-depth:
- Statuses : 1 fail(s)
- Exec time: [6.34] s
* spec@!opengl 1.1@getteximage-formats:
- Statuses : 1 fail(s)
- Exec time: [8.79] s
* spec@!opengl 1.1@teximage-colors gl_alpha:
- Statuses : 1 fail(s)
- Exec time: [0.28] s
* spec@!opengl 1.1@teximage-colors gl_alpha12:
- Statuses : 1 fail(s)
- Exec time: [0.34] s
* spec@!opengl 1.1@teximage-colors gl_alpha16:
- Statuses : 1 fail(s)
- Exec time: [0.37] s
* spec@!opengl 1.1@teximage-colors gl_alpha4:
- Statuses : 1 fail(s)
- Exec time: [0.34] s
* spec@!opengl 1.1@teximage-colors gl_alpha8:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@!opengl 1.1@teximage-colors gl_luminance:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@!opengl 1.1@teximage-colors gl_luminance12:
- Statuses : 1 fail(s)
- Exec time: [0.29] s
* spec@!opengl 1.1@teximage-colors gl_luminance12_alpha12:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@!opengl 1.1@teximage-colors gl_luminance12_alpha4:
- Statuses : 1 fail(s)
- Exec time: [0.37] s
* spec@!opengl 1.1@teximage-colors gl_luminance16:
- Statuses : 1 fail(s)
- Exec time: [0.35] s
* spec@!opengl 1.1@teximage-colors gl_luminance16_alpha16:
- Statuses : 1 fail(s)
- Exec time: [0.35] s
* spec@!opengl 1.1@teximage-colors gl_luminance4:
- Statuses : 1 fail(s)
- Exec time: [0.35] s
* spec@!opengl 1.1@teximage-colors gl_luminance4_alpha4:
- Statuses : 1 fail(s)
- Exec time: [0.28] s
* spec@!opengl 1.1@teximage-colors gl_luminance6_alpha2:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@!opengl 1.1@teximage-colors gl_luminance8:
- Statuses : 1 fail(s)
- Exec time: [0.28] s
* spec@!opengl 1.1@teximage-colors gl_luminance8_alpha8:
- Statuses : 1 fail(s)
- Exec time: [0.32] s
* spec@!opengl 1.1@teximage-colors gl_luminance_alpha:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@!opengl 1.1@teximage-colors gl
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev2)
== Series Details == Series: series starting with [v3,01/11] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev2) URL : https://patchwork.freedesktop.org/series/71009/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7581 -> Patchwork_15813 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15813 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15813, 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_15813/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_15813: ### IGT changes ### Possible regressions * igt@kms_busy@basic-flip-pipe-b: - fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-cfl-guc/igt@kms_b...@basic-flip-pipe-b.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-cfl-guc/igt@kms_b...@basic-flip-pipe-b.html - fi-cfl-8700k: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-cfl-8700k/igt@kms_b...@basic-flip-pipe-b.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-cfl-8700k/igt@kms_b...@basic-flip-pipe-b.html * igt@kms_busy@basic-flip-pipe-c: - fi-kbl-7500u: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-c.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-kbl-7500u/igt@kms_b...@basic-flip-pipe-c.html - fi-skl-guc: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-guc/igt@kms_b...@basic-flip-pipe-c.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-skl-guc/igt@kms_b...@basic-flip-pipe-c.html * igt@runner@aborted: - fi-whl-u: NOTRUN -> [FAIL][9] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-whl-u/igt@run...@aborted.html - fi-bxt-dsi: NOTRUN -> [FAIL][10] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-bxt-dsi/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_15813 that come from known issues: ### IGT changes ### Issues hit * igt@kms_busy@basic-flip-pipe-b: - fi-skl-6770hq: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html - fi-skl-lmem:[PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-lmem/igt@kms_b...@basic-flip-pipe-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-skl-lmem/igt@kms_b...@basic-flip-pipe-b.html - fi-cml-u2: [PASS][15] -> [TIMEOUT][16] ([i915#109] / [i915#449]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-cml-u2/igt@kms_b...@basic-flip-pipe-b.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-cml-u2/igt@kms_b...@basic-flip-pipe-b.html - fi-apl-guc: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-apl-guc/igt@kms_b...@basic-flip-pipe-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-apl-guc/igt@kms_b...@basic-flip-pipe-b.html - fi-bxt-dsi: [PASS][19] -> [TIMEOUT][20] ([i915#109] / [i915#449]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-bxt-dsi/igt@kms_b...@basic-flip-pipe-b.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-bxt-dsi/igt@kms_b...@basic-flip-pipe-b.html - fi-skl-6600u: [PASS][21] -> [TIMEOUT][22] ([i915#109] / [i915#449]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-6600u/igt@kms_b...@basic-flip-pipe-b.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-skl-6600u/igt@kms_b...@basic-flip-pipe-b.html - fi-whl-u: [PASS][23] -> [TIMEOUT][24] ([i915#109] / [i915#449]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-whl-u/igt@kms_b...@basic-flip-pipe-b.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813/fi-whl-u/igt@kms_b...@basic-flip-pipe-b.html - fi-icl-y: [PASS][25] -> [TIMEOUT][26] ([i915#109] / [i915#449]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-icl-y/igt@kms_b...@basic-flip-pipe-b.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15813
Re: [Intel-gfx] [PATCH 1/8] drm/print: introduce new struct drm_device based logging macros
On Tue, 10 Dec 2019, Jani Nikula wrote: > Add new struct drm_device based logging macros modeled after the core > kernel device based logging macros. These would be preferred over the > drm printk and struct device based macros in drm code, where possible. > > We have existing drm specific struct device based logging functions, but > they are too verbose to use for two main reasons: > > * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). > > * The use of struct device over struct drm_device is too generic for >most users, leading to an extra dereference. > > For example: > > DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); > > vs. > > drm_dbg_kms(drm, "Hello, world\n"); > > It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be > less readable than lowercase. > > Some names are changed from old DRM names to be based on the core kernel > logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> > dbg. > > Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use > (DRM_DEBUG is used widely in drivers though it's supposed to be a core > debugging category), they are named as drm_dbg_core and drm_dbg, > respectively. > > The drm_err and _once/_ratelimited variants no longer include the > function name in order to be able to use the core device based logging > macros. Arguably this is not a significant change; error messages should > not be so common to be only distinguishable by the function name. > > Ratelimited debug logging macros are to be added later. > > Cc: Sam Ravnborg > Acked-by: Ville Syrjälä > Reviewed-by: Rodrigo Vivi > Acked-by: Sean Paul > Signed-off-by: Jani Nikula Pushed this one patch, thanks for the reviews and acks. The rest could still use review. ;) BR, Jani. > > --- > > With something like this, I think i915 could start migrating to > drm_device based logging. I have a hard time convincing myself or anyone > about migrating to the DRM_DEV_* variants. > --- > include/drm/drm_print.h | 65 + > 1 file changed, 65 insertions(+) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index 085a9685270c..8f99d389792d 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -322,6 +322,8 @@ static inline bool drm_debug_enabled(enum > drm_debug_category category) > > /* > * struct device based logging > + * > + * Prefer drm_device based logging over device or prink based logging. > */ > > __printf(3, 4) > @@ -417,8 +419,71 @@ void drm_dev_dbg(const struct device *dev, enum > drm_debug_category category, > _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, DRM_UT_PRIME,\ > fmt, ##__VA_ARGS__) > > +/* > + * struct drm_device based logging > + * > + * Prefer drm_device based logging over device or prink based logging. > + */ > + > +/* Helper for struct drm_device based logging. */ > +#define __drm_printk(drm, level, type, fmt, ...) \ > + dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__) > + > + > +#define drm_info(drm, fmt, ...) \ > + __drm_printk((drm), info,, fmt, ##__VA_ARGS__) > + > +#define drm_notice(drm, fmt, ...)\ > + __drm_printk((drm), notice,, fmt, ##__VA_ARGS__) > + > +#define drm_warn(drm, fmt, ...) \ > + __drm_printk((drm), warn,, fmt, ##__VA_ARGS__) > + > +#define drm_err(drm, fmt, ...) \ > + __drm_printk((drm), err,, "*ERROR* " fmt, ##__VA_ARGS__) > + > + > +#define drm_info_once(drm, fmt, ...) \ > + __drm_printk((drm), info, _once, fmt, ##__VA_ARGS__) > + > +#define drm_notice_once(drm, fmt, ...) \ > + __drm_printk((drm), notice, _once, fmt, ##__VA_ARGS__) > + > +#define drm_warn_once(drm, fmt, ...) \ > + __drm_printk((drm), warn, _once, fmt, ##__VA_ARGS__) > + > +#define drm_err_once(drm, fmt, ...) \ > + __drm_printk((drm), err, _once, "*ERROR* " fmt, ##__VA_ARGS__) > + > + > +#define drm_err_ratelimited(drm, fmt, ...) \ > + __drm_printk((drm), err, _ratelimited, "*ERROR* " fmt, ##__VA_ARGS__) > + > + > +#define drm_dbg_core(drm, fmt, ...) \ > + drm_dev_dbg((drm)->dev, DRM_UT_CORE, fmt, ##__VA_ARGS__) > +#define drm_dbg(drm, fmt, ...) > \ > + drm_dev_dbg((drm)->dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__) > +#define drm_dbg_kms(drm, fmt, ...) \ > + drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__) > +#define drm_dbg_prime(drm, fmt, ...) \ > + drm_dev_dbg((drm)->dev, DRM_UT_PRIME, fmt, ##__VA_ARGS__) > +#define drm_dbg_atomic(drm, fmt, ...)
[Intel-gfx] [PATCH v4 rebased 2/2] drm/i915/display: Fix warning about MST and DDI restrictions
Capturing the restrictions of the BSpec pages bellow: SKL and CNL do not support MST in DDI E, DDI E only support 2 lanes and it is mostly used to support a 4 lanes eDP panel together with DDI A. ICL's DDI E support MST just like other ports but DDI A is still eDP and MIPI only. TGL supports MST in any DDI, including DDI A but TGL has it's own ddi_pre_enable_dp function already without any warning. [ 215.579791] [ cut here ] [ 215.579794] WARN_ON(is_mst && (port == PORT_A || port == PORT_E)) [ 215.579875] WARNING: CPU: 0 PID: 268 at drivers/gpu/drm/i915/display/intel_ddi.c:3576 intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579878] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core asix mei_hdcp cdc_ether x86_pkg_temp_thermal mei_me snd_pcm r8152 coretemp usbnet mei crct10dif_pclmul mii ptp ecdh_generic crc32_pclmul i2c_i801 ecc pps_core ghash_clmulni_intel thunderbolt [ 215.579905] CPU: 0 PID: 268 Comm: kworker/0:2 Tainted: GW 5.4.0-rc8-zeh+ #1307 [ 215.579907] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019 [ 215.579912] Workqueue: events_long drm_dp_mst_link_probe_work [ 215.579975] RIP: 0010:intel_ddi_pre_enable+0x124/0xea0 [i915] [ 215.579978] Code: ff 8b 7c 24 10 89 44 24 30 85 ff 74 1f f7 44 24 18 fb ff ff ff 75 15 48 c7 c6 98 fa 48 a0 48 c7 c7 d3 df 4a a0 e8 cf d5 d0 e0 <0f> 0b 0f b6 4c 24 2c 41 8b b5 04 06 00 00 4c 89 e7 41 0f b6 95 0c [ 215.579980] RSP: 0018:c90001a5f990 EFLAGS: 00010286 [ 215.579984] RAX: RBX: 88848356a000 RCX: [ 215.579986] RDX: 1df1 RSI: 88849340c998 RDI: 821489c5 [ 215.579989] RBP: 88848356a000 R08: c021a419 R09: [ 215.579991] R10: R11: R12: 88848356a118 [ 215.579994] R13: 88847f39c000 R14: 88847fe7 R15: 88848356a000 [ 215.579996] FS: () GS:88849f80() knlGS: [ 215.57] CS: 0010 DS: ES: CR0: 80050033 [ 215.580001] CR2: 55d3d5a26bc0 CR3: 000480ba6005 CR4: 00760ef0 [ 215.580004] PKRU: 5554 [ 215.580006] Call Trace: [ 215.580014] ? drm_dp_mst_topology_put_port+0x6f/0x130 [ 215.580072] intel_mst_pre_enable_dp+0x14b/0x170 [i915] [ 215.580129] intel_encoders_pre_enable+0x76/0x90 [i915] [ 215.580191] haswell_crtc_enable+0x84/0x880 [i915] [ 215.580266] intel_update_crtc+0x1e4/0x200 [i915] [ 215.580333] skl_commit_modeset_enables+0x287/0x420 [i915] [ 215.580405] intel_atomic_commit_tail+0x332/0x14e0 [i915] [ 215.580410] ? queue_work_on+0x41/0x70 [ 215.580489] intel_atomic_commit+0x31e/0x350 [i915] [ 215.580500] drm_client_modeset_commit_atomic+0x18b/0x220 [ 215.580523] drm_client_modeset_commit_force+0x4d/0x180 [ 215.580531] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 215.580538] drm_fb_helper_set_par+0x27/0x50 [ 215.580543] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0 [ 215.580549] drm_kms_helper_hotplug_event+0x21/0x30 [ 215.580553] process_one_work+0x25b/0x5b0 [ 215.580566] worker_thread+0x4b/0x3b0 [ 215.580578] kthread+0x100/0x140 [ 215.580581] ? process_one_work+0x5b0/0x5b0 [ 215.580585] ? kthread_park+0x80/0x80 [ 215.580591] ret_from_fork+0x24/0x50 [ 215.580603] irq event stamp: 1393930 [ 215.580606] hardirqs last enabled at (1393929): [] vprintk_emit+0x143/0x330 [ 215.580609] hardirqs last disabled at (1393930): [] trace_hardirqs_off_thunk+0x1a/0x20 [ 215.580613] softirqs last enabled at (1393434): [] __do_softirq+0x389/0x47f [ 215.580618] softirqs last disabled at (1393423): [] irq_exit+0xa9/0xc0 [ 215.580621] ---[ end trace afd44ea9caa6373e ]--- BSpec: 4217 BSpec: 14004 BSpec: 20584 BSpec: 50583 Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_ddi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 1d98d90a715a..0e0874ebf3ee 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3525,7 +3525,10 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder *encoder, bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST); int level = intel_ddi_dp_level(intel_dp); - WARN_ON(is_mst && (port == PORT_A || port == PORT_E)); + if (INTEL_GEN(dev_priv) < 11) + WARN_ON(is_mst && (port == PORT_A || port == PORT_E)); + else + WARN_ON(is_mst && port == PORT_A); intel_dp_set_link_params(intel_dp, crtc_state->port_clock, crtc_state->lane_count, is_mst); -- 2.24.1
[Intel-gfx] [PATCH v4 rebased 1/2] drm/i915/display/icl+: Do not program clockgating
Talked with HW team and this is a left over, driver should not
program clockgating, mg or dekel firmware is reponsible for any
clockgating programing.
Also removing the register and bits definition related to clockgating.
v2:
Added WARN_ON
v3:
Only calling icl_phy_set_clock_gating() on intel_ddi_pre_enable_hdmi
for GEN11
v4:
ICL should also not program clockgating (thanks Matt for catching
this)
BSpec issue: 20885
BSpec: 49292
BSpec: 21735
Cc: Lucas De Marchi
Cc: Matt Roper
Cc: Jani Nikula
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 72
drivers/gpu/drm/i915/i915_reg.h | 20 ---
2 files changed, 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5b6f32517c75..1d98d90a715a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3159,57 +3159,6 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
}
}
-static void
-icl_phy_set_clock_gating(struct intel_digital_port *dig_port, bool enable)
-{
- struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
- u32 val, bits;
- int ln;
-
- if (tc_port == PORT_TC_NONE)
- return;
-
- bits = MG_DP_MODE_CFG_TR2PWR_GATING | MG_DP_MODE_CFG_TRPWR_GATING |
- MG_DP_MODE_CFG_CLNPWR_GATING | MG_DP_MODE_CFG_DIGPWR_GATING |
- MG_DP_MODE_CFG_GAONPWR_GATING;
-
- for (ln = 0; ln < 2; ln++) {
- if (INTEL_GEN(dev_priv) >= 12) {
- I915_WRITE(HIP_INDEX_REG(tc_port),
HIP_INDEX_VAL(tc_port, ln));
- val = I915_READ(DKL_DP_MODE(tc_port));
- } else {
- val = I915_READ(MG_DP_MODE(ln, tc_port));
- }
-
- if (enable)
- val |= bits;
- else
- val &= ~bits;
-
- if (INTEL_GEN(dev_priv) >= 12)
- I915_WRITE(DKL_DP_MODE(tc_port), val);
- else
- I915_WRITE(MG_DP_MODE(ln, tc_port), val);
- }
-
- if (INTEL_GEN(dev_priv) == 11) {
- bits = MG_MISC_SUS0_CFG_TR2PWR_GATING |
- MG_MISC_SUS0_CFG_CL2PWR_GATING |
- MG_MISC_SUS0_CFG_GAONPWR_GATING |
- MG_MISC_SUS0_CFG_TRPWR_GATING |
- MG_MISC_SUS0_CFG_CL1PWR_GATING |
- MG_MISC_SUS0_CFG_DGPWR_GATING;
-
- val = I915_READ(MG_MISC_SUS0(tc_port));
- if (enable)
- val |= (bits | MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3));
- else
- val &= ~(bits |
MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK);
- I915_WRITE(MG_MISC_SUS0(tc_port), val);
- }
-}
-
static void
icl_program_mg_dp_mode(struct intel_digital_port *intel_dig_port,
const struct intel_crtc_state *crtc_state)
@@ -3508,12 +3457,6 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
* down this function.
*/
- /*
-* 7.d Type C with DP alternate or fixed/legacy/static connection -
-* Disable PHY clock gating per Type-C DDI Buffer page
-*/
- icl_phy_set_clock_gating(dig_port, false);
-
/* 7.e Configure voltage swing and related IO settings */
tgl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
encoder->type);
@@ -3565,15 +3508,6 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
if (!is_trans_port_sync_mode(crtc_state))
intel_dp_stop_link_train(intel_dp);
- /*
-* TODO: enable clock gating
-*
-* It is not written in DP enabling sequence but "PHY Clockgating
-* programming" states that clock gating should be enabled after the
-* link training but doing so causes all the following trainings to fail
-* so not enabling it for now.
-*/
-
/* 7.l Configure and enable FEC if needed */
intel_ddi_enable_fec(encoder, crtc_state);
intel_dsc_enable(encoder, crtc_state);
@@ -3609,7 +3543,6 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
dig_port->ddi_io_power_domain);
icl_program_mg_dp_mode(dig_port, crtc_state);
- icl_phy_set_clock_gating(dig_port, false);
if (INTEL_GEN(dev_priv) >= 11)
icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
@@ -3643,8 +3576,6 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_ddi_enable_fec(encoder, crtc_state);
- icl_phy_set_clock_gating(dig_port, true);
-
if (!is_mst)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Keep request alive while attaching fences
== Series Details ==
Series: drm/i915/gem: Keep request alive while attaching fences
URL : https://patchwork.freedesktop.org/series/71053/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7581 -> Patchwork_15814
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/index.html
Known issues
Here are the changes found in Patchwork_15814 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [TIMEOUT][2] ([i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2: [PASS][3] -> [FAIL][4] ([fdo#103375]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-skl-6700k2: [PASS][5] -> [INCOMPLETE][6] ([i915#69])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-6700k2/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-skl-6700k2/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[PASS][7] -> [DMESG-FAIL][8] ([i915#770])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-hsw-4770/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-hsw-4770/igt@i915_selftest@live_blt.html
* igt@kms_frontbuffer_tracking@basic:
- fi-skl-6600u: [PASS][9] -> [INCOMPLETE][10] ([i915#667])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-skl-6600u/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-skl-6600u/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_module_load@reload-with-fault-injection:
- fi-ilk-650: [DMESG-WARN][11] ([i915#116]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-ilk-650/igt@i915_module_l...@reload-with-fault-injection.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-ilk-650/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_selftest@live_blt:
- fi-ivb-3770:[DMESG-FAIL][13] ([i915#725]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-ivb-3770/igt@i915_selftest@live_blt.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-ivb-3770/igt@i915_selftest@live_blt.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +9 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-icl-u2: [DMESG-WARN][17] ([i915#289]) -> [DMESG-WARN][18]
([i915#109] / [i915#289])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-icl-u2/igt@i915_pm_...@module-reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-icl-u2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][19] ([i915#553] / [i915#725]) ->
[DMESG-FAIL][20] ([i915#725])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-hsw-4770r/igt@i915_selftest@live_blt.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +6 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7581/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15814/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
[i915#116]: https://gitlab.freedesktop.org/drm/intel/issues/116
[i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/28
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, 17 Dec 2019, Andy Shevchenko wrote:
> On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote:
>> On 17/12/2019 06:37, Randy Dunlap wrote:
>> > On 12/16/19 9:42 PM, Sam Ravnborg wrote:
>> >> On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
>> >>> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
>
>> >>> on x86_64:
>> >>>
>> >>> ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight':
>> >>> (.text+0x2ee): undefined reference to `devm_of_find_backlight'
>> >>>
>> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>> >>> `intel_backlight_device_register':
>> >>> intel_panel.c:(.text+0x593e): undefined reference to
>> >>> `backlight_device_register'
>> >>> ld: drivers/gpu/drm/i915/display/intel_panel.o: in function
>> >>> `intel_backlight_device_unregister':
>> >>> intel_panel.c:(.text+0x5a04): undefined reference to
>> >>> `backlight_device_unregister'
>> >>>
>> >>> CONFIG_DRM_PANEL=y
>> >>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
>> >>> CONFIG_DRM_I915=y
>> >>>
>> >>> Full randconfig file is attached.
>> >>
>> >> Can you please verify if you have:
>> >> 907aa265fde6589b8059dc51649c6d1f49ade2f3
>> >> ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
>> >>
>> >> This commit is supposed to fix it.
>> >>
>> >> Sam
>> >>
>> >
>> > Hi Sam,
>> > I don't have the linux-next.git tree so I can't check that.
>> > I just built whatever is in linux-next of 20191216.
>> >
>>
>> 907aa265fde6589b8059dc51649c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
>> drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
>> error above is for backlight_device_register().
>>
>> From what I can tell, that commit is actually the cause of the error -
>> now intel_backlight_device_register() is being included in the kernel
>> even though it calls backlight_device_register() which is in a module.
>> Of course it also fixed the original error, so reverting it isn't any
>> use.
>>
>> The below Kconfig change fixes the build for me, but I've no idea
>> whether this is the correct fix.
>
> I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/.
> It fixes issue for me.
As discussed off-line, this will allow silently building and linking a
configuration that's actually broken. (No backlight support despite
expectations.)
IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all
over the place, while we should "depends on" it. Everything else is just
duct tape that allows configurations where built-in code calls backlight
symbols in modules. It used to be more about an interaction with ACPI,
now we've added DRM_PANEL to the mix.
I've proposed a fix five years ago [1]. That's what it takes to fix
these recurring failures for good. I'm not really all that interested in
the whack-a-mole with the hacks.
BR,
Jani.
[1]
http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com
--
Jani Nikula, Intel Open Source Graphics Center
___
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: Fix vGPU kernel context kmemleak
== Series Details ==
Series: drm/i915: Fix vGPU kernel context kmemleak
URL : https://patchwork.freedesktop.org/series/71027/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15807_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_15807_full:
### Piglit changes ###
Possible regressions
* spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-1-int-2drect (NEW):
- {pig-hsw-4770r}:NOTRUN -> [FAIL][1] +67 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15807/pig-hsw-4770r/spec@arb_gpu_shader5@texturegatheroffs...@vs-rgba-1-int-2drect.html
New tests
-
New tests have been introduced between CI_DRM_7578_full and
Patchwork_15807_full:
### New Piglit tests (68) ###
* spec@arb_gpu_shader5@texturegather@vs-r-0-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [1.58] s
* spec@arb_gpu_shader5@texturegather@vs-r-0-uint-2darray:
- Statuses : 1 fail(s)
- Exec time: [1.70] s
* spec@arb_gpu_shader5@texturegather@vs-r-0-uint-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.61] s
* spec@arb_gpu_shader5@texturegather@vs-rg-0-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [1.69] s
* spec@arb_gpu_shader5@texturegather@vs-rg-0-uint-2darray:
- Statuses : 1 fail(s)
- Exec time: [1.77] s
* spec@arb_gpu_shader5@texturegather@vs-rg-0-uint-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.42] s
* spec@arb_gpu_shader5@texturegather@vs-rg-0-uint-cube:
- Statuses : 1 fail(s)
- Exec time: [1.73] s
* spec@arb_gpu_shader5@texturegather@vs-rg-1-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [1.79] s
* spec@arb_gpu_shader5@texturegather@vs-rg-1-uint-2darray:
- Statuses : 1 fail(s)
- Exec time: [1.80] s
* spec@arb_gpu_shader5@texturegather@vs-rg-1-uint-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.53] s
* spec@arb_gpu_shader5@texturegather@vs-rg-1-uint-cube:
- Statuses : 1 fail(s)
- Exec time: [1.63] s
* spec@arb_gpu_shader5@texturegather@vs-rg-1-uint-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.77] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-0-int-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.74] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-0-int-cube:
- Statuses : 1 fail(s)
- Exec time: [1.76] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-0-int-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.62] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-1-int-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.70] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-1-int-cube:
- Statuses : 1 fail(s)
- Exec time: [1.89] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-1-int-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.72] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-2-int-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.70] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-2-int-cube:
- Statuses : 1 fail(s)
- Exec time: [1.69] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-2-int-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.73] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-3-int-2drect:
- Statuses : 1 fail(s)
- Exec time: [1.78] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-3-int-cube:
- Statuses : 1 fail(s)
- Exec time: [1.59] s
* spec@arb_gpu_shader5@texturegather@vs-rgba-3-int-cubearray:
- Statuses : 1 fail(s)
- Exec time: [1.67] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-r-0-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [6.97] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-r-0-uint-2drect:
- Statuses : 1 fail(s)
- Exec time: [6.96] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-r-0-uint-2drect-const:
- Statuses : 1 fail(s)
- Exec time: [7.07] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rg-0-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [7.06] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rg-0-uint-2d-const:
- Statuses : 1 fail(s)
- Exec time: [7.27] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rg-1-uint-2d:
- Statuses : 1 fail(s)
- Exec time: [6.98] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rg-1-uint-2d-const:
- Statuses : 1 fail(s)
- Exec time: [7.22] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-int-2darray:
- Statuses : 1 fail(s)
- Exec time: [10.29] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-int-2darray-const:
- Statuses : 1 fail(s)
- Exec time: [10.94] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-int-2drect:
- Statuses : 1 fail(s)
- Exec time: [7.01] s
* spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-int-2drect-const:
- Statuses : 1 fai
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote: > On Tue, 17 Dec 2019, Andy Shevchenko wrote: > > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. > > It fixes issue for me. > > As discussed off-line, this will allow silently building and linking a > configuration that's actually broken. (No backlight support despite > expectations.) In my case I have deliberately compile backlight as a module to be used exclusively with backlight-gpio which has nothing to do with i915. I dunno if backlight is a MUST dependency for i915. >From my perspective the original commit, with all good that it provides, should not break previously working configurations. Though we might argue if my "working" kernel configuration had been broken in the first place... Just my 2 cents, though. > IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all > over the place, while we should "depends on" it. Everything else is just > duct tape that allows configurations where built-in code calls backlight > symbols in modules. It used to be more about an interaction with ACPI, > now we've added DRM_PANEL to the mix. > > I've proposed a fix five years ago [1]. That's what it takes to fix > these recurring failures for good. I'm not really all that interested in > the whack-a-mole with the hacks. Agree with this. The root cause must be fixed once and for all. I guess it should be a logical continuation of Sam's series. > [1] > http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Dec 16 (drm_panel & intel_panel)
On Tue, 17 Dec 2019, Andy Shevchenko wrote: > On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula > wrote: >> On Tue, 17 Dec 2019, Andy Shevchenko wrote: >> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote: > >> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/. >> > It fixes issue for me. >> >> As discussed off-line, this will allow silently building and linking a >> configuration that's actually broken. (No backlight support despite >> expectations.) > > In my case I have deliberately compile backlight as a module to be > used exclusively with backlight-gpio which has nothing to do with > i915. I dunno if backlight is a MUST dependency for i915. It's not a required dependency, all combinations of i915 and backlight are fine, *except* i915=y, backlight=m. This can be achieved with: depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n BR, Jani. > > From my perspective the original commit, with all good that it > provides, should not break previously working configurations. Though > we might argue if my "working" kernel configuration had been broken in > the first place... > > Just my 2 cents, though. > >> IMO deep down the problem is that we "select" BACKLIGHT_CLASS_DEVICE all >> over the place, while we should "depends on" it. Everything else is just >> duct tape that allows configurations where built-in code calls backlight >> symbols in modules. It used to be more about an interaction with ACPI, >> now we've added DRM_PANEL to the mix. >> >> I've proposed a fix five years ago [1]. That's what it takes to fix >> these recurring failures for good. I'm not really all that interested in >> the whack-a-mole with the hacks. > > Agree with this. The root cause must be fixed once and for all. > I guess it should be a logical continuation of Sam's series. > >> [1] >> http://lore.kernel.org/r/1413580403-16225-1-git-send-email-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/print: introduce new struct drm_device based logging macros
Hi Jani. Will you type a todo entry as requested by Daniel? > Pushed this one patch, thanks for the reviews and acks. The rest could > still use review. ;) Will take a look again later tonight. I recall from last time I looked they were fine but I just never sent anything to the ML. Sam ___ 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/gt: Avoid multi-LRI on Sandybridge
== Series Details == Series: drm/i915/gt: Avoid multi-LRI on Sandybridge URL : https://patchwork.freedesktop.org/series/71029/ State : success == Summary == CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15808_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15808_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-kbl4/igt@gem_ctx_isolat...@rcs0-s3.html - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl1/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-skl6/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_isolation@vcs1-dirty-switch: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-switch.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-iclb6/igt@gem_ctx_isolat...@vcs1-dirty-switch.html * igt@gem_ctx_persistence@bcs0-mixed-process: - shard-apl: [PASS][7] -> [FAIL][8] ([i915#679]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-apl8/igt@gem_ctx_persiste...@bcs0-mixed-process.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-apl7/igt@gem_ctx_persiste...@bcs0-mixed-process.html * igt@gem_ctx_persistence@vcs0-mixed-process: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#679]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb4/igt@gem_ctx_persiste...@vcs0-mixed-process.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb7/igt@gem_ctx_persiste...@vcs0-mixed-process.html * igt@gem_exec_async@concurrent-writes-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-iclb6/igt@gem_exec_as...@concurrent-writes-bsd1.html * igt@gem_exec_create@madvise: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([i915#435]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb2/igt@gem_exec_cre...@madvise.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb6/igt@gem_exec_cre...@madvise.html * igt@gem_exec_gttfill@basic: - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([fdo#111593]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@gem_exec_gttf...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb4/igt@gem_exec_gttf...@basic.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd1: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111606] / [fdo#111677]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb8/igt@gem_exec_sched...@preempt-queue-chain-bsd1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-bsd1.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-tglb: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb4/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb3/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-apl7/igt@gem_soft...@noreloc-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-apl1/igt@gem_soft...@noreloc-s3.html * igt@gem_sync@basic-store-all: - shard-tglb: [PASS][25] -> [INCOMPLETE][26] ([i915#472]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb9/igt@gem_s...@basic-store-all.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15808/shard-tglb6/igt@
[Intel-gfx] [PATCH] drm/i915: Fix pid leak with banned clients
From: Tvrtko Ursulin
Get_pid_task() needs to be paired with a put_pid or we leak a pid
reference every time a banned client tries to create a context.
Signed-off-by: Tvrtko Ursulin
Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 46b4d1d643f8..eace1607ceb2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2193,9 +2193,11 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
ext_data.fpriv = file->driver_priv;
if (client_is_banned(ext_data.fpriv)) {
+ struct pid *pid = get_task_pid(current, PIDTYPE_PID);
+
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm,
- pid_nr(get_task_pid(current, PIDTYPE_PID)));
+ current->comm, pid_nr(pid));
+ put_pid(pid);
return -EIO;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix pid leak with banned clients
Quoting Tvrtko Ursulin (2019-12-17 16:18:14)
> From: Tvrtko Ursulin
>
> Get_pid_task() needs to be paired with a put_pid or we leak a pid
> reference every time a banned client tries to create a context.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 46b4d1d643f8..eace1607ceb2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -2193,9 +2193,11 @@ int i915_gem_context_create_ioctl(struct drm_device
> *dev, void *data,
>
> ext_data.fpriv = file->driver_priv;
> if (client_is_banned(ext_data.fpriv)) {
> + struct pid *pid = get_task_pid(current, PIDTYPE_PID);
> +
> DRM_DEBUG("client %s[%d] banned from creating ctx\n",
> - current->comm,
> - pid_nr(get_task_pid(current, PIDTYPE_PID)));
> + current->comm, pid_nr(pid));
Or, going out on a limb here, task_pid_nr(current)).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 06/11] drm/i915/display: Share intel_connector_needs_modeset()
On Mon, 2019-12-16 at 15:52 -0800, Lucas De Marchi wrote:
> On Mon, Dec 16, 2019 at 02:07:37PM -0800, Jose Souza wrote:
> > intel_connector_needs_modeset() will be used outside of
> > intel_display.c in a future patch so it would only be necessary to
> > remove the state and add the prototype to the header file.
> >
> > But while at it, I simplified the arguments and moved it to a
> > better
> > place intel_atomic.c.
> >
> > That allowed us to convert the whole
> > intel_encoders_update_prepare/complete to intel types too.
> >
> > No behavior changes intended here.
> >
> > v3:
> > - removed digital from exported version of
> > intel_connector_needs_modeset
> > - rollback connector to drm type
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic.c | 18 +++
> > drivers/gpu/drm/i915/display/intel_atomic.h | 2 +
> > drivers/gpu/drm/i915/display/intel_display.c | 53 ++---
> > ---
> > 3 files changed, 36 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index fd0026fc3618..b7dda18b6f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -174,6 +174,24 @@ intel_digital_connector_duplicate_state(struct
> > drm_connector *connector)
> > return &state->base;
> > }
> >
> > +/**
> > + * intel_connector_needs_modeset - check if connector needs a
> > modeset
> > + */
> > +bool
> > +intel_connector_needs_modeset(struct intel_atomic_state *state,
> > + struct drm_connector *connector)
> > +{
> > + const struct drm_connector_state *old_conn_state,
> > *new_conn_state;
> > +
> > + old_conn_state = drm_atomic_get_old_connector_state(&state-
> > >base, connector);
> > + new_conn_state = drm_atomic_get_new_connector_state(&state-
> > >base, connector);
> > +
> > + return old_conn_state->crtc != new_conn_state->crtc ||
> > + (new_conn_state->crtc &&
> > + drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_s
> > tate(&state->base,
> > +
> > new_conn_state->crtc)));
> > +}
> > +
> > /**
> > * intel_crtc_duplicate_state - duplicate crtc state
> > * @crtc: drm crtc
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> > b/drivers/gpu/drm/i915/display/intel_atomic.h
> > index 7b49623419ba..a7d1a8576c48 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> > @@ -32,6 +32,8 @@ int intel_digital_connector_atomic_check(struct
> > drm_connector *conn,
> > struct drm_atomic_state
> > *state);
> > struct drm_connector_state *
> > intel_digital_connector_duplicate_state(struct drm_connector
> > *connector);
> > +bool intel_connector_needs_modeset(struct intel_atomic_state
> > *state,
> > + struct drm_connector *connector);
> >
> > struct drm_crtc_state *intel_crtc_duplicate_state(struct drm_crtc
> > *crtc);
> > void intel_crtc_destroy_state(struct drm_crtc *crtc,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8e3e05cfcb27..0ee2e86a8826 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6185,71 +6185,50 @@ intel_connector_primary_encoder(struct
> > intel_connector *connector)
> > return encoder;
> > }
> >
> > -static bool
> > -intel_connector_needs_modeset(struct intel_atomic_state *state,
> > - const struct drm_connector_state
> > *old_conn_state,
> > - const struct drm_connector_state
> > *new_conn_state)
> > -{
> > - struct intel_crtc *old_crtc = old_conn_state->crtc ?
> > - to_intel_crtc(old_conn_state-
> > >crtc) : NULL;
> > - struct intel_crtc *new_crtc = new_conn_state->crtc ?
> > - to_intel_crtc(new_conn_state-
> > >crtc) : NULL;
> > -
> > - return new_crtc != old_crtc ||
> > - (new_crtc &&
> > - needs_modeset(intel_atomic_get_new_crtc_state(state,
> > new_crtc)));
> > -}
> > -
> > static void intel_encoders_update_prepare(struct intel_atomic_state
> > *state)
> > {
> > - struct drm_connector_state *old_conn_state;
> > - struct drm_connector_state *new_conn_state;
> > - struct drm_connector *conn;
> > + struct intel_digital_connector_state *new_connector_state;
>
> what's up with this fight new_conn_state vs new_connector_state? It'
> s
> the first time in the driver we would actually drive such conversion.
> I'd say to just keep the old name.
Ville asked me to rename conn to connector in the new functions that
I'm adding as this function was heavily modified I did the same here.
I will rollback if agreed by you
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Eliminate the trylock for reading a timeline's hwsp
On 16/12/2019 17:52, Chris Wilson wrote:
As we stash a pointer to the HWSP cacheline on the request, when reading
it we only need confirm that the cacheline is still valid by checking
that the request and timeline are still intact.
v2: Protect hwsp_cachline with RCU
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 59 +++-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_request.h | 5 +-
3 files changed, 30 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index d71aafb66d6e..6da3f4af9614 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -25,10 +25,14 @@ struct intel_timeline_hwsp {
struct intel_timeline_cacheline {
struct i915_active active;
+
struct intel_timeline_hwsp *hwsp;
void *vaddr;
#define CACHELINE_BITS 6
#define CACHELINE_FREE CACHELINE_BITS
+ u32 offset;
+
+ struct rcu_head rcu;
};
static struct i915_vma *__hwsp_alloc(struct intel_gt *gt)
@@ -133,7 +137,7 @@ static void __idle_cacheline_free(struct
intel_timeline_cacheline *cl)
__idle_hwsp_free(cl->hwsp, ptr_unmask_bits(cl->vaddr, CACHELINE_BITS));
i915_active_fini(&cl->active);
- kfree(cl);
+ kfree_rcu(cl, rcu);
}
__i915_active_call
@@ -177,6 +181,8 @@ cacheline_alloc(struct intel_timeline_hwsp *hwsp, unsigned
int cacheline)
i915_vma_get(hwsp->vma);
cl->hwsp = hwsp;
cl->vaddr = page_pack_bits(vaddr, cacheline);
+ cl->offset =
+ i915_ggtt_offset(cl->hwsp->vma) + cacheline * CACHELINE_BYTES;
i915_active_init(&cl->active, __cacheline_active, __cacheline_retire);
@@ -514,46 +520,33 @@ int intel_timeline_read_hwsp(struct i915_request *from,
struct i915_request *to,
u32 *hwsp)
{
- struct intel_timeline *tl;
+ struct intel_timeline_cacheline *cl;
int err;
+ GEM_BUG_ON(!rcu_access_pointer(from->hwsp_cacheline));
+
rcu_read_lock();
- tl = rcu_dereference(from->timeline);
- if (i915_request_completed(from) || !kref_get_unless_zero(&tl->kref))
- tl = NULL;
+ cl = rcu_dereference(from->hwsp_cacheline);
+ if (unlikely(!i915_active_acquire_if_busy(&cl->active)))
+ goto unlock; /* seqno wrapped and completed! */
+ if (unlikely(i915_request_completed(from)))
+ goto release;
rcu_read_unlock();
- if (!tl) /* already completed */
- return 1;
-
- GEM_BUG_ON(rcu_access_pointer(to->timeline) == tl);
-
- err = -EAGAIN;
- if (mutex_trylock(&tl->mutex)) {
- struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
-
- if (i915_request_completed(from)) {
- err = 1;
- goto unlock;
- }
- err = cacheline_ref(cl, to);
- if (err)
- goto unlock;
+ err = cacheline_ref(cl, to);
+ if (err)
+ goto out;
- if (likely(cl == tl->hwsp_cacheline)) {
- *hwsp = tl->hwsp_offset;
- } else { /* across a seqno wrap, recover the original offset */
- *hwsp = i915_ggtt_offset(cl->hwsp->vma) +
- ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) *
- CACHELINE_BYTES;
- }
+ *hwsp = cl->offset;
+out:
+ i915_active_release(&cl->active);
+ return err;
+release:
+ i915_active_release(&cl->active);
unlock:
- mutex_unlock(&tl->mutex);
- }
- intel_timeline_put(tl);
-
- return err;
+ rcu_read_unlock();
+ return 1;
}
void intel_timeline_unpin(struct intel_timeline *tl)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a59b803aef92..269470d3527a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -655,9 +655,9 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->execution_mask = ce->engine->mask;
rq->flags = 0;
- rcu_assign_pointer(rq->timeline, tl);
+ RCU_INIT_POINTER(rq->timeline, tl);
+ RCU_INIT_POINTER(rq->hwsp_cacheline, tl->hwsp_cacheline);
rq->hwsp_seqno = tl->hwsp_seqno;
- rq->hwsp_cacheline = tl->hwsp_cacheline;
rq->rcustate = get_state_synchronize_rcu(); /* acts as smp_mb() */
diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
index a561b8efe869..aa38290eea3d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -30,6 +30,7 @@
#include "gt/intel_context_types.h"
#include "gt/intel_engine_types.h"
+#include "gt/int
Re: [Intel-gfx] [PATCH v12 1/3] drm/i915: Refactor intel_can_enable_sagv
On Fri, Dec 13, 2019 at 04:12:29PM +0200, Stanislav Lisovskiy wrote:
> Currently intel_can_enable_sagv function contains
> a mix of workarounds for different platforms
> some of them are not valid for gens >= 11 already,
> so lets split it into separate functions.
>
> v2:
> - Rework watermark calculation algorithm to
> attempt to calculate Level 0 watermark
> with added sagv block time latency and
> check if it fits in DBuf in order to
> determine if SAGV can be enabled already
> at this stage, just as BSpec 49325 states.
> if that fails rollback to usual Level 0
> latency and disable SAGV.
> - Remove unneeded tabs(James Ausmus)
>
> v3: Rebased the patch
>
> v4: - Added back interlaced check for Gen12 and
> added separate function for TGL SAGV check
> (thanks to James Ausmus for spotting)
> - Removed unneeded gen check
> - Extracted Gen12 SAGV decision making code
> to a separate function from skl_compute_wm
>
> v5: - Added SAGV global state to dev_priv, because
> we need to track all pipes, not only those
> in atomic state. Each pipe has now correspondent
> bit mask reflecting, whether it can tolerate
> SAGV or not(thanks to Ville Syrjala for suggestions).
> - Now using active flag instead of enable in crc
> usage check.
>
> v6: - Fixed rebase conflicts
>
> v7: - kms_cursor_legacy seems to get broken because of multiple memcpy
> calls when copying level 0 water marks for enabled SAGV, to
> fix this now simply using that field right away, without copying,
> for that introduced a new wm_level accessor which decides which
> wm_level to return based on SAGV state.
>
> v8: - Protect crtc_sagv_mask same way as we do for other global state
> changes: i.e check if changes are needed, then grab all crtc locks
> to serialize the changes(Ville Syrjälä)
> - Add crtc_sagv_mask caching in order to avoid needless recalculations
> (Matthew Roper)
> - Put back Gen12 SAGV switch in order to get it enabled in separate
> patch(Matthew Roper)
> - Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper)
> - Check if there are no active pipes in intel_can_enable_sagv
> instead of platform specific functions(Matthew Roper), same
> for intel_has_sagv check.
>
> Signed-off-by: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Cc: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 +-
> .../drm/i915/display/intel_display_types.h| 9 +
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/intel_pm.c | 416 +++---
> drivers/gpu/drm/i915/intel_pm.h | 1 +
> 5 files changed, 393 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0f37f1d2026d..d58c70fbc08e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13379,7 +13379,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
> /* Watermarks */
> for (level = 0; level <= max_level; level++) {
> if (skl_wm_level_equals(&hw_plane_wm->wm[level],
> - &sw_plane_wm->wm[level]))
> + &sw_plane_wm->wm[level]) ||
> +(skl_wm_level_equals(&hw_plane_wm->wm[level],
> + &sw_plane_wm->sagv_wm0) &&
> +(level == 0)))
> continue;
>
> DRM_ERROR("mismatch in WM pipe %c plane %d level %d
> (expected e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
> @@ -13431,7 +13434,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
> /* Watermarks */
> for (level = 0; level <= max_level; level++) {
> if (skl_wm_level_equals(&hw_plane_wm->wm[level],
> - &sw_plane_wm->wm[level]))
> + &sw_plane_wm->wm[level]) ||
> +(skl_wm_level_equals(&hw_plane_wm->wm[level],
> + &sw_plane_wm->sagv_wm0) &&
> +(level == 0)))
> continue;
>
> DRM_ERROR("mismatch in WM pipe %c cursor level %d
> (expected e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
> @@ -14808,6 +14814,8 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> dev_priv->display.optimize_watermarks(state, crtc);
> }
>
> + dev_priv->crtc_sagv_mask = state->crtc_sagv_mask;
> +
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> intel_post_plane_update(state, c
[Intel-gfx] [PATCH v2] drm/i915: Fix pid leak with banned clients
From: Tvrtko Ursulin
Get_pid_task() needs to be paired with a put_pid or we leak a pid
reference every time a banned client tries to create a context.
v2:
* task_pid_nr helper exists! (Chris)
Signed-off-by: Tvrtko Ursulin
Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 46b4d1d643f8..6618c0c6506c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2194,8 +2194,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
ext_data.fpriv = file->driver_priv;
if (client_is_banned(ext_data.fpriv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
- current->comm,
- pid_nr(get_task_pid(current, PIDTYPE_PID)));
+ current->comm, task_pid_nr(current));
return -EIO;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix pid leak with banned clients
Quoting Tvrtko Ursulin (2019-12-17 17:09:33)
> From: Tvrtko Ursulin
>
> Get_pid_task() needs to be paired with a put_pid or we leak a pid
> reference every time a banned client tries to create a context.
>
> v2:
> * task_pid_nr helper exists! (Chris)
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: b083a0870c79 ("drm/i915: Add per client max context ban limit")
> Cc: Chris Wilson
> Cc: Mika Kuoppala
As used by others, so must be safe!
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Expose list of clients in sysfs
On 16/12/2019 12:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0781b6326b8c..9fcbcb6d6f76 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -224,6 +224,20 @@ struct drm_i915_file_private {
/** ban_score: Accumulated score of all ctx bans and fast hangs. */
atomic_t ban_score;
unsigned long hang_timestamp;
+
+ struct i915_drm_client {
+ unsigned int id;
+
+ struct pid *pid;
+ char *name;
Hmm. Should we scrap i915_gem_context.pid and just use the client.pid?
Or maybe leave as it so I don't have to worry about ctx vs client
lifetime. In other words places where we access ctx->pid and the client
is maybe long gone. I don't want to ref count clients, or maybe I do..
hmm.. keeping GPU load of a client which exited and left work running
visible?
Regards,
Tvrtko
+
+ struct kobject *root;
+
+ struct {
+ struct device_attribute pid;
+ struct device_attribute name;
+ } attr;
+ } client;
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Expose list of clients in sysfs
Quoting Tvrtko Ursulin (2019-12-17 17:21:28)
>
> On 16/12/2019 12:53, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-12-16 12:07:01)
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 0781b6326b8c..9fcbcb6d6f76 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -224,6 +224,20 @@ struct drm_i915_file_private {
> >> /** ban_score: Accumulated score of all ctx bans and fast hangs.
> >> */
> >> atomic_t ban_score;
> >> unsigned long hang_timestamp;
> >> +
> >> + struct i915_drm_client {
> >> + unsigned int id;
> >> +
> >> + struct pid *pid;
> >> + char *name;
> >
> > Hmm. Should we scrap i915_gem_context.pid and just use the client.pid?
>
> Or maybe leave as it so I don't have to worry about ctx vs client
> lifetime. In other words places where we access ctx->pid and the client
> is maybe long gone. I don't want to ref count clients, or maybe I do..
> hmm.. keeping GPU load of a client which exited and left work running
> visible?
Yeah. If we don't and all the GPU time is being hogged by zombies, users
of the interface will not be impressed they can't identify those. Next
up, kill(client_id, SIGKILL).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move stuff from haswell_crtc_disable() into encoder .post_disable()
On Fri, 2019-12-13 at 21:52 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move all of haswell_crtc_disable() into the encoder
> .post_disable() hooks. Now we're left with just
> calling the .disable() and .post_disable() hooks
> back to back.
>
> I chose to move the code into the .post_disable() hook instead
> of the .enable() hook as most of the sequence is currently
s/.enable()/.disable()
> implemented in the .post_enable() hook.
>
s/post_enable()/.post_disable()
> We should collapse it all down to just one hook and then the
> encoders can drive the modeset sequence fully. But that may
> need some further refactoring as we currently call the
> ddi .post_disable() hook from mst code and we can't just
> replace that with a call to the ddi .disable() hook.
>
> Should also follow up with similar treatment for the enable
> sequence but let's start here where it's easier.
Pretty good change, removed the feature checks from
haswell_crtc_disable() and moved to the right place.
With this changes I can do what you asked and move the code in
intel_dp_mst_post_trans_disabled() to intel_mst_post_disable_dp().
With the typos above fixed:
Reviewed-by: José Roberto de Souza
Thanks
>
> Cc: José Roberto de Souza
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 12 +
> drivers/gpu/drm/i915/display/intel_crt.c | 8 +++
> drivers/gpu/drm/i915/display/intel_ddi.c | 35
> drivers/gpu/drm/i915/display/intel_display.c | 57 +++---
> --
> drivers/gpu/drm/i915/display/intel_display.h | 4 ++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 11
> drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++-
> 7 files changed, 86 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 03aa92d317a2..006b1a297e6f 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1251,6 +1251,17 @@ static void gen11_dsi_disable(struct
> intel_encoder *encoder,
> gen11_dsi_disable_io_power(encoder);
> }
>
> +static void gen11_dsi_post_disable(struct intel_encoder *encoder,
> +const struct intel_crtc_state
> *old_crtc_state,
> +const struct drm_connector_state
> *old_conn_state)
> +{
> + intel_crtc_vblank_off(old_crtc_state);
> +
> + intel_dsc_disable(old_crtc_state);
> +
> + skylake_scaler_disable(old_crtc_state);
> +}
> +
> static enum drm_mode_status gen11_dsi_mode_valid(struct
> drm_connector *connector,
>struct
> drm_display_mode *mode)
> {
> @@ -1697,6 +1708,7 @@ void icl_dsi_init(struct drm_i915_private
> *dev_priv)
> encoder->pre_pll_enable = gen11_dsi_pre_pll_enable;
> encoder->pre_enable = gen11_dsi_pre_enable;
> encoder->disable = gen11_dsi_disable;
> + encoder->post_disable = gen11_dsi_post_disable;
> encoder->port = port;
> encoder->get_config = gen11_dsi_get_config;
> encoder->update_pipe = intel_panel_update_backlight;
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 50624b8f064d..b2b1336ecdb6 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -241,6 +241,14 @@ static void hsw_post_disable_crt(struct
> intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> + intel_crtc_vblank_off(old_crtc_state);
> +
> + intel_disable_pipe(old_crtc_state);
> +
> + intel_ddi_disable_transcoder_func(old_crtc_state);
> +
> + ironlake_pfit_disable(old_crtc_state);
> +
> intel_ddi_disable_pipe_clock(old_crtc_state);
>
> pch_post_disable_crt(encoder, old_crtc_state, old_conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index cac0be47e500..fa40ba7cbcad 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3851,6 +3851,25 @@ static void intel_ddi_post_disable_hdmi(struct
> intel_encoder *encoder,
> intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> }
>
> +static void icl_disable_transcoder_port_sync(const struct
> intel_crtc_state *old_crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
> >uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + i915_reg_t reg;
> + u32 trans_ddi_func_ctl2_val;
> +
> + if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
> + return;
> +
> + DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave
> Transcoder %s\n",
> + transcoder_name(old_crtc_state->cpu_transcoder));
> +
> + reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
> + trans_ddi_func_
Re: [Intel-gfx] [PATCH v3 06/11] drm/i915/display: Share intel_connector_needs_modeset()
On Tue, Dec 17, 2019 at 08:39:15AM -0800, Jose Souza wrote:
On Mon, 2019-12-16 at 15:52 -0800, Lucas De Marchi wrote:
On Mon, Dec 16, 2019 at 02:07:37PM -0800, Jose Souza wrote:
> intel_connector_needs_modeset() will be used outside of
> intel_display.c in a future patch so it would only be necessary to
> remove the state and add the prototype to the header file.
>
> But while at it, I simplified the arguments and moved it to a
> better
> place intel_atomic.c.
>
> That allowed us to convert the whole
> intel_encoders_update_prepare/complete to intel types too.
>
> No behavior changes intended here.
>
> v3:
> - removed digital from exported version of
> intel_connector_needs_modeset
> - rollback connector to drm type
>
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 18 +++
> drivers/gpu/drm/i915/display/intel_atomic.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 53 ++---
> ---
> 3 files changed, 36 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index fd0026fc3618..b7dda18b6f29 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -174,6 +174,24 @@ intel_digital_connector_duplicate_state(struct
> drm_connector *connector)
>return &state->base;
> }
>
> +/**
> + * intel_connector_needs_modeset - check if connector needs a
> modeset
> + */
> +bool
> +intel_connector_needs_modeset(struct intel_atomic_state *state,
> +struct drm_connector *connector)
> +{
> + const struct drm_connector_state *old_conn_state,
> *new_conn_state;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(&state-
> >base, connector);
> + new_conn_state = drm_atomic_get_new_connector_state(&state-
> >base, connector);
> +
> + return old_conn_state->crtc != new_conn_state->crtc ||
> + (new_conn_state->crtc &&
> + drm_atomic_crtc_needs_modeset(drm_atomic_get_new_crtc_s
> tate(&state->base,
> +
> new_conn_state->crtc)));
> +}
> +
> /**
> * intel_crtc_duplicate_state - duplicate crtc state
> * @crtc: drm crtc
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> b/drivers/gpu/drm/i915/display/intel_atomic.h
> index 7b49623419ba..a7d1a8576c48 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> @@ -32,6 +32,8 @@ int intel_digital_connector_atomic_check(struct
> drm_connector *conn,
> struct drm_atomic_state
> *state);
> struct drm_connector_state *
> intel_digital_connector_duplicate_state(struct drm_connector
> *connector);
> +bool intel_connector_needs_modeset(struct intel_atomic_state
> *state,
> + struct drm_connector *connector);
>
> struct drm_crtc_state *intel_crtc_duplicate_state(struct drm_crtc
> *crtc);
> void intel_crtc_destroy_state(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8e3e05cfcb27..0ee2e86a8826 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6185,71 +6185,50 @@ intel_connector_primary_encoder(struct
> intel_connector *connector)
>return encoder;
> }
>
> -static bool
> -intel_connector_needs_modeset(struct intel_atomic_state *state,
> -const struct drm_connector_state
> *old_conn_state,
> -const struct drm_connector_state
> *new_conn_state)
> -{
> - struct intel_crtc *old_crtc = old_conn_state->crtc ?
> -to_intel_crtc(old_conn_state-
> >crtc) : NULL;
> - struct intel_crtc *new_crtc = new_conn_state->crtc ?
> -to_intel_crtc(new_conn_state-
> >crtc) : NULL;
> -
> - return new_crtc != old_crtc ||
> - (new_crtc &&
> - needs_modeset(intel_atomic_get_new_crtc_state(state,
> new_crtc)));
> -}
> -
> static void intel_encoders_update_prepare(struct intel_atomic_state
> *state)
> {
> - struct drm_connector_state *old_conn_state;
> - struct drm_connector_state *new_conn_state;
> - struct drm_connector *conn;
> + struct intel_digital_connector_state *new_connector_state;
what's up with this fight new_conn_state vs new_connector_state? It'
s
the first time in the driver we would actually drive such conversion.
I'd say to just keep the old name.
Ville asked me to rename conn to connector in the new functions that
I'm adding as this function was heavily modified I did the same here.
I will rollback if agreed by you and Ville(the ones helping with TGL
MST)
I think that was about conn -> connector, not *conn_state ->
*connector_state, wasn't it?
Lucas De Marchi
I'm not sure I like the conversion to use the connector rather tha
Re: [Intel-gfx] [PATCH v12 2/3] drm/i915: Restrict qgv points which don't have enough bandwidth.
On Fri, Dec 13, 2019 at 04:12:30PM +0200, 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.
>
> v4:
> - Minor code refactoring, fixed few typos(thanks to James Ausmus)
> - Change the naming of qgv point
> masking/unmasking functions(James Ausmus).
> - Simplify the masking/unmasking operation itself,
> as we don't need to mask only single point per request(James Ausmus)
> - Reject and stick to highest bandwidth point if SAGV
> can't be enabled(BSpec)
>
> v5:
> - Add new mailbox reply codes, which seems to happen during boot
> time for TGL and indicate that QGV setting is not yet available.
>
> v6:
> - Increase number of supported QGV points to be in sync with BSpec.
>
> v7: - Rebased and resolved conflict to fix build failure.
> - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus)
>
> v8: - Don't report an error if we can't restrict qgv points, as SAGV
> can be disabled by BIOS, which is completely legal. So don't
> make CI panic. Instead if we detect that there is only 1 QGV
> point accessible just analyze if we can fit the required bandwidth
> requirements, but no need in restricting.
>
> v9: - Fix wrong QGV transition if we have 0 planes and no SAGV
> simultaneously.
>
> v10: - Fix CDCLK corruption, because of global state getting serialized
>without modeset, which caused copying of non-calculated cdclk
>to be copied to dev_priv(thanks to Ville for the hint).
>
> v11: - Remove unneeded headers and spaces(Matthew Roper)
> - Remove unneeded intel_qgv_info qi struct from bw check and zero
>out the needed one(Matthew Roper)
> - Changed QGV error message to have more clear meaning(Matthew Roper)
> - Use state->modeset_set instead of any_ms(Matthew Roper)
> - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used
> - Keep using crtc_state->hw.active instead of .enable(Matthew Roper)
> - Moved unrelated changes to other patch(using latency as parameter
>for plane wm calculation, moved to SAGV refactoring patch)
>
> v12: - Fix rebase conflict with own temporary SAGV/QGV fix.
> - Remove unnecessary mask being zero check when unmasking
>qgv points as this is completely legal(Matt Roper)
> - Check if we are setting the same mask as already being set
>in hardware to prevent error from PCode.
> - Fix error message when restricting/unrestricting qgv points
>to "mask/unmask" which sounds more accurate(Matt Roper)
> - Move sagv status setting to icl_get_bw_info from atomic check
>as this should be calculated only once.(Matt Roper)
> - Edited comments for the case when we can't enable SAGV and
>use only 1 QGV point with highest bandwidth to be more
>understandable.(Matt Roper)
>
> Reviewed-by: James Ausmus
> Signed-off-by: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Cc: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 144 +-
> drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 87 ++-
> .../drm/i915/display/intel_display_types.h| 3 +
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_reg.h | 5 +
> drivers/gpu/drm/i915/intel_sideband.c | 27 +++-
> 7 files changed, 233 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index dcb66a33be9b..95d8d7dfa769 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -8,6 +8,9 @@
> #include "intel_bw.h"
> #include "intel_display_types.h"
> #include "intel_sideband.h"
> +#include "intel_atomic.h"
> +#include "intel_pm.h"
> +
>
> /* Parameters for Qclk Geyserville (QGV) */
> struct intel_qgv_point {
> @@ -113,6 +116,26 @@ static int icl_pcode_read_qgv_point_info(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> + u32 points_mask)
> +{
> + int ret;
> +
> + /* bspec says to keep retrying for at least 1 ms */
> + ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> + points_mask,
> +
Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support
On Sun, Dec 15, 2019 at 10:24 PM Niranjan Vishwanathapura <
niranjana.vishwanathap...@intel.com> wrote:
> On Sat, Dec 14, 2019 at 10:31:37AM +, Chris Wilson wrote:
> >Quoting Jason Ekstrand (2019-12-14 00:36:19)
> >> On Fri, Dec 13, 2019 at 5:24 PM Niranjan Vishwanathapura <
> >> niranjana.vishwanathap...@intel.com> wrote:
> >>
> >> On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote:
> >> >
> >> > +/**
> >> > + * struct drm_i915_gem_vm_bind
> >> > + *
> >> > + * Bind an object in a vm's page table.
> >> >
> >> > First off, this is something I've wanted for a while for
> Vulkan, it's
> >> just
> >> > never made its way high enough up the priority list. However,
> it's
> >> going
> >> > to have to come one way or another soon. I'm glad to see
> kernel API
> >> for
> >> > this being proposed.
> >> > I do, however, have a few high-level comments/questions about
> the API:
> >> >1. In order to be useful for sparse memory support, the API
> has to go
> >> the
> >> > other way around so that it binds a VA range to a range within
> the BO.
> >> It
> >> > also needs to be able to handle overlapping where two different
> VA
> >> ranges
> >> > may map to the same underlying bytes in the BO. This likely
> means that
> >> > unbind needs to also take a VA range and only unbind that range.
> >> >2. If this is going to be useful for managing GL's address
> space where
> >> we
> >> > have lots of BOs, we probably want it to take a list of ranges
> so we
> >> > aren't making one ioctl for each thing we want to bind.
> >>
> >> Hi Jason,
> >>
> >> Yah, some of these requirements came up.
> >>
> >>
> >> Yes, I have raised them every single time an API like this has come
> across my
> >> e-mail inbox for years and they continue to get ignored. Why are we
> landing an
> >> API that we know isn't the API we want especially when it's pretty
> obvious
> >> roughly what the API we want is? It may be less time in the short
> term, but
> >> long-term it means two ioctls and two implementations in i915, IGT
> tests for
> >> both code paths, and code in all UMDs to call one or the other
> depending on
> >> what kernel you're running on, and we have to maintain all that code
> going
> >> forward forever. Sure, that's a price we pay today for a variety of
> things but
> >> that's because they all seemed like the right thing at the time.
> Landing the
> >> wrong API when we know it's the wrong API seems foolish.
> >
> >Exactly. This is not even close to the uAPI we need. Reposting an RFC
> >without taking in the concerns last time (or the time before that, or
> >the time before that...) suggests that you aren't really requesting for
> >comments at all.
>
> Thanks Jason for detailed exlanation.
> Chris, all comments and guidance are much appreciated :)
>
> I haven't looked in detail, but my concern is that implementing
> partial object binding (offset, lenght) from vma down to [un]binding
> in ppgtt might be a lot of work to include in this SVM patch series.
> I believe we need the partial object binding in non-SVM scenario
> as well?
>
Yes, the Vulkan APIs require both partial binding and aliasing.
It may be worth pointing out that we're already doing some of this stuff
today, although in a rather backwards way. Our non-softpin model for
Vulkan uses a memfd which we then map in userspace and turn into a BO via
userptr. Due to the way we handle threading in the driver, we end up with
multiple BOs pointing to the same overlapping range in the memfd and hence
the same pages. That doesn't mean that everything in the path is already
set up for what you need but the VA -> page mappings should be. Also,
avoiding these kinds of shinanigans is exactly why we want a "real" kernel
API for this. :-)
> Ok, let me change the interface as below.
>
> struct drm_i915_gem_vm_bind_va
> {
> /** VA start to bind **/
> __u64 start;
>
> /** Offset in Object to bind for I915_GEM_VM_BIND_SVM_OBJ type **/
> __u64 offset;
>
> /** VA length to [un]bind **/
> __u64 length;
>
> /** Type of memory to [un]bind **/
> __u32 type;
> #define I915_GEM_VM_BIND_SVM_OBJ 0
> #define I915_GEM_VM_BIND_SVM_BUFFER 1
>
> /** Object handle to [un]bind for I915_GEM_VM_BIND_SVM_OBJ type **/
> __u32 handle;
>
> /** Flags **/
> __u32 flags;
> #define I915_GEM_VM_BIND_UNBIND (1 << 0)
> #define I915_GEM_VM_BIND_READONLY(1 << 1)
> }
>
> struct drm_i915_gem_vm_bind {
> /** vm to [un]bind **/
> __u32 vm_id;
>
> /** number of VAs to bind **/
> __u32 num_vas;
>
> /** Array of VAs to bind **/
> struct drm_i915_gem_vm_bind_va *bind_vas;
>
> /** User extensions **/
> __u64 extensions;
> };
>
> When synchronization control is added as ext
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev3)
== Series Details ==
Series: series starting with [1/5] drm: Add
__drm_atomic_helper_crtc_state_reset() & co. (rev3)
URL : https://patchwork.freedesktop.org/series/69129/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15797_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15797_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15797_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_15797_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@linear-16bpp-rotate-180:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@kms_big...@linear-16bpp-rotate-180.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-tglb3/igt@kms_big...@linear-16bpp-rotate-180.html
* igt@kms_frontbuffer_tracking@basic:
- shard-skl: [PASS][3] -> ([INCOMPLETE][4], [PASS][5])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl4/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl10/igt@kms_frontbuffer_track...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl7/igt@kms_frontbuffer_track...@basic.html
### Piglit changes ###
Possible regressions
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 128
3 (NEW):
- {pig-hsw-4770r}:NOTRUN -> [FAIL][6] +20 similar issues
[6]: None
New tests
-
New tests have been introduced between CI_DRM_7578_full and
Patchwork_15797_full:
### New Piglit tests (21) ###
* object namespace pollution@texture with glgetteximage-compressed:
- Statuses : 1 fail(s)
- Exec time: [0.13] s
* object namespace pollution@texture with gltexsubimage2d:
- Statuses : 1 fail(s)
- Exec time: [0.15] s
* spec@arb_gpu_shader5@texturegather@vs-rgb-0-float-cube:
- Statuses : 1 fail(s)
- Exec time: [1.83] s
* spec@arb_query_buffer_object@coherency:
- Statuses : 1 fail(s)
- Exec time: [0.22] s
* spec@arb_shader_image_load_store@host-mem-barrier:
- Statuses : 1 fail(s)
- Exec time: [5.66] s
* spec@arb_shader_image_load_store@layer:
- Statuses : 1 fail(s)
- Exec time: [0.31] s
* spec@arb_shader_image_load_store@level:
- Statuses : 1 fail(s)
- Exec time: [0.27] s
* spec@arb_shader_image_load_store@semantics:
- Statuses : 1 fail(s)
- Exec time: [0.53] s
* spec@arb_shader_image_load_store@unused:
- Statuses : 1 fail(s)
- Exec time: [0.16] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 1 8 128
2:
- Statuses : 1 fail(s)
- Exec time: [0.13] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 1 128
4:
- Statuses : 1 fail(s)
- Exec time: [0.08] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 8 128
2:
- Statuses : 1 fail(s)
- Exec time: [0.10] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 32 42 8 128
3:
- Statuses : 1 fail(s)
- Exec time: [0.12] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 128
3:
- Statuses : 1 fail(s)
- Exec time: [0.24] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 128
4:
- Statuses : 1 fail(s)
- Exec time: [0.27] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 1 8 128
8:
- Statuses : 1 fail(s)
- Exec time: [0.26] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1
128 8:
- Statuses : 1 fail(s)
- Exec time: [0.19] s
* spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader 512 42 1 8
8:
- Statuses : 1 fail(s)
- Exec time: [0.17] s
*
spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-position-double_dmat3-float_mat3x2_array3:
- Statuses : 1 fail(s)
- Exec time: [0.13] s
* spec@arb_vertex_type_2_10_10_10_rev@attribs:
- Statuses : 1 fail(s)
- Exec time: [0.95] s
*
spec@glsl-4.20@execution@vs_in@vs-input-int_ivec3_array3-position-double_dmat3_array2:
- Statuses : 1 fail(s)
- Exec time: [0.18] s
Known issues
Here are the changes found in Patchwork_15797_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vcs1-none:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-iclb1
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev3)
On Tue, 2019-12-17 at 18:10 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/5] drm: Add
> __drm_atomic_helper_crtc_state_reset() & co. (rev3)
> URL : https://patchwork.freedesktop.org/series/69129/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15797_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_15797_full absolutely
> need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the
> changes
> introduced in Patchwork_15797_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_15797_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_big_fb@linear-16bpp-rotate-180:
> - shard-tglb: [PASS][1] -> [DMESG-WARN][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@kms_big...@linear-16bpp-rotate-180.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-tglb3/igt@kms_big...@linear-16bpp-rotate-180.html
This one is not related to the changes in this series
>
> * igt@kms_frontbuffer_tracking@basic:
> - shard-skl: [PASS][3] -> ([INCOMPLETE][4], [PASS][5])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl4/igt@kms_frontbuffer_track...@basic.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl10/igt@kms_frontbuffer_track...@basic.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl7/igt@kms_frontbuffer_track...@basic.html
>
Getting AccessDenied when trying to access the error reports
>
>
> ### Piglit changes ###
>
> Possible regressions
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 1 8 128 3 (NEW):
> - {pig-hsw-4770r}:NOTRUN -> [FAIL][6] +20 similar issues
>[6]: None
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_7578_full and
> Patchwork_15797_full:
>
> ### New Piglit tests (21) ###
>
> * object namespace pollution@texture with glgetteximage-compressed:
> - Statuses : 1 fail(s)
> - Exec time: [0.13] s
>
> * object namespace pollution@texture with gltexsubimage2d:
> - Statuses : 1 fail(s)
> - Exec time: [0.15] s
>
> * spec@arb_gpu_shader5@texturegather@vs-rgb-0-float-cube:
> - Statuses : 1 fail(s)
> - Exec time: [1.83] s
>
> * spec@arb_query_buffer_object@coherency:
> - Statuses : 1 fail(s)
> - Exec time: [0.22] s
>
> * spec@arb_shader_image_load_store@host-mem-barrier:
> - Statuses : 1 fail(s)
> - Exec time: [5.66] s
>
> * spec@arb_shader_image_load_store@layer:
> - Statuses : 1 fail(s)
> - Exec time: [0.31] s
>
> * spec@arb_shader_image_load_store@level:
> - Statuses : 1 fail(s)
> - Exec time: [0.27] s
>
> * spec@arb_shader_image_load_store@semantics:
> - Statuses : 1 fail(s)
> - Exec time: [0.53] s
>
> * spec@arb_shader_image_load_store@unused:
> - Statuses : 1 fail(s)
> - Exec time: [0.16] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 32 1 8 128 2:
> - Statuses : 1 fail(s)
> - Exec time: [0.13] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 32 42 1 128 4:
> - Statuses : 1 fail(s)
> - Exec time: [0.08] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 32 42 8 128 2:
> - Statuses : 1 fail(s)
> - Exec time: [0.10] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 32 42 8 128 3:
> - Statuses : 1 fail(s)
> - Exec time: [0.12] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 1 8 128 3:
> - Statuses : 1 fail(s)
> - Exec time: [0.24] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 1 8 128 4:
> - Statuses : 1 fail(s)
> - Exec time: [0.27] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 1 8 128 8:
> - Statuses : 1 fail(s)
> - Exec time: [0.26] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 42 1 128 8:
> - Statuses : 1 fail(s)
> - Exec time: [0.19] s
>
> * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> 512 42 1 8 8:
> - Statuses : 1 fail(s)
> - Exec time: [0.17] s
>
> * spec@arb_vertex_attrib_64bit@execution@
> vs_in@vs-input-position-double_dmat3-float_mat3x2_array3:
> - Statuses : 1 fail(s)
> - Exec time: [0.13] s
>
> * spec@arb_vertex_type_2_10_10_10_rev@attribs:
> - Statuses : 1 fail(s)
> - Exec time: [0.95] s
>
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Force the state compute phase once to enable PSR (rev3)
== Series Details ==
Series: drm/i915/display: Force the state compute phase once to enable PSR
(rev3)
URL : https://patchwork.freedesktop.org/series/7/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7585 -> Patchwork_15815
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/index.html
Known issues
Here are the changes found in Patchwork_15815 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2: [DMESG-WARN][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][5] ([i915#592]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][7] ([i915#553] / [i915#725]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-hsw-4770r/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][11] ([i915#44]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +6 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15815/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
[i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#553]: https://gitlab.freedesktop.org/drm/intel/issues/553
[i915#592]: https://gitlab.freedesktop.org/drm/intel/issues/592
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (54 -> 45)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-hsw-4770 fi-tgl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7585 -> Patchwork_15815
CI-20190529: 20190529
CI_DRM_7585: 96c4bb3771fb5fda19a0fa83ec2e7dba9bf6f878 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5350: 36431c5923099582e87379aec8e16d43090d06a7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15815:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm: Add __drm_atomic_helper_crtc_state_reset() & co. (rev3)
(+Lakshmi)
On Tue, Dec 17, 2019 at 06:33:58PM +, Souza, Jose wrote:
> On Tue, 2019-12-17 at 18:10 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [1/5] drm: Add
> > __drm_atomic_helper_crtc_state_reset() & co. (rev3)
> > URL : https://patchwork.freedesktop.org/series/69129/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_7578_full -> Patchwork_15797_full
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_15797_full absolutely
> > need to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the
> > changes
> > introduced in Patchwork_15797_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_15797_full:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@kms_big_fb@linear-16bpp-rotate-180:
> > - shard-tglb: [PASS][1] -> [DMESG-WARN][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-tglb5/igt@kms_big...@linear-16bpp-rotate-180.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-tglb3/igt@kms_big...@linear-16bpp-rotate-180.html
>
> This one is not related to the changes in this series
>
> >
> > * igt@kms_frontbuffer_tracking@basic:
> > - shard-skl: [PASS][3] -> ([INCOMPLETE][4], [PASS][5])
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7578/shard-skl4/igt@kms_frontbuffer_track...@basic.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl10/igt@kms_frontbuffer_track...@basic.html
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15797/shard-skl7/igt@kms_frontbuffer_track...@basic.html
> >
>
> Getting AccessDenied when trying to access the error reports
>
> >
> >
> > ### Piglit changes ###
> >
> > Possible regressions
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 512 1 8 128 3 (NEW):
> > - {pig-hsw-4770r}:NOTRUN -> [FAIL][6] +20 similar issues
> >[6]: None
> >
> >
> > New tests
> > -
> >
> > New tests have been introduced between CI_DRM_7578_full and
> > Patchwork_15797_full:
> >
> > ### New Piglit tests (21) ###
> >
> > * object namespace pollution@texture with glgetteximage-compressed:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.13] s
> >
> > * object namespace pollution@texture with gltexsubimage2d:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.15] s
> >
> > * spec@arb_gpu_shader5@texturegather@vs-rgb-0-float-cube:
> > - Statuses : 1 fail(s)
> > - Exec time: [1.83] s
> >
> > * spec@arb_query_buffer_object@coherency:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.22] s
> >
> > * spec@arb_shader_image_load_store@host-mem-barrier:
> > - Statuses : 1 fail(s)
> > - Exec time: [5.66] s
> >
> > * spec@arb_shader_image_load_store@layer:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.31] s
> >
> > * spec@arb_shader_image_load_store@level:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.27] s
> >
> > * spec@arb_shader_image_load_store@semantics:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.53] s
> >
> > * spec@arb_shader_image_load_store@unused:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.16] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 32 1 8 128 2:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.13] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 32 42 1 128 4:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.08] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 32 42 8 128 2:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.10] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 32 42 8 128 3:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.12] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 512 1 8 128 3:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.24] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 512 1 8 128 4:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.27] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 512 1 8 128 8:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.26] s
> >
> > * spec@arb_texture_barrier@arb_texture_barrier-blending-in-shader
> > 512 42 1 128 8:
> > - Statuses : 1 fail(s)
> > - Exec time: [0.19] s
> >
> > * spec@arb_texture_barrier@ar
Re: [Intel-gfx] [PATCH 2/8] drm/client: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:44PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms() and drm_err() over DRM_DEV_DEBUG_KMS() and
> DRM_DEV_ERROR().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_client.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index d9a2e3695525..b031b45aa8ef 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -150,7 +150,7 @@ void drm_client_release(struct drm_client_dev *client)
> {
> struct drm_device *dev = client->dev;
>
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s\n", client->name);
> + drm_dbg_kms(dev, "%s\n", client->name);
>
> drm_client_modeset_free(client);
> drm_client_close(client);
> @@ -203,7 +203,7 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> continue;
>
> ret = client->funcs->hotplug(client);
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
> + drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
> }
> mutex_unlock(&dev->clientlist_mutex);
> }
> @@ -223,7 +223,7 @@ void drm_client_dev_restore(struct drm_device *dev)
> continue;
>
> ret = client->funcs->restore(client);
> - DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
> + drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
> if (!ret) /* The first one to return zero gets the privilege to
> restore */
> break;
> }
> @@ -351,8 +351,8 @@ static void drm_client_buffer_rmfb(struct
> drm_client_buffer *buffer)
>
> ret = drm_mode_rmfb(buffer->client->dev, buffer->fb->base.id,
> buffer->client->file);
> if (ret)
> - DRM_DEV_ERROR(buffer->client->dev->dev,
> - "Error removing FB:%u (%d)\n",
> buffer->fb->base.id, ret);
> + drm_err(buffer->client->dev,
> + "Error removing FB:%u (%d)\n", buffer->fb->base.id,
> ret);
>
> buffer->fb = NULL;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/fb-helper: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:45PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms(), drm_info(), and drm_err() over all other
> logging. This is about KMS so switch to the KMS category while at it.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_fb_helper.c | 36 ++---
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fb9bff0f4581..f8e905192608 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -191,6 +191,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> {
> struct drm_fb_helper *helper = info->par;
> struct drm_client_dev *client = &helper->client;
> + struct drm_device *dev = helper->dev;
> struct drm_crtc *crtc;
> const struct drm_crtc_helper_funcs *funcs;
> struct drm_mode_set *mode_set;
> @@ -209,7 +210,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
> continue;
>
> if (!fb) {
> - DRM_ERROR("no fb to restore??\n");
> + drm_err(dev, "no fb to restore?\n");
> continue;
> }
>
> @@ -1248,12 +1249,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> {
> struct drm_fb_helper *fb_helper = info->par;
> struct drm_framebuffer *fb = fb_helper->fb;
> + struct drm_device *dev = fb_helper->dev;
>
> if (in_dbg_master())
> return -EINVAL;
>
> if (var->pixclock != 0) {
> - DRM_DEBUG("fbdev emulation doesn't support changing the pixel
> clock, value of pixclock is ignored\n");
> + drm_dbg_kms(dev, "fbdev emulation doesn't support changing the
> pixel clock, value of pixclock is ignored\n");
> var->pixclock = 0;
> }
>
> @@ -1268,7 +1270,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> var->xres > fb->width || var->yres > fb->height ||
> var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> - DRM_DEBUG("fb requested width/height/bpp can't fit in current
> fb "
> + drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in
> current fb "
> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> var->xres, var->yres, var->bits_per_pixel,
> var->xres_virtual, var->yres_virtual,
> @@ -1295,7 +1297,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
>* so reject all pixel format changing requests.
>*/
> if (!drm_fb_pixel_format_equal(var, &info->var)) {
> - DRM_DEBUG("fbdev emulation doesn't support changing the pixel
> format\n");
> + drm_dbg_kms(dev, "fbdev emulation doesn't support changing the
> pixel format\n");
> return -EINVAL;
> }
>
> @@ -1320,7 +1322,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
> return -EBUSY;
>
> if (var->pixclock != 0) {
> - DRM_ERROR("PIXEL CLOCK SET\n");
> + drm_err(fb_helper->dev, "PIXEL CLOCK SET\n");
> return -EINVAL;
> }
>
> @@ -1430,6 +1432,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>int preferred_bpp)
> {
> struct drm_client_dev *client = &fb_helper->client;
> + struct drm_device *dev = fb_helper->dev;
> int ret = 0;
> int crtc_count = 0;
> struct drm_connector_list_iter conn_iter;
> @@ -1493,7 +1496,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> struct drm_plane *plane = crtc->primary;
> int j;
>
> - DRM_DEBUG("test CRTC %u primary plane\n", drm_crtc_index(crtc));
> + drm_dbg_kms(dev, "test CRTC %u primary plane\n",
> drm_crtc_index(crtc));
>
> for (j = 0; j < plane->format_count; j++) {
> const struct drm_format_info *fmt;
> @@ -1526,7 +1529,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
> }
> if (sizes.surface_depth != best_depth && best_depth) {
> - DRM_INFO("requested bpp %d, scaled depth down to %d",
> + drm_info(dev, "requested bpp %d, scaled depth down to %d",
>sizes.surface_bpp, best_depth);
> sizes.surface_depth = best_depth;
> }
> @@ -1574,7 +1577,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> mutex_unlock(&client->modeset_mutex);
>
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> - DRM_INFO("Cannot find any crtc or sizes\n");
> + drm_info(dev, "Cannot find any
Re: [Intel-gfx] [PATCH 4/8] drm/gem-fb-helper: convert to drm device based logging
On Tue, Dec 10, 2019 at 02:30:46PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_kms() and drm_err() over all other logging.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index b9bcd310ca2d..3a7ace19a902 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -74,8 +74,7 @@ drm_gem_fb_alloc(struct drm_device *dev,
>
> ret = drm_framebuffer_init(dev, fb, funcs);
> if (ret) {
> - DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
> - ret);
> + drm_err(dev, "Failed to init framebuffer: %d\n", ret);
> kfree(fb);
> return ERR_PTR(ret);
> }
> @@ -160,7 +159,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
> struct drm_file *file,
>
> objs[i] = drm_gem_object_lookup(file, mode_cmd->handles[i]);
> if (!objs[i]) {
> - DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> + drm_dbg_kms(dev, "Failed to lookup GEM object\n");
> ret = -ENOENT;
> goto err_gem_object_put;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/mipi-dbi: convert to drm device based logging
On Tue, Dec 10, 2019 at 02:30:47PM +0200, Jani Nikula wrote:
> Prefer drm device based logging where possible.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index e34058c721be..86d98e7fc30a 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -225,7 +225,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
> break;
> default:
> - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> + drm_err_once(fb->dev, "Format is not supported: %s\n",
>drm_get_format_name(fb->format->format,
>&format_name));
> return -EINVAL;
> @@ -242,7 +242,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem);
> - struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> + struct drm_device *dev = fb->dev;
In this file the pattern is to use the variable name "drm" for a
drm_device *. Your changes should follow the same pattern.
Sam
> + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(dev);
> unsigned int height = rect->y2 - rect->y1;
> unsigned int width = rect->x2 - rect->x1;
> struct mipi_dbi *dbi = &dbidev->dbi;
> @@ -259,7 +260,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
>
> full = width == fb->width && height == fb->height;
>
> - DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> DRM_RECT_ARG(rect));
> + drm_dbg_kms(dev, "Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> DRM_RECT_ARG(rect));
>
> if (!dbi->dc || !full || swap ||
> fb->format->format == DRM_FORMAT_XRGB) {
> @@ -282,7 +283,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> width * height * 2);
> err_msg:
> if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> ret);
> + drm_err_once(dev, "Failed to update display %d\n", ret);
>
> drm_dev_exit(idx);
> }
> @@ -649,14 +650,14 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
>
> static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi_dev *dbidev,
> bool cond)
> {
> - struct device *dev = dbidev->drm.dev;
> + struct drm_device *dev = &dbidev->drm;
> struct mipi_dbi *dbi = &dbidev->dbi;
> int ret;
>
> if (dbidev->regulator) {
> ret = regulator_enable(dbidev->regulator);
> if (ret) {
> - DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
> ret);
> + drm_err(dev, "Failed to enable regulator (%d)\n", ret);
> return ret;
> }
> }
> @@ -667,7 +668,7 @@ static int mipi_dbi_poweron_reset_conditional(struct
> mipi_dbi_dev *dbidev, bool
> mipi_dbi_hw_reset(dbi);
> ret = mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
> if (ret) {
> - DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
> + drm_err(dev, "Failed to send reset command (%d)\n", ret);
> if (dbidev->regulator)
> regulator_disable(dbidev->regulator);
> return ret;
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset
On Tue, Dec 17, 2019 at 12:50:31PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 16, 2019 at 02:58:13PM -0800, Manasi Navare wrote:
> > On Mon, Dec 16, 2019 at 02:33:10PM -0800, Manasi Navare wrote:
> > > On Mon, Dec 16, 2019 at 11:37:38PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Dec 16, 2019 at 11:13:09AM -0800, Manasi Navare wrote:
> > > > > On Mon, Dec 16, 2019 at 04:37:38PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Dec 11, 2019 at 01:14:23PM -0800, Manasi Navare wrote:
> > > > > > > In case of tiled displays, all the tiles are linke dto each other
> > > > > > > for transcoder port sync. So in intel_atomic_check() we need to
> > > > > > > make
> > > > > > > sure that we add all the tiles to the modeset and if one of the
> > > > > > > tiles needs a full modeset then mark all other tiles for a full
> > > > > > > modeset.
> > > > > > >
> > > > > > > Suggested-by: Ville Syrjälä
> > > > > > > Cc: Ville Syrjälä
> > > > > > > Cc: José Roberto de Souza
> > > > > > > Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/5
> > > > > > > Signed-off-by: Manasi Navare
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 78
> > > > > > >
> > > > > > > 1 file changed, 78 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > index 803993a01ca7..7263eaa66cda 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > @@ -14066,6 +14066,80 @@ static int
> > > > > > > intel_atomic_check_crtcs(struct intel_atomic_state *state)
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > +static int
> > > > > > > +intel_dp_modeset_all_tiles(struct drm_i915_private *dev_priv,
> > > > > > > +struct intel_atomic_state *state, int
> > > > > > > tile_grp_id)
> > > > > > > +{
> > > > > > > + struct drm_connector *conn_iter;
> > > > > > > + struct drm_connector_list_iter conn_list_iter;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > > +
> > > > > > > + drm_connector_list_iter_begin(&dev_priv->drm, &conn_list_iter);
> > > > > > > + drm_for_each_connector_iter(conn_iter, &conn_list_iter) {
> > > > > > > + struct drm_connector_state *conn_iter_state;
> > > > > > > +
> > > > > > > + if (!conn_iter->has_tile)
> > > > > > > + continue;
> > > > > > > + conn_iter_state =
> > > > > > > drm_atomic_get_connector_state(&state->base,
> > > > > > > +
> > > > > > > conn_iter);
> > > > > > > + if (IS_ERR(conn_iter_state)) {
> > > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > > + return PTR_ERR(conn_iter_state);
> > > > > > > + }
> > > > > > > +
> > > > > > > + if (!conn_iter_state->crtc)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + if (conn_iter->tile_group->id != tile_grp_id)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + crtc_state = drm_atomic_get_crtc_state(&state->base,
> > > > > > > conn_iter_state->crtc);
> > > > > > > + if (IS_ERR(crtc_state)) {
> > > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > > + return PTR_ERR(conn_iter_state);
> > > > > > > + }
> > > > > > > + crtc_state->mode_changed = true;
> > > > > > > + }
> > > > > > > + drm_connector_list_iter_end(&conn_list_iter);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int
> > > > > > > +intel_dp_atomic_trans_port_sync_check(struct drm_i915_private
> > > > > > > *dev_priv,
> > > > > > > + struct intel_atomic_state *state)
> > > > > > > +{
> > > > > > > + struct drm_connector *connector;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > > + struct drm_connector_state *connector_state;
> > > > > > > + int i, ret, tile_grp_id = 0;
> > > > > > > +
> > > > > > > + if (INTEL_GEN(dev_priv) < 11)
> > > > > > > + return 0;
> > > > > > > +
> > > > > > > + /* Is tiled, mark all other tiled CRTCs as needing a modeset */
> > > > > > > + for_each_new_connector_in_state(&state->base, connector,
> > > > > > > connector_state, i) {
> > > > > > > + if (!connector->has_tile)
> > > > > > > + continue;
> > > > > > > + if (connector_state->crtc &&
> > > > > > > + tile_grp_id != connector->tile_group->id) {
> > > > > > > + crtc_state =
> > > > > > > drm_atomic_get_new_crtc_state(&state->base,
> > > > > > > +
> > > > > > > connector_state->crtc);
> > > > > > > + if (!drm_atomic_crtc_needs_modeset(crtc_state))
> > > > > > > +
Re: [Intel-gfx] [PATCH 6/8] drm/atomic: convert to drm device based logging
Hi Jani.
On Tue, Dec 10, 2019 at 02:30:48PM +0200, Jani Nikula wrote:
> Prefer drm_dbg_atomic().
This patch simplify code by introducing a local drm_device varialble
which is good. But this is not mentioned in the cahngelog.
Anf the patch uses more than just drm_dbg_atomic(), see for example the
first patch below.
With updated changelog and small nit mentioned later fixed:
Reviewed-by: Sam Ravnborg
Sam
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_agpsupport.c | 4 +-
> drivers/gpu/drm/drm_atomic.c | 187 +--
> 2 files changed, 102 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4c7ad46fdd21..cd675e58de50 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -330,8 +330,8 @@ int drm_agp_bind(struct drm_device *dev, struct
> drm_agp_binding *request)
> if (retcode)
> return retcode;
> entry->bound = dev->agp->base + (page << PAGE_SHIFT);
> - DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
> - dev->agp->base, entry->bound);
> + drm_dbg_core(dev, "base = 0x%lx entry->bound = 0x%lx\n",
> + dev->agp->base, entry->bound);
> return 0;
> }
> EXPORT_SYMBOL(drm_agp_bind);
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 14aeaf736321..8494b1c29bf0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -99,7 +99,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
> drm_atomic_state *state)
>
> state->dev = dev;
>
> - DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Allocated atomic state %p\n", state);
>
> return 0;
> fail:
> @@ -150,7 +150,7 @@ void drm_atomic_state_default_clear(struct
> drm_atomic_state *state)
> struct drm_mode_config *config = &dev->mode_config;
> int i;
>
> - DRM_DEBUG_ATOMIC("Clearing atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Clearing atomic state %p\n", state);
>
> for (i = 0; i < state->num_connector; i++) {
> struct drm_connector *connector = state->connectors[i].ptr;
> @@ -256,11 +256,12 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
> void __drm_atomic_state_free(struct kref *ref)
> {
> struct drm_atomic_state *state = container_of(ref, typeof(*state), ref);
> - struct drm_mode_config *config = &state->dev->mode_config;
> + struct drm_device *dev = state->dev;
> + struct drm_mode_config *config = &dev->mode_config;
>
> drm_atomic_state_clear(state);
>
> - DRM_DEBUG_ATOMIC("Freeing atomic state %p\n", state);
> + drm_dbg_atomic(dev, "Freeing atomic state %p\n", state);
>
> if (config->funcs->atomic_state_free) {
> config->funcs->atomic_state_free(state);
> @@ -290,8 +291,9 @@ struct drm_crtc_state *
> drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> {
> - int ret, index = drm_crtc_index(crtc);
> + struct drm_device *dev = state->dev;
> struct drm_crtc_state *crtc_state;
> + int ret, index = drm_crtc_index(crtc);
>
> WARN_ON(!state->acquire_ctx);
>
> @@ -313,8 +315,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> state->crtcs[index].ptr = crtc;
> crtc_state->state = state;
>
> - DRM_DEBUG_ATOMIC("Added [CRTC:%d:%s] %p state to %p\n",
> - crtc->base.id, crtc->name, crtc_state, state);
> + drm_dbg_atomic(dev, "Added [CRTC:%d:%s] %p state to %p\n",
> +crtc->base.id, crtc->name, crtc_state, state);
>
> return crtc_state;
> }
> @@ -324,6 +326,7 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>const struct drm_crtc_state *new_crtc_state)
> {
> struct drm_crtc *crtc = new_crtc_state->crtc;
> + struct drm_device *dev = crtc->dev;
>
> /* NOTE: we explicitly don't enforce constraints such as primary
>* layer covering entire screen, since that is something we want
> @@ -334,25 +337,25 @@ static int drm_atomic_crtc_check(const struct
> drm_crtc_state *old_crtc_state,
>*/
>
> if (new_crtc_state->active && !new_crtc_state->enable) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
> - crtc->base.id, crtc->name);
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] active without enabled\n",
> +crtc->base.id, crtc->name);
> return -EINVAL;
> }
>
> /* The state->enable vs. state->mode_blob checks can be WARN_ON,
>* as this is a kernel-internal detail that userspace should never
>* be able to trigger. */
> - if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
> + if (drm_core_check_feature(dev, DRIV
Re: [Intel-gfx] [PATCH 5/8] drm/mipi-dbi: convert to drm device based logging
On Tue, Dec 17, 2019 at 08:00:11PM +0100, Sam Ravnborg wrote:
> On Tue, Dec 10, 2019 at 02:30:47PM +0200, Jani Nikula wrote:
> > Prefer drm device based logging where possible.
> >
> > Signed-off-by: Jani Nikula
> > ---
> > drivers/gpu/drm/drm_mipi_dbi.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> > index e34058c721be..86d98e7fc30a 100644
> > --- a/drivers/gpu/drm/drm_mipi_dbi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> > @@ -225,7 +225,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> > *fb,
> > drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
> > break;
> > default:
> > - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> > + drm_err_once(fb->dev, "Format is not supported: %s\n",
> > drm_get_format_name(fb->format->format,
> > &format_name));
> > return -EINVAL;
> > @@ -242,7 +242,8 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> > {
> > struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
> > struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(gem);
> > - struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
> > + struct drm_device *dev = fb->dev;
>
> In this file the pattern is to use the variable name "drm" for a
> drm_device *. Your changes should follow the same pattern.
With this fixed:
Reviewed-by: Sam Ravnborg
>
> Sam
>
> > + struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(dev);
> > unsigned int height = rect->y2 - rect->y1;
> > unsigned int width = rect->x2 - rect->x1;
> > struct mipi_dbi *dbi = &dbidev->dbi;
> > @@ -259,7 +260,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> >
> > full = width == fb->width && height == fb->height;
> >
> > - DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> > DRM_RECT_ARG(rect));
> > + drm_dbg_kms(dev, "Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id,
> > DRM_RECT_ARG(rect));
> >
> > if (!dbi->dc || !full || swap ||
> > fb->format->format == DRM_FORMAT_XRGB) {
> > @@ -282,7 +283,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer
> > *fb, struct drm_rect *rect)
> >width * height * 2);
> > err_msg:
> > if (ret)
> > - dev_err_once(fb->dev->dev, "Failed to update display %d\n",
> > ret);
> > + drm_err_once(dev, "Failed to update display %d\n", ret);
> >
> > drm_dev_exit(idx);
> > }
> > @@ -649,14 +650,14 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
> >
> > static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi_dev *dbidev,
> > bool cond)
> > {
> > - struct device *dev = dbidev->drm.dev;
> > + struct drm_device *dev = &dbidev->drm;
> > struct mipi_dbi *dbi = &dbidev->dbi;
> > int ret;
> >
> > if (dbidev->regulator) {
> > ret = regulator_enable(dbidev->regulator);
> > if (ret) {
> > - DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
> > ret);
> > + drm_err(dev, "Failed to enable regulator (%d)\n", ret);
> > return ret;
> > }
> > }
> > @@ -667,7 +668,7 @@ static int mipi_dbi_poweron_reset_conditional(struct
> > mipi_dbi_dev *dbidev, bool
> > mipi_dbi_hw_reset(dbi);
> > ret = mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
> > if (ret) {
> > - DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
> > + drm_err(dev, "Failed to send reset command (%d)\n", ret);
> > if (dbidev->regulator)
> > regulator_disable(dbidev->regulator);
> > return ret;
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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/pmu: Ensure monotonic rc6 (rev2)
== Series Details ==
Series: drm/i915/pmu: Ensure monotonic rc6 (rev2)
URL : https://patchwork.freedesktop.org/series/70998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7585 -> Patchwork_15816
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/index.html
Known issues
Here are the changes found in Patchwork_15816 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900: [PASS][1] -> [DMESG-FAIL][2] ([i915#722])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [PASS][3] -> [DMESG-FAIL][4] ([i915#419])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-icl-u3: [PASS][5] -> [INCOMPLETE][6] ([i915#140])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-icl-u3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-icl-u3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2: [DMESG-WARN][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][9] ([i915#592]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][11] ([i915#770]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-4770/igt@i915_selftest@live_blt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-hsw-4770/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-hsw-peppy: [INCOMPLETE][13] ([i915#694]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][17] ([i915#44]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][19] ([i915#553] / [i915#725]) ->
[DMESG-FAIL][20] ([i915#725])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-hsw-4770r/igt@i915_selftest@live_blt.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +5 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) ->
[DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15816/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
{name}: This element is suppressed. This means it is ignore
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,rebased,1/2] drm/i915/display/icl+: Do not program clockgating
== Series Details ==
Series: series starting with [v4,rebased,1/2] drm/i915/display/icl+: Do not
program clockgating
URL : https://patchwork.freedesktop.org/series/71058/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7585 -> Patchwork_15817
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/index.html
Known issues
Here are the changes found in Patchwork_15817 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [PASS][1] -> [TIMEOUT][2] ([i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [TIMEOUT][4] ([i915#816])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@kms_frontbuffer_tracking@basic:
- fi-skl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#667])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-guc/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-skl-guc/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- {fi-tgl-guc}: [INCOMPLETE][7] ([fdo#111593]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-tgl-guc/igt@gem_exec_gttf...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-tgl-guc/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s0:
- fi-skl-6700k2: [DMESG-WARN][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html
* igt@gem_sync@basic-each:
- {fi-tgl-u}: [INCOMPLETE][11] ([i915#472] / [i915#707]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-tgl-u/igt@gem_s...@basic-each.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-tgl-u/igt@gem_s...@basic-each.html
* igt@i915_module_load@reload-no-display:
- fi-skl-lmem:[DMESG-WARN][13] ([i915#592]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-skl-lmem/igt@i915_module_l...@reload-no-display.html
Warnings
* igt@i915_selftest@live_blt:
- fi-hsw-4770:[DMESG-FAIL][15] ([i915#770]) -> [DMESG-FAIL][16]
([i915#725])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-4770/igt@i915_selftest@live_blt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-hsw-4770/igt@i915_selftest@live_blt.html
- fi-hsw-4770r: [DMESG-FAIL][17] ([i915#553] / [i915#725]) ->
[DMESG-FAIL][18] ([i915#725])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-hsw-4770r/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][19] ([fdo#111407]) -> [FAIL][20] ([fdo#111096]
/ [i915#323])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-kbl-x1275/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] / [i915#92]) +6 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7585/fi-kbl-x1275/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15817/fi-kbl-x1275/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
th
Re: [Intel-gfx] [PATCH] drm/i915/display: cleanup intel_bw_state on i915 module removal
On Thu, Dec 12, 2019 at 12:34:49PM -0800, Lucas De Marchi wrote: On Thu, Dec 12, 2019 at 09:37:17AM -0800, Matt Roper wrote: On Wed, Dec 11, 2019 at 04:22:50PM -0800, Lucas De Marchi wrote: On Wed, Dec 11, 2019 at 12:10:41PM +0530, Bharadiya,Pankaj wrote: On Tue, Dec 10, 2019 at 09:57:39PM -0800, Lucas De Marchi wrote: > On Mon, Dec 09, 2019 at 08:09:02PM +0530, Pankaj Bharadiya wrote: > >intel_bw_state allocated memory is not getting freed even after > >module removal. > > > >kmemleak reported backtrace: > > > > [<79019739>] kmemdup+0x17/0x40 > > [] intel_bw_duplicate_state+0x1b/0x40 [i915] > > [<7423ed0c>] drm_atomic_get_private_obj_state+0xca/0x140 > > [<100e3533>] intel_bw_atomic_check+0x133/0x350 [i915] > > [<126d0e0c>] intel_atomic_check+0x1ab7/0x20d0 [i915] > > [ ] drm_atomic_check_only+0x563/0x810 > > [ ] drm_atomic_commit+0xe/0x50 > > [ ] drm_atomic_helper_disable_all+0x133/0x160 > > [<3c44760c>] drm_atomic_helper_shutdown+0x65/0xc0 > > [<414e3e5c>] i915_driver_remove+0xcb/0x130 [i915] > > [ ] i915_pci_remove+0x19/0x40 [i915] > > [<2dcbd148>] pci_device_remove+0x36/0xb0 > > [<3c8c6b0a>] device_release_driver_internal+0xe0/0x1c0 > > [<580e9566>] unbind_store+0xc3/0x120 > > [<869d0df5>] kernfs_fop_write+0x104/0x190 > > [<4dc1a355>] vfs_write+0xb9/0x1d0 > > what I find strange in this is that the last state was allocated by the > "driver remove" code path. > > > > >Call the drm_atomic_private_obj_fini(), which inturn calls the > >intel_bw_destroy_state() to make sure the intel_bw_state memory is > >freed properly. > > > >Signed-off-by: Pankaj Bharadiya > >--- > >drivers/gpu/drm/i915/display/intel_bw.c | 5 + > >drivers/gpu/drm/i915/display/intel_bw.h | 1 + > >drivers/gpu/drm/i915/display/intel_display.c | 2 ++ > >3 files changed, 8 insertions(+) > > > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c > >index dcb66a33be9b..b228671d5a5d 100644 > >--- a/drivers/gpu/drm/i915/display/intel_bw.c > >+++ b/drivers/gpu/drm/i915/display/intel_bw.c > >@@ -486,3 +486,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv) > > > > return 0; > >} > >+ > >+void intel_bw_cleanup(struct drm_i915_private *dev_priv) > >+{ > >+ drm_atomic_private_obj_fini(&dev_priv->bw_obj); > >+} > >diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h > >index 9db10af012f4..20b9ad241802 100644 > >--- a/drivers/gpu/drm/i915/display/intel_bw.h > >+++ b/drivers/gpu/drm/i915/display/intel_bw.h > >@@ -25,6 +25,7 @@ struct intel_bw_state { > > > >void intel_bw_init_hw(struct drm_i915_private *dev_priv); > >int intel_bw_init(struct drm_i915_private *dev_priv); > >+void intel_bw_cleanup(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); > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > >index 3190aa27ffdc..756eb90b1bb1 100644 > >--- a/drivers/gpu/drm/i915/display/intel_display.c > >+++ b/drivers/gpu/drm/i915/display/intel_display.c > >@@ -17912,6 +17912,8 @@ void intel_modeset_driver_remove(struct drm_i915_private *i915) > > > > intel_gmbus_teardown(i915); > > > >+ intel_bw_cleanup(i915); > > This doesn't seem to match the (reverse) order of > intel_modeset_init()... but it's actually the gmbus_teardown() that is > out of place. Did you check if it's not a wrong shutdown ordering? > In intel_modeset_init(), intel_gmbus_setup() happens after intel_bw_init(). I think the patch follows the reverse ordering properly. Am I missing anything? I said it seems that it's the gmbus_teardown() that is out of place. Have you seen my comment above? Why are we duplicating the bw_state on the module-remove code path? I think that part is legitimate. Part of the module remove sequence does an atomic commit to turn everything off. During atomic transactions, we create duplicates of all modesetting state objects can be modified; if/when the transaction succeeds, those duplicates are swapped into the actual driver state and the old objects are destroyed. Thus in cases like this where we forget to destroy a private object state, that leaked state structure will be the one allocated during the very last atomic transaction that happened (i.e., on the driver teardown codepath). humn, that makes sense. The new duplicate state will replace the previous one and hence why we see it in the backtrace, rather than one allocated previously. thanks Lucas De Marchi and... Reviewed-by: Lucas De Marchi Lucas De Marchi Matt Lucas De Marchi Thanks, Pankaj > thanks > Lucas De Mar
Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support
On Fri, Dec 13, 2019 at 01:56:04PM -0800, Niranjana Vishwanathapura wrote: > + ctx = i915_gem_context_lookup(file->driver_priv, args->rsvd1); > + if (!ctx || !rcu_access_pointer(ctx->vm)) > + return -ENOENT; > + > + rcu_read_lock(); > + vm = i915_vm_get(ctx->vm); > + rcu_read_unlock(); This looks like wrong use of RCU to me. Getting a rcu lock and not calling rcu_dereference under it is basically guarenteed to be wrong.. Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi Daniel,
On Tue, 17 Dec 2019 14:19:37 +0100 Daniel Vetter wrote:
>
> On Mon, Dec 16, 2019 at 12:23:31PM +1100, Stephen Rothwell wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c: In function
> > 'anx6345_i2c_probe':
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:30: error: implicit
> > declaration of function 'i2c_new_dummy'
> > [-Werror=implicit-function-declaration]
> > 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> > | ^
> > drivers/gpu/drm/bridge/analogix/analogix-anx6345.c:738:28: warning:
> > assignment to 'struct i2c_client *' from 'int' makes pointer from integer
> > without a cast [-Wint-conversion]
> > 738 |anx6345->i2c_clients[i] = i2c_new_dummy(client->adapter,
> > |^
> >
> > Caused by commit
> >
> > 6aa192698089 ("drm/bridge: Add Analogix anx6345 support")
> >
> > interacting with commit
> >
> > 2c2f00ab1641 ("i2c: remove i2c_new_dummy() API")
> >
> > From Linus' tree.
> >
> > I have applied the following fix up patch for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 16 Dec 2019 12:11:19 +1100
> > Subject: [PATCH] drm/bridge: fix up for removal of i2c_new_dummy()
> >
> > Signed-off-by: Stephen Rothwell
>
> Thanks pulled into drm-next since I just processed the first drm-misc-next
> pull.
Thanks. For the future, though, merge fixes like this should be part
of the actual merge commit to avoid bisection problems.
--
Cheers,
Stephen Rothwell
pgpcULRT3Pf9e.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2 05/12] drm/i915/svm: Page table mirroring support
On Fri, Dec 13, 2019 at 01:56:07PM -0800, Niranjana Vishwanathapura wrote:
> +static struct i915_svm *vm_get_svm(struct i915_address_space *vm)
> +{
> + struct i915_svm *svm = vm->svm;
> +
> + mutex_lock(&vm->svm_mutex);
> + if (svm && !kref_get_unless_zero(&svm->ref))
> + svm = NULL;
Quite strange to see a get_unless_zero under a lock..
> +static void release_svm(struct kref *ref)
> +{
> + struct i915_svm *svm = container_of(ref, typeof(*svm), ref);
> + struct i915_address_space *vm = svm->vm;
> +
> + mmu_notifier_unregister(&svm->notifier, svm->notifier.mm);
This would be a lot better to use mmu_notifier_put to manage the
reference and deallocation.
> +static u32 i915_svm_build_sg(struct i915_address_space *vm,
> + struct hmm_range *range,
> + struct sg_table *st)
> +{
> + struct scatterlist *sg;
> + u32 sg_page_sizes = 0;
> + u64 i, npages;
> +
> + sg = NULL;
> + st->nents = 0;
> + npages = (range->end - range->start) / PAGE_SIZE;
> +
> + /*
> + * No need to dma map the host pages and later unmap it, as
> + * GPU is not allowed to access it with SVM.
> + * XXX: Need to dma map host pages for integrated graphics while
> + * extending SVM support there.
> + */
> + for (i = 0; i < npages; i++) {
> + u64 addr = range->pfns[i] & ~((1UL << range->pfn_shift) - 1);
> +
> + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> + sg->length += PAGE_SIZE;
> + sg_dma_len(sg) += PAGE_SIZE;
> + continue;
> + }
> +
> + if (sg)
> + sg_page_sizes |= sg->length;
> +
> + sg = sg ? __sg_next(sg) : st->sgl;
> + sg_dma_address(sg) = addr;
> + sg_dma_len(sg) = PAGE_SIZE;
This still can't be like this - assigning pfn to 'dma_address' is
fundamentally wrong.
Whatever explanation you had, this needs to be fixed up first before we get
to this patch.
> +static int i915_range_fault(struct svm_notifier *sn,
> + struct drm_i915_gem_vm_bind *args,
> + struct sg_table *st, u64 *pfns)
> +{
> + unsigned long timeout =
> + jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
> + /* Have HMM fault pages within the fault window to the GPU. */
> + struct hmm_range range = {
> + .notifier = &sn->notifier,
> + .start = sn->notifier.interval_tree.start,
> + .end = sn->notifier.interval_tree.last + 1,
> + .pfns = pfns,
> + .pfn_shift = PAGE_SHIFT,
> + .flags = i915_range_flags,
> + .values = i915_range_values,
> + .default_flags = (range.flags[HMM_PFN_VALID] |
> + ((args->flags & I915_GEM_VM_BIND_READONLY) ?
> +0 : range.flags[HMM_PFN_WRITE])),
> + .pfn_flags_mask = 0,
> +
> + };
> + struct i915_svm *svm = sn->svm;
> + struct mm_struct *mm = sn->notifier.mm;
> + struct i915_address_space *vm = svm->vm;
> + u32 sg_page_sizes;
> + u64 flags;
> + long ret;
> +
> + while (true) {
> + if (time_after(jiffies, timeout))
> + return -EBUSY;
> +
> + range.notifier_seq = mmu_interval_read_begin(range.notifier);
> + down_read(&mm->mmap_sem);
> + ret = hmm_range_fault(&range, 0);
> + up_read(&mm->mmap_sem);
> + if (ret <= 0) {
> + if (ret == 0 || ret == -EBUSY)
> + continue;
> + return ret;
> + }
> +
> + sg_page_sizes = i915_svm_build_sg(vm, &range, st);
> + mutex_lock(&svm->mutex);
> + if (mmu_interval_read_retry(range.notifier,
> + range.notifier_seq)) {
> + mutex_unlock(&svm->mutex);
> + continue;
> + }
> + break;
> + }
> +
> + flags = (args->flags & I915_GEM_VM_BIND_READONLY) ?
> + I915_GTT_SVM_READONLY : 0;
> + ret = svm_bind_addr_commit(vm, args->start, args->length,
> +flags, st, sg_page_sizes);
> + mutex_unlock(&svm->mutex);
This looks better..
> +int i915_gem_vm_bind_svm_buffer(struct i915_address_space *vm,
> + struct drm_i915_gem_vm_bind *args)
> +{
> + struct svm_notifier sn;
> + struct i915_svm *svm;
> + struct mm_struct *mm;
> + struct sg_table st;
> + u64 npages, *pfns;
> + int ret = 0;
> +
> + svm = vm_get_svm(vm);
> + if (!svm)
> + return -EINVAL;
> +
> + mm = svm->notifier.mm;
> + if (mm != current->mm) {
> + ret = -EPERM;
> + goto bind_done;
> + }
Bit strange, we have APIs now to m
Re: [Intel-gfx] [RFC v2 06/12] drm/i915/svm: Device memory support
On Fri, Dec 13, 2019 at 01:56:08PM -0800, Niranjana Vishwanathapura wrote:
> @@ -169,6 +170,11 @@ static int i915_range_fault(struct svm_notifier *sn,
> return ret;
> }
>
> + /* For dgfx, ensure the range is in device local memory only */
> + regions = i915_dmem_convert_pfn(vm->i915, &range);
> + if (!regions || (IS_DGFX(vm->i915) && (regions & REGION_SMEM)))
> + return -EINVAL;
> +
This is not OK, as I said before, the driver cannot de-reference pfns
before doing the retry check, under lock.
> +
> +int i915_dmem_convert_pfn(struct drm_i915_private *dev_priv,
> + struct hmm_range *range)
> +{
> + unsigned long i, npages;
> + int regions = 0;
> +
> + npages = (range->end - range->start) >> PAGE_SHIFT;
> + for (i = 0; i < npages; ++i) {
> + struct i915_buddy_block *block;
> + struct intel_memory_region *mem;
> + struct page *page;
> + u64 addr;
> +
> + page = hmm_device_entry_to_page(range, range->pfns[i]);
^^
For instance, that cannot be done on a speculatively loaded page.
This also looks like it suffers from the same bug as
> + if (!page)
> + continue;
> +
> + if (!(range->pfns[i] & range->flags[HMM_PFN_DEVICE_PRIVATE])) {
> + regions |= REGION_SMEM;
> + continue;
> + }
> +
> + if (!i915_dmem_page(dev_priv, page)) {
> + WARN(1, "Some unknown device memory !\n");
Why is that a WARN? The user could put other device memory in the
address space. You need to 'segfault' the GPU execution if this happens.
> + range->pfns[i] = 0;
> + continue;
> + }
> +
> + regions |= REGION_LMEM;
> + block = page->zone_device_data;
> + mem = block->private;
> + addr = mem->region.start +
> +i915_buddy_block_offset(block);
> + addr += (page_to_pfn(page) - block->pfn_first) << PAGE_SHIFT;
> +
> + range->pfns[i] &= ~range->flags[HMM_PFN_DEVICE_PRIVATE];
> + range->pfns[i] &= ((1UL << range->pfn_shift) - 1);
> + range->pfns[i] |= (addr >> PAGE_SHIFT) << range->pfn_shift;
This makes more sense as a direct manipulation of the sgl, not sure
why this routine is split out from the sgl builder?
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Handle connector tile support only for modes that match tile size
On Tue, Dec 17, 2019 at 09:56:54AM +0200, Tomi Sarvela wrote: > On 12/17/19 1:59 AM, Manasi Navare wrote: > >On Fri, Dec 13, 2019 at 10:54:55AM +0200, Tomi Sarvela wrote: > >>On 12/12/19 11:28 PM, Manasi Navare wrote: > >>>The KBL failure does not look related to the changes in this patch series. > >>>Tomi, could you confirm if this is a false negative? > >>> > >>>Manasi > >> > >>The failures with the patchset seem same as all the other results from > >>live_gt_pm: just that kbl-x1275 hasn't been ticked to the bugfilter, > >>probably because it hasn't survived the test before (module_reload). > >> > >>I've triggered shard-run for this series. > > > >Any updates on the shard-run results? > > Results are available at normal place: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15701/index.html > Cool so the failures on kbl are unrealted and false positives and Full IGT tests pass so I am merging these patches. Manasi > Tomi > > >>>On Thu, Dec 12, 2019 at 02:46:49AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm: Handle connector tile support > only for modes that match tile size > URL : https://patchwork.freedesktop.org/series/70790/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7545 -> Patchwork_15701 > > > Summary > --- > > **FAILURE** > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15701/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_15701: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_gt_pm: > - fi-kbl-x1275: NOTRUN -> [DMESG-FAIL][1] > [1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15701/fi-kbl-x1275/igt@i915_selftest@live_gt_pm.html > > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15701/index.html > > > > -- > Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Handle connector tile support only for modes that match tile size
On Wed, Dec 11, 2019 at 01:24:32PM -0800, Manasi Navare wrote:
> DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
> is set, but we need to handle tile support and look for multiple CRTCs
> only for the modes that match the tile size. The other modes should
> be able to be displayed without tile support or uisng single CRTC.
>
> This patch adds the check to match the tile size with requested mode
> to handle the tile support.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Jani Nikula
> Cc: Dave Airlie
> Signed-off-by: Manasi Navare
Capturing Dave Airlie's r-b from IRC:
Reviewed-by: Dave Airlie
Manasi
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index fb9bff0f4581..4978363714a9 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1558,7 +1558,9 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> for (j = 0; j < mode_set->num_connectors; j++) {
> struct drm_connector *connector =
> mode_set->connectors[j];
>
> - if (connector->has_tile) {
> + if (connector->has_tile &&
> + desired_mode->hdisplay == connector->tile_h_size &&
> + desired_mode->vdisplay == connector->tile_v_size) {
> lasth = (connector->tile_h_loc ==
> (connector->num_h_tile - 1));
> lastv = (connector->tile_v_loc ==
> (connector->num_v_tile - 1));
> /* cloning to multiple tiles is just
> crazy-talk, so: */
> --
> 2.19.1
>
___
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: Fix pid leak with banned clients (rev2)
== Series Details == Series: drm/i915: Fix pid leak with banned clients (rev2) URL : https://patchwork.freedesktop.org/series/71062/ State : success == Summary == CI Bug Log - changes from CI_DRM_7587 -> Patchwork_15818 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/index.html Known issues Here are the changes found in Patchwork_15818 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-skl-lmem/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-skl-lmem/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-pnv-d510:[PASS][5] -> [FAIL][6] ([i915#34]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vblank.html * igt@kms_frontbuffer_tracking@basic: - fi-skl-6600u: [PASS][7] -> [INCOMPLETE][8] ([i915#667]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-skl-6600u/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-skl-6600u/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_close_race@basic-threads: - fi-byt-n2820: [TIMEOUT][9] ([i915#816]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-byt-n2820/igt@gem_close_r...@basic-threads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-byt-n2820/igt@gem_close_r...@basic-threads.html * igt@i915_selftest@live_blt: - fi-ivb-3770:[DMESG-FAIL][11] ([i915#770]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-ivb-3770/igt@i915_selftest@live_blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-ivb-3770/igt@i915_selftest@live_blt.html - fi-hsw-peppy: [DMESG-FAIL][13] ([i915#553] / [i915#725]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-hsw-peppy/igt@i915_selftest@live_blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-hsw-peppy/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_gem_contexts: - fi-byt-j1900: [DMESG-FAIL][15] ([i915#722]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html - fi-hsw-4770:[DMESG-FAIL][17] ([i915#722]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html Warnings * igt@i915_pm_rpm@module-reload: - fi-icl-u2: [DMESG-WARN][19] ([i915#289]) -> [DMESG-WARN][20] ([i915#109] / [i915#289]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-icl-u2/igt@i915_pm_...@module-reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-icl-u2/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_blt: - fi-hsw-4770:[DMESG-FAIL][21] ([i915#563]) -> [DMESG-FAIL][22] ([i915#553] / [i915#725]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-hsw-4770/igt@i915_selftest@live_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-hsw-4770/igt@i915_selftest@live_blt.html * igt@kms_busy@basic-flip-pipe-b: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15818/fi-kbl-x1275/igt@kms_b...@basic-flip-pipe-b.html * igt@kms_flip@basic-flip-vs-modeset: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][26] ([i915#62] / [i915#92]) +6 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7587/fi-kbl-x1275/igt@kms_f...@basic-f
Re: [Intel-gfx] [PATCH v2 2/7] drm/i915/guc/ct: Drop guards in enable/disable calls
On Tue, 17 Dec 2019 02:23:11 +0100, Daniele Ceraolo Spurio wrote: We track the status of the GuC much more closely now and we expect the enable/disable functions to be correctly called only once. If this isn't true we do want to flag it as a flow failure (via the BUG_ON in the ctch functions) and not silently ignore the call. Suggested-by: Michal Wajdeczko Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Michal Wajdeczko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/guc/ct: Stop expecting multiple CT channels
On Tue, 17 Dec 2019 02:23:12 +0100, Daniele Ceraolo Spurio wrote: The GuC supports having multiple CT buffer pairs and we designed our implementation with that in mind. However, the different channels are not processed in parallel within the GuC, so there is very little advantage in having multiple channels (independent locks?), compared to the drawbacks (one channel can starve the other if messages keep being submitted to it). Given this, it is unlikely we'll ever add a second channel and therefore we can simplify our code by removing the flexibility. v2: split substructure grouping to separate patch, improve docs (Michal) Signed-off-by: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Cc: John Harrison Cc: Matthew Brost --- Reviewed-by: Michal Wajdeczko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/guc/ct: Group request-related variables in a sub-structure
On Tue, 17 Dec 2019 02:23:13 +0100, Daniele Ceraolo Spurio
wrote:
For better isolation of the request tracking from the rest of the
CT-related data.
v2: split to separate patch, move next_fence to substructure (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
Reviewed-by: Michal Wajdeczko
with some nits below (we may fix them later)
/snip/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 6e3d789b9f01..29a026dc3a13 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -48,12 +48,15 @@ struct intel_guc_ct {
/* buffers for sending(0) and receiving(1) commands */
struct intel_guc_ct_buffer ctbs[2];
- u32 next_fence; /* fence to be used with next send command */
+ struct {
+ u32 next_fence; /* fence to be used with next request to send */
nit: strictly speaking this is "last" fence
we just use it to generate next one
- spinlock_t lock; /* protects pending requests list */
- struct list_head pending_requests; /* requests waiting for response */
- struct list_head incoming_requests; /* incoming requests */
- struct work_struct worker; /* handler for incoming requests */
+ spinlock_t lock; /* protects pending requests list */
nit: do we want to use this lock to protect "next/last" fence ?
if yes, then maybe lock shall be first ?
+ struct list_head pending; /* requests waiting for response */
+
+ struct list_head incoming; /* incoming requests */
+ struct work_struct worker; /* handler for incoming requests */
+ } requests;
};
void intel_guc_ct_init_early(struct intel_guc_ct *ct);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Remove function pointers for send/receive calls
On Tue, 17 Dec 2019 02:23:14 +0100, Daniele Ceraolo Spurio
wrote:
Since we started using CT buffers on all gens, the function pointers can
only be set to either the _nop() or the _ct() functions. Since the
_nop() case applies to when the CT are disabled, we can just handle that
case in the _ct() functions and call them directly.
v2: keep intel_guc_send() and make the CT send/receive functions work on
intel_guc_ct. (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 14 -
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 18 -
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 16 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 9 +++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 -
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 +++
6 files changed, 29 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 922a19635d20..daebfec0034c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -177,8 +177,6 @@ void intel_guc_init_early(struct intel_guc *guc)
mutex_init(&guc->send_mutex);
spin_lock_init(&guc->irq_lock);
- guc->send = intel_guc_send_nop;
- guc->handler = intel_guc_to_host_event_handler_nop;
if (INTEL_GEN(i915) >= 11) {
guc->notify = gen11_guc_raise_irq;
guc->interrupts.reset = gen11_reset_guc_interrupts;
@@ -403,18 +401,6 @@ void intel_guc_fini(struct intel_guc *guc)
intel_uc_fw_cleanup_fetch(&guc->fw);
}
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32
len,
- u32 *response_buf, u32 response_buf_size)
-{
- WARN(1, "Unexpected send: action=%#x\n", *action);
- return -ENODEV;
-}
-
-void intel_guc_to_host_event_handler_nop(struct intel_guc *guc)
-{
- WARN(1, "Unexpected event: no suitable handler\n");
-}
-
/*
* This function implements the MMIO based host to GuC interface.
*/
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index cd09c912e361..253b1ac7716e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -70,13 +70,6 @@ struct intel_guc {
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;
- /* GuC's FW specific send function */
- int (*send)(struct intel_guc *guc, const u32 *data, u32 len,
- u32 *response_buf, u32 response_buf_size);
-
- /* GuC's FW specific event handler function */
- void (*handler)(struct intel_guc *guc);
-
/* GuC's FW specific notify function */
void (*notify)(struct intel_guc *guc);
};
@@ -84,14 +77,15 @@ struct intel_guc {
static
inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
len)
{
- return guc->send(guc, action, len, NULL, 0);
+ return intel_guc_ct_send(&guc->ct, action, len, NULL, 0);
}
static inline int
intel_guc_send_and_receive(struct intel_guc *guc, const u32 *action,
u32 len,
u32 *response_buf, u32 response_buf_size)
{
- return guc->send(guc, action, len, response_buf, response_buf_size);
+ return intel_guc_ct_send(&guc->ct, action, len,
+response_buf, response_buf_size);
}
static inline void intel_guc_notify(struct intel_guc *guc)
@@ -101,7 +95,7 @@ static inline void intel_guc_notify(struct intel_guc
*guc)
static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
{
- guc->handler(guc);
+ intel_guc_ct_event_handler(&guc->ct);
}
/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
@@ -136,12 +130,8 @@ void intel_guc_init_send_regs(struct intel_guc
*guc);
void intel_guc_write_params(struct intel_guc *guc);
int intel_guc_init(struct intel_guc *guc);
void intel_guc_fini(struct intel_guc *guc);
-int intel_guc_send_nop(struct intel_guc *guc, const u32 *action, u32
len,
- u32 *response_buf, u32 response_buf_size);
int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
len,
u32 *response_buf, u32 response_buf_size);
-void intel_guc_to_host_event_handler(struct intel_guc *guc);
-void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
const u32 *payload, u32 len);
int intel_guc_sample_forcewake(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index f22cd9b2311b..c6f971a049f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -510,13 +510,18 @@ static int ct_se
